Posted on
3 minutes to read
Why I like colliding requirements
A large and gratifying part of my role at ReedPop involves discovering conflicting project requirements and resolving them in a way that leads us to create better products.
On large scale projects it's normal for us to have stakeholders that represent our different departments or divisions -- editorial, commercial, design, technology, legal, and more -- and each stakeholder will bring their own preconceptions, ideas, or goals to projects.
During the discovery phase of projects we'll spend a lot of time conducting stakeholder interviews to hear about what problems our stakeholders are trying to solve with the project. That is an art in itself, but it largely involves asking open questions, doing a lot of listening, and teasing out broad goals rather than specific requests.
The discovery phase will leave us with a healthy amount of things to think about and directions for the project to go, but the bit I like most is where we take the stakeholder interviews and compare and contrast them against each other. Eventually we'll surface some competing goals between stakeholders.
Here's the fun bit: my role is then to talk through any colliding requirements with stakeholders and to coach them into resolving the requirements into something that leaves us with a better product.
Note that my role isn't to resolve the requirements myself -- although I will certainly have my own opinions and will want to shape the final requirements into something I think works! -- but it is more about getting two stakeholders together and talking through how interesting it is that their goals aren't completely aligned and talk about ways in which they can be coalesced into something that everyone is happy with. It's essentially a form of mediation.
This can be daunting to less experienced members of the team. My experience has shown that a lot of people in technology tend to dislike saying no, especially to stakeholders with seniority, and will try and quietly satisfy and serve competing requirements rather than folding them into something equitable for everyone. But that won't help anyone as the colliding requirements will just surface further into the project when it will be harder to resolve them.
The tone you adopt is important. Resolving colliding requirements is not an antagonistic exercise, but should be seen as something which empowers everyone.
What's lovely about doing this kind of work is that if it's done successfully everyone leaves with a shared vision for a project -- or for that piece of the project, at least.
Because this new, shared vision is shared with two or more stakeholder who more often than not have leadership roles, that shared vision can then trickle down across teams and eventually the whole organisation. That's big.
These sessions also lead to more cross-pollination of ideas between teams. I often find that the best ideas come from requirement resolution meetings and that they tend to be a synthesis of two team's ideas.
What's even more lovely is that if you do this sort of thing right the teams will feel energised by the encounter and will be happy that progress has been made. And you will have unblocked a decision or clarified requirements for your team, too.
So that's why I like colliding requirements.
