In the news this week are the gory details of yet another IT project disaster with thousands of customers of a major UK high street bank being inconvenienced, so why is it so common for IT projects to go badly wrong and what can you do to avoid them.
I’ve worked in the IT industry for over 30 years and it is depressing to see how IT project failures keep occurring. When you look at other industries such as construction and aviation they continue to improve their performance and safety records, but IT projects have a bad reputation for going wrong, so here are my tips to help you avoid your project turning into a project disaster.
Start with the right team
In my experience the most successful projects have the right team involved at the start. It is essential that all parts of an organisation (including customers) are part of the project planning and implementation process. Too often IT systems are created and launched without the people who are most affected by them having input from the start.
Technical components
At a very early stage the project team should agree on the technical components which will be used to deliver the project. It is important that the technical components which are chosen are mature and the technical team have sufficient experience in delivering projects using them.
Proof of concept
If there are any doubts or questions about the ability of a particular technology or component to do what it needs to as part of the project then I would recommend spending time on a proof of concept. This will allow the technical team to try any technologies and ensure they are fit for the purpose they will be used to deliver the project.
Be honest
If you were asked by a senior person in your team to run a marathon tomorrow in under 3 hours, then the chances are you would decline. In 3 months time, with the right preparation and training, then it might be a more realistic request – but only you can really know.
If you are part of a team responsible for delivering an IT project then it is important to express any concerns you have about timescales, ability and resources. There is normally a time pressure to deliver an IT project and because certain elements like user and capacity testing can only be done at the end, then these are the elements which can get squeezed.
So you owe it to yourself and the project team to be honest about the ability of the team to deliver the project successfully within the timescales and budget available.
Deliver in phases
Sometime this isn’t always possible, but if you can break the delivery of the overall project down into more manageable phases then this can reduce the risk of a disaster. A phased approach also gives the project team the ability to change the deliverables of future phases based on their experience and user feedback of what has been delivered so far.
Testing
This is the obvious one but it is also very apparent from some of the IT disasters which have occurred that clearly sometimes systems are launched which haven’t been fully tested.
If you don’t do sufficient testing then you are putting the whole project at risk, so don’t compromise on this one.
Data migration
If your IT project involves the migration of data from one system to another or you are replacing an old legacy system with a new one then you must test the migration process thoroughly before the deadline date. I would recommend using a copy of the latest live dataset to use as a test to make the process as realistic as possible.
Test platform
I would recommend that the platform which will be used to test the final project is as close as possible to the final live environment. This will help the project team measure the overall performance of the system and ensure that the live system will be able to cope with the predicted amount of user and processing power required.
Stress testing
If the system which is going to be delivered is likely to experience certain peaks in demand then it is recommended that the system is tested to replicate this level of activity. This is particularly important if the users of the system may have deadlines which can result in a high level of activity over a short period of time as deadlines approach. Again, testing is so important.
Plan your go live carefully
So you’ve developed the system and carried out the testing and everyone in the project team is happy for it to go live. It is so important to have a detailed go live plan in place and to ensure that everyone knows their role. In my business we have developed a series of go live checklists which we use to ensure that all of the key elements have been covered.
The plan should cover all elements including the setup of the platform, software versions, security, data migration and final testing.
I would also recommend agreeing a realistic timescale for making the project live and to add in some contingency in case anything unexpected should occur.
Have a backup plan
Sometimes despite all of the planning things go wrong. I would recommend having a backup plan which is agreed with the project team before any go live is attempted. The reason many IT projects fail is that systems are launched and made live when they are not ready. It is better to recognise this in advance of go live rather than making a system live and then spending days or weeks trying to fix it which just frustrates and annoys users.
As part of your go live plan you should set internal deadlines and be prepared to stop the deployment or roll back to the original system if these deadlines are missed.
Members of the project team who are responsible for making a system live need to be brave enough to recognise when things are not going to plan and to roll back, learn from the experience and then reschedule the go live again. This isn’t always easy but is preferable to fixing a live system which is deployed too soon.
