PLANNING THE CMMI PROCESS IMPROVEMENT PROJECT

Establishing the Process Improvement Project Team

Traditionally, process focus groups such as SEPGs are the default project team for the CMM or CMMI process improvement project, even when those people haven t yet had the epiphany that their work is a project. However, the classical view of what type of people should comprise the SEPG is exactly what puts the process improvement project at risk. If you think about a systems development and delivery life cycle, you realize that you need different people with different knowledge and skills at different phases of the life cycle. The same is true for developing a delivering process system. It is very unlikely that the same set of people chosen to serve in a process focus function (i.e., the SEPG) will possess all the knowledge and skills the process improvement project will need to succeed.

Table 3.4: Simple Three-Dimensional Project Stakeholder Plan

Establishing the Project Work Breakdown Structure

Defining a WBS for a process improvement project is not that much different from defining a WBS for the development of a software or integrated system. This is one area in which your organization s process experts either need to also possess strong project management skills or they should recruit an experienced project manager to help out.

Where to Start

The goal(s) of this process improvement project. If this project was initiated to correct an acute business problem, you probably want to see results as soon as possible. For example, if the primary goal of the project is to make estimates more realistic and rebuild your customer s faith in them, you might want to consider rapid prototyping. The WBS should reflect quick cycles with immediate improvement in this one area of project planning and project tracking with heavy emphasis on keeping the stakeholders involved.

The culture of the organization. If the organization is accustomed to delivering a product every six months, for example, you might want to structure your CMMI project to deliver a subset of improvements every six months. You don t need the busy work of changing the components of the culture that are working. This situation might lend itself to an iterative spiral development and delivery approach.

Time and money constraints. Being an imperfect world, money and resources tend to be available for a limited time. If you can determine these constraints, you can make sure you deliver something with the available resources. Remember it is better to deliver a slimmed down system that works, than the ultimate unfinished system that dies on the vine from lack of resources and never gets delivered. You are probably looking at a waterfall life cycle with a reduced scope in this example.

Make sure the life cycle you choose is in the list of approved life cycles for the organization and document why you chose this particular lifecycle in the project plan.

The Process Improvement WBS Content

The phases in a process improvement project are very much like the phases in a software or systems development project. This section describes the minimum phases and tasks or activities therein for almost any CMMI-based process improvement project. Although the information herein is presented in a structure that appears to be a traditional waterfall life-cycle model, realize that there is plenty of opportunity for parallel and iterative work to be performed.

There are at least eight distinct phases to a process improvement project, although your organization can decide to combine the work in two or more of these phases:

Phase 1: Establish the process improvement project and characterize current state

Phase 2: Define and baseline the process improvement requirements Phase 3: Plan the process improvement project

Phase 4: Design and architecture of the process system and assets Phase 5: Build the process system and assets

Phase 6: Test (pilot) the process system or its components and fix defects

Phase 7: Communicate, train, and implement the process system

Phase 8: Measure and advertise success in improvements

The following subsections briefly describe the critical tasks and activities for each of these phases. Your project s WBS will differ based on the project s goals, scope and applicability, and constraints levied on the project, such as a target date for achieving a maturity level.

Phase 1: Establish the Process Improvement Project and Characterize the Current State

Establishing the process improvement project is primarily a matter of defining the project s initial purpose (goal), scope, applicability, and high-level success criteria. You will also want to at least get a start on defining the project s stakeholders. Before exiting Phase 1, you should negotiate and acquire at least enough resources and funding to execute project planning in Phase 2. The primary physical output of this phase is a document that defines the information described herein and an allocation of resources to execute project planning.

In Phase 2, the organization will define the requirements for process improvement. However, it will be very difficult to define reasonable process system requirements without some knowledge of the organization s current state in terms of process capability or CMMI maturity. Thus, a task to characterize or assess the organization s current processes and their implementation is frequently a large part of Phase 1. Figure 3.9 shows Phase 1 tasks and activities.

Figure 3.9: Process Improvement Project Phase 1 Tasks

This sample WBS and those shown in the subsequent subsections intentionally do not include scheduling parameters such as start and finish dates and resources. Remember, establishing the WBS is just the first step in establishing the schedule, which cannot be performed until you have more information developed and acquired in the next phase, project planning.

Also, realize and accept the fact that much of what you initially define in this phase can and will change as you gather more information in subsequent phases. When the things defined in Phase 1 do change, it is the process improvement project s responsibility to communicate the changes with the stakeholders.

Phase 2: Define and Baseline the Process Improvement Requirements

As with other projects, the process system to be delivered by the process improvement or CMMI project should be driven by requirements. The process system s requirements are derived from the project s goals, which define the desired state and the current state, which comprises the current process strengths and weaknesses and current business problems that might be resolved through process improvement. If the only requirement anyone can come up with for the process system is that it be used in an appraisal to achieve a CMMI maturity level, you probably don t have a strong enough business case for the project to proceed forward.

The primary output of this phase is a document that defines the baseline requirements for the process improvement project and the process system it will deliver. Again, the stakeholders (as best you can identify them at this phase) should have to review and approve the baseline requirements. As with other projects, the requirements are likely to change in subsequent project phases, so it s a good idea to establish requirements traceability. For more information on defining and managing the process improvement project s requirements, read Getting from Measures to Process Improvement Actions: Managing Process Improvement Requirements in this chapter.

Figure 3.10 shows the minimum tasks the WBS should contain for Phase 2.

Figure 3.10: Process Improvement Project Phase 2 Tasks

Phase 3: Plan the Process Improvement Project

Two great sources of guidance for planning a process improvement project are the Project Planning process area of CMMI2 and PMBOK. ^[16] Planning the development of a process system includes most of the tasks and activities required to plan a systems project, including:

• Establishing the project goals, scope, and stakeholders (Phase 1 in this section)

• Establishing baseline requirements and requirements traceability (Phase 2 in this section)

• Establishing the project team (read Establishing the Process Improvement Project Team in this chapter)

• Defining the development or implementation approach and processes

• Defining project assumptions

• Establishing the WBS (this section)

• Estimating cost, effort, and schedule for WBS tasks Defining task dependencies, constraints, and critical path or critical chain

• Defining and planning for the management of project risks (look at PP and RSKM)

• Establishing plans for project monitoring, control, reporting, and communication

• Establishing plans for stakeholder involvement and monitoring stakeholder commitments

• Establishing the project and process system configuration management subplan (look at CM and OPD)

• Establishing the project and process system quality assurance subplan (look at PPQA)

• Establishing the plans for testing (piloting, verification, and validation) of the implementation (look at VER and VAL) Establishing the process improvement project s measurement subplan (look at MA and OPP)

The primary output of the planning phase is a process improvement project plan which either contains or references all related supporting plans or subplans. Again, the process improvement project team will want to involve relevant stakeholders in the creation of this plan and its review and approval.

Figure 3.11 shows the high-level tasks involved in the process improvement project planning phase.

Figure 3.11: Process Improvement Project Phase 3 Tasks

Phase 4: Design and Architecture of the Process System and Assets

The process system, like a software “hardware system, should be built in accordance with an architecture or high-level design and standards. You also need to define the process by which the process system and its components will be designed and built.

The first task in process design is defining the terminology that you want people in the organization to use when talking about different process assets. For example, when someone uses the word procedure, you want everyone in the organization to have a common understanding of what that term means. For more information on establishing process definitions, read Define the Process Language for Your Organization in Chapter 5 ” Five Critical Factors in Successful Process Definition.

The next major task in this phase is defining the process by which the process assets will be developed. Will processes and assets be built from scratch or will legacy assets be incrementally improved? What will be the criteria for making such a decision? How and when will process assets be reviewed and what are the processes for accomplishing review and approval? What is the process, method, or mechanism by which the various components of the process system will be integrated or linked together? Will process definition tools be used and, if so, how will they be used and what are the criteria for this decision? When answered , these and other similar questions will yield the process for process definition.

Other critical tasks in this phase include defining the standards ” for both format and content ” for the various process assets and designing the system by which the process system and its components will be stored and accessed by users. A large factor in designing a process system is first understanding the use cases: how will people use the processes and process assets. Figure 3.12 illustrates the minimum critical high-level tasks and activities for this phase.

Figure 3.12: Process Improvement Project Phase 4 Tasks

The critical outputs from completing this phase are:

Process asset dictionary Process asset standards Process definition process description Process asset repository design and architecture

(Also read Design First, then Build in Chapter 5 ” Five Critical Factors in Successful Process Definition.)

Phase 5: Build the Process System and Assets

The fifth phase is to build the processes and assets in accordance with the design and architecture defined in the previous phase and in accordance with the project and process system requirements defined in Phase 2. The work in this phase relies heavily on the use of expertise in workflow diagramming and illustration, information mapping, and process/procedural writing. This is not a phase for people new to writing and technical documentation work. Figure 3.13 identifies the critical few tasks in this phase.

Figure 3.13: Process Improvement Project Phase 5 Tasks

Phase 6: Test (Pilot) the Process System or Its Components and Fix Defects

In the vernacular of software or systems engineering, we say we are testing the products ” the process system in this case ” that we have developed. In the language of CMMI, we are verifying the system or validating it.

There are a number of ways to verify that the process system or its components satisfy the requirements and other acceptance criteria such as standards. Peer reviews, walk-throughs , and inspection methods all work, so long as they are performed against objective criteria so that they don t simply become opinion polls .

A powerful lesson I ve learned in this phase is that, if you re not careful, you and the process focus or process development people can get caught in an almost perpetual loop of review and revision of the process assets. In the first and second reviews, people will catch about 80 percent of the defects. In the third review, they ll catch another 10 to 15 percent of the remaining defects. Now they re addicted to the quest for perfection and overengineering. People will spend 4 to 8 times the effort and money to remove the last 5 percent of defects as they did getting the first 95 percent. This is a miserable return on effort and investment. How do you prevent this? Up front in the planning, establish the exit criteria for verifying the process assets. In other words, get people to agree on a quantitative definition of good enough. (Read Process Asset Quality in Chapter 5 ” Five Critical Factors in Successful Process Definition.)

In terms of validation (i.e., the system works as intended in the intended environment), the best way to accomplish this is just put the thing into play. In accordance with the plan for verification and validation, introduce the process system or some components into software/systems projects and let people test drive the stuff. This is where the process team gets tremendous payback on the usability and usefulness of the process assets they have built.

The major word of caution here is: Don t ask people to pilot or validate process assets that are out of phase with the project s current phase or stage. Don t ask project personnel to pilot your project plan template when it is already in system integration and test with the deliverables. There are many other factors that deter mine which software “systems project pilots which pieces of the process system, but the point is to have a plan. JPEG devised a plan for projects to pilot various components of JEEP that was brilliant in both its comprehension and simplicity. This plan ” a matrix ” is shown in Figure 3.14. In one single matrix, it provides both the piloting plan and the current status of process piloting efforts.

Figure 3.14: JT3 Pilot Plan and Status Matrix

Phase 7: Communicate, Train, and Implement the Process System

This phase in the process improvement project would be called release or transition in a software or systems delivery project. The goal of this phase is to transfer the new technology ” the processes and process assets ” into the community of users and customers. Don t forget that the project needs skill sets that are different from the prior phases to accomplish this phase, primarily people with knowledge and experience in education, training, and knowledge transference.

Phase 8: Measure and Advertise Success in Improvements

In SEI s IDEAL model, this phase falls into the Leveraging or Learning phase. There are two primary tasks or activities in this phase:

1. Determine the qualitative and quantitative measures which indicate the business results from the process improvement project. Announce, promote, advertise, and shout at the top of your lungs the business successes resulting from CMMI-based process improvement.

2. Plan and conduct an appraisal to determine if the organization achieved a targeted maturity level or process capability from the process improvement project.

Estimating the Process Improvement Work

Whoa there! Have you read the previous sections on defining goals, requirements, and a WBS for your process improvement project? If not, what are you going to estimate? Before you can estimate the work involved in the project, don t you need to first know the tasks and activities by reading the previous section?

Let s say ” hypothetically, of course ” that your boss has decided that the process improvement project s only goal is to achieve a maturity level and that your boss wants to know how long it will take. How do you respond? Tell him or her to give you one-half hour and you ll be back with a rough guess and then go to do the following

Visit SEI s Web site at http://www.sei.cmu.edu and conduct a keyword search on maturity profile. There you ll find the most current version of SEI s maturity profile, ^[26] which is compiled and published at least twice annually. This profile will inform you how long it takes various kinds of organizations to achieve the maturity levels. Figure out the type of industry and organizational size in which your organization would be categorized in the profile, then look at the short, long, average, and median lengths of time it took others to achieve the maturity level your organization is pursuing. If the number of months make you nervous, add some padding like all project managers do, and give the number to your manager. There, you ve just made a schedule estimate using historical data.

Again, planning your process improvement project is an excellent way to walk the talk by demonstrating to project managers and others that you re willing to do what you re asking of them. Estimating is just one element of planning; you should also plan and document the project s commitments, assumptions, risks, project team roles and responsibilities, communications, configuration or change management, and process quality assurance.

CMMI Process Improvement Effort and Cost Estimate Considerations

One of the consequences of process improvement efforts not being managed as projects is the fact that there is a lack of historical effort and cost data from such efforts. There is, however, some cost-modeling and scant actual data that you can use to develop a rough order of magnitude (ROM) for your process improvement project.

There are dozens of variables that will affect the cost of your SPI project, but the three variables having the most weight are:

1. What is the starting point? How much work needs to be done to implement processes consistent with the organization s targeted maturity level? Since this is the biggest factor affecting total effort and cost, do not make assumptions about your starting point. Read Determine the Starting Point for CMMI Process Improvement in this chapter.

2. How many people are in the organization? Answering this question assumes you and other stakeholders have defined the term organization. If not, read the section titled Establish a Common Language in this chapter.

3. What will be your approach? The approach you choose will dramatically affect the speed and cost of achieving your process improvement goals and the resulting quality of the deliverables. (Read Chapter 4 ” Process Improvement Strategies that Work.)

Process Improvement Project Assumptions

As with any project, the success (or failure) of the process improvement project depends on certain assumptions being true and remaining true throughout the life of the project. However, the key to successful project planning is not simply acknowledging this, but getting those assumptions out of peoples heads, writing them down, and getting consensus on them from the project stakeholders. As in most human endeavors, our egos lead us to assume that everyone else s assumptions are the same as ours. If we proceed to act on this assumption without validating its truth, we put into motion most of the risks our project will incur.

Developing and documenting project assumptions is a difficult endeavor. Even when people can bring their assumptions to the conscious level and articulate them, they often hesitate to do so because they perceive it will reveal too much about the way they view work and their personal agendas . One of the easier techniques for getting stakeholders to reveal to you their assumptions is by starting first. Say to others, Here are my assumptions about this project; what do you think? Throw your own assumptions out on the table as thought starters. Be prepared for people to attack the validity of your assumptions. That s okay, because what you re really after is getting people to open up about their own assumptions. Listen closely when someone tries to disclaim your assumptions because in doing so they may be revealing their own.

After collecting assumptions and getting stakeholder consensus, document them in your project plan. In doing so, make it clear that the assumptions must be true and remain true for the project to succeed. In project planning, the logical opposite of an assumption ” that is, an assumption that becomes untrue ” is a risk or constraint. In fact, a simple rewording of an assumption can be used in your risk management plan.

Here are some typical assumptions you can modify and reuse in your own process improvement planning:

Senior management will approve and support the project goals and scope identified in the process improvement project plan in a timely manner ( assuming the words approve and support have been defined).

Project team members have or will acquire the skills and knowledge needed to perform their tasks.

Planned and committed resources will remain available to the team. The requirements for or scope of this process improvement project will not change significantly once the project is funded and initiated.

Process Improvement Project Risks

The most important thing to remember about project risks is that they are there whether or not you acknowledge them or do anything about them. Someone smart once said, the greatest risk is not taking one, which alludes to the opportunities we often find in risks. My corollary to this view is that the greatest risk you can take in a project is the delusion that there are none.

Unlike effort and cost data, there is plenty of publicly available information you can use to plan and manage risks to the organization s CMMI process improvement project. Remember, your organization is not the first to implement CMMI-based process improvements! Consider the following sources.

One of the better sources on the risks to process improvement is from Karl Weigers. ^[38] Weigers provides ways for you to recognize and mitigate these problems that commonly plague process improvement efforts, including:

• Lack of management commitment Unrealistic management expectations Time-stingy project leaders Inadequate training

• Expecting defined procedures to make people interchangeable Failing to scale formal processes to project size

• Process improvement becomes a game

• Process assessments are ineffective

From PMI s PMBOK, ^[16] we have these ten major reasons for project failure:

1. Inadequate specifications

2. Changing requirements

3. Lack of management change control

4. Inexperienced personnel

5. Unrealistic estimates

6. Subcontractor failure

7. Poor project management

8. Lack of user involvement

9. Expectations not properly set

10. Poor architectural design

With the exception of three of these items ” inadequate specifications, subcontractor failure, and poor architectural design ” these top causes of failure in software “systems projects can easily also be the top causes of failure in process improvement projects. PMI also lists Classic Process-Related Mistakes made in software “systems projects. Following each listed classic mistake below is a brief description of how the mistake is manifested in process improvement projects. The important lesson here is recognizing that the same risks and problems which have historically plagued software and systems projects are most likely the same problems and risks which will plague a process improvement project. Once that is recognized, your organization can employ the same effective risk management techniques used in successful software “systems projects.

Overly Optimistic Schedules

Management sets timeframes for achieving maturity levels without the schedule being supported by historical data or estimates from people actually doing the work.

Insufficient Risk Management

People planning the organization s CMM/CMMI process improvements ignore this section of this book (or any such section in any such book) and just go merrily along practicing another mistake on PMI s list called wishful thinking. For many, hope will always be the strategy.

Abandonment of Planning Under Pressure

The deadline for achieving the target maturity level is rapidly approaching, so instead of managing the CMMI project in accordance with the plans (assuming there were plans), frenzy sets in. What last week were thought-out, estimated process definition and implementation tasks have now become ad hoc rehearsals for appraisal interviews and retrofitting project documentation with sections intended to satisfy CMMI practices.

Code Like Hell Programming

In process improvement, this equates to write like hell process definition. The SEPG and others responsible for process rapidly roll out processes by defining all kinds of CMMI-based procedures, putting them in some repository, commanding everyone in the organization to go read them, and then claiming the processes are implemented just in time for the appraisal.

^[16] The Project Management Body of Knowledge (PMBOK) is an online repository of project management information. This repository is maintained by the Project Management Institute (PMI). For more information, go to www.pmbok.com.

^[26] The Maturity Profile is a report periodically published by the Software Engineering Institute (SEI). This document provides information and statistics from the results of CMM and CMMI appraisals reported to SEI. For more information, go to www.sei.cmu.edu.

^[38] Wiegers, K., Software Process Improvement: Ten Traps to Avoid. Go to www.processimpact.com.