Many IT project failures have hit the headlines in recent years. I’d need more than one hand to count Australia’s monolithic IT projects that have gained public attention – and no…
Many IT project failures have hit the headlines in recent years. I’d need more than one hand to count Australia’s monolithic IT projects that have gained public attention – and notoriety.
The global numbers are no better. According to the US-based Project Management Institute, the failure rate stands at 17%, meaning that one in seven projects fails. Another report put project success rate at around 30%. That leaves a lot of middle ground for projects that are somewhere in-between.
There has been much navel-gazing about why this is so. An analysis of Britain's NHS project, which was claimed to be the world’s largest civil IT project stated:
“The system of systems that was to provide EHRs was initially designed by a large central team and intended as a complete “big-bang” replacement for the many and varied existing EHR systems.
It would have been far better to employ evolutionary acquisition, i.e. to specify, implement, deploy and evaluate a sequence of ever more complete IT systems, in a process that was controlled by the stakeholders who were most directly involved, rather than by some distant central bureaucracy.”
This gets to the guts of some of the gaping problems that software development projects often suffer. While there are many contributing factors, keeping users at arms length is a recipe for disaster. Without close collaboration, users are never going to adopt a new system. The other issue is trying to tackle everything at once. If there’s one hard lesson to learn, it’s that this inevitably results in requirements that are written so far out that they are obsolete by the time they get to production.
A better way to run IT projects
I’m a firm believer that how you run an IT project is just as important as what you’re aiming to achieve. There are five key pillars we’ve been using for years to achieve project success. These are:
1. Spend time at the frontline
You can’t delight the end users of a new IT system without fully understanding the problems they face. This means spending time with them, in their work environment and gaining empathy and insight – before prescribing what the solution should be. Sounds simple but often people are fixated on a certain type of solution without conducting the necessary exploration.
We use a design thinking approach to gain user buy-in and fully define the problem. While a client typically has broad business goals that go beyond the operational, the reality is that these can’t be achieved unless are using the system and creating quality data.
2. Allow for change
If there’s one constant in an IT project, it’s change. This is why we use an agile methodology, because it recognises that a software project will never be fully defined, and has the flexibility to accommodate change. Instead of addressing everything upfront, we prioritise. This means defining the highest value items, delivering a Minimum Viable Product and then making our way through a priority list. We do this using Sprints, typically short bursts of fortnightly production with regular client demos and feedback sessions factored in. This approach builds trust, transparency, and avoids the change request hell that typically follows a project with the all-at-once approach.
3. Avoid the custom cost and resource drain
It used to be that you had to choose between custom and off-the-shelf software, weighing up the balance of cost vs fit-for-purpose. But there are better choices available now. A core technology platform brings with it a huge array of built-in functionality that avoids having to develop everything from scratch. Yet it also delivers the flexibility to create multiple line-of-business applications that can be fully customised – and quickly. Our technology of choice is Microsoft Dynamics 365 along with SharePoint.
4. Minimise scope creep and pricing overruns
It’s easy to blow out a budget when you’re paying for development on a time basis (how long is a piece of string?). A better way to gain control is to pay via a fixed cost. We do this by turning requested features into a fully costed list, then allowing clients to prioritise and plan their spend. A word of warning though – many developers don’t have this capacity. We have honed our ability to price accurately through deep industry knowledge, years of experience, and use of a technology platform.
5. Don’t forget support
As IT projects limp towards the finish line, the reality dawns: there is no finish line. There will always be further development, user support and maintenance. And worse news – if an IT project wasn’t done well to begin with, spiraling support costs can blow out the project even further. The antidote? A fixed price approach to support that brings predictability, and the flexibility to change to suit requirements.