Author: Adriana Beal
Among the many competencies that business analysts need to develop in order to advance their careers, the ability to manage ambiguity is undoubtedly a critical one. The rapid changes that happen internally and externally to organizations require business analysts to become comfortable acting in an environment in which uncertainty and change are constants, and timely decisions need to be made even when not all the variables are known.
How can a BA improve his/her performance dealing with uncertainty and unpredictability? This is a competency most likely to be developed through informal practices. A good start is to acknowledge that managing ambiguity well typically requires two approaches: working to reduce ambiguity and finding ways to become productive even when uncertainty is unavoidable.
By the nature of their activities BAs plays a crucial role reducing project ambiguity. Typical business analysis tasks, such as clarifying project scope, defining and communicating requirements, and making sure that each business term used is clearly defined in a project glossary, significantly contributes to reducing ambiguity in a project.
In addition to reducing uncertainty in their projects, business analysts are also instrumental in helping the team remain productive amid ambiguity. Examples of steps that a BA can take to achieve this objective include:
- Assisting the project manager in establishing ground rules, roles and mechanisms to foster productive discussions and interpretations of business needs and solutions;
- Prioritizing and organizing issues to reduce the distraction caused by too many unknown factors;
- Making an effort to establish a common understanding of project goals among different stakeholders so conflict is replaced by cooperation.
Finally, BAs can also become more skilled at managing ambiguity by accepting criticism as learning. Leaders who manage ambiguity well understand that they will make mistakes and adopt the attitude that failure only happens if they choose not to learn from the experience. By being open to making mistakes (which are bound to happen in situations that aren’t black and white), and choosing to interpret the criticism as learning, a business analyst can become significant better at managing ambiguity over time.
This post from the website Better Projects talks about how Google is not afraid to fail, and what BAs can learn from the company:
We BAs could learn a lot from that kind of mentality about failure. No requirements document will be perfect on its first (or often even fifth) version. No screen mockup can encompass all the needed functionality and interaction. No use case can cover all possible directions that a user may go. Yet despite knowing the limitations, we should not just toss up our hands when we don’t get it right on the first try. We learn what our customers really need and next time, we get it right. We look for that elusive ‘killer app’ that will win approval from our customers so we have it ready for them, exactly when they need it the most.
This is certainly a good mindset for BAs to adopt while working under highly ambiguous circumstances.
>> Learn How to Ask the Right Questions
Interested in receiving a comprehensive set of questions you can ask in almost any project context to reduce ambiguity on your project? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.
Click here to learn more about the Requirements Discovery Checklist Pack
Very valuable advise. Exactly what I needed to hear after a dismal miscommunication that happened between myself (BA), developers and the key stakeholders.
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.
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.
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.
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!
I’m glad you used the term “managing ambiguity”, because I sometimes find that it’s important to use ambiguity constructively. Requirements that are overly detailed can constrain design solutions in ways that aren’t necessary.
For example, you might write a use case step that says “Actor clicks the X button.” Is it really important that the X command be issued via a button? Would a menu item or some other mechanism work just as well? Until we start designing solutions, it’s hard to say. A better–though more ambiguous–way of stating the step might be “Actor issues the X command.”
I believe it’s one of the BA’s jobs to control ambiguity, rather than always eliminate it.
Pingback: 2wtx Mastering Business Analysis » Blog Archive » New article at Bridging the Gap
Thank you, Randy and Alex, for your comments. Good points about BAs playing an important role helping the customers get clarity about what they want, and the risk of suffering from analysis paralysis when uncertainty isn’ t managed well.
This is an interesting article on the reality that we must all become adept at managing uncertainty – it’s not just a challenge for the BA.
There are other risks of striving for perfection whether it’s perfect knowledge (i.e. complete understanding) or the perfect requirement document. It used to be called ‘analysis paralysis’ which is the state where the analysis doesn’t move forward through the fear of the unknown.
The unknown unknowns as Donald Rumsfeld would say 😉
It all boils down to managing risk well. The biggest risk in business these days is not making a bad decision but not making a decision at all!
A business that suffers from analysis paralysis will not last long!
This is a nice article. Ambiguity will always be present in all projects. Using our elicitation skills helps reduce ambiguity in project requirements. We should also be leaders in our user community. Mostly, ambiguity is present because our customer don,t have a picture of what they want. I believe it is our job as BAs to lead our customers to what they really need and help them achieve their goals.