Monday, 25 August 2014 00:00

Planning is Not a Solo Activity

Written by

Planning is something I have a love/hate relationship with. Done properly it is a thing of beauty: The team working together to plot a common path through a thicket of issues. An initially vigorous debate that eventually settles down as objections are countered and agreement is reached. Done badly it’s a dreadful sight. A Project Manager sitting alone at a computer cursing Microsoft Project.

Related concepts

It’s important to clearly distinguish a number of related concepts:

  • Planning is an activity in which the actions to be taken are developed in advance;
  • A Plan is some form of documentation that communicates the result of the planning activity;
  • Microsoft Project is a useful tool for producing some of the components expected in a plan, such as a Gantt[1] chart.

It should be clear from these descriptions that planning must come before a plan, and that entering scheduling information into Microsoft Project does not substitute for having an actual plan.

What’s in a plan?

A plan should include everything you need to communicate how your goals will be achieved. It should not contain unnecessary boilerplate as plans may change regularly and need to be easy to keep up-to-date.
Importantly, not every plan needs the same level of detail nor to cover the same timeframe. The project team requires a plan that goes into detail about the current stage, but can be vague about future stages, so they can coordinate their work. This kind of plan should be updated regularly as the team gains more experience and progress, or lack thereof, becomes apparent.

The project board needs a simple plan that shows a schedule of major milestones and deliverables for the whole project, and a high-level indication of how these will be achieved with the available resources. This kind of plan should be light on detail – because the detail isn’t generally known yet – and should only be updated at the end of a stage or in response to an exception.

A classic PM mistake is to try to have both these levels of plan combined together into a single document – or worse into a single schedule in Microsoft Project. The problem with this is that the project team is never allowed to change “the plan” because the PM fears the project board will think that “the plan” has changed.

It hasn’t of course, because in reality there are different plans with different purposes, and at different levels of granularity. But now the PM is stuck, and planning, if it occurs at all, is now off the record.

Who does the planning on your project?

On many projects it is assumed that the Project Manager does all the planning. This is a grave error[2]. The people who should be planning the work are the ones who will perform it. There are at least there reasons for this:

  1. Even a Project Manager with extensive experience of all the tasks to be performed is unlikely to be able to estimate accurately without knowledge of the capabilities of everyone else on the team[3];
  2. A team member who was not involved in planning her work cannot reasonably be held to a plan devised by someone else. Buy-in to the plan requires participation in creating it;
  3. Except in the simplest case, a plan is not a list of independent tasks, and therefore everyone involved must plan together to identify dependencies and gaps.

The Project Manager owns the plan, and should ensure that the results of planning are captured, documented, and can be used to monitor progress. But planning itself is a team activity. Get everyone in a room and work through what needs to be done together. Drill down until the key tasks are clear to everyone. Question assumptions. Repeat.

Plan well and prosper

Planning is not a solo activity. If you join a project and are given a detailed plan (or more likely a schedule) with your name next to various activities, ask when the next team planning session is.

Don't forget to leave your comments below.

References
[1] http://en.wikipedia.org/wiki/Gantt_chart
[2] In mature industries this may not be the case, but IT is not a mature industry. If you don’t believe me ask yourself what other industry accepts a 60-70% failure rate for projects.
http://www.zdnet.com/blog/projectfailures/study-68-percent-of-it-projects-fail/1175
http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf
[3] In some organisations the same team works together repeatedly on similar projects. In which case the project manager may be justified in doing all the planning. This is the exception.

Read 8119 times
Duncan Watts

One of Redvespa’s true characters, Duncan joined us in 2008 when he emigrated from the UK. A proud Welshman, Duncan came to New Zealand with his Kiwi wife and has immersed himself right into Kiwi culture – a process assisted by his passion for rugby and steak and cheese pies. Duncan’s personality makes him an engaging BA. He is able to sit down with people, draw out their requirements and gather the information needed to enable success. And throw in a bit of humour while he’s at it to make the whole process more fun!

© BA Times.com 2019

macgregor logo white web