Early in my career I had an experience in managing assumptions that has stuck with me. Many years ago, as a young computer programmer, I complained to my team leader that I didn’t have enough information to design a change in an application I had been asked to write.

I was told by the my team leader to proceed with my design, complete it by the milestone date, and to document all my assumptions.

All of which I proceeded to do. It was frustrating because many of the assumptions I was documenting seemed to be nit-picking and simple enough to solve issues if I only knew who to talk to.

The problem was, when I presented my completed design to the customer he didn’t read anymore than the first few pages - the rest of the document was ‘too technical’ (it wasn't really - but that’s another article). When he got to the list of assumptions that had allowed me to complete the design on time and said:

‘I see these assumptions. I’m not sure they are valid. What is your assumption validation plan?’

I hated that phase when I first heard it. 'What is your assumption validation plan?' To me, creating the list of assumptions was already more time than I wanted to spend on these issues. I was a programmer, so I was wondering - like many new programmers do - why I had to do all of this documenting when I should be coding.

Step forward 15 years or so and I no longer wonder why we need to do all of this documenting when we should be coding. But this problem wasn't solved by changing developers, it was solved by specialisation. The IT industry has matured to the point where most organisations try to have separate designers, business analysts, project managers, architects, etc so programmers can get on with the business of coding - and so that the quality of the documentation is improved through specialisation.

But for all the change in the IT industry many things in management remain the same. I now understand the question ‘What is your assumption validation plan?’ to be one of the most insightful questions in general management.

The question 'What is your assumption validation plan?' recognises that assumptions themselves have a life-cycle and that they must be managed. It also recognises a more important point that assumptions have a history! It is a question that skips over the dubious discussion about why somebody took the time to raise this assumption, and proceeds directly to what we are going to do about it now.

Asking this question stops assumptions being used as a ‘out’ from having to deal with an issue. An assumption validation plan is more work - work that still needs to be done - and perhaps even work that could have been avoided if the assumption hadn’t been made.

Making assumptions simply allows work to proceed now by defering other work (and possible re-work) to later. It's a useful tool. But only if you remember you have defered work and manage that future effort.

But the management profession being what it is, when it comes to the crunch and somebody complains that they don’t have enough information to proceed I still often hear ‘Proceed with your design, complete it by the milestone date, and document all of your assumptions…’

In fact, I think I hear this even more often. But I almost never hear 'What is your assumption validation plan?' or 'This is our assumption validation plan'. And it’s not just programmers. It seems project managers, designers, business analysts, and architects are getting the same advice - 'Proceed with your work - and document all your assumptions...'

Somewhere in the world, there is a bunch of work building up that nobody is managing!

The lesson I learnt from that early experience was to not make assumptions. I don’t mean not to state my assumptions - I mean not to make assumptions in the first place. My approach is to either find the upstream deliverable that needs to be developed or updated so the assumption doesn’t need to be made.

Also, all documents I produce that might otherwise contains ‘assumptions’ instead contain clearly identified sections for issues and decisions that need to be managed. By the time the document is completed these issues are resolved, the decisions are made, or the decisions are with the very people who the document is being delivered to.

Over the years I’ve come to realise that the ‘assumptions’ shtick, like many concepts that start out as good management practice, has been co-opted by managers to serve nothing more than the managers own interests. As always, with managers under time pressures, impossible demands, and gaps in knowledge - just like the rest of us - they are forced to utilise management words to protect their own interests.

The Life-Cycle of an Assumption In this case the life-cycle of an assumption is mapped on top of the software development process. This makes the impacts of an assumption made in the intial stages of a software development project clear. However, the life-cycle of an assumption remains the same whatever the situation. Click image to enlarge.

In software development, for example, assumptions made or approved by project managers can only be ‘validated’ in a handful of ways:

• If the assumption is made in a detailed design, the high-level design should probably be refined so that the assumption doesn’t need to be made

• If the assumption can be resolved before finalising design - by speaking to somebody - then this should be done sooner rather than later

• If the assumption might cause an issue when the system goes live - but can’t be validated through analysis or asking the right people - the assumption validation may be deferred to the testing phase. However, effort for this should be included in the plan. In particular, testing without an expected results can be time consuming and from a test manager's perspective is an ‘experiment’ rather than a test. Also, you’ll need a mechanism to remind you to include the assumption validation in the testing phase (which may be many months in the future at the time the assumption is made).

• If the assumption validation plan doesn't exist, and the assumptions could impact the production environment, then the default assumption validation plan is to wait and see. Essentially this is a ‘risk’ and should be shown as such. In this case an assumption becomes a risk.

In the case where the assumption becomes a risk the work still doesn’t stop. Risks need to be managed, so it’s possible you will still decide that it would have been easier not to make the assumption in the first place.

The question is - if this is the life-cycle of an assumption, why aren’t assumption validation plans the norm?

ManageWithoutThem contends that this is because assumptions provide an ‘out’ for managers. While they are intended to allow work to continue without being blocked, they have been co-opted as a way of saving managers from managing.