Hello folks, quick question about how different people approach building WBS.
Let's say you have a new project, to build a web site. It's a small project, scope has been defined and you have a team, next step is to create the WBS.
So, what approaches do you take to creating the WBS?
I'm talking specifically about, what is your approach to the meeting in which you would create the WBS to make it most effective?
One of the methods I have found to be effective is brainstorming. Put together the key players on the project, lock the door(!) and then begin ferreting out the ideas, using sticky notes for each step. Only after all the steps are noted, do I then work with the team to try to put them in order. I strongly believe in the idea that many heads are better than one, as long as there is a strong leadership presence shown by the PM to rein in and focus the ideas. Saving Changes...
Hi all, This is interesting. Creating a WBS can be difficult, especially when no one really agrees on what a WBS is. The Project Management Institute defines it as "A deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project."
That said, most people in IS define it as the set of tasks, in outline format, the constitute the work of the project. It's what we enter into MS Project. Thus, it becomes more of a "To Do List" then "Deliverable oriented."
Because you said in the original post that scope was defined, I'll assume that we are talking about the organized To Do List, instead of the deliverable list.
Fortunately, many many people have already done very similar projects to yours. You can learn from their successes (and failures). My recommendation is to research development methodologies and select one that seems to fit your organization and the project at hand. There are even a few methodologies available here on Gantthead. Then, present the selected life cycle to your "Key Players" to add, delete or change tasks, task order or specific contents. The brainstorming technique is a good way to do this. I recommend the methodology approach over straight up brainstorming because the methodologies presented usually have some measure of success on real projects. It may also take some of the work out of creating a schedule, by presenting dependencies or resource/staffing information.
A WBS can be one of the real sticky points of project management. They either are too detailed or not detailed enough. You, as project manager, have to have a fairly good idea of what you need from a WBS and how you will use it. When brainstorming (in either case presented) the PM must be careful to 1) include the right people and 2) focus the time on the level of detail desired. Sometimes, people can be to high level and not provide enough information for a suitable schedule. In other cases people can be too technical, and not be aware of other activities like communications, negotiations, training, quality assurance or other important activities.
In the end, creating a WBS is more of an art than a science. There are techniques that are better than others, but there is no foolproof way to define a WBS. Get as many opintions as you can afford to, and always get buy-in to the WBS from the team, management and the customer.
The planning approach common to many implementations of Critical Chain-based project management (known in the community as "Network Building") typically starts with a very shallow WBS -- usually about two levels, maybe three for a real complex project -- sufficient to identify the major deliverables, each defined in a detail to reflect specific desired qualities and quantified info associated with it.
The process then quickly shifts to a dependency-centric approach, starting with each identified element in this brief WBS and backing through the chain of anticipated handoffs (and tasks to develop them), always asking about necessity and sufficiency to start the task under review.
IMHO, the emphasis on dependencies is a very effective way of catching things that might be missed -- more effective than thinking in terms of a hierarchical WBS in which it might be too easy to overlook dependencies that cross the vertical/local/partial view that such a view emphasizes.
John ZacharProduct Dev Manager| Association for Project Management (APM)Brackley,, Northamptonshire, United Kingdom
I heartily endorse Frank's posting. Start with the deliverables or products. Using Frank's terminology, create the three level of deliverables, but call it a product breakdown structue (PBS). Put the proudcts in 'dependency order' and you have a (high) level milestone chart.
Identify the activities and task for each product, do some estimates, identify resources, convert to duration, wind the durations into the dependency chart, hey presto you have a high level plan, spread over time, with a critical path identified.
Using a good scheduling tool, like Project, you can assign task to resources / individuals / groups say a couple of months at a time.
Finally, brainstorming, locked rooms, brown paper and postits is the most successful way I have found to get the planning job done. Saving Changes...
Thanks for the agreement, John. Like many things in our little world of Project Management, there seems to be a propensity to make things more difficult than they have to be.
But then I guess that's what certification is all about. ;-)
One comment on your process, however. I would identify the dependencies first, which can then be split further or combined to determine appropriate resourcing. Then the resources (or their reps) can help with the duration estimates.
If you're interested in WBS, the Project Management Institute (www.pmi.org)has released "PMI Practice Standard for Work Breakdown Structures." They have excerpts available on their site at no cost. PMI members can access the full book in their members area. The full book is also for sale in their online bookstore. Saving Changes...
As a project manager I believe in the approach Frank emphasises. Basically, understand what your going to build, what items are dependent on each other, how your going to build it, and then fill in time estimates for each task.
When I start using terms like PBS and WBS and how to generate them I look like a great project manager and everyone here thinks I'm on top it. But I haven't done anything and we aren't headed for success.
I need the support of the development community to create both the PBS and WBS. Also I need them to have solid methods and processes for building the product. Often they don't understand project management activities or PM deliverables.
Assuming that the development community has a solid understanding of the methods and processes the PMI and other sources can help you complete your deliverables based on what they can tell you. If the team your working with doesn't have a solid understanding of methods and processes to be used I recommend the following.
1. Work hard to define the product and be sure that everyone understands what the product will be when it's completed. (DEFINE DONE.) 2. Help the development community understand the project life cycle. I know that you'd think professional developers would know this but as a community they may not agree nor understand each of the deliverables they are to produce. (DEFINE STEPS to get done.) 3. Use the system architecture document as the baseline PBS. Work with the developers to fill in any wholes left in the architecture that are things to be worked on. (DEFINE WORK NEEDED TO GET DONE.) 4. Review the components to be built with the team members and get agreement on the dependencies between components. (DEFINE ORDER OF WORK TO GET DONE.) 5. Breakout the components into a work flow based on the identified dependencies. 6. Identify the appropriate level of person to work on that component. 7. For each component identify at least the following activities and the estimated labor for each. A. Analysis. B. Design. C. Implemenation. D. Validation. E. Verification. 8. Revisit all dependencies and resolve any open concerns or questions.
Once I get to this level I have the WBS I work from.
I have found that a variety of group discussions and one-on-one sessions are needed to get all of this accomplished.
I like your process, David. It closely parallels the generic "network building" process used by myself and many other Critical Chain oriented practitioners. I particularly thank you for the detail in your step 7. It's a nice summary of generic subcomponents of common IT tasks. Saving Changes...
