Program management in a multiple IPT environment


The objective of this paper is to highlight the benefits of a process-driven program and structuring the program around multiple IPTs. The paper relates how the PMBOK® Program Management methods and Systems Engineering processes were tailored and implemented by the prime contractor to achieve exceptional contractor performance ratings on a Department of Defense Aircraft Maintenance Training System Concurrency contract for the C-17 Globemaster III Aircraft.

Program Environment

A cornerstone in winning this contract was the proposed plan to establish the Program Office and work site close to the U.S. Air Force Training Detachment Team (TDT) located at Charleston Air Force Base, South Carolina. This created the unique challenges associated with ramping up a new, state-of-the-art facility and all new staffing while performing Current Engineering Development on a very aggressive schedule. The site, renovations included offices, conference rooms, cubicles, T1 lines, and servers.

Contract Purpose and Type

The purpose of the contract is to provide MTDs with a high degree of fidelity that will provide training for maintenance personnel and certify personnel to perform maintenance on the aircraft without taking an aircraft out of service. This maintenance training concept increases the aircraft’s mission availability. The contract is a cost-plus-award-fee type of contract. A major requirement of the contract is to provide MTDs that are concurrent with the aircraft configuration 90 days prior to the aircraft delivery. In order to keep the trainer configuration concurrent with the aircraft configuration, a very close relationship had to be developed with Boeing Aircraft Company, the aircraft manufacturer. This relationship allows us to be aware of planned changes and upgrades to the aircraft before they are implemented on the aircraft. This process of maintaining the proper configuration is referred to as “Concurrent Engineering.” As you may imagine, concurrent engineering has several unique configuration management challenges that I will discuss later.

Contract Scope

The deliverables for this contract are 11 different types of MTDs. Each MTD replicates a major portion of the C-17 aircraft and has the necessary hardware and software required to simulate selected maintenance tasks with a high degree of fidelity. The current suite of 11 trainers is capable of training and certifying over 1,500 maintenance tasks when performed in accordance with the aircraft Technical Order (TO). The portions of the aircraft represented by the trainers are the cockpit, main and forward landing gears, flight control surfaces, cargo door and ramp, fuel tanks and air refueling surfaces and controls, air conditioning, auxiliary power unit, and complete engines on pylons. These MTDs are capable of training and certifying systems operational checkouts, fault isolations, and remove-and-replace types of maintenance tasks.

Program IPT Organization

The program organization was structured using Integrated Product and Process Development (IPPD) IPTs. The MTDs were categorized as powered or nonpowered and grouped into major technical functional areas based on mechanical, electrical, and software complexity. This allowed the 11 MTDs to be assigned to four separate Design Groups (DGs) referred to as DG1 through DG4. Each DG had full responsibility for delivering the MTD(s) assigned to its group.

Exhibit 1. C17 Aircraft Cockpit Maintenance Trainer

C17 Aircraft Cockpit Maintenance Trainer

Exhibit 2. C17 Aircraft Automatic Flight Control Systems Maintenance Trainer

C17 Aircraft Automatic Flight Control Systems Maintenance Trainer

Exhibit 3. C17 Aircraft Engine Cowling Maintenance Trainer

C17 Aircraft Engine Cowling Maintenance Trainer

Exhibit 4. C17 Aircraft Forward and Main Landing Gear Maintenance Trainer

C17 Aircraft Forward and Main Landing Gear Maintenance Trainer

Exhibit 5. C17 Aircraft Air Conditioning Maintenance Trainer

C17 Aircraft Air Conditioning Maintenance Trainer

Exhibit 6. C17 Aircraft Cargo Door and Ramp Maintenance Trainer

C17 Aircraft Cargo Door and Ramp Maintenance Trainer

Exhibit 7. C17 Aircraft Air Refueling Receptacle Maintenance Trainer

C17 Aircraft Air Refueling Receptacle Maintenance Trainer

Exhibit 8. C17 Aircraft Engine Maintenance Trainer

C17 Aircraft Engine Maintenance Trainer

Exhibit 9. C17 Aircraft Auxiliary Power Unit Maintenance Trainer

C17 Aircraft Auxiliary Power Unit Maintenance Trainer

Exhibit 10. C17 Aircraft Maintenance Systems Trainer

C17 Aircraft Maintenance Systems Trainer

The DG Leader became the Project Manager (PM) for the DG and held the title of Senior Systems Engineer. The PM addressed schedule, personnel staffing, and was the Cost Account Manager (CAM) for each trainer assigned to the group. Each IPT was composed of several systems engineers, as well as electrical, mechanical, and software engineers as required, depending on the complexity of the trainer. In addition, each DG was provided with Subject Mater Expert(s) (SMEs) familiar with the training tasks taught on the MTDs assigned to each group. Finally, each IPT had an Air Force member(s) assigned to it. The Air Force member was the end user of the trainers and had specific needs that wanted to have implemented on the trainers to facilitate training. The Air Force members were provided their own office area with networked computers. This gave them full access to all analysis and presentation data as it was being prepared for formal reviews. The showed boxes on the organization chart represent the Air Force member on the team. Having the customer present on a real-time basis provided quick resolution to ambiguous requirements.

Exhibit 11. C17 Aircraft Fuel Systems Maintenance Trainer

C17 Aircraft Fuel Systems Maintenance Trainer

Program Management Performance and Customer Satisfaction

The customer made written evaluations of the program every month and used these reports to determine a quarterly grade. These quarterly reports and grades were used to arrive at an annual rating, which determined the percentage of the available award fee that would be awarded on an annual basis. The program has achieved a rating of greater than 90% the first two years the program. When your program or project receives a customer satisfaction rating of greater than 90%, it is an indication that you are doing something right.

We feel that this exceptional performance is the direct result of setting up IPTs as the main organizational structure. This organization process was kicked off with a two-day on-site meeting attended by all ESI and all government personnel assigned to the program. The Government personnel included the Program Manager, representatives from Contracts, Headquarters Training Command, and the TDT from Charleston Air Force Base, and the Project Engineers. The meeting was also attended by representatives from Boeing. One of the main themes of the presentation was to ensure completely open communications and that everyone on the program had unrestricted access to information. There were no secrets. Everyone had access to our network and could review data in real time. Another benefit of the IPT was realized by having the customer as team members. TDT personnel are the end users of the trainers. By having them as team members, we were able to clarify and tailor ambiguous requirements as soon as they were identified. The open communications extended not only to the on-site Air Force members but also to the government program offices and supporting agencies. This ongoing real-time communications made the program reviews “nonevents.” Basically, there were no surprises when we conducted the 11 Systems Requirements Reviews and the 11 System Design Reviews followed by 11 Preliminary Design and 11 Critical Design reviews. This was evident by the low number of generated action items.

Exhibit 12. Organization Chart

Organization Chart

Process-Driven Program

The importance of having processes in place cannot be overemphasized. When you have four DGs developing new designs for 11 different trainers—where some designs were common across different trainers and others were unique to each trainer—common processes become a necessity. Since this was a completely new contract at a new site with 90% of the personnel new to the company, we were not tightly held to the existing Systems Engineering processes in place at our home plant. However, they were used as a starting point to be tailored specifically for this contract. To create these newly tailored processes, a special Systems Engineering Integration Team (SEIT) was formed. The SEIT was staffed with senior systems engineering personnel with a background in trainer and simulation modifications. Each process was written and presented to the DG Leaders for comments and approval. The initial systems engineering processes that were developed for the program are System Requirements Analysis, System Design Review (SDR), Preliminary Design Review (PDR), and Critical Design Review (CDR). The system requirements analysis and the system design analysis processes were tailored the most. The Systems Requirements Analysis Process was composed of three embedded analyses: Technical Order Analysis, Aircraft Fidelity Analysis, and Aircraft Change Analysis. The System Design analysis and Review process was divided into Functional Partitioning, Requirements Allocation, and Top-Level Design Solution. The Preliminary Design Review and the Critical Design Review processes were typical of a development program. Each process had an entrance and exit criterion. In addition to these front-end processes, new processes were developed for CADCAM, configuration management, software development, testing, estimating, and purchasing. This was a tremendous effort, but we believed that it was necessary to steer the four DGs and manage the program. As you may suspect after the first time through the processes, each was reviewed and modified to improve its effectiveness.

Requirements Traceability (RT)

When you consider the 11 different trainers and 1,500 tasks all being analyzed and upgraded to different requirements at different times, you can get a feel for Concurrent Engineering. As you might suspect, Concurrent Engineering creates a major configuration management challenge. One of the benefits of a detailed requirements traceability tool was that it helped to control scope creep and requirement drift. As new requirements were defined for each block upgrade, these requirements were entered into a relational database. The Dynamic Object-Oriented Requirements System (DOORS) is the tool being used. The RT tool is being used to track the requirements and develop test criteria for each of the 11 trainers for each block upgrade. While each new block upgrade requirement was being defined, the previous block upgrade requirements were being implemented via PDRs and CDRs, etc. There is a tendency to want to continuously move the new requirements back into the previous block upgrade work. However, if this were done, the trainer would never be delivered because there is always another block upgrade in progress creating new requirements. It can be compared to waiting for the next upgraded computer to be released before you buy your first one.

Leadership Personnel

The DG Leaders are the first line of supervision and have the biggest impact on the overall performance of the program. In addition to the soft personnel supervision skills, the DG Leaders must be capable of performing CAM duties and schedule functions. Each DG was given independent control over his team and budget. Because the contract is a cost-plus type, a major emphasis was placed on measuring cost, schedule, and technical performance. Instead of using major milestones to determine progress and potentially discovering problems too late, a more detailed method was put in place. We referred to it as inchstones. It is based on the premise that all work can be broken down into small, measurable increments. The effort required to track and report status and cost at the very lowest level of work can be a burden to the CAM. But the process that was developed shifted the progress reporting to the person responsible for the work. This information was captured on the network, and the CAM could access it any time to establish his overall performance. This provided the DG with real-time status, in turn allowing him to address problem areas as they developed.

Customer Relations

Establishing a credible relationship with your customer is one of the single most important factors to ensure success. This can only be achieved with totally open communications. The C-17 MTS Program set the tone for this to happen when it held the two-day IPT training, which included all of the government program personnel. This program-wide understanding that we were all on the same team with the same goals to deliver trainers on schedule was a tremendous help in encouraging lower-level team members, both on the government and the contractor sides, to speak freely about their concerns, and help resolve problem areas.

Lessons Learned

The program is now over two years old and we have delivered several trainers within budget and ahead of schedule. However, there is always room for improvement. The following are some of the key areas that we feel are important:

Co-location of the DG leader and his complete design group: This was a major factor that kept all the members of the group current on the team’s progress.

Communications: Each month all personnel on the program (~200 now) were briefed on the overall program performance by the program manager. It is very important that the DGs communicate regularly to prevent the “Smoke Stack” effect, where each group solves the same problem differently.

Leadership Positions: The selection of capable DG leaders and other IPT leaders is critical for success.

Process Driven: The processes are the backbone of the program. One of the problems we had is each DG started to drift away from the initial process. This was usually the result of the DG taking proactive steps to head off a cost or schedule problem. The problem was that each DG handled the situation differently. This could be looked at as a shot coming of the existing process, since it did not address workarounds. Each process should be reviewed by the users periodically for efficiency, and their comments should be forwarded to the Systems Engineering Integration Team (SEIT).

I would like to acknowledge Donna Cook for her assistance in preparing this paper.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA