seen a number of common patterns over the years in relation to assumptions.
Sometimes using assumptions can be useful, you can proceed with an initiative and begin to make progress and
check in on points as they are discovered, since we can’t know everything up
front. Other times, assumptions can be downright dangerous and many of those
times it’s because we haven’t realised that they are assumptions that need to
be validated or invalidated. By validating assumptions, we have a solid
information on which to base decisions – without such a foundation our initiatives
are destined to crumble and fall.
of the common patterns I’ve seen is the use of a “Business Requirements Document”.
This kind of pattern has other manifestations, but essentially it comes at the
outset of the imitative and the underlying assumption is that all this work
will achieve the outcome. Often there is a lot of complexity in the underlying
initiative and it’s too hard to predict exactly what will occur. Indeed, perhaps
this is a good general rule – there’s no way to predict with absolute certainty
exactly how your customers / users will react to a change. Thus, our path becomes
set with a series of assumptions.
I’d rather see the word “Requirements” replaced with assumptions that will need to be validated somewhere along the lifecycle. Which leads me to my next point – the lifecycle or the knowledge discovery steps don’t take into account validating those assumptions in the real world. Often, I see Kanban boards like this:
When really, if the team were to add an additional knowledge discovery step along the lines of the following, the team would be prompted that they’re working with assumptions and they have to think about how they’re going to validate them:
What often results is that people focus on purely “getting stuff done” rather than ensuring “someone’s need was fulfilled” (I like this “Definition of Done” from Mike Burrows) – and by that, I mean we know through validation that the need was actually fulfilled. That’s being fit for your customers purpose. That’s really what we need to be focusing on.
what results is that either we don’t validate that we’ve solved the problem and
move on to the next shiny thing, or we have to go back for one or more swings
at it. If you’ve got stakeholders that are counting on your promises that you’ll
solve their problem the first-time round, then you’ve got a fairly serious
stakeholder management issue. Also, what was the opportunity cost of learning
this so late? What could we have been doing with the time and money that we’ve
spent to invalidate this assumption?
it be simpler to plan this from the start? In areas of uncertainty and
complexity, we really shouldn’t be blind to our assumptions, rather we should
be acknowledging we don’t know everything, but we plan to learn as soon as
possible. Even if we’re using leading indicators to show we’re heading in the
wrong direction this can be better than relying on the assumption to hold.
Don’t be blind to assumptions, they can be useful when they need to be, but often they are not catered for in many systems of work. It’s not a difficult thing to add the validate step to a board, but changing the behaviours to ensure you really are meeting that customer / user need can take more time. If you’re not validating your assumptions, you’re likely falling behind your competitors who are.
RETURN TO BLOG