NO WARRANTY

xi


List of Figures
Most software projects are delivered late, over budget, with less functionality than expected, and with quality problems.According to a Standish Group International CHAOS study [Standish 01], only 28 percent of all software projects finish on schedule, within budget, and contain all of the features and functions as originally specified.To help address these problems, many organizations have implemented process improvement programs based on the Capability Maturity Model for Software (SW-CMM®) and the Software Capability Maturity Model Integration (CMMI®) frameworks.Even with SW-CMM or CMMI, the road to success often proves to be long, with steep hills, deep valleys, and occasional dead ends, leading participants in these efforts to pose the frequently asked question, "Are we there yet?"As a result, it is not uncommon to hear comments that many of the "improvement" efforts implemented to address software project problems take too long, do not persist within the organization, and do not yield measurable results.
This report outlines how two U.S. Naval Air Systems Command (NAVAIR) organizations integrated a pair of complementary process improvement technologies to accelerate implementation of a solution to address their process improvement problems.The information contained in this report should prove to be useful for Software Engineering Process Groups (SEPGs), Engineering Process Group (EPG) members, Team Software ProcessSM (TSPSM) coaches, process professionals, process managers, project leaders, and organizational managers who are interested in addressing cost, scheduling, and quality problems.The report assumes the reader has some general familiarity with process improvement activities, but may not be familiar with the details of the SW-CMM, CMMI, or TSP technologies.Readers who are unfamiliar with these technologies can review the materials listed in the bibliography.
Section 2 of this report provides background information about the process improvement methodologies used by NAVAIR: Capability Maturity Modeling (CMM), Personal Software Process SM (PSPSM), and TSP.Section 3 presents information about the two NAVAIR organizations that participated in this case study and describes the key components and activities used to achieve rapid results.Based on these data, the conclusion of this report in Section 4 summarizes the common elements that helped the NAVAIR organizations to achieve lasting process improvement success.

THE CMMI FRAMEWORK
The CMMI framework is a reference model consisting of best practice descriptions for a broad range of engineering activities, covering the entire product life cycle from requirements definition through delivery and maintenance.It succeeds the Systems Engineering Capability Model (SECM) from the Electronics Industries Alliance, the Integrated Product Development Capability Maturity Model (IPD-CMM), and the SW-CMM, which was originated by the Carnegie Mellon® Software Engineering Institute (SEI) [Chrissis 2003].Because many process improvement models focus on a specific part of an organization's operations and do not take a systemic approach to the problems that most organizations face, such models tend to perpetuate the barriers to improvement that exist in most organizations.The CMMI framework builds on the SW-CMM concepts to provide a mechanism for process improvement that helps organizations to avoid or eliminate these barriers by integrating models that transcend disciplines.As a descriptive model, CMMI is well suited for organizations that are seeking to quantify their capabilities within the scope of software, systems, or product engineering by participating in an appraisal.It is also instrumental in guiding the broad direction of process improvement efforts in each area of expertise.
Like the SW-CMM model, the CMMI framework is based on the premise that process improvement is based on small, evolutionary steps rather than large-scale, sweeping changes [Paulk 93].
The SW-CMM and CMMI frameworks provide a foundation for gradual improvement by defining five maturity levels that set forth a measurable set of criteria for assessing an organization's software process maturity and for evaluating its software capability.Each of the five levels is composed of a set of process areas with component goals, that, when satisfied, provide significant improvement in a particular area of the software process.

Average Time Between Maturity Levels
Because the CMMI has only recently replaced the SW-CMM, there currently is insufficient statistically-valid data to report on the average time taken by an organization to transition from one maturity level to the next when using the CMMI framework; however, preliminary evidence suggests that the time for transitions between CMMI maturity levels is likely to be similar to that of organizations that used SW-CMM.SEI data show that the mean time required for such organizations to progress from Maturity Level 2 (ML2) to Maturity Level 3 (ML3) was 19 months, and the mean time to progress from ML3 to Maturity Level 4 (ML4) was 25 months.Figure 1

THE PSP AND TSP METHODOLOGIES
The SW-CMM principles were intended for use in large organizations, but based on its success, small organizations and separate units of large organizations wanted to know how they could tailor the SW-CMM for use in their environments.Could software development teams and individuals apply similar principles to improve their work?Watts S. Humphrey, a founder of the process improvement initiative at the SEI, decided to apply SW-CMM principles to the development of module-sized software programs, both to see whether this approach could work at the individual level and to determine whether software engineers could be convinced to adopt different practices for developing software modules.Humphrey's research evolved into the Personal Software Process (PSP).In developing the PSP methodologies, he used all of the software SW-CMM practices up through Maturity Level 5.
PSP process provides engineers with a structured framework for doing software work.It consists of a set of methods, forms, scripts, measures, and standards that show software engineers how to use a disciplined process to plan, measure, and manage their work.
After developing PSP, the next milestone in software process improvement was the introduction of the Team Software Process (TSP).TSP uses the principles and methods of PSP to provide a context for performing disciplined, team-oriented engineering work.The principal motivator for the development of the TSP was the conviction that engineering teams can do extraordinary work, but only if such teams are properly formed, suitably trained, staffed with skilled members, and effectively led.The objective of TSP is to provide a framework for building and guiding such teams.

The PSP and TSP Introduction Strategy
The SEI has developed a strategy for introducing the PSP and TSP into an organization.This strategy parallels many aspects of the SW-CMM introduction strategy and, as will be described in Section 3 of this report, the SEI introduction strategy was followed closely by the organizations at NAVAIR.The introduction strategy involves the following overlapping steps.
1. Identify the key projects for the initial introduction.
2. Hold an executive strategy seminar with the key stakeholders (1 day) and a transition planning session (0.5 day).
3. Identify two to four projects to pilot the process.Use the following guidelines when selecting pilot projects.5. Conduct pilot projects and evaluate the results.
6. Train and authorize an internal PSP/TSP transition team.
7. Define the introduction goals and responsibilities.
8. Designate a team to plan and initiate a broad rollout.9. Work project by project and launch each one by using TSP.
10. Build an experience base and train managers, engineers, and other support personnel as needed.
11. Repeat the introduction steps across the organization.
Using this strategy, a 200-person software organization can achieve organization-wide use of TSP within 24 to 30 months.Training additional TSP instructors and coaches can increase this rate of adoption.

The TSP and CMMI are Complementary
When adopting a particular SEI improvement technology, many organizations mistakenly view implementation of this technology 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 [McHale 05].Therefore, adoption of TSP and CMMI should not be seen as an "either-or" choice, since TSP and CMMI are designed to work together.Much evidence suggests that the two technologies are most effective when introduced together.
The CMMI framework provides top-down guidance for what organizations should do to improve processes, while TSP and PSP provide team-and individual-oriented principles for how to implement most of the CMMI process areas.As shown in Figure 2, the CMMI framework provides the overall improvement structure needed for effective engineering work [Chrissis 03].The TSP methodology enables engineering teams to more effectively develop and support softwareintensive systems.The PSP provides the discipline that engineers need to consistently use a defined, planned, and measured process [Humphrey 96].In 1998, a Business Process Reengineering (BPR) team was assembled to make recommendations for improving software engineering practices across NAVAIR's field activities.Such improvements were mandated by NAVAIRINST 5234.2, which required all NAVAIR software-intensive programs to initiate process improvement practices [NAVAIR 04].After studying various organizations around the country and analyzing the collected data, the BPR group recommended that NAVAIR use the SW-CMM as a major tool for achieving software process improvement.One BPR group member, Jeff Schwalb of the Software Leadership Team (SLT), had previous software process improvement experience and was an authorized PSP instructor.At Schwalb's urging, Watts Humphrey briefed the SLT on the PSP and TSP, and after the briefing, the team understood that PSP and TSP methods were ways to quickly implement SW-CMM-based process improvement.As part of NAVAIR's overall process improvement initiative, a policy was created, recommending that "programs engaged in organic software development should use the Personal Software Process and Team Software Process (PSP/TSP) methodologies for personnel training, project initiation and execution."

P-3C MARITIME SURVEILLANCE AIRCRAFT SOFTWARE SUPPORT ACTIVITY (NAVAIR PAX RIVER, MARYLAND)
This section describes the background and approach of the P-3C Maritime Surveillance Aircraft (MSA) Software Support Activity (SSA) organization, which used TSP to decrease the amount of time required to progress between SW-CMM maturity levels.

Organization Background
The P-3C SSA organization is located at Naval Air Station Patuxent River, Maryland.It provides software support for the P-3C Orion aircraft, shown in Figure 4.The P-3C was originally designed as a land-based, long-range, anti-submarine warfare patrol aircraft, but today is used mostly for battlespace surveillance over both land and sea.

Process Improvement Approach
Based on the recommendation from the BRP and the realization that the organization needed to improve its processes, NAVAIR formed an Integrated Program Leadership Team (IPLT) in April 2001.
The IPLT participated in "High-Performance Organization (HPO)" workshops, during which the team documented its vision, values, and leadership philosophy and conducted a strategic customer-value analysis to ensure that the goals of the organization aligned with the needs of its sponsors.During these workshops, the leadership team realized that it had a real business need for developing a set of organizational process improvement goals.These goals were to Before starting its improvement efforts, the IPLT realized that it first needed to understand the state of P-3C SSA's current practices with regard to the SW-CMM.After reviewing the model, the IPLT realized that the organization was already performing many of the Maturity Level 2 practices.However, many practices were not being documented using well-defined stakeholder involvement and entry and exit criteria, as dictated by SW-CMM.The leadership team agreed that the P-3C SSA organization would benefit from institutionalizing the Maturity Level 3 practices by pursuing a Maturity Level 3 rating.
The P-3C SSA officially kicked off its process improvement initiative by forming a Process Improvement Group (PIG) in February 2002.The PIG consisted of members of the engineering community representing each phase of the product life cycle.PIG members accepted assignments to lead process-action teams to develop policies, processes, templates, and standards that included well-defined entry and exit criteria and stakeholder involvement.As part of the kickoff, the PIG and the IPLT attended the SEI Introduction to CMMI course.
Since the PIG did not have previous experience with TSP, several members consulted other NAVAIR teams who were familiar with TSP.They discussed the process for introducing TSP into an organization and the lessons they had learned.Eventually, the PIG elicited TSP coaching support from another NAVAIR organization.In March 2003, TSP was introduced into the P-3C SSA using the standard TSP introduction strategy.The P-3C SSA conducted an executive seminar to brief the leadership on what TSP was and the types of benefits that could be realized.Managers received the proper training and two development subteams, the Tactical Mission Software (TMS) group and Acoustics Team, were trained in PSP.The TMS subteam held its first TSP launch in May 2003.
The process improvement effort was extremely important to senior management.To demonstrate its support, the IPLT lead attended PIG meetings, elicited feedback from the team, asked questions about current and future processes, helped facilitate the sessions, and ensured that progress was being made and that barriers to change were being removed.The IPLT lead regularly briefed upper management and the rest of the organization on the initiative.The PIG viewed senior management's involvement as a driving factor that moved the organization forward.
After planning its strategy and winning the approval of the IPLT, the PIG started 17 Process Action Teams (PATs) in June 2002, with each assigned to work on a portion of the CMMI Maturity Level 2 and 3 process areas (PAs).Initially, the PATs worked individually to establish plans that defined the required CMMI elements for each of the assigned process areas.After several months, it was determined that the PATs were ineffective because team members didn't grasp the intent of the CMMI model as a whole.In addition, the PATs didn't have enough time to analyze the model and their processes, and in some cases didn't even involve the correct stakeholders.The PIG leaders recognized that this approach was not effective and disbanded the PATs.
The PIG realized that it needed a new approach to its process improvement efforts.In 2002, the SEI had published a milestone technical report titled Relating the Team Software Process (TSP) to the Capability Maturity Model (CMM) for Software [Davis 02].The PIG used this report to understand which process areas of the SW-CMM overlapped with TSP and to determine where gaps existed.While reviewing this document and the SW-CMM requirements for Maturity Level 4, the group realized that TSP covered approximately 90% of the Level 4 key practices.The P-3C SAA would have to close only a few gaps to obtain Maturity Level 4 capability.Also, because TSP was already being used to develop and maintain software, some teams in the P-3C SAA were already working at close to Level 4 capability.
In January of 2003, the PIG formed 12 new PATs to address each phase of the product life cycle.Each PAT outlined the existing process architectures for each of its phases using flowcharts.The PATs also addressed overarching areas such as program management, configuration management, quality assurance, and training.Using the CMMI framework as a guide, the PIG lead worked with each PAT to ensure that the appropriate processes, templates, and standards were generated for each step in each product life-cycle phase.The TSP was then incorporated into the plans with the standard scripts being customized to meet the organization's needs.The PIG lead ensured that the intent of TSP methods and the CMMI framework were both preserved by reviewing the newly defined processes.The PIG also conducted a gap analysis to ensure that their implementation complied with the CMMI model.As the PATs worked to redefine processes, opportunities for improvement surfaced and were integrated into the plan.This resulted in the creation of the organization's standard process architecture, which the PIG calls "The Golden Process."This architecture is a set of well-defined processes that can be tailored to meet the needs of individual project teams.Even today, the PIG reviews all proposed changes to the Golden Process and serves as the approving authority for all change requests.
The PIG understood that process improvement involved more than just documenting current processes, understanding and closing gaps between TSP methods and the CMMI framework, and implementing the processes on real projects.The PIG members realized that in order to make the improvements last the organization's culture needed to change.Everyone in the P-3C organization needed to understand what process improvement was all about and needed to become convinced that improving processes wasn't something separate from his or her daily work, but an integral part of it.Utilizing the PIG model, the P-3C organization launched a communications campaign to keep everyone informed.New PIGs began to appear throughout the organization and posters touting the benefits of process improvement hung on the door of every manager.They sent newsletters about process improvement, held senior management pep talks, team-building events, team training, and even picnics and a logo contest.The P-3C Process Improvement Lead, Julie Switzer, explained "People resist change because they don't understand it, they perceive it as a threat, or it's forced upon them.Involving the team, keeping them informed and encouraging them to be proactive in documenting and defining their processes helped to create a collaborative, synergistic environment.This was critical in achieving success in process improvement." Software development and maintenance work continued as process improvements were gradually implemented.The Acoustics Team held its first TSP launch and relaunch.Several members of the organization were trained as PSP instructors and TSP coaches.
After two years of dedicated work, new processes were in place and use of TSP methods was starting to pay dividends in improved schedule variance, increased ability to estimate costs, decreased defect density, reduced rework, faster cycle time for products, and detection of defects earlier in the development cycle [Switzer 04].Table 1 shows some of the P-3C results.In February 2004, the organization conducted what it called a "CMM snapshot assessment" to determine how the P-3C SSA was progressing and to determine its readiness for a formal assessment.The snapshot assessment identified a few weak process areas (PAs) and a SCAMPI A appraisal performed on the Measurement and Analysis and Risk Management PAs identified several small issues that the PIG and teams addressed during the next few months.
In May 2004, just 27 months after beginning their process improvement activities, the P-3C SSA organization underwent a two-week assessment and achieved Maturity Level 4.

Process Improvement Timeline
The timeline of the P-3C SSA process improvement efforts described in this case study is as follows.

Continuing Process Improvement in the P-3C SSA Organization
Currently, the P-3C SSA organization is transitioning from the SW-CMM to the CMMI framework.During this transition, it is revisiting and revising its mission, values, customer needs, and organizational goals.The PIG is conducting a CMMI gap analysis and formulating an action plan for each PAT, focusing first on the areas not specifically addressed by the SW-CMM and the improvement opportunities identified during their two-week assessment.As part of the gap analysis, the PIG is using the latest SEI technical report that maps TSP methods to the CMMI framework, Mapping TSP to CMMI [McHale 05].

AV-8B JOINT SYSTEM SUPPORT ACTIVITY (CHINA LAKE, CALIFORNIA)
This section describes the background and approach of the AV-8B Joint System Support Activity (JSSA) organization for using TSP to decrease the amount of time spent between CMM maturity levels.

Organization Background
The organization described in this section is the AV-8B JSSA, located at China Lake, California.It provides software support for the AV-8B Harrier aircraft, shown in Figure 5, for the United States Marine Corps and its allies, Spain and Italy.During the time in which the AV-8B JSSA organization began using TSP, it employed approximately 125 people.Its primary focus is on two goals: develop new software and maintain existing software.
In May 2004, the AV-8B JSSA achieved Maturity Level 4. The organization accomplished this feat in just two and a half years.

Process Improvement Approach
The AV-8B TSP story is very similar to that of the P-3C organization.As part of the NAVAIR organization, the AV-8B organization also needed to satisfy the policy developed by the BPR, which required Maturity Level 3 or equivalent rating for all software-intensive programs and compliance with a strong recommendation to use the PSP and TSP methodologies.
The AV-8B organization also had similar process improvement goals to those identified by the P-3C SSA organization: to positively affect cost, schedule, quality, and the work environment by employing High-Performance Organization principles to improve AV-8B's leadership philosophy, culture, and business processes.The other significant process improvement technology the AV-8B organization used was SW-CMM.It began implementing SW-CMM in March 2000 by using the traditional approach.The organization identified Software Process Improvement (SPI) goals in relation to the business goals (use of the model, attaining a maturity level, and the performance benefits).A crossfunctional systems and software engineering process group (SSEPG) was formed to define the program's scope and to create an SSEPG charter.To ensure that everyone understood the foundations of SW-CMM, the SSEPG attended the Introduction to SW-CMM course.After training was complete, PATs were formed to identify and validate existing AV-8B organization processes and documentation.The PATs and the SSEPG identified gaps in their current processes and what was required for a SW-CMM Maturity Level 2 rating and made adjustments to close the gaps.
In October 2000, the AV-8B organization introduced TSP using the standard introduction strategy.The introduction included an executive seminar, manager and support staff training, and software engineer training.
The existing SW-CMM implementation was supported by the adoption of TSP as its standard software process.The TSP provided the AV-8B with a complete package of training, tools, processes, coaching, and mentoring.With TSP as its standard software process, the organization had a customizable framework with which to estimate, plan, track, communicate, and measure the quality of its software processes and work products.In addition, through assignment of standard TSP roles, responsibilities for communicating and coordinating software team activities within the larger AV-8B organization were established [Pracchia 04].
The AV-8B launched its first TSP development project for new software at the beginning of 2001, followed by the launch of a TSP project for software maintenance in mid-2002.
In May 2001, the AV-8B organization underwent a CMM-Based Appraisal for Internal Process Improvement (CBA IPI).The assessment included TSP and non-TSP projects of similar sizes.This resulted in the organization's achieving a SW-CMM Level 2 rating in just 14 months.While this assessment was officially focused on meeting Maturity Level 2 and 3 goals, the organization also created observations for the Maturity Level 4 and 5 practices to aid in understanding the effect of implementing TSP in the organization.These observations were used to help determine which SW-CMM key process areas (KPAs) were influenced by TSP and to what extent.
Initially, the EVMS and SW-CMM initiatives were not closely coordinated and the SSEPG had mixed expectations, which made process improvement efforts difficult.As a result, several changes were made to the SPI program.First, the SSEPG began executing the SPI effort as a project.It appointed a SSEPG lead who had strong project management and communication skills.
The SSEPG streamlined its operations and infrastructure and developed tools for defining and improving processes and established a process configuration management process and repository.
The SSEPG soon realized that there were three overlapping process improvement initiatives in place and it needed to understand the gaps and overlaps among the different projects before proceeding.To facilitate its understanding, the SSEPG obtained a copy of the SEI technical report, Relating the Team Software Process (TSP) to the Capability Maturity Model (CMM) for Software [Davis 02].After reading the report and reviewing its assessment results, the SSEPG realized how synergistic the EVMS, SW-CMM, and TSP technologies are and that using them in conjunction with one another was important to achieving the organization's process improvement goals.The SSEPG then worked to understand and close the "gaps" between all three technologies and the organization's current practices.
In September 2002, the AV-8B organization underwent another CBA IPI and achieved a Maturity Level 4 rating 16 months after reaching Level 2. Fostering a team-oriented culture, having champions for software process improvement, having sound discipline, schedule adherence, and management support, and focusing on EVMS and TSP are factors that made success a reality.

Conclusion
By using the PSP, TSP, and the CMMI framework in conjunction, organizations can jump-start, accelerate, and better sustain their process improvement initiatives.Using TSP methodology is a manageable way for organizations to get started with process improvement.The TSP also satisfies the majority of the CMMI project-level practices and can be readily adapted to support organizational-level practices [Davis 03,McHale 05].
However, even organizations that use this approach can encounter failures in their process improvement projects because in most organizations, it is extremely difficult to affect change.The sections below present one model of how to make change happen successfully and how the actions of the NAVAIR organizations featured in this case study align with this model.

COMPONENTS REQUIRED FOR SUCCESSFUL CHANGE
Implementing process improvements or any kind of change in an organization is difficult, and many efforts fail to achieve the desired results.In his book, Strategic Organizational Change: A Practitioner's Guide for Managers and Consultants, Michael Beitler [2003] outlined a model of seven key components required for successful organizational change.These components are described as follows.
1. Involve the people who will be affected by and/or implementing the change so that they buy in and take ownership of the plan for change.
2. Communicate the need for or reasons behind the change so that the effort is seen as relevant and strategy-driven.
3. Designate a champion for the change effort; a senior manager or executive is good, but a fellow employee may be even better.
4. Create a transition management team to provide emotional support and practical ideas for the organizational change.
5. Provide training in new skills, behaviors, or values to ensure competency and minimize feelings of inadequacy.
6. Bring in outside help to provide fresh perspectives and/or needed expertise.
7. Reward people for their accomplishments in implementing or adopting the desired changes.
If any of these components are missing, change is more difficult to achieve and may or may not be successfully implemented.
Beitler's model can be used to help organizations to diagnose the origin of their problems in implementing successful change or process improvement efforts, and can help in determining what types of actions are needed to correct the situation.For example, when there is resistance or re-fusal to change among members of the organization, it is often due to lack of buy-in by the parties who must implement or actuate the change; getting these people involved and ensuring that they understand why the change is needed helps to reduce or eliminate the resistance to change.Lack of progress in implementing the plan or changes in direction may indicate lack of a champion or absence of a transition management team.When there is significant anxiety within the organization, this often means that people may lack the skills, vision, or expertise necessary to implement the change; this can be remedied by providing training or bringing in outside help.If the desired change is taking place but progress is slow or stalls, it may be that the wrong incentives (or possibly no incentives) are in place.

KEY FACTORS IN NAVAIR'S PROCESS IMPROVEMENT SUCCESS
The P-3C SSA and AV-8B organizations successfully raised their maturity levels and met their initial business objectives in just 24 to 30 months.Analysis of their stories yields a set of success factors that are shared by both organizations.The success factors listed below are organized using the components of the Beitler model to facilitate understanding of how these factors led to the changes taking place in the two NAVAIR organizations.

•
The NAVAIR organizations treated the process improvement effort as a project with dedicated resources, and they selected project leaders with strong project management skills.Without proper and adequate resources, change will not take place.
• Involvement of the people affected by the changes in formulating and implementing the changes was one of the key success factors in the NAVAIR efforts.PATs were composed of members of the engineering community from each phase of the product life cycle; PAT members accepted assignments to recruit and lead PIGs to develop policies, processes, templates, and standards that included stakeholder involvement.
• Leaders understood that process improvement requires a cultural change.In order for process improvement to take place and have the desired effect, the culture of the organization has to change.People must embrace the idea that process improvement is not extra work; it is how the work is to be done every day.Understanding and promoting requirements is a basic ingredient for successful process improvement.

COMMUNICATE WHY CHANGE IS NECESSARY AND WHAT THE OUTCOME SHOULD LOOK LIKE
• NAVAIR identified its business needs.Project leaders understood why they needed to change and what the consequences would be if they didn't.
• Organizational goals and policies were established and communicated.The leadership team communicated why the process improvements needed to take place and explicitly stated its expectations for the organization.

•
The NAVAIR groups began planning by first understanding their current practices, as well as identifying the gaps and overlaps between their current practices and the SW-CMM and TSP.With this understanding, they were better able to understand what they needed to do, and to appropriately tailor the SW-CMM model and TSP to fit their organizational needs.

PROVIDE A CHAMPION FOR THE CHANGE EFFORT
• Ensuring that there were champions at all levels of the organization who were credible to the people affected by the changes was a key factor in the NAVAIR efforts, and is a critical element in any change movement. • The organizations had strong, visible leadership.This was another critical element, since without continued and visible support by senior leaders, most process improvement efforts fail, even if there are peer-level champions.

CREATE A TRANSITION MANAGEMENT TEAM
• Formation of cross-functional Project Action Teams (PATs), Process Improvement Groups (PIGs), and Systems and Software Engineering Process Groups (SSEPGs) provided practical ideas for improvement and were able to recognize when various approaches were not working so that the organization's approach could change.
• Team-building and communications efforts spearheaded by the PIGs helped to build awareness of and support for the change efforts; with organization-wide buy-in for the improvement efforts, implementation of the new technologies was successful.

PROVIDE TRAINING IN NEW SKILLS, BEHAVIORS, AND VALUES
• Both NAVAIR organizations provided appropriate training for all participants in the change process.This training encompassed both the necessary skills for understanding and implementing the changes, as well as the skills and knowledge needed to perform the tasks required by the process itself.Process improvement teams were trained with the Introduction to CMM and Introduction to CMMI courses, and a tailored version of this material was provided for the engineers and support staff.Appropriate PSP training was provided for managers, engineers, and other support staff.Additional training was provided as needed to support the practices within each KPA.

•
The two organizations developed internal PSP/TSP capabilities by training PSP instructors and TSP coaches to support the internal rollout of these technologies.By receiving training in the technologies to be used in the process improvement activity, employees became more valuable to the organization and increased their personal capabilities.

•
The NAVAIR organizations utilized experts where appropriate (authorized PSP instructors, TSP coaches, and lead assessors/appraisers).Because organizations do not always have the capability or knowledge required to implement the desired changes, they should make use of experts when appropriate and advantageous.

PROVIDE REWARDS AND COMMUNICATE THE BENEFITS OF CHANGING
• With business needs identified and communicated to organization personnel, the people in both NAVAIR groups knew why process improvements were taking place and understood what the consequences would be if the improvements were not implemented.
• NAVAIR planned for continual assessment of the status of their TSP implementation.The two organizations analyzed and published project data to ensure that they were achieving the desired results.They utilized formal and informal assessments to determine the organizations' status as measured against the SW-CMM model.
• Measurable improvements provided incentive to continue with the process improvement efforts.Understanding the problem areas and seeing measurable progress increased momentum within the organization.

CONCLUSION
By using PSP, TSP, and the CMMI framework in conjunction, organizations can achieve a quick start to process improvement, and can accelerate and better sustain process improvement initiatives already underway.Both TSP and the CMMI framework are proven-effective ways for organizations to implement a successful process improvement effort.Because TSP also satisfies the majority of the CMMI project-level practices and can be readily adapted to support organizational-level practices, better process improvement results should be expected if both technologies are implemented in a complementary fashion.
Figure 1: Time Required to Move up Maturity Levels

Figure 1 :
Figure 1: Time Required to Move up Maturity Levels -intensive new development or maintenance − involves members and managers who are willing to participate in the pilot 4. Train affected managers (three days), engineers (two weeks), and support personnel (two days).

Figure 2 :
Figure 2: The CMMI Framework, TSP, and PSP are Complementary

Figure 3 :
Figure 3: TSP Coverage of the CMMI Framework

•
Feb. 2002 − began SW-CMM-based improvement effort, formed PIG • Mar.2002 − began PSP/TSP introduction • May 2002 − launched first TSP team • June 2002 − started PATs to develop processes • Jan. 2003 − reformed PATs focusing on development life cycle and the SW-CMM framework • May 2003 − launched second TSP team • May 2004 − reached Maturity Level 4 1 Final build testing was incomplete; projected number of test defects estimated to be 37 (1 per 1 KSLOC). 2 Many requirements changes throughout the program caused excessive replanning, dates were meaningless.SOFTWARE ENGINEERING INSTITUTE | 13

Table 1 :
P-3C Process Improvement Results To accomplish these goals it decided to use two different, but synergistic, process improvement technologies: the Earned Value Management System (EVMS) (which is also used in PSP/TSP measurements) and Capability Maturity Modeling (CMM).The EVMS is a management technique that integrates cost, schedule, and technical performance and is based on the Department of Defense (DoD) stringent, 32-point criteria [OSD 05].The AV-8B organization began using the EVMS in 1998.Capability milestones derived from implementing the EVMS included • documenting organizational standard processes for activities such as negotiating commitments • estimating, planning, and tracking all project work based on a standard work breakdown structure • assigning and communicating responsibilities • managing critical paths and resourced dependencies within and across projects • taking corrective actions based on established thresholds By May 2001, the AV-8B organization met its EVMS goals by achieving a DoD system certification [Pracchia 04].