For the last month or so, I’ve been working on an all-consuming project. Yesterday, during a conversation with the recipient of this work, it became obvious that both of us had made some assumptions about the work that overcomplicated the project in the short term. In the long term, no time was wasted on this large, multi-phase project but in the short term – the assumptions were stunning.
Despite hours of phone conversations and emails, detailed technical specifications (geeks: think WSDL but newer), we still managed to have a rather large gap in the workflow of this project. Fortunately, there wasn’t any damage done and the situation merely juggles the position of a few tasks on the timeline, but we didn’t have to be that lucky.
The root of assumptions
The root of assumptions, at least in this case, was both groups of people thinking they had properly and completely described the project. Bear in mind that there are mindmaps and API calls and a bunch of other technobabble. Still, this happened.
But why?
Not enough questions?
Not enough diagrams?
Not enough workflow description?
Not enough conversation?
Perhaps all of those, but there had been plenty. What ultimately caused this was quite simple: there was a fundamental asset involved in this project that I was unaware of. They knew it would be used. I didn’t know it existed, and I was dealing with a similar asset under my control.
I speak vaguely about these things because the details really don’t matter and I don’t want the technical jargon to distract from the meat of the discussion: assumptions are dangerous.
The project will come in on time and it’ll be good for both parties, but it might not have worked out as well had this discovery happened a week later. It wouldn’t have broken anything, but it would have wasted some time, or at least caused work to be done that won’t be needed for a month or more and that would delay work needed soon.
There are many ways that assumptions can endanger your projects. The key is to have a process that does as much as possible to eliminate them.
Eliminating assumptions with a third party
The most dangerous assumption I made was that the technical documentation and the mindmaps would effectively communicate the project’s details to a technical audience. At a granular level that was true. Where this assumption got me was at the 10,000 foot level – the level where you break down a ton of technical workflow to 10 sentences (step one, step two, step three…) in plain old English that anyone would understand.
Didn’t happen. Six weeks went by without this critical message climbing out of the technical documentation – and even then, it didn’t. It came out when those 10 sentences were written to clarify something that suddenly became confusing.
Many years ago, I was involved in an exercise along these lines where two people with experience in a field had to explain something to each other. Once they reached agreement, they had to explain it to a third person who had no background in the subject.
A fascinating thing happened.
The two people who thought they were describing the same thing were still far apart. When each of them described the project to the third party, they were stunned at the assumptions each of them had made – not big ones, not project killing ones, but differences that could create drama, friction, additional cost and so on.
Watching these two people realize they were not talking about the same thing was illuminating and stunning at the same time because the audience was made up of people with similar experience to the two ‘explainers’.
Of course, the exercise was designed to set them up to some extent and the whole idea was communicate to all involved that communication is real work and that it is breathtakingly easy to make a few small assumptions that can take two parties on substantially different paths even though they think they are talking about the same thing.
Getting two people (or two groups) to understand each other and agree that they are talking about the same thing requires great care.
Next time you have a project to deliver, involve a third party with much different skills. Describe the project to them and see where the conversation goes. Maybe you can avoid dangerous and potentially costly assumptions.
Want to learn more about Mark or ask him to write about a strategic, operations or marketing problem? See Mark’s site, contact him on Twitter, or email him at [email protected].