The core team of the CCPDS-R software organization was established early in the concept definition phase to deal explicitly with the important 20% of the software engineering activities that had a high return on investment. In particular, this team of fewer than 10 individuals was responsible for the following:
1. Developing the highest leverage components (mostly within the NAS CSCI). These components resolved many of the difficult computer science issues such as real-time scheduling, interprocess communications, run-time configuration management, error processing, and distributed systems programming. As a result of encapsulating these complex issues in a small number of high-leverage components, the mainstream components were simpler and far less dependent on expert personnel.
2. Setting the standards and procedures for design walkthroughs and software artifacts. In general, the core team represented the frontline pioneers for most of the software activities. This team was generally the first team to conduct any given project workflow and built the first version of most artifacts. Consequently, the core team was intimately involved with setting precedent, whether it was the standards for a given activity or the format/ content of a given artifact.
3. Disseminating the culture throughout the software organization. The core team was truly a single, tight-knit team during the inception phase and for most of the elaboration phase. As the process and architecture stabilized, the team started to migrate, with several of its members taking on technical leadership roles on the various development and assessment teams. During construction and transition, a few members of the core team still maintained the architecture integrity across the entire project. However, there was also a set of globally minded individuals with strong relationships to the architecture team who became immersed in other areas of development and assessment. These team and personnel transitions proved to be an invaluable mechanism for maintaining a common culture.
This core team concept is similar in purpose to the architecture team described in Section 11.2.
During the mid-1980s, software expertise was at a premium. TRW software integration business and the general software industry were growing rapidly. Both TRW management and the government customer were acutely concerned about recruiting and retaining a stable, quality software team for the CCPDS-R project. The project also needed to obtain and develop as much Ada experience as possible, and Ada experience was a scarce resource during the early stages of CCPDS-R. TRW proposed an innovative profit sharing approach to enhance the project's ability to attract and retain a complementary team.
The basic premise of the CCPDS-R award fee flowdown plan was that employees would share in the profitability of the project. (Award fees are contract payments over and above the cost basis. They are tied to project performance against predefined criteria.) TRW management agreed to allocate a substantial portion of the award fee pool at each major milestone to be given directly to project employees. This additional compensation was to be distributed to the individuals based on their relative contribution and their longevity on the project. The implementation of the award fee flowdown plan was intended to achieve the following objectives:
• Reward the entire team for excellent project performance
• Reward different peer groups relative to their overall contribution
• Substantially reward the top performers in every peer group
• Minimize attrition of good people
The resulting plan was fairly complex but straightforward to implement. In the end, this plan achieved its goals in minimizing attrition, especially in the early phases of the life cycle, when the loss of key people could have been devastating. In retrospect, the one flaw in the plan was that the early award fees (at PDR and CDR) were far less substantial than the later award fees. As a result, the teams responsible for the construction and transition phases received more award fee flowdown than did the teams working on the inception and elaboration phases. This was the basic operational concept of the plan:
• Management defined the various peer groups (systems engineering, software engineering, business administration, and administration).
• Every 6 months, the people within each peer group ranked one another with respect to their contribution to the project. The manager of each peer group also ranked the entire team. The manager compiled the results into a global performance ranking of the peer group.
• Each award fee was determined by the customer at certain major milestones. Half of each award fee pool was distributed to project employees.
• The algorithm for distributions to project employees was fairly simple. The general range of additional compensation relative to each employee's salary was about 2% to 10% each year.
• The distribution to each peer group was made relative to the average salary and total number of people within the group. The differences in employees' salaries within each group defined the relative differences in what was expected of the employees in terms of contributions toward overall project success.
• The distribution within a peer group had two parts. Half of the total peer group pool was distributed equally among all members. The other half was distributed to the top performers within the peer group as defined by the group's self-ranking. Management had some discretion in the amounts and ranges.
The true impact of this award fee flowdown plan is hard to determine. I think it made a difference in the overall teamwork and in retaining the critical people. The peer rankings worked well in discriminating the top performers. While there were always a few surprises, the peer rankings matched management perceptions pretty closely. The end results of CCPDS-R speak for themselves. Overall, TRW shared a little less than 10% of its overall profit with project employees. CCPDS-R was a very profitable project for TRW and a good value for the Air Force customer. The return on this investment would be considered very high by all stakeholders.
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.