Defining Policies | Interpreting the CMMI (R): A Process Improvement Approach, Second Edition

This chapter is the "meat and potatoes" chapter. It provides guidelines for creating process improvement documentation and presents templates. You do not have to use these templates; they are simply provided to help you get started. Find something that fits your organization's culture and use it.

Defining Processes

A process consists of:

Roles and responsibilities of the people assigned to do the work
Appropriate tools and equipment to support individuals in doing their jobs
Procedures and methods defining how to do the tasks and the relationships between the tasks

A process is not just a high-level flowchart. A life-cycle standard (e.g., DOD-MIL-STD-498 or 2167a) is not a process. A tool is not a process. A process consists of sequential steps of what needs to be done, plus the procedures detailing how to do the what s.

The CMMI definition of a process is found in Chapter 3 of the staged representation. It states that "A process as used in the CMMI product suite consists of 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." Although this definition does focus on implementing the practices of the CMMI, we find the definition unsatisfactory. We prefer to look at the definition in the CMMI for process description. A process description is "a documented expression of a set of activities performed to achieve a given purpose that provides an operational definition of the major components of a process. The documentation specifies, in a complete, precise, and verifiable manner, the requirements, design, behavior, or other characteristics of a process. It also may include procedures for determining whether these provisions have been satisfied. Process descriptions may be found at the activity, project, or organizational level." This definition seems to allude to the fact that processes must be detailed enough to be followed, and that procedures can lead to that effect.

More about procedures later. Let us now concentrate on how to define a process. With a defined process, you can see where to improve quality, productivity, cost, and schedule. A defined process is the prerequisite for process improvement. Without defining processes in an orderly fashion, sustained improvement is impossible . Defined processes improve communication and understanding of both the currently existing "As Is" processes used in the organization, and the "To Be" processes that constitute the desired end result. Defined processes aid in planning and execution of the plans, provide the ability to capture Lessons Learned, and help facilitate the analysis and improvement of organizationwide and enterprisewide processes.

When is a process defined? When it is documented, training is provided in the process, and it is practiced on a day-to-day basis. To create process documentation, the writers of the process at hand must understand the current process (As Is) and must have developed a shared vision of the desired process (To Be).

Where to start? Translate your products and services into outcomes . That is, if you build B1 Bombers, your outcome would be the fully constructed bomber. However, you would also have to break down this outcome into its constituent parts: the body, the software, the hardware, etc. Then break those parts down into their parts , etc. You will need a documented process (actually documented process es ) for the work to be performed to develop each outcome. Now take one outcome and divide it by all of the activities it takes to produce that outcome. Be sure to include organizational units and support areas. This involves figuring out the tasks associated with the work to be performed, the inputs and outputs , dependencies , and roles and responsibilities .

Yes, it is a lot of work and, yes, it is difficult work.

Most templates for defining processes include the following entities:

Activity Entry Criteria
Activity Exit Criteria
Activity Input
Activity Output
Activity Performed By
What Activity Is Next

This is called the ETVX format, and was created by IBM and used by the SEI (Software Engineering Institute) as part of its process framework. This generic method of transcribing activities, ETVX, stands for: E ntry Criteria, T asks, V erification, and e X it Criteria. Terms used include:

Work Product/Work Outcome: any product, service, or result
Activity: the action taken to create or achieve the product, service, or result; this can also be the Task part of ETVX.
Agent: the person who accomplishes or performs the action to achieve or create the product, service, or result

Examples of Work Outcomes are the results or products of a process, such as a Project Plan, a project schedule, allocated requirements, management approval, management sign-off, or trained employees . The following paragraphs demonstrate a sequence to be used when defining processes, as well as questions to ask and examples.

Activity Entry Criteria

When can this activity begin?

Entry criteria describe the conditions under which the activity can be started.

Answers

A:	Jot down a verb describing the state of an activity.

Examples: Approved Statement of Work, responsibilities for creating the Project Plan, an approved Test Plan.

Activity Exit Criteria

When is this activity completed?

Describe the conditions under which an activity can be declared complete and may determine the next activity.

Answers

A:	Verb about the state of the product, the person performing the activity, or the activity itself.

Examples: The Project Plan is ready for review, customer commitments are approved and incorporated into the project schedule, control mechanisms are in place for changes to the schedule.

Activity Input Criteria

What interim work products are used by this activity?

Input is a relationship or link between an activity and a work result. Inputs are the results of a prior activity and used by the activity being described.

Answers

A:	The name of the resultant work product.

Examples: Statement of Work, approved allocated requirements.

Activity Output Criteria

What work results or products are produced by this activity?

Output is a relationship or link between an activity and a work result. Outputs are the results produced by the activity being described.

Answers

A:	The name of the resultant work product.

Examples: A piece of code, a test procedure, a design specification, an approved Statement of Work.

Activity Performed By

Who performs this activity?

"Activity performed by" is a relationship or link between an activity and an agent (the person performing the activity). It is the organizational unit, role, or automated agent responsible for performing the activity.

Answers

A:	A list of the organizational units, roles, or automated agents that participate or are affected by the work.

Examples: The Quality Assurance (QA) group , a Project Manager, a Lead Software Engineer.

What Activity Is Next?

What activity is next?

Activity flow is a conditional relationship or link between activities. Activity flow defines the ordering of activities and is generally dependent on exit criteria.

Answers

A:	The result produced.

Examples: Final product OR product leading to the next set of ETVX activities.

Sometimes, Entry criteria and Inputs are combined, and Exit criteria and Outputs are combined. They are not really the same, as Entry and Exit criteria are triggers . Inputs and outputs are products . It is up to you how to do it. Most organizations currently combine the concepts.

Sometimes the previous ETVX information is presented as a flowchart with accompanying verbiage describing what goes on; sometimes it is presented as a list of sequenced steps; and sometimes it is presented as pages and pages of text. Whatever format fits the culture of the organization should be used.

After documenting the processes, the supporting procedures would be written, based on the process steps just documented. The procedures describe in detail how to perform the steps in the process.

Exhibit 1 shows an example of a process for Requirements Management. This template was created by an organization that did not depend on a lot of verbiage in its documentation. The organization wanted just the facts ” short and sweet. Although the information looks short, if there are many steps to a process, this can get quite complicated.

Exhibit 1: Process for Requirements Management

Action	Responsibility
Obtain Work Request from the customer	SM, PM
Review Work Request	PM
Create initial budget/estimates/schedule	PM
Initial planning	PM, project team
High-level requirements	PM, project team, customer
Risk identification and documentation	PM
Requirements Spec Draft	PM, project team
Technical review	PM, project team, QA
Customer review	Customer
Refine requirements	PM, project team, customer
Create Requirements Traceability Matrix (RTM)	PM, project team
Review requirements and RTM	PM, customer, project team, QA
Review/update risks	PM
Update estimates and schedules	PM
Review requirements, schedules, and estimates	PM, project team, QA, customer
Requirements Spec Final	PM, analysts
Approvals and sign-offs	Customer, QA, PM, SM, EPG
Baseline Requirements Spec	PM, CCB, EPG
Assess, track, and incorporate changes	PM, CCB, QA, EPG, customer, project team
Note:
PM = Project Manager
SM = Senior Management
CCB = Configuration Control Board
QA = Quality Assurance
EPG = Engineering Process Group

Exhibit 2 shows another example of the same process by the same organization when it decided to add more text to explain the above process. Included in the text were the supporting procedures. The exhibit is simply the Table of Contents for the process. The complete process was 20 pages long. Although it was called the "Requirements Management Process," it only concentrated on creating the Requirements Specification, the Requirements Traceability Matrix, and changes to the requirements document itself.

Exhibit 2: Requirements Management (RM) Process

TABLE OF CONTENTS
1.0	Introduction
	1.1	Purpose
	1.2	Scope
	1.3	Change Management
	1.4	Roles and Responsibilities
2.0	Process Description
	2.1	Process Overview
	2.2	Process Flow
	2.3	Process Detail
		2.3.1	Develop the Requirements Specification
			2.3.1.1	Description
			2.3.1.2	Input/Entry Criteria
			2.3.1.3	Tasks/Activities
			2.3.1.4	Conduct Reviews
			2.3.1.5	Output/Exit Criteria
		2.3.2	Develop the Requirements Traceability Matrix (RTM)
			2.3.2.1	Description
			2.3.2.2	Input/Entry Criteria
			2.3.2.3	Tasks
			2.3.2.4	Output/Exit Criteria
		2.3.3	Changes to Requirements
		2.3.4	Verification
			2.3.4.1	Senior Management Involvement
			2.3.4.2	Project Manager (PM) Involvement
			2.3.4.3	Quality Assurance (QA) Involvement
			2.3.4.4	Product Reviews
			2.3.4.5	Management Reviews
			2.3.4.6	Customer Reviews
3.0	Resources and Funding
4.0	Measurements
5.0	Training
6.0	Reference Documents
7.0	Change History