Procedures Specify HOW to Do Something, Not WHAT to Do

A common problem I notice when reviewing an organization's processes and procedures is that the organization doesn't understand how to document a procedure. Rather than simply telling someone HOW to perform the process, the document states a set of requirements that must be met by the people performing the procedure, which then allows multiple ways of performing the procedure by any person attempting to use the document. There seems to be a general misunderstanding that commands or directives tell someone HOW to perform a process, when in actuality all that is being communicated is WHAT to do.

The CMMI Glossary defines process as activities that can be recognized as implementations of practices in a CMMI model. These activities can be mapped to one or more practices in CMMI process areas to allow a model to be useful for process improvement and process appraisal.

The Glossary also defines a process element as the fundamental unit of a process. A process can be defined in terms of sub-processes and/or process elements. A sub-process can be further decomposed into sub-processes and/or process elements; a process element cannot. Each process element covers a closely related set of activities (e.g. estimating element, peer review element). Process elements can be portrayed using templates to be completed, abstractions to be refined, or descriptions to be modified or used. A process element can be an activity or task.

Page 53 of the CMMI book provides the following description of Maturity Level 2:

At Maturity Level 2, the projects of the organization have ensured that processes are planned and executed in accordance with policy; the projects employ skilled people who have adequate resources to produce controlled outputs; involve relevant stakeholders; are monitored, controlled, and reviewed; and are evaluated for adherence to their process descriptions. The process discipline reflected by Maturity Level 2 helps to ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.

At Maturity Level 2, the status of work products and the delivery of services are visible to management at defined points (e.g., at major milestones and at the completion of major tasks). Commitments are established among relevant stakeholders and are revised as needed. Work products are appropriately controlled. The work products and services satisfy their specified process descriptions, standards, and procedures.

Page 54 of the CMMI book provides the following description of Maturity Level 3:

At Maturity Level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods. The organization’s set of standard processes, which is the basis for Maturity Level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization’s set of standard processes according to tailoring guidelines.

A critical distinction between Maturity Levels 2 and 3 is the scope of standards, process descriptions, and procedures. At Maturity Level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (e.g., on a particular project). At Maturity Level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit and therefore are more consistent, except for differences allowed by the tailoring guidelines.

Another critical distinction is that at Maturity Level 3, processes are typically described more rigorously than at Maturity Level 2. A defined process clearly states the purpose, inputs, entry criteria, activities, roles, measures, verification steps, outputs, and exit criteria. At Maturity Level 3, processes are managed more proactively using an understanding of the interrelationships of the process activities and detailed measures of the process, its work products, and its services.

Page 295 in Organizational Process Definition provides some Tips that relate to processes and process assets:

Organizational process assets support a fundamental change in behavior. Projects no longer create their processes from scratch but instead use the best practices of the organization, thus improving quality and saving time and money.

Standard processes define the key activities performed in an organization. Some examples of standard processes include requirements elicitation, design, and testing; planning, estimating, monitoring, and control; and product delivery and support.

The objective is to decompose and define the process so that it can be performed consistently across projects but will allow enough flexibility to meet the unique requirements of each project.

And from the book Interpreting the CMMI by Margaret Kulpa and Kent Johnson, second edition on page 198 there is a section on Defining Procedures that supports the CMMI material quoted above. In the context of the CMMI, procedures are equivalent to sub-processes and process elements.

Procedures are step-by-step instructions on how to perform a task. To be repeatable, the steps need to be broken down to a level that anyone who needs to perform the task, with a general understanding of the work to be done, can perform the work adequately by following the instructions. Procedures are a subset of processes. The process is what to do; the procedures are how to do the steps of the process.

Procedures are step-by-step instructions of how your processes are performed. They include:

• Sequence of activities
• Deliverables
• Controls
• Inspections and reviews
• Guidelines and standards used

In addition, in the CMMI book on pages 99 and 100, Bill Curtis, an author of the Software CMM, talks about policies, PPQA, and process improvement:

Polices that merely regurgitate goals from CMMI process areas represent a lost opportunity for executives to communicate their expectations for behavior in their organizations. Once policies are established, executives need visibility into compliance. Assurance groups have influence only to the extent that executives attend to their reports and address noncompliance. However, the greatest value of assurance groups, and this is subtle in Process and Product Quality Assurance (PPQA), is when they serve as mentors to project managers and technical staff on practices that support compliance. Consequently, assurance groups need to be staffed with competent developers and managers so that they are credible in transferring knowledge of best practices across the organization.

Process improvement must be conducted as a project. Executives must assign responsibility for managing the project, provide funding and resources, expect periodic status reports, and measure results. The person assigned to lead the improvement project must be a good role model for other project managers. Executives should ask frequent questions about project plans and the assumptions underlying them. The guidebooks, defined processes, measures, checklists, and other artifacts produced through process improvements are organizational assets. They should be treated as products, albeit for internal use, and be produced with the same discipline used in producing any other product.

Consequences and Summary
By not specifying how to perform the process steps it gives carte blanche to whoever is performing the process to do whatever they want to in order to satisfy the step. In addition, by not specifying how to perform the process steps, it makes it impossible to perform a PPQA process audit. The person performing the objective evaluation of the process (process audit) needs to know how the process is supposed to be performed in order to create a checklist so he or she can objectively evaluate whether or not the process is being followed the way it is supposed to be followed.

Essentially, by not supplying the information of how to perform a process, you do not have a repeatable process, which is at the core of Maturity Level 2. A repeatable process means that every time someone uses the same documented process description, he or she will perform it the same way. The only way that you can ensure this outcome is to document how the process is performed. At Maturity Level 2 it is permissible to have multiple documented processes for the same process. At Maturity Level 3 the organization is supposed to examine the multiple documented processes and look for exemplar practices to elevate to the organization level to become the standard process for the organization.

The challenge facing the process writers is to document the process such that it is neither too detailed nor too general to follow. If it is too detailed, then you have painted yourself into a corner and the process may be too detailed to correctly follow. If too general, then it basically allows you to do anything you want. Either way, there is no benefit to the organization.

This issue also points out a fundamental difference between ISO 9000 and the CMMI. At its core, ISO 9000 is a set of standards for a quality system. It requires the existence of processes good, bad, or indifferent. In contrast, the CMMI is a set of guidelines for process integration and product improvement. The whole focus of the CMMI is process improvement. And it becomes very difficult to do process improvement if you don’t spell out how a process is performed.

To illustrate the issue allow me to cite an example of incorrectly worded procedure step.

• The Project Manager derives estimates for the size of the software work products, or changes to the size of the software work products.

There is more than one way to estimate size if you don’t specify how to perform this step. By not specifying how, you cripple your ability to analyze the process and identify process improvements.

If I were to ask the Project Manager how he or she peforms this step, I might find out that they do this by using the project requirements and historical data (notes and reports from past projects and lessons learned) from similar past projects to determine size factors (SLOCs, number of files, database size, number of screens) and applying appropriate scaling factors using engineering judgment. The Project Manager then reviews the size estimates with the Team Leads for reasonableness. This is an excellent explanation and practice.

By providing this level of detail, now there is enough information for PPQA to perform a process audit and also enough information to perform process improvement and determine if an estimation model can be built to improve the accuracy of project estimates.

OSSP Question

What does "organization’s set of standard processes" mean?

As I have indicated in previous blog entries, the first place you should always check for definition questions is the CMMI Glossary. You will find a comprehensive definition of the OSSP there. If after reading the definition you still have questions, then read the Organization Process Definition (OPD) Process Area which will put the OSSP into context. And if you still have unanswererd questions, please post them to this blog.

Definition of SOW

I would like to know what is the content of the Statement of Work and how does this document meet requirements of the CMMI?

As a best practice with definition questions, the first place to look is the CMMI Glossary. In this case there is a definition of Statement of Work (SOW) in the Glossary. “A description of contracted work required to complete a project.” In other words, the SOW contains the requirements for what you have to delivery to the customer. And there are varying levels of detail from SOW to SOW depending on the size, criticality, and nature of the work. For large government contracts, the SOW may also contain the Work Breakdown Structure (WBS) for the program/project as well. At a minimum, the SOW will contain the customer’s requirements that the organization will further develop. So the SOW supports RD and may also support PP.

Definition of Work Product Terms

What is the meaning of the following work products: WBS task dictionary, documented requests for commitments, and documented commitments?

There are no unique definitions for these terms in the context of the CMMI. Otherwise these terms would be defined in the CMMI Glossary. These are standard Project Management terms.

The WBS Task Dictionary is the list of tasks, deliverables, and predecessor/successor relationships between the tasks. There is sufficient information provided so anyone using the WBS Task Dictionary will have enough information to create a WBS for a project.

Documented Requests for Commitments means exactly what the words say. A request for a commitment. It can be as simple as emailing a document to someone for their commitment and approval.

Documented Commitments again means exactly what the words say. Basically the commitments made by the various parties and stakeholders are written down somewhere.

Objective Evidence vs. Typical Work Products

Would you please explain the relationship between Objective Evidence and Typical Work Products?

This is an interesting question, and one that can be easily answered by reading the CMMI Glossary, a little used part of the model. Most answers to questions can be found by first reading the Glossary definitions.

From the CMMI Glossary, the definition of Objective Evidence: As used in CMMI appraisal materials, documents or interview results used as indicators of the implementation or institutionalization of model practices. Sources of objective evidence can include instruments (questionnaires), presentations, documents, and interviews.

Typical Work Products are one of the topics contained in the Informative Component. All model components are important because the Informative Component helps you understand the Expected and Required Components. It is best to take these model components as a whole. If you understand all three types of information, then you can understand how everything fits together to form a framework that can benefit your organization.

From the CMMI Glossary, the definition of Typical Work Products: An informative model component that provides sample outputs from a specific practice. These examples are called typical work products because there are often other work products that are just as effective but are not listed.

So, in a nutshell, a Typical Work Product is an example of a tangible output that might be produced by performing a Specific Practice. The Objective Evidence are the actual work products and other items produced by performing the organization’s documented processes. So the Objective Evidence provided in an appraisal might or might not match the items listed as Typical Work Products.

What is the Difference Between PPB & PCB?

Please explain the difference between Process Performance Baseline (PPB) and Process Capability Baseline (PCB) as OPP PA talks only about establishment of process performance baselines.

This is a good, but very easy question to answer. First, you should ALWAYS check the CMMI Glossary first before asking a question. Many times you will find the answer to your question in the Glossary. Here are the Glossary definitions for these two terms. I think that these definitions clearly point out the differences.

Process Capability – The range of expected results that can be achieved by following a process.
Process Performance Baseline – A documented characterization of the actual results achieved by following a process, which is used as a benchmark for comparing actual process performance against expected process performance.

TS SP 2.2 Establish a Technical Data Package

During our implementation of the Technical Solution (TS) Process Area (PA) we had some discussions on how to implement the Technical Data Package.

Is this Specific Practice (SP) expecting just the design documents with the generic artifacts captured as part of CM plan or SMP deliverables?
OR
Is this SP requiring explicit capture of all the applicable technical data like architecture, data sheets, other technical articles, etc. as a section of the design document?

The quick answer is yes. First go to the CMMI Glossary and look up “technical data package.” There you will find a “shopping list” of the typical contents of the technical data package. The contents of the package are a function of where you are in the development lifecycle. Early in the lifecycle there won’t be a lot of content, but at the end of the lifecycle there should be a lot of information. The organization should decide on what the standard contents of the technical data package should be and then each project will tailor this list for its particular needs.

The purpose of the technical data package is to provide the developer with a comprehensive description of the product or product component as it is developed throughout the lifecycle. You have to decide what the necessary documents and information are to provide a comprehensive description.

CMMI Glossary - An Overlooked Resource

The CMMI Glossary defines the basic terms used in the CMMI, especially those terms that have a specific mean in the context of the CMMI. Many of the definitions are for multiple-word terms. If the Glossary does not contain a definition, then the common usage or other dictionary definition is applicable.

The SEI's Introduction to CMMI class spends some time stressing the importance of the Glossary and the need to consult it whenever a question arises.

Despite all this, the CMMI Glossary, next to the Generic Goals and Generic Practices section, is probably the most overlooked area of the model. People tend to remain focussed on reading the Process Areas and rather than consult the Glossary for specific definitions and also tend to apply their own definitions and interpretations, which can lead to improper implementations. Plus it doesn't help that the Glossary is at the back of the book.

For example, the "CMMI lawyers" can start to argue that documented policies and procedures are not required because there are no explicit words in the CMMI stating documented policies or procedures. What the "lawyers" are missing is the special CMMI meaning of the phrase "establish and maintain." This phrase is emphasized in the Intro to CMMI class and is defined in the Glossary as formulate, document, and use. So in GP 2.1 where it states "establish and maintain an organizational policy for ..." that means to think about the wording of the policy, talk about it and achieve consensus, write it down or document it, and then use it.

So, the lesson here is whenever you have a question about the CMMI, the first place you should go is the Glossary and see if the term or phrase in question has been defined in the context of the CMMI. There is a lot of good information contained in the Glossary. Granted, it is not complete, so you may expect to find a definition here that is missing. If you disagree with a Glossary definition and/or wish to include a definition, you can always write a Change Request to the Glossary and submit it to the SEI for consideration.

What is the Difference Between OPF SP 3.1 and SP 3.2?

There are some fine shades of distinction here between these two Specific Practices that can cause some confusion. Both Specific Practices concern deployment. OPF SP 3.1 covers the deployment of process assets and OPF SP 3.2 covers the deployment of the standard processes. The CMMI defines process asset as “Anything that the organization considers useful in attaining the goals of a process area.” And organizational process assets as “Artifacts that relate to describing, implementing, and improving processes.” In other words, process assets are those things that help or enable you to follow the process. Process assets include the policies, measurements, process descriptions, templates, checklists, etc. It is always best to consult the CMMI Glossary for definitions when you have interpretation questions about the CMMI. There is a lot of helpful information contained in those pages.

So, OPF SP 3.1 is concerned with deploying the process assets (new or changed) across the organization. For example, deploying a new or modified template keeping in mind that the associated process may not have changed, just the template. OPF 3.2 is concerned with deploying new or changed processes across the organization. For example, deploying a new or modified Peer Review process, keeping in mind that the associated process assets may not have changed. The model is splitting these two practices apart for clarity because it is possible, as my examples indicate, to perform them independently. Now, from a practical standpoint, most organizations do these two practices together. When beginning process improvement, organizations usually modify BOTH the process and the associated process assets at the same time. As the organization matures, they may be able to modify a process asset without a corresponding process change and vice versa.

And if you remember back to when you took the Intro to CMMI class, your instructor should have emphasized that there is no implied flow from one Specific Practice to the next. They can occur in any combination or order, just as long as the Specific Goals are satisfied. However, in the Engineering PAs there are certain practices that most everyone performs in a certain order.