WBS is often recognised as a critical document to prepare in order to ensure the success of a project. But there are many approaches to prepare this important component : product oriented, task oriented, even organisation oriented (even if this is a mix of WBS and OBS). I would like to know others' opinions before to set a standard in my team. Saving Changes...
Todd WethyProgram Manager| Volkswagen of AmericaAuburn Hills, Mi, United States
Yes, there are many opions on the "correct" way to generate and use a WBS. I tend to lean towards the product centric view. I like to use the WBS with the customer to clearly define the deliverables of a project. I actually have used it as a status indicator for the customer as well, i.e. when an item on the WBS is through the design activitiy I can color code it to indicate that it is atthis stage and so on for each deliverable throughout the development process.
The whole product vs task orientation for a WBS question seems like a trivial one to me, as there is no real difference between the two, besides perhaps the addition of a verb or two to the product item description to turn it into a task.
---
What I'd like to ask Ganttheaders is how they feel about combining the development of the WBS with the identification of dependencies. After all, the bits and pieces identified in a WBS are meaningless without understanding the interactions between them. Projects are not collections of stand-alone products or tasks; projects are collections of dependent products/tasks. The easiest way, for me at least, to identify what is needed in a WBS is to start with the objectives, deliverables, and success criteria of a project and ask what I need to deliver them -- the predecessor dependencies. Saving Changes...
Todd WethyProgram Manager| Volkswagen of AmericaAuburn Hills, Mi, United States
Trivial? Boy, I've been in PM "discussions" regarding the use of a WBS that were certainly not trivial to some participants. There is a population out there that feels different about the use of a WBS, that just adding verbs to the WBS elements creates a schedule.
I was attempting to communicate that Didier may want to use the WBS for multiple purposes, as a PM deliverable to the customer to communicate the planned project deliverables as well as an input into the development of the schedule and not to limit his team to a single use.
The problem is, Todd, that some people do think that "just adding verbs to WBS elements creates a schedule." Typical WBS structures lay out what the creator thinks is needed to be done or delivered. They do not usually include any real dependency relationships, especially across the higher WBS elements. WBS' too frequently fall into the trap of local focus when a global (cross-project dependency) focus is what is needed. Saving Changes...
I would like to complete a WBS for a current project that I am starting next week. Does anybody have an example of one they have produced that they can share with me so that I begin to understand more about how to construct one? Saving Changes...
Anonymous
You're missing something, one should begin their development of a WBS after the high level business requirements and critical success factors are documented. Only then do you have a foundation from which the Project Manager and the senior leads for the project can start building the WBS, and don't worry, no one ever builds the WBS perfect with the first guess, the eraser always shows up during the discussion. THe best way to start the discussion is to understand two items. First, that the WBS is to reflect the contractual scope of work, and it's goal is to break that down into smaller, manageable chunks of work that can be estimated, planned, managed and controlled with cost accounts. Second, before you draw one box in the WBS you must first decide the naming convention of the LEVELS in the WBS to guide you on how to build it. For example, Level 1 is the title of the project, that's easy. Level 2 can be the PM phases of start-up, planning, execution and closedown. Level 3 can be the product or systems life cycle phases, all drawn under the execution box in Level 2, or you can put the life cycle phases in Level 2 with the major project delivery areas in Level 3. See why this is so important to label the levels? And, you might find that after you start to draw up the WBS, it's better to flip flop the levels to make more sense for your project. Also, one of the reasons for considering the higherarchy of a WBS first is that the WBS structure provides the rollup design for reporting later on, so if you don't want the project to be organized different from how you'll report on it, better adjust your WBS structure. Finally, the WBS is one of the very few items other than project scope that qualifies as a change control item, due to the fact that if you change the WBS, all historical reports and actuals will not align to the new structure, and the traceability of plans and progress becomes in jeapordy. There's lots more. Have I said too much? [email protected] Saving Changes...
Microsoft Project 98 does not automatically handle WBS coding. Does anyone have any tricks? Is is better to control the project in a Word document? Does Project 2000 do this better? Saving Changes...
Anonymous
It does. You can approach this two ways (at least).
1. You can insert a column to the layout and select WBS from the list.
2. Go to Tools/Options and selct the check box for "Show outline number". Saving Changes...
Whilst the outline and WBS fields in P98 do work, P98 does not support the use of a custom (generated) WBS coding scheme. You can type anything into the WBS field, but then you must maintain it manually.
Take a look at P2000 if this bothers you - here you can tell the program how your WBS coding scheme works, and the custom code will be generated automatically. Saving Changes...
There is a new book out - "How to Build a Work Breakdown Structure" by Carl Pritchard that is the best I have seen. It is available through the PMI.org website. Saving Changes...
