The power of the assumption — The techniques and the examples

In the previous post about the power of assumption, we discussed the assumptions in general and provided one powerful way of using them in a “low-on-time and low-on-information but high-on-commitment” scenario. In this post, we’ll further explore what you can accomplish just by assuming things the right way.

1. You can choose the solution which is optimal for *both* you and your client

In the engineering world, any problem defined by a set of requirements can be solved by several different technical solutions, and when all those possible solutions are considered together, they compose what is called “the solution space” — a set of all possible solutions for a given problem/set of requirements (if you want to know more about this concept — this article should get you started).

Since that solution space includes all possible solutions, it also includes the one that would work best for our client and us simultaneously. So we need a way to extract it. The easiest way to mold and navigate the solution space is to fence and then isolate the set of solutions we prefer (and are still good solutions for the client — that is a crucial thing we must never forget, as we’re not designing the solution for our amusement but rather for our client and their business needs/ideas) with a carefully selected set of assumptions — remember, they are just additional requirements, and each additional requirement directly influences the solution space by either restricting or enlarging it — depending on the particular requirement added.

The process here, therefore, is to take a kernel idea provided by the client and — using well-formed assumptions — design the requirements around it so that they pick the “just right” solution from the overall solution space. Where “just right” caters not *only* to the needs of the client but also to your organization’s strengths.

2. You can “stabilize” the project environment in a way that allows you to estimate and plan significantly better

You’ve probably been there — there are some requirements, the client and the vendor (a.k.a. “you”) agree upon them, and then as soon as you start developing things start to change and the “is this a change request or not” discussions start and begin eating everyone’s time and degrading the relationship with the client.

Assumptions fix that. (that is if you know how to write them well, and have written them at the right point in time).

The trick here is to explicitly state the assumptions in the offer/contract and make sure they are written properly — ie. as unambiguous and as detailed as possible, and make them “fragile” in a sense that if the environment changes in a direction that would have a negative impact on the development process or the scope, those assumptions would automatically be invalidated and (this is important) that fact would easily be demonstrable.

Let’s assume that you’re developing a mobile app that heavily depends on an API provided by someone else.

Consider the difference between these two assumptions:

• “API is available and well documented”

And the following set

• “The API is Restful, it is well documented and the documentation includes usage examples”
• “The API provides the sandbox test environment”
• “API is fully featured, available, and testable at least 2 weeks prior to development start”
• “API features fully match the functional requirements of the system and no additional complex processing of the API response or combining the results of the multiple API calls is needed besides the basic decorating or simple linear combinations”

The first assumption would still stand regardless of whether the API is JSON: API, GraphQL, or SOAP, or some custom abomination, not available fully during half of the development, and that in order to accomplish anything of relevance in your app would require you combining and arranging responses from 5 different API endpoints in complicated ways.

The other set would break like a dry twig in those conditions.

Now if your contracts include stipulations that trigger change requests or some other measure by default as soon as some key assumptions are invalidated by the real-world situation — provided your assumptions are realistic and written in good faith — the whole “is this change request or not” thing pretty much goes away, the relationship with the client is preserved and you can spend your time developing rather than doing “document and mail forensics” to prove whether something was agreed upon previously or is a billable change request.

IMPORTANT: I’ve said above “provided that your ‘fragile’ assumptions were realistic and written in good faith”, That is crucial, as it’s very easy to use “fragile” assumptions as a sort of trap or a minefield where you start with *expecting* the client to break them so you can charge them for the CRs quickly and early. That approach is opposite of “written in good faith” and you should never do it (unless you are a terrible person, in which case you probably should do it, as it’s very effective).

The key is for assumptions to be realistic — meaning that they provide a set of requirements for the solution that you honestly believe to be of good quality, while at the same time they are detailed enough that they cover all the main risks that you expect in the project.

This is where you can really use your experience with past projects in order to protect yourself from the things you know might go wrong.

Assumptions are tightly connected with risk management — as they are very suitable for stabilizing the scope in areas where we identified significant risks. So in order to be able to write good assumptions, you’d also need to be able to identify risks well.

3. You can guide your estimates towards the given target in a meaningful way

Another scenario where assumptions really come in handy is when you’re trying to get a “committable” value out of your estimated range with as little risk as possible.

As a refresher — estimates are always a range with the “most likely” the value placed somewhere between the optimistic and pessimistic extremes. The range communicates the uncertainty (risk) that the estimators have about the amount of work that would be needed for the implementation of the technical solution for the currently known scope. The commitment, consequently, is a value within the said estimated range that you are willing to “commit” to — ie. a budget value in which you believe you can build the software product or a feature — with relative confidence.

You’ve also heard about the cone of uncertainty and it depicts the typical error margins due to the undefined scope. 

Those two (estimate and the cone) error margins add up, and at the beginning of the project, which is usually just about the time you’d typically be asked to do an estimate, the error margins can be in the multiples of 100% (yes, that’s not the typo — 400% is often cited value for the scope related estimation errors at the beginning of the project — before any real requirements are done).

So if know that there is a 100%–400% area where our real effort might fall, that means that our estimate, and consequently the bid can be anything in that range, and picking a lower number will introduce a higher budget overflow risk while increasing our chances of getting the contract, and vice versa. So how do we select a lower committable budget while not increasing the risk?

The approach is pretty similar to one described previously in this very text, and they do often go hand in hand.

The idea is to identify functional segments/system areas where most of your uncertainty lies (stuff like 3rd party integrations, very complex business processes/logic, tricky operational requirements or dependency on external teams you have no experience working with, etc.) and then “assume them away” — by creating a set of assumptions that both remove that uncertainty away and at the same time use solutions, techniques and technologies your organization is familiar with and can utilize them in an optimal way.

However, here again, it is of extreme importance that whatever assumption you propose — has to be both feasible and you honestly must believe that the resulting solution would be of the required quality and good for the client.

What you end up with is an estimate that is biased towards a potential solution through a set of carefully selected assumptions, and where that solution is selected so it fits the target budget for the project (provided by the sales typically) as well as it possibly can right from the start. This approach eliminates the “please estimate effort for X — why is the estimate so high? — can you reestimate and make it lower?” sales/pm-engineering estimation loop that we all know and love (hate) so much.

4. You can significantly improve the quality of your estimations

“A business analyst wields its newfound power responsibly, digital art” (OpenAI Dall-E, 2022)

Assumptions are pure gold that (should) come as one of the mandatory results of your estimation process — provided you do it correctly, but more about that in a couple of weeks.

The "method"

Now that we covered a few techniques and scenarios where a well-designed set of assumptions can (and do) make all the difference in the world, what we still need to figure out is some kind of process for coming up with those assumptions.

And one fairly simple process, which utilizes all the experience you’ve gathered so far in your career and that results in a relatively comprehensive set of assumptions whose role is to stabilize a particular project environment would look something like this:

Trigger event: You are confronted with an environment that has a lot of inherent risks and unknowns, but you are still tasked with giving some form of fixed commitment

1. First, think about all the reasons you can think of that prevents you from feeling secure in giving commitment at this point (the stuff that scares/worries you)
2. Now visualize the reality in which those reasons do not exists, and in particular, pay close attention to what exists in their place — ie. with what you’ve replaced them within this new reality of yours
3. Write a “diff” between those two realities in as much detail as you can
4. That diff you came up with is the list of assumptions that need to be fulfilled in order for the risks to go away.
5. You win and become an inspiration to millions around the world.

So it might feel a bit abstract, all that talk about visualizing and diffing realities (but you have to admit it sounds rather cool) but it’s really not — as what you come with is typically stuff like this:

• API documentation is written using OpenAPI 3.0 standard, documents every API endpoint, and includes illustrative examples of complex usage for each of the documented endpoints
• An IT operations provider is available during development for consulting
• An IT operations provider’s staff working on the project have at least one year of operational experience with technologies X, Y, Z
• An IT operations provider’s staff has extensive experience and expertise in technologies Q, W, and E and at least 3 years of experience with each
• UI designs are ready and verified at the latest one week prior to the development start for each individual functional section.
• UI designs and wireframes are verified against the functional requirements and confirmed to be complete and accurate before being delivered to the development team

The level of detail will depend on your previous experience and the particular situation but the rule of thumb is always that whenever you feel that you can make an assumption more precise, then do so. Otherwise, you might end up adding some silent assumptions to your explicit ones — and since that former variant is bad, that will just result in weakening the explicit assumption you worked so much to create in the first place.

Conclusion

Assumptions are nature’s out-of-the-box solution to “known unknowns”, and if used correctly they can even somewhat reduce the “unknown unknowns” space as a “side-effect” — although they can obviously never eliminate it completely. And for that alone, they are an extremely powerful tool, as a large chunk of the problems related to IT development often stems from the incomplete requirements implicitly supplemented by a set of various silent assumptions by different actors within the project.

Understanding assumptions and using them consciously (and communicating them loudly and clearly) is, at least in my opinion and experience an extremely powerful and resource-light / effective tool. It provides you with a way of tackling uncertainties at the early stages of a project, shields you from most of the harm in the “fluid” requirements scenarios, and as an added bonus, you’ll be able to understand (and tweak) your estimates much better.

So as a final word — don’t be afraid of assuming, just make sure you let everyone know when you do, and you’ll have a superpower at your disposal without the inconvenience of going through lab explosions, exposure to radiation, or other personal trauma in general. I find it much more enjoyable and altogether safer this way.