Do You Know What You Want?

Pre-script: I wrote the below with two groups, a client and a consultant. But if that is not your world, it is still valid any time you have a separate “problem haver” and “problem solver.” That split in the world is why people often refer to “internal consultants.” Basically, any time you split the responsibility of identifying a problem and solving that problem, the post applies.

A few months into my first job as a consultant, I was able to verbalize that one of my favorite parts of the job was “requirements gathering.” To which the people I worked with basically answered “you have fun with that.” The official definition maybe explains their lack of enthusiasm. Requirements gathering is presented as a process of writing down in detail what the client says you will have to do. Calling requirements gathering one piece of “discovery” is a little more evocative of something interesting, but that still implies you are unearthing things that already exist.

More experienced consultants will point out that the client often (usually?) asks for the wrong problem to be solved. If the client is asking for the wrong thing, both “requirements gathering” and “discovery” are missing the implication that the thing you are unearthing or documenting does not exist yet. Figuring out what the client is trying to accomplish and crafting a path from here to there still involves gathering inputs from them. And you are still certainly discovering what they value or hope to accomplish. But it is a much more active discussion compared to if they know exactly what needed to be done.

How can us consultants claim the client is asking for the wrong thing to begin with? If “the customer is always right” then why would you question them? Even if you don’t believe that, you should believe that the people in a company know much more about what makes it work compared to a random consultant who is on their first day at the organization. In this newsletter, the answer often comes down to “awareness of the possible solutions.”

We can suppose for a moment that a client has in mind some problem to solve. The first thing we need to discover is what exactly they have in mind. As I have covered in some earlier posts, a problem can mean a lot of different things to different people. Taken from Mortimer Adler’s How to Speak, How to Listen the first step of listening well is to understand what the person is actually saying before you worry about if they are right or not.  At this phase I typically ask a lot of questions which looks like traditional requirements gathering. The difference being, I am focused on why they want a solution instead of what solution they want.

Staying focused on the why is usually easier for everyone. At least, if you are the first person working on defining the problem who also has the capability to solve it, there are guaranteed to be some things that the earlier problem-definers overlooked. Those missed elements do not always change the right solution, but sometimes they reveal opportunities or costs that do have a major impact.

Once both the consultant and client have a shared understanding of why we are talking at all, it makes a lot more sense to transition to the decision problem of “what should we do about it?” The client will have some ideas there, though the answer could range from “complete this exact set of requirements” to “somehow make the problems less of a problem.” In the latter setting there is the opportunity to develop the requirements together.

Why is it better to develop the requirements together? I like to point out that the client will have some sense of what solving the problem is worth to them, while the consultant has a better sense of how much effort it will take to solve that problem. Since odds are there are some elements of the problem that are optional to solve, each of those elements needs to be weighed against the marginal cost. Without the consultant we don’t know the effort. Without the client we don’t know the benefit.

And what if nobody knows the answer? It turns into a gamble or a research and development project. Estimating benefits and costs are both hard, so one answer is to cap costs and somehow get a lower bound on the benefit. Any project which you can estimate well enough, and you see it will be worth it… well, then it’s worth it! Good discipline would mean you should still put in the work to really know the benefit, but you can be optimistic that the math will make sense after the fact.

And this is the joy of requirements gathering and discovery when the problem and solution are not yet set in stone. Working with the client and the whole world of opportunity in front of us to figure out how they can accomplish what they want to. A puzzle of what are the right decisions given those goals. Documentation and discovery are a piece of it, but also the reward of creating something new and better than existed before.