Cliff's Top Ten Ways to Ensure New Software to Fail - Absolutely Guaranteed!

Cliff Billingsley

Experience 32 Years IT Audit/Systems

Management/Controller Oracle, SAP, Other Packaged

Software Installs, Upgrades, Systems

Interfaces Business Process Redesign

Software Failure Cost Outside losses range from 450 down to

202 million for 2002 What about inside losses from failed

new systems? $6.5 billion for FAA Advanced

Automation System $3.3 billion for failed IRS system $330 million for delayed Denver Airport

baggage handling system $300 million for California tax flop

Hidden Software Failure Cost Seldom evaluated or reported Under realized systems Keep pouring in money until

something works Declare success and ignore the

rioting masses Ignorance of what might have been

My Top Ten List Warning signs of pending

problems Everyone wants to be successful Deadly games to avoid

No. 10 We are not certain exactly how we

want to use this software so let’s not finalize the design until we have a chance to see how the software will perform after setup and testing

OR How can I exceed my implementation budget by 200% and end up with a system that no one really likes!

No. 9 We purchased G/L, A/P,

Purchasing, A/R and F/A and scheduled all to go live at the start of the fiscal year

OR Instead of minimizing our risk by placing one or two modules at a time in production, why don’t we overload the users and IT by doing all five at once and see how they deal with the overload!

No. 8 Printers? Sure we have a printer

setup for you to test on OR How can we create an

immediate crises and be certain that no one gets anything out of the new system when it goes into production?

No. 7

Concentrate on testing the basic business processes. Don’t worry about the isolated things that you only do once in a blue moon. We will deal with that stuff as it happens

OR It’s always the little stuff that kills you!

No. 6

We want you to participate in the testing process. Please allot time for any testing design, performance and evaluation that you feel necessary before we go into production

OR What is the best possible way to ensure that users do not properly test the new system before production?

No. 5

We made certain that we will get acceptable response time in the new system because we put a “three second response time” into the deliverables of our contract

OR How stupid do you think the software vendors really are?

No. 4

Let’s get the minimum infrastructure that the vendor recommends to run this software. I don’t want to pay for more than we can effectively utilize. We can always get more later if we need it

OR Why don’t we really turn off the users to the new system by giving them terrible response times!

No. 3

Training costs too much and we will never need to know all of this stuff; let’s hire “consultants who already know the software” to design and setup the system

OR Pay now or pay again and again and again and again and again later…..

No. 2

Don’t worry about the interfaces until we get the new systems installed and tested. Interfaces should never drive the new system.

OR We only put one round in the chamber and anyway it’s the system user who has to point the gun at his head.

No. 1

Don’t include the users in the basic setup and business workflow design because they really can’t understand this technical stuff especially workflow design.

OR How can we get the least buy-in from the user community so there is absolutely no ownership of the new system.

What can you do? Make project teams accountable Establish policies about user

involvement in new systems and upgrades

Establish strong internal user groups who can make their opinions heard

Always be wary when you hear one of the “Top Ten”