After this you can define sub-task so that you can control and monitor the WBS. Saving Changes...
RAJESH K LProject Manager, PMP| Bharat Electronics, Bengaluru, IndiaBengaluru, Karnataka, India
I think guidelines to WBS in PMBOK to be referred. WBS to be identified to the level to which PM shall track / monitor. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
There is also a new Practice Standard for WBS, edition 3 from 2019. The stated purpose of a WBS is to help the team to overcome large uncertainties. That means it reduces complexity and is meant to simplify communication. I therefore recommend to have the WBS on one sheet of paper A4, with at most 6 levels down and 8 elements across. And put it on a wall.
After the WBS is agreed, the activities / tasks can be created and put into a schedule.
There are several ways to structure a WBS, these can be combined and all of them should be tried out to arrive at the WBS that reduces complexity.
The ways that were mentioned here: a) structured along type of work, may be good for team members with different roles to easily see what they are expected to work on b) structured along the product of the project (if that is considered complex, but be aware of tools you mst build that are not delivered) c) Sandeep's way along the phases/timeline Saving Changes...
Paul AzanorProject Consultant| Lagos NigeriaIkoyi, Lagos, Nigeria
Best practice is to get the deliverable / product based WBS ready before the scheduling process.
The second level of the WBS should be decomposed into the main project phases. i.e. something similar to the first option. Saving Changes...
Tamer Zeyad SadiqAssistant Cost Manager| Turner & TownsendRiyadh, Ar Riyad, Saudi Arabia
When I create my project schedule, I decompose each deliverable to a point where I feel comfortable that there leaves little for my Superintendent/Foreman has to guess. I have a procurement and programming schedule as well since. I build these into the top layers of the project schedule so that I can close down my summary tasks. I distribute them to the functional leadership over our procurement and programming teams. The rest of my project schedule is a typical decomposition of the project deliverables as I stated earlier. In most cases, my project schedule includes Pre-Project, Definition, Engineering, Execution, Commissioning and Project Close as major Summary Tasks. I break down each of those. Saving Changes...
I find in these situation the more detail the better and if you have it use short hand and acronyms of most common used words to increase word count. Otherwise you are going to have calls and email asking you to explain what this and that means. Also you could go over the schedule briefly at project meetings to see if anything has been missed. Microsoft Project does allow you to increase your schedule size from 100 lines to 200 lines effectively doubling the amount of information that you can store and view. Saving Changes...
Paul AzanorProject Consultant| Lagos NigeriaIkoyi, Lagos, Nigeria
If best practices are followed, as in WBS, WBS Dictionary, Project Scope Stmt. before developing schedule, then needless to worry about phone calls and emails to clarify the schedule. Saving Changes...
J. Jorge TorresElectrical Design Engineer| Techint Engineering and ConstructionLeón, Guanajuato, Mexico
Agree with Thomas Walenta, strongly suggest you to review WBS recommendations. For the options that you enlisted, I would go with B, because you have an easy view of critical aspects and the opportunity to break down easily according to milestones. Saving Changes...
