A recent article over on Procurement Leaders titled “software procurement blunder grounds vital military helicopters” has me fuming.

First of all, it contains the phrase “procurement blunder” when the blunder does not appear to be the fault of the Procurement department, but the fault of idiots higher up.

Secondly, it contains the statement that an organization should “cut costs by developing its own software“.

I guess I should step back a minute and summarize the article. The UK MoD (Ministry of Defense) purchased eight (8) Chinook Mk3 helicopters in 1995 from Boeing which were delivered in 2001 at a cost of £259 Million. As of 2007, they were still not deployable because they could not be flown in poor visibility or at low altitudes because they were missing key operational software. This software, which would only have cost £50 Million (which is only 2.5% of the purchase price of the eight helicopters), was not included in the purchase because the UK Treasury demanded the MoD cut costs by developing its own software.

This is just nuts in so many ways. For starters:

• Over 90% of software projects fail to come in on time and on budget.
• Complex software systems, especially operating systems, typically require thousands of man years to develop. Red Hat 7.1, which only has to operate a PC and not a complex military helicopter with dozens of systems and hundreds of controls, required about 8,000 man years of development effort.
• Complex (operating) systems can only be built by senior developers, which, fully burdened (with salary, benefits, hardware, and software costs), will cost you about 200K / man year.
• This says that 100 M (slightly more than £50) only buys you 5,000 man years.
• Even if your programmers knew exactly what to do, it’s doubtful you could even match the market cost of an already developed system which is being amortized over a large group of buyers.
• The only way the MoD could make the helicopters flyable was to spend untold millions stripping them down to Mk2a configurations, which also delayed their deployment for 2 or more additional years.

But, more importantly, you’re trying to save pounds by pinching pennies! That never works! It would have been much more logical to try and find ways to reduce the purchase price of the helicopters by 2.5%. For example, could the purchasers have worked with Boeing to help them execute more strategic sourcing projects to reduce Boeing’s cost in a savings-split? Could UK MoD manpower have been lent to Boeing? Since most purchasers believe in the old maxim that you can take 10% off of the cost of anything, how hard would it really have been to reduce costs by 2.5% to cover the software costs if Procurement was allowed to be creative instead of having to deal with idiocy pushed down from the top?

Share This on Linked In

A recent CIO blog post asked “what does a “successful” ERP implementation actually mean”? This puzzled me, because the answer is easy:

One that is never started.

As the author notes, there’s just no way the majority of these bloated projects come in on time, on budget and without one or two people losing their jobs … because all big bang projects do is blow up.

Not that they can’t be successful, they can, and a handful have been, but, in reality, with the complication inherent in today’s business and the complication inherent in today’s systems, they usually aren’t … no matter how well contingencies have been planned for, how reasonable the expectations are, or how good communications are from start to finish. After thirty years, these systems are still so complicated that they are still beyond the comprehension of the average company.

That’s why you should approach your enterprise software needs one step at a time, one core system at a time, and one standard at a time. Define your basic architecture and your basic interoperability model and then select systems that fit into that model. Implement one system to solve one set of problems at a time, insuring one is working before starting on the next, and you’ll greatly reduce the risk of your project being a catastrophic failure.

This isn’t to say that you can’t standardize on one ERP platform … a few companies have found success with mostly end-to-end SAP and mostly end-to-end Oracle, but that if you take the approach, you do it one module at a time. If your integrator says you have to do it all at once, find a new integrator. If your provider says you have to implement the entire system at once, find a new provider. It’s literally as simple as that because, when you get right down to it, it’s your money … let it talk.  After all, as Vinnie astutely points out, if you really want to succeed, don’t upgrade, escape.