Academics and others are peddling the line that business is changing so fast that it is pointless setting out on a project of any duration because too much can change in the meantime. So, instead, you’re to focus on defining the problem and identify what assumptions are involved in this problem definition and therefore what needs to be done to confirm the problem because, by the time you’ve confirmed it, it may have changed due to other circumstances.

Okay, we’re in the midst of the greatest financial crisis of our lifetimes. The world today is not the same as the world of January 2008. Things have moved fast in that banks have disappeared or become part-government owned, credit has dried up and ‘leverage’ and ‘debt’ are now unacceptable words in business.

But how has this changed projects? Most organizations have reviewed their projects and culled some, mostly to conserve cash and investment funds rather than because the projects are now irrelevant (although some will have become irrelevant).

But does this change how we approach projects as claimed by the academics? Not really.  What it does do is highlight the need for our project delivery processes to work more effectively.

We need effective prioritisation processes that cull early poor and irrelevant projects early and allow us to flex our project portfolio to meet future environments and challenges.

Our ‘strategic alignment’ processes need to reflect our current strategies. Revenue growth may have been replaced in priority by cash conservation or cash flow. Supply chain protection may have replaced supply chain optimisation, and so on. But strategic alignment processes should be reviewed yearly at least, so this is only adding one or two additional intra-year reviews.

Project planning and delivery processes need to ensure continuous delivery of benefits so that if they need to be cancelled or mothballed they have delivered something of value. But they should be doing this anyway.

Benefits tracking and measurement now become paramount in that if you’re going to do projects you now need to ensure you realize the value (rather than rely on ‘hope’). But, again, this should be the norm (although I concede it is not). Every project should now be measuring monthly its viability as, with the economic climate changing, some of the financial parameters can change radically on almost a monthly basis which, in turn, can dramatically impact the financial viability of a project.

So, I don’t think the academics are right. Sure some things are changing fast, but should the reaction be a furious realignment to short-term agile type approaches to projects in the belief that too much will change to make any other approach workable? No. The more appropriate answer is to quickly get our house in order in terms of how we select, prioritise and deliver projects and their benefits — which is what we’ve been furiously saying for 15 years!

Your comments ?

When considering a request for additional funding there are three types of funds — sunk funds, the ‘money at risk’ (to be spent in the next phase) and the remaining projected cost of the project. The remaining projected costs have not yet been spent.

Money already spent is ‘sunk’ and cannot be recovered. Money not yet spent is controllable. So, when do you continue or stop investing in a project? When are you pouring good money after bad?

When a project asks for more funds there are two ways of looking at the additional investment

1. The incremental cost over and above the ‘sunk funds’ invested to date — only another $Zm
2. An increase in the total cost of the project from inception — from a total of $Xm to a new total of $Ym.

Using the incremental approach projects can (and do) grow from $60m to $180m, for example, in “only another $20m” increments! Each decision justified on the basis of realizing some value from the sunk costs to date.

Some project managers will argue that the only consideration is total cost from here on in, as the sunk costs are already gone. So, having spent, say, $50m, you can justify another $20m on top of the original $60m as “we need another $30m to finish”. This is a dangerous road to follow.

The relevant questions are:

“What cost will the value proposition sustain?”

At some point the financial return on the investment (ROI) will turn negative. From this point onwards you are destroying capital in your business.

You need to know the maximum delivery cost your project’s benefits will support to give a neutral ROI. Be very reluctant to go beyond this cost.

“How certain is this ‘final’ figure?”

Most projects that have gone way over budget have done so in several small increments. This is partly because small increments are easier to get approved and partly because the bases on which these revised estimates were calculated were not reliable.

You need to know how certain the estimates behind the revised figures are. If you are still high on the uncertainty curve then you know the figures are uncertain and, therefore, likely to be exceeded in due course. Then you know that this additional cost is not likely to be the final cost. Are you prepared to spend even more?

“What is the business cost of not completing this project?”

Taking a purely project-financial perspective and stopping a project because it is no longer financially viable can destroy other business value.

For example, if you’re trying to catch up the competition and your project becomes unviable; if you stop the project you’ll remain uncompetitive in the market with consequent downstream impacts.

You need to understand the full business impact of the project (usually covered in the business case’s project rationale and ‘do nothing’ options) when making a decision. Are the downstream impacts acceptable (either way)?

Further complicating matters is the tax dimension that requires cancelled projects’ costs to be expensed this year whereas delivered projects’ costs can be depreciated over several years. This tax policy encourages pouring good money after bad to deliver ‘something’ and enable depreciation.

So, when do you pull the plug rather than continue to invest?

1 When the project will not deliver a (worthwhile) solution.
I stopped a HR system that was so out of control that it had consumed its total budget and then some more before it had even finalized the requirements.

I stopped another project in the planning phase when it had re-planned three times in three months but was unable to articulate what it was going to deliver. This project, originally costed at $82m, was restarted and delivered for $36m.

2 When the project’s original costs/estimates are obviously out of range
EG a project’s original costs are seen to be, at most, half of the likely total cost.

A $5m project should be set up as a $5m project; a $10+m more complex project will be set up differently and require a different calibre of project leadership team. Just ploughing money into a project that is set up inappropriately is to invest in failure.

These types of projects need to be re-baselined, re-justified and restarted, not continued with additional funds.

3 When the project is not delivering successfully — a proven record of non-success
I stopped a project that had delivered phase 1 but it was not working well and the estimated cost of rolling out the other five phases had increased by 50%. Rather than impose the same or similar pain on the rest of the organization, the project was cancelled and the implementation rolled back to the original system. The total investment ($11.7m) was written off.

4 When the value has been lost
Where the project’s value is based on uniqueness, being first to market or lowest cost, for example, but this opportunity has been lost.

I stopped a ‘low cost account’ system in bank when the projected cost of delivery and operation of the new account exceeded the current account system costs.

5 When the need for the project has disappeared/is found to be missing or can be met more cost-effectively
I stopped a project when we found an alternative solution could fix the problem for less than 4% of the original project’s projected cost.

I cancelled a project when I found that the problem it was solving would not occur for another eight to ten years!

6 When there is a better use of the resources
I cancelled a “Staff wardrobe stock control system” when we couldn’t find any IT resources to bring new products to market. While few of the wardrobe IT resources could be reallocated in this case, by releasing them and hiring the appropriate resources we could deliver the organization’s strategy (even if not its wardrobe!)

Always think of it as your money — would you continue to invest in this project? Don’t be afraid to stop projects and reallocate the funding to more worthwhile projects to generate greater value. After all, generating the maximum value is what portfolio and investment management is all about.

Please post your comments below

Many of you will know the famous Abbott and Costello comedy routine about who is on the various bases at a baseball game. Because the player is called “Who” there is great confusion as to who is on first base.

(see http://vintage.videosift.com/video/Abbott-and-Costellos-Whos-on-First-Routine)

Which brings me to this week’s topic — when evaluating project proposals, who’s on first? What dimension do you evaluate first?

The traditional approach has been to look at the financials first. Does it have a positive ROI? Are the financials believable and appropriate? If the project passes the ROI hurdle it gets a BIG tick. In some cases only if it fails this first hurdle do the other dimensions get evaluated.

But is this right?

Research by PWC found that 83% of project proposals had their numbers ‘fudged’ to get them through the evaluation process. You want a hurdle rate of 15%, we’ll give you a proposal with a return of 15.2%!

We recently found the CFO of a major organization fudged his project’s business case to get the requisite ROI figure!

The number of assumptions built into a project’s costings and benefits make many ROIs a guesstimate at best.

Also, as external to the project events can change the project’s value and therefore its ROI, the financials are the least reliable and consistent measure of a project’s (potential) success.

So, should they be the first evaluation measure? Probably not.

The first question should be “Does this project align with our strategic direction and priorities?” Is it helping us get to where we want to get to? Is it relevant?

There are projects that, financially, have a great positive ROI but which are totally irrelevant to the goals and focus of the organization.

Some years ago, a management team prioritised its projects and the project that was rated number two in priority disappeared completely when a strategic alignment overlay was added. It was totally irrelevant. The firm had a lot of key issues to address, and this project was not focused on any of them. It was cancelled.

This, of course, requires an effective and objective way of scoring strategic contribution. (Which we can provide.) Once this is in place, the management team can ask the following questions in the following order

• Why are we doing this? (What’s the opportunity/problem?)
• Why is this relevant? (What’s the strategic alignment and contribution?)
• What’s the value? (What are the financials?)
• Is it doable? (What are the risks and delivery capability requirements?)
• Is it doable now? (What are the resource and deployment constraints?)

What do you think? Add your comments below.

There are three numbers that should be indelibly burned on every Sponsor, Steering Committee member, Investment Committee member and Project Manager’s mind when approaching projects. These three numbers are 15%, 35% and 5%.

These numbers have remained constant for the past 17 years, since the first such analysis was done by AD Little in 1991. Indeed, I confirmed these figures again in Australia last year.

Let’s explain these three numbers.

15% of projects fail. They may not finish, they may vaporize, they may be cancelled, in some cases they may actually be implemented and found to either not work or not be used — by whichever of these means the project fails, the money spent is wasted and no value is delivered. Worse, often in the process of these projects failing, real existing value is destroyed.

(Another way of looking at this number is that of every $1m spent on projects, $150,000 will be wasted.)

However, you don’t want a 0% failure rate — you want to invest some funds in speculative projects and ideas that you don’t know are feasible or whether they will come off. In our experience, a reasonable ‘failure’ rate of formally cancelled projects is about 5%. This enables innovation with minimum waste. Having an acceptance that some projects will and can be cancelled also prevents projects being ‘condemned to completion’.

Only 35% of projects deliver efficiently. By ‘efficiently’ I mean ‘on time, on budget and to specification’. These are often the project manager’s personal measures of success, but even so the majority of projects still fail on one or more of these three efficiency criteria.

While to be commended, projects are not commissioned to enable ‘efficient’ delivery — this is a project performance factor rather than a business goal. Projects are commissioned to deliver business value and, as many a project successfully delivered to time and budget and specification will attest, you can meet these three measures and still not deliver value to the organization.

The key measure of project success is effectiveness — did the project deliver the outcomes and benefits expected? Did the project improve the performance of the organization? The fact that a projects can be delivered ‘to specification’ but not deliver value is an indictment on both our needs specification and value delivery processes.

Only 5% of projects are delivered effectively. This is the number of projects that deliver on time, on budget, to specification AND deliver all of the expected and available outcomes, benefits and value.

This number means that 95% of projects started are not going to deliver the full value expected.

Either way you look at these numbers, they are terrible and have not changed since AD Little did their first measure of project success in 1991.

The reasons why these figures have not improved are many and include:

• projects are not set up or run to deliver value (to increase the 5%); they are set up and run to deliver outputs or ‘products’ or deliverables. The difference can be about 80% of the value!!
• projects are still primarily measured with the ‘on time/on budget’ metric as this is more visible and easier to measure than the harder to measure benefits and value measures. So we’re still using simple, even if wrong, measures.
• many senior management teams still focus almost exclusively on cost. Indeed, many organizations seem to be content to see their projects come in late (which usually destroys more value than going over budget) but go ballistic if they go over budget. With this myopic focus on cost they basically have to ‘hope’ that the value will follow. As the figures show, it doesn’t.

So, if we’re going to change these numbers we need to change how we deliver projects and move our focus from mere project delivery to full value delivery.

The good news is, focusing on value delivery simplifies project delivery and makes meeting all of the project success measures more achievable.

Post your comments at valuedeliverymanagement.com

When life was simpler, projects could be assessed on their claimed return on investment (ROI). If the project was financially worthwhile (at the time of approval) and supported by some executive, it would be approved.

Projects tended to be approved in isolation creating problems at the portfolio level clashes and when they came to be implemented.

So the evaluation of projects has become more sophisticated. Or has it? A recent analysis of eight major approved projects found that seven should not have been approved in their current form. One was solving a non-problem, one was delivering a solution that was incompatible with the organization’s future direction, one was a project that was already off-the-rails! And so on.

Yet each of these projects had been evaluated by their divisional investment committees as well as the enterprise investment committee. The problem was that this (and most) organization did not have a clear and effective evaluation model.

The following evaluation model makes the bases for evaluating projects clear:

(Targetting Investments)

The first question is, “What’s the project’s value?” — why are we considering doing this project, what will we get from it? Obviously if you fail on this test, you don’t go any further.

Then the question is, “Will we get the value?” — is the project too risky, too complex, too vague or mismanaged to deliver the value promised? The value proposition is only as good as its ability to be delivered.

The next question is from the corporate perspective, “Does it advance our strategy?” — is it relevant to what we’re trying to do, the problems we are addressing, the direction we’re taking? If not, why are we doing it?

The fourth question looks at the organization’s capability to deliver the project “Can we deliver this type of project successfully?”

The reaction to many a failed project is to start it again with a new team, but sometimes the reason for the failure is that the project is beyond the capability of the organization to deliver. If you don’t know your organization’s project delivery capability you can be wasting large sums of money on projects you’re just not able to deliver.

The next perspective is whether we have the capacity to do this project — do we have the resources to deliver it, can the business absorb it effectively? Too much concurrent change reduces the actual value delivered as the staff become change-weary. Also, too many concurrent projects spreads people’s attention and commitment to thin. Can we do this project well? is the key question.

Then the portfolio perspective is applied. “Does it fit in with our existing portfolio?” — does it support other projects, can we accommodate it and implement it when due? A high-risk project by itself is not necessarily a concern, the fourth concurrent high-risk project is a concern. So how this project fits with what is already in-flight is important.

The final question, “Is this something we should do now?” — is it the most important, the most valuable project on offer? Is it worth the effort? What will happen if we defer or even stop it? This question needs to be asked whenever the project is being re-evaluated for continued funding. Just continuing to do a project because you’ve started it is no basis at all, it is better to cut your losses and reapply the remaining funds to a higher priority project.

Accompanied with a thorough evaluation process, this process culls irrelevant projects, projects you cannot do, projects that overload the organization and refocuses your investment funds onto the projects with the most value and likelihood of success.

Our Guide, “Understanding Prioritisation” will be available shortly — more details to follow soon

Why is it that two organizations implementing the same technical solution (hardware and software) can generate very different results? One implementation may be a disaster and threaten the existence of the organization, while the other generates massive, positive returns.

When we[1] found this discrepancy in business results from common technology in 1993-96[2] we went back to see why this was occurring. What we found was that different organizations had different approaches to implementing projects in general, and systems projects in particular, and that there was a direct correlation between these approaches and the results consistently obtained.

Through further work we identified five measurable levels of ‘business project delivery capability maturity’.

Now maturity models abound in and around IT — the SEI and COBIT maturity models are the most well known. However, these maturity models seek to improve the same processes until they are ‘optimized’.

The business capability maturity model found that there was a break point between maturity levels three and four where the whole foundations and thinking about projects changed. And the results changed too, increasing exponentially.

At maturity level-1 there are few repeatable project delivery processes. The organization relies on ‘heroes’ to bring the projects in. Therefore there are some successes (where the stars line up) and many non-successes, to varying degrees. Over time, the nett return on investment, once you’ve taken into account the ongoing operating and support costs, is negative.

Level-2 brings formality. Fed up with the hit and miss approach of level-1, organizations install methodologies, governance and approval processes. These processes are rigorously enforced, almost making following the process an end itself. The results improve generating a break-even investment return. Many organizations are still struggling to get to and sustain this level today.

Level-3 adapts the rigour and processes of level-2 to get even better results — a return of 1.3 to 1.5:1 on funds invested. Good, but not great. The highest IT maturity levels of SEI and COBIT will, by themselves, only allow you to get to this level. At least the returns are positive, but they can be doubled by level-4[3].

At level-4 the whole approach to projects switches from IT, project or quality-improvement delivery to strategy and value delivery. The returns double from level-3 (to 3:1), the time taken to do projects reduces and the time and effort wasted is minimized. Organizations at level-4 can generate two to three times the returns from the same level of investment as their peers — a sustainable cost advantage.

If your organization is not at level-4[4] you’re giving away significant value on each and every project and leaving the potential for a competitive advantage to your competitors. For most organizations, level-4 is the target level of maturity.

Level-5 is when the disciplines and approaches of level-4 are embedded in how the organization does business, competes and makes money — it is in its DNA. The returns increase exponentially again.

The other significance of the business capability maturity model is that it determines what types of projects you can successfully complete. Large-scale, complex, innovative projects require more mature delivery ‘capability’ than smaller, simpler projects. Taking on projects beyond your capability to deliver is a frequent reason why so many large projects fail in organizations.

So, you need to understand your level of capability, the level of capability your project demands and check that you do have the wherewithal in capability terms to deliver and realize the value. If not, don’t start.

For a complete description of the Business Project Delivery Capability Maturity Model, read “Project Delivery Capability — the next competitive battleground” available from www.project-sponsor.com.

[3] Level-4 can give you a cost advantage as you can halve your investment levels and still get the same results!

[4] Usually over 50% of the potential value on most projects!

If you’re asked to estimate the time it will take you get from somewhere you’ve never been to another place you’ve never been either, how accurate would your estimate be? So it is with many project estimates – they’re based on too little knowledge and too much uncertainty.

Any later adjustments to your estimate would be as you increase your knowledge of the challenge you’ve been asked – they would not be testaments to your estimating incompetence!

Estimates are dependent on the ‘Uncertainty principle’ that illustrates why initial estimates tend to be inaccurate and only become more accurate as the project progresses

Failure to recognise the Uncertainty Principle leads to a lot of misunderstanding about estimates (and therefore budgets and timescales). The Uncertainty Principle makes sense of a perplexing subject – estimating.

Uncertainty Principle

How long does it take you to get to work? Let’s say it’s 40 minutes.

So, most days it’s 40 minutes give or take a few minutes. Some days it is quicker – nearer 30 minutes – other days it takes longer, say over 50 minutes. On a few occasions it can take 90 or so minutes due to accidents, road-works and alike.

So tomorrow you have an important meeting with ‘the big boss’ at 8am. What time will you leave home – 7.20? Unlikely. There is enough uncertainty in your journey time for you to ‘allow’ for delays, bad weather, etc. You’d probably leave at, say, 7am. This is a 50% allowance for ‘uncertainty’.

The ‘uncertainty principle’ is the level of uncertainty that exists when making an estimate – the level of unknowns.

To illustrate. Take a journey between two point you’ve never been to. How would you estimate that journey time? To do this you’d have to seek out as much information about the journey, roads, form of transport, likely impediments, weather conditions, etc.

As you get more information you’ll be able to give a better estimate of the journey time. The earlier you’re asked for a ‘final’ estimate the more woolly and inaccurate it will be, as your level of uncertainty (unknowns) will be high.

So it is with project estimating. The more unknowns, the more the uncertainty, the less accurate the estimates. As you progress through the project the more the unknowns will become knowns and the more accurate the estimates will be.

By the end of the project’s solution-design stage the estimates should be fairly robust. But before that any estimates range from wild guesstimates to only partly-informed estimates.

However, when do most organizations expect a business case with fixed cost and time estimates? Often before even the requirements have been done! IE when the level of uncertainty is still very high.

No wonder these estimates are so often wrong.

“But,” you may ask, “why are estimates always ‘under estimated’ even when contingency and ‘padding’ is included?” There are three principal answers to this question.

When estimates are under-estimated this means they’ll be surplus funds. Now, rather than return the funds or deliver early, what tends to happen is that work expands to the funds available. A key governance team accountability is to see the funds allocated to the project as the maximum to be spent, not the target to be spent

Then there’s people’s optimism. Most people naturally under-estimate. They identify the obvious activities but usually don’t foresee all of the glitches, problems, delays or special events that will occur. To illustrate this, I have found that a carefully compiled workload estimate, including contingency allowances for things going wrong, delays, etc, must still be multiplied by FOUR to be accurate!

Management cannot take the answer. The team works out the estimates and finds the true total estimate to be an answer that is too high, one that the management won’t accept. So, rather than present the true total figure, the team presents a reduced estimate so as to get the project approved. Then, as the project progresses, the estimate is ‘adjusted’ to the full figure.

One Project Investment Committee member recently observed that he automatically doubled the costs and halved the benefits on any proposal presented. (Unfortunately, in his organization, this was usually very accurate.) Although extreme, he was in effect applying ‘the uncertainty principle’ to project estimates. However, there is a better way.

When estimates are uncertain, three different estimates should be given – best case, worst case and most likely. The range between these three figures should narrow as the project progresses and the level of uncertainty is reduced.

What these three estimates are saying is, “If you are not willing the spend the best case estimate, don’t start. However, the project should never exceed the worst-case estimate. At this time our most likely estimate is this”

However, the ‘uncertainty principle’ dictates that the earlier you ask for estimates, the less reliable they are. So if you go to your investment committee with a funding request based on highly uncertain estimates (that you’ve demanded from your project team) you’ve only got yourself to blame for any subsequent increase in the estimates.

In a recent exercise with one major corporation we reviewed six of their recently approved multi-million dollar projects — and found five of them should not have been approved.

These projects needed to be done, but the way they had been scoped and framed minimised their business value (but not their cost).

From these reviews, and many others, we found some leading indicators that should make you afraid to approve such projects.

1 Technology only or technology upgrade projects

No company exists to use technology. The question with any technology project is “Why are we upgrading? What’s the business value?”

Overcoming technical failures and out-of-support concerns, and other such reasons, are not enough because addressing these will usually only give you what you’ve got to day but with a higher price. Hardly a compelling value proposition.

Find the business value or find another project.

2 Confused business cases

Some business case read well, make a good case for their project and give you confidence that the project is well understood and under control (even if, at times, misfocused).

Other business cases are just a collection of fields that don’t tell a story or are internally inconsistent in their message.

A poor business case is a good leading indicator of a poor, confused project. If the project team and/or Sponsor cannot clearly articulate a compelling rationale and value proposition for their project, reject it.

3 System-named projects

Naming your project after the system (or vendor) immediately suggests a systems, rather than business, focus. A systems focus loses sight of 70-80% of the potential business value.

For example, a project to combine financial systems (called, “Common Financials”) identified potential benefits of $16m. By changing the perspective to the business outcomes level — improving financial management performance —benefits worth more than $40m were quickly found. The increase in delivery cost for this additional $24m in value? $1.2m (or 5% of the original project cost).

4 Mandatory projects

Government and industry laws and regulations can ‘require’ changes. But there is more than one choice other than ‘mandatory compliance’.

You can choose not to comply (not recommended), to just comply (minimising investment), or to exploit the need to comply to achieve additional business outcomes and maximise returns on the investment.

Too often too little thought is given to ‘mandatory’ projects. We once converted a $8m ‘mandatory’ proposal into a $30K Excel spreadsheet-based solution by asking what was the absolute minimum we could do to comply.

Subject any ‘Mandatory’ projects to rigorous scrutiny to find the best value solution that also aligns with your business strategy.

When allocating millions of dollars to projects it pays to ensure that they are

• the right projects
• correctly focused
• not unnecessarily costly
• proposing the most appropriate solution
• maximising the business value to be delivered.

Not unreasonable requirements surely?

The project had already failed, been stopped or refocused three times. From its initial inception to now it had been in existence for 7 years.

The total funds invested, and mostly written off, neared $50m.

This time, the company vowed, it was going to succeed!

First step, they put in as project manager a business executive who had never run a project before. (And, it transpired later, did not really see this appointment as a great career move.)

Second step, they chunked down the project to deliver in phases. The first phase was designed to remove the paper out of the process. But, instead of actually eliminating the paper processes, they merely automated them. The paper became electronic images and the process was only marginally improved.

Small wonder, therefore, that the project continued to struggle with its business case. It was only allowed to continue because the senior executives fervently believed it was worthwhile.

Step three, they changed the Sponsor. After the third attempt had failed the Sponsor was fired (along with the Project Director). A radical step that indicated a level of seriousness.

So, the new Sponsor could recognise a ‘hot potato’ when he saw one and handballed accountability to a newly formed “Project Director” role designed, not least, to be the logical sponsor of the project.

The Sponsor inherited a project ‘in flight’ with plans, technologies selected and a continuously draft business case. And, a business unit that wouldn’t release staff to work on the project. (The business unit was experiencing record high sales volumes. This made achieving the efficiencies and work reductions the project promised even more urgent while also putting pressure on the staff workload, making releasing staff for the project difficult.)

However, the project team and business inadvertently conspired to create a ‘catch-22’ situation. The project did not plan to deliver many short-term savings in order to create the capacity to release staff to work on the project, so the project was going at half pace or less because the analysts could not get access to the business staff to understand the requirements, so the time to benefits was extended, therefore the project didn’t plan to deliver many short term savings, …

The project was doomed a fourth time.

Sheer determination would ensure it delivered something and would, eventually, cover all of the scope of the project. So, at (probably) twice the cost required it would deliver less than half of the potential benefits.

This would be considered a ‘success’ as it had completed — but as a failure by any other measure.

What could have been done to rescue this mess?

1. Focus on the easiest, most voluminous processes first to create immediate savings to create the capacity for full business involvement on the more complex processes. Otherwise, stop the project — too little business involvement means too few desired business outcomes and benefits will be achieved, therefore, too little value will be delivered.
2. Appoint an experienced business-oriented project manager — one who would have recognised that not having your business requirements complete after 15 months of trying was a leading indicator of failure!
3. Set a series of ‘go/no go’ stagesRequire the project to deliver some immediate savings within, say, 4 months, or kill the project.Require the project to finalise the business requirements and valid business case within, say 6 months, or kill the project.Require the project to identify how additional savings will be delivered in the following, say 6 months, or kill the project.

Let’s get some focus here, some urgency and some value. Let’s save this project from its slow, painful existence, or kill it, now!