There’s an old saying about what happens to you and me when we assume things. I recently had an experience that brought this to life, especially when you don’t confirm or share your assumptions.
Imagine this scenario, you are preparing an estimate for a project at the time when you normal prepare an estimate for a project – at the beginning when you have the least amount of information available suitable for that purpose. To keep from getting wrapped around the axle you make some assumptions to provide key data points. Sometimes these assumptions are specific numbers or metrics that are used in the estimating. Sometimes these assumptions focus around the order in which you deliver certain functionality, or the whether you will be delivering functionality at all. Regardless, you make those assumptions, and you even write them down. You then complete your estimate and proceed happily along the project approval process, figuring if any of the reviewers cared about the assumptions, they could look them up. You documented them after all, didn’t you?
Then imagine a few months down the road, you start to get into the work of the project, and you find out that some of the assumptions you made were not correct. That’s bad enough, but when those incorrect assumptions have a dramatic (usually detrimental) impact on your projects budget and scope, the proverbial donkey waste starts hitting the proverbial fan.
So what went wrong? You wrote the assumptions down. They were available for people to review. What more could you have done? Below is a list of quick suggestions I have for using assumptions to their fullest benefit:
- Keep track of your assumptions and where they were used. Writing down your assumptions is certainly a good start. Tying them to what estimates were based on those assumptions is even better, especially when you revisit your understanding of the project and find that your assumptions are either confirmed or disproved, you can revise the expectations of your stakeholders appropriately.
- Let people know that you are making an assumption. Although it is certainly helpful to write your assumptions down for the purposes of institutional memory, it’s even more helpful when you let those who may be affected that assumptions are being made. They may find out about it sooner or later through other means, but that’s usually after something very bad has happened.
- Assume that you are not going to do something, don’t ever assume that someone else actually will. The experience that inspired the scenario I described above included one project (let’s call it project A) explicitly assuming that another project (we’ll call this one project B) was going to do some things that were key to the success of the other project. When those assumptions were made Project B had not even started, and the items that were assumed we would be tackling were much more critical to the success of Project A. They were assumed away in order to produce a more appealing estimate. Once those assumptions were identified and declared false, Project A had to go through a change request to add those responsibilities back to the project.
- Verify whether your assumption is even valid. Assuming things away can be very convenient, but things can get ugly if there is no way that the assumption would ever be true. By making invalid assumptions, and basing estimates and plans on those assumptions, you are inviting the inevitable “what were you thinking?” discussions, not to mention delays and increased costs.
- Revisit your assumptions often. Assumptions are handy ways to aid decision making when you don’t have much information. Once you get that information, you should revisit those assumptions to make sure the decisions still make sense. The quicker you revisit your assumptions, the more flexibility you will have to change your decisions when appropriate without suffering too many consequences.
- Communicate with the appropriate stakeholders as soon as an assumption is proven false. Just like you should communicate what your assumptions are, you should also let your key stakeholders know when your assumptions have proven false. This ties to the above point. If those assumptions do turn out to be false, you may need your stakeholder’s support to revise the decisions tied to those assumptions.
In the story of Project A and Project B, we were fortunate. We caught the incorrect assumption early enough that decisions could be revised. Had we not followed several of the items above however, Project A may have about to turn off a critical system with no way of supporting key processes. Their only response would have been, “Oh, well we thought Project B was going to do that. See, it’s right here in our assumptions we made a year ago.” Luckily, we won’t have to witness that discussion.