Turning Failure Inside Out

Turning Failure Inside Out

The risks of technology implementation and the imperfect nature of IT development practices make project abandonment inevitable - CIOs must learn how to handle the crisis

SIDEBAR: In the Know

by Dave Rensin

The Universal Law of Technology Project Failure

Stories of high-dollar, long-term enterprise IT projects (especially ERP projects) failing spectacularly abound in the news. The important question is: Why does this happen?

My theory is this: There is a Universal Law of Technology Project Failure that asserts itself in these cases and dooms these kinds of projects. The law can be simply stated thusly:

Big Dollars + Long Time Horizons = Certain Failure

This Universal Law of Technology Project Failure has the following implications:

1. You can spend a lot of money over a short period of time and achieve a good result.This is essentially the brute-force method of problem-solving, but it can work for short-duration projects. Anyone who has ever watched Extreme Makeover: Home Edition has seen this in practice. On the popular TV show, people build completely new houses from scratch in just seven days. They spend a lot of money doing it, but it gets done.

2. You can spend small amounts of money over an extended period of time and have success. This makes sense when you think about it. If you're spending only at small levels over a long period of time, it won't cost a lot to correct mistakes along the way. The investment risk between milestones is small, so the institutional bias against change will also be small.

3. You can't spend large amounts of money over a long period of time and expect success - especially as it relates to technology. Let's say, for example, you're in charge of a multimillion-dollar IT modernization for your company that's supposed to phase in over the next five years. First, you can't possibly know what the state of new technologies will be five years from now. What winds up happening is that you project the technology you know (12-18 months) into a future you don't (five years). This means that one of three outcomes will occur:

  • At the end of the project, the solution will almost certainly be several generations behind the current state of the art.

  • Somewhere in the middle of the project, someone will notice what a waste of money it has become and kill it.

  • Approximately 18 months before the project is scheduled to end, people will notice how out of date the result will be, and you'll have to spend much more money to fix it on time.

The high-dollar component of this kind of project also places it at risk because it encourages an undisciplined approach to planning. After all, you can afford to take a lot of risks with a multimillion-dollar budget.

Large enterprises often take the completely wrong approach to IT modernization and technology selection. Rather than planning projects with ridiculously long time frames, companies should focus on projects that can be delivered in 12 months or less.

If it's absolutely critical that the project go longer than that, then at least break it up into several six-month subprojects. Secondly, make further funding of the subprojects contingent on the successes of the previous tasks. This will encourage internal staffers and outside contractors to use good project and risk management practices between milestones.

What Are the Odds?

If the preceding seems a little too touchy-feely for you, then let's consider the different approaches quantitatively.

All IT processes are part of an information supply chain. Each sub process is a discrete unit of work that can be optimized (or not). Take, for example, the simple case of processing a credit card application:

1. The customer completes the application.

2. The data is keyed into a computer.

3. The computer computes a credit score for the applicant and either

  • Denies the application or

  • Approves the application and sets an initial credit limit.

4. A physical credit card is created and sent to the applicant.

5. The applicant activates the card by calling a special toll-free number from his home phone.

There are only five basic steps in this supply chain - most mission-critical processes have many more. Let's assume that you wanted to optimize the entire process. What would be your chances of success in doing the whole thing in one fell swoop?

For the sake of the exercise, let's further stipulate that you're very good at your job and that your first attempt at optimizing any one of these steps will be 90 percent correct. This means that your odds of bettering the whole process in one large project are 0.95 - or 59 percent. That's right: You only have a 6 in 10 chance of fixing the whole thing the first time out - and this is a relatively simple case!

On the other hand, if you attempt to fix only one step in the process, your odds of success are 90 percent. Where you fail (and you will fail - at least a little), you can make corrections because the incremental cost of repair is small. When you're done with one step, you can move on to the next.

The problem, of course, is that CFOs and other corporate managers want to know the cost of fixing the whole thing upfront. There are budgets to be planned, and these budgets exist on spreadsheets that must be filled. Resign yourself to the fact that it will be nearly impossible to predict that number - especially as the number of steps in the supply chain grows. Instead, propose only to fix one of the steps and give it a finite budget. (Don't forget to budget a little extra for the corrections you will inevitably have to make after your first pass.)

Tell whoever controls the purse strings that you will provide a business case for fixing each of the steps individually and will tackle only one step at a time. This creates two things CFOs really like - accountability and fiscal discipline.

At first blush, you might be thinking that this approach will substantially elongate the time frame to complete any complex IT project. This is not so. It has been my experience that projects that take an incremental approach toward completion almost always cost less and conclude faster than all-in-one modernizations. You simply waste less time and money fixing mistakes.

Dave Rensin is CEO of consulting firm Reality Mobile LLC

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about 3M AustraliaBIASHIS

Show Comments