“Would you please help me print out this ‘WBS’? It won’t fit in one page. I have a status meeting with the Sponsor in 30 minutes!” a colleague of mine approached me and asked. “This is not a WBS! It is a Schedule in a form of hierarchal structure.” I said sarcastically when I saw her WBS. She listed all project deliverables, and listed all activities below each one. This is not what a WBS is intended to be used for. Does your sponsor or client need to know how you’re going to complete each deliverable? Do you really need to present a 100+ boxes on your WBS to get your sponsor agree on what’s included and what’s excluded in your project scope? Absolutely not.
The primary benefits of having a WBS in any successful project dictate the need to keep it simple. Firstly, a WBS depicts the boundaries of project scope. A client or a sponsor can easily sign off a well-structured WBS as it includes all project scope and excludes whatever out of scope. Secondly, it ensures that effort is not wasted on unnecessary or out-of-scope deliverables. That is, if the WBS lists a redundant Work Package, this would require extra resources, time, and cost. Finally, a good WBS can be used on a project dashboard to communicate scope (changes) without confusing stakeholders with scores of activities needed to complete deliverables. The latter point is actually the key to build a good WBS. A WBS does not include activities; it only lists deliverables down to the Work Package level. Leave listing activities to the Project Schedule. WBS is composed of tangible deliverables without activities whereas a Schedule describes all activities required to complete those deliverables outlined in the WBS.
From another perspective, a WBS represents the project lifecycle that is different from the PM Process Groups. WBS is not used to chart Initiating, Planning, Executing, Monitoring & Controlling, and Closing of a project. These are process groups that describe how you manage a project from start to end but not what the project includes and what it excludes (scope). On the other hand, a project lifecycle describes the phases into which a project evolves to complete each of the agreed upon deliverables. Hence, one of the most commonly-used WBS’s is breaking down the project into phases, deliverables, sub-deliverables, and Work Packages that collectively constitutes the overall scope of the project.
If WBS represents the lifecycle, how should PM processes be represented as part of the project effort? Project Management is actually a phase in the WBS that has its own deliverables, sub-deliverables, and Work Packages. Taking a software development project as an example, the WBS shown in figure (1) is what is expected to represent the lifecycle and scope of the project (WBS in its initial structure for illustration purposes).
As shown in figure (1) the Analysis phase of the project consists of two deliverables: Glossary, and Requirements Specifications. The SRS deliverable consists of three sub-deliverables: Use Cases, Supplementary Specifications, and Reporting Requirements. The sub-deliverables can be broken down further into Work Packages (components that can be estimated for required time, resources, and cost). Use Cases, for instance, can be broken down into more specific use cases discussed with customer or user of the system under development.
Although WBS is progressively elaborated (built in increments as project progresses) a PM should make sure her WBS is complete and constitutes 100% of the agreed scope. All phases should make up the 100% completeness of the project. And all child deliverables under each phase should make up 100% of the parent phase, and so on. This is one way to ensure a WBS, so scope, completeness.
After a WBS is structured correctly, a project schedule can be established. From each deliverable or Work Package in the WBS PM with her team members can list the required activities to build each component. Time, resources, and cost are then allocated to each activity of the component after which a project schedule (e.g. MS Project Plan) is generated and schedule baseline is then set.
Pingback: Tweets that mention Work Breakdown Structure Made Easy « Mohammed Barakat's Blog -- Topsy.com
Hi
Good tip,
Which tool did u use to draw the WBS?
Another point,
U mentioned Requirements Specification , but I would consider Requirements Engineering which can include Elicitation ,Prioritization (triage), Specification
and in Specification at can have Design, while u preferred to put Design as a seprate from Req Specif.
To me Design is also a tool for analysis , thats why it looks better under Req Spec.
And Design can also include Prototyping which can be initial phase for Construction.
What you say ?
Hi Soren,
Regarding the tool I used is a web-based WBS Tool that is actually FREE. You just register (or even without login) and use it forever. Visit this link (http://www.wbstool.com )
Well, regardless of how your WBS is structured it should be broken down into phases then deliverables. In the WBS shown in this post I considered Analysis as one phase that can only be completed by delivering the Software Requirements Specifications (SRS). If you want to use Requirements Engineering then I would say it is phase (1.1) that is broken down into sub-phases like Requirements Elicitation (1.1.1), Requirements Analysis and Documentation (1.1.2), etc. but these are not the lowest levels of your WBS as each one of these sub-phases should end up with a deliverable such as Requirements Document for sub-phase (1.1.2).
A project lifecycle, and hence the WBS, can be tailored to each industry or each organization methodology, so you can build your WBS in the way you see suitable to your business, but this post gives guidelines on how to breakdown your project into phases and deliverables.
Hi,
I have just received this post via ISCoP newsletter. One thing makes me think in the picture. Why are requirements specifications separated from the project management? Requirements specifications should be done by analysts, but they are also important part of the project management, that is “collect requirements” process in planning process group.
I would be very grateful for answer on this matter.