Chapter 16: Defining Processes, Procedures, Policies, and Charters


Tracking the Documentation

Monitoring the process improvement effort is critical to stay focused and ensure that progress is being made. To track the activities of the PATs, we provide a sample compliance matrix in Exhibit 3. This matrix is based on tracking the activities performed during the Design phase. Piles of documentation will be written. This exhibit may help you track this effort. However, do not be fooled into thinking that once you have your procedures written, you are finished. Remember: you still have to train the pilot participants , pilot the procedures, re-write them based on the pilot results, train the organization in the procedures, roll out the procedures for implementation, and track adherence and changes. There is still a lot of work to be done. The Action Plans can track PAT efforts, and the PI Plan and Implementation/Operations Plan can be used to track EPG and organizational-level tasks .

Exhibit 3: Sample CMMI Compliance Matrix
start example

No.

Practice or Activity

Associated Procedure/Document

Assigned To

Date Due

Date Reviewed

Status

 

Process Area: RM

 

Process Area: GG2: Institutionalize a Managed Process

1

GP2.1 (CO1): Establish an organizational policy

Policy

   

03/02/02

Approved

2

GP2.2 (AB1): Plan the process

  1. Plan

  2. Process description

  3. Schedule

  4. Estimates

   

03/02/02

Complete

3

GP2.3 (AB2): Provide resources

See Plan

     

Complete

4

GP2.4 (AB3): Assign responsibility

See Plan

     

Complete

5

GP2.5 (AB4): Train people

See Plan and training materials

     

In progress

6

GP2.6 (DI1): Manage configurations

TBD

     

In progress

7

GP2.7 (DI2): Identify and involve relevant stakeholders

See Implementation Plan

     

Complete

8

GP2.8 (DI3): Monitor and control the process

TBD

     

Deferred

9

GP2.9 (VE1): Objectively evaluate adherence

Procedure PI5 Procedure PI7

     

Complete

10

GP2.10 (VE2): Review status with higher-level management

Procedure PI6

     

Complete

 

Process Area: SG1: Manage Requirements

11

SP1.1: Obtain an understanding of requirements

Procedure RM1

     

EPG review

12

SP1.2: Obtain commitment to requirements

Procedure RM2

     

EPG review

13

SP1.3: Manage requirements changes

Procedure RM3, RM4 Procedure CM4

     

Pending

14

SP1.4: Maintain bi-directional traceability of requirements

Procedure RM4

     

Rejected

15

SP1.5: Identify inconsistencies between project work and requirements

Procedure RM5

     

Pending

end example
 

In Exhibit 3, only the practices for a specific process area (RM, Requirements Management) are listed. It should be noted that, to fully understand and implement the practice, the subpractice must usually be analyzed and incorporated into the procedure. This template can also be used for tracking infrastructure documentation such as plans, charters , and standards preparation, as well as any other activities performed throughout the PI effort.

Another example is shown in Exhibit 4 using the CMM for Software as the model. This example also depicts Requirements Management, as well as some infrastructure documentation and Project Planning. Note that all of the practices are not mentioned: this is only an example. We feel that most practices should be covered in some way by documentation ” either a single document per practice or, more likely, several documents that describe how to do several practices.

Exhibit 4: Sample CMM Compliance Matrix
start example

No.

Process Area

CMM Reference

Document

Assigned To

Date Due/Reviewed

Status

1

Infrastructure

 

SPI Plan

     

2

Infrastructure

 

Implementation Plan

     

3

Infrastructure

 

Organization's Standard Software Process (OSSP)

     

4

Infrastructure

 

SEPG Charter

     

5

Infrastructure

 

SEPG Presentation Template

     

6

Infrastructure

 

Procedure Template

     

7

Infrastructure

 

Training Packet Guidelines for Pilots

     

8

Requirements Management

 

RM Charter

     

9

Requirements Management

 

RM Action Plan

     

10

Requirements Management

 

RM WBS

     

11

Requirements Management

 

RM Schedule

     

12

Requirements Management

CO1, AB1, AB3, AB4

Policy for managing system requirements allocated to software: includes establishing responsibility, providing adequate resources, and required RM training

   

13

Requirements Management

AB2, AC1

Procedure for Requirements Specification and Review

     

14

Requirements Management

AB2, AC2

Procedure for completing Requirements Traceability Matrix (RTM): includes use as basis for SDP and work products.

     

15

Requirements Management

AC3

Procedure for SRS and RTM changes

     

16

Requirements Management

ME1

Procedure for RM metrics

     

17

Requirements Management

VE1, VE2

Procedure for Project and Senior Management reviews

     

18

Software Project Planning

 

SPP Charter

     

19

Software Project Planning

 

SPP Action Plan

     

20

Software Project Planning

 

SPP WBS

     

21

Software Project Planning

 

SPP Schedule

     

22

Software Project Planning

 

SPP Process Overview Document

     

23

Software Project Planning

Com-1

Software PM designated in Policy for SDP and commitments

   

24

Software Project Planning

Com-2

Policy for planning a software project

     

25

Software Project Planning

Abil-1

Statement of Work for each software project

     

26

Software Project Planning

Act-6

Procedure for developing a Software Development Plan

     

27

Software Project Planning

Act-7

Software Development Plan for each software project ( Note: may be contained in several "documents" of different names )

     

28

Software Project Planning

Act-9

Procedure for estimating size of software work products

     

29

Software Project Planning

Act-10

Procedure for estimating effort and cost for the software project.

     

30

Software Project Planning

Act-11

Procedure for estimating critical computer resources

     

31

Software Project Planning

Act-12

Procedure for deriving software project schedule

     

32

Software Project Planning

Act-13

Risk identification and assessment document for each software project

     

33

Software Project Planning

Act-14

Plans for software facilities and tools for each software project

   

34

Software Project Planning

Act-15

Estimates and basis for estimates data are recorded for each software project

     

35

Software Project Planning

ME 1

Measurements are made to determine status of software planning activities (rationale for measurements and how to collect and analyze them)

     

36

Software Project Planning

VE1, VE2

The activities of SW project planning are reviewed with Senior Management and Project Management ” procedures for both

     

37

Software Project Planning

VE3

SQA audit of PP Activities ” procedures for quality reviews ” may be found in SQA KPA

     
end example
 

It is also necessary to track how the procedures are being used in the projects, and to what extent they are being used. For this task, we suggest talking to people to find out. If people will not talk, and do not voice their displeasure, it does not mean they are happy campers. It means they have concerns but feel that voicing the concerns will be of no use. They feel they have not been part of the process and their opinions are worthless. So, no news is not good news. If people do not feel part of the process, they will not buy into it. And ultimately, they might sabotage the effort. So try to find out what is happening.

The opposite also holds true. People will complain ad nauseum about the procedures because:

  • They have to read them. No one likes to read anymore: we wait for the movie or the video game to become available.

  • They have to follow them.

  • They have to change the way they work.

  • Someone is monitoring how they do their jobs.

We will not go into changing the culture ” there are already several books on the market about that. Suffice it to say, people do not like to change. So reward them for their efforts and praise them.

In addition to simply talking (and listening) to people, we suggest a report card. Simply create a checklist that can be e-mailed to each project manager and have him (or her) fill it out and return it to the EPG. It should track whether each project is using the procedures, which ones are used or not used, and why or why not.

You may have to take a stand to stop the complaints. But before you do, you had better check to see whether these folks are justified in their complaints. Are these procedures really a good fit for them, or are they forced to use them just because the procedures took a long time to write and you need to get the Maturity Level to bid on contracts? Is the appraisal team on its way to conduct a SCAMPI for a rating? Is that why you have not changed the procedures? Or is it because it took blood to write the procedures, so there is no way they will ever be changed? Was the organization forced to cut the time it took to produce the procedures? Was the Pilot phase skipped ? Were people pulled from the PATs to do "real work"?

This brings us to management commitment. We usually have to set up a special one- to three- hour executive briefing for management because they are not willing to take the time to attend the full-blown class. True management commitment is shown by providing adequate resources and funding. That means enough of the right people, enough time, and enough money to do the job. While management might send out memos promoting the greater glory of the organization and why the organization should adhere to process improvement, real management commitment does not really happen ” especially at first. Management (and we mean very senior management ” the executive levels that decide process improvement must be done to garner future business) does not understand what process improvement really means and what it takes. We have taught over 150 Introduction classes; and in all that time, we have had only one executive in the class. The remaining students were usually process improvement people or developers. Management will say they are committed. It is up to you to make them prove it by following the concepts expressed in this book.




Interpreting the CMMI(c) A Process Improvement Approach
Interpreting the CMMI (R): A Process Improvement Approach, Second Edition
ISBN: 142006052X
EAN: 2147483647
Year: 2005
Pages: 205

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net