Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Work Breakdown Structures (WBS)
WBS and OBS intersection
As a project manager, have you ever applied the WBS and OBS intersection technique? Why and how?
Sort By:
Engineering projects are often broken down based on the system level architecture decomposition of the thing to be produced rather than by the organization structure and skills.

I might have a hydraulic system design project that requires mechanical engineers, electrical engineers, supplier management, test and evaluation, etc. Those functions are in different parts of the organization so while the WBS of the project has a branch for "Hydraulics", the work under that branch of the WBS can involve many teams outside the OBS branch for "Hydraulic Systems" so the PM must understand where that work is actually being performed.

The reason those related tasks often don't go under the WBS for electrical, SM, etc. is that it's easier to see if you have a complete plan for the system of interest if the related tasks are together, rather than having to piece orphan work statements together and try to identify whether they form a complete plan or are there any gaps.

While the PM may be managing from a system architecture view, each of the organizations have their own people and budget, which they manage by OBS rather than WBS so different managers are looking at different views, both of which must agree.
...
1 reply by Steven Draheim
Mar 10, 2020 8:29 AM
Steven Draheim
...
Boom! Keith just educated me! Thanks!!!
Each time because without it we can not do planning, monitoring & controlling properly. A tool can be used is RASCI matrix.
I would say the information is needed each time, but a mapping exercise is not required each time. A new project on a mature program will often use an existing WBS already mapped to the OBS. If the project requires a new or revised WBS or OBS, then it is necessary to identify who does what work.
Jan 23, 2019 11:57 AM
Replying to Keith Novak
...
Engineering projects are often broken down based on the system level architecture decomposition of the thing to be produced rather than by the organization structure and skills.

I might have a hydraulic system design project that requires mechanical engineers, electrical engineers, supplier management, test and evaluation, etc. Those functions are in different parts of the organization so while the WBS of the project has a branch for "Hydraulics", the work under that branch of the WBS can involve many teams outside the OBS branch for "Hydraulic Systems" so the PM must understand where that work is actually being performed.

The reason those related tasks often don't go under the WBS for electrical, SM, etc. is that it's easier to see if you have a complete plan for the system of interest if the related tasks are together, rather than having to piece orphan work statements together and try to identify whether they form a complete plan or are there any gaps.

While the PM may be managing from a system architecture view, each of the organizations have their own people and budget, which they manage by OBS rather than WBS so different managers are looking at different views, both of which must agree.
Boom! Keith just educated me! Thanks!!!
Each WBS element should have at least one OBS element, usually the owner. Each OBS element should have at least a WBS element. (If they don't then they are not project stakeholders.)

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Brevity is the soul of lingerie."

- Dorothy Parker

ADVERTISEMENT

Sponsors