Guideline: Managing Capability Improvement as a Project
This guideline describes how to manage your capability improvement project as you would any other software development project.
Relationships
Main Description

Phased Approach

Implementing software development process and tools in an organization is a complex task and needs to be done in a controlled manner. We recommend treating it as a project that is external to or is a sub-project of your software capability improvement program. Set up milestones, allocate resources, and manage it as you would any other project.

The process-implementation project is divided into a number of phases where all four steps are performed in each phase until the project is ready and the process and tools are deployed and successfully used by the entire organization as shown in the following figure.

A process-implementation project can be divided into phases.

The following table gives a general idea of how a project can be planned with four phases.



Relative Phase Purpose Important results after the phase
Phase 1 To sell the process-implementation project to the sponsors A go or no-go decision from the sponsors. To support the decision, the tools may be demonstrated and a the process may be exemplified.
Phase 2 To handle the major risks A demonstrable prototype of the customer's software development environment is ready, including tools, templates, guidelines, and examples of processes.
Phase 3 To complete everything Completion of the customers software development environment including integration, test, and demonstration of its usage. All tools are ready to use. Templates, guidelines, and examples of processes are ready, a training curriculum is ready, and mentors are ready to start supporting the real projects through the next phase.
Phase 4 To deploy it to the entire organization Process and tools are deployed to the entire organization.


A project to implement process and tools in an organization has many similarities to a software development project. It has even been suggested that the phases above are named Inception, Elaboration, Construction, and Transition as they are for a software development project using the Rational Unified Process. However, we recommend that you do not use the same names on the phases to avoid any confusion.  

Planning Milestones

When you define the content and goals of the milestones, keep the following guidelines in mind:

  • Keep the final vision in mind.
  • Reduce major risks early.
  • Focus on major problem areas early.
  • Select those areas where you can make some easy gains early.


Planning Considerations

Some typical factors and how they can affect the plans are provided below.

  • Problems in the current development process. Focus on those areas of the development process where the organization has problems today. Focus on areas where you can expect some easy results and where people can see the benefits early. Make sure the first iterations focus on an area where you know you will address and solve one of the major problems in today's organization.
  • The need for change in the current organization. If there are lots of problems in the organization-with the tools or the way people work-the frustration level in the organization will be high. In this case, you can be more aggressive and employ the new process and tools, or parts of them, in real projects.
  • The capacity for change in the current organization. If they are either unaccustomed to change or currently overwhelmed by it, the goals of the first few iterations should be modest. In this case, the primary objective should be to build credibility and confidence in the process, with more intrusive changes reserved for later iterations when they can be more easily accommodated. See Concept: Managing Organizational Change
  • The size of the organization. If the organization using the process and tools is large, be sure that the process and the tools are stable enough to be used by many developers. In this case, be more careful by implementing the process and supporting tools during several iterations in one or more software development projects.
  • The risks involved. If they are small, be more aggressive and start using the process and tools in new projects earlier. If the risks are large, be more careful and use pilot projects to verify the process and the tools.
  • The attitude among people in the organization. Communicate the problems with today's organization and how it's working. If current personnel understand today's problems, it will be easier to accept and understand the need for change. Involve those people outside of the immediately affected part of the organization.


Do not try to do everything all at once. Instead, divide the implementation into a number of increments and, in each one, implement a portion of the new process together with the supporting tools. Typically, focus on one of the areas where you believe the change will have the most impact. For example, if the software development organization is weak in testing, you may start by introducing Test practices with tools that automate testing. However, if the organization is weak in capturing or managing requirements, start by introducing Requirements practices together with its supporting tools.

Implement the process and tools in iterations of software development projects whether in pilot projects or real projects. The purpose is to verify the process and the tools in as real an environment as possible. Consider the following points when you select software development projects and iterations:

  • If the goal is to implement the process and tools in one single software development project, decide to implement the process and tools in that one project, then monitor and improve the process as the project continues.
  • If the goal is to implement the process and tools in a large organization over many projects, consider implementing and verifying the process and tools in iterations over several phases. In that case, choose a relatively small project where you can apply the process and tools during the whole lifecycle of a software project.
  • If the improvements represent a significant departure from your current software engineering process, if you need to get a better handle on the risks and advantages of introducing the new process or if you are in a new organization with little or no process in place, try them out on a mini-project or a pilot project before applying it to your major, mission-critical development project.

See Guideline: Selecting a Capability Improvement Roll-Out Strategy for more information about implementation approaches.


The use of a new process, new tools, and possibly new technology in a software project makes the project's schedule more volatile. Be sure to allocate time and resources to implement the process, train people, and so on during the iteration in the software-development project where you start using the process and tools.


Top Reasons for Failure

It is important to understand these top reasons for failure:

  • Failure to incrementally implement process and tools.
  • Lack of management support.
  • Lack of bringing stakeholders on board. All stakeholders affected by the new process and tools must be onboard, including customers, other department, and sub-contractors.
  • Lack of willingness or ability to deal with organizational change.

These reasons focus on non-technical issues, which is exactly what our experience shows.