Mostly on-the-job training and internal mentoring
rework (less than 25%) enabled by an architecture-first focus, an iterative development process, an enlightened and open-minded customer, and the use of modern environments, languages, and tools.
Overall, the Common Subsystem subsidized much of the groundwork for the PDS and STRATCOM subsystems—namely, the process definition, the tools, and the reusable architecture primitives. This investment paid significant returns on the subsequent subsystems, in which productivity and quality improved. This is the economic expectation of a mature software process such as that developed and evolved on CCPDS-R.
CCPDS-R adhered to DOD-STD-2167A and delivered all the required contract deliverable documents in the Common Subsystem. As the stakeholders gained experience in the new iterative process and demonstration-based reviews, the pressure to deliver ineffective documentation was reduced. The customer and user were far more concerned with the evolving capability than they were with delivered paper.
One of the primary (and subtle) improvements that was enabled by the CCPDS-R software approach was the teamwork between the customer, user, and contractor. Continuous bartering, negotiation, and interpretation of the contract deliverables were productive in making real progress and ensuring that each phase of the life cycle resulted in a win-win situation for all stakeholders.
The level of requirements volatility was moderate, with numerous user interface changes, missile warning algorithm changes, and other requirements changes accommodated throughout the project. On the design side, TRW also incorporated numerous architectural changes, technology insertions, and other design changes from the original technical proposal. Requirements were continuously evolved with designs and were stabilized after CDR as test-to baselines. There was one late, major contract scope change, which was normalized out of most of the data in this case study to provide a more readable presentation. This change occurred around month 35 and involved a complete overhaul of the input message formats into the system. With the intense focus on performance, many components were built with some tight dependencies on the input message formats. Unlike many of the architectural changes, algorithm changes, and display changes, this sort of change was simply not foreseen. Consequently, performance optimizations during design sacrificed some ease of changeability in the message formats. The breakage caused by this change was not as localized as it could have been but was straightforwardly absorbed with predictable performance. The late uptick in rework trends (maintenance changes depicted in Figure D-14) was a result of incorporating this major change. All stakeholders were pleased with the resulting solution.
The requirements volatility described above would have killed most projects using a conventional management approach. CCPDS-R maintained good project performance and nonadversarial relationships among stakeholders throughout the life cycle while continuously absorbing a moderate level of requirements volatility. While this is very difficult to quantify and qualify, I think it was the most significant accomplishment of the entire project.
As discussed in Chapter 15, successful projects tend to provide a balance across the i breadth of technologies required. Too great a focus on any technology will not result in success. A balanced effort across the majority of the technologies is necessary to succeed on a large project. CCPDS-R is a perfect example. There was a heavy investment in developing the right process, integrating tools into an effective environment, and developing the architecture components necessary to implement a demonstration-based approach. All stakeholders (developers, managers, customers, and users) were engaged in nonadversarial relationships and working toward a common set of goals.
The CCPDS-R team was successful all along the way. While many people and organizations contributed to the project, the following individuals had a major impact on the overall management approach: Tom Bostelaar, Charles Grauling, Tom Herman, Terry Krupp, Steve Patay, Patti Shishido, and Mike Springman (all from TRW); Gerry LaCroix (Mitre); Paul Heartquist and Bill Wenninger (U.S. Air Force). The project management skill of Don Andres, at TRW, was critical to executing a new software process with a lot of good ideas and to achieving success under the game conditions of a large-scale, nationally important project with tremendous scrutiny from multiple government organizations.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.