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!