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.
No comments:
Post a Comment