Thanks very much for checking out the article and extending the conversation! You did misinterpret one element of my article, and I apologize for not being clear in my writing.

I’m definitely not suggesting that business analysts (or product managers) should promote the selection of a conflict winner into a design. Here’s the part I didn’t go into in this article (which was just “remember to unearth conflicts”).

Most of the conflicts I’ve seen come when a solution is proposed, not when the goals are defined. A solution that focuses on only one goal is at risk of creating conflict with the other goal. A solution that attempts to meet both goals is ideal – eliminating the artificially induced “conflict” inherent in a particular solution or approach that only addresses one goal.

As a design engineer, I used to use the QFD “house of quality” tool to identify conflicting goals (be cheaper, be smaller) where the degree of conflict was representative of “established approaches” to addressing the requirements. Capturing that perspective served as a good cue to inspire me to be innovative (devise a cheaper AND smaller) solution.

That’s the mindset I’m approaching this with from a requirements perspective. Analysts should definitely be aware, but not so that they can pick one, but rather so that the engineering team can eliminate the conflict if possible, and pick the right one if not.

There are “zero sum game” situations where goals are diametrically opposed, but I have personally seen them very infrequently.

Imagine two kids who both wish to talk to their grandmother on the phone one evening. When forced to take turns (with the solution of “one phone”), their goals are opposed. When your engineering team proposes “use the phone at the same time” or “pick up the extension”), the conflict is eliminated.

When you are presented with a conflict that is impractical to resolve given the realities of a situation, you need to know who the “winner” is. But the intent is to highlight a conflict so that you can resolve it if possible.

Also – for the record, I really like Diet Mountain Dew. And I would definitely drink water before drinking Pepsi (to avoid the sugar). As to Diet Pepsi vs. water – it depends. If thirst is my primary motivator, I go with the water. If I’m drowsy, I go with the caffeine. Soft drinks are not perfect substitutes for me. Based on that, I’m willing to hypothesize that this might be true for other people – as you say, data is needed. Consider the alternative of “find another vending machine” instead of “water” if it prevents derailing.

At the end of the day, I really appreciate your extension of the discussion, and exposure of the ideas to others. I don’t agree that including the “solution design” part of the process is lazy. The best solutions come out of a dialog of collaboration that informs in both directions. Ignoring either limits the opportunities for your team to contribute to solutions. Or perhaps I mis-interpreted your premise.

Thanks again!

Scott

I’ve published an article that argues a position contrary to the one you’ve taken here.

But perhaps further discussion will reveal there is only an apparent difference in our positions.

Scott Sehlhorst, over at the Tyner Blain blog, published an article arguing that Business Analysts must remain aware of goal conflicts between actors in order to cho ……

@Robin – Great point! I sometimes forget to take a moment and think about the real-world context, to make sure and apply the right design principles, instead of defaulting to “user first.”

Being able to step back and assess the trail of goals was very insightful and helpful. Now I have to figure out how I’m going to think about this all day (personal goal) while still being able to get me job done (corporate goal).

DougGtheBA