My first post related to project management on this blog will be dedicated to sharing some of the basic tips and tricks which I learnt over the years and that I use when building a project work breakdown structure.
I do use these simple guidelines during initial planning reviews and when discussing with Project Managers about their plans. These principles are about the level of detail required for creating a qualitiative Work Breakdown Structure (WBS):
1. Each task should be be given a simple and straightforward name
Example: Design and coding of a piece of software should be split into 2 different tasks: one for the design and one for the coding.
The response to the question: "What exactly will be the outcome of this task?" should be obvious and straightforward. This is the key to a common understanding on both sides, the PM and the owner of the task, of what has to be done.
2. A task should allocated a single deliverable (e.g. some software documentation, an written paper deliverable, a piece of code, etc.)
"What will be produced?" If several a single task encompasses several deliverables, then what will be the status of that project task when only deliverable A out of say three deliverables (A,B and C) is made available? Will we consider this task 33% completed? The other two deliverables could take a fraction of the time it took to produce A. Or just the opposite. If there are dependencies between these tasks, then should we assume that the impact is on all 3 deliverables or only A or B? All these open questions reinforce the need to allocate one and only one deliverable to each of your tasks.
3. Each task should be placed under the responsibility of one single resource
Task responsibility isn't something to be trifled with. If you cannot possibly divide a task so as to share the workload amongst all the resources allocated to a deliverable, please ensure that there is only one resource in charge of the entire task.
4. A task should enable an estimate of time and effort with a very high degree of trust
When is a project broken down into an optimum number of tasks? This, in essence, is always debatable. This simple rule mentioned above has proven very effective as far as I am concerned. When we can, with a high level of confidence, estimate the effort required and the duration of the task: we've gone far enough in the breakdown of the projects into tasks.
I hope that you'll find these hints useful, let me have your comments and additional suggestions.
I've been leading IT projects for more than 20 years at telecom and computer manufacturers: Thomson Sintra, Digital Equipment, NCR, Nortel Networks, Orange Business. My passion is Project Management and leadership and I run a blog on the PM best practices at http://dantotsupm.com/