Blog

Paul McAteer, Head of Project Delivery, Pulsion Technology

If you have spent any length of time within the IT Industry, you could probably point to a project that you know of that has failed. Some have done so more spectacularly than others, with the occasional few unfortunately making it to the wider media, just to add insult to injury.

So, what is the extent of the problem? The Standish Group’s 2015 Chaos report illustrates a project success rate of only 29% in 2015. Standish Group has been reporting on the software development industry since 1994 and 2015’s figures for success are only 1% up on the year before.

Why is there such a large rate of failure in software development projects? Regardless of whether this is an internal business project or has more of an external focus, what are the common mistakes that seem to be made again and again? This 3-part blog series will consider some of the reasons why projects fail and what you can do to mitigate against failure in the future. Part I looks at requirements gathering.

Clear requirements gathering

The earliest and most important stage of a project is the requirements gathering stage. Regardless of whether you are managing a project on an Agile basis or Waterfall, understanding the scope of the project is key to its success. It’s very unlikely for a traveller to set off on a journey without knowing where they are going, how they are getting there and what time they need to arrive. Same theory in general, applies to a project.

Trouble can start if the stakeholders have difficulty agreeing on the aims and objectives of the project internally. Clarifying that all key stakeholders know and agree on what they need and want, (and have documented and shared this internally) makes for a positive project kick-off!

Making assumptions, as we know can often lead to misunderstanding, frustration and unintended consequences. So, when it comes to the stakeholders communicating their requirements, this needs to be done in such a way that the project team fully understands and is able to accurately restate the requirements as an acknowledgement of their understanding.

Are the requirements separated into functional and non-functional? It’s important to distinguish between these as they deal with very different aspects of the delivery, but together paint the full picture. Just delivering on functional requirements could miss out entirely on important factors such as usability, scalability and performance – adversely affecting the expected characteristics and attributes of the end product or solution.

On the odd occasion that the stakeholders do not fully understand what they need or want, then it’s up to a skilled Business Analyst to elicit the requirements with a great deal of importance placed upon gaining consensus and approval on the outputs from all the appropriate key individuals. Conflict within project stakeholders is much more difficult to resolve when the project is in flight.

Working to an agreed set of requirements should help set the project on the right course regardless of the management process and goes some way to ensuring a positive outcome.

In the next post, we’ll take a look at the role of a project manager and their management approach. If you need project management help or have any questions, contact us on info@pulsion.co.uk

Pin It on Pinterest