Zombie – /ˈzɒmbi/ (noun):- (in popular fiction): a person or reanimated corpse that has been turned into a creature capable of movement but not of rational thought, which feeds on human flesh.

It’s not only people who can become zombies; it’s projects too. Have you ever encountered a project – or proposed project – that refuses to die? You’ve chopped off its limbs and buried it, but it still manages to resurrect itself. Even when you think it’s gone, it pops up at your next project board, maybe in a slightly different guise, taking up time and distracting from more important activities.

Maybe it is a project that has been around for years, feeding on money and resources, but never delivering anything. Or it might be a project idea that has struggled to get support but gets continually re-presented. We shall refer to these as “zombies”. It might be worth thinking about one of your own “zombies” as you read this.

It is very tempting to take a zombie on head-on, as you probably feel that you have logic and right on your side, but we respectfully suggest a more measured approach. Our starting point is that direct attempts to kill the zombie thus far, whether by you or others, have been unsuccessful (otherwise it wouldn’t still be around).

The first things to consider are:

• Why does it exist? At one point, it may have been a great idea. Maybe it had benefits for a particular department, or it made sense when the business had a different structure or products. Perhaps it had a particularly vocal senior supporter.
• Why won’t it die? It still has enough supporters – either because they believe in it or because they have already invested so much time and energy. Or it might actually just be a good project.

If you have come to that conclusion that the zombie must die, then there should be sensible reasons for that – it is not aligned to current strategy, it has been superseded by other projects or events, or it will never deliver enough benefit to be prioritised. Sometimes, there are just so many things happening that you need to clear away any distractions so you can see the wood for the trees.

Then comes the difficult bit; actually killing it once and for all. Have we ever managed to kill a zombie project? Yes, using both analysis and sensitivity. If you are telling someone, or a group, that their project will never be delivered, won’t generate the benefits they had hoped for, or is no longer relevant in the company/environment, then you are more likely to get their support if you can offer them an alternative, such as:

• Including part of their requirements in a different project
• Asking them to support other projects beneficial for their department or area of interest
• Involving their team in other, relevant projects

While you are delivering an unwanted message to one person, it is often the case that they are representing a team, department or business area for which the project is a high priority (even if it is a low priority in the big scheme of things) and that is the message that they have to deliver. We believe that you can never lose sight of that impact.

Linked to this is timing. The opportunities for killing off zombie projects, or at least doing a critical review, are often after an agreed threshold has been reached, e.g. a project has been on the list for 2 years but never started; when you take on a new project, programme or department and have the opportunity to do a full review of everything, or; a large, company-wide project is about to take place, e.g. core system replacement, so all resources should be focused on that.

Last, but not least, what prevents resurrection? If it is an active project, it should be formally closed down; if it is a project proposal, it should be formally rejected by the appropriate committee. Keeping a log of closed/rejected projects with a detailed explanation of the rationale makes it easier to identify it if it resurfaces, particularly for a new project manager who might not know the history.

Killing a zombie is not easy so, if you can, stop them being created in the first place.

navigation – navɪˈɡeɪʃ(ə)n/  (noun) – the process or activity of accurately ascertaining one’s position and planning and following a route.

One of the hardest parts – perhaps the hardest part – of project management is navigation. Continuous navigation. The project manager is constantly assessing the position and navigating the project through an ever-changing landscape of priorities, deliverables, corporate restructures, stakeholder divergence, and morale black-spots. Any respite is short-lived and quickly forgotten when the next storm hits. The route changes regularly as the landscape changes and, often, the planning process is only able to go a few steps ahead with any kind of accuracy.

The challenge for the project manager is to understand and track all of these moving parts, continually modify the route, keep stakeholders up to date, take everyone with them on the journey, and to do it both calmly and with pace. If you thought that the project manager simply writes a plan at the beginning and then tracks it, you would be wrong. If you recognise that project managers are constantly bombarded with new information and have to immediately assess and assimilate, you would be right. It should come as no surprise when, in a project with hundreds or thousands of moving parts, the project manager cannot immediately articulate every impact of the information they only found out 3 minutes ago.

While it is important to recognise the nature of the environments we operate in, it is more important to develop ways of operating successfully within them. A good project manager can navigate successfully given sufficient time to do it, but the luxury of time is rarely afforded. Navigating within the time available, and with the responsiveness expected, is what matters.

Intellectual flexibility is important – you need to juggle a lot of things in your head and be comfortable with constant change – but the ability, and bravery, to take intellectual shortcuts is more important. To stop you running aground use these 6 tips to steer towards calmer seas:

1. Looking ahead. Work out how far ahead you can see. Sometimes you can see to the end of the project, sometimes only a few weeks or months ahead. Knowing how far you can see determines how you approach planning, team management, governance, and everything else.
2. Recognising pitfalls. You cannot critically assess everything in the landscape so you need to prioritise. You are unlikely to trip over a blade of grass but a large boulder may fall on you. Work out what to spend your time on.
3. Knowing your toolkit. Every project manager should have a toolkit of methodologies, processes, templates, techniques, etc. The more tools you have, the quicker you can select the right one, and the better you are at using them, the faster you can operate. Even the simplest job, like finding the right template, can waste an hour if you don’t have it to hand.
4. Delegating. If you take everything on yourself then you will quickly be bogged down. Being an effective delegator can save you hours every week.
5. Using experience. If you have done something before, or someone you trust has, use that knowledge. That can be anything from “here is a plan I prepared earlier” to “the last 3 times I have run identical projects, this activity has taken 40-45 days”. Don’t go back to first principles when you already have a reasonable estimate.
6. Communicating. Navigating depends on information. The project manager must be constantly gathering and sharing information. And everyone on the project should be keeping the project manager up to date.

There is no silver bullet for successful project navigation. Sometimes you receive emails faster than you can read them, your phone doesn’t stop ringing, you spend 8 hours a day in meetings, and there is a seemingly endless merry-go-around of status reports. This is when navigation – and everything that it takes to do it well – is most important.

Lots of people will tell you that project management is just common sense, including project managers. You can find articles, books and methodologies devoted to the idea that it is. And at the beginning of a recent seminar 80% of our audience, mainly project professionals, agreed with that.

We are not so sure.

If we take a standard definition of common sense – “the ability to perceive, understand and judge things that are common to nearly all people and can reasonably be expected of nearly all people without need for debate” – then we can apply that to our own project experiences.

While much of project management theory, for good reason, is about creating a commonality (a “common sense”) across the project, the reality is that this is incredibly difficult to do in a moving corporate environment with changing scope, timelines, priorities, and personnel. That lack of commonality can apply to both what the project is trying to achieve (the objectives or deliverables) and how it is trying to achieve it (the methodology).

While there are positive trends within the research on the effectiveness on project delivery, studies in the past 12 months continue to show that less than one-third of projects deliver on time, on budget or with alignment to the organisational strategy. If everyone was truly on the same page wouldn’t we expect a much higher project success rate?

So, here is our view.

Project management is often seen as common sense because, to us project folk, it is common sense and we often frame it in that context. At the same time, the concepts of project management are very easy to grasp and can seem obvious. Perhaps, when we talk about project management being common sense, we are talking about the concepts rather than the practicalities of implementation.

When we draw that distinction between the concepts – scope, planning, dependencies, risk management – and the practicalities – managing people, corporate navigation, priority juggling, creating momentum, stakeholder coordination – then project management feels less like common sense. The skills, experience and ability to deal with these day to day challenges are, in our opinion, not common.

Why do we care?

It is, as we said above, for good reason that a lot of project management is about creating commonality. The ability to create that commonality is a key factor is making projects successful. When we talk about change management, engagement, and communications this is one of the key things that we are trying to achieve.

And it is much harder to achieve if the starting position is “this is just common sense”. That statement comes with implicit assumptions about how much people know, how much time needs to be put in to creating the commonality, and the skills and experience needed to do it. If our starting point is that we are doing something that is either not common or not common to everyone involved then, in theory, we should be giving more thought to how we make it common and increase the chances of the project being successful.

Our conclusion is that, overall, project management is not common sense and, particularly at the beginning of a project, it is highly unlikely that what needs to be done is common sense to everyone involved. By the end of the seminar 80% of the audience agreed.

In the next part, we’ll give you our top tips on how to create common sense on your project.