TOP Ideas

Hi All

No we haven’t gone off the planet or suffered a terminal post-Xmas hangover; it is just taking longer to get our ‘ducks in a row’ than we thought for our new launch.

So, thank you for your patience and meanwhile, here is some food for thought – have you seen this, or worse, are you seeing this now?

---

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 issued a Request for Tender to select a systems implementer to work with them, and also issued a Request for Tender for the ERP package. (Major warning bell!)

The initial ‘design stage’ (another warning bell) immediately leapt from $3m to $9m and from 6 to 10 months. (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.

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 your requirements. Now I know that many want to use the software to determine “What we can do” but this is a dangerous approach. You need to define your requirements and then select the software. Would you buy yourself a house first and then decide if it fitted your needs?
3. The first stage should be a ‘requirements definition stage’ not a design stage. Until you know what you want, how can you design the solution?
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 this is certain), then your project is ‘off the rails’.

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

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

The winner will be the systems implementer provided they can prevent themselves 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 avoidable. Successful projects are easy if you just follow the formula –

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

This isn’t ‘rocket science’, it is value delivery management.

© Jed Simms, Australia, 2010