Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
I was asked this question recently. Bear with me, it's a bit long-winded.
"Sometimes when we put together business cases we make assumptions about the project. Then, when the execution starts, we find out that the assumptions we made are wrong. How can I still deliver to the existing business case?"
It seems a no-brainer to me that you can't, and shouldn't. If the assumptions change, then you should review the business case and see if the project still has any value. If it does, great. If it doesn't, recommend that it's closed/postponed and save what you can.
Has anyone worked in a situation where they've been asked to stick to the original business case even though it is no longer valid? What did you do? And I am wrong for thinking this is a simple situation with a simple answer? Maybe there are genuine reasons for trying to stick to the original business case, but right now I can't think of any... Saving Changes...
Sort By:
Robin GoldsmithPresident| Go Pro Management Inc.Needham, Ma, United States
In my experience, flawed business cases are much more common than ordinarily recognized, largely because the project is ill-conceived from the start. Typical project initiation (and typical problem statements) assume whatever has been declared as the problem is correct and move forward from there. Too often they are solving the wrong problem or not solving the right problem, largely because the typical project process does not include mechanisms to confirm the problem is right.
In contrast, the Problem Pyramid™ tool provides a systematic, disciplined method to first give far greater assurances the REAL Problem is properly defined before proceeding. Part of getting the problem right is determining current measures that tell us it is a problem and goal measures that tell us the problem has been addressed adequately and provides REAL value. You can learn more about it in my book, Discovering REAL Business Requirements for Software Project Success, my seminars, and several articles cited on www.gopromanagement.com.
Saving Changes...
Anonymous
In the past, I've been appointed to a project where I've had to deliver to a business case, with figures that were questionable. Having raised my concerns both in private with members of the project board and with the project board during reviews, it was obvious that I was there to deliver the required outputs - not to review the business case.
Having said that, the project was a "pet project" for a senior director (who was the business exec) and has lost it's momentum since he moved onto another role. Needless to say - the project has been mothballed. Phew!! Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
The question is not whether the business case is flawed (all business cases will be flawed), but how badly is it flawed?
A business case is nothing more than a prediction of how much benefit wil be received at how much cost. The benefit will not be correctly known until after the fact and will likely not be fully measureable. The same is true of the cost. Given that, as long as the perceived benefit continues to exceed the perceived cost to complete, then there is every reason to deliver. Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
Thanks, everyone for your replies. Saving Changes...
Bernard GorePortfolio, Programme & Project Professional| NZ PoliceWellington, New Zealand
As others have said, every business case is flawed. Anyone who tries to write the perfect business case will never get it done, and the project will never happen.
And yes, when you start to execute, some of the assumptions, both those you stated and others you didn't realise you made, will prove wrong. This is NOT a cause to stop execution, but every such "flaw" needs to be assessed - will it affect the fundametal achievability of the project? Will it compromise the benefits, or increase the costs, to the point where the project is not worthwhile?
Every assumption that turns out to be inaccurate becomes an issue, and the impact of that issue needs to be assessed. You should have "Tolerances" in place and if the impact shows you will (or may) exceed these then you will need to escalate to the right level for a continue/stop decision.
Ultimately there are decission makers who have the authority and responsibility for deciding - and if the relevant ones decide that although the business case is so flawed as to be invalid, they still wish to continue, then that is their decision, and your job is to make sure they make this decision in a fully informed manner and that you provide an honest recommendation on whether to proceed or not, but if they decide to continue against this advice then abide by it.
You should make sure that the issue remains "visible' so that it doesn't come back to bite you, but if a business wants to take a risky, or even unprofitable, decision, then that is their choice. Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Strictly speaking, project manager delivers project based on the agreed scope and functional specifications within the triple constraints. Realizing the benefits and values of the project is not the responsibilities of the project manager; these are the responsibilities of the sponsor and/or product manager. However, regardless 'who is responsible', if assumptions ever changed, we should always review the business case again and someone has to make a call if the project should still carry on. Saving Changes...
Robin GoldsmithPresident| Go Pro Management Inc.Needham, Ma, United States
Whether you know it or like it, projects must deliver value; and the project manager is responsible for delivering the project that delivers value. A ‘not my job’ mindset is entirely inappropriate and irresponsible advice.
Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Great post and replies by all. I would only add there can be reasons why not all involved in the project and in the business case may possess all of the "Truth" cards. Hence, what may appear to be a flawed business case, may serve to another aim. For example, knowing that a plant/operation/organization will be shut down, but continuing a project or program to keep employees gainfully at work. Or a business case that may seem flawed to on its merits but that has other reasons for it that are of a need-to-know-basis only such as a stalling tactic or a tactic to gain working information on a company or its product. In such cases, it might be that the PM doesn't (and can't) possess all of the management team truth cards. This may not be the kind of flawed business case scenario of the posted question, but I have been seen and been party to a few of these over the years. Saving Changes...
