The Principles of Building a Post-Assessment Process Improvement Action Plan
After an organization has taken a deep breath and organized itself to follow up the findings and recommendations of an assessment, step one is for the authorities and structures outlined previously to lay out and implement a one-year action plan, with another assessment or "health check" scheduled at the end of the year. (Many organizations believe in alternating between informal "health checks" and official CBA IPI or SCAMPI assessments.)
After reviewing the relevant list of projects and KPAs/PAs that need improvement, and deciding which improvements are appropriate, a detailed plan of what needs to be accomplished should be drawn up for each area. This plan should include information as to when and how. Part of developing a process improvement culture involves yearly reviews of what remains to be improved.
Developing a process improvement plan entails laying out the activities needed to accomplish a specified improvement, determining the expected duration and required resources for each activity, and then developing a schedule that recognizes that some activities may depend on the successful completion of others. Then an evaluation of available resources can be made, and an assessment of the fit between the improvement schedule and other project and/or organization schedules can be undertaken.
Process improvement should then be managed like a project. The plan needs to be monitored and controlled. Measurements should be established and reported regularly to different levels of management. These can include Gantt charts; rate (status of activity completion) charts; and budget, resources, and risk charts.
A number of organizations have found that requiring project personnel to spend half their time on process improvement ensures making improvement real and immediate. Because they implement the improvements on their own projects, the two halves of their work become parts of a whole.
Status reports should be reviewed monthly not only by the process improvement project managers but also by a management steering group and by a senior management steering group (including the president/managing director) .
The Contents of a Post-Assessment Process Improvement Action Plan: An Overview
A post-assessment process improvement plan should include the following, some of which have already been mentioned:
- Identifying long-term and near-term business strategic goals.
- Tying business goals to assessment recommendations and improvement activities. A process improvement plan in a mature organization will include a description of how the organization’s goals are distributed over individual departments and are related to individual process improvement activities.
- Describing specific process improvement objectives, activities, and tasks.
- Describing and assigning roles and responsibilities for improvement activities.
- Identifying risks and resource constraints.
- Gaining provisional approval of the plan by senior and project management.
- Scheduling improvement activities. (This also means recognizing their logical sequence.)
- Conducting serial closed-loop reviews of the plan leading to final approval by project managers, personnel, and senior managers.
A Template of a Simple Plan to Identify and Track the Execution of Improvement Goals
The Components of a Thorough Process Improvement Plan: A Template Designed for a Mature Organization
The following Software Process Improvement plan template presents a sample organizational software performance improvement program for a given division. It lists organizational goals that have been developed in concert with senior management based on the company’s business goals and objectives.
Sample Template
1.0 Yearly Organizational Goals
The executive staff is to develop organizational goals, which will then be elaborated into engineering goals. Subsequently, the engineering goals will be developed into software engineering goals. Finally, software engineering activities will be planned to achieve the software engineering goals.
2.0 Processes That Have Greatest Impact on Organizational Goals
A Management Steering Group (MSG) identifies the processes most important for meeting organizational goals (for example, via a prioritization worksheet). This identifies the processes that directly or indirectly will have the greatest impact on achieving the organizational goals. The MSG then determines which of the highest scoring processes in the Prioritization Worksheet has the greatest scope for improvement. The worksheet identifies the following:
- Highest scope for improvement
- High scope for improvement
- Medium scope for improvement
3.0 Table for the Mapping Activities Against Processes
Mapping of Activities to Priority Processes
4.0 Table for the Mapping of Goal Measurements
A primary measurement is used to monitor how well the organizational goals are being achieved.
5.0 Creating a Quantitative Management Plan
Quantitative management activities are conducted by the software engineering organization and by projects with software content.
Organizational and Detailed Measurements Software Engineering Goal contains the detailed measurements that will be used by the projects to track their performance in meeting the organizational goals.
Describe who maintains process capabilities for peer reviews and defect profiles based upon the project’s performance. Describe who will continue to evaluate peer review and defect data from projects that have implemented quantitative management.
6.0 Creating a Defect Prevention Plan
Organization’s Goals
The software engineering organization’s defect prevention activities will be aligned with the software engineering organization’s goals.
Defect Prevention Infrastructure
Software defect prevention activities are conducted by [Title] and by projects with software content in accordance with a defect prevention process.
The [Title] manager leads the software engineering organization’s defect prevention activities.
The following indicates possible assignments for an organizational causal analysis team:
The organizational defect prevention manager:
- Assigns personnel to develop corrective action proposals for organizational issues.
- Selects tools to support defect prevention activities in accordance with the technology change management process.
- Manages the defect prevention activities in accordance with the defect prevention process.
A defect prevention manager is assigned to lead each project’s software defect prevention activities. The defect prevention manager assigns project personnel to causal analysis teams to develop corrective action proposals in accordance with the "develop corrective action proposal" process. He assigns project personnel to implementation teams to implement corrective action proposals in accordance with the defect prevention process.
7.0 Scheduling Organization-Level Defect Prevention Activities (for a Level 4 or Level 5 Organization)
The schedule for the organization-level defect prevention activities is shown in Organization Defect Prevention Schedule Activity.
Activity
Schedule
Hold organization defect prevention meetings
Monthly
Hold quarterly meeting with defect prevention managers
February, May, August, November
Collect and analyze defect prevention metrics; feedback to software engineering and SQA personnel; status, effectiveness, risks, and issues to senior management
Monthly
As new projects collect a certain number of operational defects or systemic defects, the appropriate project personnel will be trained and will start performing defect prevention.
8.0 Creating a Software Technology Plan
Software technology is implemented in accordance with a technology change management process. Proposals for technology can be categorized in two ways:
Recommendations from the process improvement planning activities. The recommendations are based upon the software organization’s goals and are documented in this plan.
- Recommendations include inputs from the engineers and projects; new technology that is required by a project but not in general use within the organization, recommendations from a Software Technology Insertion Review Board, and so on.
- Personnel that are drawn from across engineering staff a Software Technology Insertion Review Board.
Additional staff members are drawn from multiple sources including project, SQA, and software engineering personnel, and from the Software Engineering Process Group (SEPG).
The budget for the year to run the board and conduct Software Performance Improvement Plan improvements and opportunistic investigations is [X$].
9.0 Creating a Rewards and Recognition Program
Each quarter, the Management Steering Group (MSG) evaluates the people in the organization that have made significant contribution to the software process improvement program and recommends them for rewards and recognition. The rewards will be selected by the MSG based upon contributions.
10.0 Approval Authorization for Organization Process Definition (OPD) Updates
The SEPG should be authorized to decide on (i.e., accept or reject) most OPD updates. However, if the updates will take more than a certain number of hours to implement, or if the change may have a large potential impact on product quality or productivity, then the updates will be referred to the MSG for acceptance.
11.0 Tracking Software Process Improvement Measurements
In addition to the measurement and reports called out in the software process improvement process, the following measurements will be made to determine the status of the software process improvement activity each month:
- Actual versus budget for the software performance improvement activities.
- Milestone completion for the software performance improvement activities.
12.0 Assigning Software Performance Improvement Schedule and Budget
The software process improvement budget for [year] is [X$]. There are additional sources of funding related to the software performance improvement activity including funding [X$] for:
- Capital expenditures
- Training
- CMMI support
- Software Technology Review Board
- Project funding
- Dues and fees
13.0 Planning Activities to Address Assessment Weakness
In year 1, an assessment (i.e., SCAMPI or CBA-IPI) was held.
14.0 Planning Activities to Support Software Goals
Software engineering goals are developed from organization and engineering goals. The MSG will analyze each of the software engineering goals and recommend the following activities in order to achieve the goals. When an activity supports more than one goal, it is described with the goal it primarily supports.
Describe activity
- Priority:
- Assigned to:
- Develop capability report and brief to program managers and marketing by [date]:
A Common Temptation: Trying to Run Before You Walk
When confronted with assessment results, some organizations start thinking about moving up several levels at once. They often do not understand, though, that part of what has to be changed is the culture of their organization, which needs the experience of performing an improved process multiple times for it to become second nature. Approaching improvement by trying to skip a maturity level almost never works: "When you are starting a long-term endeavor, the goal is not to finish. Rather, the goal is to start. Once you have started, the goal is to keep going, and if you get stuck, the goal is to start again. How do you start? Begin by understanding the relationship between the current state and the desired state… What are we doing now? What can we change now? And what can’t we change yet?" .
Continuous optimization means sustaining momentum for change, not necessarily changing everything at once. Progress is made one step at a time, which means accepting that some things can’t be changed at this time but might be changed later.
Concentrate on what can be changed now. How much can be done in a month? Lay a foundation and come back in six months to make more improvements. Don’t wait for perfection, or else you might end up writing nothing or writing useless processes: "Build momentum by achieving small, successful steps that add up to greater progress. Understand the direction you are heading and start moving in that direction" .
Why Maturity Levels Can’t Be Skipped
Process capability grows in stages. Processes are only effective after prerequisite processes are stabilized. Engineering processes, for example, usually do not improve before management stabilizes the way it makes decisions. If management changes working conditions every week, the best processes in the world do not have a chance to succeed.
Maturity Level 2 is largely concerned with management decision processes. As management discipline solidifies, so does a more general quality discipline [Humphrey 89].
Moving from Maturity Level 2 to Maturity Level 3 is concerned with developing an organizational discipline. Maturity Level 4 is concerned with managing by data and using statistical process control. And at Maturity Level 5, an organization has developed a continuous improvement discipline.
In technical terms, at Level 2, managers learn to prepare estimates with their team rather than by themselves and begin methodically to track actuals against estimates. These changes constitute an important increase in management rigor.
They also, however, involve changing perspectives. Managers are empowered by enhanced information to take corrective action early rather than late, and they get into the habit of doing so when they need to. When costly problems are found in reviews and then fixed early and easily, teams start to see the benefit of independent and methodical reviewing and begin to feel discomfort when consistent processes are missing.
Planning for Reiterated Assessments
A schedule of periodic assessments keeps an organization focused on what needs to be improved and on whether past improvements are really working. When assessments are conducted on a continuing basis, their effect becomes less disruptive, and they begin to instill an instinctive feeling for continuous improvement.
Kim Caputo relates Unisys’s experience with multiple assessments this way: "Our initial assessment experience was like a shock to the system. When the assessors presented the list of major issues in five or six key areas, the managers were shocked by what they saw as bad news. They were not surprised by the contents of the list and they agreed that these were indeed the key major issues. But it wasn’t very pleasant to see all the major issues all at once.
"The second assessment and subsequent assessments were slightly different. The expectations were higher, because improvement work was in progress. Even though there was a similar shock reaction to the issues, it was balanced by encouragement for the progress that had been made. So the shock was not as severe. It seems that the more an organization works on process improvements, the easier it is to accept the assessment of major issues objectively with fewer negative reactions. The report is simply information that you need to know in order to improve. You can’t change what you don’t know about; you can’t change what you don’t talk about" .
Organizations have found that having frequent assessments is a very useful way to keep their eye on the improvement ball. Assessments signpost where an organization currently is, where its strengths lie, and what areas still need improvement. Periodic assessments allow this process to be conducted in a non-defensive way.