Assumptions are dangerous

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.

“Your assumptions are your windows on the world. Scrub them off every once in a while, or the light won’t come in.” – Isaac Asimov

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 have 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, so I was planning to use 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 1, step 2, step 3…) 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.

Hat tip to @ClayForsberg for the Asimov quote.

If Godzilla taught user interface lessons…

A few weeks ago, I helped my mom buy an iPad.

You would think that my mom, who is in her 70s, would be the one learning the most from this exercise, but you’d be wrong.

Going through this with her simply reminded me (again) to discard all assumptions when building a user interface, when training and most of all, when designing a process that brings new customers into the fold.

So why Godzilla?

Godzilla has very short arms, much like a T-Rex. Those of you who remember Bill Harley’s dinosaur story about the boy who wanted to be a T-Rex will be familiar with Godzilla’s challenge: Harley’s dinosaur ate the french fries off his plate like a dog because his arms wouldn’t reach the fork.

Godzilla would have an equally rough time using software that assumes the user can touch the iPad’s screen.

What I’m getting at here is that making assumptions about your clientele (or in this story’s case – end users) can threaten your ability to help them if it’s focused in the wrong place because you made too many assumptions.

My Assumptions

Before you think I’m accusing you of making assumptions about your clientele, keep in mind that I had done the same thing prior to going through this iPad install: I assumed that there was some familiarity with iPads/iPhones and touch devices in general – even though I knew better.

While mom has been a desktop computer user for quite a long time – she doesn’t have a smartphone or another touch device, so we were going into uncharted territory. This also meant that there was a pretty good chance that she’d have no familiarity with iOS basics, the iOS app store, iTunes, or anything else in that sphere of knowledge.

The adventure

Let’s go over what we did, what I learned and what you can take away from this little adventure.

The steps we performed: Initial power on, get wireless working so everything else would work, connect to iTunes store, create an iTunes account, timeout while fiddling with passwords and addresses, start over on the iTunes store setup and thus, account setup, then setup iTunes and download the Kindle reader app.

For someone in the geek business, this is a fairly simple exercise. Here’s the trick – if you’re an iPad owner for over a year – do you remember the steps and details of the signup and setup process? Do you think it has changed in the last year, much less two or three years? Of course.

So again, assumptions creep into the discussion. My probably-faulty memory was helping mom through this process without seeing her screen, so another layer of frivolity crept in.

After the create-an-account timeout, things went pretty smooth but the assumption monster was always peeking around from behind the iPad.

Your turn

Given my story about the iPad, think about the process you go through with a new client. Sometimes they seem so lost, so uninformed, so out of touch.

And here we are, looking at them like fools. They are the fools, so to speak, who just paid us to help them deal with the fact that they don’t know the things they paid us to help them with.

Perhaps a definition is in order.

Client (n) – “a person or organization in the case of a professional person or company.”

If your newest client told your best prospect that they are “In the care of…” your business, what would they say?

Is that different you would want them to say? You know the truth, be it good or not so good.

You may call them clients because you want to believe you treat them differently than ‘just a customer’, but if you don’t, they aren’t.

Back to those assumptions

Think about the last time you visited a doctor’s office. You come in, someone shoves a clipboard into your hands and you write the same information three times on different pieces of paper. Occasionally, someone asks a question about one of your answers.

Is this process guided? Non-repetitive? What about your questions? Do all the surprises and customer / client / patient assumptions go away?

On their next visit to your office, shop, warehouse or store… do they know exactly what to expect before they arrive? Do they leave without having experienced unexpected, unpleasant surprises? Do they know what they should expect the *next* time?

Assumptions work that way too.