Today I came across an interesting blog article on . It's about a comment made by Admiral Gehman (Head of the ) regarding Space Shuttle Management at NASA. I've copied the key part below:

The program manager essentially has four areas to trade. The first one is money. Obviously, he can go get more money if he falls behind schedule. If he runs into technical difficulties or something goes wrong, he can go ask for more money. The second one is quantity.  The third one is performance margin. If you are in trouble with your program, and it isn’t working, you shave the performance. You shave the safety margin. You shave the margins.  The fourth one is time. If you are out of money, and you’re running into technical problems, or you need more time to solve a margin problem, you spread the program out, take more time. These are the four things that a program manager has. If you are a program manager for the shuttle, the option of quantity is eliminated. There are only four shuttles. You’re not going to buy any more. What you got is what you got. If money is being held constant, which it is—they’re on a fixed budget, and I’ll get into that later—then if you run into some kind of problem with your program, you can only trade time and margin. If somebody is making you stick to a rigid time schedule, then you’ve only got one thing left, and that’s margin. By margin, I mean either redundancy—making something 1.5 times stronger than it needs to be instead of 1.7 times stronger than it needs to be—or testing it twice instead of five times. That’s what I mean by margin.

What has this got to do with IT projects?

Well, a lot actually. In IT projects we are always up against the same sort of constraints and in IT projects there are the same four areas that can be traded:

• Time

• The timeframe for the project, including testing and documentation.

• Money

• The budget for the project including overtime.

• Quality

• The actual 'fit for purpose' result of the project.

• Scope

• What needs to be achieved within the time frame and with the money provided.

All four areas are linked and a change in one has an impact on the other three, for example, Reducing the time but keeping the scope the same will impact the money and quality side of things whereas increasing the quality either increases the time (due to the additional validation tests) or reduces the scope (to ensure that what is delivered is as accurate as possible).

Now, on most IT projects the two things that are set in stone is the budget and the time frame.
All too often the time frame is arbitrary and so not related to any valid reason for having said time frame. The delivery deadline is generally picked and handed down simply because a senior manager wants to see something by date x and these dates are normally tied to budget cycles rather than to the complexity of the work.

On the flip side the budget is often set at the start of the project and long before the software and hardware requirements have been thought through. This does leads to cases where additional licences are required and yet cannot be purchased because the budget has been set and so workarounds have to be developed and this affects the quality and time side of the project.

Many projects are presented that have the time (deadline) and budget set.
In many the scope as well has been pre-determined, even more often the scope will grow during the project.
Managers/clients will want to shoehorn things into the project that were originally not in the scope.
This is normally seen by management as a way of saving money due to them adding more to the scope but not increasing the time or budget allocated.
Even more often, during the project it is found that a dependency on a system not in scope is affected by a system that is in scope and so suddenly the not-in-scope system has to be added to the scope.

This means that the only thing that we, as project staff, IT admins, consultants, etc have any actual control over is the quality and the only control we have is to reduce the quality of the work in order to meet the demands of the time, budget and scope.

Even more often the time factor becomes such a pressing issue that overtime is demanded/pushed to such an extent that quality is automatically sacrificed on the altar of  'getting it done' and, of course, as I said above, you can't change one thing in isolation without a knock on effect of the other three. The quality decreasing will have an impact on the time as things need to be fixed, the budget as more staff/more overtime is needed and the scope as things are sometimes dropped in order to meet the deadline again.

Absolutely none of this is news and I suspect everyone who reads this and works on some sort of IT project is nodding theirs heads because they have been there yet why do we, as IT professionals keep getting caught in the same trap? It's not even as if anything I've written here is new - Tony Collins in 1999 which goes into some detail about several major IT disasters. 1999 was almost 14 years ago so why do we still have the same mistakes?

It is long past time that IT became a traditional engineering discipline and that engineers working on projects spoke up when a scope, schedule or budget was obviously written in fantasy land. Let's start doing projects once and doing them right.

wrote a book