When you assume, you make an ass out of u and me
The topic of assumptions cropped up in an end of project retro recently and it started us thinking about how to communicate in a way that better manages expectations.
In our example, we’d replaced a CRM with a stripped-down reporting tool, and it had gone live to raptourous applause. Everyone was feeling that fuzzy retro feeling, when the following question arose:
“So, are we starting work on the next iteration now?”
…. well that raised a few eyebrows.
Iteration 2 will follow immediately on the tails of iteration 1.
The customer knows we’re booked up for 8-12 weeks.
What went wrong?
We always try to communicate our lead time in initial discussions. But a few months of design and several sprints later, it’s not surprising if this information disappears from people’s minds.
Come to think of it, it shouldn’t be surprising if any information from an initial discussion disappears from people’s minds.
Design and development are full-on. There are daily progress calls and testing, and decisions are needed at every turn.
So, unless we are prepared to continually remind people about things, we shouldn’t assume that they know everything we know, just because we maybe mentioned it once.
We live and breathe this stuff, while our product owners are often being carried along with us, bouyed up by an exceptionally large amount of trust.
Fortunately in the example of the CRM system, there was a large amount of understanding and respect in the team – something that will save you from almost any miscommunication (see David Nice’s post about relationships for more on this).
But when an assumption is not understood or explained, major problems can occur.
So what are assumptions?
An assumption is a personally held belief or expectation about an outcome, place, person or thing.
We make these assumptions every day. We turn a tap on assuming water will come out, plan our journey assuming we’ll arrive at our destination on time or arrive at KFC believing there will be chicken. But sometimes these assumptions turn out to be plain wrong. Then what do you do?
At the beginning of a project you can’t possibly know everything with 100% certainty (if you do please submit lottery numbers here).
The big mistake
Our biggest mistake can come from assuming others think the same way we think. They don’t.
The one thing we should always assume is that others can interpret what we say, quite differently to what we mean. Consequently the person across from us may understand something that’s different from the message we are trying to get across. Until we have addressed this, it’s sensible to assume that we may not be fully understood.
“Our biggest mistake can come from assuming others think the same way we think. They don’t. .”
Sense check your assumptions
Quite often it is not the specified unknowns that are the biggest problem, but the things we don’t address because we think we know the answer.
If you have not asked a clarifying question because you believe you already know what the answer is, you’re not going to be able to separate assumptions from the facts. This will result in that sinking feeling that is experienced when something we believed to be ‘true’ turns out be false (i.e. I thought we had been allocated enough resources available for this work).
The results of an assumption that has been proven to be false can have a major impact on the project.
Despite the old saying, “when you assume something, you make an ass out of you and me,” assumptions will always be prevalent in any project (no matter what methodology you may be using to manage it). It is important to try to identify the assumptions held by each stakeholder as early as possible and to continue to do this throughout the duration of the work.
Of course assumptions that are correctly identified as being in conflict with each other or the facts can present an opportunity to prevent future problems. Using and managing assumptions well can be a great way to improve planning and communications in projects