Top 10 IT Project Mistakes
It’s rare for an IT project failure to become a trending hashtag, so spare a thought for the poor folk at the Australian Bureau of Statistics. In 2016, after heavily promoting online census submissions by advertising “Get online on August 9”, they were faced with the nightmare scenario of their website failing on the one critical night everything needed to go right.
As an IT person, I often wonder why my industry finds it so hard to deliver. Every month or two it seems there is another high-profile failure. And clearly the doubts exist on the client side too. Research participants rated the chance of their project’s success at less than 50% and the average final cost at over twice the original estimate.
Read this article in the CIO magazine as one of many articles on this subject.
This table is another illustration of the high failure rates of IT projects. It is also highly likely these numbers under count project failures as in my experience a lot of failed projects are disguised as successes to save face. Click here to see the full report from the Standish Group.
Despite these dire statistics, every business today is inevitably becoming more of a tech based business, and we must forge ahead with our digital projects, or get left behind. But is failure really just down to a flip of the coin?
In my experience companies inevitably make one, some, or all of the same 10 IT systems project mistakes – and if take the right precautions and avoid these you won’t become just another statistic.
Mistake #1: Not being clear on the purpose.
This may seem obvious, but there is often a big divide between what each of the different stakeholder groups want and expect from a new system project.
A classic example of competing agendas arose on a large Axe Group IT systems project. The Project Sponsor wanted a totally new system, quite different and better than the one being replaced. The Head of Sales on the other hand wanted something that looked and worked just like the old system so that agents using the new system would not get confused.
Mismatched goals need to be exposed early. Don’t make the assumption that a long RFP process means there is already clear consensus on scope. Conducting facilitated workshops early helps to ensure everyone is on the same page. In our case, we used the outputs of these sessions to devise an entirely new third solution that met both parties’ needs.
Mistake #2: Getting caught in the sunk investment trap of past IT systems projects.
Many companies mistakenly persist in pouring money into projects to patch up or add onto legacy IT systems rather than cutting their losses and replacing the old system. The arguments to retain the old system will likely come from people who:
- want to preserve the technology they are skilled in
- do not want to write off the capitalised value of the old system in the accounts
- are worried about the replacement project failing
- are nervous that change may reduce their status
Clinging to the past can be directly and indirectly costly. Over the remaining lifetime of the system the extra cost of persisting is likely to be considerably higher than if they moved to newer technology.
It is inevitable that you will need to keep your technology up to date or go out of business so you may as well get started now. Rather than the 4 issues above and any others stopping you from replacing your systems, think of them as normal challenges of any project that need to be addressed.
To counter the argument that the current system is highly capitalised and you can’t afford to write it off, you need to understand the true total cost of the system, including the ongoing maintenance costs, the cost of enhancement projects and the lost opportunity costs of projects that can’t be delivered or will deliver late. Unless you are in a declining business with no real need to change then the new system is likely to be considerably cheaper over its lifetime.
Mistake #3: Not taking the new IT system for a test drive before you buy.
You wouldn’t buy a car without a test drive, but many IT systems are sold without the buyers having an opportunity to test it out. With the growing number of stakeholders and the complexity of RFPs it can be difficult to find the best fit-for-purpose system in the time normally provided, by which time usually a large portion of the budget has already been committed.
With the average system lasting around 15 years and costing several million dollars to implement, consider investing a smaller sum in a pilot project to validate and test the potential solution rather than committing all in to a multi-million IT systems project up front.
Mistake #4: Just because you can, doesn’t mean you should.
When you prepare your RFI and RFPs it can be tempting to consider that every want is actually a need. But a surprisingly high proportion of system functionality is rarely used, and a lot is never used. An example we had of these extra ‘bells and whistles’ was a systems project where the client wanted to allow for up to 5 people to be on the same life insurance quote. After the first couple of years, only 2 quotes ever had had more than 2 people on them.
It’s a great idea to consider all the possible scenarios as you plan your new project. But consider that 80-90% are actually rare situations which can be handled through an exceptions process. Keeping things simple from the get go will save time and money. And remember that additions can always be added in future upgrades.
The initial roll out should just be the minimum working product - although you must select a technology that easily supports adding on extra functionality and adjusting what you’ve already built.
Mistake #5: Skimping on the support infrastructure for your new IT system project.
A full IT system has a number of components beyond the code or the UX design. Ignore these at your peril. Just about every enterprise system we’ve seen has suffered slow responses because of under investment in critical infrastructure. Plus many provide developers with under-powered PCs, have tedious manual release processes, no automated regression tests, unit test and or build processes, a lack of documentation, and do not have a set of identically configured environments suitable for each stage of testing.
Like adding a short expressway, underinvestment only gets you to the next traffic jam faster. Avoid the risks that come with compromised development environments and practices by ensuring every element is high grade.
While it is not cheap to have the best quality infrastructure and supporting processes, taking short cuts will inevitably backfire.
If you don’t have the budget for this consider scaling back the entire project, otherwise it is like buying a nice new car and running old, bald tyres; it’s okay until it rains!
Mistake #6: Not reassessing during a project whether the system is still the best choice to save face.
A disappointingly common scenario we see is a system in development for years that finally goes live only to be scrapped a few months later. It seems almost everyone on the project knew it was not going to work, but no one wants to take responsibility for canning the project mid-stream.
Due diligence will prevent a lot of costly mistakes, but it’s impossible to be sure about everything in a fast-moving world. What may have been the best option when you started may no longer be the case as you progress. Sometimes even the best people get it wrong. You need to be prepared at any stage to say you’ve make a mistake. The earlier you do, the more chance you have of a recovery.
Mistake #7: Not maintaining a steady pace and clear focus.
In the very early stages of a project the level of excitement and interest are high, and a fast pace develops organically amongst the team who want to get the project approved and onto development. However, once the project starts, teams slip into cruise mode as it looks like there is plenty of time and money available.
Fast forward to a few months out from the go live date and panic sets in when the team realise they’re not even 50% done. In the rush to get things over the line, the fancy stuff is dropped, daily stand ups (aka crisis meetings) are held and work days stretch out to midnight. And after ‘completion’ the key project people are burnt out and leave. Because the budget is exceeded there is little money for maintenance, and there is usually a backlog of fixes so real improvements fall away to a trickle.
To achieve a steady pace, you can break up big projects into a number of smaller ones run in an ‘agile’ style with smaller and more focused teams. These should aim to deliver real functionality each fortnight or so into a test environment and then every 3 to 6 months into production.
This dynamic can continue after the core functions are delivered as there will always be new improvements and technology updates needed.
Mistake #8: Not focusing on delivering a working system.
A large project will always need people who are doing tasks other than actually building the system, such as updating the business and technical specifications, monitoring project risks and writing regular project reports for management. While this work is important, it can come at the expense of actually building a system that works.
Beautiful documentation is a nice to have in the early days after launch, but a well-designed and intuitive system shouldn’t need a manual for day-to-day use. Ensure your team are working to a thought-out plan that lets you deliver valuable functionality to the business every week.
As mentioned above projects need to deliver working functionality early - ideally at least every 2 weeks so that the test team and business team can verify the progress and importantly adjust the scope as you go.
Mistake #9: Running projects with huge teams.
A project needs people to carry out tasks and actually build the solution, but past a surprisingly small number, adding additional people is more likely to lead the project to be strangled by bureaucracy than to increase the total output. Larger development teams also tend to focus on their own small sub-projects which can cause issues when the sub parts are brought together.
Smaller teams are the key to innovation. There are some great Harvard studies that show small teams often beat large teams, through their ability to make decisions more quickly, collaborate more easily and never lose sight of the software forest for the feature trees.
The US Navy Seals prefer small teams of 4 to 7, and in every project I have been on there has always been a core group of 3 to 6 that do the bulk of the work.
If the project is very large then you should manage this by breaking it out by business area and by technical function (say requirements gathering, coding, testing, infrastructure and data analysis) so that you have a number of smaller teams with their own goals, rather than a single large team.
And finally… Mistake #10: Not building a team of talented and diligent people.
We think of space travel as being one of our greatest technical achievements, but in 1961 when Alan Shepard became the first US astronaut, every single calculation that got him safely into space and back was done by one human (and a woman at that). That’s right, people are always the most important factor contributing to a project’s success or failure. And yet in many projects people are referred to as ‘resources’ or by their skill as in, “we need 20 resources”, “10 UX experts”, or “10 coders” as if they were all interchangeable widgets.
Today’s technology is extremely complex. The best solutions like Google search may look very simple on the surface but there are some very smart people and a lot of complexity behind that clean facade. To ensure success you must assemble a talented and dedicated team, and most importantly look after them.
In selecting people you should not just focus on specific technical skills but look for people who have the ability to learn, to work in a team and bring a wide range of skills to the table. It’s better to have a group who can work together and all contribute to solving issues rather than highly skilled technicians that need to be closely directed.
What big IT systems project mistakes have you seen?