Project Practitioners > Don't Assume Quietly

Don't Assume Quietly

By Sinikka Waugh

I'm turning over a new leaf today.   Starting now, I'm going to do everything in my power to help us talk about our assumptions.  This will strike you as odd, I suspect, since we're all so familiar with the quaint little saying about what happens when we ass u me.  But from now on, I'm going to wear my assumptions on my sleeve, and I encourage you to do the same.

You see, my friends, assumptions are like... well... let's just say we've all got 'em.   Where we get into trouble (and incidentally, where any good analogy falls short) is when we keep them to ourselves.

Have you ever noticed the “Assumptions” section of project documents?  I’ve seen them in business cases, project proposal documents, charters, statements of work, scope documents, requirements documents, design documents, and test plans.  A valuable little section, often near the front – usually near any estimates of time or cost – that simply tells the reader, “here’s what we believe to be true, or the educated guesses we have made, since we don’t have all of the facts and can’t foretell the future.”  While they are not necessarily actionable, they are statements of what the document writers believe to be true about the situation, environment, project, etc., and that shed light into the way the authors perceive the situation.

A mentor once told me to avoid assumptions, since an assumption is just a weak way of stating a risk.  Stating a thing as an assumption, he said, was like saying, “I’m going to state this risk as a matter of fact so I don’t have to take any further action on it.”  His perspective was that we shouldn’t even have assumptions sections, because we should state our risks as actionable risks.

I don’t disagree that we should state risks as actionable risks, but I’ve begun looking at assumptions from a different perspective.  What if we simply can’t avoid making assumptions?  What if by calling out our assumptions, we’re actually making it easier to work together?  What if the real risk is in not stating what we assume?

Instead of limiting the number of statements that show up in the assumptions section of a project document, I think we ought to fill it with as much as we can, to help others understand our perspective better.

We each come into any situation with a set of preconceived notions, based on our own life experiences.  Some assumptions are reasonable, and based on societal norms or widely accepted business practices.  But most of our assumptions are so ingrained within our own personal background and outlook that we have no right to imagine that anyone else shares exactly the same assumption.

The perfect place to apply this first is in project roles.  How many times does something slip through the cracks because we each assumed the other was taking care of it?  How often does work get duplicated because we each assumed that task fell to us?  Now how many of those could have been avoided if we had just taken time to articulate our assumptions?

Instead of…fielding calls from disgruntled business analysts about my communication skills, what if...I had made sure the BA lead and I had the same assumptions about the flow of information: 

PM to BA Lead:  I assume that as Business Analyst Lead, you’ll be representing the Business Analysts on the project – sharing their input with the project leadership group, and sharing information back from the project leadership to them.

BA Lead to PM:  Oh, really, I thought I was just coordinating work efforts like I did on my last project.  I hadn’t expected to have to manage communications either direction. 

PM to BA Lead:  Okay, so we’re not on the same page, what are your thoughts around how we resolve this?...

Another great place to apply this is in defining communication strategies.  How often do we miss simple details about communication preferences that cause us more work in the long run?  How often do we set ourselves up for failure instead of success just because we didn’t share assumptions on how to communicate?  How much easier would things be if we just took time to talk about our assumptions? 

Instead of…taking calls from a sponsor-turned-micromanager wondering what we’re working on today, what if...I had made sure the sponsor and I had the same assumptions about frequency of updates:

Sponsor to PM:  I assume that if I don’t hear from you on a daily basis, that means you’re not making progress.

PM to Sponsor:  Oh!  I had just assumed we’d use the weekly status report we agreed to, and reach out to you when we need help, but otherwise “no news is good news.”

We can also use our assumptions as ways to help set expectations.  How often do we use terms like “ready” or “almost done” with our own meanings, or use time frames like “this week” to mean anything from Monday morning to late Saturday night.  Wouldn’t it be easier to call out our assumptions so everyone has the same expectations?

Instead of…calling on the technical resource named as “backup” while the tech lead is out of the office, and frustrating him with work he wasn’t expecting to have to handle, what if...I had made sure the tech lead and I had set the same expectations with each other, the backup, and the customer?

PM to Tech Lead:  I assume that since you’ve named a backup in your absence, that your backup will be able to handle issues as they come up so we’re not stopped in our tracks while you’re gone.

Tech Lead to PM:  Oh!  Glad you said something.  That’s not really what I was thinking.  My backup is only familiar with part of the application, and anything else would take him more work to uncover than it would for me to resolve when I get back.

PM to Tech Lead:  I’m okay with this, but let’s figure out what the client’s expectations are before you leave on vacation…

All that being said, I’d like to change the expression from “don’t assume…” to “don’t assume quietly…”    We all assume things, the problem is if we don’t talk about what we’re assuming, we won’t be able to recognize the gaps between our assumptions until it’s too late.

Go ahead and assume, I say.   But don’t do it quietly.  Tell me what you’re thinking.  Be candid.  Be forthright.  If you think your role is to do X and mine is to do Y, then tell me that, so I can confirm we’re on the same page – or get us there if we’re not.  If you’re expecting me to do something in a certain way, tell me what your assumption is so I can meet or adjust your expectations.

If I don’t think you’ve been clear about your assumptions, I’m going to ask you to tell me about them.  If I haven’t told you clearly about mine, I’m hoping you’ll ask me to spell them out.  It’s okay to assume, but let’s make an effort to not do it quietly!

Related Links
Kent McDonald once described project hassles of unspoken assumptions. Instead of assuming roles, document them in a Team Roles and Responsibilities List. When you bring in new team members, even temporarily, don't assume they know all the passwords.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

I really like the phrase "don't assume quietly." I think another place quiet or silent assumptions happen is related to people (not) speaking up about issues they see. The underlying assumption is likely "no one will listen to me" or "management never pays attention anyway, why bother".

I've seen teams do a section in a project kickoff meeting where they say "ok, get it all on the table - what assumptions do you already have about this project, what we should and shouldn't do, what we can and can't do, what the customer does or doesn't want, etc. Get it out there." And they do a fast brainstorm to figure out where everyone is. It can be very revealing - and sometimes even funny :-) to find out how all over the map people are. (It's only funny if you're finding out very early in the project before anything goes WRONG because of all the different assumptions....)

I like what this article says about making it each person's responsibility to state their assumptions. I also find myself thinking about how to "goose" that thinking a little throughout a project. How to get assumptions on the table in each team meeting? I think your 3 categories give a good frame for that. "OK, people, (1-roles) What assumptions are we each making about what each person's role is during this part of the project 92-communication) Who needs to know what right now and what assumptions are we making about how they're finding out? (3-Expectations) Given what each of us is working on and what we need from each other, what expectations do we have about what we're getting when? etc.

This is just me thinking about how to apply these concepts in a consistent manner across a team - thanks for the provoking of some new ideas....

Great text! And what i find interesting about it is that once you tell your real assumptions you probably start to creat an atmosphere of confidence among the team members... telling what you thing about it will certainly support others to do the same and hopefully team building and integration will be achieved in the long run...

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.