Talk:Work breakdown structure

From Wikipedia, the free encyclopedia

Contents

[edit] Please list the buzzwords

We need to address the "buzzwords" so we can remove the tag that has been placed on this article. For example is the term "progressive elaboration" considered a buzzword? (It can be cited in the PMBOK Guide Third Edition, Section 1.2 What is a Project? p. 6) What other terms in this article are perceived as buzzwords? --Garrybooker 19:26, 10 August 2007 (UTC)

<<list buzzword here>>
<<list buzzword here>>


I'd say that if nobody has come up with any items for the list in a little over three months time, then maybe there aren't so many buzzwords that need removing after-all. The only part of this article that felt even slightly "buzzwordy" to me was the section "Level of detail (granularity) and progressive elaboration". Even there, the phrase "Progressive Elaboration" was well-explained in simple terms, leaving only "rolling wave planning" as being only slightly "buzzish".
I don't think it would even have occurred to me to stop and ask about it if there wasn't a big "BUZZWORDS" tag at the top.
Personally, I'd remove it, but I don't think unilateral action is the "Wiki Way". -- DigitalSorceress (talk) 22:29, 29 November 2007 (UTC)

I would suggest asking a non-PM friend to read the article if you can't see the buzzwords. (Then you could decide which were buzzwords and which were just jargon.)
But before doing that, you should re-think how much PMBOK this article contains and whether it really constitutes "fair use". Rather than an ecyclopedic treatment of the WBS concept, we appear to have a paraphrased PMBOK entry. No background. No history of development. No real examples of use. No reference to systems engineering. Not much connection to other techniques. I suspect editing this into a more encyclopedic article would reduce the buzz-count. ComputerGeezer (talk) 01:15, 10 January 2008 (UTC)

You don't understand: these are technical terminology, not buzzwords. Of course, ignorant people might copy the technicians and misuse these words ad nauseam. The words remain, however, terminology. 99.201.221.255 (talk) 03:45, 1 February 2008 (UTC)

Someone delete the buzz word stamp and see if anyone notices / cares! I'd agree there are a lot of technical terms in there, beyond that there are terms which are perhaps hard to describe or require some knowledge of the terms used.Zelphi (talk) 13:46, 9 April 2008 (UTC)

[edit] This article was re-written from scratch on Dec 2, 2006

I've put this article on my To Do list for substantial re-work. Here are a few ideas: A WBS should be comprehensive but not "exhaustive." A WBS is a step-wise refinement of broad objectives to discrete effort that can be scheduled, or similar wording. No reason to associate WBS with U.S. Government projects; it applies to all projects even if the WBS is a simple list. The painting example goes back to the orignal aricle; need a better example and better presentation. How to Build a WBS states "In building a work breakdown structure for painting a room (activity-oriented) it is essential that you state the obvious." Huh? The second graphic (generated by inforapid.com) violates WBS design principles and graphic design principles. WBS design principles not spelled out clearly (e.g. 100% rule, outcome orientation, triple constraint decomposition, etc.) Application of short-term memory to WBS design? This is not supported by literature, and it's just wrong. Link cleanup More later If you have other ideas, now is a good time to list them. --Garrybooker 20:39, 14 November 2006 (UTC)

A major re-write has been initiated, as I announced here about two weeks ago. This is an important topic, and the prior article was unsatisfactory. Comments? Questions? Complaints? Garrybooker 07:32, 2 December 2006 (UTC)
Just one, since its an article talk page, its not good practice to remove any talk from the page unless its vandalism or personal attacks.--Crossmr 21:57, 2 December 2006 (UTC)

[edit] Feedback wanted

Do you like the WBS construction illustration? Garrybooker 05:43, 3 December 2006 (UTC)

Some other thoughts- A WBS is primarily a tool for organizing and managing the work on a project. That is its reason for being.
- A WBS uses a hierarchical coding structure for tasks with each succeeding level providing a lower level of detail. The depth of any branch in the WBS hierarchy will vary and is dictated by need.
-A WBS groups tasks by work areas and sub-areas. An area can be physical areas, design drawing packages, project phases, system modules, or anything that makes sense for organizing and managing a particular kind of project.
The WBS structure for the engineering phase of an engineering and construction project will be organizaed differently than the construction WBS for the same project. This is because the work is organized and managed differently for the two phases.
- The top level of a WBS, the project level, is most commonly called level 0, not level 1. However there is no perfect agreement on this in the literature or by organizations.
- The lowest level of a WBS, sometimes called the terminal level, is just above activities, is generally called the work package level.
- I will try to upload a WBS example graphic for you to consider later this week.
I hope this is useful.
Regards,
H.E. Hall —The preceding unsigned comment was added by 74.242.64.129 (talk) 11:01, 11 December 2006 (UTC).
Reply to H.E. Hall: Thanks so much for the helpful advice! I too prefer labelling the root as Level 0, but PMI's Practice Standard for Work Breakdown Structures uses Level 1 for root of the bicycle example. I'll try to put some time on the article this week, too. I think having a section of exempalary WBSs is a good idea. We just need to watch for poor examples, such as the room painting example that was here for over five years. --Garrybooker 16:40, 11 December 2006 (UTC)
NOTICE: I plan to delete the paragraph Work_breakdown_structure#WBS_construction_example and Figure 1. There is no suitable citation that supports this technique directly. I hope, in time, there will be! If there are any comments, add them here with two indents (colons). Otherwise, it's gone. Garrybooker 04:15, 12 December 2006 (UTC)
Hello, I'm new to Wikipedia, so excuse me if I have used the wrong function to add a comment. Back to the subject : I think the construction example should stay, at least until a replacement can be found. Perhaps it would be necessary to add a line such as "This describes one of the possible methods of WBS construction. Other methods exist." Personally I was taught and have used mainly vertical WBS structures using hierarchically linked boxes (the same WBS structure would later be used horizontally for tabular reporting or creation of gantt charts), and I would like to see such an example here too.~ Markspar 14:47, 13 December 2006 (UTC)Markspar 14:49, 13 December 2006 (UTC)
Markspar, your feedback was perfectly executed by Wikipedia standards. Thanks for the signature, too. The PMI Practice Standard (Second Edition) includes a number of presentation methods such as the hierarchical box method. I think we'll create an examples section toward the end of the article. The examples can show different WBS content and different WBS presentations. Garrybooker 17:14, 13 December 2006 (UTC)

Hallo,

No the WBS construction illustration is not ok. Sorry, direct.
It shows a PBS Product breakdown structure.
WBS should be something like : define prodcut, realise parts, assemble and test product.
It's an old and even PMBoK mistake to mix up Product and Work breakdown strucutre. It is necessary to define at first the product breakdown strucutre bike to frame (to : fork, frame), frontwheel (to : hub, spokes, tyre, ...), rearwheel ( ...), powertrain, breaks, ... then you might decide to develop the frame (MAKE), but buy all other components (BUY).
A WBS could look like develop bike to : edit tech Specs for bike, design frame, produce frame, edit TechSpec for parts, buy parts, assemble bike, test bike.


--Legeland 14:07, 12 October 2007 (UTC)

[edit] WBS element

Phil Magrogan: The statement, " A terminal element is sometimes called a work package, although the two terms are not synonymous." is not a correct statement in teh PMBOK. According to PMI the Work Package "is" the lowest level of the WBS. —The preceding unsigned comment was added by 72.83.129.163 (talk) 01:51, 7 March 2007 (UTC).

[edit] Human memory

"It is far more important to construct a logical grouping of planned outcomes than to worry about the limits of short-term human memory." Is it? Who says? How many people disagree? This statement, and the section it is in, are dangerously close to opinion, rather than the consensus or neutral view. Even if it is the dominant view, it shouldn't be expressed in such sweeping terms. My experience suggests that there are times when it is important to construct the WBS strictly according to the product architecture, and to do so comprehensively, and other times (short projects for example) when psychological constraints come in to play. Matt Whyndham 08:15, 7 September 2007 (UTC)

I wrote that, and I agree with Matt. I wrote it in response to the original article that included this sweeping un-sourced opinion...
"Each level should be 5-9 elements broad. These suggestions derive from the following facts:
1. short-term memory capacity is limited to 5-9 items.
2. having fixed time to plan a project, the more terminal elements there are, the less time there is to pay attention to any single one of them. Consequently, the estimates are less thought-through.
3. the more terminal elements there are the more there are potential dependencies among them (see fact 2 above for consequences).
This original information was apparently an opinion, and not backed up by any credible source that I am aware of. My response should have been simply to delete it. Since I wrote the offending response, I'll delete it. Thanks Matt, good catch. --Garrybooker 16:23, 7 September 2007 (UTC)
Hi Garry, I can see why that earlier opinion should have got you going! Though it's exactly the sort of informal advice I give to WBS-knitters, but I wouldn't want it in an encyclopedia, which should be fairly close to well-known bodies (NB plural not just PMI's) and prominent alternate views. Given that, something like the following "Some authors advise [refs (you got any? I haven't)], on the basis of ease-of-use arguments, that the WBS be structured with a limited number of branches at each node." might fit OK though. But I wouldn't care too much if it wasn't mentioned at all, either. Cheers. Matt Whyndham 07:13, 8 September 2007 (UTC)
Hey Matt. I'm not aware of any such sources. I currently have a project where one branch has eleven work packages -- because that was the simplest and most logical way to define the scope. If I had followed a rule that arbitrarily limited me to nine elements, it would have introduced unnecessary and unhelpful complexity into my WBS. So I think the issue is something of a red herring. Therefore, I think it doesn't belong in the main article, but this discussion may be valuable to some readers. --Garrybooker 22:48, 9 September 2007 (UTC)
Hello,I’m new, I don’t know how this works, sorry :). Regarding the WBS, I’ve stated in the developement procedure that the WBS will generate the BSI (Basic Subject Index). What should I do if a branch will exceed 9 elements, as the available digits in the document code are only nine?? —Preceding unsigned comment added by Flash Q Dunne (talk • contribs) 07:29, 21 January 2008 (UTC)

[edit] Copyright Issue

There is a substantially similar white paper by Michael D. Taylor at http://www.projectmgt.com/Files/Article-WBS%20How.pdf

Has Mr. Taylor released this paper into the public domain? Or is the paper an expansion of the wiki? Or should this article revert to its previous form? --ComputerGeezer (talk) 18:23, 11 January 2008 (UTC)

No, don't revert. This Wikipedia article definitely came first. Mr. Taylor's article is a copy of much of the content from this Wikipedia article. I know this because I wrote much of the original content of this article on Dec 2, 2006 (see note above) including the graphic in Taylor's white paper. --Garrybooker (talk) 03:35, 12 January 2008 (UTC)
See, that's why I don't just revert without asking...perhaps someone should suggest some attribution notes on the whitepaper. ComputerGeezer (talk) 18:20, 12 January 2008 (UTC)

[edit] Diagram

The diagram has underscores after every item, not just the terminal elements, contrary to ...

"In this example, the WBS coding scheme includes a trailing "underscore" character ("_") to identify terminal elements."

... It looks incorrect to me, but I'm not a PM-person... 203.110.13.5 (talk) 03:01, 4 February 2008 (UTC)

  • 203.110.13.5 is partially correct, but the greater error lies in the page's preceding definition of "terminal element." A terminal element is not necessarily the smallest level of work possible, but rather the lowest level of work called out in any particular WBS. Accordingly, the graphic uses underscores to indicate the terminal elements in a Level 1 structure, in a Level 2 structure, and so on. Note that the Level 3 structure has underscores with secondary or tertiary elements, depending on whether the secondary elements were further subdivided. Please reference the PMBOK Guide to amend the definition of terminal element. 66.255.98.82 (talk) 18:19, 8 May 2008 (UTC)