Ambiguity, Uncertainty or Both?

Featured
27096 Views
8 Comments
9 Likes

Why Organizations Need Business Analysts

Ambiguity, Uncertainty or Both?We have always been fascinated by the exceptional business analysts who can create order out of total chaos. The ones who can ask those great questions, who can figure out what’s important and what’s less so, who can synthesize lots of information, put it all into their magic hat and come out with requirements that make sense to all the stakeholders. In other words, the ones with the high tolerance for ambiguity,who know that eventually this mish-mash of requirements, expectations, and semi-articulated wants will come together into a reflection of the real business needs.

We are also aware that Project Management requires a different skill set thanBusiness Analysis. It’s not that we can’t wear both hats. It’s just that the hats really are different. And although we both have worn each hat for well over a decade apiece, we both love the ambiguous nature of Business Analysis. As a project manager one of the authors couldn’t leave Business Analysis alone. sheusually attended all the requirements workshops, despite having truly capable business analysts on the project.The excuse she used was that I was nervous about the schedule.Truth be told, it was because requirements activities were the favorite part of her job.Why was it so muchmore interesting to me than project management?

The missing piece fell into place when we attended this year’s PMI North American Global Congress. A session was presented by Michel Thiry, MSc, PMP, whom we have known for several years. His presentation made an interesting distinction between uncertainty and ambiguity. And while he didn’t mention it, he provided a framework which could be applied to Business Analysis.

Uncertainty. As PMs understand, the less we know, the more uncertainty there is, and therefore the greater risk. As we move throughout the project, more becomes known, and what was uncertain is now certain, so the risk decreases. There are many things we can do to reduce uncertainty, such as decompose our projects, deliverables, and tasks, or to manage risks. So even if a project is complicated, it is not necessarily complex or ambiguous.

Ambiguity.  Ambiguity differs from uncertainty. While reducing uncertainty is linear, reducing ambiguity happens iteratively. In Business Analysis terms, we ask a question and the answer temporarily reduces ambiguity. However, answering one question leads to more questions. We ask more questions, get more answers, and each answer reduces the ambiguity related only to that specific question. But more questions generally arise. As Thiry points out, in an ambiguous environment, decisions have to be made before the full impacts are known, and much of what we know is learned through retrospection.

HUHA Matrix.  Thiry has developed a simple matrix of uncertainty and ambiguity related to project management. We refined two of the quadrants on the matrix by clarifying the disciplines that define them. See Table 1 below.

On one axis we measure ambiguity going from low to high. On the other we measure uncertainty going from low to high. There are four quadrants. In the lower left quadrant are those activities that are lower in uncertainty and lower in ambiguity (LULA). These are the day-to-day operations where people perform processes, and Business Process Management helps to maximize process assets. Project Management falls in the low ambiguity/high uncertainty quadrant (HULA). Portfolio Management falls into the low uncertainty/high ambiguity quadrant (LUHA).

Sitting through Michel’s presentation, it struck us independently (and immediately) that Business Analysis was the best discipline to address the high ambiguity/high uncertainty (HUHA) situations as shown in Table 1.The best BAs do bring “order out of chaos” and contribute to reduced ambiguity.

An interesting side-note to this framework, it seems to us, is that organizations are most productive when they can reduce ambiguity and uncertainty. This means using Business Analysis, Portfolio Management, and Project Management to solve business problems and seize opportunities, ultimately moving the results towards the LULA quadrant of Process Management. But, that’s a whole other article! 

 


Table 1 – Uncertainty/Ambiguity Matrix, Modified from Michel Thiry’s
Contextualization of the Project Organization [1]

What causes so much ambiguity in requirements? There are many reasons. Business SMEs change their minds. Or they don’t know what they want. Or they know what they want, but they can’t articulate it. Or they think they know what they want, but when we start asking questions, it becomes apparent that they don’t. Or they present a solution without understanding their real business needs. Or they present what they think management wants. The list goes on and on.

As an example, if you build a house, can you imagine not changing your mind as your house is being built and you see the frame added, then the roof, the floors, and the details of the kitchens, bedroom, etc.? What gardener keeps their initial design? They learn that certain plants do better or worse in certain locations. Trees grow and provide more shade. Or they die and shade plants suddenly get exposed to light. Neighbors move in and build walls, or plant their own trees. Things change.

To be sure, there are many requirements analysis techniques that provide a structure to help formulate questions to more quickly reduce ambiguity. Process, data, and use case models help uncover different aspects of requirements. Mock-ups and prototypes provide concrete “pictures” that help the business visualize the end product before time and money are spent developing it.

The iterative nature of Agile methods, such as Scrum, also helps reduce both uncertainty and ambiguity.  They help to reduce uncertainty through early delivery, that is, breaking requirements into small features and functions which are delivered iteratively, usually every few weeks. Agile methods help reduce ambiguity by providing a mechanism for responding to change, because we cannot predict the consequences and impacts of decisions made during one iteration on future iterations. An important part of ambiguity, according to Thiry, is learning through retrospection, again, because the future is unpredictable.

But none of these is the silver bullet businesses have been craving since the beginning of time. Business Analysis operates in the realm of both high uncertainty and high ambiguity and the great BAs navigate this terrain expertly. No wonder BAs are so important to project and organizational success!

Authors: Elizabeth Larson and Richard Larson

Elizabeth Larson, CBAP, PMP, CSM and Richard Larson, CBAP, PMP are Co-Principals of Watermark Learning, a globally recognized business analysis and project management training company. With over 30 years of industry experience each, they have used their expertise to help thousands of BA and PM practitioners develop new skills. Their speaking history includes repeat appearances at IIBA and PMI Global Congresses, chapter meetings, and professional development days, as well as BA World conferences.

They have co-written the acclaimed CBAP Certification Study Guide and The Practitioners’ Guide to Requirements Management. They have been quoted in PM Network and CIO magazine. They were lead contributors to the BABOK Guide® Version 2.0, as well as the PMBOK Guide® – Fourth edition.


[1] PMI Global Congress 2011, Ambiguity Management: The New Frontier, by Michel Thiry, MSc, PMP

Like this article:
  9 members liked this article
Featured
27096 Views
8 Comments
9 Likes

COMMENTS

Tony Markos posted on Monday, November 21, 2011 1:49 PM
Hi:

The major task of a Business Analyst is proper partitioninig, and except for trivial systems, this involves decomposition. You say PM's reduce ambugiity by decomposition, well that is the same thing that the BA does.


Tony

ajmarkos
AdamITBSA posted on Tuesday, November 22, 2011 11:09 AM
Thanks for pointing us toward Thiry's information -- I found this discussion of uncertainty vs. ambiguity helpful with respect to business analysis.

It's a such a fact of life(-cycles) that "in an ambiguous environment, decisions have to be made before the full impacts are known" -- risk-based BA approaches attempt to resolve this, but it's still a fine line. Does this just come down to experience on the decision-maker's part?

-- Adam
adamlopuch
Richard Larson posted on Wednesday, November 23, 2011 12:25 PM
@Tony - you are correct - BAs do decomposition in many ways and places. BAs and PMs may decompose different things, but you are right that one way BAs reduce ambiguity is by decomposition. Thanks for pointing that out!
Rich_Larson
Richard Larson posted on Wednesday, November 23, 2011 12:35 PM
@Adam - You're welcome - Thiry's framework struck us as just as applicable (maybe even more) to Business Analysis as it was for Project Management.
Making decisions before all the impacts are known is a constant in business, isn't it? Take business cases, which BAs are often called on to prepare. We're projecting benefits based on limited information, and decision-makers need to trust our preparation, research, and insights. There will always be assumptions, too, and a certain amount of risk tolerance to proceed in spite of the uncertainties. The more experienced the business case developer and the decision-maker, the better the outcome. Hope this addresses what you meant.
Rich_Larson
zarfman posted on Monday, December 19, 2011 9:36 PM
Greetings Elizabeth Richard et al:

I really am having a hard time understanding your paper.

I tend to think that the degree of ambiguity and uncertainty can vary widely depending upon the cognitive abilities of the inquirers (BA’s) mind. Perhaps one could suggest that ambiguity and uncertainty are a function of complexity

Your mixed metaphor HUHA matrix confuses me. You have 2x2 matrix or rectangular array. The X and Y axis are dimensionless, they could be linear or nonlinear depending upon the problem at hand.

Then I read, the less we know, the more uncertainty there is, and therefore the greater risk. As I understand it, in common parlance, risk and uncertainty seem to be one and the same thing. It seems to connote actions or events over which one has no control and may occur in future. To me that though both ‘risk and uncertainty’ talk about future losses or hazards, I think risk can be quantified and measured; I don’t know of any way of ascertaining uncertainty a priori. Perhaps risk is thus closer to probability where you know what the chances of an outcome are.

I’m going to avoid chaos theory entirely.

This is taxing my mind; I’m going to watch something mindless on TV. Let me know if I’ve gone astray in my thinking.

Regards,

Zarfman

zarfman
elarson posted on Tuesday, December 20, 2011 3:52 PM
@Zarfman, thank you for writing. I want to respond to a couple of your concerns. I hope this info helps you understand.
Risk and uncertainty. Risk is “an uncertain event that if it occurs has a positive or negative effect on the project objectives” (PMBOK® Guide 4th edition, Glossary). Uncertainty is what we don’t know, not an event. There is a correlation between risk and uncertainty. In project lingo we talk about the degree of uncertainty. The greater the degree of uncertainty, the greater the chance that a potential event will affect project objectives, so the more project risk there is.

For the explanation on the difference between uncertainty and ambiguity, the following links should help you. http://www.projects.uts.edu.au/resources/pdfs/PMI-Europe2001PgM.pdf. This link will take you to an article by Michele Thiry, PMP, MSc, that includes his matrix. We attended his presentation at the PMI North American Global Congress and have referred to his matrix with his permission. If his work is not connecting for you, you might want to try a distillation of his presentation. http://hssc.sla.mdx.ac.uk/ncpm/Thiry%20notes.pdf. This link will take you to an article that explains the HUHA matrix. In short:
Low uncertainty /low ambiguity (LULA)
This defines routine work, best managed by good administration and operations
management.
Low uncertainty/high ambiguity (LUHA)
Defines an area of the business that is best managed using portfolio management
and power-based methods of control, e.g. how the budget is allocated.
High uncertainty/low ambiguity (HULA)
Is where project management is in its element; the big decisions have already been
made and what is needed is a performance-based method to ensure their
implementation
High uncertainty/high ambiguity (HUHA)
Describes unsettling work such as mergers and acquisitions, for which learning-based
methods and value management are the key.

enlarson
zarfman posted on Friday, February 3, 2012 8:35 PM
Greetings:

I still have some questions about the HUHA matrix

Low uncertainty/high ambiguity (LUHA)
Defines an area of the business that is best managed using portfolio management
and power-based methods of control, e.g. how the budget is allocated.

Zarfman writes: I’m not sure what you mean by power-based methods of control. Googling the term didn’t help, lots of info about electronic control systems.

High uncertainty/low ambiguity (HULA)
Is where project management is in its element; the big decisions have already been
made and what is needed is a performance-based method to ensure their
implementation

Zarfman writes: Sounds reasonable, however, I’ve been in situations where to big decision sounded OK, but during implementation it became clear it was a really bad idea.

High uncertainty/high ambiguity (HUHA)
Describes unsettling work such as mergers and acquisitions, for which learning-based
methods and value management are the key.

Zarfman writes: I’ve done mergers and acquisitions they all involved attorneys, CPA’s, taxation specialists etc all of whom have prior merger and acquisition experience. Unfortunately, I’m not sure how learning-based methods and value management apply in this case.

Regards,

Zarfman
zarfman
elarson posted on Saturday, February 4, 2012 10:58 AM
Hi Zarfman. In response to your previous questions I included a link to Thiry's work. What Richard and I did, with Thiry's permission, was to apply his matrix to the project world. It seems like you’re interested in Thiry’s work and his matrix, and I encourage you to explore it further.
enlarson
Only registered users may post comments.

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC