I’ve tried to capture a technique that I apply when I’m feeling the ache – hopefully there’s something in it for you.
Consider; you walk into a restaurant and say, “I’m hungry”. In response, you’re asked to choose the condiments you want on your sandwich. There have been a bunch of assumptions made about what would solve your “hungry” problem… and that “hungry” is your actual problem. It’s possible that a sandwich is the right solution, but it’s just as possible that it isn’t too.
Alternatively, you walk into a restaurant say, “I’m hungry”. In response, you’re asked whether you want to eat with your hands or cutlery, whether you’d like to sit down to eat or eat on the go, whether you have any food sensitivities or allergies, and whether you’d had enough water to drink today. Your answers help guide what you’re served – while the solution may still end up being a sandwich, whatever you end up eating is more likely to satisfy you.
Food service has been around a long time, and restaurants have refined their requirements process a great deal. There are signs out front to provide a cue as what kind of restaurant it is, menus to describe what’s on offer and help address potential dietary restrictions. The questions people expect to be asked, the questions that either have implied answers or can be safely assumed and relevant terminology are all widely understood. Questions regarding what you should eat (or not eat) are typically avoided altogether. While these kinds of things optimize the interaction and reduce the time it takes to provide service, it doesn’t mean that the differences between requirements and design aren’t being respected – the relationship between them is just so intuitive now that it all seems like one thing.
Maturing service areas – like technology – don’t offer the same refinement as mature service areas. Very similar concepts can have very different names, and very similar names can represent very different concepts. The risk of misunderstanding and of problems common to different areas in an organization receiving independent treatment is much higher. There are opportunities to mitigate these risks every time a team is formed by sorting out the language used to describe concepts everyone understands but may label differently.
A distinction I feel is particularly important is between “requirements” and “designs”. I like to distinguish between these concepts like this:
- Information that describes the capabilities needed to solve a problem are “requirements” (what you need)
- Information that describes the characteristics of whichever solution has been selected to meet the requirements are “designs” (how you’ll deliver what’s needed).
In many cases, people want to leap-frog over the “what” and focus on “how”, and I can empathize. “How” is more fun - it’s often more tangible and easier to envision. It does, however, reduce the opportunity to consider alternatives to the way a single person (or a small number of people) have envisioned it. As with the sandwich, the best solution may end up being the one that was originally envisioned – exploring options helps build understanding and consensus – a good thing for any team.
I’ve heard several different ways to describe what I call “designs” here, usually as requirement (system requirement, solution requirement, technical requirement, etc.). I’m not suggesting that this is wrong per se, but I am suggesting that blending everything under the “requirements” label can make it trickier to keep stakeholders focused on what they need vs. how they envision the solution.
The challenge in maintaining focus comes from an honest place - business stakeholders are often “restaurant owners” (in keeping with the analogy) – they are experts in the area. They live and breathe it and have become so immersed in their knowledge that they view it as a single thing. It’s the rest of a project team that benefits most from distinguishing between requirements and designs initially, although some stakeholders may suffer from “that’s-the-way-it-has-always-been” syndrome – asking them to clarify why things are important to them can lead to some interesting discoveries.
The single biggest obstacle to decoupling requirements from designs is not that people don’t understand the difference – it’s the time it can take to sort information in this way. If commitments have been made (to delivery dates, vendors, resource managers etc.) around a specific outcome before any requirements were gathered, it can be difficult to get back to it.
In some cases this discussion may be easy –any assumptions or conclusions your business experts have made independently can often be readily explained and if there is clarity with respect to the problem that needs to be solved and the capabilities that will help solve it - whether “requirements” have been formally gathered or not – the team can proceed.
In other cases, the discussion may not be as easy. I’d suggest that the time it’d take to make sure people are clear on the “what” and “why” will be a fraction of the time the team will experience in delays and other waste if they proceed to discussing “how” without this understanding – even the most delicious, perfect sandwich in the history of sandwiches crafted with the utmost care and attention to detail will go in the bin if the customer is allergic to bread.