It is “obvious” what makes a good plan:
- Ensure that you’ve got everything in the plan
- Break things down to a “sensible” level
- Everyone understands and agrees with the plan
- The plan is used and updated.
In practice I have found that these obvious things very considerably across projects and project managers so I suggest some simple to apply ‘rules’ to help achieve the obvious.
Ensure the plan contains everything
This breaks down into two questions:
Have you covered the entire scope of the project.
Use a Work Breakdown or Product Breakdown structure (WBS or PBS) to initially break the project into the required deliverables and/or outcomes. There are also some simple questions to ask yourself:
- When you have completed every line in the plan is the project complete?
- Don’t have any implied activity (“everyone knows that”… “it’s obvious that…” “of course when doing X you also need to be doing A, B, C”). Make these items explicit and trackable.
- Define all dependencies and make sure that both the supplier and customer of the “thing” agree what that “thing” will actually be when it turns up.
Obviously the breakdown structure will help to answer these questions but it can also help to structure the plan – if it made sense to break the project down in that way it probably also provides an excellent outline structure for the plan.
Have you captured all the activities to deliver all the “things”?
A simple rule is that all tasks in the plan need to have a verb. This sounds overly simplistic however it helps to break a “thing” down into the activities required to deliver it and helps structure the plan into deliverables and tasks.
When building a plan it is easy to focus on your own activities, thus “how long to produce this specification?” could be answered “about a few days but allow a week”. This would result in 1 week being build into the plan. Using the “must contain a verb” rule might allow you to change the outcome: “OK so that is Write Specification, is there a review step?” and hence identify that there is actually an additional review which normally takes a week followed by modifications and sign off which take another week. So the original plan would have been out by 2 weeks!
Some things are better tracked off the plan. This seems to run counter to the above point however if you have ‘off plan’ trackers then make sure that there is a task on the plan for that work which is directly driven by the tracker. An example might be a plan which requires 30 Standard Operating Procedures or Work Instructions to be updated. The plan could contain 30 Write/Review/Modify/sign off task chains but we know that the order in which these will be dealt with will be very flexible. As such it is better to track these in a spreadsheet shared between the team however in the plan there is a single task “update work instructions” with the start/finish date driven by the tracker as is %complete.
Break things down
The use of the Verb rule above helps with this but you also need to be concerned with the length of tasks. Having long duration items makes it harder to give accurate % complete statements and also allows slippage to remain hidden for longer.
If you have a 3 month task in the plan updating it involves thinking about all the things that go into it, how many are complete, when are moving and then working out how much is done vs how much remains. This is a very inexact science. Alternatively it comes down to gut feel “we’re about on track” or “we’re a bit behind”.
Unless there is a good reason I suggest that the maximum duration for any single task is no more than 3x the update frequency. Obviously, this is a guideline but breaking things down make the update faster; it is more of a started, completed, nearly there or slipping type update rather than an estimation. It also forces you to consider what goes into that long duration task and might allow greater finesse when applying resource or dependencies.
The exception to this is obviously things which are being tracked ‘off plan’.
Once tasks are broken down into the components it becomes very much easier to link them together to correctly reflect when a dependency is needed. Rather than having to say that in a 2 month task we’ll need X about 2 weeks into the task, the actual thing that X drives can be shown and the real impact of X moving out by 1 week can be seen.
Everyone understands the plan and agrees
The plan is owned by the project manager or whom ever will be delivering the activity/deliverables. Thus the plan needs to be written and structured in a way that makes sense to them. This is especially important when someone else is maintaining and possibly producing the plan for them – the plan has to be in the owner’s voice.
Never the less the plan has to be understood and bought into by all the people involved. This means it is vital that the people doing the tasks or responsible for them have contributed and agreed the activities and timescales. The number of plans which are ‘imposed’ on people is depressing because this is usually an early indicator of failure because the people actually doing the work don’t believe the plan!
The plan also needs to be communicated to stakeholders both at the beginning to gain buy-in and as the project progresses. This is where the Plan on a Page (POAP) or single page summary comes in. Being able to communicate on a single page is very powerful and you may find that different audiences need a different view but it is vital that all summaries agree with each other and can be maintained going forwards – this is the purpose of SummaryPro.
Use the plan
Whilst producing a plan is a useful exercise in its own right the continued use of the plan; updating it, using it as the only source of date information and running reports from the plan mean that it stays current and useful. The plan is your tool to predict the future, identify the impact of change and communicate progress to the team and stakeholders. Once you accept that no plan stays rigidly the same such change becomes second nature and a powerful tool.
Remember that most planning tools have the ability to save a baseline so you can always compare the current plan to the 'agreed' or baseline plan to see what has changed.
Other rules to help
Don’t have resources on summary tasks – not only does this confuse the picture as resources can only work on tasks but planning tools such as MS Project will also then apply these resources to all sub tasks in a hard to find way.
Don’t have linkages from or to Summary Tasks – in a simple plan this appears OK but once the plan grows to cover multiple pages or screens the ‘driving’ link can disapeaar off the top of the page and you can’t work out why a task is behaving as it is; “why can’t this task with no dependencies happen when I know it should?”
When updating a task change the dates – there is a temptation to not change the ‘agree’ plan however one of the functions of a plan is to predict the future. If a task is taking longer than expected or didn’t start when planned update the plan with your current expectations / assumptions. Thus the plan can move in line with the current reality of the project and predict what will happen. This can be vital when attempting to communicate the impact of change and uses the power of the program to avoid missed implications.
Linked to the above is “don’t have work in the past” – unless you’ve got a cunning plan to speed progress up on a task don’t have uncompleted work in the past. If you allow this to build up your plan can not be delivered to the timescales it is showing giving a false impression of what is possible.
Everything in the plan needs to be linked to something. Every task needs to be fully linked to all the things that are driving it and all the things that it drives. If something doesn't have any onward links it has to be one of the end points of the project. This means that when something moves it can correctly affect the other elements in the plan. This means that you'e using the power of the planning tool to help predict the impact of change, saving you effort and time as well as protecting you against unexpected impacts.