You’ve done it! The project came in on time and on budget, with the users conducting all their tests and finding that all of the specified deliverables are up and running. Time to rest on your laurels? All the challenges are over? While we don’t want to sound like merchants of doom, the truth is that, from a business point of view, the project has only just started – the anticipated benefits now need to be experienced and this period is most critical. Business needs to take ownership of the system and make it work for them.
The most obvious risk is that some functionality of the application is missing or incorrect, moreover the specification and the testing had not included it. ‘Where’s our class list with student photos, email address and employment details – like we had with the old system?’ went up the cry when our new student records system was implemented. ‘What do you mean “you entered phone numbers in that field that we’ve just removed”?’ While ‘key users’ are often involved in many projects, it is rare that all users are. Some users of pensioned-off legacy systems will have been able to get that clunky old system to sing like a bird. They will have accumulated a trove of workarounds that have delivered important functionality. Data fields are reused; reports used for quite different purposes than their titles suggest; and informal mechanisms, such as extracts to Excel, have become essential.
The next challenge comes when the application is fully loaded with data, and real workloads accumulate. Here the performance in terms of response time, capacity utilization and batch process operation becomes apparent and it may fall short of the promises. Some applications simply don’t scale. They work fine with 1000 records but crash or stall with 100 000. One hundred concurrent users are fine, but 200 demonstrate serious degradation.
Perhaps this problem isn’t immediately apparent but comes to light only when the business is much more successful than anticipated. Take-up rates for on-line banking and stockbroking were excellent, maybe more booming than even the optimists expected. And optimists get short shrift in banks!
When the application is fully tried and tested, working satisfactorily, there remains a significant risk. Is it flexible enough to accommodate the totally unanticipated enhancements and modifications that will be required? Browserbased workflow? Integration with a key customer or supplier? Wireless networks, PDAs, customers with mobile phones, SMS or instant messaging? Under this category must also be the ability to cope with inevitable upgrades to operating systems and other infrastructure components.
More dramatically, mergers and acquisitions are seldom decided on the basis of the compatibility of IT – and due diligence may not explore this issue thoroughly. So the two IT heads have to work this out – which may not be realistic if they’re fighting for one job. A realistic and detaile compilation of the funds required to merge or replace the IT may take some gloss from the exciting merger announcements.
And then, the final hour approaches, the application is becoming frail, hard to support, hanging on by the skin of its teeth. The risks are increasing and will continue to do so. Time to pull the plug. But the assessment of frailty will be different between key players in the organization. Whose counts?
— Extract from Beating IT Risks, Chapter 1: Thriving on risk —