Comments on: Managing ambiguity – a key business analyst competency

By: Nosisa

Nosisa — Tue, 06 Nov 2012 07:59:08 +0000

Very valuable advise. Exactly what I needed to hear after a dismal miscommunication that happened between myself (BA), developers and the key stakeholders.

By: steve blais

steve blais — Fri, 05 Feb 2010 19:23:37 +0000

Ah, yes, ambiguity is everywhere. It’s a gray world, and I’m not just referring to the ugly clouds in the sky portending rain. We all live with ambiguity, good enough, fuzzy logic, and “OK, we’ll work with it for now.” Why do we need to eliminate ambiguity?
So that their is no doubt as to who is to blame when something goes wrong?
To hold someone to an exact outcome?
To be able to make clear, unassailable decisions?
Actually, in addition to all of the above, in computer technology, there is a real reason: a binary world.
Those of us who have lived inside and around computers for a number of years get to believe that the entire world can be rendered in black and white, off and on, one and zero. Since we are forced to almost inhuman exactitude we expect those who want our services and need our automated support to conform to the same expectations. Since we can’t program ambiguities we expect that our requirements, designs, tests, conversations, and negotiations all to without ambiguities as well.
The take-away for business analysts from the previous paragraph, especially those business analysts who do not hail from the technical side, is that you will need extra patience when dealing with the technologists demanding freedom from ambiguity. In the agile world, a guideline is to make decisions, which includes resolution of ambiguities, as late as possible in the development cycle. This allows additional information to come into play that may influence the decision.
Apply that guideline to all you do as a business analyst. Disambiguate where possible, live and work with the rest.

By: Adriana Beal

Adriana Beal — Thu, 04 Feb 2010 15:23:26 +0000

Steve, thank you for your thoughts on ambiguity in requirements. I have certainly seen stakeholders being purposefully ambiguous, as you describe…

As I wrote the article, I tried not to focus exclusively on ambiguous requirements because ambiguity frequently exists outside solution requirements as well, affecting for example, project roles, assumptions about external factors that may impact decisions thoughout the project, and so on. I definitely agree that living with ambiguity (in requirements or elsewhere) is in many cases necessary and even advisable, and that BAs can make a positive contribution getting people more comfortable with it.

By: steve blais

steve blais — Wed, 03 Feb 2010 22:45:47 +0000

Two points about ambiguity:
Ambiguity may be purposeful, as Tom DeMarco says, it may be a way of papering over disagreements. It may also hide indecision which may in turn come from fear of being responsible for that decision. If I tell you to do something that can be taken two different ways, I always have an out if it doesn’t work. I can claim you misunderstood. When users are pressed by business analysts or anyone to state their requirements they often are purposefully ambiguous because they really don’t know what the solution is. Removing this type of ambiguity is tricky and requires a bit of finesse on the part of the business analyst. You are, after all, working against the person’s emotions. And then again, the stakeholder requiring an ambiguously defined feature may want to see more before settling on the final requirement, which is where the iterative and agile practices come into play. It’s hard to be ambiguous about executing software. In the end, though, it is possible to tactfully and diplomatically resolve the purposeful ambiguity. First you have to recognize it and understand where it is coming from.
The second issue is the ambiguity that disappears. Several business analysts and solution team members sit around a table discussing a set of user stories or requirements. One person reads a requirement or feature description and suggests a meaning to the words. Another has another opinion of the meaning and a discussion ensues. Eventually a decision is made on which meaning is right. The ambiguity is still there, but the team has agreed on a single meaning thus apparently resolving the ambiguity. Two problems still exist: they might have chosen the wrong meaning and damage the product or delivery; and the written word still remains to be misinterpreted later by testers, auditors, customers, etc. The same scenario happens when a person states a meaning and those who might have interpreted it differently do not lodge their interpretation allowing the interpretation to appear unambiguous. This is more common when the interpreter is the systems architect, the project manager, or anyone else of authority.
Bottom line: if one person out of a dozen has a differing opinion of the meaning of a requirement or anything else, that requirement is ambiguous and must be resolved – not by voting on which interpretation is right, or arguing the relative merits of the interpretations.
Also remember that it might be necessary and advisable, even preferable, to live with ambiguity for a long time, even into production, before resolving it. And the business analyst also has to use his or her formidable influence skills to keep everyone on all sides comfortable with it.

By: Adriana Beal

Adriana Beal — Wed, 03 Feb 2010 20:48:11 +0000

Carl, well said – overly detailed requirements is not the solution to uncertainty, and better results can be achieved from trying to control/manage ambiguity constructively than from attempting to eliminate it at any cost. Thanks for adding your thoughts!