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
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| 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
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|