Project Planning (Practical Project Management Series). This time the subject is ‘project planning’
First of all I would like to make a clear the distinction between ‘project planning’ and ‘project plan’ because I’ve seen several times that this was causing problems in practice.
The ‘project planning’ describes the sequence and duration of tasks and links to the roles/people who are going to execute these tasks. In short: who does what and when (and when are the prodcuts being delivered). A ‘project planning’ is quite often a ‘Gantt-chart’.
The ‘project plan’ is a document that describes the project in terms of eg. project background, scope (what will be done and what will NOT be done within the project) and organisation.
My vision is that the project planning is intended to be a means and not an objective. What do I mean by this? The amount of time a Project Manager invests in planning and the amount of details should be proportional with the size of the project. In other words: don’t invest too much time in a project planning and keep the project planning clear. A project planning of eg. 1000 lines is hardly to oversee and requires a lot of time to build and maintain (even when you use the ‘fold mechanism’ of the tool). The structure of the project planning is of utmost importance to keep an overview and to see the relationships between the tasks.
Some practical tips for making a project planning:
- Start with making one main task and indent all other (‘summary’) tasks which enable you to see immediately the entire project duration.
- Create a ‘summary’ task for Project Management while you need this role during the entire project.
- Create a ‘summary’ task called ‘dependencies’ (eg.hardware delivery) in which you define all external (outside the project) dependencies (might be in the form of a milestone). Link all other tasks (or summary tasks) which are depending on this dependency. In this way you can see immediately what the impact will be of a dependency on your planning.
- Terminate a ‘summary’ task with a deliverable (as milestone) which enables you to see quickly when what is being delivered (and this is why we are doing the project isn’t it?).
- Planning of tasks etc. over a half a year is normally not very useful. Of course you plan what needs to be done but that’s about it. In the meantime so many things can (and will) change (often called ‘progressive insight’) that the chance is pretty big that this part needs to be planned again.
When you are using an Agile approach this is quite different while a ‘sprint’ is of a rather short period (weeks).
- Use the task ‘note’ option to document remarks and assumptions.
- Use for instance first ‘mindmapping’ to determine the project planning structure and then make the actual project planning which can be derived directly from the ‘mindmap’. The big advantage of a ‘mindmap’ is that this on a single page makes it easier to keep the overview and see the relationships.
- Add in the ‘footer’ of the project planning the date so you can always see which planning version this is.
The next time I’ll describe ‘change management’.
This is a ‘blog’ article by Lex van der Heijden regarding practical Project Management. For questions/remarks I’m available via [email protected] or via LinkedIn (nl.linkedin.com/in/lexvanderheijden/).
