“[…]Organizations dealing repeatedly with projects will soon develop templates of Work Breakdown Structures (WBS) holding the most current tasks and milestones. These canvasses speed up somewhat the project initiation and ensure some degree of standardization.
Over time though, the copy-pasting from one project to the next, the addition of “improvements” and requirements as well as countermeasures to problems kind of inflate the templates and the projects. This, in turn, extends the project’s duration as every additional task not only adds its allocated time to completion, but also the safety margin(s) the doer and/or project manager will add on top.[…]”
The project management literature astonishingly fails to provide guidance on the art of breaking a project down into tasks. The “Body of Knowledge” tells you what a Work Breakdown Structure (WBS) should look like but not how you actually break a project down into meaningful pieces, whether it is a dinner party, the construction of a bridge, or a moon shot. For a manager who has to make a plan, this makes templates irresistible: instead of thinking, you just fill in the blanks.
Chris’s questions are certainly relevant but I would like to go further and propose a few rules for generating a WBS.
“Manage technical data” is not an appropriate definition for a project or a task; “landing a man on the moon and bringing him back safely to the earth” is.
Projects are defined by their outcomes, and so are tasks at all levels in the WBS. And milestones are points in time at which subsets of outcomes have been achieved. Microsoft Project lets you assign durations to milestones, which, from a project management perspective, is absurd.
Work Backwards From The End Result
When developing a project plan, most managers start from today and work forward in time. First you need a spec, then a design, then a prototype, etc. This may work if you are a carpenter building a staircase for the 38th time, but not if you are innovating. You need instead to start from the desired outcome and paint a picture of it that is as accurate and detailed as possible.
From that picture, you can then determine what needs to happen to make it a reality, including training people, building structures and devices, securing permits, etc. While the end-state picture is likely to change during the project, your concept of it at the start is the best hope you have of not omitting anything essential in the WBS, and of getting task dependencies right.
Fit The Plan To The Project, Not The Opposite
The WBS — and the whole plan — should be determined by the desired outcome, not the other way around. To Chris’s concerns, I would add that using templates eventually restricts you to projects they apply to. The Kaizen Event, for example, is a project template, and, under the guise of implementing Lean, many companies only do what can be done as a Kaizen Event, and ignore projects that are either too small or too big for this template.
Use Templates As Checklists
Some projects, like office moves, are usually managed by junior employees who have never done it before. Once they have done one office move, apparently, they are not keen to repeat the experience. While they are doing it, they are understandably worried about forgetting anything essential, and templates or even documentation left from prior moves are useful as checklists.
If you work backward from the target outcome, you are unlikely to include unnecessary tasks or omit tasks that are physically necessary to produce it but you may omit some that have to do with the project’s environment. For example, you may need to inform and consult with groups of non-participants who will be affected by the project while in progress or after completion, and there may be regulatory compliance issues you are not aware of.
Apr 28 2017
7 questions to help you reduce project durations | Christian Hohmann
“[…]Organizations dealing repeatedly with projects will soon develop templates of Work Breakdown Structures (WBS) holding the most current tasks and milestones. These canvasses speed up somewhat the project initiation and ensure some degree of standardization.
Over time though, the copy-pasting from one project to the next, the addition of “improvements” and requirements as well as countermeasures to problems kind of inflate the templates and the projects. This, in turn, extends the project’s duration as every additional task not only adds its allocated time to completion, but also the safety margin(s) the doer and/or project manager will add on top.[…]”
Sourced through Chris Hohmann
Michel Baudin‘s comments:
The project management literature astonishingly fails to provide guidance on the art of breaking a project down into tasks. The “Body of Knowledge” tells you what a Work Breakdown Structure (WBS) should look like but not how you actually break a project down into meaningful pieces, whether it is a dinner party, the construction of a bridge, or a moon shot. For a manager who has to make a plan, this makes templates irresistible: instead of thinking, you just fill in the blanks.
Chris’s questions are certainly relevant but I would like to go further and propose a few rules for generating a WBS.
Contents
Definition By Outcome
“Manage technical data” is not an appropriate definition for a project or a task; “landing a man on the moon and bringing him back safely to the earth” is.
Projects are defined by their outcomes, and so are tasks at all levels in the WBS. And milestones are points in time at which subsets of outcomes have been achieved. Microsoft Project lets you assign durations to milestones, which, from a project management perspective, is absurd.
Work Backwards From The End Result
When developing a project plan, most managers start from today and work forward in time. First you need a spec, then a design, then a prototype, etc. This may work if you are a carpenter building a staircase for the 38th time, but not if you are innovating. You need instead to start from the desired outcome and paint a picture of it that is as accurate and detailed as possible.
From that picture, you can then determine what needs to happen to make it a reality, including training people, building structures and devices, securing permits, etc. While the end-state picture is likely to change during the project, your concept of it at the start is the best hope you have of not omitting anything essential in the WBS, and of getting task dependencies right.
Fit The Plan To The Project, Not The Opposite
The WBS — and the whole plan — should be determined by the desired outcome, not the other way around. To Chris’s concerns, I would add that using templates eventually restricts you to projects they apply to. The Kaizen Event, for example, is a project template, and, under the guise of implementing Lean, many companies only do what can be done as a Kaizen Event, and ignore projects that are either too small or too big for this template.
Use Templates As Checklists
Some projects, like office moves, are usually managed by junior employees who have never done it before. Once they have done one office move, apparently, they are not keen to repeat the experience. While they are doing it, they are understandably worried about forgetting anything essential, and templates or even documentation left from prior moves are useful as checklists.
If you work backward from the target outcome, you are unlikely to include unnecessary tasks or omit tasks that are physically necessary to produce it but you may omit some that have to do with the project’s environment. For example, you may need to inform and consult with groups of non-participants who will be affected by the project while in progress or after completion, and there may be regulatory compliance issues you are not aware of.
#ProjectManagement, #Templates, #KaizenEvent
See on <Scoop it link>
Share this:
Like this:
Related
By Michel Baudin • Blog reviews • 0 • Tags: Kaizen Event, Project management, Templates