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 .
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 |
| 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 |
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.
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 |
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.