Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.
If I asked you how to bake a cake, you'd probably tell me to mix the ingredients in a bowl, pour the batter into a tin and bake until golden brown. But that's a deceptively simple answer for what is actually a multi-tiered process.
In project management, you must detail every step needed to get the project done and the precise order in which to complete them.
New project managers may not be used to doing things this way. Work breakdown structures (WBS) and schedule network diagrams can help them in forming a project management plan.
A WBS illustrates all of the work that needs to get done to accomplish the objectives of the project, in order of importance. To create a WBS, you subdivide project elements into manageable components and keep breaking them down until you reach the work package level.
A schedule network diagram visually depicts of how all the tasks in your schedule string together. While the WBS shows you how many tasks you have to accomplish, the schedule network diagram shows the order those tasks need to happen.
Most tasks people perform on a daily basis aren't explicitly dependent on the order in which they occur. And when order does matter, we usually engage in that activity naturally.
Our natural ability to skip details and abridge processes can save us time in everyday life. But this "normal" behavior could lead to disaster on a project where some tasks must precede or succeed others. Project managers might lose an opportunity to shorten schedules or see which tasks can run in parallel, for example.
Do you use a WBS or schedule network diagram in your projects?
In my experience, it's not so much the younger PMs that have trouble with this. The older PMs always throw together a vague schedule, never update it, or cost load them.
Just yesterday we had a similar discussion with my customer (a German automobile company producing trucks). We use a standard WBS defined out of a technical point of view.
Here work packages include components with the same date of manufacturing. So the target to homologate the assembly line of an ongoing production dominates the decomposition. The problem is, caused by the grouping of parts with the same manufacturing introduction date there can be 20 and more variations of a component belonging to different trucks, in a single work package.
My customer is of the opinion a work package has to be a summary task in the schedule network diagram.
But this brings an overload in the schedule for you canâ€™t get an overview. Could you give me an advice, how to proceed?
The companyâ€™s information- and production- systems are working with this decomposition, but does that mean the project managers have to do it in the same way?
Would you connect WBS and schedule network diagram?
thanks for any advice...
While WBS and network diagrams are useful, I still believe in simple Gantt charts. They do the job most quickly if the project and the team are not ultra large.
Robert Dudley, PMP, PMI-SP
I am glad that I am not the only one that believes that these are a must.
WBS provide a value to management in general. WBS helps teams think through a project, product or services. WBS can help clearly define a product's requirements or at least validate them to the customer. WBS is more of a tool to help teams develop a better plan and think through a project either from start to finish or phases.
As for network diagrams, I use but I prefer the old yellow sticky notes and a blank wall. To capture the info I use a digital camera to take photos of the diagram so I can then place it in Visio. There is something to be said about developing both the WBS and Network Diagrams without a computer.
Teo Tuang Kai
I have been using WBS for detailed project breakdown so that the team can see a clearly picture of the work scope. However, I found that the stakeholder will not look at the benefit of having that WBS unless it has been constantly reviewed at every meeting and get the team feedback for any scope creep.
Likewise, for Network diagram, the team must also be educated to see how their work will affect the next task especially executed by another team member. This will ultimately lead to delivery.
Constant reviewing of project status will see any schedule slip that will affect the task link in the network diagram.
The WBS and Network diagram must constantly review in every project meeting although we have schedule develop from these predecessors. Iteration is the only solution to keep the project plan in check.
othman ben el aouad PMP
I am fully behind the use of WBS and network diagram. But in my experience the most technical team members see this as overhead like a lot of management process/tools/methods.
According to me the challenge is to get the team motivated in using those techniques by clearly defining the added value of those techniques for them.
I have used WBS many times for small to large projects and even programmes. I am finding however that there are a lot of PM's out there who are more used to throwing activities on a project plan opposed to a correct WBS for the project delivery.
As an example - I constantly hear PM's asking if daily / weekly stand up meetings should be captured in project plans. If you have defined your PBS and subsequently your WBS correctly only those meetings which have a dependency / decision that will affect the completion of the project should be captured in the WBS. (This assumes the WBS is not for a client contract/government bid).
I find today that there is confusion in terminologies for Network diagrams especially when working around telecoms technical teams. I do use these and tailor MS project accordingly as the default does not include a decent network diagram block with the leads/lags etc. But I do find that a lot of PM's I have worked with in the last 7 years never look at or use network diagrams and focus on the Gannt chart instead, much to their own risk.
I have also found however that many people outside of project management have no idea what these are and how to read them. I have had to give presentations to teams on what these are and how to read the details as personnel have found them too confusing.
I will continue to use these but I will always tailor what I communicate and use with teams which may result in not exposing them to those stakeholders formally.
Taralyn R. Frasqueri-Molina
@ Kirk - PMs of a more experienced level should get back to the basics often. It seems if you get too out of touch with the foundational elements of project management, you get a bit careless and tend to cut corners.
@Axel - Your post is great! I have to say much of what you mentioned is beyond me as I'm not in the automotive or manufacturing industry, but I'll try my best.
I probably wouldn't include the tasks in a work package, as just a "summary task" in the schedule network diagram. I would probably separate all these tasks out as their precedence may play a factor in how to approach delivery. The work package isn't just a chunk of tasks that get done at the same time. They are, however, a chunk of tasks that will lead to completion of a deliverable. But how each task is approached, and who you need inputs from, may be different.
When it comes to a project manager following a company's set of procedures to run their projects, I'd probably be more inclined to respect their process and do things their way. However, if I think a better way is available, I wouldn't hesitate to talk to management and get permission to try something out of the normal mode of business.
And finally, yes the WBS most definitely connects to the network diagram, which in turn connects to the schedule. The WBS shows all the work/tasks that need to be done to complete certain deliverables. Completion of all those deliverables eventually leads to completion of the project.
What the WBS doesn't tell you is what order those tasks need to happen in, who you need inputs from, who you give outputs to, and what and when tasks can start. The network diagram illustrates precedence - what order tasks are started and completed in. When you have that squared away, add in your durations and you'll will end up with a schedule for your project.
Chandramohan 'CM' Kannan
The answer is totally based on how much historical data and predictability, you have to manage the project.
If the data you have & predictability associated can only be applied to less than 30% of the project you are managing, start with a WBS, and get to understand activities at the level of the lowest denominator/work package.
If the data & predictability can be applied to greater than 80% of the project, you are good to go with just a Scheduled Network Diagram.
For the in-between cases, it is better advised to have a WBS that at-least covers the areas which do not have historical data or predictability associated to it.
The projects that I have been involved in have usually been small efforts, between 3-9 months. While a WBS was never a part of the consulting agreement with my customers, I have never the less created one for most of our engagements.
The primary intent was not to actually manage the scope via the WBS but to have a visual representation of the scope to engage our customers in discussions regarding the scope. The customers seemed to "dig it" when we showed them a graphical/hierarchical WBS that gave an overview over all the components that we are working on. They naturally understood the "org chart like" approach.
It was also a great tool to show progress. A green box meant that this particular work package was completed, yellow meant trouble and red meant behind schedule. The customers appreciated the simplicity.
So this wasn't necessarily a traditional usage of the WBS on my projects but it was a wonderful tool to help facilitate expectations management.
I feel strongly that PMs must develop the deliverable-oriented WBS with their project teams during the planning process. Having that hierarchical list of deliverables provides an almost magical degree of clarity about the project.
The WBS is then broken down into the tasks necessary to create the deliverables and this becomes the project schedule.
Nice post. WBS is very important, it's essential part of my projects.
@IK - How do you get to a gantt chart without listing your tasks or the order they are going to happen in?
Perhaps you are skipping the step of making a physical WBS or precedence diagram - but it sounds like you are doing the work that's involved anyway, just skipping to the gantt.
@Robert - Thinking through a project is so key! Not thinking it through is what causes a lot of little irritating troubles for my crew. They have great enthusiasm to get the work done, but little patience when it comes to thinking through all the moving parts.
@Teo - I find that no matter how many times I mention something, even if it's not about the WBS or Network Diagram, most of my team will shuffle it to the back of their minds and promptly forget it. Regular, gentle reminders about upcoming work, tasks and outputs that someone else needs are how I manage to keep things on track. You can't get frustrated! Most project management things will be more important to you than your team.
@Othman - Without buy in on most project management processes from my team, my projects would be doomed. What I do is use our past successes to highlight why we are doing something a particular way or using a particular tool. It's much harder to argue with success!
Taralyn R. Frasqueri-Molina
@Peter W - One of the things I regularly remind myself is that all of my wonderful tools and templates are for the most part just for me. Throwing up a bunch of graphs to people who don't understand project management isn't going to make anyone any wiser. Tailoring the info is very important.
@CM - Call me a stickler but I think regardless of how much data you have to manage, or how small a project is, a WBS and Network Diagram, even hand written ones, can only help a project succeed.
@Cornelius - Thanks for posting Cornelius! I know you've been in the biz for a very long time, so I appreciate your feedback! Your approach bring the people back into the mix. It shows that a WBS doesn't have to be a obtuse, un-understandable thing. With a few simple adjustments, a WBS can be used to show progress to stakeholders quite clearly. Sounds like with a WBS in hand, you already have a built in dashboard.
@Lisa - Your comment should be a poster. It's straightforward and simple. When working on a WBS with my there is always an aha moment, when they see very clearly everything that the project is about, what their work will be and that all the hand offs are. Magical degree of clarity indeed!
I have found using WBS and network diagrams useful for my own use but it wasn't until I began using a "modified" network diagram that it became a useful tool for the rest of the team.
I now create the network diagram in the traditional sense but have begun adding the milestones, including the dates. I also include the the resource and time estimates. The disciplines (analysis, development, testing, etc.) are all color-coded so team members can easily see what work belongs to them.
Because we use an iterative approach, this keeps the network diagrams at a manageable size and I am able to list the activities at the same level as in our timekeeping system.
It helps the team visualize the dependencies their work has on others (no one want to be the cog in the wheel), expected completion dates, etc. Since implementing this approach the team has excelled in what they have accomplished, estimates have gotten better, team cohesiveness has grown, and other project sponsors are asking their PM's to do the same.
I guess I use a combination of both. Depending on the complexity of the project, I list either WBS elements or Network Activities in a spreadsheet. I use a column to identify dependencies between elements/activities. Another column can be used to assign responsibilities. Other columns are used to show effort or duration.
By using a spreadsheet, I can share this document with the team, get an individual's feedback, and roll them into a master copy. Quick, simple ... and using a technology almost everyone is comfortable with.
James M Shaffer, PMP
I use a WBS for my projects. It gives my shareholders a great list (along with the WBS Dictionary) of each task accompanied by the definition.
One person mentioned a "deliverable oriented WBS" and I agree with that. Though I work on "in-house" projects currently, I have, in the past, worked with suppliers on defining their deliverables which would give both teams the best organization and expectations.