If you've spent any time in project or product management, you're most likely familiar with this customer requirement image..

Generally, we could define a successful project/product as one that is delivered on time, within budget and cost and delivers value in line with stakeholders’ requirements. However, as have been identified by several studies, we still have a high level of project failures; even with agile methodologies.

I’ve curated a few reasons that jump out to me below. These are majorly from my experience and in my opinion (though quite a few have been identified by bodies including PMI and The Standish Group)

1. Sentimental attachments lead to sometimes cloudy judgment. When you are super close to the product, you are sentimentally attached; you most likely will make sentimental decisions as against data driven ones. It’s like having and raising a baby… you just can’t separate yourself from some things. Well, unless you‘re like my mother shaa.. that woman will beat you like she didn’t carry you for 9 months then walk up and down Oluyoro in the middle of the night to induce labour..

2. Managing stakeholder requirements (i.e. gathering, interpreting and communicating) is one of the most important steps to ensuring the right solution is developed. As depicted in the image above, the client’s request usually ends up different from what gets built. So  you find that earlier in planning and development, ideas are usually vague, then as development progresses and the product begins to take shape, stakeholders tend to be more articulate in stating their requirements more specifically. Why? Well, now they have a point of reference basically. I know you’re thinking err… what happened to mockups and prototypes? Yes. They do help to create a less vague interpretation of the stakeholders’ requirements and the more detailed they are the better. However, unfortunately, because many times, we want to go to market NOW NOW, we skip a few steps and as expected, they come back to bite us in the behind.

3. Scope creep is the devil. As the product becomes clearer during development, ideas and/or market realities evolve which means that the team needs to reevaluate initial requirements and incorporate changes. Sometimes this means an entire change to the drawing board which naturally means more time and resources. In a waterfall environment, major changes such as these would most of the time lead to the death of the project. With Agile environments, failing fast and failing forward is the mantra.

4. Definition of Done. Ideally, the definition of done (when a backlog item is done) should be agreed upon before development; but somehow, you find that the goal post keeps moving. Moving goal posts are typically as a result of increasing clarity of how we want to deliver value as the product unfolds. This as well can be solved by setting clear goals during design and planning. No matter how small the increment is, breaking it down into clear achievable parts, with visual representation where required helps remove ambiguity.

5. Relegating requirements management to just a project document. So it’s one thing to gather requirements and document them; it’s another thing to actually have a process in place to manage them. Having a defined process helps the team to be ready for changes and adapt to them properly. Processes can also be adapted to fit current realities; however, we should have a baseline – always.

6. You cannot not involve stakeholders enough. Lol… that sentence is so weird, but seriously, ensuring that all key stakeholders are carried along at every step of the way saves a lot of time spent on rework. Product Owner wants to make sure that the goal is clear. You want to repeat your understanding of the product/project objective, features and roadmap, sprint goal, delivery targets and everything in between because in the long run, after all your late nights and early mornings, if your stakeholders are not happy with the output… oh well..

Ok.. so basically, what I’ve found is – clear definitions of goals, processes and acceptance criteria are key to achieving success and clearly understood and effectively managed requirements are the oil the grease the wheels helping to avoid design rework and reducing development failures. Here’s a link to an article about requirements management that I find very interesting.