<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on Apply work breakdown structure techniques to organize a project ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-249373]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-249373/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-05-25T16:25:32-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[RE: Apply work breakdown structure techniques to organize a project]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-249373-2394913]]></link>
        <description><![CDATA[Lots of wisdom in a small space here.  The comments add significant insights, too.  Thanks.What struck me as implicit in the article and the comments was the interplay between the product (the system to be developed) and the project.  Both are systems, and all systems are hierarchical.  That's why they can be modeled as tree structures, such as a WBS.A good WBS is product oriented.  It should derive from the hierarchical model of the product, which is usually called a Product Breakdown Structure (PBS).  The work to develop each PBS element is the core of the WBS.Too often WBSs look like either the organization chart of the team that is to develop the system or the customer's or developer's cost accounting structure.  There needs to be a mapping of the WBS to both of these, but not as a means for designing the project.Finally, as both the article and the comments imply, to the PBS core of the WBS there needs to be added the work needed to create the process-oriented deliverables of a project, such as documents, quality processes, testing, and the work to create the PBS (system engineering) and to progressively integrate the pieces as they are deweloped.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-249373-2394913]]></guid>
        <dc:creator><![CDATA[wspuck@...]]></dc:creator>
        <pubDate>Thu, 03 Jan 2008 10:05:18 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Apply work breakdown structure techniques to organize a project]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-249373-2393985]]></link>
        <description><![CDATA[The one element missing in hour excellent brief is the need for interface control among the sub projects and the work elements in the decomposed project's WBS.It may be old-fashioned - it goes back decades - but the Interface Control Document holds the work to a mutually understood requirement while giving freedom within the subproject and work packages. It should be one fo the first tasks and should be developed when the WBS is developed.Interface control can take the form of an annotated interface diagram, a process description, an IO or HIPO description, or whatever suits the type of project. The factors can be data, interface protocols, processes, etc.; whatever fits.If a basic ICD is not developed at the time of establishing the WBS, and if it is not maintained just as rigorously as the CM docs, error creeps in, and the level of error - the angle of deviation - is not always predictable.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-249373-2393985]]></guid>
        <dc:creator><![CDATA[cook.sandy@...]]></dc:creator>
        <pubDate>Wed, 02 Jan 2008 10:40:33 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Use Structured Analysis for WBS]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-249373-2393928]]></link>
        <description><![CDATA[I've found that structured analysis (data flow diagramming) can be a powerful technique for creating work breakdown structures.  Simply treat the project as a one time process, with inputs and outputs, sources and destinations, etc.  Start with the &quot;single bubble&quot; for the entire project, and include all the &quot;sources&quot; (user needs, existing components, etc.) and &quot;destinations&quot; (system operating environments, trainers, etc.)As you perform the process decomposition, a WBS falls out as a sub-process outline, with deliverables (outputs) associated with each sub-process (= project activities and tasks.)One benefit of this approach is that it's very thorough...if you track the flows properly, everything gets accounted for.  You in fact have a detailed description of exactly what needs to happen to create the deliverables.Another benefit of this approach is that the cross sub-process flows tell you where the dependencies are, so you can easily sort out parallel and sequential processes.It may appear that this is &quot;the long way around&quot; to get to a WBS and that it would be more straightforward to use a more &quot;experience&quot; and template based outlining approach to the WBS, working directly in the final project-oriented formats.What I've found is that after you learn to use structured analysis diagramming for WBS, it's much more reliable, much faster, and produces a higher quality end product.  Structured analysis diagramming can be performed very quickly and agressively, with a lot of confidence, due to its built in consistency checks.  It doesn't make assumptions and it doesn't leave anything to chance.Translating the results back to standard project formats is small change compared to the overall work of analysis and design in constructing the raw WBS.  Jim Johnsonhttp://www.actionmap.com]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-249373-2393928]]></guid>
        <dc:creator><![CDATA[jbjohnson@...]]></dc:creator>
        <pubDate>Wed, 02 Jan 2008 09:25:41 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[WBS: the heart of PM]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-249373-2393719]]></link>
        <description><![CDATA[like this simple and precise approach, and I would like to add few essential things to be remembered:In step 2 Break the overall scope into the underlying deliverables: apply the 100% rule; the WBS should contain all the work packages needed to execute the project, if it is not in the WBS it is not in the projectIn step 5 Estimate the work required for each project: add some management reserve to your estimation to cover the risks of unknown unknowns In step 6 Put the projects in sequence: look for hidden dependencies that may jeopardize your planning if they stay undiscovered]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-249373-2393719]]></guid>
        <dc:creator><![CDATA[jbakaev@...]]></dc:creator>
        <pubDate>Wed, 02 Jan 2008 03:22:00 -0800</pubDate>
    </item>
    </channel>
</rss>

