I was asked in a press conference once if ‘schedule pressure’ had affected my decision for a launch. I wanted to throw the reporter out of the room, but I liked my job. Schedule pressure affecting a decision? Instead of a tirade, it was clear the reporter needed a little refresher in the basics of Project Management 101. Here it is:
Work scope. Budget. Schedule. Magic, huh?
Numerous times in the Shuttle program we were accused of letting the schedule affect some decision made. News flash—of course it did! What the reporter was really asking was is if the schedule made me make an unsafe decision. If he had actually asked me that way, then I would have thrown him out.
My job, and indeed the jobs of ALL the great people working so hard to put our astronauts into orbit, was to “get it done, safely.” No exceptions, no excuses for anything less. I found that the suggestion that it was otherwise to be appalling and personally offensive. But we heard it from time to time, and not just from the press. Indeed, to their defense, they had to ask it. Doesn’t make it any more friendly, but it was their job to push for answers. I much preferred the phrase ‘schedule awareness’, and that was how I answered the question. Schedules were just as real as money and scope. But none of the three trumped safety.
Of course we got the “how much did it cost?” question, and much more frequently than the safety question, fortunately. I always liked the cost question because that never drove my decisions, much to the dismay of our program office. My own view was that we had enough money to get the work done to the agreed upon schedule, and a little more. After all, the vast majority of our costs at KSC were labor, so we met the schedule based on the size of the workforce driven by allotted budget. Magic again. More money would have permitted more people working more shifts no doubt, but absent that, we got by with what we had.
Work scope was driven by essentially three factors. There were the normal systems tests, checkouts, maintenance, etc., that were required just to maintain a healthy, functioning program. There was scope, driven by failures and therefore some needed repair or replacement. And then there were system upgrades over the life of the program to modernize and improve safety margins. These could range from relatively minor enhancements, such as upgrades to the slidewire emergency egress system, to major flight hardware improvements, such as upgrades to the Space Shuttle Main Engines aimed at reducing the chances of a shutdown during ascent.
It was during these debates when scope growth was weighed against cost and schedule. And—virtually every upgrade decision made was based on an improvement to some safety margin, or it wouldn’t have made it to the table for discussion in the first place. Some ‘operability’ upgrades were accepted, but I would argue that these had their roots in improving safety by allowing better and/or easier user-to-system interaction.
Project Management 101. Simple. But in manned spaceflight, Safety was the overarching requirement—inescapable and thoroughly embraced. It wasn’t ‘the fourth factor’—it was the paramount factor, not often taught in the typical PM 101 course.