Stop sabotaging your technology projects: How to communicate requirements effectively

Technology teams, departments and industry still hold a reputation for failed projects, where customers and product owners spend too much for too little, or where results pale in comparison to expectations held. We hear about these unmet expectations all the time, followed by budgets blown on project extensions and scope changes. We also hear about customers who “don’t know what they want”, or who “keep changing their minds”. Sound familiar?

Many of these projects are unknowingly sabotaged before they start. This is because expectations are mismatched out the starting blocks, and there is little chance that the solution could ever go on to solve the meaningful problems faced in reality. This is a scary situation which traps all parties in projects which are destined to fail. It’s worth spending the time upfront to clarify expectations and give your projects the best possible chance of success.

Here are four important concepts to help you avoid self-sabotage by communicating your requirements effectively:

1. Describe the problem, not the solution
You know your business best. Instinctively, you would want to explain how you would solve the problems your business is experiencing. However, this often causes more harm than good. Describing your requirements as solutions will deprive you of the opportunity to explore multiple different solutions with your development team which might have stemmed from a clear problem-statement. We need to recognise that we’re usually not all that great at explaining what we need but are probably quite good at explaining our problems.

Focus on the problem space instead. Spend the effort clearly describing the challenges which exist, and what success would look and feel like. Let the experts contribute to the problem-solving process – it’s why they’re there and it’s what they’re good at. When combining good requirements and good problem solving, you allow optimisation for time, scope and quality (and a great overall solution).

2. Try not to hide complexity
When compiling requirements, it is important not to mix concepts or priorities in a way which will disorient your audience. Priority should flow from top to bottom, and requirements should be clustered around the problems they’re linked to. What you may consider to be a very complex need may in fact be a simple feature. In contrast, one innocuous line in a requirements brief could ultimately account for a disproportionate amount of the work.

Hidden complexity leads to time bombs ticking away in your backlog. Requirements should be logically grouped, and clear enough for your audience to easily spot this hidden complexity so you can clarify it and defuse the bomb before getting started.

3. Manage expectations
Expectations must be shared and discussed early and often. Seasoned project managers and experienced software engineers know that expectation management is an important part of any successful software development project. There needs to be a communication culture to ensure that there are shared perspectives of the end result. The tree swing analogy depicts how different parties interpret and implement requirements during the development process. When there is a lack of shared understanding during these processes, stakeholders often genuinely think they are interpreting requirements correctly, but disaster ensues once results are visible and material.

4. Prioritisation is key
Once there is a clear set of requirements, it is important to rank them. Requirements will vary wildly in complexity, time and cost, which makes a shared understanding of priority fundamental to success.

Prioritisation should weigh up what’s important versus what’s urgent, consider the right mix of functionality and differentiation, and take value versus effort into account. Techniques like the MoSCoW method can be used to build this prioritisation puzzle to create a solution that maximises time, cost, customer and business value, and operational objectives.

• Must have: Non-negotiable product needs that are mandatory to complete the project
• Should have: Important features that aren't vital, but add significant value
• Could have: Nice-to-have features that would only have a small impact if left out
• Won't have: Features that aren't a priority for the current scope

This allows the development team to arrange the project into phases, plan for minimum viable product (MVP) releases when necessary and have the “nice-to-have” requirements in scope for future phases.

Requirements are often the primary medium of communication throughout development. Communicating them effectively is clearly not a trivial exercise. Describing needs well means agreeing on expectations between parties from the very different perspectives held by technology, business, product and strategy. It also means that dissonance is managed and dispelled as early as possible in the process.

Stop sabotaging your projects. Detail your challenges more so than your preconceived solutions, try not to hide complexity, work to establish shared expectations, and be clear about what is important versus what is urgent. Set yourself up for success.