Why plans go wrong – and how to fix them

It has been quite a while since I was last given a project or programme to run from scratch from day one. These days I tend to be brought in to fix problems. As a result I see many broken plans and often have to advise on how to fix them.

Virtually every plan I see is a typical task based plan with a work break down structure. Some are reasonably well maintained with actual effort or percentage complete maintained. Others were clearly created at the start of a project and then not really used to control the project at all. They are nearly always Microsoft Project or Excel based and comprise a list of tasks. Some (but not many) may have risks or issues associated with some tasks or milestones but otherwise there is little other written documentation about the plan.

The core problems for most of the plans I see are:

The plan doesn’t include all the activities (and information about those activities) required to deliver the project and;

Not enough time is allowed in the plan to do all the activities

How does this situation occur and what can you do to prevent it happening to you?

When given something to do, most people’s inclination is to get on and do it. That’s why so many projects (especially small ones) start without a plan at all. Even where the project manager does create a plan the inclination is to not want to spend too much time on it because it’s important to deliver stuff. In fact, many projects spend less time than they should on Initiation and Planning. But it is a false economy because you can end up going down so many blind alleys wasting time and effort for no reward.

Project managers are also often overly optimistic, either by nature or because their business colleagues pressure them to be. Great, but can you deliver it 3 or 6 months earlier is a mantra I often hear from the business.

How to mitigate the problems.

The first requirement of the project if you are to avoid these problems is discipline. You know you shouldn’t go headlong in to delivery or agree to unproven and unrealistic dates. So have the discipline to follow best practice, use the tools and techniques at your disposal, and learn how to say no – constructively. That means having good reasons for saying no, and pragmatic alternatives to offer rather than a petulant straight refusal.

What best practice tools and techniques am I referring to? Only two:

Asking the project managers most important question – why? and;

Product based planning

Using these two in tandem you can resolve most project planning problems. Ask yourself or your business why are we doing this project? You need to know what the project is supposed to deliver. What is the end result, or product expected to be? Don’t allow yourself to get distracted by when, just focus on the what, the reason why you are doing the project.

Then you need to describe that end result or product. In doing so you’ll identify components or sub-products. Each of these should be described in a product specification. This should include the quality and acceptance criteria for the product. Keep breaking it down until you get to components or products you can buy in to specification or that you can make. It might be a computer server if you are implementing a new system, or a bathroom suite if you were building a house.

In doing this you have created a product breakdown structure. You’ve defined a hierarchy of all the products your need to produce to deliver your project. Now you can identify all of the tasks needed to create each product. And because you have created product specifications with acceptance criteria, you know when each product has been built to the right quality.

Using this product based planning approach you have ensured you know all the activities required to deliver the project, solving the first of our problems. With that information you have a fighting chance of estimating the total effort required to deliver the project. You can build in a level of contingency consistent with the level of understanding of how much effort is required for each task. With that you can complete your left to right plan. From your product breakdown structure you will understand any dependencies to factor in to the plan. You can also look at reducing the overall timeline but undertaking some tasks in parallel whilst fully understanding the risks that might introduce.

Because you have this detailed understanding of everything that needs to be completed to deliver the project you have all the ammunition you need to argue the case for sufficient time and resources to do the job to the required level of quality. If challenged to deliver earlier you can demonstrate the risks that will result. If pushed to cut corners you can immediately identify the quality criteria that won’t be met.

Product based planning is a cornerstone of the Prince2 project management methodology. Yet it is probably the least used part of it, possibly because it forces project managers and project teams to think through the project in greater detail. But as I’ve described above, it can provide you with the best foundation for your project’s success.