When I was with what is now called Accenture (which was then Arthur Andersens) our Managing Partner was adamant that if a project went over budget we had to ask the client for additional funds. Woe betide any manager who failed to get additional funds.

Some years later when Head of Strategy for a bank, I employed my former firm to do an IT strategy on a fixed price. We really mucked them about going through three Sponsors (CEOs) during the project. I calculated that it had cost them three times their fixed quote, so I got approval to pay them another $100,000 on top of their fixed price. But I was only going to give it to them if they asked.

So, in came the Managing Partner (who had been supervising the project) for THE conversation. The conversation moved closed to the question, and then veered away. This happened four times and the question was never asked — so I kept the money and was angry that the Managing Partner himself could not ask for more funds after all the times he had berated us to do so!

But it raises the question, when should you pay your consultants more and when should you refuse to pay them?

Underestimation
If the consultants under-estimate the job then that’s their problem. However, if this situation is going to put them out of business and you need their ongoing support, then you should act sensibly and commercially.

Client caused delays
If you cause the delays and problems, then you should pay extra to cover the extra costs you have caused them to incur. Regardless of the terms of the contract this is both ethical and fair.

Unjustified charges
However, if you keep getting unjustified extra consultancy charges that are out of proportion to the perceived effort and workload, then you need to take a stand. Before they get the job the consultancy is often very careful in it’s pricing, after it’s got the job it can try to leverage up the price. You need to manage this situation by calling in the consultants and getting them to justify IN DETAIL every (extra) charge. They’ll quickly find the cost of detailed justification outweighs any possible financial benefits of extra charging.

Another version of this is low productivity. Consultants are expensive and therefore should perform better than other staff. If they’re goofing off, having long coffee breaks, disappearing for hours around lunch time, etc, refuse to pay for that time. It will very quickly sharpen up their act.

Uncommissioned jobs
If they charge you for things you didn’t ask for — don’t pay. But here you must have a clear process for ‘asking’ for work and can’t suddenly change the rules mid-term. If you’ve asked for it, however informally, then you should pay. If they don’t give you what you asked for, refuse to accept it or pay for it.

Partner costs
Consulting partners have a habit of arbitrarily allocating their time to projects under their supervision in order to reach their required ‘consulting’ hours. Their costs can be substantial for little time. So, if you haven’t seen the partner for a while but their time is being charged to your project, challenge them to justify what they’ve done and what value they’ve delivered to you and your assignment.

Working in your favour here is the consultant project manager who hates having the partner’s costs assigned to their project as it eats up too much of the budget. If you have a quiet word with the consultant project manager questioning the partner fees they’ll usually take the necessary action!

Summary

If, as the client, you’ve asked for it, caused it or are in anyway responsible for it, you should pay even above a fixed price.
If the consultants have mucked-up, under-quoted, under-performed, been unproductive and overrun, then that’s their problem.

And, if the consultants are charging what seem unreasonable fees (even if they are allowed for in the contract), challenge them, make any possibility of sloppy or over-charging too dangerous. When they’re being watched closely they take more care with their invoicing.

If in dispute, pay what is not dispute and hold the rest until the dispute is resolved.

To understand consultants, buy Consultants.CON from valuedeliverymanagement.com — an entertaining look at how consultants think and work. (more information)

To learn how to manage them to get the most value, buy “How to manage your consultants” also from valuedeliverymanagement.com. (more information)

Please post your comments below.

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

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!

A major international consultancy showed me their project health check checklist. It wasn’t a ‘health check’ at all, it was really a project audit.

What’s the difference?

An audit checks the existence of the necessary documents, reports and sign-offs. Do you have a change management strategy? Yes, tick, move on.

This approaches assesses the existence and, occasionally, the content and assumes that, if we have all the right documents, we will have a successful project. Not so.

A true ‘health check’ doesn’t ask, “Is the project under control?” so much as, “Is it set up and aligned to deliver the business outcomes and benefits agreed?”

This perspective adds another dimension to the review. For each document the questions are

• does it exist?
• is it relevant and appropriate?
• and, is it effective?

A couple of real life examples to illustrate.

One project, being managed by one of the top international consultancies, had a Change Management Strategy of 36 pages. Exist? Yes, tick.

One paragraph at the bottom of page 27 actually talked about making change. The other pages talked about the theories of change, approaches to change, causes of resistance to change, problems with change programs, etc. Relevant and appropriate? No, not really.

Because the strategy was not useful it was not effective. The strategy had no positive impact on the project and its delivery of the outcomes and benefits. It may have cost $60K to develop, but was effectively worthless. For all intents and purposes, the project did not have a change strategy.

Another example, this time a Communications Strategy.

It existed, was relevant and appropriate. Indeed it was one of the best we’ve seen. It actually focused on addressing the stakeholders’ agendas rather than the project team’s. So, Exist? Tick. Relevant and appropriate? Tick.

Unfortunately, the person who developed the strategy had left the project and been replaced by more conventional communications strategists. They had either not read the Strategy or decided to ignore it and had gone back to conventional team-oriented communication approaches. So, Effective? No.

In both these examples many conventional ‘health check’ approaches would have given the project a green light. The documents existed. But in both cases, for different reasons, no effective strategies existed in operation.

And, as it only matters ‘in operation’, this is a real cause for concern.

So, when you next look out your health check approaches, look to see if they actually evaluate the impact of the document on the outcomes of the project. If they don’t, the health check itself is in bad health.