One saying that many of my colleagues and clients hear me mutter is: Assumptions and Constraints. During my early days at university (and in high school maths), we were taught to list out the assumptions we were making. These assumptions helped define the problem and how we were going to solve it. They also created a set of constraints to narrow down the problem space to something much smaller.

This is exactly what I mean when I talk about Constraints and Assumptions. However, in a general context, there are some differences. The types of assumptions I used to make in those classes included:

• This is an ideal Op-amp¹,
• The fluid is a Newtonian fluid² with a temperature of 25°C.
• The column is perfectly straight³ with no defects.

The critical thing is, we were told to make these specific assumptions (and many more). We were taught these because they were based on repeatable observations in vast amounts of engineering literature. They were specifically there to make the problem smaller and simpler. They constrained the solution space. But, even more critically, we had the proof that these assumptions were valid, logical, and understood.

These assumptions also helped to stop analysis paralysis, as in the vast majority of cases, these additional concerns did not impact the overall outcome. There are instances where you actually need to consider the additional complexity. These instances are where we are operating at the edge of “normal” or need to absolutely maximize the characteristics of the solution.

This provided a clear foundation for how to tackle problems. Listing out the assumptions and making them constraints allowed us to clearly communicate with the lecturer marking our paper that we knew what we were doing and how we would go about it. This was highly technical, yet it was just a simple communication tool.

In many projects that I work on or advise, there are unknown assumptions. They are unknown because almost every stakeholder is making an assumption, but no one knows if others are making the same assumption(s).

A classic example is creating a new system. The development team makes a number of assumptions. But they are assumptions until they get tested, validated, and a consensus is reached with the relevant stakeholders. The team may not even realize that they are making assumptions. By realising that these assumptions are being made, more effective risk management for projects and solutions can be made.

Case studies

Rolling out of multi-factor Authentication for a 200-user client

The client came to me wanting to roll out a project to onboard the entire organisation to being MFA enabled, and then during phase two or the project, MFA enforced for all authentication flows.

There were a number of well identified assumptions made, and then turned into constraints:

• All applications and services that the organisation uses, support the preferred MFA methods either natively, or via SAML/SSO integration into Azure Entra.
• The applications allow controls over when the MFA challenge would be presented.

But during the roll out, we determined that there was a show stopping implicit assumption made:

• All users had a capable mobile device.
• All users that did not have a company issued device, would accept the use of their personal device for the MFA.

These assumptions were made on our side because we did not know the corpus of users well enough. And these assumptions were made on the client’s side because they thought we knew their users.

These assumptions were uncovered quickly, but the roll out of suitable alternatives for the impacted users delayed Phase Two by nearly 12 months as HR policies needed to be updated, hardware security tokens needed to be evaluated, and procedures and processes needed to be updated.

As a lesson learnt, for other MFA rollout projects, we now challenge these very assumptions and ask the client to validate it.

Internet speeds on remote rural farms

While designing a compute system to perform AI inference on large datasets of images that were collected on a farm. A core assumption that drove a lot of decisions was:

The internet speed in the locations of our main clients will not be fast enough for the farmer to be able to upload the data and get a result soon enough for it to be valuable.

That one statement actually contained a few assumptions:

• Internet speeds will not be fast enough.
• The turnaround time was critical to the value that the farmers received.

Even with the arrival of cheap, high bandwidth satellite data connections, this assumption stayed true-ish. This one constraint led to at least three possible design choices:

• The vast quantities of data and have localised micro data centres to process these data sets. Either the farmers would physically deliver the data to the location, or we would.
• We would deploy the necessary compute at the farmers location so that they can compute in a co-location to where they collected the data.
• We do the entire collection and processing as a full service.

There were other options and choices that were made and explored, but these were the three that were re-occurring and resonated the most. This assumption and potential decisions were not only technical in nature, but also non-technical and directly impacted the business strategy, direction, business model, and all financial calculations.

How to identify the assumptions

It can be difficult to identify when an assumption is being made. Whilst the joke of a spherical cow it is clear that not only is that a poor assumption, but it is also highlights that these assumptions may not stand up to the real-world scrutiny. By making it clear before proceeding with the milk production increase project, the scientists stated their assumptions and I assume, the project did not go ahead because of the assumption.

Ways that I have identified when an assumption is being made include:

• Someone says: “I assume…”, “I think they mean…”, “Logically that means…”, “It stands to reason…” and others.
• When there is no source for the “constraint”.
• The stakeholder that this will impact has not provided the statement.
• When the context, and history of the problem is poorly understood.
• When everyone has a different understanding of the problem.
• When a stakeholder is stating a decision on behalf of a non-present stakeholder that are not part of the same group of stakeholders.

Turning an Assumption into a Constraint

It would be dangerous to suggest that you need to validate all assumptions. This would be time consuming, and result in very poor relationships with clients. But it is key to identify where an assumption has been made that will have lasting, enduring or difficult to unwind if the assumption is incorrect.

In the second case study, if that assumption was wrong, or flawed. It would have meant designing and building a solution that was not suitable for our clients. And it was well recognised as being a fundamental assumption. We did real work to validate the assumption to ensure that it was a real constraint.

Ways that we validated included:

• Questionnaires to stakeholders (asking about real-world performance of their data connectivity).
• Spoke to and evaluated several data service providers.
• Reviewed upcoming data connectivity claims for speeds.

We did work to ensure that the assumption really was a constraint that would underpin a hugh number of difficult to unwind decisions.

References

1. Operational amplifier – Wikipedia ↩︎
2. Newtonian fluid – Wikipedia ↩︎
3. Euler’s critical load – Wikipedia ↩︎
4. Spherical cow – Wikipedia ↩︎