CRITICAL FACTOR 3: DEFINE THE PROCESS LANGUAGE FOR YOUR ORGANIZATION

What we call things seems so trivial that we see no reason to waste time discussing language or asking much less answering questions like, what do we mean when we use the word ˜process ? After all, everyone with whom I work has the same meaning and understanding of common words and phrases as I do, don t they?

But it s not trivial at all; in fact, it s big very, very big! Not establishing common definitions and a common understanding of the difference between the words policy, process, and procedure can cost your organization tens of thousands of dollars. Not establishing common definitions and an understanding of the word organization as it is used in CMMI-based process improvement can cost millions of dollars. For example, let s say you and your SEPG work in a midsized IT shop in General Motors Corporation that is responsible for developing and maintaining a supply chain data warehouse. A vice president asks you to put together a project plan for CMMI-based process improvement for the organization. You and the other process people build a plan for implementing CMMI-based systems engineering improvements in the supply chain data warehouse and present that plan to the VP. Then he says, Oh no, I meant a process improvement plan for every software and systems engineering unit in GM. Your plan and estimates might need a little revision, eh?

The next two subsections give you some insight into the words and phrases that are the most important in terms of planning and performing process definition work. The most important thing to remember is this:

Your organization does not have to invent definitions for these words. There are plenty of references, such as the CMMI Glossary, that contain definitions which will give you a workable starting point. However, generic or textbook definitions will not be sufficient for your organization and its specific CMMI implementation and process improvement work. In the end, what really matters is that communication within your organization and with stakeholders is not misunderstood; that is the ultimate success criteria.

Defining Process Assets

Process definition is the phrase normally used to describe the activities involved in designing and developing policies, processes or procedures, and related process work products such as forms, templates, checklists, etc. In some shops , process definition can also include process change management and process deployment. And that s about all the consensus you ll find in this area. Figure 5.2 illustrates most of the terms related to process definition that people fail to define, which leads to waste and rework downstream.

Figure 5.2: Process Asset Terms Which Often Do Not Get Defined

Within the process improvement or CMM and CMMI industry, we use words such as policy, process, procedure, guide, handbook, template, checklist, and form frequently, but we often use these words without a consensus understanding of their meaning. You know what you re talking about when you use these terms. If you assume everyone else has the same definition, you d be wrong. Test this out: Go out into your organization and ask three people (separately) the following questions:

What is a policy? How is it used and by whom?
What is a process? How is it used, by whom, and when?
What is a procedure? How is it used, by whom, and when?
What is the difference between these three types of documents?

If you get the exact same answers, write to me. It seems that in the area of process definition, some definition is very much needed. Take a look at Figure 5.3. It introduces some rationale for defining three of the major terms used in process definition and improvement.

Figure 5.3: Rationale for Defining Policy, Process, and Procedure

In addition to policy, process, and procedure, you will also need to define and distinguish between template and form. You may also have to define guideline, handbook, criteria, and desk instruction.

One process asset term that sometimes makes people get really testy is plan. I have frequently come across documents which people referred to as a plan. The so-called plans described how something was going to be performed, but it did not describe tasks , assumptions, dependencies, constraints, risks, effort and cost estimates, or schedule. My own experience and cognitive filters caused me to have a hard time accepting such documents as plans, but their owners were quite adamant that they were plans. Hence the problem when you don t have consensus definitions on such terms.

Defining the Language of Your Organization

In addition to defining terms that represent different process assets, the people involved in process definition work and the stakeholders thereof also need to define other words which are probably spoken and assumed, but undefined in the organization. Several terms are more critical to define than others. The following subsections identify these critical terms, why they re so important, and the questions people need to ask to arrive at consensus definitions.

Defining Organization

This word is by far the most important word to define before any realistic planning for CMMI-based process improvement can be accomplished. Every aspect and parameter of a CMMI process improvement project ” the scope, cost, schedule, quality, appraisal ” everything depends on the definition of this one word. In planning and executing the CMMI process improvement project, everyone will need to know which organizational units will be involved, which people or roles will be affected, which programs and projects will be affected, which systems and products will be affected, and so forth. The definition of this word defines the boundaries of the CMMI process improvement effort. No one in the organization can afford to assume its meaning. Most of all, realize that for CMMI process improvement and an eventual appraisal, the organization may not be the same as the organization chart.

Defining System and System Engineering

Maybe your organization moved from SW-CMM to CMMI because the leadership realized the not-so-widely- acknowledged fact that there are really very few pure software organizations left in the world. Maybe, there never actually was a software industry because you don t have to think too hard to realize that software does not nor has it ever done anything by itself. Software has always been a part of larger systems ” from wrist watches to space shuttles ” that perform tasks; they do things. The more likely reason your organization is moving or has moved to CMMI is because everybody else is doing so. That s okay, but if your process improvement effort previously focused on software, the organization now needs to define what the word system means in the context of their business and process improvement work.

As with other words your organization needs to define, there are plenty of published references that can give you good definitions for a system, but the only definition that counts is the one that works for your organization. By reading this book, you already have had your concept of system expanded to include process systems. Your place of work is a system of systems. There are sociological (people) systems, there are technological systems, and there are process systems. All of these subsystems work together to make the organization a viable , functioning system.

However, for the purposes of CMMI-based process improvement, if you re using the systems engineering discipline (CMMI-SE/SW), your organization will need to define what system means in terms of improving system engineering processes. This task is anything but easy because, inevitably, the definitions people start talking about will challenge and threaten other people s long-held beliefs of the definition of a system.

Defining Project

Watch out! This is another word that will get people riled up when you start asking what it means. I had a person yell at me, I know a project when I see one and that s the only damn definition we need! That attitude is perfectly workable so long as no one has to ever work with anyone else. The problem comes when two or more people have to work together on achieving a common task or goal ” like what we do every single day in the business world.

The reason it is so critical to define the word project up front is because most of the CMMI practices in the Project Management and Engineering Process Area categories, and many of the practices in the Support Process Areas, are based on an organizational definition for project. Your organization doesn t have to use the word project; it can call the same grouping of work by a different name . Many of Natural SPI s clients in the defense contracting world refer to programs, which turns out to be their equivalent of what most of us call a project.

Earlier in Chapter 3, the text provided a starting-point definition for project which is worth repeating. Generically, a project can be defined as a collection of tasks or activities that:

Have a start date and an end date
Will deliver something that can be defined, measured, or tested
Will be allocated defined resources
Will deliver something to a customer or customers who are identified

That s easy enough, but eventually the process people will run into some difference of opinion with relevant stakeholders on the definition of a project. People will wonder how software or system maintenance fits into the definition of project. Let s say you have an organization that gets an annual budget to fix or repair system defects reported to it by users and customers. The organization resolves hundreds of defects a year and releases dozens of patches or software system releases which contain the solutions to the defects. You could tell these people that each individual reported defect constitutes a requirement and that a single solution to a single defect constitutes a project, but you ll probably be inciting a riot by doing so. The people working maintenance or systems sustaining will be very vocal in pointing out the insanity of applying full project management discipline and practices to a single defect resolution and they would be correct.

The good news is that your organization gets to define project, even if that definition differs from the industry s glossaries. If you have a maintenance or sustaining budget with which the shop will deliver some number of defect solutions to a defined customer, doesn t that constitute a set of defined tasks or activities with a start and end date, allocated resources, defined deliverables, and defined customers? Is that not a project?

That won t be the end of the dialog on this subject; it is not easy. Most likely the next series of conversations will be to answer the question, what do we mean by ˜development ? because people make the reasonable assumption that the CMMI-SE/SW best fits software or systems development. This discussion lasted months in one of my client organizations. The question is very easy to answer if an organization is truly building a completely new system or product from scratch, but the answer gets elusive for questions such as:

How much of an existing system can change before it is considered development?
If fixing defects significantly changes the system, is that development?
Is migrating a software system to a new platform considered development?
Is rewriting a system in a new language development?

There are no easy answers to these and other questions. There is, however, only one right answer: the answer that best suits the needs of the people in your organization who will need to work with the answer in the future.

Defining Stakeholder and Relevant Stakeholder

One of the significant benefits of CMMI over predecessor maturity models is that it codifies useful guidelines for involving stakeholders and relevant stakeholders in processes and project decisions and work (GP 2.7). The downside, as usual, is that you and your organization get to do the hard work of figuring out what is meant by stakeholder and who are the stakeholders in different decisions and actions.

The importance of defining the stakeholders or relevant stakeholders for decisions and activities cannot be overstated. Here is just a short list of real situations that resulted in waste, rework, lost time, momentum, or emotional capital which were caused by not having defined these terms:

Processes and process assets thought to be complete had to be reworked because a stakeholder was not included in the review and approval.
Completed project deliverables were not accepted by a customer because he wasn t involved in defining the requirements or other project decisions.
A group of people ignored the new processes and work products because they didn t have a say in their design and development.
A project s scope, effort, cost, and schedule were woefully underestimated because a relevant stakeholder was excluded from the project initiation decisions.

I m quite certain you have many similar war stories of your own on this topic. Again, the CMMI Glossary and other references can provide you with a generic definition for stakeholder, which the process focus people need to take and modify to make it real and workable for your organization.

One lesson learned by organizations with which I ve worked is that they needed to distinguish between the terms stakeholder and relevant stakeholder. For stakeholder, they accepted the CMMI Glossary s definition verbatim. However, they also don t use this term very often and only use it in a generic context when it is spoken or written. In most cases, particularly in the processes and implementation work products, the organization has made the effort to define (by name, by function, or by role) the specific relevant stakeholders for a specific decision or action. For example, a decision to accept and baseline project requirements will have a group of relevant stakeholders identified for that particular decision. Within the same project, different relevant stakeholders may be defined for receiving project status reports . Natural SPI has provided some very convenient tools for documenting relevant stakeholders such as roles, responsibilities, and required skills matrix and a review “act “change “initiate (RACI) matrix. The mechanics of documenting relevant stakeholders is easy; building consensus on those decisions is the hard work.

The last important point to be made about defining stakeholders and relevant stakeholders is that stakeholders should never be defined and planned without those people agreeing to their involvement as a stakeholder. Some people may not want or think they should have participation in a certain decision or action and, if so, others should try to encourage and persuade the needed involvement.

Documenting the Organization s Language

Once the organization has defined its language and has obtained general acceptance of those definitions, this body of knowledge needs to be documented and disseminated to everyone using the language. This document will essentially be a translation table that provides the translation between outsider language, such as standard industry terminology, and the insider language. Table 5.1 shows an example of a partial language translation table.

Table 5.1: Sample Organization Translation Table
Outsider Term or Phrase	Our Organization s Term or Phrase	Our Definition
Project	Task	A task is a unit of work or a logical grouping of units of work requiring a total estimated effort greater than 120 hours or an estimated duration greater than 3 weeks. A task must also have defined or definable requirements.
System	Products	Products are deliverable physical items or services produced for the customer.
Senior Management	Program Managers	For the purposes of systems development and delivery and process improvement, our program managers constitute senior management. This includes grades E10 through E13.
Development	Engineering	The term engineering in our organization is used to describe all work and activities related to the development, repair, and maintenance of hardware, software, firmware, and products composed of any combination of hardware, software, or firmware.
Quality Assurance	Quality Control	In our organization, quality control (QC) is the same function as that described for PPQA in CMMI.
Configuration Management	Change Management	Change management is the term we use to describe all forms of establishing and controlling configurations of products and product components . Change management also includes the management of document revisions or versions.

Critical Factor 4: Design First, Then Build

As briefly addressed in Chapter 3 ” Managing the Process Improvement Project, process systems are sometimes built without an architecture or design. Not surprisingly, such process systems are often later rebuilt because the builders, usually SEPG, skipped design decisions which would have yielded a system closer to correct the first time.

In our work, we have found there are at least four (probably more) significant components or subsystems of a process system s design. These design components need to be thought through, discussed, negotiated, and documented before people go off and write processes or procedures. The four main process system components are:

Content: Which elements of information does each process asset type or class contain?
Format: What do the various process assets look like?
Quality: What testable criteria constitute usable or good enough?
Environment: Who will use which process assets and how will they be used?

These design components and considerations are addressed in some detail in the following sections.

Process Asset Content

Let s go back to our discussion about defining what we mean when we use words such as process, procedure, policy, handbook, form, etc. In the section on Critical Factor 3 in this chapter, Figure 5.3 provides you with some rationale for distinguishing between three common process assets ” policy, process, and procedure ” and how each of these three assets are related. However, when it comes down to creating such assets, the developers of the process system are going to need more detailed guidance than that.

You could repeat the two most common mistakes made by organizations in designing process asset content:

Skip the discussions altogether, build the process assets, and then rebuild them when everyone realizes they should have a structured design.
Put a bunch of expensive people in a room and let them argue about it for days on end.

Or you can skip both expensive lessons, build something similar to the matrix shown in Table 5.2, and give people a straw-man content standard to jump-start this design component.

Table 5.2: Example of Defining Process Asset Content

Table 5.2 shows an example of just one way to design the content for various types of process assets. Each column (following the first column) identifies a type or class of process asset such as process, form, template, policy. Each row identifies a content element, which often represents a section or subsection of information in a document. Where a column (process asset) and a row (process element) intersect, you find information that provides the content standard. Of course, providing this type of matrix alone is not sufficient. Each of the process elements (in the first column) must be defined so that people won t have to guess at their meaning as they create the process assets.

If the people designing the process system build something like Table 5.2 first, then people won t waste their time trying to figure out which types of information goes in each of the types of process assets, nor will the organization lose time and money rebuilding process assets which all come out inconsistent because there was no content design.

Format and Style

Designing the content of the organization s process assets is the most critical aspect of designing the process system, but designing the look and feel or presentation of those assets is also important. Essentially, you want customers and users of the process system to be able to look at one component (i.e., one process asset) and intuitively recognize it as belonging to the larger process system. Accomplishing this goal requires that the process definition plan allocate some resources to designing process asset format.

There are several techniques for expeditiously designing and implementing process asset format which can save the organization time and money. Some combination of these techniques can be tailored to suit your organization s process definition needs:

Assuming most of the process assets will initially be in the form of physical documents, recruit a publications designer to work with the rest of the process definition teams to create a consistent look and feel for the assets. Chances are pretty good that there is someone in your organization with this skill and experience, but you won t know unless you ask.
Assuming most or many of the process assets will eventually be accessible electronically (i.e., through a Web interface), recruit someone from within your organization who has experience with designing online documentation systems. Have this person work with both the people doing process definition and the physical document designer (in the preceding point) to design the process system.
For every type of process asset, design and build a template or a model of that process asset before anyone starts developing instantiations of the asset. For example, design and build a process template to give to process definition teams to use for building their respective processes. If MS Word is the tool being used to document the process assets, make sure the templates contain predefined styles for elements such as section headings, body text, figure and table titles, notes and cautions , and headers and footers. Predefined styles will save many, many hours of work for people who are very knowledgeable in the processes, but who are not experts in the use of document production or publication tools.
Have each process definition team build only one instantiation of a process asset first: a prototype, if you will. Schedule and conduct some form of verification such as peer reviews for the purpose of verifying each process definition team s first output conforms to the approved design standards. This way, you catch the significant deviations and defects in the process assets before those defects are repeated and perpetuated in all the subsequent assets that will be built.

Process Asset Quality

Another area that usually becomes problematic to people doing process definition work is quality. The reason it becomes a problem is because the relevant stakeholders fail to define quality for the process assets they intend to build. It is ironic how quickly system engineering people can readily quote you the quality standards and thresholds for their system products in terms of defects, defect density, or defect severity. Yet, put them on a SEPG and ask them to define quality standards for process documentation, and they re suddenly and mysteriously mute.

What we ve witnessed happen time and time again in organizations is that a bunch of people will build a bunch of process assets. If they re thinking, they will peer review or inspect those process assets before piloting them in the organization (never ask your customer to test for you unless you offer them incentives for doing so). This is where it goes south. In the first round of peer reviews, they ll find and remove from the process assets about 80 percent of the defects (deviations from standards and design). For some, this won t be good enough. So then, they ll conduct several more rounds of peer reviews or inspections, spending three to five times the amount of effort and money spent on the first review, to find and remove the remaining 20 percent of the defects. People will spend a dollar to find and correct a major process content defect, such as a workflow sequencing problem, and then spend five more dollars to find three typographical errors in a 25-page procedure.

Why do people do this? Well, some of it is the nature of people. There are those among us who continually strive for perfection even when perfection is not defined and therefore, by definition, not achievable. There are others among us who simply cannot leave a document untouched; they must make some change to it no matter how trivial because then they will feel they ve contributed . Yet other people who review a process asset are not really qualified to make a substantive or contextual change, so they make unsubstantial changes because they don t know what else to do. Another reason is that we sometimes recruit highly technical people for our SEPGs and process definition teams. Engineers and software developers come from a world in which one singular mistyped character in one line of a software program can cause the entire system to fail. Such people have difficulty changing their frame of reference to one in which it s almost impossible for a singular typographical error in a process document to cause the process to fail.

However, experience and observations tell us that the number one reason people spend too much money on their quest for quality in process assets is because they forgot or didn t think to define quality up front, before the process assets were built. In other words, they didn t define good enough ” good enough to pilot, good enough to implement, good enough to train, and so forth.

Yet defining quality for process assets is not so difficult. It can be predefined in either qualitative or quantitative terms or in both. A quantitative definition for quality in a process system is similar to the quality parameters a project and stakeholders establish for other types of systems. Classes and severity of process defects can be defined (at least by example if not in abstraction). Then numbers of defects or defect density percentages can be established for passing verification or validation or for releasing the process system products into the field for piloting and use.

Quality for the process system can also be qualitatively predefined in terms of risk. The question, is it good enough? can be answered by the answer to the question, what problems will the unresolved defects cause if we release the process asset ˜as is ? People involved in process definition and design can even roughly estimate the cost of releasing process assets containing nonsevere defects and determine an acceptable cost, below which it doesn t make financial sense to perpetually pursue low-risk defects. Or, the decision makers in this phase can simply use some broadbrush questions to determine the risk of defects in the process assets such as:

Are the defects so severe that they will cause work stoppage? Will the defects cause the process to be performed incorrectly? Will the defects, although individually minor, when viewed in the aggregate result in an overall unfavorable impression of the CMMI process improvement project in the community?

The people designing the risk thresholds can decide that if the answers to all of the above questions are no, then the process assets will be released to pilot or to implementation and the defects will be removed later as time permits .

When implementing improvements in the organization, it s important that the people responsible for those improvements always seek an appropriate balance between making their products good and making their products available to the user community. If the process improvement project team or the process focus people hold onto the improved process assets too long trying to make them perfect, their customers ” the users of the processes ” won t wait. The users will keep doing their work the way they always have, and they won t be very forgiving that the process improvement project seemingly doesn t have to hold to a schedule while they do. On the other hand, if the process improvement project prematurely releases unusable junk into the user community, project improvement will probably never regain the trust and faith of the users. So, it is critical that people involved in planning and designing the process system establish the criteria for good enough early in the process improvement life cycle.

Process Usage and Customer Environment

The fourth critical design component of the process system concerns defining the environment in which the process system will be used and designing how people will use the system s components and products. The key questions which need to be answered to inform these design considerations are:

How will people use the process assets? Will the process assets be used in physical (paper) form or will they be used electronically?
How will people want to move from one process asset to another when the assets are linked?
How much detail is needed for different classes or types of users?
How will people navigate through the process system so that they can quickly get to the particular asset or task they need to perform now?

The process improvement project team and the process focus people, as smart as they may be, probably shouldn t try to answer these design questions in a vacuum . Pull together some small focus groups of potential users of the process system and get their answers to these questions. If possible, show them some existing or demonstration process systems and get the users comments on what they like or don t like.

The one aspect of this area of process design that I have found to be overlooked and underestimated most often is the consideration of how much detail is needed for different classes or types of users. People involved in process definition don t ignore this concern, but they do struggle with it. In the end, thinking they have to decide between too much process detail and too little, they almost inevitably settle on providing too much. The resolution to this dilemma does not have to be too much or too little. A process cannot be all things to all people, but it can be many things to many different levels of users.

Let s look at a project planning process as an example. In any random population of a software or system engineering organization, there will be almost infinite different levels of knowledge and experience in project planning tools and techniques, and there will certainly be many different needs for the project planning process and its resulting work products. To illustrate how a process can be designed to satisfy multiple levels of experience and knowledge and different levels of need, we ll define the superset of potential users and stakeholders of the project planning process into five subsets :

Novice project managers who have very little knowledge of or experience in project planning processes, techniques, or tools.
Intermediate project managers who have pretty good knowledge of and experience with how the organization does project planning.
Expert project managers who have extensive knowledge of and many years experience in project planning processes, tools, and techniques (i.e., a PMI-certified PMP).
Project team members such as analysts, developers, engineers, and testers who contribute to project planning at the direction of the project manager, but who do not directly use the project planning process.
Stakeholders such as program managers, senior managers, and customers who are usually recipients of the outcomes and outputs of the project planning process being performed.

Table 5.3 lists each of the classes of project planning users, describes their respective needs or levels of interaction with the process, and then provides some process design concepts for providing a process solution for each class of user.

Table 5.3: How to Design Process Assets for Different Classes of Users
User Classes for Project Planning Process Assets	Information Needs and Process Interaction Level	Process Asset Design Concepts
Novice project manager	Needs lots of procedural how to detail and self-instructing templates, checklists, and forms	Planning process; what needs to be performed Detailed how to planning procedure Self-instructing project plan template Self-instructing templates, forms, and worksheets for estimating, risk analysis, and resource planning
Intermediate project manager	Needs mostly process what to do, does not need procedural detail for project planning	Planning process; what needs to be performed Self-instructing project plan template Self-instructing templates, forms, and worksheets for estimating, risk analysis, and resource planning
Expert project manager	Needs quick, easy tools for creating and delivering project planning work products; does not need process-level or procedural detail	Checklist of major project planning tasks and deliverables Self-instructing project plan template Self-instructing templates, forms, and worksheets for estimating, risk analysis, and resource planning
Project team members	Need awareness-level knowledge of which aspects of project planning to which they contribute; need self-instructing templates or worksheets for project estimating	Checklist identifying project planning tasks in which they are involved Self-instructing templates, forms, and worksheets for project planning tasks to which they contribute
Project planning stakeholders	Need awareness-level information on work products and other planning outputs they should expect to receive; also need summary of their participation as a stakeholder in project planning	Checklist of project planning outputs they should expect to receive and instructions on what to do with those items Project roles and responsibility matrix or stakeholder participation matrix

The point being made here is that one level of detail does not fit all; it never has and it never will. The people in charge of designing and developing process assets don t have to choose between alienating a particular class of user to appease another.