Software development projects - why do some projects fail?
It’s always interesting to hear about a software project that’s gone wrong. Not because of schadenfreude but because it’s interesting to see how the reasons are often very similar; there’s a small set of things that cause big problems on a project. The good news is they are easy to avoid if you do a bit of careful planning.
What are the reasons?
- No real business case or poor buy-in from senior stakeholders. A project needs strong foundations - it needs a good business case and it must have buy-in from senior staff. It gets harder and harder to manage a project if the people above you either don’t understand it or privately think it isn’t worthwhile. Every project needs a project board that meets regularly look at the project in a wider business context.
- Poor planning - that usually means the requirements are just not understood. Software can be complicated - not a technical level but at a business process level. It can take time to unpick what a client really wants and then design software that works across the different user groups. Fairly simple business processes can turn into complicated workflows when multiple teams are involved. Pressure to keep the price down during the sale and unreasonable deadlines can make it even harder for the project manager to get to grips with real complexity. Plan the project carefully - talk to all stakeholders - and set aside reasonable contingency.
- A team that won’t (or feels it can’t) pass on bad news to the project manager. There’s always somebody on a development team that knew the project was going to fail before the project manager did. The right team culture encourages open discussion of problems. A list of issues and risks that gets a slot on the agenda at the team meeting is a good way to get people to open up about problems that they know put the project at risk.
- A lack of technical expertise in the development team. Every development team needs at least one or two seriously good developers. They are more productive - maybe 5 times or more productive than the least experienced members of the team - and they have broad project experience and are more likely to spot and then flag up potential problems early. Inexperienced teams flounder and find it hard to give honest estimates when the project begin to slip. Make sure you’ve got sufficient technical expertise in the team.
- A badly organised client team. Clients need good management. Either they have their own project manager or you have to do it for them - you organise the client, get them to clarify requirements and make sure they are happy when they review work in progress. Things go awry - budgets and schedules - when clients begin to struggle to manage their own internal stakeholders. A complex fixed-price software development for a client with multiple internal & external stakeholders needs careful management.
Another interesting thing about projects that go wrong is that you can always point to something in Prince2 that, if you’d done it right, would have prevented the problem from occurring. Prince2 sometimes gets a bad press - too bureaucratic, too many processes and controls, not agile - but there is a lot that’s good about it. Breaking projects down into stages, lists of issues and risk registers all make sense. The trick is to pick the right tools, match them to your project and then use them with the team in a way that facilitates progress rather than one that creates an extra layer of admin.