Image Credit © Richard Villalon – Fotolia.com
Understanding tricky business situations often requires us to draw upon our modelling skills. There are a wide range of types of model that we might utilise, ranging from conceptual models that help us understand how stakeholders think the situation ought to be operating, right through to process models, data or information models, state transition diagrams and many, many more beside.
Yet with this plethora of models comes a challenge: how do we create ‘views’ of the situation (or requirements) that are actually meaningful? How can we convey tricky and complex information in an understandable way, to a whole range of interested stakeholders, each of whom have different preferences and needs?
This is a perennial challenge. Executive stakeholders often want a “helicopter view” of a situation, and a detailed process or data model may disengage them. I remember working with one senior manager whose mantra was “one slide”. She took the view that if an idea or proposal couldn’t be distilled to a single slide, then it probably wasn’t well enough thought through (yet). She was probably right.
Yet, as well as executive and senior managers we need to communicate effectively with end-users, subject matter experts, vendors, third parties, middle managers and so on, each of whom will have different interests and concerns. Can ‘modelling’ really help us with this? Don’t we risk creating something that is too high level to be useful, or so detailed that it will swamp and overload our stakeholders?
Precision and Accuracy
I was recently discussing this challenge with a client when a useful analogy emerged. We could perhaps consider communication—of any type, but including communication using models—along two dimensions: Precision and Accuracy
Take these three statements:
A.”The plane has been refuelled”
B. “We have sufficient fuel in the tank to reach our destination”
C. “Flight BI276 (tail number GC-GCI) has been re-fuelled with 40,000 gallons of aviation fuel, which is sufficient to get us to our destination with a contingency reserve which would allow us to divert to an alternative airport if required for operational or safety reasons. All statutory fuel tank checks have been completed and concluded satisfactorily”
Which of these is “right”?
It is quite possible that they are all right—they are all accurate—but what they show is a different level of precision. And it is quite possible to imagine different stakeholders would be satisfied by the different statements. Passengers would find (a) useful, the cabin crew may find (b) re-assuring, but the pilots may need the level of precision expressed in (c).
We could even expand the statement further, adding even more precision, perhaps mentioning the viscosity or grade of the fuel—indeed this might be relevant to some stakeholders. Yet, as with any communication, it is important to know what the recipient needs. If we were to gave the wrong message to a stakeholder it would likely cause confusion (imagine being a passenger on a plane where a pilot announces the volume of aviation fuel and the split between engines. I’d imagine this would raise concern!).
It’s all about stakeholders and context
This brings us to an interesting and possibly intuitive conclusion: modelling is about communication, and therefore the amount of precision we need requires us to think about our audience and the context in which we are operating within. Too much or too little detail and we risk disengaging our stakeholders, and potentially even causing unnecessary confusion, frustration or concern. It also implies that having the ability to create a range of models—to different levels of abstraction—will help us communicate relevant information to stakeholders that need it.
This is something that it is well worth us considering in the early stages of a BA engagement. Indeed BABOK® v3 includes the idea of ‘planning business analysis information management’ as well as ‘defining a requirement architecture’. These tasks are of course broader than just considering which models to use, and encourage us to consider the types of artefacts that we’ll create, and how we’ll maintain links between them. Time is often short at the early stages and it may be tempting to overlook these activities. Yet spending time consciously considering these aspects and deciding how we will get our message across effectively will help us avoid costly communication clashes!
NB: It should be noted that in scientific and mathematical fields, the terms ‘accuracy’ and ‘precision’ have a specific meaning, which is different in intent from the article above which focusses on the common usage of the words.
What are your views on modelling and precision vs accuracy, do you have any tips, perspectives or anything to add? I’d love to hear your thoughts. Please add a comment below, and let’s keep the conversation flowing!
If you’ve enjoyed this article don’t forget to subscribe.
About the author:
Adrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.
To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com
Agree that knowing your audience and their need for information “precision” is key. I recently asked an associate about how he presented dynamic system models to execs, and he replied that he wouldn’t recommend doing so because such models would likely create confusion and pushback. Although managers may well want (and need) to know the details about how how a model is constructed and operates, the execs typically will want “the solution”, delivered via attractive slides that include the basic assumptions, risks and proposed actions for them to approve.
Hi Robert, thanks so much for you comment. Absolutely — I often find the same, there is certainly a place for ‘slideware’ as well as more formal and detailed models. Knowing what to *leave out* is often as important as knowing what to *include*, it seems!
Thanks again, Adrian.