Conflict. It’s something you probably deal with every day. Sometimes it’s minor and doesn’t draw upon skills any more advanced than those you learned in your first few years of grade school (fortunately, shoving the other person to the ground is not an acceptable practice once you’re an adult). Sometimes however, the problems are more difficult and cannot be solved with simple tools. When you meet these kinds of problems, you need something more formal.
As a Software Development Manager, the most common cause of conflict shouldn’t be between people on your own team. Hopefully your teams run smoothly enough that you don’t have to solve those kinds of problems regularly. Instead, most of the conflict you likely encounter is with your customers.
Let’s make time for a quick side-note here. Just what do we mean when we say “conflict”? As it turns out, there is a pretty precise meaning for this word. It means quite simply that one person’s view of a situation is not aligned with someone else’s view of that same situation. The beauty of this definition is that it highlights an interesting point: one person can be in conflict with another, without the other person being in conflict in return. If you think your partner should feel a certain way about a particular issue, but your partner doesn’t care about the issue in any way, you might be in conflict, but your partner isn’t.
How can you use your understanding of conflict to resolve challenges with your customers? Well, any time you or your customer disagree about the view of a particular situation (say a scope document, or the timeline for a project) you have a conflict. I can already hear you saying to yourself “thanks Cliff, as if that wasn’t painfully obvious.”
But here’s the less-obvious point. Once you are in a conflict with a customer, the tendency is for everyone to focus on resolving the conflict before allowing any other progress to be made. If you feel you need to invest fifteen man-weeks of work to resolve that conflict, or your customer feels they have to accept a multi-month delay to resolve the conflict, you are playing a high-stakes game. Everyone ends up on the defensive and true progress becomes very challenging.
The next time you are in this situation, try something different. It starts with remembering that conflict is about each person’s view of the situation. You might genuinely want different outcomes from the situation, but that’s not the conflict; the conflict lies in each person’s views. If you can resolve the conflict of views, you can remove a very real source of stress and difficulty, and put the project in a better position to find a solution both parties will accept.
Enter the Gap document.
This is a document that articulates the points of a conflict, turning what was a disagreement into something two parties can agree on. Once everyone agrees on the gap, it breaks the conflict’s momentum and allows everyone to start finding paths forward.
Gap documents are essentially very simple things. They state, point by detailed point, what each person in the conflict believes to be the truth, and describes the gap between those two positions. For example, one entry in your Gap document might be:
Customer: The product must collect dollar amounts in any number of international currencies.
Developer: The product was only specified to support US and Canadian currencies. It does that well.
Gap: The product does not support non-US and non-Canadian currencies. The customer requires additional currencies to go into production.
Why is a document full of this stuff useful? Because it gives both parties a single item they can agree upon. If you have captured the customer’s expectations properly, they will readily agree to the statement about their needs. If you have captured your corporate position properly, you can readily agree to that statement. If you are honest in the document, and don’t use heavily biased language, both parties should be capable of agreeing on the Gap between the two statements.
The beauty of this document is that nobody has given up their position, yet both parties now agree on a common statement. From this document there is a clear path forward: you take the Gaps one at a time and work out a path to resolution. The document doesn’t make the resolution steps any easier, but it removes the conflict, which is often a huge part of the problem in the first place. Now you have two parties agreeing on what is wrong and working together on the solution.
If you aren’t convinced this can work with your customers, try it inside your team first. If you’ve never used a method like this before, I am confident it can make a difference.