Let me be candid and up front – I do not like assumptions. Never have, never will. I truly believe that they can be one of the most destructive forces in business analysis. I do not like them here or there. I would not like them anywhere. I do not like them I believe, so make them go away and leave! (Thank you Dr. Seuss, you always inspire me). So why is Bob the BA all jacked up about assumptions? Well… let’s just say he has first-hand experience with the pain they can bring. Now even though I do not like them I will also recognize up front that they are a necessary evil. Notice I said evil.
The dictionary says an assumption is “a fact or statement taken for granted” and that is the first problem that I have with them. We take things for granted and in many cases due diligence is not carried out to prove or disprove what needs to be done. As a result, we pay the price of taking something for granted when it does not go as expected. Do you see the problem? I cannot manage stakeholder expectations with a vague assumption – something people took for granted. I need fully fleshed out quantified and qualified requirements to manage expectations. Your view and my view of an assumption can simply be different. It leaves things open to interpretation.
The BABOK® definition states “Assumptions are influencing factors that are believed to be true but have not been confirmed to be accurate”. So the take away here is that we use them to influence a specific direction. Okay, we all get it. We often do not have enough information at the beginning of a project so we make some assumptions to help provide direction. This is a key concept for project managers in getting the project to move forward quickly but it can be disastrous to business analysis efforts. This is the “necessary” part which is all well and good except for the fact that many of these assumptions never get confirmed as being accurate. This is where the necessary turns evil and it gives me the chills. I could be influencing people down the wrong path or I could be influenced by them and doing analysis that is not required.
Besides taking things for granted, a pet peeve of mine regarding assumptions is how people use them. They throw them up into the air to see where they will land or they chuck them over the wall and forget about them. “Well I put that in the assumptions so they should have known that they needed to do something”. Really? That statement alone erodes your credibility and overall trust you have with your stakeholders. It is a bad practice to assume your stakeholders will do something based on an ambiguous statement buried deep in a requirements document. Even if your corporate culture embraces this practice, generally it is the BA that will get the blame and not the stakeholders so why would you want to follow it? Remember the Titanic? If you want your ship to sail do not throw your assumption over the iceberg “wall” that is waiting to sink you.
We all know the old saying right? When you “assume” you make an “A**” out of “U” and “ME”. When it happens it can ruin projects, systems and people all because we failed to confirm the assumption. Let me say this; all assumptions before requirements signoff should turn into risks, issues, constraints or requirements. I will say it again; risks, issues, constraints or requirements. Yes, we could debate that there are no such things as issues – only risks. We can also debate that constraints (and assumptions) are indeed types of requirements (which I believe they are) but for similar reasons I have defined all of these as separate entities for my explanation. Many corporate cultures have their own standards or views on why they are kept separate and where they are documented, so for that purpose I have stated all of these terms to differentiate that assumptions, like the caterpillar must transform. Without this transformation you have ambiguity. You must turn assumptions into risks, issues, constraints or requirements to remove the ambiguity. In the end, if you have quantified and clarified your assumption you will “ILLUME” and not “ASSUME”. People will not speak “ILL” of “U” and “ME” because you did “ILLUME” them or “bring light” to your requirements understanding. Being able to illume is a lot better than assume don’t you think?
Yes, I am being very hard on my friends the assumptions and I am actually just getting started! I hear rumor that they do not want to be my friends anymore. So the assumptions and I will take the professional route; we will be cordial and understand that we have to work together even if we do not like one other. There is a place for assumptions but only before requirements signoff. Want to know why or simply want to really explore the ins and outs of assumptions fully? I have a lot more to say which you can read in my article.
For more information on this topic:
- See our course called Project R.E.A.L. (Real Experience, Applied Learning)
- Read my Assumptions are Project Killers! article. (Login is required. Registration is free.)