Talk:Work breakdown structure

From Wikipedia, the free encyclopedia

	This article is within the scope of the following WikiProjects:
WikiProject Systems     (Rated C-Class) Systems science portal This article is within the scope of WikiProject Systems, which collaborates on articles related to Systems science. Systems rating: C Class Mid importance  Field: Systems engineering Please update this rating as the article progresses, or if the rating is inaccurate. Please also add comments to suggest improvements to the article. {{#switch:{{ucfirst:systems engineering		Cybernetics|Control theory|Dynamical systems|Dynamical systems|Operations research|Scientific modeling|Social systems theory|Software engineering|Systems|Systems biology|Systems ecology|Systems engineering|Systems psychology|Systems theory|Visualization=

Contents 1 Please list the buzzwords 2 This article was re-written from scratch on Dec 2, 2006 3 Feedback wanted 4 WBS element 5 Human memory 6 Copyright Issue 7 Diagram 8 Common pitfalls and misconceptions 9 Plain English... 10 Examples of STANDARDIZED WBS (for the built environment and offshore oil and gas) 11 The use of abbreviations 12 Work or Product Breakdown structure as main image

[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)

I understand some of your concerns. I have rewritten the introduction and moved that template into the article.

-- Marcel Douwe Dekker (talk) 16:15, 1 December 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)

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)

[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).

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)

[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)

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)

[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)

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)

[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)

[edit] Common pitfalls and misconceptions

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)

[edit] Plain English...

... 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)

[edit] Examples of STANDARDIZED WBS (for the built environment and offshore oil and gas)

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)

[edit] The use of abbreviations

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)

I think the applicable policy would be here, which says that acronym usage is acceptable. The first use in the lead paragraph is meant to function as the explanation.

I do tend to think that abbreviations can be overused in an exclusionary way that makes it harder to read an article, but that doesn't seem to apply to the term WBS here. We've explained what the abbreviation means in the lead paragraph, and we've devoted the entire article to the concept of a Work Breakdown Structure (WBS).

Other terms used here, if used for the first time, or used only once, would probably merit expansion for the initial use. That will reduce the "buzzword" perception. I'll probably even help you do that, when I know enough to do so.

In my experience, the common usage is "WBS", not "Work Breakdown Structure", because it's such a mouthful. Perhaps a good analogy would be something like a DVD. People don't usually expand the acronym "Digital Video Disk" in speech; it's awkward and tedious. Writing is not so dissimilar from speech in that respect. DudeFromWork (talk) 04:37, 14 February 2009 (UTC)

Thanks, this seems like a good proposal, but I have my doubts. I implemented a compromis in this article between mentioning the acronym once, and not using it at all.

I am not from the field, not familiar with that common use, and a foreigner as well... but I am a systems engineer. I have in the past experienced the abbreviation as confusing several times. I am also not a guy who starts online reading an article from the beginning to the end. Reading the abbreviation onze doesn't really help. Now in total I introduced the acronym about a seven times... but with fast online reading you will hardly notice. It seems to me only the experts care...!? -- Marcel Douwe Dekker (talk) 15:43, 14 February 2009 (UTC)

I have listed my concerns above. Would you please explain your doubts, so that we can have a meaningful discussion, and come to a consensus as to what should be done? DudeFromWork (talk) 18:40, 24 February 2009 (UTC)

Ok. I will rephrase. There are different options here:

1. Using only the abbreviation WBS and mentioning the full term "Work breakdown structure" only once, see here
2. Using only the abbreviation WBS and introducing the term "Work Breakdown Structure (WBS)" in every paragraph, see here 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)

[edit] Work or Product Breakdown structure as main image

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)

I have replaced the first image with an image presented in "Systems Engineering Fundamentals. as a WBS. Now I guess you are gointg to argue, that this is a similar image representing a product breakdown structure. It seems to me we have to talk semantics here first. The term "Work breakdown structure" seem to have at least two meanings:

1. the subsystems of a complex system shown in multiple levens, also called a product breakdown structure.
2. the work tasks and activities required to produce something.

I think this article should explain and visualize both meanings. The "product breakdown structure" seems just an alternative term to me. I don't agree with the argumentation, that because there is an article "product breakdown structure", we should give this "Work breakdown structure" article an other content. If these terms relate to the same object, both articles should be merged. -- Marcel Douwe Dekker (talk) 19:42, 17 March 2009 (UTC)

P.S. In Wikipedia we try to keep the talk item titles neutral

Hmmm. I thought the whole point of starting a discussion was to gain consensus before changing an article, especially when the image has been with the article for such a long time. Is that not so? (thanks for the pointer regarding section headings).

In formal project management there are three key elements to control - what you are delivering (the products), the activities required to produce them (the work), and the resources required to do that work (the organisation). Each of these has it's own breakdown structure (of course, the organisation breakdown structure is more commonly known as an organisation chart or organogram).

Work and Product are not interchangeable, and it is a common mistake to consider them to be the same. Under PRINCE2, it is best practice to approach projects with a product-based planning method, so that the focus for the whole project is on what has to be delivered, then you can work back from that to determine what work must be done to achieve it. The tasks on a WBS can be thought of as the same blocks of effort that appear on a Gantt chart, Pert chart, and critical path plan. Likewise, the naming of tasks and activities should include a verb as the first part.

So on a project that delivers a single product and there would be several tasks to produce it, for example: to produce a new payment page on a website, you might need to plan tasks such as elicit requirements, design page, create HTML, develop functional code, test integration with other pages, test interface with banks, gain user acceptance, and release to website.

I would vigorously resist any attempt to merge the two articles as that would not be encyclopedic, but I would be happy to include a section in the WBS article to explain that it is often confused with PBS, and an explanation as to why it is different (such as that I gave above). Greyskinnedboy (talk) 19:00, 18 March 2009 (UTC)

Wikipedia encourages users to be bold when updating pages, see Wikipedia:Be bold. Because you made some objections, I change back the situation for now. This I my idea of good practise.

What your telling here makes perfectly sense, and new to me. It seems to me it contradicts some of the existing introduction I added here, three months ago, see here. Or maybe not. I found in some sources:

• A Work breakdown structure element may be a product, data, a service, or any combination.
• The Work Breakdown Structure is a tree structure, which shows a subdivision of effort required to achieve an objective; for example a program, project, and contract. The WBS may show hardware, product, service, or process oriented

Now you seem to state:

• a WBS only relates to the tasks to be performed, and is significantly different from a product breakdown structure and organisation breakdown structure.

You seem to refer to PRINCE2, but I am not familiar with it. I am surprized by your remark:

• Work and Product are not interchangeable, and it is a common mistake to consider them to be the same...

But again I am not a real rexpert in the field. The current article give a listing of five Pitfalls and misconceptions, and the second starts with:

• A WBS is not a project plan or a project schedule and it is not a chronological listing...

You seem to state the opposite, please correct me if I am wrong. -- Marcel Douwe Dekker (talk) 12:55, 19 March 2009 (UTC)

Again, I have been bold and added an other image, which might visualize your intention. If not, just let me know. -- Marcel Douwe Dekker (talk) 13:19, 19 March 2009 (UTC)

Again, I thought the purpose of the discussion page was (once started) to gain consensus before making further changes, rather than shadowing changes with reactions. There's nothing wrong with being bold if you see something that needs changing (after all, it's always possible to revert if there's major disagreement), but when you have a topic under discussion, the aim of which is to determine an agreed course of action, it undermines the faith of participants in the process if someone just keeps making changes anyway. I started this discussion because I saw something needed changing, and wanted input from other interested parties before changing it.

As to the defintion - a WBS is intended to represent the work/activies/tasks involved in producing something. As I said, "it is best practice to approach projects with a product-based planning method", i.e. decide on the deliverables first then agree what you need to do to create them, otherwise you tend to end up with a huge list of activities which may not all be necessary.

To ensure that we understand each other I need to clarify that I did not say some of the things you say are my view:

• I did not say that a WBS only relates to tasks
• I did not say that a WBS is the same as a project plan (or Gantt chart or similar)
• I did not say that a WBS is chronological.

My comment was that one can consider the tasks in a WBS to be sam as activites in a project plan. You would would normally get from one to the other by taking the tasks from the WBS, combine them with the PBS to form a PERT chart, identify the critical path, then create a project plan around that. Then, on the project plan you would include other tasks to represent the things you need to do to keep a project going, but which don't in themselves contribute to the delivery of any products (NB: you should never put those types of tasks into a WBS). I hope you can see now that I agree that while a WBS should be based on the PBS, we just need some clarity that it should show the tasks required to produce the products (the detail of the WBS article does explain this) rather than just be a duplicate of the PBS (otherwise why have it at all). In a nutshell, the clue really is in the name - it is a work breakdown rather than the product breakdown, but it should reflect and be based on the product breakdown.

Finally, to use a Gantt chart here implies they are one and the same, and will only confuse people who are coming to Wikipedia for the accurate view. Again, the reason I started this discussion was to ensure that we had an image that was not confusing. Please revert the image and, please, let's gain some consensus before changing anything else! Greyskinnedboy (talk) 03:19, 20 March 2009 (UTC)

Being bold in Wikipedia could mean, that you reverted my last move yourself. There is no harm in reverting even a senior editor. It happens at least every week, and sometimes they are right. The main purpose of discussion here is to get the article improved. I usually both try to respond, and look for an alternative. Now I was under the intention you started this discussion, because something needed to change. Now I am not so sure, any more.

Now back to the beginning. You started about a "diagram that more accurately reflects the work tasks and activities required to produce something"... and you wanted to get consensus to replace the first image. Now I am not going to give you any carte blanche, before I have seen the actual image, and you revealed the source of it. Just upload the image, or email it to me, and I can have a look. -- Marcel Douwe Dekker (talk) 13:14, 20 March 2009 (UTC)

Greyskinnedboy, please do as Mdd suggests, and BE BOLD with your edits. There's no need to send anybody private email, just make an honest effort, and if anybody disagrees, we would gladly discuss it with you to reach a consensus. You might try breaking up your edits to allow us to address the issues more piecemeal, if you think it's appropriate. 70.250.238.173 (talk) 01:08, 22 March 2009 (UTC)

I don't know what the background from this latest comment, but if Greyskinnedboy wants to make some minor or mayor edits, he could also create a dummy in his own userspace. For example start a User:Greyskinnedboy/Work breakdown structure page and copy all current content there, and he can do what he wants. I have made dozens of those pages. -- Marcel Douwe Dekker (talk) 01:30, 22 March 2009 (UTC)

P.S. I have been bold and create to dummy article. If you don't like it, remove all content and the page gets deleted automatically sooner or later.

WOW. OK everybody. I started the discussion to check what others thought because there is confusion over work breakdown versus product breakdown, and although I have made many edits, they were usually small ones, so I was hesitant when it came to something larger. Thanks for your support, and for helping me with Wikipedia etiquette. So I have been conducting some research over the weekend, online and through all my project management books, and have uncovered a few points. To do this right, the product breakdown article needs a little changing as well, so if the rule is to be be bold, I think I'll complete my fact gathering then set about the updates. I'll comment back here when it's done. Greyskinnedboy (talk) 12:16, 22 March 2009 (UTC)