A disaster in flight



The Board has approved, in principle, $42m for a new ERP system to be progressively implemented across the group.

This “Business transformation project” is led by IT. (Warning bell)

On approval, the project team issues a Request for Tender to select a systems implementer to work with them and also issues a Request for Tender for the ERP package. (Major warning bell – first the solution, then the requirements!)

The responses ranged from $9 million to $35 million. Although the business was involved in the selection process, they were looking for a systems-based ‘silver bullet’ to solve all of their problems.

The winner was selected on both price and claimed domain experience – they brought their ‘experts’ to the presentation. On day-1 of the project, none of the ‘experts’ appeared and many had left the company between the bid and the contract’s finalisation.

On commencement, the initial ‘design stage’ (another warning bell) immediately leaped from $3m to $9m in cost and from 6 to 10 months in duration. (Multiple warning bells!)

So, within months of the ‘in principle’ approval this project is heading off the rails at an alarming and costly rate. We can already assert that this project will either fail or cost in the region of $60m plus[1].

Why?

  1. “Business transformation” projects are change projects, not IT projects. IT should only be a service provider. If the business cannot find anyone (internally) to effectively lead the project, it should be stopped.
  2. You don’t start a project by selecting the software. You need to first define in detail your business requirements. Now I know that clearly the software requirements to determine “what we can do?” but this is a dangerous approach. You need to define your own requirements and then select the software. Would you buy yourself a house first and then decide if it fit your needs later? The first stage should be a ‘requirements definition stage’ not a design stage. Until you know what you want, how can you design or select the solution?
  3. The business needs to accept responsibility for defining and later delivering the business solution – it can’t just abdicate to IT and the system's implementer and expect a low-cost, highly effective result.
  4. When the first phase of the project extends at the outset in both time and cost, you have a problem. Unless this time and cost will be recovered later (and that this is certain), then your project is ‘off the rails’.[2]

The business, in this case, example, is keen and skeptical. It wants better systems but does not trust itself to deliver them successfully. This will cause it to rely too heavily on the system's implementer who has a very different agenda (profit from the project not the client’s return on investment) and a different measure of success (systems implementation, not effective transformation and systems capability leverage).

The result will be a reduction in business benefits (to mostly those automatically caused by the new system) and an increase in project costs (as unnecessary rework and complexity, inadequate business involvement, and poor implementation). This subsequently highlights an increase in the workload but not the net value of the investment.

The winner will be the system's implementer, provided they can prevent themselves from being blamed for the project’s failings. The loser will be the business - both in its investment loss and, more importantly, its loss of opportunity to get it right.

Yet, this is all so unavoidable. Successful project investments are easy if you just follow the formula –

  • Initiate assess if it is worthwhile and feasible
  • Define your requirements. Define how you want to do business, compete and make money in the future through end-to-end simplified processes
  • Select the software that matches your simplified future process needs
  • Define your value proposition. Define the business outcomes, benefits and value of the investment and how will they be realised
  • Plan progressive delivery - i.e. deliver benefits early and often (to reduce the net cost of the project)
  • Manage project delivery to minimise rework and focus on delivery efficiency
  • Govern effectively to protect and deliver the value (even after the project has finished)
  • Track, measure and report real progress, real benefits realisation, and the achievement of all of the measures of success.

This isn’t ‘rocket science’, it is value delivery management made possible by Totally Optimized Projects™.

Postscript: The featured project has now past $100m and is still going although the company is now subject to a takeover!

Topics: Value Delivery, Project Controls, Value Equation, Project Governance

Further Reading

 




Footnotes

[1] We were wrong. When last seen it had exceeded $100m!

[2] To cope with the delays the project has since been re-baselined every time it is late – so it is always ‘on schedule’





Revision History

First published: Simms, J. (Jan 2010) as "A Disaster In Flight"

Updated: Chapman, A. (March 2020), Revisions and Corrections