What An In-Flight Meal And The Cookie Monster Can Teach Us About Business Analysis

Cookie which says "Anytime Cookie" on the labelI’ve always thought that one of the ‘fun’ parts of travelling by air is the in-flight meal.  When packed in economy, there’s a real art to opening the foil or cellophane wrapped food items without showering the contents over yourself or a fellow passenger.  This is made even more problematic if, like me, you enjoy the occasional beer in the airport before the flight…

 

On a recent trip, I was given the usual choice of chicken or pasta, and alongside the main course there was a cookie.  After ravenously demolishing the main course (I always seem to sit in an area that is last to be served) my attention turned to the cookie—which was curiously labelled as an anytime cookie. I couldn’t help but smile when I saw this as it immediately triggered an image in my mind of the Cookie Monster saying “All cookies are anytime cookies! Me eat cookies all day!”.  But, being the self-confessed BA geek that I am, my thoughts then immediately came back to business analysis and logic

 

As BAs and professionals that help enable value to be created and captured, we deal a lot with logic.  We use models and other ways of communicating that allow us to convey complicated concepts concisely and precisely.  Yet when eliciting information we typically have to rely on everyday language—and if we are not careful these conversations can be filled with tacit assumptions and misunderstandings when we play them back.

 

Let’s take an example. The fact that anytime cookies exist does not imply that other cookies are time restricted.  That sounds so obvious, doesn’t it? Nobody would fall for that fallacy, I’m sure, but what about the points below?  Is there a risk that either us or our stakeholders might make tacit assumptions about the logic?

 

The fact that senior users can access management functionality does not (itself) imply that others cannot.

The fact that the system must be available (to an agreed level of availability) between 09:00 and 19:00 does not (itself) clarify whether the system needs to be available (or not) between 19:01 and 08:59

The fact that new letters will be scanned into the system within 24 hours of receipt does not imply that old letters won’t be scanned, although some people might read it that way.

The fact that parking is not permitted between 08:00 and 17:00 does not (by itself) imply that parking is unrestricted between 17:01 and 07:59, in absence of another rule or convention.

 

These are all fairly high-level examples, and there’s a danger that they’d fall into the ‘cookie trap’.  If they are viewed in isolation, away from other related rules and requirements, people might make incorrect assumptions.  They may (metaphorically) assume that the presence of an ‘anytime cookie’ means that all other cookies have time constraints.  Or, more realistically, they may assume that because senior users can access management functionality, that others cannot.

 

There are many tools in our toolkit that can help us avoid these misunderstandings, including use of a range of general model types, business rules (alongside standard business vocabulary and a concept model), acceptance criteria and lots more beside.  The tools that will be most relevant depend on the context of the organisation and the project—but whichever tools we use we should cultivate clear communication through regular conversations, whilst actively avoiding the ‘cookie trap’!

 


What are your views? Please add a comment below, and let’s keep the conversation flowing! 

If you’ve enjoyed this article don’t forget to subscribe.

Subscribe to Adrian Reed's Business Analysis Blog


About the author:

Adrian ReedAdrian 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

Blackmetric Logo

Rich

Hi Adrian. Your article makes a very valid point, which is essentially about being aware of the assumptions that we (and others) make. When we are conscious of these assumptions, we can be better prepared in challenging these, especially where it’s easy to read between the lines (as in your examples above), or where others are making the same assumptions as we are.

Adrian Reed

Hi Rich, thanks for the comment. Yes, it is so key to be aware of assumptions isn’t it — the challenge being when they are ‘hidden’. I find that modelling can be (one) way of helping with this… so often when I draw a model I find I am challenging my own (and others’) assumptions, somehow the models become greater than the sum of their parts!

Thanks again for the comment Rich. Take care & speak soon — Adrian.

Adrian Reed

Hi Rich, thanks for the comment. Yes, it is so key to be aware of assumptions isn’t it — the challenge being when they are ‘hidden’. I find that modelling can be (one) way of helping with this… so often when I draw a model I find I am challenging my own (and others’) assumptions, somehow the models become greater than the sum of their parts!

Thanks again for the comment Rich. Take care & speak soon — Adrian.

Roland Hesz

So true, all the “well, it’s obvious” assumptions can cause quite a number of problems.
And the more homogeneous your project team is, the more of these assumptions will slip through without anyone noticing them.
One reason why I think that the idea that a BA must have a decade worth of experience in the industry is a harmful one – who will challenge the assumptions if everyone comes from the same background?

Do you plan to have a post on useful practices and exercises to discover and validate assumptions?

Adrian Reed

Hi Roland, long time no speak! I hope you are keeping well.

Glad that you liked the article. I don’t currently have an article planned around discovering and validating assumptions, but I will add this to the backlog!

Take care, Adrian

David Smith

Great article Adrian. I am disappointed whenever I ask to see a project’s requirements and I’m presented with a long list of requirements stated in a Requirements Catalogue, with no sign of any models.

The first thing that comes to mind is how did they arrive at these requirements, before I even look to see if they are ambiguous or contradictory.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.