Menu
… and what can you do to stay on track?
It is widely recognised that IT projects fail more often than they succeed. There are lots of software project failure statistics ranging from 60% to 90% failure (depending on where you’re getting your information from), but everyone’s agreed – once you’ve got a project started, it’s far from a done deal that it will finish well.
There are many challenges to oversome in IT project management, and the cost of failure can be high.
The truth is that projects are often easy to start but difficult to run well. This is usually due to not recognising the critical tasks that need to be done, or recognising them but not knowing how to do them well. In this article, we go over the main things that tend to be missed out, what can be done to put things right, and the tell-tale signs that a project is heading south.
If you’re managing an IT project in trouble or you’d like to make sure you have the risks covered, this article is for you.
Reading time: 7 minutes
“We know what we want from our project. We have a list of six key objectives defining what we’re trying to achieve. Surely that’s enough?” Perhaps not.
Requirements describe, at the right level of detail, exactly what is needed from the solution, and they are one of the key omissions in most IT projects. They aren’t a nice-to-have – they’re the fundamental building block of the project, and if you skimp here, you can expect bad things to happen down the line.
Having said that, striking the right balance of details is crucial. Too much details and chances are you’ll just be producing documentation that’s no longer up-to-date by the time you come to rolling out. For that reason requirements should concentrate on what the users need out of the software, not how to do it.
If you don’t have requirements to the right level, critical components needed from the solution will probably not be included. Unfortunately, you usually don’t find out until the end – after you’ve bought or developed the software, and you’re too far down the line to backtrack.
“Requirements are not a nice-to-have, they’re the fundamental building block of the project.”
Most projects involve a certain amount of conflict and confrontation. There’s no avoiding this – stakeholders will disagree about the project requirements, argue with each other about which software product is best, and refuse to be involved if things don’t go their way.
The way to deal with differing opinions among stakeholders is through leadership, good collaboration and communication. But it’s not easy – you have to face the problems head-on, and there can be a certain amount of confrontation.
But if you exclude stakeholders, or don’t consider their concerns because they’re too challenging, then the project will probably be considered a failure by at least some parts of the organisation.
Even where a project involves a lot of IT, people still have to use it as part of their jobs. If the software works on its own but it doesn’t fit in with the way people work, then the project will fail.
Nevertheless, many projects continue to run as though the only really important thing to think about and test is the software. Instead, a good project will look at the Whole Solution – how the software will fit in with the rest of the processes, the people who will use the software, and how their job roles are structured.
Also don’t forget to involve your HR department. Changes to job roles and the way people work might have consequences on aspects governed by employment laws.
Ensure you engage your end users at the start. Conduct interviews and surveys about their daily challenges and processes and get their feedback on what the project requirements are to make sure the initial requirements you defined early on are aligned with the requirements your end users have.
If the software is the only focus of attention, then it may work just fine – but if nobody uses it because it doesn’t work well in context, the project won’t be an improvement on the current situation.
Today, most software is procured from a third party rather than developed in-house. These solutions are often ‘off the shelf’ and it can be difficult to match your project requirements with software on the market. It’s very hard to tell from a supplier demo whether you’re actually going to get what you need.
Procuring a major piece of software should include sending the supplier clear requirements, evaluating their response carefully, and getting an effective demonstration of their product (ideally using your environment).
If a software product is bought without the right level of scrutiny and due diligence, it probably won’t do what you want it to do – but this will not be clear until after the contract is signed and you’ve started using it.
Once the software has been chosen, the relationship with the suppliers continues – for the rest of the project, while they help install and roll it out, and beyond, as they maintain it over its lifespan. A common problem is the assumption that software suppliers will do most of the work, and will do it well.
Good practice is to agree with the supplier exactly what services they’re offering, and to make sure they stick to it afterwards. The supplier can’t and won’t understand an organisation’s requirements in depth, so it’s up to the project to take the lead in business change. However, the supplier should be there to answer detailed questions and to help with any technical installation or integration.
Business change is often left until last because typically, it happens at the end of the project. At that point, it’s usually too late to do what’s necessary. In fact, business change should be thought about right from the beginning as part of every project task that’s undertaken.
It begins with actively listening to everyone involved in order to consider and/or align with their requirements, and communicating with them about what you’re planning. It means keeping them informed and involved throughout the project, and giving them the confidence that you understand what they need and why they need it. It is also about ensuring effective training and documentation , which might mean delivering something different to different people.
If business change isn’t properly attended to, it can mean the failure of the whole project at the final hurdle.
For a project to run well, there should be a Project Manager and a Business Analyst at a minimum. It is crucial to have both roles filled – the two jobs are very different, and each is as important as the other.
Broadly, the Project Manager ensures the project delivers on time and doesn’t go over budget.
A Business Analyst ensures the software solution is good quality and that it satisfies organisational and stakeholder requirements.
In many organisations, those running projects may be staff with other duties as well, meaning project management is not their primary profession. Even though they may be very experienced business people, they may not be able to deliver on all the IT project management activities without help.
There are a number of solutions to overcome the lack of project management resource:
Gillian has been a Senior Business Analyst and Project Manager for many years in organisations of all sizes. She started in the IT industry as a young programmer working in California, and then spent some years in Seattle as a business analyst in the banking sector.
When she came back to England to start a family, she stayed in the commercial area for some years and then moved on to the varied environment of a large public authority. She has now been consulting for nearly a decade, where she has experienced a wide range of projects in sectors from the construction industry to medical charities.
We’re here to help you overcome your IT project challenges. Start with our health check tool for software projects.