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.”

Everyone has their own tricks to ensure their projects stay on track. Like high school students sitting exams, we all have our equivalent of lucky underwear. In fact, if you start looking for advice on what makes projects successful, you’ll find it by the bucket load. Ideas will flow your way until you have so much that you could easily spend all your time doing the things that prevent project failure, and not doing the things that get your project done. So how do you choose what actually works?

One of the advantages of meeting people through facilitating seminars is that I get to talk to experts in their fields. Put 40 project managers in a room and you’ll end up with some strong opinions, but at least you’ll know that they are speaking from experience. Their techniques work.

So standing in front of a group of delegates recently, I asked them what they do to make their projects a success. We came up with 27 different things to do to improve the chances of a project not failing from the simple (“test”) to the obscure (“GOBIGL”). Several themes were evident, and as we grouped the responses on a flip chart the top three tips for project success became clear.

1. Manage your stakeholders
Work out who your key stakeholders are – the list is likely to be much longer than your first expect. Involve the project team in identifying different internal and external stakeholder groups as by yourself you’ll never think of everyone. Then prioritise: who from that list needs to be involved in the project? Establish a governance framework of key stakeholders with regular meetings. You’ll probably end up with several different groups: your project steering group, of course, but also others. How about holding a user forum? What group of people need to see your weekly progress report?

Absolute support from key management stakeholders and your project sponsor is the number one thing for project success. After all, if your sponsor isn’t interested in the end result, why are you bothering?

2. Manage your risks
First things first: you can’t manage risks unless you work out what those risks are. Spend some time upfront with your project team identifying all the things that could go wrong. Then put some action plans in place straight away to mitigate against them.

Risk management is not just a one-off exercise. You should do monthly risk review meetings, but don’t feel that the project team have to wait until that session before they raise a risk with you for the log: they can (and should) be sending you details of impending risks as soon as they become aware of them themselves.

3. Expect and manage change
What you set out to do at the beginning of a project will not be what you deliver at the end. Period. Unfortunately life doesn’t stand still, and neither does business. The requirements and scope may change as the business evolves over the lifecycle of the project or as your end customer develops a better appreciation of what they have asked for.

If you expect change to happen you will be better at handling it when it comes along. What is your change control process? How are revisions to scope or plan going to be handled? Early on, identify how you will get stakeholders to approve all changes. Then when the inevitable happens, your change management procedure can swing into action creating the least disruption to the project possible.

There is no secret formula for project success: if there was, the statistics about project failure wouldn’t be so disheartening and project managers salaries would be several times what they are today. Many things conspire to make projects fail, but getting the basics right and following the tips above will go a long way to making sure your project isn’t one of those.

Oh, and if anyone was wondering about GOBIGL, it stands for get out before it goes live!