Document assumptions

In any project, there are things you don’t know. It is impractical to wait until everything is a known fact before work on the project starts. In order to start work, it is necessary to form some assumptions – statements about what you believe to be the case – to create a position from which to begin. These will be proved or disproved as you work on the project.

W O R K I N G I N T H E D A R K

‘One killer in terms of scope and budget for projects can be assumptions,’

says Neville Turbit, a convenor of the Australian Computer Society Project Management group and principal of the project management software and consultancy firm, Project Perfect.

He spent some time working with an Australian government department to help them implement a project-management methodology, which included handling assumptions in a pragmatic and practical way. Teams often find themselves in the dark at the beginning of a project, which means assump­

tions form a necessary part of the foundations of the requirements and plans.

‘I talk to my teams about travelling down a tunnel with only a flashlight. We can see clearly what is immediately in front of us, but only some of what is down the tunnel,’ Turbit says. ‘We know there is more down the tunnel than we can see. We just don’t know what it is. That’s the way it is with scope. We know there is more scope than we can see. We just don’t know what it is until we get further down the project tunnel.’

It is the same with assumptions about budget and time. ‘At first I started trying to get them to add a contingency to the budget. And I tried to get them to leave a hole in the Gantt chart for the unforeseen. There was so much resistance to unallocated resources that this proved almost impossible. The line management way of thinking does not fit with a project environment and its so many unknowns.’

The government department learnt to handle assumptions as ongoing open issues, with actions required to validate them. Turbit gives an example:

‘If we make an assumption that we will not have a distributed database, then the project team immediately creates an action to validate the fact that it will not be a distributed database. The action is assigned to a person, and given a date for completion. That action is then monitored by the project manager.’

This means that assumptions don’t stay assumptions for very long. Either the result of the investigation is that the assumption is true and it becomes a known fact, which aids the further development of the project. Or it is false.

‘If it proves an incorrect assumption,’ Turbit says, ‘we call a meeting to look at its impact and what other actions may be required to compensate. Too often in projects I have seen assumptions documented and forgotten,’ he says.

Document assumptions

D E F I N I T I O N

Assumptions can be:

• things that you are taking for granted will stay the same;

• things you have to assume because you don’t yet know for sure.

In the first case, it is worth documenting these assumptions in your project initiation document, even if everyone accepts that is the way things are. Just because something is like that now does not mean it will stay that way. The way organizations work changes more often than a project manager can keep track of: a change in an area where you least expect it can, and will, interrupt your plans. Examples of this type of assumption are:

• Payment for contractors will stay at £900 per day.

• The marketing department will make resources available for testing.

• The October 2006 IT security standards will be used to develop the application.

If payment rates change, marketing cannot provide testers or the security standards are updated, you suddenly face a very different project – one that you probably will not have the budget or time to complete. You will still be the project manager and be expected to deliver but, having documented the assumptions, it will be easier to explain to your sponsor why you now need more money, time or people. The sponsor originally agreed to a project in a certain environment: now that has changed, with all the relevant knock-on impacts to the project budget, scope and timescale.

The second type of assumption will allow you to plan more accurately.

You might not yet know the number of staff that will need to be trained on the new accounting system, but you can assume it will be half the finance department, say 35 people. Having stated and documented this, you can decide that they will be trained in two groups and book those dates, plan the costs for the trainer, hire the room and so on. Planning based on assumptions almost always results in a potential issue, so add an issue to your log: ‘Number of delegates to be trained still undefined.’ Allocate an owner to the issue and make them responsible for validating the number of staff that need to go through the training. Once you have a concrete answer, you can replan as appropriate.

W A R N I N G

A word of warning: use assumptions with care! It is always better to have the full picture and work with concrete facts.

Making assumptions such as ‘I will have a budget of £500,000 to set up the company football team’ will not help you manage

Project Management in the Real World

the project at all. The fewer assumptions you have, the more likely it is your project will avoid surprises later on and the more realistic your plan will be.

G O L D E N R U L E S

Document all project assumptions in the project initiation document. Document and monitor the associated issues and update your plan when you have validated each assumption.