This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
The contents of the Progressive elaboration page were merged into Work breakdown structure on 29 October 2023. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
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)
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)
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)
Probably late in the "progressive elaboration" of this article but thought it was important to note that the PMBOK was collaorativey developed and is recognized as an ANSI standard for their process to include all appropriate voices in what is viewed as best practices in the industry. That being said I believe quoting terms like progressive elaboration reflect some of the best thinking on the subject and fit well with in the wiki-pedia model. Once the concept is presented in the encyclopedic article, it becomes important to then explain how the concept applies within other bodies of knowledge like systems engineering.-- 75.27.24.83 ( talk) 14:42, 22 September 2009 (UTC)
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)
Do you like the WBS construction illustration? Garrybooker 05:43, 3 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)
Gary et al,
The concept of a WBS is or should be fairly straightforward. The WBS tells us WHAT elements ("deliverables") are necessary to plan, execute, control and close a project, while the schedule will tell us HOW we plan on creating each of those deliverables. In this context, the WBS should always represent exactly 100% of the approved scope (deliverables) of any project.
I would suggest we cite the work of Max Wideman http://www.maxwideman.com/pmglossary/PMG_W00.htm#Work%20Breakdown%20Structure%20Dictionary who has compiled a glossary of common definitions for WBS from a variety of sources, not just PMI's PMBOK Guide.
As we can see from the definitions posted by Wideman, there is a clear difference between those who think the WBS should be DELIVERABLE oriented (as I do) as opposed to those who think the WBS should be TASK oriented.
Perhaps we should make some distinction between the two schools of thought?
BR, Dr. PDG, Jakarta
118.137.203.218 ( talk) 04:51, 27 October 2008 (UTC)
I see both approaches - product or task - and think either one or a mix of both can serve the purpose of providing a name and numbering structure that helps organize and manage. I'd focus more on it should help accomplishing that goal rather than particular approach to building it. It seems more important that the breakdown numbering and naming is used in SOW, accounting, and CDRL to tie all parts together than what the philosophy of name choices is. (One could just use a base heirarchy from MIL-881 instead of making up unique words and numbers... it is more important it works than it look pretty.) It also seems more important to say that clear definitions of the names are part of WBS, and numbering comes in tabular form, the focus on a diagram that goes 3 levels is to convey the concept but is somewhat misleading impression that WBS is a 3-level diagram. Markbassett ( talk) 12:36, 23 April 2013 (UTC)
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).
I do not consider the PMBOK Guide to be the end all source of definitions. But your definition from the PMBOK Guide is not complete. It is the lowest DEVELOPED level, not the lowest POSSIBLE level. Implicit in this is as the project becomes better defined, the "work package" will change, eventually consisting of one or more activities in the CPM schedule.
IMPO, PMI does a poor job of differentiating the line of demarcation where scope definition ends and scheduling begins. Jim Lewis does a better job of defining the various levels. (See Project Manager’s Desk Reference, 2nd Edition, Lewis, 2000, pg 91) In this illustration, he doe not reflect PMI's particular perspective of the Work Package) as being the lowest developed level, but a discrete level (Level 5.0).
The part I like about Lewis's approach is he resolves the quandary between those who claim the WBS is process driven vs those who claim it to be deliverable driven. Lewis (correctly so, IMPO) indicates that while some levels are very much process focused, other levels are clearly deliverable focused.
BR, Dr. PDG, Jakarta
118.137.203.218 ( talk) 06:13, 27 October 2008 (UTC)
"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)
The Human Memory myth has worked its way back into this article. As discussed in 2007, this myth probably derives from the common misapplication of George A. Miller's 1956 paper The_Magical_Number_Seven,_Plus_or_Minus_Two. Miller's paper is about recall of unrelated bits of information. WBS child elements are grouped (chunked) under a common WBS parent element, so they are arguably not unrelated bits of information. A list of 20 logically related elements with a common parent may be more appropriate than dividing the list into three arbitrary sub-groups, which would add unnecessary complexity. Moreover, no credible citations for this WBS design opinion were presented in previous discussions. So, I'm deleting the paragraph "Decomposition Considerations (Breadth vs. Depth)." -- Garrybooker ( talk) 14:51, 4 November 2008 (UTC)
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)
I believe Mr. Taylor's paper is substantially correct, although I do not believe his paper represents anything unique or otherwise copyrightable, other than the illustrations.
I do not agree with Taylor that the WBS establishes the start and end dates. The way I use and create WBS, they form the basis to define 100% of the work outputs required to complete a project. Thus the WBS elements become SUMMARY BARS (using MSP) or Hammock Activities (using Primavera) with the start and end dates being determined by the logic and durations of all previous activities which come before them, and the actual duration to produce each specific deliverable represents the combined duration of all the activities and logic which are necessary to produce the deliverable defined by the WBS.
BR, Dr. PDG, Jakarta
118.137.203.218 ( talk) 05:08, 27 October 2008 (UTC)
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)
I'm not sure a comprehensive list of "what a WBS is not" is possible or advisable. Unless someone cites a source for these "common" problems, I recommend removal of the section. ComputerGeezer ( talk) 00:35, 18 June 2008 (UTC)
... would greatly enhance information delivery to the individuals involved in the readership of this article. Just saying. 189.136.140.190 ( talk) 00:06, 18 September 2008 (UTC)
"Plain English" as distinguished from what? From terms of art? From professional language that has precise meaning to members of the profession? Would you ask a forester to speak of "trees" or "beetles" instead of speaking of tan-bark oaks or dendroctonus brevicomis? Maclir2001 ( talk) 05:34, 3 October 2009 (UTC)
To help with this discussion, I am sharing three examples of standardized WBS models that have or are finding their way into the "public domain" simply through the fact they are being widely adopted as standards.
The three of them are: The Construction Specifications Institute's "Masterformat" [1]- and "Uniformat" [2]; NORSOK Z-014 Standardized Cost Breakdown Structure ISO/PAC's Omniclass [3]
The driver behind the standardization of these WBS examples is Building Integrated Modeling (BIM) which is the confluence between the use of computers which will link the world of architecture and engineering, using 3 Dimensional Computer Aided Design and Drafting (3D CADD) combined with the cost estimating (4D CADD) function and the creation of Critical Path Method Scheduling (CPM) using 5D CADD.
In order to effectively integrate these three disparate disciplines, each "object" (deliverable in the parlance of project management) will need to have all the information associated with that object accessible, including not only the design specifications, but also the costs of procuring and installing, the lead times and installation times. To accomplish this, a common numbering system is necessary. The three examples I have shared are coming from the construction sector and while CSI has been around for something like 40 years and the NORSOK standards have been around for at least 25 years, the real driver has been the need to integrate the design, procurement and construction, operation, maintenance and eventual disposal processes. Truly a "birth to death" or "Life Cycle" (more appropriately, IMPO, Life SPAN) or Asset Management model.
BR, Dr. PDG, Jakarta
118.137.203.218 ( talk) 02:33, 23 November 2008 (UTC)
All Wikipedia articles at first are written for people unfamilar with the subject. That is why, I think, the use of abbreviations, particular the term WBS, should be limited.
To improve online reading for those people, I explicitly introduced the abbreviation "Work Breakdown Structure (WBS)" in every new paragraph.
-- Marcel Douwe Dekker ( talk) 15:23, 8 February 2009 (UTC)
Ok. I will rephrase. There are different options here:
Now the first option is not acceptable to me. I think the article is getting to technical that way. I also think the Manual of Style you are refering to is not that clear. There should at least be a difference between familiar (UK, US, NASA, DVD) and unfamiliar (CAD, CAM, WBS) abbreviations. Now in your experience, the common usage is "WBS", not "Work Breakdown Structure". Being a Dude From Work, I guess you are refering to common use among professionals. Wikipedia however is an encyclopedia more for beginners. We make our own rules. For example, just last week we agreed on Wikicommons to change the name "Category:CAD" in "Category:Computer Aided Design (CAD)", see here
Now I guess the second option is appearently over the top for you, or you just want the first option back??
Now I took a look at the similar German article, named "Projektstrukturplan", and found a third option. In that article the full term "Projektstrukturplan" is used more often, but the abreviation is explained only once. This seems like a good alternative, and I will implement it right now to see how it works.
One last thing. The manual indeed states, that acronym usage is acceptable. And the abbreviation WBS is indeed used several times in the article. The manual doesn't state the abbreviation should be used exclusively.
-- Marcel Douwe Dekker ( talk) 20:02, 24 February 2009 (UTC)
The main image for this article claims to represent a work breakdown structure, but actually appears to be a product breakdown structure. This could prove confusing to those new to the concepts.
If we can get consensus, I would like to replace this with a diagram that more accurately reflects the work tasks and activities required to produce something. What are your thoughts? Greyskinnedboy ( talk) 19:02, 17 March 2009 (UTC)
There has been a lot of confusion on this page stemming (I believe) from the disparate uses of the phrase "work breakdown structure". PRINCE2 uses the phrase "Product breakdown structure" to describe what other practitioners call a "physical achitecture" or "product part" of a work breakdown structure. Perhaps it would be helpful to create new articles labeled Work breakdown structure (PRINCE2) and Product breakdown structure (PRINCE2) so that those definitions could be clearly laid out there. You could even label the existing article "Work breakdown structure (PMI/US/NASA/DoD)" or something like that... 214.4.238.61 ( talk) 22:38, 29 December 2009 (UTC)
The "Coding" section of this page was largely copied and pasted from http://www.pmhut.com/wbs-examples. Seems to be a pretty clear violation of the copyright asserted by that page ( © 2007-2011 PM Hut - an itoctopus project ) It is not OK to copy-paste from a non-free source even if we change the text a little bit ( Wikipedia:Copy-paste#Can I copy-paste if I change the text a little bit? ) 164.58.104.33 ( talk) 19:05, 27 July 2011 (UTC)
The first two bullet points, or "rules of thumb" are a tad bit confusing. At first reading I thought they were incompatible: if a a work package is maximum 80 hours (presumably man-hours, or is it just 80 regardless of the amount of committed manpower?) then how could it exceed a reporting period of a month? Then I the work package would not necessarily have to be contiguous, therefore it could be an amount of time that when added together was 80 hours but could potentially exceed a month.
My point being, as a layman with over a decade of practical self-taught project management experience exploring the formal theories of project management and trying to fit my experience into this framework, this section seems like it could be a bit clearer, or that a small amount of elaboration might be hugely beneficial. Orson1492 ( talk) 17:21, 14 January 2015 (UTC)
Does the article need more highlighting of the context or use ? If so, HOW ???? I am thinking the article perhaps needs an explicit section for usage or relationshiops.
It's not something you see much said directly but more apparent by the context and examples, so I've not got an easy way to summarization nor something said in numerous cites. The WBS is able to be the dictionary defining each part of work and everywhere else (like invoices or orgcharts) can just then use those reference numbers to indicate the association and show complete coverage. It's easy if the WBS matches exactly the label, meaning, and structure of the contract document -- it could/should basically be the outline or table of contents for Statement of work that gives the definition of what is done, and the Statement of work says what to do at each. I've not seen usage and relationship commonly SAID nor is it commonly said all WBS uses, but do see many instances of mention -- the MIL-HDBK-881 on WBS, the DAU SE Fundamentals or their Scheduling guide for PMs, the CMMI project planning requires it to breakdown work, be heirarchial, and include definitions. Then in various users I see locally-specific relationship or practices, such as MIL-HDBK-245, the CDC practice guide. consultant,
So -- anyone want have a better way than just making a section and trying to fill it in ? Markbassett ( talk) 22:10, 26 February 2016 (UTC)
It looks like user:Jpussacq uploaded a new file named "Product-oriented work breakdown structure of an aircraft system.png" to the Commons in support of es:wikipedia, then user:Armbrust thoughtfully updated the filename to WBS.png to make it clearer, thus destroying the English language picture which originally held the name "WBS.png". Now we have a Spanish language example illustration in the lede. Fortunately it's too small to read anyway, so I guess we'll just leave it there...
--a former editor 214.10.6.24 ( talk) 16:14, 8 June 2016 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on Work breakdown structure. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 17:49, 2 December 2017 (UTC)
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
The contents of the Progressive elaboration page were merged into Work breakdown structure on 29 October 2023. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
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)
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)
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)
Probably late in the "progressive elaboration" of this article but thought it was important to note that the PMBOK was collaorativey developed and is recognized as an ANSI standard for their process to include all appropriate voices in what is viewed as best practices in the industry. That being said I believe quoting terms like progressive elaboration reflect some of the best thinking on the subject and fit well with in the wiki-pedia model. Once the concept is presented in the encyclopedic article, it becomes important to then explain how the concept applies within other bodies of knowledge like systems engineering.-- 75.27.24.83 ( talk) 14:42, 22 September 2009 (UTC)
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)
Do you like the WBS construction illustration? Garrybooker 05:43, 3 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)
Gary et al,
The concept of a WBS is or should be fairly straightforward. The WBS tells us WHAT elements ("deliverables") are necessary to plan, execute, control and close a project, while the schedule will tell us HOW we plan on creating each of those deliverables. In this context, the WBS should always represent exactly 100% of the approved scope (deliverables) of any project.
I would suggest we cite the work of Max Wideman http://www.maxwideman.com/pmglossary/PMG_W00.htm#Work%20Breakdown%20Structure%20Dictionary who has compiled a glossary of common definitions for WBS from a variety of sources, not just PMI's PMBOK Guide.
As we can see from the definitions posted by Wideman, there is a clear difference between those who think the WBS should be DELIVERABLE oriented (as I do) as opposed to those who think the WBS should be TASK oriented.
Perhaps we should make some distinction between the two schools of thought?
BR, Dr. PDG, Jakarta
118.137.203.218 ( talk) 04:51, 27 October 2008 (UTC)
I see both approaches - product or task - and think either one or a mix of both can serve the purpose of providing a name and numbering structure that helps organize and manage. I'd focus more on it should help accomplishing that goal rather than particular approach to building it. It seems more important that the breakdown numbering and naming is used in SOW, accounting, and CDRL to tie all parts together than what the philosophy of name choices is. (One could just use a base heirarchy from MIL-881 instead of making up unique words and numbers... it is more important it works than it look pretty.) It also seems more important to say that clear definitions of the names are part of WBS, and numbering comes in tabular form, the focus on a diagram that goes 3 levels is to convey the concept but is somewhat misleading impression that WBS is a 3-level diagram. Markbassett ( talk) 12:36, 23 April 2013 (UTC)
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).
I do not consider the PMBOK Guide to be the end all source of definitions. But your definition from the PMBOK Guide is not complete. It is the lowest DEVELOPED level, not the lowest POSSIBLE level. Implicit in this is as the project becomes better defined, the "work package" will change, eventually consisting of one or more activities in the CPM schedule.
IMPO, PMI does a poor job of differentiating the line of demarcation where scope definition ends and scheduling begins. Jim Lewis does a better job of defining the various levels. (See Project Manager’s Desk Reference, 2nd Edition, Lewis, 2000, pg 91) In this illustration, he doe not reflect PMI's particular perspective of the Work Package) as being the lowest developed level, but a discrete level (Level 5.0).
The part I like about Lewis's approach is he resolves the quandary between those who claim the WBS is process driven vs those who claim it to be deliverable driven. Lewis (correctly so, IMPO) indicates that while some levels are very much process focused, other levels are clearly deliverable focused.
BR, Dr. PDG, Jakarta
118.137.203.218 ( talk) 06:13, 27 October 2008 (UTC)
"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)
The Human Memory myth has worked its way back into this article. As discussed in 2007, this myth probably derives from the common misapplication of George A. Miller's 1956 paper The_Magical_Number_Seven,_Plus_or_Minus_Two. Miller's paper is about recall of unrelated bits of information. WBS child elements are grouped (chunked) under a common WBS parent element, so they are arguably not unrelated bits of information. A list of 20 logically related elements with a common parent may be more appropriate than dividing the list into three arbitrary sub-groups, which would add unnecessary complexity. Moreover, no credible citations for this WBS design opinion were presented in previous discussions. So, I'm deleting the paragraph "Decomposition Considerations (Breadth vs. Depth)." -- Garrybooker ( talk) 14:51, 4 November 2008 (UTC)
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)
I believe Mr. Taylor's paper is substantially correct, although I do not believe his paper represents anything unique or otherwise copyrightable, other than the illustrations.
I do not agree with Taylor that the WBS establishes the start and end dates. The way I use and create WBS, they form the basis to define 100% of the work outputs required to complete a project. Thus the WBS elements become SUMMARY BARS (using MSP) or Hammock Activities (using Primavera) with the start and end dates being determined by the logic and durations of all previous activities which come before them, and the actual duration to produce each specific deliverable represents the combined duration of all the activities and logic which are necessary to produce the deliverable defined by the WBS.
BR, Dr. PDG, Jakarta
118.137.203.218 ( talk) 05:08, 27 October 2008 (UTC)
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)
I'm not sure a comprehensive list of "what a WBS is not" is possible or advisable. Unless someone cites a source for these "common" problems, I recommend removal of the section. ComputerGeezer ( talk) 00:35, 18 June 2008 (UTC)
... would greatly enhance information delivery to the individuals involved in the readership of this article. Just saying. 189.136.140.190 ( talk) 00:06, 18 September 2008 (UTC)
"Plain English" as distinguished from what? From terms of art? From professional language that has precise meaning to members of the profession? Would you ask a forester to speak of "trees" or "beetles" instead of speaking of tan-bark oaks or dendroctonus brevicomis? Maclir2001 ( talk) 05:34, 3 October 2009 (UTC)
To help with this discussion, I am sharing three examples of standardized WBS models that have or are finding their way into the "public domain" simply through the fact they are being widely adopted as standards.
The three of them are: The Construction Specifications Institute's "Masterformat" [1]- and "Uniformat" [2]; NORSOK Z-014 Standardized Cost Breakdown Structure ISO/PAC's Omniclass [3]
The driver behind the standardization of these WBS examples is Building Integrated Modeling (BIM) which is the confluence between the use of computers which will link the world of architecture and engineering, using 3 Dimensional Computer Aided Design and Drafting (3D CADD) combined with the cost estimating (4D CADD) function and the creation of Critical Path Method Scheduling (CPM) using 5D CADD.
In order to effectively integrate these three disparate disciplines, each "object" (deliverable in the parlance of project management) will need to have all the information associated with that object accessible, including not only the design specifications, but also the costs of procuring and installing, the lead times and installation times. To accomplish this, a common numbering system is necessary. The three examples I have shared are coming from the construction sector and while CSI has been around for something like 40 years and the NORSOK standards have been around for at least 25 years, the real driver has been the need to integrate the design, procurement and construction, operation, maintenance and eventual disposal processes. Truly a "birth to death" or "Life Cycle" (more appropriately, IMPO, Life SPAN) or Asset Management model.
BR, Dr. PDG, Jakarta
118.137.203.218 ( talk) 02:33, 23 November 2008 (UTC)
All Wikipedia articles at first are written for people unfamilar with the subject. That is why, I think, the use of abbreviations, particular the term WBS, should be limited.
To improve online reading for those people, I explicitly introduced the abbreviation "Work Breakdown Structure (WBS)" in every new paragraph.
-- Marcel Douwe Dekker ( talk) 15:23, 8 February 2009 (UTC)
Ok. I will rephrase. There are different options here:
Now the first option is not acceptable to me. I think the article is getting to technical that way. I also think the Manual of Style you are refering to is not that clear. There should at least be a difference between familiar (UK, US, NASA, DVD) and unfamiliar (CAD, CAM, WBS) abbreviations. Now in your experience, the common usage is "WBS", not "Work Breakdown Structure". Being a Dude From Work, I guess you are refering to common use among professionals. Wikipedia however is an encyclopedia more for beginners. We make our own rules. For example, just last week we agreed on Wikicommons to change the name "Category:CAD" in "Category:Computer Aided Design (CAD)", see here
Now I guess the second option is appearently over the top for you, or you just want the first option back??
Now I took a look at the similar German article, named "Projektstrukturplan", and found a third option. In that article the full term "Projektstrukturplan" is used more often, but the abreviation is explained only once. This seems like a good alternative, and I will implement it right now to see how it works.
One last thing. The manual indeed states, that acronym usage is acceptable. And the abbreviation WBS is indeed used several times in the article. The manual doesn't state the abbreviation should be used exclusively.
-- Marcel Douwe Dekker ( talk) 20:02, 24 February 2009 (UTC)
The main image for this article claims to represent a work breakdown structure, but actually appears to be a product breakdown structure. This could prove confusing to those new to the concepts.
If we can get consensus, I would like to replace this with a diagram that more accurately reflects the work tasks and activities required to produce something. What are your thoughts? Greyskinnedboy ( talk) 19:02, 17 March 2009 (UTC)
There has been a lot of confusion on this page stemming (I believe) from the disparate uses of the phrase "work breakdown structure". PRINCE2 uses the phrase "Product breakdown structure" to describe what other practitioners call a "physical achitecture" or "product part" of a work breakdown structure. Perhaps it would be helpful to create new articles labeled Work breakdown structure (PRINCE2) and Product breakdown structure (PRINCE2) so that those definitions could be clearly laid out there. You could even label the existing article "Work breakdown structure (PMI/US/NASA/DoD)" or something like that... 214.4.238.61 ( talk) 22:38, 29 December 2009 (UTC)
The "Coding" section of this page was largely copied and pasted from http://www.pmhut.com/wbs-examples. Seems to be a pretty clear violation of the copyright asserted by that page ( © 2007-2011 PM Hut - an itoctopus project ) It is not OK to copy-paste from a non-free source even if we change the text a little bit ( Wikipedia:Copy-paste#Can I copy-paste if I change the text a little bit? ) 164.58.104.33 ( talk) 19:05, 27 July 2011 (UTC)
The first two bullet points, or "rules of thumb" are a tad bit confusing. At first reading I thought they were incompatible: if a a work package is maximum 80 hours (presumably man-hours, or is it just 80 regardless of the amount of committed manpower?) then how could it exceed a reporting period of a month? Then I the work package would not necessarily have to be contiguous, therefore it could be an amount of time that when added together was 80 hours but could potentially exceed a month.
My point being, as a layman with over a decade of practical self-taught project management experience exploring the formal theories of project management and trying to fit my experience into this framework, this section seems like it could be a bit clearer, or that a small amount of elaboration might be hugely beneficial. Orson1492 ( talk) 17:21, 14 January 2015 (UTC)
Does the article need more highlighting of the context or use ? If so, HOW ???? I am thinking the article perhaps needs an explicit section for usage or relationshiops.
It's not something you see much said directly but more apparent by the context and examples, so I've not got an easy way to summarization nor something said in numerous cites. The WBS is able to be the dictionary defining each part of work and everywhere else (like invoices or orgcharts) can just then use those reference numbers to indicate the association and show complete coverage. It's easy if the WBS matches exactly the label, meaning, and structure of the contract document -- it could/should basically be the outline or table of contents for Statement of work that gives the definition of what is done, and the Statement of work says what to do at each. I've not seen usage and relationship commonly SAID nor is it commonly said all WBS uses, but do see many instances of mention -- the MIL-HDBK-881 on WBS, the DAU SE Fundamentals or their Scheduling guide for PMs, the CMMI project planning requires it to breakdown work, be heirarchial, and include definitions. Then in various users I see locally-specific relationship or practices, such as MIL-HDBK-245, the CDC practice guide. consultant,
So -- anyone want have a better way than just making a section and trying to fill it in ? Markbassett ( talk) 22:10, 26 February 2016 (UTC)
It looks like user:Jpussacq uploaded a new file named "Product-oriented work breakdown structure of an aircraft system.png" to the Commons in support of es:wikipedia, then user:Armbrust thoughtfully updated the filename to WBS.png to make it clearer, thus destroying the English language picture which originally held the name "WBS.png". Now we have a Spanish language example illustration in the lede. Fortunately it's too small to read anyway, so I guess we'll just leave it there...
--a former editor 214.10.6.24 ( talk) 16:14, 8 June 2016 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on Work breakdown structure. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 17:49, 2 December 2017 (UTC)