My good friend and colleague from the Flight Director’s office, Jeff Bantle, left the agency several years ago to head up Lockheed-Martin’s Presidential Helicopter project. He now has a great presentation talk about how incrementally added requirements can sink a project. I suppose many folks could tell a similar story about a home renovation project that got out of hand. Indeed, one of the first lessons at project managers’ school is the need to control requirements. A successful project always has a concise, well considered, thorough list of what must be done to be successful, and a successful project manager is one that manages to avoid “requirements creep”. (Couldn’t we just wallpaper the kids’ bathroom while we are redoing their bedroom? How about added a comm system to the helicopter that can communicate anywhere with anybody?).
Put in simple terms, if you want to be successful, it is good to have the “must do” list of things and not add to it half way through. While I can’t cite specific studies, my observation of several major NASA projects that have gotten in trouble over the years shows a high correlation with new, added, late, or poorly defined requirements which caused technical issues, increased the costs, and delayed the schedule. Put simply, a good program manager has got to have the gumption to just say no to changes in requirements – even when they are really good ideas.
I have frequently quoted the old adage: “given unlimited resources and unlimited schedule, great engineers will produce exactly nothing.” That is because we engineers can’t leave it alone; there is always a slightly better way to do it if we just junk the design we have in hand and start with a clean sheet of paper. Successful program and project management requires many talents and abilities, but critical among them is having a leader who can just say no to creeping requirements.
So the Space Shuttle Program – lead by some really terrific managers over the years – really clamped on to the notion that having good, well defined, concise requirements was absolutely necessary and new, nice-to-have ideas were very carefully scrutinized and generally turned down. Part of that is due to financial concerns – a topic for the next blog post in this series. But mostly, that culture was inculcated because requirements control is the cornerstone of excellent program management.
Many people inside the shuttle program – as well as hordes of armchair commentators – never understood this. The need to keep strict division between doing what was mandatory, what must be done – the ‘requirements’ – and those really good ideas that might make the system better, safer, more economical, etc., is difficult. And all experienced project managers have been burned by “good ideas” that cost more money than expected, have unintended consequences, and frequently just didn’t work out.
So, over time, the shuttle program did some things – like upgrading the Space Shuttle Main Engines – and did not do other things – like building advanced solid rocket boosters or liquid strap on boosters. Working on a real program with real deadlines and a real budget means that you have to choose. Mostly, shuttle program managers over the years just had to say no.
In space repair of the shuttle thermal protection tiles was considered a requirement at the start of the program in the 1970’s. The tiles were fragile and could be easily damaged. A great deal of money, time, and effort was spent in trying to develop a repair material and techniques that could be applied in space. It didn’t work out. Technology wasn’t there. The requirement was deleted. After the Columbia accident, we reinstituted tile repair as a requirement. Many experts reminded us that repair was a failure before and we should avoid repeating the mistakes of 30 years earlier. But after 30 years, materials science had advanced enough so that the project was successful. Successful at great cost, operational complexity and overhead, and significant schedule impact. Was it worth it? Tile repair plus other improved capabilities gave us the confidence to fly another 20 shuttle flights. We never needed to repair a tile in space, of course.
So every item, every requirement, every suggestion was reviewed – and repeatedly reviewed as the financial constraints tightened – and the phrase “is this really a requirement” came to mean, ‘is this really something that we have to do or can we argue our way out of doing it’. So “requirements” became a tyranny. Justifying something as a requirement became a herculean task. For all but the most obvious mandatory changes, the leadership just said no in the name of “good program management” in a “mature program”. There is another topic to discuss in that last sentence too.
And so the day came, when an operation that many people wanted, and that I championed, one that bears directly on the loss of Columbia, was denied because “nobody has a requirement for that”.
It probably won’t have helped anyway.
The story will continue.
Originally posted Oct. 7, 2012 on Wayne Hale’s Blog.
