There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don’t know we don’t know.

Sound familiar? It was said by Donald Rumsfeld back in February 2002, in a quote that has now become famous in its impenetrability. So how can you apply this to your skillset and become a Project Manager “In The Know?”

But he wasn’t the first to use it. If you have ever studied cognitive psychology – or attended a personal development course – you may have come across the Johari window which is the same principle. And for the project manager, it makes a lot of sense.

Let’s put aside the things we know. They are tasks, people, requirements – all things we are aware of and in control of, to a lesser or greater degree. Let’s also put aside things we don’t know that we don’t know. We have no appreciation of that piece of the puzzle, so we can’t do anything to influence it. Instead, let’s concentrate on the things we know that we don’t know.

In any project there are things you don’t know. It’s not practical 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.

So what is an assumption? 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.

Even if you think things will stay the same it is worth documenting these assumptions in your project initiation document. Just because something is like that now does not mean it will stay that way, especially on projects that will run over a year or longer. This particularly applies to the financial elements of your project, as moving into a different financial year can mean that different tax rates apply, equipment prices go up or people cost more. 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 sales department will make resources available for testing.
• The January 2009 IT security standards will be used to develop the application.

If contractor day rates change, the sales team cannot provide testers or the security standards are updated, you suddenly face a very different project – one which 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. They 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 is when you have basically guessed at how something will turn out. The idea behind these assumptions is that they will help you plan. You can’t plan at all if you don’t know what task you are trying to complete. For example, you might not know for certain that the IT system you are upgrading needs to be done at the weekend. You might be able to do it during the week, but it’s likely that in order to avoid disruption to the users during their main hours of work that you will complete the upgrade at the weekend. That’s an assumption, and it comes with another one too: you can assume that staff will be available to work that weekend.

In reality, unless you have a very flexible workforce, no one is likely to want to work at the weekends. But by documenting your assumption you can start to assess the impact: will you pay people overtime? Do you need to factor in extra expenses if people need to be away from home? How will you get updates from your team over the weekend? These questions all help you to plan how that task will be completed. If you then find that you can upgrade the system in ten minutes one evening during the week, then that’s great news. But you have an alternative plan in place just in case.

Planning based on assumptions almost always results in a potential issue, so add an issue to your log: ‘Upgrade schedule still undefined.’ Allocate an owner to the issue and make him or her responsible for producing the schedule. Once you have a concrete answer, you can replan as appropriate.

Finally, don’t over-use assumptions. It is always better to have the full picture and work with facts. 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. OK all you PM’s out there – now you “know.”