Making Assumptions on Projects Is a Ticking Time Bomb
Assumptions are a fact of life. Without making assumptions, it’s unlikely that many decisions would get made, and certainly fewer projects would ever get launched.
However, sometimes assumptions come back to haunt us as the UK’s Royal Navy recently experienced. The Navy reportedly made a decision to scrap an order for jump jets, which it subsequently overturned.
The UK’s Public Accounts Committee has scrutinized the original decision and described it as being made based on “immature data and flawed assumptions.” The reported cost of this U-turn is £74 million ($113 million USD)—quite a blow to the taxpayers’ pockets.
If assumptions are a reality of life, how should we handle them when working on projects? And how can we avoid getting tripped up by them later in the project? The nature of an assumption is that if it’s correct, we almost certainly won’t have a problem. It is only the incorrect assumptions that will come back to haunt us. It’s therefore extremely important that assumptions are actively managed and regularly revisited.
The first step to conquering assumptions is to identify them and then question and challenge them to make sure they are valid. It’s particularly important to challenge assumptions that appear to be the product of wishful thinking. I’m sure we’ve all found situations where a stakeholder or sponsor falls in love with a pet project and will do anything to keep it going.
It is these projects where a business analyst can add significant value by acting as a critical friend and challenging with rapport. As the example above illustrates, assumptions that are flawed can lead to expensive and embarrassing situations, situations that most business stakeholders would like to avoid. Liz Strauss outlines five tools for finding faulty assumptions, and it’s well worth considering these points whenever an assumption emerges.
It’s also important to make assumptions explicit and visible and to identify an owner for them. Hopefully a project manager will be on hand to undertake this activity, but we might not always be afforded this luxury. If no project manager is present, a simple log can be maintained. It is valuable to log other things too, particularly constraints, assumptions, risks, issues, dependencies, and decisions.
Additionally, it’s vital that assumptions aren’t left to fester—they should be revisited regularly by the owner to make sure they are still valid. In addition to keeping a central log, it is also worth explicitly stating any relevant assumptions up-front in any terms of reference that you write for your analysis work and also explicitly stating them within requirement specifications.
When dealing with assumptions, remember to make them explicit and aim for openness and transparency.
