Building the plan starts with its endpoint and working back from there.  The endpoint is when the customer has taken delivery AND begun to successfully use the air vehicle in support of their mission.  This cannot be stressed enough, and was perfectly captured in Alan Mulally's quip describing the commercial airplane business:  "Happy passengers, at their destination, for a profit."  Something similar could be said of the customer missions for defense and space products.  If the customer's ultimate reason for buying the air vehicle in the first place is actually and completely being supported by it in service, then the initial goal of the full scale engineering development part of the program has been accomplished.  So, the WBS should start with that point, and it has a name:

​

Initial Operational Capability, or IOC

​

Before the program begins, an agreement must be reached with the customer as to both a date and a clear definition of what IOC looks like.  That's the stake in the ground.

​

From there, everything that must be accomplished to get from program authorization to IOC needs to be described and put in a structured list that explains which tasks have to be accomplished in sequence (task dependencies).  Any notes on special requirements for each task should be described.  The document that is produced is called the Work Breakdown Structure, or WBS.

​

The WBS is then used as the basis to build two other documents.  One is the schedule, the other is the Program Management Plan, or PMP.  Essentially, the PMP is a description of the who, when, and where for each element in the schedule.  The schedule and the PMP are built in a series of passes, each in increasing levels of detail.  At the very top level or first pass, is the Tier 0 schedule.  For the WBS, an initial cut at inhouse versus sourced work is described.  This may have some aspirational aspects.  A big question will be whether or not the needed talent and resources exist or can be created either internally or by would-be suppliers such that the schedule can be met.

 

Again, the schedule is everything.  This cannot be said too many times.  Schedules are sacrosanct.  They are the key to managing costs and performance.  Budgets are not.  Budgets are not.  Budgets are not.  Maybe we should say that again.  Schedules are not just everything, they are the only thing.  Stay on schedule and everything else will fall into place.  Get behind, and everything starts to fall apart.  Everyone must make their deliverables, and they have to be of an acceptable quality, per the schedule requirements.

​

To make things come together, it is important that the PMP identify the actual names of key people.  This includes both management and technical leads.  Its even a good idea to have some meetings with the customer and introduce to them the individuals identified in the PMP and establish who their counterparts are on the customer side, so that appropriate consultations can be had as the program progresses.  The key to a having a happy customer at IOC is no surprises on the day of the IOC celebration.  

 

The theme to keep in mind is that people link the system.  The better those links work, the better the chances are that IOC will happen on time, and that the customer will be happy with the result.  It was in recognition of this that the theme developed for the 777 program was "Working Together," which was also used as the name of WA001, the prototype plane used for first flight and a significant portion of the flight test program.

​

This also gets us to a reality on day on of the program after board authorization is received to go ahead with it.  On day one, every last item on the schedule feels like it is late.  Everything is flaming red, and that's ok.  If everyone starts with that sense of clarity about the schedule, then there is actually a pretty good chance of making IOC on time and with a happy customer.

​

All of this means that the plan has to be realistic.  If the major tasks from the WBS are assigned to capable performers in the PMP, and there is a good plan for getting to where the identified task owners can perform the work, then all will be well.  This worked pretty well on all Boeing programs from the Model 299 through 777.  It fell completely apart on 787.  On 787 many of the task assignments were assigned to people and suppliers who did not have the ability to deliver per the schedule, and senior management chose to pretend that was not the case and do nothing about it.  That approach must never be repeated. 

 

The problem on the tanker was a bit different.  There, a concept was sold to the customer and a commitment to go ahead with an FSED program, including full production, without having done the work up front to validate the feasibility of the concept.  It is always better to under promise and over deliver instead of the other way around.  These bad experiences should be kept in mind on any new program so as to avoid repeating either mistake.  If the lessons prove to have been learned, then maybe the fiascos can be chalked up to good learning experiences, except of course for what happened on 737, but that is beyond the scope of this commentary.