Blog post
Assuming is an integral part of our conscious experience, but still, assumptions have a bad “rep” when it comes to engineering. Why is it so and, more importantly, is it deserved and can we still use them to our benefit somehow?
A bit of theory
It can safely be said that, at least to a certain degree, we assume our way through life. The truth is that our brains simply don’t possess enough “processing power” to analyze every single change in every single detail of every moment of our conscious experience in real time.
In order to compensate for that — we, and by “we” I mean “our brain”, assume. And that fact is well established in neuroscience research (as for example described here or here, etc.)
Although the article mentioned above describes skipping the processing of the information by assuming the expected result, assumptions still work just as well in the scenario where we don’t have all information, to begin with, but are still expected to come up with some conclusion or a result anyway.
Since assumptions are nothing other than our best guesses about the things that we “know that we don’t know” (or we simply don’t have enough time to process fully), our default solution to the problem of the missing information is to just assume those information gaps away.
The point I’m trying to make here is that the statement above is not an abstract observational fact but that it applies just as well to the assumptions we make in a much more particular context of software requirements and IT engineering in general.
The reputation
You might’ve noticed a bit of contradiction here – so far we’ve asserted that the assumptions are perfectly normal, and are an integral part of how we perceive everyday reality. Still, we all know that when it comes to engineering, they have quite a bad reputation.
It is said that the assumptions make an ass out of both you and me, and some even go as far as suggesting that the assumption is the mother of all f**kups.
And generally speaking, “they” are right.
However, “they” do make one assumption themselves. And that assumption is that all assumptions are created equal.
That particular assumption is, however, wrong.
The thing is, assumptions in the context of engineering are not a monolithic concept, but rather come in two “flavors”. In particular, we should distinguish between non-communicated (silent) assumptions and communicated ones.
Uncommunicated ones are bad. Those are the ones that so rudely make an ass out of you and me and foster all those nasty f**kups we keep hearing about.
The (clearly) communicated kind is perfectly fine though, and I’ll even argue that it’s an extremely valuable tool for anyone creating any requirements and designing any system in an environment where information is incomplete or fragmented or the time available is insufficient for the task at hand.
So, with all that in mind, you are right to ask the proverbial “what’s in it for me, the business analyst?”.
One simple but quite powerful usage scenario
“An engineer thinking up assumptions, digital art” (OpenAI Dall-E 2022)
There are actually quite a few ways to use assumptions to our advantage and we’ll start with the one that is rather easy to implement and whose (hopefully positive) effects should be immediately felt.
Observe that the communicated or “spoken” assumptions are essentially just additional requirements. It is as simple as that. It can sound a bit trivial, but it’s quite powerful, as unlike the majority of the requirements you’ll be working on in a role of a business analyst or when documenting requirements — *you* are the one authoring the assumptions and consequently the requirements that they represent — and therefore, you have the control over them.
Imagine the following scenario.
You are tasked with providing the high-level requirements for a project and you know that those requirements will later be used for the effort estimation. Your only input is what the client provided – and that typically tends to be rather lopsided and generally skewed towards the topics that the client is either strongly opinionated about, are the core of its business idea, or are just things that whoever created the information is familiar with.
In other words, what you received from the client and are supposed to base your entire analysis and/or estimate upon — is usually quite far from being functionally complete.
Now, “where’s the problem?” you say, “we can compile a detailed list of questions based upon what we see is missing and the client will answer those questions, and we’ll fill the missing requirements with the information provided within their answers”.
I envy your innocence.
That never really works, at least in my experience, as you’ll either get the information that is still incomplete, or you’ll ask things that the client hasn’t really thought about and, consequently, won’t be able to give you a useful answer on the spot. And the timeframe for getting the answers is typically very constrained at this point in the project lifecycle.
As a result, you’ll just end up putting yourself in the position where the client (and often your project manager/sales rep/team lead as well) thinks that you’ve asked everything you wanted to ask and that they provided you with all the answers they could and now everything is peachy. The reality is that you’re still stuck with a fractured and incomplete set of requirements while the client and your boss believe that you’re fine, and in my opinion (and experience), you’re typically way worse off at that point.
So what can you do to prevent that?
Remember how we observed that the spoken/communicated/documented assumptions are really the requirements you have control over? Let’s find out what can we do with that.
Ask for confirmation rather than for the information
If we assume that the above is true (note that we’ve clearly stated our assumption here), then what logically follows is that, given that we’re competent functional solution designers/business analysts, we can “plug” all the holes in the requirements with some reasonable assumptions until the system described is functionally complete and makes sense to us first, and only then turn to the client for answers or even just for confirmations of our assumptions.
It’s important however to keep our assumptions relatively big in scope and to assume standardized, easily communicable solutions as much as possible — as otherwise you’re risking going down the rabbit hole of designing low-level functional details in a situation where you don’t have time for that.
Why is this approach any different from the “classic” one described before? You still end up asking the client some questions related to the missing information, don’t you?
Well, the main difference is that in the first scenario we started with a fragmented system description and were asking the user to provide us with the information required to fill the holes, as opposed to the alternative approach where we start with a functionally complete system defined by the initial set of requirements and augmented with a set of reasonable assumptions that bridge the “functional gaps”, and then we’re just asking the client to confirm that our assumptions are correct/acceptable.
This is a very significant difference — as the question “is this particular assumption valid?” is much more precise and easy to understand and answer than “How did you plan for this feature to work?” “What about this situation?” etc.
Also, and that is very important — the answers you get either validate your assumptions or not, but in any case, they allow you to very transparently produce a “backlog” of assumptions that are invalid and then work them one by one with the client — where the client is very aware of open topics — avoiding that entire “but you asked and we answered, why is that not clear yet” situation — as the answers to the “is this assumption correct” are manly yes/no ones, and it’s very easy for the client to understand what exactly is open and what isn’t.
In a nutshell, by filling the functional gaps with precisely stated and clearly communicated assumptions, the communication with the client immediately becomes much more manageable and exact in nature.
Add to that the fact the assumptions are easily enhanced and illustrated with examples — for both the situations where the assumption is validated and for the situations where it isn’t and you have yourself a very very powerful tool.
But that’s not all!
There are a couple of other handy techniques that become available as unlockables in your “functional designer skill tree” once you start looking at the assumptions in this new way.
UPDATED - Check the techniques and the examples in part 2 of our writings about assumptions!
