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.

CMMI-SVC and Emergence of Open Organizations

Emergence of Open Organization- when will it happen? LinkedIn + Google+Sourceforge+Newscale + Visa
I foresee Newscale/ Pinky/SEI coming up with a master service catalogue that could be integrated with Google where any Group member can have his own service catalog in his profile. The Group Service catalog could well be an Organization's service catalog. Probably any individual would say he has his office is in Yahoo!, Google etc and may add that he works for a particular social enterprise/many enterprises. I also feel that some governmental procedures or a global standard will evolve for the governance of Open companies. My question is does the CMMI-SVC address this?

What you are asking about is a virtual office environment and the tools to enable this environment. There are two practices in the CMMI that address work environments: OPD SP 1.6 Establish and maintain work environment standards and IPM SP 1.3 Establish and maintain the project’s work environment based on the organization’s work environment standards. Since both OPD and IPM are Core Process Areas (PAs), they are common to all CMMI constellations CMMI-DEV, CMMI-ACQ, and CMMI-SVC. So your virtual office concept can work with any of the three constellations.

Interpreting OPD SP 1.6

While discussing Organizational Process Definition (OPD) Specific Practice (SP) 1.6, we arrived at the following two interpretations for a software development organization:

OPD SP 1.6 "Establish and Maintain Work Environment Standards"

Interpretation 1: Work Environment Standard refers to the environment (Hardware, Software) required by a project for its successful completion. So, if a project mentions its resource requirements (including hardware, software, human resources, trainings, skill set, etc) then it will meet the intent of this practice.

Interpretation 2: We need to explicitly document the "Work Environment Standards of the Organization" for this practice, which includes:

• Standard Hardware & Software on a machine
• Standard Hardware & Software configurations on a machine
• Standard LAN Speed required
• Stanadard Internet Speed required
• Standard Temprature
• Standard Dress Code
• Emergency Numbers
• Fire alarms
• Smoke detectors

Which interpretation is correct?

Reading your question gives me the uneasy feeling that you may have not read the informative material for OPD SP 1.6. The model clearly states that “work environment standards allow the organization and projects to benefit from common tools, training, and maintenance, as well as cost savings from volume purchases.” And then there is a list of 6 examples of work environment standards, which I will repeat here:

• Procedures for operation, safety, and security of the work environment
• Standard workstation hardware and software
• Standard application software and tailoring guidelines for it
• Standard production and calibration equipment
• Process for requesting and approving tailoring or waivers

Given this informative material, it is very clear in my mind what constitutes a work environment standard. I would say that your second interpretation is more correct than your first interpretation, though the correct answer is probably a combination of the two. However, I would question why you would include standard temperature, dress code, emergency numbers, fire alarms, and smoke detectors in your work environment standards for software development and maintenance, unless these are safety standards. Do these items affect how you develop software? The work environment standards I typically encounter at a client site include standards for a workstation (including desk, table, chair, computer), a standard software load (including MS Office), standards for the conference rooms (including wired or wireless connections, laptop or desktop, LCD projector, screen, whiteboard, markers, etc.), standards for the development environment, standards for the test environment, and standards for the production environment.

Another Work Environment Question

Both Organizational Process Definition (OPD) and Integrated Project Management (IPM) reference the work environment. What is the difference between OPD SP 1.6 and IPM SP 1.3?

OPD Specific Practice (SP) 1.6 is "Establish and maintain work environment standards" and IPM SP 1.3 is "Establish and maintain the project's work environment based on the organization's work environment standards." OPD is an organizational level Process Area (PA) and IPM is a project level PA.

The expectation for OPD SP 1.6 is that the organization defines work environment standards that allow both the organization and projects to benefit from a common set of tools, training, and maintenance. The intent of OPD SP 1.6 is NOT to define the standard work environment, but to define standards for the work environment. Standards typically include work environment operations, safety, and security procedures, standard hardware and software configurations, standard software application loads, and procedures for requesting waivers or tailoring. In addition, projects may have additional requirements for their work environments.

In contrast, the intent of IPM SP 1.3 is to use the work environment standards defined by OPD SP 1.6 to define the appropriate work environment for the project. The project's work environment might include the development environment, the testing environment, the integration environment, the verification environment, and the validation environment. These environments could be one environment or separate environments and/or facilities.

Work Environment Evidence Question

There are two Specific Practices in the CMMI that address the work environment:

• OPD SP 1.6 Establish and maintain work environment standards
• IPM SP 1.3 Establish and maintain the project’s work environment based on the organization’s work environment standards

There are other Specific Practices in the model that address specific environments:

• VER SP 1.2 Establish and maintain the environment needed to support verification
• VAL SP 1.2 Establish and maintain the environment needed to support validation
• PI SP 1.2 Establish and maintain the environment needed to support the integration of the product components

In addition, the model references a number of other project work environments: maintenance, operational, production, and engineering.

Since IPM SP 1.3 contains the phrase “establish and maintain”, the organization needs to provide for a SCAMPI A appraisal evidence of “formulate”, “document”, and “use” of the project’s work environment. What is appropriate evidence to provide for IPM SP 1.3?

The “document” evidence could be the document(s) containing the description of each of the project’s work environments and its relationship to the organization’s work environment standards. The “formulate” evidence might be the inspection/review report(s) of these document(s). And the “use” evidence could be an example of a work product produced using the documented work environment. For example, evidence of use of the development environment might be a product build report demonstrating use of the environment for developing the product.

Since the Verification, Validation, and Integration Environments are covered by other Process Areas, it would be appropriate to provide for IPM SP 1.3 evidence of use of other components of the documented work environment to demonstrate the work environment covers more than testing.

Interpretation of GP 3.2 and Associated Evidence

GP3.2 states "Collect work products, measures, measurement results, and improvement information derived from planning and performing the process to support the future use and improvement of the organization¢s processes and process assets."

Do we need to collect measures and have measurement results for all the Process Areas or would just conducting lessons learned at the end of a milestone/phase/project be enough to satisfy the practice? Lessons learned in our case are mostly qualitative comments only and very few quantitative. We have all the planning and tracking related details available in EPM and other associated templates.

Please keep in mind that GP 3.2 is a generic practice and it applies to EVERY Process Area (PA) from Maturity Level 3 and up. It also happens to be one of those compound practices that require multiple things. In this case four different items to collect and feedback into OPF, OPD, and IPM. The advice that I give my clients when preparing the PIIDs for an appraisal is that the process work products you provide for GP 2.6 should be the same work products you are submitting for GP 3.2; the process measures that you use to monitor and control the process in GP 2.8 and the results reviewed with higher management in GP 2.10 should be the measures and measurement results you are submitting in GP 3.2. Therefore, the only additional piece of information required by GP 3.2 is improvement information from planning and performing the process. Sometimes this takes the form of lessons learned, which is an exercise focused on gathering data on what worked, what didn’t work, and what should be changed for future use. There are other ways of collecting this information without conducting a formal lessons learned meeting. But the bottom line is that you are EXPECTED to collect all of these data items for every PA in scope of your implementation and appraisal.

Another point is that these four items are independent of each other and therefore would be collected at different times. Conducting lessons learned meetings at the end of a milestone, phase, or project is a good practice and they don’t have to be quantitative in nature, unless you are at Maturity Levels 4 or 5. What you are trying to do is surface candidate process improvement suggestions from the people who have just used a process.

What is IPPD All About?

Would you please explain the basic concepts of IPPD, why, when, where and how to use it? Please try to explain using simple terms not using the cmmi terminology, although down the road that terminology can be referred.

Basically Integrated Process and Product Development (IPPD) is a beefed up version of Intergroup Coordination from the Software CMM and it is intended for use when you assemble a team or teams of people from different groups to work a specific task. For example, if you were to design and build new car, the design team might consist of a propulsion expert, a transmission expert, an interior design expert, an electrical expert, a manufacturing expert, etc. These experts may come from several different departments and have at least two reporting paths, one to the project team for technical issues, one to their home organization for administrative issues, and possibly others. This integrated team is empowered by management to make technical design decisions and there may only be a team lead and not a manager on the team.

Sometimes an organization may use an integrated team for new design, but then the team remains intact for the sustaining engineering phase, which could last for years. In this situation the integrated aspect of the team becomes blurred. According to Mike Phillips/SEI IPPD can apply to almost any type of team as long as you can demonstrate that you are satisfying OPD SG2 and IPM SG3.

Another example of an integrated team is the SEPG. Typically the SEPG exists outside of the normal organizational management and teaming structure. The SEPG is formed by bringing people from different groups together to address the organization’s process improvement needs and objectives.

So, when do you need to use IPPD? When you need to bring together people from different groups to address a specific task or work an issue. If your organization structure is such that the project manager is responsible for both the technical work and the administrative needs of his or her staff, then IPPD probably does not apply. And if you are not being required to demonstrate the IPPD capability by your customers, I would not be concerned about implementing IPPD, unless you feel it is applicable or absolutely necessary.

Motivate and Facilitate buy-in

What are some different ways and means of making the process implementation look easy to the implementers (like creating high level architecture of all the process interactions, providing templates with dummy data, etc...) to facilitate buy-in?

There are two basic audiences for the process documentation:

1. the process engineers (those who define and document the processes) and
2. the practitioners (those who have to follow the processes)

The process engineers are very interested in the overall process architecture, inputs/outputs, interfaces, etc. The practitioners just want to know what they need to get their specific jobs done. When you read the purpose of OPD, one of the key words is establishing and maintaining a USABLE set of processes and process assets. Therefore, in order for your processes and process assets to be usable by the practitioners, it doesn’t help them to provide all the process architecture, inputs/outputs, interfaces, etc. that the process engineers need and want. The simplest approach that I have seen for the practitioners is to provide a “swim lane” process flow chart. Then it is very easy for the practitioner to see where they fit into the process. Also providing good, as well as bad, examples of how a template or checklist should be filled out is also a good idea.

But keep in mind, that an approach that works in one organization for achieving “buy-in” may not work in another. You really need to work with the organization and jointly determine the best method for the organization. If most of the practitioners, for example, do not relate to visual process flows, then the “swim lane” approach I mentioned above may not work.

Individual benefits are highly variable. You may gain some insight into dealing with different people by reading my presentation on Managing Cultural Change. I have posted it in several locations on the web. You can access it through my web site www.ppqc.net or at SlideShare http://www.slideshare.net/HenrySchneider/managing-change-324890/

Process Documentation

There are two basic audiences for process documentation:

1. Process Engineers (those who define and document the processes) and
2. Practitioners (those who have to follow the processes).

The process engineers are very interested in the overall process architecture, inputs/outputs, interfaces, etc. In contrast, the practitioners simply want to know exactly what they have to do in order to get their jobs done. When you read the purpose of Organizational Process Description (OPD), one of the key messages is establishing and maintaining a USABLE set of processes and process assets. Therefore, in order for your processes and process assets to be usable by the practitioners, it doesn’t help if you provide them all of the process architecture, inputs/outputs, interfaces, etc. that the process engineers need and want. The simplest approach that I have seen for the practitioners is to provide a “swim lane” process flow chart. Then it is very easy for the practitioner to see where they fit into the process. Also providing good, as well as bad, examples of how a template or checklist should be filled out is also a good idea.

But keep in mind, that an approach that works in one organization for achieving “buy-in” may not work in another. You really need to work with the organization and jointly determine the best method for the organization. If most of the practitioners, for example, do not relate to visual process flows, then the “swim lane” approach may not work.

Establishing the Verification Environment

VER SP 1.2 is “Establish and maintain the environment to support verification.” Companion practices are OPD SP 1.6 “Establish and maintain work environment standards.” And IPM SP 1.3 “Establish and maintain the project’s work environment based on the organization’s work environment standards.”

So what this all means is that you have to define at the organization level what the standards are for verification environments, in IPM define the project’s verification environment(s) in the project plan, and in VER define what the various verification environments are. When you consider VER, there are at least two and possibly more verification environments depending on the system you are developing. At a minimum you have a peer review environment and a product testing environment. Both of these environments have requirements, resources, equipment, and tools which you will have to define yourself. In the case of peer reviews and inspections the environment is many times just the conference room with a whiteboard, LAN connection, computer, and a projector, plus other requirements. The testing environment may be a specific room and equipment set aside as a testing lab, etc. So, to implement VER SP 1.2 you have to define the requirements for each verification environment that you have defined for the project, along with the resources, equipment, and tools, and then the acquisition of these items to actually construct and maintain the environment(s), which also include upgrades over time.

And keep in mind the CMMI definition of the phrase “establish and maintain”, which means formulate, document, and use. Therefore you need to design the environment, document the environment, and use the environment for verification.