Agreeing on the Problem

In last week’s post I wrote about requirements gathering and specifically how that process is somewhat different when the requirements you are gathering are not really defined yet. I find the most conflicts come up when the client and the consultant do not see eye-to-eye on if the requirements are in fact defined. These misalignments can happen every way you would imagine, though accurately recognizing your role in the situation can reduce the friction in the process.

Client thinks they have been clear, but the consultant does not.

This can be further broken down into the client actually was clear and the consultant just missed it versus the client was not clear and so they’re reasonably being asked to be clearer. Communication is always a two-way street so the goal is for both sides to try to meet in the middle in the hopes that clarity is achieved. If you get the sense the other person is not trying their best to meet you in the middle, then you have a problem. As long as both sides are trying, the goal is to attempt different methods until you have successfully communicated!

Client thinks they do NOT know what they want, but the consultant insists they have a complete problem statement.

Again, this can be broken down into either the consultant misunderstood or they super-understood. These unfortunately are very hard for the client to tell apart until the consultant presents a candidate solution and the client says “yep, that fits my needs” or… not. This is the value of early and iterative demos since a picture is worth a thousand words and even if you think everyone understands, what matters is what actually gets built.

Client and Consultant disagree on who should be writing down requirements.

This misalignment is unfortunately common and is often driven by each side thinking the other is better suited to write down what is needed. On the client side, it’s easy to think “the consultants are the experts and the ones who will do the work, so they should write down the requirements.” On the consultant side, it is easy to think “the client is the one who actually wants something specific, so they should write down what they want so they can own the finished product.” Bridging this gap takes one side taking the first swing at creating something the other side can agree or disagree is right. Whether that thing is formal requirements or a first draft solution like agile suggests does not really matter. What does matter is that someone presents something that can either be built or evaluated as correct.

“Why?” as a solution

In my last post, one thing I mentioned is that since I assume the client does not know what needs to be built, I focus on what they would like to be different in the future. This works well if I can figure out how to go from what they say they want to be different to what I can do about it. Being able to connect those dots turns out to be a somewhat challenging skill set to find. The most effective way I have personally found to do this work is to role play that I have the job of the person in question. If I can imagine what would help me not have the problem they describe, I am set.

If you do not have that skill, and the client cannot identify what they need either, everyone just ends up frustrated. The consultant asks what should be built and the client says they don’t know. It is easy to start finger pointing instead of working like you are on the same team to achieve a goal.

If everyone is on the same page at this point, it is just a different problem to solve. If you don’t know what you need, you pay people to tell you. This is a normal and useful kind of service. As an example, people go to the doctor to understand what is going on with our health and we all understand it is their job to both diagnose the problem and identify a solution. Explaining why the candidate solutions fit and would create a better future state is also part of the job.