“Assumptions are for lazy architects”

This is one of my favourite quotes in tech consulting. Said by an ex Royal Australian Airforce fighter pilot now tech consulting executive.

An assumption, is, yes, something one assumes. But what is something one assumes? It’s something you don’t know, but going to guess for now.

Assumptions are for lazy architects, the next time I hear someone say “put it as an assumption” to something that could be answered with a quick phone call, I’ll… I’ll… I’ll politely ask them to call.

This is against what is common in the consulting and solution architecture world. Load contracts and solutions up with a ton of assumptions. It’s our get out of jail free card. The plane crashed sure, but you can’t sue us, because we put it right there in the contract, right there, we assumed we had enough fuel.

“I assume the door is locked” whilst I sit in my bed, nervous, is a lazy habit. Lazy. What about the radical idea of checking if the door is actually unlocked? Or to put it as the responsibility of the security guard. Not ‘we assume the security guard will lock the door’, instead ‘it is the responsibility of the security guard to lock the door’.

Now, this is where this post gets awkward, I’m actually a big fan of assumptions. Huge fan. Huge. At the start of figuring out a solution to a problem, not the end. So at the start you have a ton of assumptions and you come up with a possible solution approach, a solution concept as I call it. I absolutely 100% know that it’s incorrect and it’ll change, but I also know that by guessing/assuming, and documenting them, I’m able to formulate/synthesise/extrapolate/construct/hypothesise/meganotise to 90% complete. Meganotise is not a word by the way, next time speak up when you hear something that sounds garbage.

The reason why it makes sense at the start is that we discover a ton of insight just through building our way through a problem. Call it bias toward action. Instead of starting a solution, then finding something we don’t know, stopping and waiting for the next design governance forum (or other form of ceremony involving a dozen people to answer a question they are only involved with for an hour a week), we take a guess, and keep going. But we document the guess and try find the answer. It’s my common advice, take a guess and keep going.

So, by the time we get to the point of building our house, we won’t assume that the wolf can’t blow it down, we would’ve tested a few different materials and built our house out of bricks. However, we do assume that the wolf will not acquire a bulldozer licence in the near future. That’s an ok assumption. Seems reasonable. Assuming that straw will withstand the wolf is not an ok assumption if we could’ve tested it.

“But what about things we need?” These aren’t assumptions, these are dependencies… “We assume the concrete will be set by the 12 of August”. Is this an assumption or is this a dependency? If it’s a dependency label it as that. “We are dependent on the concrete being set by the 12th of August”. Dependencies aren’t things you hope for, they are things you ensure all parties are aware of and take action on. They are usually things out of our control, but that we need to execute our plan.

On most projects assumptions are impossible to avoid, but I think that 95% are avoidable. They can either be moved from something we assume to something we know through a little bit of effort, or they can be moved to a dependency. Where they remain assumptions, what have you done to minimise how much you are assuming? Here are some examples.

• OLD: Assuming the client will acquire all appropriate hardware by start date
  NEW: Project start date depends on acquiring all appropriate hardware by start date
• OLD: We assume a configuration only implementation
  NEW: We have validated a configuration only proof of concept with the pilot group and this forms basis of the estimates
• OLD: Assuming client will not need more than 1000 fields
  NEW: Projected field count is 325 based on x,y,z specifications. Any additional fields will be assessed as phase 2.
• OLD: Assuming users will be trained by the change team
  NEW: Users are dependent on training given by change team
• OLD: We assume the exchange rate will remain stable
  NEW: We assume, based on forecasts by x,y,z, that the exchange rate will remain stable until FY2021, the end date of the project

Assume early, assume liberally, but validate constantly.