[alert type=”general”] This guest post by Adrian Reed is part of a series of contributions by business analysis professionals I respect, and whose work I follow. I’ve followed Adrian’s blog for a while. I especially enjoyed his article, “Stop the project plan crash. You are the expert.” Enjoy! – JB[/alert]
I was recently boarding a flight, and whilst I was waiting to climb the steps to the aircraft, I happened to look around the runway. I saw, at the edge of the tarmac, what appeared (initially) to be a rather obvious sign. The sign read “Caution Aircraft”. I smiled – and I sensed others around me found the sign entertaining too. In fact, I could hear a couple chuckling behind me – I mean, come on. It’s a runway. It’s obvious that there are going to be planes there. Why on earth would we need a sign to remind us of that?
The couple behind me continued to chuckle about the “obviousness” of the sign as we boarded the plane. As I climbed the stepsand boarded, curiosity got the better of me and I looked down from the steps. From this new vantage point, I noticed that the tarmac was buzzing with activity. Not only were there planes, but there were trucks carrying fuel, buggies carrying luggage, food delivery vans and more. When planes landed, these support vehicles rushed over to get them ready for the next flight. Many of these support vehicles seemed to come onto the tarmac around where the sign was located, so presumably the sign was a ‘reminder’ for vehicles that were entering an active part of the runway.
With this in mind, perhaps the sign was reminding them of something that might seem obvious from some vantage points – but something that is crucially important. The sign only looked obvious from our perspective because we were looking from the tarmac outwards. If you were driving onto the tarmac from a support road, it might not be clear where the road finishes and the airfield begins. What’s blindingly obvious from one perspective might not be intuitive or “obvious” at all from other perspectives.
The danger of “obviousness” on projects.
This reminded me of a pattern that can occur when progressing change initiatives. On occasion, we might meet with stakeholders who are pushed for time. We might go in and ask them questions about their business, their processes or their systems. We’ll be aiming to understand the business problem or opportunity that they need to address, and we’ll be wanting to help them define the value that they want to deliver. If they are time-pushed, we might hit a nerve. They might deflect our questions by saying:
“But that’s so obvious, we don’t need to discuss that at all”.
Yet by playing the “that’s obvious card” they are making a number of tacit assumptions – they are assuming that:
- What is obvious for them is obvious for everyone
- That everyone involved or impacted by the issue/change/initiative has exactly the same understanding of the “obvious” (i.e. there is no disagreement over the content)
- That the scale and scope of what is “obvious” is consistently understood and there are no ambiguities (and that all interfaces with the “obvious” are clearly defined and agreed)
- That we are all looking at the “obvious” thing from the same vantage point (think of the aircraft example above)
Rarely will all of these statements hold true. In most cases, the stakeholder will have tacit knowledge – that is, knowledge that is so ingrained that they don’t consciously think to mention it. In other cases, we might find that what they tell us is “obvious” hasn’t actually been defined, evaluated or fully thought through. In these cases, it is paramount to probe further! If we don’t, then our change initiatives might flounder, fail, and our organisations may waste resources finding out that different stakeholder groups had a decidedly different view on what is required. Something that is taken for granted might well be missed, and we might only find out when the project crashes and burns.
As business analysts, we create the permission to ask difficult questions—with rapport—which help us to break down the “obvious” barriers and get to the root of a problem. Doing so helps us to ensure our stakeholders get the business outcomes that they need and want.
Hi, Adrian,
Curiously I recently wrote about the other side of the coin (BAs who focus on documenting the obvious while leaving out non-obvious portions that truly need to be spelled out for the delivery team :-). The link to my article is in my signature.
A key points here, with which I agree: first, you can’t assume that anything about the problem or solution domain is obvious without having the conversation. What is obvious for one person is NOT necessarily obvious for everyone.
However, when it comes to project documentation, in many cases I find it relatively easy to evaluate if one is documenting the obvious: 1) is the concept already largely used within the organization? 2) can you, in a quick conversation with the audience of your document, establish that there is no ambiguity or diverse interpretation of what the thing is?
If the answer to the two questions is yes, the risk would be low to move this part of the documentation to the bottom of your priority (or even make the decision to exclude it). This is how you get to focus on the areas that do require solid descriptions to avoid confusion (because time is finite, and knowing how to prioritize specifications is key).
For example, suppose you are documenting login and password recovery features for a new system. If the organization already has multiple systems that use passwords for login, I don’t see much risk involved in providing a brief description that focuses on the security policies that must be enforced by the system (e.g., minimum of 6 digits, etc.), as opposed to writing many paragraphs defining what a password is.
There’s definitely art involved in making the decision of what to document or not in projects. In an ideal world, everything would be completely documented, kept up-to-date as decisions change, and easy to find or ignore when someone is combing through the documentation but don’t need the level of detail provided. But at least in my projects, by the time business analysts and designers finished all the possible project documentation, either the product would have been long shipped, or the organization would have given up in building it already :-).
I’m interested in knowing what you and others think of my stance. Thanks for creating this opportunity to discuss!
Hi Adrian,
I heard about this post via Adriana’s newsletter. I’m glad she passed it along…good stuff here.
I definitely agree with your analysis: more than once I’ve worked on projects where we’ve gotten to the end and something that we thought was “obvious” turned out to be a significant issue.
A couple thoughts to add. You and Adriana pointed out that there’s a certain skill in identifying items that appear obvious but are not. I’d also add that there’s not only the skill but also the willingness to speak up and ask an “obvious” question. It can be scary to ask a question when you think everyone else in the meeting already knows the answer. And I think this is where Business Analysts can add major value: ensuring a clear conversation about the product/project, rather than trying to appear to have all the answers.
On Adriana’s point about documenting the obvious. I actually see that as a different issue. In the password recovery example: if the functionality is documented elsewhere, I would just link to the existing doc in any future projects. I agree that once you’ve agreed to use existing functionality (clarifying that you will be using existing functionality, rather than some variation of it), than re-documenting it again is “obvious” and not useful.
But what I hear in Adrian’s post is a slightly different scenario: a situation where something *appears* to be obvious, but actually is not. In other words, perceived consensus that is hiding complexity/lack of consensus. My experience is that you can quickly identify whether an item is truly obvious by asking a few questions in a meeting or or on a phone call. Ask a few questions, if it truly is an obvious/agreed upon point, no further action needs to be taken (you probably don’t need to document anything). If you ask a few questions and it’s clear that there’s more there, then you can go to work on it.
Thanks Adrian and Adriana for this great discussion. Adriana: it’s always great to read your work, and I’m glad you introduced me to Adrian’s
Peace,
Brian
Well put. I accepted “obvious” thing early in my career (I guess its still kinda early), and I paid for it in the long run. I call them learning experiences and I definitely don’t allow anything that seems obvious stop me from digging a little deeper to really find out the who, what, where and most importantly… WHY?
Thanks for Sharing
Great article. Thanks for sharing.