Skip to main content

A Surefire Way of Delivering What You Set Out to Deliver In Your Next Project Plan

No amount of detailed planning will guarantee success.

Yes – you read that correctly.

Many project managers tend to think – “I’ve planned the project, worked out when we need to have things done, now just monitor the work and it will all happen.”

No it won’t.

In fact, the only thing you can really guarantee about a plan is that it won’t go to plan.

Related Article: Look Out for “Best Efforts” Projects

I can just hear it now… “Mark – why start with this seemingly contrary aspect of project planning as a way of ensuring I deliver what we set out to deliver?” Simple – it’s to show that you should not spend an undue amount of time getting every little detail right when planning.

In fact, the more detail you attempt to put into a plan, the more likely your project will start to miss targets, start to get behind and generally cause you a lot of angst. So the idea is to find the happy median between too little and too much detail. But how?

What you need is clarity of what it is you want to deliver from the start.

Planning involves the deliberate intent to think about what needs to be done, when, by whom and what dependencies are required before we are part way through – while it is all on paper and much easier to change as we work it out some more.

We must be careful about being too sequential in our thinking when planning. We need to think holistically as we work out to successfully deliver our new project. That is, work from a high level down.

Too many PM’s try to start planning at the perceived start of the project and then attempt to think of everything that needs to be done in sequence.

Don’t do this.

Your projects will suddenly take you months (or even years) longer than expected, you will get bogged down in detail and will likely miss something that needs to be done. And most importantly – never seem to get started. (And likely have a plan that will be off track before you barely get into it).

Work from a broad overall picture then tease out the detail.

Anyone who has done any painting knows this – try painting a portrait from the top of the canvas to the bottom every little detail as you go – and see how good the painting is in the end! (It can be done – but you need to be an outstanding technician, very experienced and very familiar with your subject.)

By working with a broader overall context first and refining things as you plan, you have a far greater advantage over the sequence driven planner – you can stop at whatever level of granularity is appropriate for now – and be confident you have not left out anything even if you are not sure about the detail yet.

To do this, start with the end in mind. In our project world, this means starting with a clear definition of what we want at the end.

The PRINCE2 methodology has a nice way of doing this – with a “Project Product Description” – a brief description of the overall “product” or set of products that you are going to deliver. (PRINCE2 uses the term “Product” instead of “Deliverables” – I will use the terms interchangeably – but understand they mean the same thing – something you can point at in the end).

In reality, this overall vision can be in the form of a concept model of any type – document, drawings, computer presentation/mockups, physical models. The clearer, the better. As long as the key people involved in your project agree what it is.

Next – agree on the definition of “done”. That is, when is the product considered complete?


Step 1 – Have a clear definition of what it is your project will deliver in the end.

Step 2 – Define “done” for each deliverable.

This is the starting point to having a plan that is focused on what the project owner wants while at the same time stopping us from over thinking everything in a sequential manner when we do our planning.

If you are in the software development world and you are using agile software planning – the principle still applies. You start with story “epics” that denote the essential pieces of functionality that make up your new overall product.

Planning for a Product-Driven Project

One of the best ways to achieve the happy medium in terms of detail in your plan is to start with this end-project vision and break it down into the various components or “sub-products” that must be delivered to get us there.

You can (if you want) draw up a dependency diagram of the components of your products; however, a simple indented list does just as well.

Don’t be tempted to get into activities and estimates of time and resource allocations just yet. That comes later. Just the thinking that goes into what we need to deliver overall as interim deliverables towards that overall end product is what is important.

Here are a couple of examples of the type of thing I’m talking about as a simple indented list:

  • Big Expensive Software Product
    • Functional Requirements Document
    • Tender Request Document
    • Budget Plan
    • Business Case
    • Evaluation Criteria
    • Evaluation Team
    • Legal Team
  • New Warehouse
    • Plans
    • Council Submission
    • Budget Plan
    • Road Access Plan
    • etc

Remember everything in the hierarchy is something you can point at later. Products (or deliverables) are things you can see and touch. We normally use nouns to describe them.

By the way, I’m not trying to advocate PRINCE2 in particular (although it has a lot of advantages for the more formal project environment) – however, this is one very nice aspect of that methodology that is useful for many projects. 

Often people say – “but, my project is a doing thing, like – move the office to a new location, purchase a new software package, migrate the data center”.

Yes – these are actions. But these are actually the outcomes we want to achieve – “I want to move my data centre into the cloud” – is an outcome or objective of the project owner.

Certainly finding the appropriate thing / noun from this as your first instruction can require you to flip your thinking – but work with it. It’ll be worth it. The deliverable, in the end, are still things – “outsourced data centre”, “software x”, “new office”.

So start with a clear definition of what it is you want to deliver IN THE END and work holistically – use a “broad brush” approach sketching the overall picture and then work out the lower level components – all things you can see and touch. Have a definition of “done” for each.

Work on detail for the first things you need to do for now.

Such a simple process. It will deliver the results you want.

Happy projects.


Comments (4)