Fixing Requirements: It’s Not What You Build, It’s Why
We’re often asked how “our methodology” helps drive better user adoption. The key to user adoption is satisfying users’ needs, within the context of their environment. This sounds obvious, but it’s surprisingly easy to miss the mark. And all too often, projects are doomed from the beginning…with the requirements.
What’s Hiding in the Requirements?
When you look at a requirements document, what’s actually in there? These are typically long documents, with many, many discrete statements. In concept, these statements are all important, they define and delineate the project, and act as instructions for the reader – “if you satisfy all these statements, then the project will be a success.” Seems reasonable. But, as we all know, not every project with a requirements document ends up a success. And the ones that do often run into overruns, changes, and other types of chaos later in the project. It turns out, a requirements document is not exactly an ideal format for defining a project. When we think they are complete and solid, we may be setting ourselves up for failure. As Tony Byrne and Jarrod Gingras explain, “large requirements packages actually provide a false sense of security.”¹
The process of defining the requirements is full of traps. There are three main problems with requirements that lead us astray. Let’s look at them, and explore how to get around them.
Problem 1: The Way Requirements are Gathered
We first need to think about how requirements get defined. “Gathering” is the right term here, because that’s precisely what’s happening: each stakeholders’ wish list is taken down, verbatim. These items may be categorized, but are not usually filtered or modified (or even prioritized). Requirements are all-too-often a confused hodgepodge; a collection of disparate stakeholder dreams and demands. And once these requests make it into the requirements doc, we take them for granted. If something is a requirement, we don’t question its validity, or probe for details. Every requirement adds constraints to the project, limiting the possible ways for you to achieve the underlying goals, or even creating an impossible project.
A subtle, but more insidious problem with this is that stakeholders rarely have exactly the same idea about what this project is, and what it’s supposed to achieve. So when it comes to requirements, the whole is not the sum of its parts – it’s typically less. Not only does our pile of requirements limit how we can solve a problem, but it also doesn’t form a coherent overall picture. If you were to peel back the positions of all the requests, what you might find is that some of the intentions line up, but others are unrelated – or worse, conflict each other.
This brings up the concept of positions vs. interests, from Roger Fisher and William Ury’s classic book on negotiation Getting to Yes. People often say what they want in specific terms, without sharing their underlying needs. If you knew the real goal, you might have actually been able to find other suitable ways to solve the request. The point of this is that an interest can be solved in many ways; a position, only one.
Problem 2: Our Invisible Lenses
The second problem is that we tend to think in terms of solutions, which leads us to run up against our own blind spots. We are optimized for solving problems in a tangible world with the tools we have around us. We learn how to navigate this reality from our own observations and from others, and eventually settle upon strategies, tools and rules-of-thumb that work comfortably for us. With repetition, these strategies turn into automatic behaviors as they wear deep grooves into our mind, eventually becoming the invisible lenses through which we see whatever we encounter in the world. Humans excel at pattern-matching, and use this skill to minimize mental effort. When we’ve really mastered something, the solutions just come to us without effort.
The downside of this approach is that we tend to get stuck in certain patterns of thought and action, while simultaneously losing the ability to see that this is even happening. This situation is perfectly fine if we happen to be using the optimal way of doing things, but not quite so fine if we aren’t, or if we encounter changing situations. Is the architecture you’ve had success with in the past really the best fit for the new project? Is a 3-tab Dashboard really the right design solution?
The nature of so-called “knowledge work” is that we’re always coming up against novel situations; every project is always at least somewhat different. If it wasn’t, we would simply be following a step-by-step, repeatable process, and it wouldn’t really be knowledge work.
You can see the problem here: we are great at finding patterns based on what we know, but we so often find ourselves in the new and unknown, where our patterns often fail. So what we need to do is, essentially, forget what we know. We need to put aside our pattern-matching mental machine, put aside our instinctive answers, and look at this new project with fresh eyes.
Good requirements take a big, uncomfortable step back from the tangible world, into the abstract. Good requirements treat the project definition as a black box, and focus on its external characteristics (“page loads within 1 second”), and intended effect on the surrounding context (“enable the sales team to quickly identify current opportunities”).
Problem 3: Assumptions
The final problem with a requirements document is the problem of assumptions. We start the project with grand ideas and a Utopian vision of how it’s going to change the world. We think that our users are just going to flock over in droves, and totally change the way they work once we’re done. This rarely happens, especially when we don’t really understand our users and their workflows. If your target users have an existing process or workarounds, what incentive do they have to use whatever you’re building? If your users rarely use a desktop computer, do you really want to build a complex dashboard that is difficult to consume via mobile devices?
While we need to treat the project itself as a black box, we need to be very clear about the surrounding context. Seemingly minor details can mean the difference between success and failure. If your project is the boat, then assumptions are the smooth surface of the water, and reality is rocks hiding just below the surface. You can’t see these rocks from where you are, but you’re definitely going to feel them when you get there.
We always have a picture of reality in our minds, but the picture is something that we create. We have a painter in our mind, tirelessly filling in the gaps in our knowledge; completing our rough sketch of reality with vivid, yet misleading details. It’s a caricature, drawn from the prominent details that stick out the most to us. And, just like our invisible lenses, it’s impossible to see our inner painter.
The crux of the matter is that we simply don’t know enough about our users and their context when we create requirements. It’s uncommon that the people charged with defining requirements actually spend a lot of time “in the field.” We rarely have a solid understanding of how things work, but we always think we do.
The solution to the problem of assumptions is exceedingly simple: observation. You must actually go to where your users are. Talk to them, and watch what they do. If we don’t have time to do this before the project starts, the least we can do is acknowledge that we might not know everything. We’re going to need to take a fine-tooth comb through the requirements and ask ourselves, “do we really know that this is true?”
The Experience Design Approach
In our Experience Design approach, written business requirements serve as one of many inputs to the process; they aren’t the sole source of design direction. To put it another way, the requirements are a piece of the context, not the full story. This is not to say that requirements are useless, or poorly written, they just don’t always provide enough direction for design.
With a clear understanding of the goals, the context, and the true constraints, we’ll be able to do a lot better job in the project, with a lot less pain. Armed with this information, we will be able to prioritize the written requirements in the context of the underlying goals and the reality of the business context. You might be able to eliminate some requirements altogether (do we really need this to work on IE?), and others will morph into a more useful form. You may also find that, now that the team understands each others’ true interests, there might be creative alternatives to the assumed solutions they had in mind at the start (“I guess we could just send users an email, rather than building a whole app for this.”).
It’s time to fix the requirements phase. It doesn’t have to be a slog, a battle, and a requirements definition doesn’t have to be a boring read. This phase of the project should be a time of possibility, of curiosity, of excitement. As you can see, it is possible to define a project in a way that generates excitement and simultaneously makes the project more achievable. Let’s choose that path instead.
References
1 Byrne, Tony, and Jarrod Gingras. “The Right Way to Select Technology, An Excerpt.” A List Apart The Full, A List Apart, 7 Mar. 2018, alistapart.com/article/the-right-way-to-select-technology-excerpt.
About Ironside
Ironside was founded in 1999 as an enterprise data and analytics solution provider and system integrator. Our clients hire us to acquire, enrich and measure their data so they can make smarter, better decisions about their business. No matter your industry or specific business challenges, Ironside has the experience, perspective and agility to help transform your analytic environment.
