WBS: why is it important & why it is not important?
Can somebody post their view or opinion based on practice, why is it that WBS is not important or why is it that WBS is important in managing project?
I appreciate all ur input.
creating a wbs forces you to think about how you are going to dissect your project and organize your project into meaningful groups or packages of work.
It is a way to group your work so that people can understand the where's the what's and the how's you will approcah the work.
for example if you were looking for an activity in the 2rd floor of Building B and the activities were not group by building and floor it would be very hard to find.
Also by using a wbs you can collapse work and summarise work more easily.
I love a good WBS!
See below link to one of our newsletters.
I started using activity codes even before WBS functionality was available. And I still use them, precisely for purposes as you mentioned - eg filtering the plastering items etc. And since I started using these things from DOS days, I also make use of the characters in activity ID to represent various things. And as you correctly mentioned, it is also possible to get those functionalities from few characters in the activity description.
In fact, the best way to input your coded information is in the activity id. That way, the information is "in built" and cannot be changed easily.
All these things including searching and filtering (eg for filtering for certain characters in activity id or description) work well when everybody is disciplined in naming and coding. And as long as one person is doing all these things, everything works perfectly well for him (as it does for me and you). But when you are integrating programmes from various contractors, it is not easy to excecise those rules with planners from various firms.
WBS concept is as old as project management but its functionality appeared relatively late. Even in P3 3.1, WBS is still optional function that appears the same way as acivity codes. And some people still dont use it because 1) it is optional 2) activity codes seem to do the same job and 3) they are more used to activity codes. But even in P3 3.0, WBS code can do things which activity codes cant.
For example, you can have WBS activity and it does not need any links as in hammock activities. And this WBS activity can summarise all the activities which have the same WBS code. When you need a high level programme that shows bars in the same line as activity description (activity code roll up bar appears one line below), you can just filter for WBS activities and you get very good presentation. And the list goes on.
And when you start using P3e, WBS is no more optional and it appears more different than activity codes and thus makes it more apparent. But activity code has more functionality in new programmes as well as you can have second level of codes within same acitity code. And these lower levels of codes work exactly the same way as WBS does. So you can have work breakdown stucture as well as ANY breakdown structure using a single code.
But as long as you have to use two or more actity codes (as you have to do in P3 3.1 and earlier), to make your work breakdown structure, it is far more easier to do so using the in built WBS coding. (And you can of course, still use activity codes, for other functionalities).
I can therefore sort as activity description contains plastering and all the activities drop out. Now If I have also coded for floors and towers I can organise so the towers and floors show up so I know where I am.
That means I need to code in a tower and a floor with each activity, thats pretty easy cos I can copy and past this info.
If I am really smart when I copy and past the fragnet I can add some alpha numerics at the end of the ID ie 100 activity number from fragnet then T1 (tower 1) then F1 ie the id is know 100T1F1 this helps in that I can sort all activities in tower 1 or floor 1 or whatever so by using the ID and the description almost without touching the codes we have a pretty robust sorting catergory. In turn when you can sort in this way logic application and resource balancing becomes much easier.
Lets go back to the plastering scenario we now have all the activities, so linking floor to floor or globally copying resources is easy as is levelling them because you can see whats happening and more importantly so can everybody else.
In this way you can tell your subby exactly what he needs.
I am not saying you cant do it with WBS and of course you can what I am saying is for a great deal of what we do in building and Civil Engineering WBS codeing is excessively complicated.
Im Currently using Hierarchical code structures to help with the application of the cost accounts from our cost tool. I simply apply the codes to the activities and then group and sort with totals and balance my activity budgets.
So you can use code fields to give rudimentry totals for Units.
This process has helped me immensley as when I started with this company 9 weeks ago there wernt even any baselines in the projects and they were using units % Complete and just adding extra hours to the remainings by multiples of 10 or 50. They even expected to be able to resource level with this data.
Activity codes look good and seems to show what you want to show only when data is organized in a particular way (eg phase, location, contractor etc). So it is very much a Layout depedent method.
WBS works no matter how you organize your activities. And you can have WBS activity (in P3 for example) which summarises all the activities which have the same WBS code no matter where those activites are located. There is no such functionality available for activity codes.
Furthermore when you organize activities with acitity codes, you will always end up with groups with no names. Planner would understand it but there would be many would be questining it everytime they see it.
So when you want work breakdown that really add up to whole project, use WBS. It is that simple. And use activity codes for other organizing and filtering purpose.
I suppose WBS & Codes are lying on the same concept, so why bother? youre not showing codes on your schedule anyway.
Dont let anybody walk away with the idea when you have explained something "gee I wonder what he is smoking"
Often in fact more often than I care to remember I dont employ planners because they cant do their job but because they cant explain what their job is.
Remember we are planners, that makes us somebody who assists the process not somebody who actually does it, so go and assist the person doing it by understanding what he wants not what you feel you should give him.
The WBS structure is simply an end to a means.
The end is being able to provide BAC, ACWP, ETC, EAC & EV for particular portions of the project.
The WBS is simply the most widley used method of doing this, and as a consequence comes as a standard part (or code) of most planning/scheduling software.
As far as codes go - well the world is your oyster.
As far as how to, and what size, and by what method you chose to quantify and divide your project up, its really up to you..... However you should document what each structre is for and what assumptions were made to arrive at the particular structure.
CBS - Cost Breakdown Structure, ETC.
Again I will say its limitless to how many you can have, but you should document what it is and how you came up with it.
That way when youre asked to explain a code field that you thought was a good idea at the time - Your manager doesnt walk away with the "I dont know what that guy was on about" thought in their head.
this is very simple! you use WBS or Codes to make your Project become "Measurable" either in a summarized form or a detailed one. But how do you put a certain unit to a summarized deliverable? Isnt it Lump Sum (LS)? and how do you define Lump Sum? are you gonna need WBS or Codes?
While the Explanation is well "dry but clear"
I think all would benefit more if you provided sonme clarity with examples.
As I have mention before WBS development can be viewed as the process of grouping all project elements into several major categories, normally referred to as Level One; each one of these categories will itself contain several subcategories, normally referred to as Level Two. Alternately, and more accurately, developing a WBS involves dividing the deliverable items until the project has been divided into manageable, discrete, and identifiable items requiring simple tasks to complete that, when combined, constitute the project deliverable.
Logically is to keep dividing the project until the elements cannot realistically be divided anymore and may vary from organization to organization or may even vary among project managers within the same organization.
Each level of detail contains not only organization specific, but they also are specific to the nature of the deliverables involved in each project. Similarly, the degree of detail at the lowest level of each branch must be in line with the size of the project and in conformance with the organization’s operational philosophies.
Ideally, there should be some uniformity and consistency in the WBS. To achieve this uniformity, all children of the same parent must be developed based on the same division basis.
Usual practice of WBS are using three division levels which are “Deliverables oriented (Structure or products, functional system, physical area and proof of capability)”, “Schedule oriented (normally referring to a task or activity and sequential/ phases)” and “Resource oriented (disciplines, administrative units and financial accounts)”.
So again, no matters how you do it by codes or groups fields or using the WBS field as long as you define the structure into manageable level and represent the project deliverable that will contribute to success of the project.
Most of my work is in building construction, so maybe the fact that I like codes better is biased by my work.
But if sometimes you need to see activities organized by floor; sometimes by trade; other time by trade within each floor, etc. There’s no way to do that except with codes.
Do other lines of work have the same need or is it enough for you to squeeze into a rigid WBS and limit reports and analisys to that single point of view?
what I believe it says is that progranmmes should be structured in such a way as to enable sorting in a logical and affective manner thus enabling the team to ascertain an accurate picture of the progress of the works and the elements that make up the works.
"for hard planning thinkers"?? they dont know how to use codes?
WBS show the heirarchy of Scope of work and deliverables.
WBS is the standard for PMI, PMP, Planning Professional.
It is very clear in PMI influence or way of project management in general and planning in particular way of managing project.
So for hard planning thinkers, WBS is the preference.
I think the need and importance of structure in a schedule is clear and proven. The point now is how.
I prefer primavera codes over WBS or outlines. Codes are much more flexible and let you organize activities in different ways to analize different aspects of a schedule. WBS an outlines are rigid.
Of course you can use both at the same time, but unless I´m forced by a client, I don´t use a WBS, but codes.
Its just a simple divide and conquer technique. It a way to go from general to specifics. Its like writing a book first you have the outline the going to the details and contents.In a way it helps in organizing a project and simplify the job of a planner.
Breakdown Structure - Work, Cost, Organization..whatever it is..It is important! I think nobody is using a one liner schedule!
Just to explain more on WBS. As I have said on the other thread (Work Breakdown Structure is a results-oriented family tree that captures all the work of a project in an organized way. It is often portrayed graphically as a hierarchical tree; however, it can also be a tabular list of "element" categories and tasks or the indented task list that appears in your Gantt chart schedule). Meaning it can be shown on a different approach or style as long as it became meaningful and useful to other member of project management. It defines as a level of schedule to make it more sensible and manageable. It is used to define the project objectives with sufficient detail information into more detail groups of scope or task. Some planner/ scheduler used activity codes as their WBS and others are just the first 1, 2, 3 or 4 character of their activities.
Proper schedules are using this technique according to their own methods so they can level their schedule to more manageable levels.
On my own view “schedule without the proper work breakdown structure is going nowhere or meaningless as its does not show the sensible picture of the project”.
Any serious program must have some kind of organization so it is usable for control.
WBS is one way, but theres also activity codes.
The more detail that you want to see (monitor), the more important the WBS. A formal and logical structure helps capture the project data (activity type, resourcing, costing, progress etc.) in the most appropriate "pigeon-hole".