Project Management Book

One day you're happily sitting at your desk when your boss walks up to you and utters some rather spine chilling words: "I have an opportunity for you."

It transpires that your company wants to write an all singing, all dancing new IT system that will replace all the existing systems and will run the company's whole business. Your opportunity is to manage the project. Having overcome your first reaction - to run like heck - you take a look and you realise that, at the extremes, the project could be done in two ways.

At one extreme you could establish a single, three year long project that would at the end of three years deliver the new system: the "big bang" approach.

But you realise it could be done another way: as a series of releases. Release 1 would, after 8 months, deliver a subset of the eventual functionality but would be installed and used in anger. Six months later Release 2 comes along and bolts on more function and by Release 4 everything will have been delivered.

Which might be the better approach? As always, it depends, but what might be the pros and cons of each.

These are the arguments usually advanced in favour of the 3 year long big bang approach:

• It's more visible
• More focus from senior management because it's big
• Only one implementation, one disruption to the business
• Only one tranche of training
• Plenty of time to do it properly
• More holistic approach to design
• Nice clean switch from old to new
• No temporary bridges from old to new

  If you're not involved in software projects: The next three pages relate specifically to software development. To skip these three pages go here or see the index

• Everything being done only once so lower cost
• If it's going wrong, plenty of time to get out before the end

And for the release approach these arguments are usually advanced:

• Better team motivation
• Less spent on project control
• Greater flexibility for senior management
• Learning from experience
• Easier to handle change
• Less business risk: evolution not revolution
• Less waste on never-used functionality
• Easier to manage four small projects than one large one
• Easier to commit people for eight months than for three years
• Fewer people leave during a release project than during the big bang project
• Earlier benefits realisation
• Lower cost overall (yes, it's on both lists)

Let's look at a few of these arguments in favour of releases in more detail.

Better team motivation. If you have ever worked on a long project you will know that at the beginning the team members tend to think: "We've got three years to do this, bags of time." And this lack of urgency can mean that not a lot gets done for several months. But if the end date is only eight months away there's much more natural urgency and the team think: "We haven't got long, we'd better get on with it."

Less spent on project control. The larger the project the greater the percentage of its budget will need to be spent on controlling it. So four smaller release projects may well in total spend less on project control than one large big bang project.

Greater flexibility for senior management. Imagine you are three quarters of the way through a big bang project. It's growing like Topsy and getting far too expensive. Can you, this far through, descope the project and save money? Probably not. Suppose you are having an eight bedroom mansion designed and built for you, it's three quarters built but getting far too expensive. Can you descope to a two bedroom bungalow and save money? No, that will cost you even more at this stage.

The same is true when you're building IT systems - beyond a certain point descoping will increase the cost not reduce it - not to mention the money wasted on what has been built that must now be thrown away. But with a release strategy, at the beginning of Release 4 senior management could simply decide not to do Release 4 and save its whole budget. Good news for the company but bad news if you happen to be the person whose need was going to satisfied by Release 4. There is always a plus and a minus, but at least with releases you get the choice.

Learning from experience. Release 1 goes live but the users conclude it isn't quite what they wanted. You can learn from that and adjust in subsequent releases. If the users had that same reaction when the big bang went live you have a bit of a problem. Equally, during Release 1 you will learn in project management terms and each subsequent release will be managed more efficiently and effectively than its predecessor, one hopes.

Easier to handle change. Suppose at the start of a three year long big bang project you define in great detail the business requirements that the project will satisfy. Obviously, over the three years a lot of those requirements will change - and change again, and change again. The longer the project the greater the percentage of its budget will be spent changing things that have been wholly or partially completed (see Fig 1). In fact some projects are so long they drop off the end of the chart: they never finish - so much has changed out there in the real world that the project is no longer relevant and it gets cancelled.

Figure 1: Percentage of effort spent on change in a long project

With releases you can much more readily react to changing requirements (see Fig 2). Yes, during Release 1 there will be some change to its requirements. But the real benefit is that at the start of Release 2 you define its requirements as the world then is, not as it was six months ago. And at the beginning of Release 3 you define its requirements as the world is then, not as it was a year ago. Release 3 may also be able to exploit technology that wasn't available a year ago - it's much more difficult to adopt new technology half way through a big bang. With releases you'll almost certainly spend less on change.

Figure 2: Overall less spent on change

As an aside, if you are at the start of a large IT project and your best guess is that 35% of your budget will be spent because requirements change as you go along, would you view the project as high, medium or low risk? Experienced project managers would probably say very high risk. Why? If you expect that much change you'll probably get more than that anyway and you may find that so much is changing all over the place throughout the project that it becomes very difficult to keep everything synchronised and you run the risk of chaos breaking out. Even if 35% of the budget is set aside to cover the cost of the change the change could still cause the project to get out of control. A good defence could well be to break the project into releases. If you only spend 10% - 15% or so of your budget because things change as you go along, you shouldn't have too much of a problem controlling change. We will cover change more fully in a later chapter.

Of course, with releases some of the cost of Release 3 could be re-engineering what had been delivered in Release 1, to improve it based on experience of use. This is either good news (you're improving things) or bad news (it costs you) depending upon your point of view.

Less business risk. When (if) the big bang project finally finishes, cutting over the company's whole operation to the new system could represent a huge business risk - what if it doesn't work? Cutting over a bit at a time at the end of each release may help the Directors sleep a little easier.

Less waste on never-used functionality. Imagine you are a business manager and at the beginning of a three year long big bang project you are asked: "What would you like this system to do for you in three years' time?" Your reaction will be: "Three years' time! Well, we'll definitely need this and this, almost certainly this, probably these things, maybe this and we'd better put these things in just in case..." If you ever see a big bang delivered, albeit late and over budget, and you do a hard-nosed audit of which functions are being used and which are not being used you may be horrified to discover just how much of what you have delivered is never used. That is a huge waste of money. The world never turns out the way you thought it would three years ago.

Easier to manage four small projects than one large one. Small projects are usually easier to manage than large ones and will probably need a smaller percentage of their cost spent on project control.

Easier to commit people for eight months than for three years. It's much easier to lock someone in to a project for 8 months than for 3 years. And committing business people for 8 months probably means their skills will still be current when the project ends. After three years out of the front line they may need retraining.

Fewer people leave. The longer the project the greater the risk that people will leave during it. More people will leave during a three year long big bang than during a six or eight month long release. Anyone leaving a project team constitutes risk.

Earlier benefits realisation. The big bang project may deliver a lot of benefits - but only when it's finished. Three years can be a long time to wait. With the release approach you start to reap benefits as soon as Release 1 goes live. And who knows, these benefits might even pay for subsequent releases.

Lower cost overall. Which approach will be cheaper overall, big bang or releases? Put your money on release. Less spent on control, less spent on change, less wasted on never-used functionality. And the cash flow advantage of earlier benefits realisation can have a powerful effect on the business case. Add to this the problems that large projects so often experience and the option of breaking it up into shorter sharper releases becomes yet more attractive.

In practice it depends upon so many factors that you can't say one option or the other will always be the better. If it were that simple people wouldn't be paid all that money to manage projects.

If you adopt a release approach, only include in Release 1 the functionality that will be needed on day 1 and leave all the other stuff and the nice-to-have features until later releases. But this raises one rather major question: whose job is it to ensure that Release 1 only contains the things that need to be in Release 1? People's answer to this question is often "the users" - which is a pretty meaningless answer, or "the sponsor" - which is true only to the extent that he is ultimately responsible for everything.

The correct answer is the project manager. This doesn't mean the project manager makes a random selection in splendid isolation. It means that the project manager makes the stakeholders (sponsor, steering committee members, users, IT, etc) work out what is really needed and what isn't really needed in Release 1. However, in managing that process the project manager may well find that he ends up knowing even better than the stakeholders what they really need and in the end he may have to, with the sponsor's blessing, make the scope decisions. It is ever so easy at the beginning of a large project to be everyone's friend and say: "You'd like that included? No problem I'll put that in for you." Anyone can do that. To be a good project manager you have to learn how to say the most important word in the project manager's vocabulary: "No". Politely but firmly: "No".

At the start of Release 1 cut its scope back to the bone - for which everyone will hate you. But they'll love you at the end when you deliver on time on budget. (Tip: having cut scope to the bone at the beginning, during the project slip in a couple of sexy features that you know everyone will like, but which you know will be cheap and easy to do - that'll make 'em smile.)

There aren't all that many very large projects around so the chances are that the sponsor and project manager will not have been involved in a very large project before. This inexperience may mean that they drift into the big bang approach without too much thought (or even awareness) of the releases alternative and on the unconscious assumption that it must surely be cheaper to do everything just once. There are plenty of horror stories out there of large projects that started out big bang, went nowhere, then restarted with a release approach.

If nothing else, be alert to the danger that a big bang approach can imply, and the day the boss knocks on your door and says: "I have an opportunity for you", from the very first moment assume the release approach. Then, if after careful consideration you conclude big bang really is better, fair enough. At least you'll be going in with your eyes open.

In summary, breaking a potentially long project into a series of short, sharp release projects will probably cost less, deliver benefits earlier and be more likely to succeed. The release approach will give the business a better return on investment.


...next

Privacy Policy and Cookies