Task: Manage the Capability Improvement Program
Plan, monitor, and control all projects that are part of the software development capability improvement program. Manage launches of process and tool improvements across projects.
Disciplines: Software Capability Improvement
Purpose
Ensure the successful adoption of needed enhancements to process and tools in order to achieve operational objectives.
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
  • None
Optional:
    Outputs
      Main Description

      A process and tools improvement program should be managed as you manage any other program of projects. Implementing new processes and tools across an organization is a complex effort requiring effective planning, monitoring, and control, because changing the way people work can jeopardize the success of projects.

      Set up milestones, allocate resources, execute iteratively, and manage it as you would a software development project.



      Steps
      Initiate the program
      The program is initiated following approval of the Business Case. This step sets up the necessary executive management and planning teams, and also sets out the criteria that will be used to determine success.
      Identify, assess, manage risks

      To identify risks, consider 'what can go wrong.' At the broadest level, of course, everything can go wrong. The point is not to cast a pessimistic view on the program, however; we want to identify potential barriers to success so that we can reduce or eliminate them. More specifically, we are looking for the events which might occur which would decrease the likelihood that we will be able to deliver process and tools improvements with the right features, the requisite level of quality, on time and within budget.

      Generally, based on the existing list, new risks will be identified by the team members, and captured at regular Status Assessments.

      Schedule and assign work

      Accommodate approved work for each process improvement project. This includes the development of plans, developing or evolving process assets and tool configurations, conducting training and mentoring and so on.

      For each project:

      The Iteration Plan prepared at the start of the iteration can select only from what is known at the time. This will be an increment of the total capability required (the requirements), and Change Requests left over from previous iterations. The Process Manager can then determine the resources and schedule for the iteration. Allowance for addressing problems and issues should be built into the plan for the iteration, either implicitly, in the effort allocated to the production of an artifact, or explicitly, in particular work packages. It is recommended that the latter method be adopted.

      The Process Manager will exercise some planning discretion in deciding when work should be undertaken - but in general, an attempt should be made to correct problems in the iteration in which they are discovered, and it should be possible to do this with the resources planned at the start of the iteration. There will inevitably be some (discovered) issues left unfixed at the end of an iteration (because an iteration should be timeboxed), but for the iteration to be deemed a success, it is not likely that many of these would be severe or rated high priority for other reasons.

      Little allowance can be made, however, for other than trivial enhancement requests, that arise unexpectedly. If such a Change Request for a substantial enhancement is sanctioned for the current iteration, the Process Manager will almost certainly have to re-plan, either by pushing off some planned capability to the next iteration, or by finding extra resources to make the change. Usually, such requests for enhancements will be held over for the next iteration, or even later ones, and then be made part of the regular iteration planning cycle.

      Monitor and report status

      Capture current status of the program, evaluate it against plans, and report it.

      Typically, project leads submit regular progress reports to the Process Manager providing the following information:

      • Effort booked against work packages
      • Estimated effort to complete each work package for which they are responsible
      • Tasks completed
      • Deliverables published
      • Issues arising that require management attention (from Review Records, for example). The Process Manager may record some or all of these in the Issues List for further attention and tracking.


      In order to properly assess the program's progress in relation to the plans, the Process Manager "rolls-up" the primitive metrics reported by the project teams to provide a full picture of the program's progress. The program's Measurement Plan describes how these derived metrics (the "progress indicators") are calculated.

      In addition to monitoring the work progress, the Process Manager also monitors the quality of the project artifacts. Quality metrics (again as defined by the program's Measurement Plan), are consolidated to provide an overall picture of the program's status compared to its stated quality objectives

      Having derived the program's progress and quality indicators, the Process Manager compares these against the expected state of the program as defined by the Release and Iteration Plans. At this point the Process Manager will evaluate the following:

      • Have all planned tasks been completed?
      • Have all artifacts been published as planned?
      • Is the estimated effort to complete tasks that are "in progress" within plan?
      • Are quality metrics (e.g. open defect counts) within planned tolerances?


      The Process Manager will also review the risk indicators identified for each risk on the Risk List to decide whether any risk mitigation strategies should be activated at this time.

      Relevant details are published to stakeholders as appropriate.

      Handle exceptions and problems
      Initiate appropriate corrective actions to problems and exceptions arising in the program.

      The Process Manager invokes the Handle Exceptions and Problems step to address any problems or issues as they become known.

      The first task is to evaluate each of the problems/issues identified in the Status Assessment and Issues List of all projects within the program. Most projects run a regular (often weekly) "Issues Meeting" for this purpose attended by the project manager, technical lead, and other team leads. For each problem/issue you need to identify the cause, its impact on the project and the program, and determine what your options are to resolve it. You should also determine if the possible solutions are within the authority of the project team to implement.

      Next, for each problem/exception, select the preferred approach for resolution and determine the steps you need to take to implement it. Once the corrective action for each problem or exception has been determined, and any necessary approvals, the project manager documents the work involved and raises Change Requests and/or Work Orders to initiate the work. The project manager is often able to retire issues from the Issues List at this point, because the closure will be tracked by other means.

      Prepare for project close-out (for each project)

      Complete the formalities associated with project acceptance and close-out, reassign project staff, and transfer other project resources.

      This step occurs for each capability improvement project after the final delivery of the main deliverables. The expectation is that there remain no problems that will preclude formal acceptance and adoption, and that any issues that do remain are documented and handed over for resolution to the maintenance team. A final Status Assessment will be prepared for the Project Acceptance Review; the stakeholders should acknowledge that all deliverables have been completed according to the contract and its supporting plans. If  acceptance is not provided, then there may have to be another iteration to resolve the issues that block acceptance.

      The project manager handles the remaining administrative tasks of project termination. These may include:

      • Ensuring that the project is formally accepted: the contract and the Product Acceptance Plan will describe the requirements. In the end, what is needed, in effect, is signed agreement from the customer that all contracted deliveries have been made, meet the contracted requirements and are accepted into ownership by the customer; all contracted activities (including acceptance test, if any) have been successfully completed; and that the customer takes all further responsibility (warranty and latent defect claims aside), for the products and any residual issues and actions associated with them.
      • Settling the project's finances - making sure all payments have been received and all suppliers and subcontractors paid. Organizational policy or other regulatory requirement may also require a more formal audit process at project termination, covering the project's finances, budgeting process, and assets.
      • Archiving all project documentation and records.
      • Transferring any remaining (non-deliverable) hardware and environment assets to the owning organization's pool of assets.
      • Transfer the project measurements to the corporate historical database.
      • Reassign remaining project staff: if possible, this should not be done abruptly. Most projects can accommodate a gradual ramp-down of staff levels, and allow a smoother transition of staff to other projects. The project manager should ensure that the project knowledge and responsibilities of departing staff have been transferred to those remaining. Staff performance reviews should also be conducted as staff are transferred.



      Key Considerations

      This task is performed iteratively and as often as required. It is typically required for any nontrivial capability enhancement efforts.

      If the organization does not manage capability improvement as a program, process and tools adoption is at risk. Without a managed program it is difficult to:

      • Provide objective evidence that the organization is improving
      • Achieve successful adoption by managing risks

      It is critical that the organizational software capability improvement team sees themselves as a service organization measured by the success of the software development projects it supports.


       

      More Information