SOFTWARE PROCESS IMPROVEMENT PROJECT PLAN draft 09/01/94 1.0 SCOPE In concert with the corporate strategy for business process improvement, and with particular emphasis on improving customer satisfaction, our organization has decided to ensure that we employ the same engineering excellence in our software development practises that we build into our products. This document describes a plan to: 1. improve software quality so that it always meets requirements with as few defects as possible 2. lower the cost of maintaining software 3. reduce the cycle-time of software development 4. improve the accuracy of project forecasting 2.0 IDENTIFICATION 2.1 PROBLEM STATEMENT Our customers are as individual as the many different countries in which they are located. All, however, face an ever changing business environment. As they strive for excellence in producing their products, they place ever increasing demands on our products and services. Rapid change makes for excellent business opportunities, but we need to minimize the problems associated with it: 1. a desire to rush products to the customer, leading to: A. insufficient functionality, i.e. not having all the real requirements satisfied B. high defect counts due to the shortening of design and test cycles C. lack of rigorous project planning and internal development documentation D. excess design complexity resulting from a failure to recognize the commonalities in what seem to be disjoint requirements from different customers E. failure to properly partner with customers to determine their true underlying needs 2. high long term maintenance costs, stemming from: A. having to fix products already in the field B. constant functionality changes/enhancements which require continual product redesign (and the risks associated therewith) C. training/retraining employees without proper documentation In order to keep up with our changing business environment, we must reduce our software development cycle time. But at the same time, we must preserve our high quality standards. In order to provide timely and correct product availability information to our customers, and so that we can more accurately balance internal resources, we must improve our schedule forecasting accuracy. 2.2 PROJECT CHARTER The Software Process Improvement (SPI) project's mission is to determine which software development areas need to be improved and to ensure that improvement occurs. That mission must be accomplished while our group continues to operate its business. Since no improvement can be made instantaneously and many cannot be made simultaneously, this project must achieve its goals using a sequence of improvement cycles based on the SEMATECH Software Process Improvement Method. That is, we will strive for improvement continuously. In each cycle, the areas which need improvement the most will be targeted. 2.3 PROJECT CUSTOMERS AND PARTICIPANTS Everyone in our group will eventually be both a customer and a participant of process improvement. The Quality Steering Team (QST) created the Software Quality Improvement Team (QIT) and gave it the responsibility for planning and deploying an improved software process. The QIT will propose process changes to the QST which will approve them for deployment in either pilot form or for wide scale use. The QIT has members from each software development organization to insure that each group's special needs are considered. The software staff will: 1. help direct the software process improvement activities 2. serve as action team representatives 3. take part in pilot projects 4. implement the software development process Our customers will be partnering with development to help us produce high quality products that meet all the requirements the first time. 2.4 PROJECT PHASES, OBJECTIVES, AND TACTICS Each cycle of the project will have the following major phases: 1. Conceptual 2. Appraisal 3. Goal Setting 4. Action plan development 5. Implementation 6. Evaluation At the end of each phase, the products of that phase and the action plans for the next phase will be reviewed with the QST and software staff. The QST is asked to concur with the approach and level of effort. The software staff is informed of the activities impacting them and provide comments to the QIT. Refer to the SOFTWARE PROCESS IMPROVEMENT PROJECT SCHEDULE for information about the timings of the phases. 2.4.1 Conceptual In this phase: 1. problems are recognized and reduced to least common denominators and stated in very general terms 2. an initial software process improvement plan is developed 3. a preliminary definition of software quality and preliminary quality goals are developed 4. a generic description of action teams is developed. The description of the teams covers the scope, approach, goals, responsibilities, and procedures. 2.4.2 Appraisal In this phase, a rigorous appraisal of the current state of our software development capabilities will be made using the "Coached Self Appraisal" provided by the Software Technology and Engineering Process methodology. The appraisal should provide concrete data upon which to build specific testable goals. The appraisal will be administered to all software staff at once so that different groups don't interpret the questionnaire differently. A summarized report of the findings will be presented to the QST and software staff. 2.4.3 Goal Setting In this phase, the QIT will use the appraisal results to finalize the quality goals and express them in a testable form. Certain improvements will be targeted for immediate action, and others left for a subsequent improvement cycle -- based on the perceived benefit of the change and the resources available. 2.4.4 Action plan development For each targeted activity, an improvement plan document, modeled after this one, will be produced by the QIT. These documents will describe the nature of the activity, the participants, the expected benefits of the change, and the measures of success that will expected. The action teams, which will shepherd the implementation of the activity, will be defined. Members will be chosen by the QIT with QST and software management concurrence. The QIT will customize the Generic Action Team Description for the specific activity and will add guidelines for its implementation. Action Teams define in detail the activities required to implement the improvement. The Action Team generates estimates of effort and schedules. Key points for conducting reviews will be identified by the Action Teams. 2.4.5 Implementation In this phase, the action plans described above, will be executed. Quality measurements will be taken throughout the implementation process so that an evaluation of process improvements can be made based on factual data in the evaluation phase. Pilot projects may be used to validate new processes. When a pilot is done, an evaluation of "lessons learned" will be made before putting the process into wide use. 2.4.6 Evaluation An analysis of what was done and how effectively it was done will be made in the evaluation phase -- which will be begin after all targeted activities have been put into organization wide utilization. The following major areas will be studied: 1. how effective were the changes in achieving our goals as described in section 1.0? 2. how well did the this process improvement plan work? 3. where can we improve the process? 4. how well did we get organization wide participation in the SPI activities? One product of the evaluation will be a list of improvements to make in the next cycle of the project. 2.5 PROJECT BENEFITS AND SUCCESS CRITERIA This project will be a success if: 1. there is a clear, measurable success in solving at least one of the problems, stated in section 2.1 2. a culture of continuous improvement is established 3. a organization wide software development process is established 2.6 PROJECT MANAGEMENT The QST created the Software QIT and will regularly review its progress towards meeting the objectives, stated section 1.0. The QIT is composed of members from the various development groups within the group so as to insure that each group's special technical needs are met. The QST is composed of the managers of each group and can insure that business needs are met. The QIT will have the central role in planning process improvement activities. The QST will make the decisions about additional participation in the appraisal, action plan development, and implementation phases described in section 2.4. Some development organizations have their own software process improvement teams. The QIT will attempt to interface with these teams when action plans need to be developed and when implementation efforts are needed. It is assumed that no additional head count will be available to implement process improvement activities or any new process developed. To minimize the risks of such a major, organization wide change, the SPI approach is: 1. The QIT is kept small to reduce costs, but is composed of members of all development organizations to insure completeness. 2. The department manager will supervise the activities of the SPI and report on their process to the leadership team. 3. Regular reviews with the QST are being held. 4. The SEMATECH Software Process Improvement method is being followed. This method has been shown to be successful in one company and SEMATECH is beta testing with six additional companies in 1994. In 1995, the method will be available for general use. 5. Regular consultation with the software staff to get the benefit of their experience and to keep them informed are being held. 6. Rigorous project planning and documentation are being done to: A. help insure the SPI project's success B. train the QIT members on the process C. serve as an example of the process That is, the process is being used to establish the process. 7. Process improvements are implemented in a stepwise fashion, instead of all at once. Project documents are being placed on a commonly available file server. Once a document has been accepted by the QST it can only be changed with the QST's approval (except for cosmetic changes which Russ Keenan, as QST liaison, can approve). Project schedules will also be placed on this file server, and will be updated regularly as work is actually accomplished. Changes to schedules will not require QST approval unless they impact cost or resource allocations previously agreed upon by the QST. The QIT will review progress against schedule at each meeting. All versions of all documents will be kept for comparison. Ascii files will be used to minimize cross platform incompatibilities. 2.6.1 SPI Project Business Plan This project's activities are described in the SEMATECH SPI method mentioned earlier. Wayman Garnett provided the QIT with a detailed project schedule corresponding to this method. Microsoft Project for Windows will be used to help estimate schedule and track progress. Project status will be reported to the QST and to the software staff on a regular basis. The QST has committed a few hours of each QIT member's time each week to the SPI project. As additional time is needed, particularly during the action plan development and implementation phases, the QIT will negotiate with the QST as to when or if a given project milestone should be pursued, based on the availability of resources. At the beginning of each major phase, the QIT will estimate the effort. If the expected effort exceeds that previously agreed to by the QST, the QIT will ask the QST for permission to proceed. 2.6.2 SPI Project Personnel Training Plan The QIT has received high level training about the STEP methodology and the SEMATECH Software Process Improvement methodology. Decisions about subsequent training for the QIT and other personnel will be made based on the kinds of process improvements deemed to be needed in the action planning phase of the current project cycle. 2.6.3 Toolset Identification Decisions about the need for specific software tools will be made based on the kinds of process improvements deemed to be necessary in the action planning phase or as early in the current SPI cycle as required to support improvement implementation needs. 3.0 SOFTWARE PROCESS IMPROVEMENT WORK PLAN 3.1 SOFTWARE PROCESS CAPABILITY ASSESSMENT We will use STEP's Coached Self-Appraisal to evaluate its software engineering capability. All software staff will be invited to participate in the appraisal the first time it is administered. A random sampling of developers is all that is technically required, but participating in the appraisal will be helpful in educating the participants. A random sampling may be used to reduce the cost of subsequent re-appraisals needed to measure progress. In each appraisal, the SPI team leader will: 1. Prepare for the appraisal. 2. Develop and deliver directions for the appraisal participants and will be available during the appraisal to answer questions so that everyone filling out the questionnaire will answer the questions in the same way. Software groups will collaborate to complete a single questionnaire for the group. 3. Collect and analyze the appraisal questionnaire data. 4. Present the appraisal findings to the participants. 5. Complete an appraisal findings report for the QST and the rest of organization. 6. Lead in the presentation of the appraisal findings to the QST and software staff managers / supervisors. The QIT will: 1. assist in the implementation of the appraisal 2. participate in the appraisal 3. participate in the presentation of the findings to the QST and software staff management. 3.2 FINALIZE THE PROJECT PLANS AND GOALS The QIT will take into account the appraisal findings, QST recommendations, and finalize the quality plans and goals. 3.3 IMPLEMENTATION The QIT will produce a list of the processes which need improvement. An action plan for each will be developed by the QIT. The plans will provide a "first pass" document describing: 1. objectives 2. expected benefits 3. measures of success 4. resources required 5. target schedules: A. for the pilot (if any) B. organization wide utilization 6. guidelines for an action team to follow The QST will determine which action plans it wishes to fund in the current improvement cycle. An action team will be formed to shepherd the implementation of each action plan. An action team is a collection of individuals experienced in the process being improved, and who have a vested interest in seeing the improvement be successful. Each team will: 1. Finalize the action plan. The criteria for each team to begin implementation includes: A. target estimates for the effort and schedules B. QIT concurrence with the plan C. measurements for tracking quality level attainment D. progress toward completion of the improvement activity 2. Implement the plan and collect quality measures. 3. Regularly review their status with the QIT and with other software staff. 4. Provide an evaluation of their successes, failures, or other lessons learned.                 A more complete description of the action teams may be found here. A QIT team member will be assigned to be the liaison between each action team and the QIT. The QIT will regularly report the status of the action teams to the QST. The QIT will make the determination as to which action plans to submit to the QST for approval based on the following prioritised criteria: 1. a desire to achieve a clear, demonstrable success in some process improvement area 2. an expectation that the QST will make the needed resources available 3. ease of implementation 4. expected benefit 3.4 EVALUATION Near the end of the process improvement cycle and after all targeted improvements have been implemented organization wide and after the quality measurements have been correctly gathered for a substantial period of time, an analysis of the progress towards achieving the goals stated in section 1.0 will be made by the QIT. The Software Quality Goals along with the action team evaluation reports and customer and software staff feed back will be taken into consideration. The quality measurements collection strategy will also be reviewed. A final version of the definition of software quality and the quality goals will be created. The SPI Strategy will be updated. An evaluation report will be presented to the QST and the the development staff. 3.5 ESTABLISHING A CONTINUOUS IMPROVEMENT PROCESS After the evaluation, plans for the development of a continuous SPI strategy will be developed and submitted to the QST. The following will be defined: 1. the role of management 2. the role of the Software QIT 3. the role of individual software staff 4. descriptions of generic SPI action teams 5. how we are going to oversee the continuous SPI process on its own (without the direct support of an SRDT SEPG person -- embodied by Wayman Garnett at this time). 3.6 NEXT CYCLE ACTION PLAN An SPI action plan for the next cycle will be produced by the QIT and submitted to the QST for approval. That plan will be modeled after this one, but will be enhanced by the insights and experience obtained from the current SPI cycle. The results of the appraisal and software metrics activities will figure prominently in its development. Process improvement activities, such as BEST, will be reviewed by the QIT and action plans will be aligned with these initiatives. 4.0 SPI PLAN SIGN OFF Before this plan can be implemented, it must be signed off by the the QST.