Mapping TSP to CMMI
Technical Report
CMU/SEI-2004-TR-014
Integration of Software-Intensive Systems Initiative
Unlimited distribution subject to the copyright.
[Abstract]
[3
[5 TSP Process Elements]
[7 TSP and CMMI Process Management Process Areas]
[Appendix A: Supplier Management Process Areas]
[Appendix B: Process Management Process Areas Using TSP as the Implementation Method]
[References]
Foreword
The SEI produced this technical report for those interested in both CMMI and the TSP and in how these two technologies might be used together to accelerate their process improvement efforts. The report also clarifies some common misconceptions about how these two improvement frameworks support each other.
TSP-CMMI Synergies
When adopting an SEI improvement technology, many organizations mistakenly view it as a stand-alone effort. However, software engineering is a rich and varied field and, as demonstrated by many other fields of engineering and science, there are often important synergistic benefits between seemingly unrelated technical disciplines. To encourage organizations to capitalize on these potential synergies, the SEI has a strategy for relating its improvement activities and for showing its partners and affiliates how its many programs can be used to support and enhance each other. This technical report is an early step in this strategy. It has been produced through the joint efforts of the CMMI and TSP project teams.
Mapping the TSP to CMMI
This report is similar in nature to an earlier SEI technical report mapping TSP practices to the CMM [Davis 02]. At the time of the earlier report, the CMMI framework was well advanced, and the SEI had committed to extending the earlier CMM-TSP mapping to cover CMMI. This is the CMMI-TSP report.
When we originally developed the TSP, we built on the CMM model and established the personal and team practices needed to implement the key CMM process areas that were directly pertinent to development teams. As shown in the earlier technical report, this included a high percentage of the practices at all process maturity levels, with a heavy focus on maturity levels 3 and 4.
However, because the CMM had important gaps, we had to identify and define a family of practices that were not covered by the CMM. These included, for example, risk management, integrated teaming, and distributed engineering. With the improved coverage that CMMI provides in these areas, the close relationship of the TSP and CMMI should be clearer than before. This close relationship has advantages for TSP teams, but it should be particularly valuable to organizations that use the TSP to accelerate their CMMI improvement.
The CMMI-TSP Improvement Strategy
Some people have the mistaken impression that TSP should not be introduced until organizations have reached CMMI level 2 or higher. It is now clear, however, that TSP can help organizations at all maturity levels, and that the sooner TSP is introduced, the better. Adopting TSP has been shown to greatly accelerate CMM process improvement. For example, SEI studies show that the mean time required for organizations to improve from CMM level 2 to CMM level 3 is 22 months and that the mean time to improve from level 3 to level 4 is 28 months. However, a NAVAIR study showed that its AV-8B Joint Systems Support Activity moved from level 2 to level 4 in only 16 months instead of the expected 50.1 They attributed this rapid pace of improvement to the organization's prior introduction of the TSP. While studies are currently underway, there are not yet any completed studies that document the acceleration achievable in CMMI process improvement through using the TSP. Based on the work done to date, however, the improvement benefits should be at least comparable to those of CMM acceleration with TSP.
Furthermore, the move from level 3 to level 4 has been recognized as the most difficult of all CMM-based improvement steps and it probably will be the most difficult CMMI improvement step. The principal reason for this difficulty may be that the process definitions that many organizations develop for level 3 must be reworked to include process measurement when they move to level 4. Because TSP includes the extensive use of measures, its use both accelerates the level 3 process definition work and also largely eliminates the need to rewrite these processes when moving to level 4. The move from level 3 to level 4 then needs only to address the two level 4 process areas.
The objective of this report is to help process professionals, process managers, project leaders, and organizational management to establish process improvement strategies and plans. If you are not now using TSP, this report will show you why it would be helpful to introduce it in parallel with your CMMI improvement efforts. However, if your organization is already using TSP and if you are planning a CMMI process improvement effort, this report will help you to decide on the most efficient and expeditious way to proceed. In either case, we suggest the use of TSP to guide the project-centered improvements and to concentrate the CMMI improvement effort on the organization-wide responsibilities that are not as completely covered by TSP.
The rest of this foreword assumes that you have a CMMI improvement effort in the planning stages or underway and that you are considering TSP introduction.
Typical Questions about TSP and CMMI
People have asked many questions about the relationship between the TSP and CMMI. Some of the most common questions are the following.
I have been told that TSP should not be introduced until an organization is at level 3 or above. Is that correct?
No. As mentioned earlier, the TSP is helpful to organizations at every CMMI maturity level. Experience demonstrates significant benefits from TSP introduction before or concurrent with the move to CMMI maturity level 3.
We have a crash program underway to get to CMMI level 3 as fast as possible. Should we attempt to introduce TSP at the same time?
That depends on your objective. TSP introduction will improve organizational performance faster than anything else you do. If your objective is solely to reach a given maturity level rather than to improve performance, you may wish to defer TSP introduction. However, by concentrating exclusively on achieving a maturity level rather than focusing on performance improvement, you are likely to get disappointing results. A maturity level focus may lead to a bureaucratic process, and this generally delays real process improvement and damages a development organization's performance rather than enhancing it.
We are moving to CMMI level 2 and replacing our entire development environment. Senior management would also like to introduce TSP at the same time. Technical management is resisting. Should we push ahead with TSP anyway?
Probably not. While some level of change is normal in most organizations, there is a point beyond which change can be destructive. At that point, it is usually wise to limit the pace of change to something that people can tolerate. Remember, the organization must continue to operate productively during the change process.
We have been at CMM level 1 for 10 years and have been unable to make significant improvement progress. Would TSP help us with CMMI improvement?
It very likely would. Generally, the reason that organizations stay stuck at level 1 is that their senior management is unable or unwilling to provide adequate support or to give sufficient priority to the change activities. Since CMMI improvement generally must be implemented in parallel by most parts of an organization, large, entrenched, or highly bureaucratic groups are often extremely difficult to change. Because a TSP-based improvement effort can be focused on a relatively concentrated area, it is easier for management to provide the needed focus on process improvement. However, you still must have senior management support, or no improvement effort is likely to succeed.
Is TSP introduction always successful or does it sometimes fail?
The TSP is not magic. When TSP introduction efforts have failed, it has been for the same reasons that CMMI improvement efforts fail: the management team does not understand or agree with the need to change. At any maturity level, the most common problems are the lack of management support, changes in senior management, or business failures and cutbacks. Generally, when the senior management champions stay in place, both TSP and CMMI improvement efforts succeed.
Final Considerations
It is becoming clear that by using TSP, organizations can greatly accelerate their CMMI process improvement work. However, several additional points should also be considered when deciding whether and how to combine TSP and CMMI improvement efforts.
First, through using TSP, engineers and engineering teams can see the reasons for many of the high-maturity CMMI practices, and they will be more likely to cooperate with and support a CMMI-based process improvement effort. It is much easier to get the support of engineers who have PSP training (part of TSP introduction) and TSP experience.
Second, since the objective of any software process improvement effort is to enhance organizational performance, and since this will require changes in engineering behavior, any improvement effort should be accompanied by steps that demonstrably change engineering behavior. PSP and TSP do this.
Third, a major risk for any improvement effort is that it can become bureaucratic and can impose added demands on the engineers instead of helping them. If, as suggested by this strategy, the group charged with process improvement work treats TSP teams as its customers, this risk will be greatly reduced.
Finally, while introducing TSP can greatly facilitate CMMI-based process improvement, this will only be true if it is properly introduced and used. For example, each TSP team should capitalize on the organization's existing2 processes and should work closely with the established quality assurance, process, configuration management, systems, requirements, and test groups. For the TSP effort to succeed, all of the team members and all of the involved management must be properly trained, the TSP activities must be led and coached by an SEI-authorized TSP coach, and the coach must be available to coach and support the team immediately after the launch. Guidance on TSP training and introduction can be found in Winning with Software: An Executive Strategy [Humphrey 02].Fourth, even if all of the above points were not enough, TSP can substantially improve the performance of the organization's software groups, even in some groups that have already achieved CMMI maturity level 5 [Brady 04].
[3
[5 TSP Process Elements]
[7 TSP and CMMI Process Management Process Areas]
[Appendix A: Supplier Management Process Areas]
[Appendix B: Process Management Process Areas Using TSP as the Implementation Method]
[References]
Acknowledgments
We hereby acknowledge the colleagues that helped in various ways to produce this report.
Detailed reviews of the specific practice observations by Mike Konrad and Suzanne Garcia improved the report tremendously. It is no exaggeration to say that we learned a lot about both CMMI and TSP in producing this report, and much of that was due to the clear feedback and insightful questions from the experts.
Our early reviewers, Watts Humphrey and Marsha Pomeroy-Huff, were instrumental in letting us know where we were on the right track and where we had gone off course. Marsha's detailed editorial comments deserve special mention in light of our editor's remark that the initial draft was "wonderfully well written and grammatically correct."
In addition to Watts and Marsha, the balance of the TSP Initiative team at the SEI provided steadfast support, encouragement, and crucial schedule relief. They are: Dan Burton, Kim Campbell, Anita Carleton, Noopur Davis, Caroline Graettinger, Julia Mullaney, Jodie Spielvogle, and Alan Willett.
Support from our chain of command never wavered during the production of this report. Jim Over, head of the TSP Initiative, and Bill Peterson, head of the SEI's Software Engineering Process Management (SEPM) program, have been constant believers in the importance of this work, and managed to push us along steadily without making us feel unduly pressured.
We had the extreme good fortune to have Watts Humphrey and Mike Konrad lend their time and talent to produce a foreword for this report. We hope that the reader finds the balance of the report as useful as their foreword.
Our editor, Pamela Curtis, provided a calming influence on the sometimes hectic final throes of production.
Finally, to the many colleagues in the process improvement community who provided input on specific points, and to the even larger number that have been checking our progress, we thank you for your patience.
[3
[5 TSP Process Elements]
[7 TSP and CMMI Process Management Process Areas]
[Appendix B: Process Management Process Areas Using TSP as the Implementation Method]
1 Introduction
Capability Maturity Model Integration (CMMI) is a reference model consisting of best practice descriptions for a broad range of engineering activities. It is the successor model to the Capability Maturity Model for Software (SW-CMM), the Systems Engineering Capability Model (SECM) from the Electronics Industries Alliance, and the Integrated Product Development Capability Maturity Model (IPD-CMM) [Chrissis 03]. As a descriptive model, CMMI is well suited for appraisal efforts seeking to determine a particular organization's capabilities within the scope of software, systems, integrated product engineering, or acquisition and for guiding the broad direction of process improvement efforts in these areas of expertise. However, it is not unusual for organizations to struggle when attempting to define operational practices that are both effective in terms of getting the work done and that adequately cover areas of the model targeted for compliance.
The Team Software Process (TSP) is a set of defined operational processes originally designed to implement high-maturity project-level practices of the SW-CMM. There is a growing body of evidence showing that TSP performs well in addressing key common goals of both SW-CMM and CMMI, namely, delivery of high-quality software, schedule performance, and cost performance [McAndrews 00, Davis 03]. In addition, TSP processes have been shown on paper to compare well to SW-CMM practices [Davis 02] and also have been demonstrated to be effective in helping real organizations to achieve high maturity on an accelerated basis [Hefley 02, Pracchia 04, Switzer 04]. With the advent of CMMI, the question naturally arises as to how well the TSP compares to the newer model. The purpose of this report is to answer that question, and to do so in a way that enables TSP implementation to be closely coupled with CMMI improvement efforts. The goal is that TSP implementation will enhance and enable the achievement of higher CMMI maturity levels in considerably less time than is commonly reported [SEI 04].
The tables presented in Section 6 constitute the core of the report. These tables, one for each process area (PA), list each specific practice (SP) of CMMI-SE/SW/IPPD v.1.1 [CMMI 02a, CMMI 02b], along with references to particular TSP process elements and practices. For each practice, a score is assigned, as explained in the methodology described in Section 2, along with any relevant notes. The PA tables are grouped by process category: project management, process management, engineering, and support. At the end of each process category grouping, an additional table is provided to summarize how the TSP maps into the generic practices (GPs) for that process category.
Section 3 and Section 4 of the report provide graphical summaries of the observation scores, grouping the PAs first by process categories per the CMMI continuous representation (Section 3), and then by maturity levels per the CMMI staged representation (Section 4). The TSP process elements referenced in the mapping tables are listed and briefly described in Section 5.
[3
[5 TSP Process Elements]
[7 TSP and CMMI Process Management Process Areas]
[9 TSP and CMMI Support Process Areas]
[Appendix A: Supplier Management Process Areas]
[Appendix B: Process Management Process Areas Using TSP as the Implementation Method]
[References]
2 Methodology
When determining how to score TSP practices with respect to related CMMI practices, the following guidelines were used to develop scoring values.
- Avoid the use of SCAMPI class "A" appraisal terminology. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) "A" rules of evidence clearly are not met by a paper exercise such as this, and the authors want to be unequivocal in declaring that this mapping is not a guarantee of SCAMPI compliance when appraisal time comes. Therefore, instead of "Fully/Largely/Partially/Not Implemented," the authors opted for the terminology detailed below. It is the proper activity of the engineering process group (EPG) and the appraisal team to make the determinations required by the SCAMPI method. Readers of the earlier TSP-CMM mapping [Davis 02] will recognize a similarity in terminology between the two reports.
- Avoid problems encountered in the earlier TSP-CMM mapping. While many of the ambiguities and overlaps between organizational and project practices that were inherent in the CMM for Software v.1.1 have been resolved in CMMI, of necessity a few still remain. The authors of this report have attempted to avoid labeling clearly good things in the TSP as "Partial," when in fact they are mature project practices that support a desirable organizational activity. Therefore, a rating of "S" for "Supports" was formulated to describe more closely how TSP relates to the model practice, while making it clear that there is more to the practice than what the TSP implements. "Fully addresses" was changed to "Directly addresses" to avoid the problems inherent in questions of whether all of the subpractices of a particular practice have been covered. "Directly" says exactly what is meant, without implying that all subpractices are necessarily implemented.
Table 1: Scoring Terminology Used in the Maps
2.1 Assumptions Behind the Observations
The following assumptions underlie the observations detailed in Section 6, Section 7, Section 8, and Section 9 of this report.
- The organization in question used the SEI-recommended TSP introduction strategy for training personnel and launching projects.
- All projects in the organization are using the TSP for all phases of a "normal" development life cycle (i.e., requirements, architecture, implementation, deployment, and maintenance). Specifically excluded are things such as business planning, business case analysis, and the like.
There is no assumption of a particular maturity level or capability level in any of the observations. However, the interpretation of whether a particular practice is rightly a project-level or organization-level practice remains open, and is one of the major issues with which an EPG must deal on an ongoing basis. The resolution of this issue is also likely to change over time as the organization and its projects work with the TSP process assets and assimilate them into their own ways of doing business.
In general, a lower maturity organization will leave more practices to the projects, but months or years later, many of the same practices for a similar project in the same organization will be performed as organization-level activities by the EPG or other designated group. A higher maturity organization with, by definition, significant experience in process improvement will naturally recognize many practices as standard organizational activities, and TSP teams will treat them as such when defining their working processes.
This report defaults to the assumption that specific practices (SPs) in the project management, engineering, and support categories are project-level activities, with exceptions noted as they occur. Specific practices within the process management category default to the assumption that they are organization level, again with exceptions as noted. All SPs are treated individually, however, with one observation block per SP in the analysis.
Generic practices (GPs) are institutionalization activities, though not necessarily organization-level activities. This report treats the GPs collectively according to the process categories, with each GP having one observation block across all the of the process areas (PAs) within its category. While this approach may be of lesser value in determining how well an idealized TSP implementation rates against CMMI, the intent of the report here is to emphasize that the GPs really are institutionalization activities, that TSP provides many hooks for true institutionalization, but that the decisions of whether, and how, to push the implementation of individual generic practices down to the team rests with the organization. Also, these decisions should probably relate across the PAs within a category. The approach used here seems to make these points adequately.
[3
[5 TSP Process Elements]
[7 TSP and CMMI Process Management Process Areas]
[9 TSP and CMMI Support Process Areas]
[Appendix A: Supplier Management Process Areas]
[Appendix B: Process Management Process Areas Using TSP as the Implementation Method]
[References]
3 TSP and the CMMI Process Categories
3.1 Overall
TSP as written covers a large footprint of specific practices across CMMI, as shown in the charts in this section and the next. The charts each show the percentage of SPs addressed, and to what extent they are addressed, with respect to different groupings of either the staged or continuous representations of the model.
TSP as typically implemented incorporates existing practices into a defined, measured process framework. The exact mix of existing practices and TSP practices is therefore different, not only for each organization that implements TSP, but also very often for each project, even within the same organization. In order for the information in this report to be useful, it should be combined with detailed knowledge of an organization's existing practices, possibly gained through a SCAMPI appraisal or other formal method.
Figure 1 shows a summary of TSP coverage of specific practices summarized by process category. For detailed observations of each PA, see Section 6, Section 7, Section 8, and Section 9.
Figure 1: Summary of TSP Project Practice Coverage by Process Category
3.2 Process Management
The process management PAs deal with cross-project activities related to developing, sharing, and adapting processes. Most of these activities are necessarily not specific to the work of a single development project, the domain of the TSP. However, TSP practices support nearly all of these activities, either by providing data and process assets for organizational use, by providing explicit process steps for using organizational assets, or by providing detailed implementations of a group of practices that can serve as an organizational exemplar. Depending on implementation choices made by the organization's EPG, many of these practices could be rated as directly addressed.
Figure 2 shows the percentage of process management specific practices addressed by TSP for each PA. For detailed observations of each PA, see Section 7.
Figure 2: TSP Practice Profile by Process Management PA
3.3 Project Management
The TSP shows remarkable coverage with respect to most of the process areas in the project management category. Much of the strength of the TSP lies in the multiple assets that it brings to bear in planning and tracking a project using data gathered and analyzed by the project team on an ongoing basis. While there is relatively weak coverage with respect to Supplier Agreement Management (SAM) and Integrated Supplier Management (ISM) specific practices, a project team using the TSP and planning to acquire significant components of its delivered product from other groups would likely include such acquisition activities in its planning and engineering processes as necessary.
Figure 3 shows the percentage of project practices addressed by TSP for each PA in the project management category. For detailed observations of each PA, see Section 6.
Figure 3: TSP Practice Profile by Project Management PA
3.4 Engineering
When a TSP team plans its engineering activities, it begins at a minimum with the core of TSP development and maintenance life-cycle process assets on which to draw. More often, however, the project team has its own practices, either from prior development cycles or from organizational process assets, to adapt into the defined, measured, and managed framework learned in PSP training and instantiated during the TSP launch. While the chart below reflects strong CMMI coverage using the TSP default development processes, the process group using this report to guide a process improvement effort should take special care to discover the actual engineering processes used.
Figure 4 shows the percentage of specific practices addressed by TSP for each PA in the engineering category. For detailed observations on each PA, see Section 8.
Figure 4: TSP Practice Profile by Engineering PA
3.5 Support
The CMMI support categories can be applied to any process area or process category, and therefore lack the central theme that the other categories possess. There is no particular pattern, therefore, in how the TSP addresses these categories. For example, Measurement and Analysis (MA) shows strong coverage, reflecting the TSP's fundamental alignment with such activities. On the other hand, Organizational Environment for Integration (OEI) deals with activities outside the scope of the typical TSP team, and therefore reflects weak coverage by the TSP.
Figure 5 shows the percentage of project practices addressed by TSP for each PA of the support category. For detailed observations on each PA, see Section 6.
Figure 5: TSP Practice Profile by Support PA
[3
[5 TSP Process Elements]
[7 TSP and CMMI Process Management Process Areas]
[Appendix A: Supplier Management Process Areas]
[Appendix B: Process Management Process Areas Using TSP as the Implementation Method]
[References]
4 TSP and the CMMI Maturity Levels
4.1 TSP and Maturity Level 2
At maturity level 2, the projects in an organization have ensured that requirements are being managed; processes are planned, performed, measured, and controlled to ensure meeting project commitments; suppliers are selected and managed to meet project commitments. This means that commitments are established and reviewed with stakeholders, management has visibility into the status of work products and the delivery of services, work products are appropriately controlled, and these deliverables satisfy their specified process descriptions, standards, and procedures.
The TSP provides specific guidance for Project Planning (PP), Project Monitoring and Control (PMC), Requirements Management (REQM), Measurement and Analysis (MA), and Process and Product Quality Assurance (PPQA). While Supplier Agreement Management (SAM) is not specifically addressed by TSP, the project planning, monitoring, and measurement aspects of TSP provide support for these activities. It is not unusual for an organization using the TSP to start asking their suppliers for TSP-equivalent project planning, tracking, and quality information.
Figure 6 shows the percentage of specific practices addressed by TSP for each PA at maturity level 2. For detailed observations on each PA, see Section 6, Section 8, and Section 9.
Figure 6: TSP Practice Profile by Maturity Level 2 PA
4.2 TSP and Maturity Level 3
At maturity level 2, it is not unusual for each individual project within an organization to have a different set of management and technical process descriptions, procedures, and standards. As an organization moves towards maturity level 3, a critical distinction becomes evident. At maturity level 3, the standards, process descriptions, and procedures for a project are tailored from the organization's set of standard processes to suit the needs of each project. As a result, the processes that are performed across the organization are consistent, except for the differences allowed by the tailoring guidelines.
The TSP focus is on teams, not organizations. Even if all projects in an organization are using the TSP, there is a need for additional organizational support. (Look at Organizational Process Definition (OPD) for examples of the additional support required.) The TSP provides teams with a robust set of processes and procedures that are usually tailored to meet the team's needs with guidance from a TSP coach. These standard TSP processes can be used to support the creation of an organization's standard set of processes, but they do not fully address all organizational process needs. TSP teams also collect and analyze product and process data, but in order to meet the intent of this PA, there is an additional need for an organizational function that collects and reviews this data and makes it available across the organization. In fact, it is not uncommon for an organization using the TSP for product development to initiate TSP process development projects to address the "organizational PAs" of maturity level 3: Organizational Process Focus (OPF), Organizational Process Definition (OPD), and Organizational Training (OT).
The TSP, along with the PSP, provides specific guidance for Requirements Development (RD), Technical Solution (TS), Product Integration (PI), Verification (VER), Validation (VAL), Risk Management (RSKM), and Integrated Teaming (IT). The TSP launch process, process and product data, and weekly team meetings support and enable Integrated Project Management (IPM), RSKM, and Decision Analysis and Resolution (DAR). While Integrated Supplier Management (ISM) is not specifically addressed by TSP, the project planning, monitoring, and measurement aspects of TSP provide support for its activities. The OPF and OPD process areas are supported by the process elements, process architecture, and process and product data from the TSP. OT is enabled and must be partially implemented by the introduction of TSP, as portions of the organizational training needs are identified, planned, and executed. The TSP launch and status reporting processes support Integrated Project Management for Integrated Product and Process Development (IPM for IPPD, often shortened to IPM-IPPD) and for Organizational Environment for Integration (OEI).
Figure 7 shows the percentage of specific practices addressed by TSP for each PA of maturity level 3. For detailed observations on each PA, see Section 6, Section 7, Section 8, and Section 9.
Figure 7: TSP Practices Profile by Maturity Level 3 P
4.3 TSP and Maturity Level 4
At maturity level 4, the organization and projects establish quantitative objectives for quality and process performance and then use these criteria in managing the projects. Quality and process performance are understood in statistical terms and are managed throughout the life of the processes.
Organizational Process Performance (OPP) derives quantitative objectives for quality and process performance from the organization's business objectives. TSP launch preparation calls for the team to have available the organization's standard processes for use by the team. A typical management goal, communicated in the launch, is to meet certain specified process performance and quality standards.
Quantitative Project Management (QPM) applies quantitative and statistical techniques to the management of process performance and product quality. Quality and process performance objectives for the project are based on those established by the organization. The TSP provides strong support for this process area: quality and process performance are planned, tracked, managed, and understood.
Figure 8 shows the percentage of specific practices addressed by TSP for each PA of maturity level 4. For detailed observations on each PA, see Section 6 and Section 7.
Figure 8: TSP Practice Profile by Maturity Level 4 PA
4.4 TSP and Maturity Level 5
At maturity level 5, processes are continually improved through both incremental and innovative technological improvements that are based on the quantitative understanding achieved at maturity level 4. Organizational Innovation and Deployment (OID) enables the selection and deployment of improvements that can enhance the organization's ability to meet its quality and process performance objectives. Causal Analysis and Resolution (CAR) provides a mechanism for projects to evaluate their processes and to look for improvements that can be implemented.
The TSP explicitly addresses the practices within the Causal Analysis and Resolution (CAR) PA and strongly supports the implementation of the OID practices. Postmortem meetings consolidate and begin to analyze data gathered either during a launch or following a development cycle. Specific problems and suggestions are documented by process improvement proposals (PIPs) during the postmortem or at any time in the life cycle. Future launches and relaunches then typically make relevant adjustments to the project's defined processes. Most organizations implementing the TSP recognize the value of such feedback from the primary users of the organizational processes and create mechanisms to incorporate the lessons learned so that other project teams may benefit.
Figure 9 shows the percentage of specific practices addressed by TSP for each PA of maturity level 5. For detailed observations on each PA, see Section 7 and Section 9.
Figure 9: TSP Practice Profile by Maturity Level 5 PA
[3
[5 TSP Process Elements]
[7 TSP and CMMI Process Management Process Areas]
[Appendix A: Supplier Management Process Areas]
[Appendix B: Process Management Process Areas Using TSP as the Implementation Method]
5 TSP Process Elements
The TSP is defined by a set of process elements that includes the following:
- scripts to guide specific work processes
- forms to capture specific information generated by enacting one or more scripts or otherwise required by some part of the process
- role specifications to guide individuals on a project in performing critical but often non-scripted (possibly non-scriptable) activities
- other assets such as the TSP introduction strategy, checklists, guidelines, and specifications not related to roles
- training courses and authorization activities in the TSP and PSP technologies
- These assets, summarized in the table below, are referenced in the "TSP Reference" column in the mapping tables of Section 6.
5.1 Scripts
5.2 Forms
|
Description |
|
|
Asterisked (*) items or equivalents are implemented in the TSP workbook (see Section 5.4) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Modified versions of form WEEK are used in each launch meeting. |
5.3 Roles
5.4 Other
Grouping / Name |
Description |
Notes |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
|
|
|
||
|
||
|
||
Team plan review questions; a quick start for an executive reviewing a TSP team's plan |
These assets can be found in Winning with Software [Humphrey 02]. | |
Project review questions; a quick start for senior managers to probe the status of a TSP project |
||
A generic procedure and timeline for TSP implementation in an organization |
||
|
||
|
||
|
||
|
||
Automated individual and team (consolidated) plans and actuals for size, effort, defects, and schedule; functionally equivalent versions of asterisked (*) items above under Forms are included in the TSP Workbook |
Excel-based; provided by the SEI as part of the licensed TSP product suite |
|
A review of the project to date conducted by the TSP coach or other process expert |
|
|
5.5 Training
[3
[5 TSP Process Elements]
[7 TSP and CMMI Process Management Process Areas]
[Appendix B: Process Management Process Areas Using TSP as the Implementation Method]
6 Observations by Process Categories and PAs
6.1 TSP and CMMI Project Management PAs
The Project Management process areas cover the project management activities related to planning, monitoring, and controlling the project. The page numbers for each process area as listed below are from CMMI: Guidelines for Process Improvement and Product Improvement [Chrissis 03].
The Project Management category contains the following process areas.
6.1.1 Project Planning (PP)
The Project Planning (PP) process area includes developing the project plan, involving stakeholders appropriately, obtaining commitment to the plan, and maintaining the plan. When using an IPPD approach, stakeholders represent not just the technical expertise for product and process development, but also the business implications of the product and process development. Planning begins with requirements that define the product and project. The project plan covers the various project management and engineering activities that will be performed by the project. The project will review other plans that affect the project from various relevant stakeholders and establish commitments with those relevant stakeholders for their contributions to the project.
6.1.2 Project Monitoring and Control (PMC)
The Project Monitoring and Control (PMC) process area includes monitoring activities and taking corrective actions. The project plan specifies the appropriate level of project monitoring, the frequency of progress reviews, and the measures used to monitor progress. Progress is primarily determined by comparing progress to the plan. When actual status deviates significantly from expected values, corrective actions are taken as appropriate. These actions may include replanning.