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

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

2. Experience • 32 Years IT Audit/Systems Management/Controller • Oracle, SAP, Other Packaged Software • Installs, Upgrades, Systems Interfaces • Business Process Redesign

3. 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

4. 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

5. My Top Ten List • Warning signs of pending problems • Everyone wants to be successful • Deadly games to avoid

6. 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!

7. 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!

8. 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?

9. 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!

10. 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?

11. 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?

12. 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!

13. 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…..

14. 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.

15. 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.

16. 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”