Mark SchwartzProject Manager| Certified Construction Consultants LLCRoyal Palm Beach, Fl, United States
It's me again my friends...How many project managers actually use a work breakdown structure (WBS)? I have been a project manager on very large healthcare construction projects and have never seen another project manager use it. Saving Changes...
MARK A ANNUNZIATA, SrVP/EXPERT CONSULTANCY TO THE CONSTRUCTION INDUSTRY| ROMAN STRUCTURES, INC WELLINGTON FLDammam, Eastern Province, Saudi Arabia
Sirs-
The WBS and use of the Primavera programs is absolutely essential for large Projects. While I have my challenges with who and how the Work Packages are produced (most P6 "experts" are do not have enough field experience to define tasks and priorities) these are absolute and Contract Requirements for USACE and Overseas work. My PMT's deliver EVM data every week at Contract Required Progress Meetings.
I have no idea how a Senior PM can monitor a large (over 200M usd) Project without P6---Microsoft Project is not an alternative.
That's my 2 cents worth!
M Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
May 18, 2016 11:12 PM
Replying to Mark Schwartz
...
Stephane
Usually, a schedule is created from the information contained in the WBS, but as I understand, every project manager has his/her own style and if it works, don't break it.
I think we need to be careful about the 'if it works, don't fix it" mindset. We live in a world where change is accelerating. What works one day, may not work the next. Saving Changes...
I think you could step back a bit and consider residential construction (I'm not familiar with commercial). Break the project down into site prep, foundation, framing, roofing, windows/doors, HVAC, electrical, plumbing, etc. Each of these can then break down in work packages that include such mundane items as number of windows, sizes, by room, number of receptacles/light fixtures, by room, etc. This data then drives the budget estimates for each trade, which then builds up to an initial cost estimate before contingency funding and risk management. Just my opinion, but its how I've experienced WBS in construction.
Agree. Perhaps what is not done is explicitly doing a hierarchical structural representation of the WBS. But ultimately if you have a Project schedule you implicitly have a WBS. Saving Changes...
I believe WBS plays a vital role in success of every other project, either it can be IT / Construction / Product based projects. WBS gives a confidence to PM to access the amount of work involved for a project.
Its easiest path to keep a track of project and what to be done next. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
I use WBS on all projects.
It reduces complexity not only for me but for all stakeholders.
A WBS value is to show all project work structured on a one pager and everybody can see the full picture, even if they only are concerned with specific parts.
I normally start with a mindmap, and some tools offer the format to be a WBS. Saving Changes...
Mark WarnerProject Manager| AURATucson, Az, United States
I've been doing engineering and engineering project management for nearly 40 years. Industries I've worked in include large and complex science projects (e.g., observatories), heavy construction, and aerospace. I have literally never seen a *successful* project performed that didn't have a well-defined WBS from its start. In fact, I have a very hard time understanding project managers that don't take the time to create a WBS. Remember, a WBS is a full accounting of the scope of a project (both product and project scope). How the heck does one put together a schedule, budget, risks assessment, etc without *first* defining what the project is supposed to create? Every good project starts with defining what the project is about, and that should start with defining its scope. Ergo, a WBS is required. (Or, at an absolute minimum, a detailed scope statement.) You can't manage a project unless you first can define and document what it's supposed to deliver. Period.
...
1 reply by Eduard Hernandez
Jul 27, 2022 10:05 AM
Eduard Hernandez
...
Absolutely, I have witnessed similar experiences. WBS is an essential piece of the puzzle. Without it, one can't develop a proper schedule. It amazes me when "experienced" PMs struggle to know where the crtical path in their projects is.
Product Operations Program ManagerBarcelona, Cataluña, Spain
Jul 27, 2022 8:47 AM
Replying to Mark Warner
...
I've been doing engineering and engineering project management for nearly 40 years. Industries I've worked in include large and complex science projects (e.g., observatories), heavy construction, and aerospace. I have literally never seen a *successful* project performed that didn't have a well-defined WBS from its start. In fact, I have a very hard time understanding project managers that don't take the time to create a WBS. Remember, a WBS is a full accounting of the scope of a project (both product and project scope). How the heck does one put together a schedule, budget, risks assessment, etc without *first* defining what the project is supposed to create? Every good project starts with defining what the project is about, and that should start with defining its scope. Ergo, a WBS is required. (Or, at an absolute minimum, a detailed scope statement.) You can't manage a project unless you first can define and document what it's supposed to deliver. Period.
Absolutely, I have witnessed similar experiences. WBS is an essential piece of the puzzle. Without it, one can't develop a proper schedule. It amazes me when "experienced" PMs struggle to know where the crtical path in their projects is. Saving Changes...
I wonder on what basis you assign resources, estimate things and perform risk and procurement?
...
1 reply by Keith Novak
Jul 27, 2022 5:46 PM
Keith Novak
...
It depends on how the WBS is structured. With the classic method developed back in the 1950s for primarily physical products vs. software, the WBS is organized based on the product architecture and aligned to the performing organization. Each section of the WBS is assigned an owner, and how many hours of work are required, which can then be collected by team.
The description of the lower level product is analyzed to determine what it takes to construct the parts. That information is used for make/buy decisions. If something is made in house, a bill of materials is generated for raw materials etc., and whether those are procured in bulk or must be purchased specifically for the product. Cost and flow estimates for procured parts are estimated based on historical data, or gathered discretely from suppliers.
Part level build plans aligned to the WBS are compiled into an overall product level build plan based on required sequencing and part availability. The resource estimates to build things from part level to product level is used to generate manufacturing staffing levels.
Risks may come from many places and overlap various sections of the WBS. They may be identified in the WBS itself, but often there is a separate repository for risks/issues. That may drive additional hours into the WBS, or the labor and other costs required may be covered under management reserve.
I wonder on what basis you assign resources, estimate things and perform risk and procurement?
It depends on how the WBS is structured. With the classic method developed back in the 1950s for primarily physical products vs. software, the WBS is organized based on the product architecture and aligned to the performing organization. Each section of the WBS is assigned an owner, and how many hours of work are required, which can then be collected by team.
The description of the lower level product is analyzed to determine what it takes to construct the parts. That information is used for make/buy decisions. If something is made in house, a bill of materials is generated for raw materials etc., and whether those are procured in bulk or must be purchased specifically for the product. Cost and flow estimates for procured parts are estimated based on historical data, or gathered discretely from suppliers.
Part level build plans aligned to the WBS are compiled into an overall product level build plan based on required sequencing and part availability. The resource estimates to build things from part level to product level is used to generate manufacturing staffing levels.
Risks may come from many places and overlap various sections of the WBS. They may be identified in the WBS itself, but often there is a separate repository for risks/issues. That may drive additional hours into the WBS, or the labor and other costs required may be covered under management reserve. Saving Changes...
Community Champion
