Programme and product requirements

Absolutely agree. Taking the time to clearly define requirements is essential to building the right product or service. Without well-documented requirements, how can we be sure our solution truly addresses the needs? And when it comes to testing, robust validation is only possible when there’s a solid set of criteria to measure against. In Agile, we use User Stories or Product Backlog Items to capture these requirements. Regardless of terminology, the goal is the same: to intentionally document both the outputs we want to achieve and the outcomes we aim for. As the good book says, "Write the vision and make it plain"—this applies in business as well. Clear, concise documentation makes it possible for teams to understand, align, and deliver successfully.

Paul Meredith, requirement and the lack of or the clarity of is an age old problem. Businesses often rush through the requirements phase eager to get the the out put but this is a false economy and and often a project/programme killer! Its essential that requirements are elicited successfully. What does successfully mean? In this circumstance it means: Assure the business requirements are gathered with the benefit of all parties Avoid gathering requirements in silos, failure to do so could lead to just that failure... Requirements are walked through and all parties understand their meaning and intent If you have a Product Manager/Owner they are invaluable to assure that the focus does not shift from the requirements (no matter the delivery methodology being used) Requirements can shift and evolve (thats life) assure constant/regular evaluation with all parties to assure that; a) there is a clear evolution of the requirement, b) the project/programme acknowledges the amend and ratifies the impact of the change, c) any evolution forms part of the project/programme artifacts and is tracked What is critical though is a project and programmes success is pinned to the requirements, so try to get them right!!!

With IT projects analysis is a major issue. First off you have the "Stenographers", who simply record the unstructured ramblings of the client. Secondly you have the "Hieroglyphs" who produce wonderful (and meaningless) process flow diagrams and expect non technical people to understand them, plus of course they are invariably wrong. Finally you have the "Protectionist" the individual who is the font of all knowledge on existing systems and is always on hand to save the day. With this person's involvement requirements start off with 'This is what program X does and we want the new system to do this plus these changes we identified" There are things that can be done to improve the chances of delivering something that is right, but this in part means doing things in a timely manner, using the right people and ensuring the organization is prepared.

I agree that defining requirements should not be shifted to the technical teams. But defining requirements in detail can be challenging, and sometimes business units need a bit of support to truly identify and articulate what they want. This is where technical expertise can really make a difference—bringing in ideas that may not have been considered but could enhance the final product if implemented thoughtfully. Co-creation between the business and tech teams can bridge this gap, often leading to solutions that are both creative and aligned with real needs.?