Understanding Risks in IT Projects

Understanding Risks in IT Projects


It is a shared practice that when a business, whether small or large decides to attempt an IT project, the first thing a project manager will do is to whip out a Gantt chart and starts planning including drawing up the budget, timeline and the expectations. This is then presented to the board (in big businesses), or the owner (in small businesses) for approval. Then voila… everything should work according to plan, with some minor adjustments factored into the plan, right? Wrong… this is a shared misconception of many, who would ultimately learn that in any IT projects, big or small carries risks, and the bigger the project is, the bigger the risks and the stake will be higher. These risks may ultimately cost the business heavily in terms of monetary losses or damaged reputation. This can happen in all sorts of unthinkable ways. That being said, there are small IT projects that did have harsh negative repercussions in addition. Trying to “dive in” without first spending some time doing ground work and talking to applicable parties while exploring the bigger picture is just a recipe for disaster.

The Devil is in the Details

The shared thing that happens when a project is first tabled is assumptions are made. While it is easy to make assumptions, the problem is some of these may appear true until someone truly does the work and found it otherwise. This can happen despite the best intention of all parties. For example, I have come across many times when certain third party products (software and hardware) promises certain specifications, only to fail to live up to their promises when it is truly put to use. The sales team from these third party companies typically tried very hard to sell and make promises to the procurement team, and the buyer was convinced that it was the right solution without running past the stakeholders, until the guys who do the work truly try to use them. Without naming any companies (and risk getting sued), one multi-million dollar company that specialises in producing software libraries promised that their new product would sustain the legacy interface, persuaded us to upgrade at the cost of £10,000, only for us to find out that it was not 100% compliant. The results? A major software rewrite that almost doubled the initial cost as it is not possible to have a uncompletely half-baked solution. Another multi-million dollar shopping cart company endorsed by Google stated that their automated payment system fully supports Google checkout for digital goods, only for me to point out after testing that they failed to automatically email the license meaningful upon buy. It has to be manual and that defeats the concept of automation. When it was brought to their attention, it took them nearly 4 weeks (and counting) to try to fix their bug. Needless to say, these problems cost money and we will not be reimbursed by the faulting party. I should be glad then, that at the minimum some companies have the decency to concede and fix them. Shockingly, some already refused point blank and blamed others, including their own customers for the failure of their own products.

Small changes could potentially have a very BIG impact

I remembered too well that at many times, when asked how long it would take for a seemingly easy software change, some talented software guys would say, “Ah.. that’s easy, it would be a 5 minute job. “. In one case, I protested and said that it would take 2 days, and clearly everyone was thinking that I was trying to be funny. The results? The job took just under 2 days. Why? It was because the actual job to do that may take only 5 minutes, but there are other associated costs, such as integration and testing, not to mention house-keeping. Before the job is carried out, one must carefully look at the bigger picture and think what the implications are. This could either consequence in an unexpected problem somewhere far away that seems unrelated, or breaks something obvious. In this case, the 5 minute job truly resulted in allowing the end user to potentially click a button, and screw up the system.

In another case, I nevertheless remember that I have told a former colleague certain steps that must be performed just before doing the first official release. He proven it after I have spent an hour with him. It was all in the notes. The company has spent a great deal of money and man hours on security and encryption as the new laptops contain very sensitive information that would be highly useful to criminals. The user account has been locked down, privileges removed, and all precautionary steps were taken in case any laptop got stolen. On the eve of the major release, in his haste, he had skipped one important step. The results? Nobody could log into the laptops after a week due to a security auto-lockdown kicking in by design, and the company then had to issue the administrator password to everybody as it severely impacted their operations. The release of the administrator password negated the whole huge effort and put the company in harm’s way. Weeks were spent thereafter to undo the damage.

In another company many years ago, a small change to fix a bug was applauded only for the customers to vigorously complain about the fixes. The reason? These customers had unwittingly relied on that bug in their work flow, and by fixing that bug; we had truly disrupted their workflow and consequently did them a huge disservice. Hence there were only 2 choices, to reintroduce the bug and keep the customers happy, or to develop additional functionality so that a different work flow could be introduced. The management decided to do both.


In a lot of the project plans, there is no mention of the maintenance phase. Projects are expected to complete and one FTSE 100 company already closed down the budget code upon completion (which method that once the project has been delivered, there is no more money to do anything else). In reality, there is a tail off phase in any projects where bugs WILL be found despite heavy testing, or the usability may not be quite right. For example, a project to upgrade the telephony system to Avaya had to be changed after a release, as the call handlers work in a very strange fact. I only found out after spending an afternoon training the first operator, when I noticed that he had to manually jot down the phone numbers on a piece of paper that was displayed after an incoming call, in case he had to ring the customer back when the line dropped. Needless to say, I then introduced a “callback” button post-delivery for that project, which made their life easier. No input on this was given by the stakeholders during the 3 month period.


In conclusion, there are many risks that are hard to avoid, but one should at the minimum find ways to mitigate them and do not ever underestimate the risks involved, no matter how small a project is. There are many factors that do not allow the luxury of time for additional fixes, for e.g. projects that are geared for the Formula One event, or the Olympic Games. clearly any delay would average disaster and the project is as good as dead. In scenarios like these, a compromise must be made, for e.g. can we deliver less, with less features or functionalities, but crucially we deliver on time?

Testing is of paramount importance. Testing must be done extensively already after a small minute change. Hence the best practice is to do a lockdown of releases (i.e. no more minor changes, quick fixes etc), and to test that release thoroughly. The stakeholders must be made to understand that while any small change may seem innocent and risk free, the reality is, no one can provide a 100% guarantee that it is. A small change may consequence in the customers unable to buy goods on your website, or charged twice. Stakeholders must be made to understand that any quick fixes will invalidate any past lengthy tests and a pain-staking re-test is necessary.

There are also scenarios whereby what happens if the stakeholder fell sick? Or had a car accident? I remembered that once we were days away from a major first release, I fell terribly sick and was shivering the whole day. My phone rang continuously as the project manager was desperate to find out how ill I was. I was too sick to already answer the phone. Fortunately I was back at work the next day but it was a close call.

The risk of any IT project, post or pre-delivery is huge. Take for example the recent Royal Bank of Scotland’s computer glitches. The failure was due to a slight human error, but the consequences was devastating, at the minimum to the thousands of customers who could not access their money in the bank, or make mortgage payments, or already complete their house purchases (crucial for those who bought at auctions where delays may average huge capital losses). Some could not already buy food, or fuel.

Understanding the risk is crucial in any IT projects and the stakeholders must be made to think of the doomsday scenario. Risk mitigation is basic and there must be contingency plans for these scenarios. While this may sound pessimistic, it is crucial to the planning, like having a fire assembly points where employees gather in case the building burns down.

Dr Kenneth Zhang is a software consultant specialising chiefly in Microsoft technologies for the past 13 years. He is the owner of ManageForm.com – http://manageform.com (Online employee forms management) and Kenicom Ltd(Software Consultancy). He has been involved in high profile projects, such as the multi-million pound IT fleet modernisation at the AA (leader in the UK for means breakdown emergency sets) in 2010 and the Formula One Project at BskyB (which has been broadcasted across the world under Sky Sports) in 2012.

Published date – August 2012

leave your comment