How to use CMMI to bring your project management process to the next level

Abstract

Are you stuck in a project management process crunch and try to find out how to get out from there? At the same time, are you trying to identify why your software quality stagnates or even degrades?

CMMI^® has started to play a key role in software development organizations worldwide. In order to compete with increasing software quality demands, many organizations claim or aim to move from their current CMM^® level to the next higher one. CMMI is more comprehensive and rigid than CMM, as it covers 24 process areas versus CMM's 18 process areas. In addition, CMMI has 460 practices versus CMM's 316. The number of processes can be very overwhelming and it opens up the question how to best implement them. In order to stage the process improvement effort, CMMI offers five maturity levels that can only be reached one after the other. This paper focuses on how the Engineering organization at LogicVision Inc. improved its project management methods by using CMMI level 2 project management processes as a target. We start by explaining the basic structure of CMMI and describe the goals set for project management in CMMI maturity level 2. LogicVision selects the specific goals for project planning (PP) and project monitoring and control (PMC). Then these goals are transformed into requirements for project management templates.

In order to explain how we meet these CMMI goals, we provide examples of the schedule and project plan template designed for engineering projects. As a result this paper demonstrates how CMMI level 2 goals for project management can be used as a tool to drive change and improve project management processes within an Engineering organization.

Introduction

LogicVision Inc. leverages the power of its embedded-test technology to provide leading-edge solutions to maximize the yield and life of semiconductors throughout the supply chain. In order to aggressively expand their business opportunities, LogicVision decided in late 2003 that they needed to re-position the company to go after this newly formed yield-learning opportunity.

This laid the foundation for the following product development goals:

• Build the right products needed to grow a profitable business
• Build a development organization that can respond quickly to an ill-defined, yet fast-changing marketplace
• Expect that product teams will scale quickly, either through additional hiring or through acquisition
• Increase productivity
• Ensure the development organization is self-sustaining in terms of day-to-day operation

These goals required the following changes in LogicVision's approach to product and project management. LogicVision:

• Moved from a centralized, executive-level product and project management style into a de-centralized style where there existed three levels of management: product, project, and coordination. Each product team had responsibility for the business success of the product family. As a result, they were tasked with managing project requirements, change control etc. Each project team had responsibility to implement the projects meeting all scope, schedule, and quality expectations. There were two coordinators. One to ensure an efficient mapping of projects to releases, and the other to ensure the local project solutions mapped well into the overall LogicVision solution.
• Changed their focus away from being release-centric (i.e.: One major release and one minor release per year, with various project content) into being project-centric (i.e.: organize around the key projects needed for the business, with releases being the delivery vehicle, not the driver)

To implement product and project management in this way, it was critical that LogicVision has a solid, well defined, and self sustaining project management program within LogicVision. After some research, it was clear that CMMI clearly identified all of the steps that we needed to adopt.

CMMI Structure

The Capability Maturity Model Integration (CMMI) provides a framework for the integration of process improvement for multiple process areas. The process areas are systems engineering; software engineering; supplier sourcing and development; and integrated product and process development. Different versions exist depending on how many of these areas are applicable to the organization. CMMI then offers two different improvement models for each version; the continuous model and the staged model:

• Continuous: Organizations that like to improve its processes one area at a time might likely chose the continuous model. The continuous model applies specific process improvement achievements for each process area. These are measured by capability levels from zero to five.
• Staged: Organizations that like to improve their processes across various process areas to reflect a certain maturity are likely to choose the staged model. In the staged model, the overall maturity of the organization is measured by maturity levels from one to five:
  1. Initial
  2. Managed
  3. Defined
  4. Quantitatively Managed
  5. Optimizing

The structure of the staged model is shown in Exhibit 1. Each maturity level builds on the previous level by pre-defining a set of process areas that must be met in order to reach that level. Each process area includes a set of specific and generic goals. Specific goals are unique to the relevant process area (e.g. “Develop a Project Plan” is a specific goal within the Project Planning (PP) process area). Each specific goal applies activities, so-called “specific practices” that help to achieve these specific goals. Generic goals are common between the set of process areas (e.g., “Institutionalize a managed process” is a generic goal). Each Generic goal consists of a set of “generic practices” that help achieve the generic goal.

Exhibit 1: Staged model

The critical distinction between “maturity level 1” and “maturity level 2” is that level 2 organizations maximize their productivity etc. by focusing and perfecting the processes deployed within the organization, versus relying on the competence and heroics of individuals in the organization. When LogicVision evaluated their processes in relation to CMMI, they identified that they were performing well in some areas, but not others. As a result, they didn't consider themselves as being a typical level 1 company. In order to reach a baseline, they decided to set themselves the goal of reaching CMMI level 2 within a 12-month period.

CMMI Level 2 Process Areas

CMMI level 2 consists of the following process areas:

• Requirements Management (REQM)
• Project Planning (PP)
• Project Monitoring and Control (PMC)
• Configuration Management (CM)
• Supplier Agreement Management (SAM)
• Measurement and Analysis (MA)
• Process and Product Quality Assurance (PPQA)

Although all seven process areas add value, LogicVision placed priority on the first three process areas ; REQM, PP, and PMC. The others were either already working well (CM and SAM), or were deemed as having a lower return on investment. With the creation of the product team organization, it was critical that we had well defined roles and responsibilities as well as a clear set of processes and templates around requirements definition and change control. REQM process was fully adopted and executed with great success. The scope of this paper focuses on how LogicVision implemented project management areas PP and PMC within the project team and release coordination organizations.

To help understand the scope of process areas PP and PMC, the specific CMMI practices are shown in Exhibits 2 and 3.

Exhibit 2: Specific Goals and Practices for Project Planning (PP)

Exhibit 3: Specific Goals and Practices for Project Monitoring and Control (PMC)

Implementation of PP and PMC Process Areas

Given that LogicVision had limited project management documentation in place, a focused and streamlined approach was important for the successful implementation of PP and PMC CMMI processes. As a result, the company decided to implement PP and PMC as a series of steps:

1. Gather data on existing project management and tracking practices used within LogicVision.
2. Assess current used practices against PP and PMC, then identify the gaps.
3. Design and/or upgrade our project management processes to meet PP and PMC needs.
4. Design and/or upgrade our project plan, project schedule, and project tracking spreadsheet templates.
5. Select individuals in the organization that we felt would make strong project leads.
6. Define roles and responsibilities, then assign this responsibility to these leads.
7. “Beta test” the new CMMI-compliant processes and templates by having the selected project leads use these processes as part of implementing one new project.
8. Gather feedback and update processes and templates as needed.
9. Create formal project management training that fully articulates PP and PMC processes and templates.
10. Roll out training across the entire development organization (not just engineering).

In the past LogicVision followed an annual release cycle. In order to satisfy increasing customer demands, the Engineering organization decided to move to a project-driven approach and that could also be self-sustaining. Engineering started to divide releases into much smaller subprojects, and then introduced the role of project lead to take on project management responsibilities. The release becomes a roll up of the individual projects managed by the release coordinator.

Besides defining the project lead role, the current project management practices and related processes were evaluated. As a result, the requirements management process was formally documented and adapted to specific goals of the CMMI Requirements area level 2. The change management process was identified and implemented. The goals of the PP and PMC process areas were used as design requirements for the project management templates. The set of project management templates includes a release/project schedule template, a project plan, and a project tracking spreadsheet. The project plan is a living document until the baseline for requirements and timeline has been identified. The project tracking spreadsheet is used for monitoring and controlling the project during execution. It includes sections to track the overall status, action items, change management, decisions and risks. Exhibit 4 and 5 show how goals and practices of PP and PMC were addressed in the project templates.

Exhibit 4: PP specific goals and implementation

New project leads were coached in the process on how to use the project templates to guarantee its successful implementation. Feedback was immediately incorporated in project management process and templates. These early trials of the project templates allowed management to assess the training needs for the project leads. We created a formal training class and rolled it out to the project leads.

Exhibit 5: PMC specific goals and implementation

Implementation Examples

This section demonstrates how the specific practice SP 1.1 (Estimate the Scope of the Project) of PP's specific goal SG 1 (Establish Estimates) has been implemented at LogicVision:

• Exhibit 6 shows the product development lifecycle that we use. As this model has been working well for the company, it was used to build the baseline for the release/project template. Only minor modifications were needed to create consistency to CMMI level 2.
• Exhibit 7 shows the WBS for the project schedule template. The first-level work breakdown shows the main activities for a typical project; Requirements (tasks 1.1), Planning (tasks 1.2), Development (task 1.3), and Validation (task 1.4).
• Exhibit 8 shows how sections of the project plan relate to activities captured in the WBS. Standard activities and dependencies are part of the schedule template. Project-specific activities and dependencies are documented in the project plan.

The presentation at the conference will show more examples of the implementation of the CMMI specific goals for PP and PMC.

Exhibit 6: Product Life Cycle

Exhibit 7: WBS for project schedule template

Exhibit 8: Examples of Sections of the project plan template relevant for implementation of SP1.1

Conclusion

By leveraging the strong foundation of experience, process, and structure provided by the CMMI maturity model, LogicVision has made significant progress in transitioning to our new product development model. We feel that we now have a very strong infrastructure in-place. Product teams are ramping up and are taking on responsibility for product business decisions. CMMI's requirements management process (REQM) is helping these teams build the right products needed to increase business and customer satisfaction. Project teams have been created and are operating under the new de-centralized paradigm. Projects and releases are planned and managed proactively through the steps of the product development lifecycle. CMMI's project management (PP and PMC) are in place and have become part of daily routine. The introduction of the project lead role has empowered the project teams to resolve issues and make decisions quicker to achieve project goals and deadlines. Because of the distributed project leadership function, we have successfully removed the highly anticipated bottleneck in product and project management.

By splitting the release into multiple projects, the Engineering organization has successfully transformed itself from a software development organization issuing annual releases to an organization focused and driven by projects which, in turn, roll up into releases that meet customer need. As a result, we have observed a significant increase in productivity (product content) as well as increased flexibility in reacting to customer and market conditions. Lastly, it is clear that we have a solid foundation upon which to scale our development organization.

In conclusion, we feel that adopting CMMI's maturity model has significantly contributed to our success in transitioning to our new product development model, as well as reaching the strategic goals outlined in the introduction.