Wednesday, May 13, 2009

What should be put on WBS?

I am writing this post in response to a discussion on LinkedIn titled "Do you incorporate the PM processes into your WBS?"

Technically speaking everything that is being done, has already been done or has to be done on a project must go to WBS. In other words anything that is not on WBS must either not be done or added to WBS.

Please excuse me if it does not sound very polite but there is no scope for what you think and what I think here. What is right is right. WBS must contain no less than 100% and no more than 100% work on the project. It is a living document and is updated very frequently until the closing stage.

It might not always be possible to have a perfect and complete WBS in the beginning. Very often, and particularly in the crisis situation, we might need to call emergency meetings or work on work around plans that were not there in the WBS. In such a situation, the new tasks are added to WBS and the task of adding the tasks on WBS, which is itself a task is also added to WBS.

I am not adverse to the idea of avoiding putting very minor tasks to save time and effort. However, we must acknowledge that that would be a compromise and not the correct way. That might also be the best way in certain situations, but again that will not be the correct way. After all sometimes the correct way is not the best way.

Some of the project tasks that are apparently small in nature can be grouped together into a task of visible magnitude. For instance the "secretary's time to send your package to a vendor" might be grouped with an adjacent task or a few. If it is not, then where else do you show it in the plan? We cannot put it in the schedule if it is not in WBS.

On the other hand meetings are not considered small tasks and must go to WBS without fail.

Coming back to WBS, what is WBS after all? Is it just a planning tool? The fact is that it is more a communication tool. It is used to communicate scope of the project or all the tasks that would need to be done to realize the scope of the products (derivable) of the project, to the stakeholders. After the WBS, supported by the WBS dictionary, is approved by the stake holders, particularly by the customer, the sponsor and the project team, the same document is processed and elaborated to make more than half of the project documents. The cost estimates, budget, final costing and invoices, etc everything is based on WBS.

However, there is a catch. Customer will never be happy to see "secretary's time to send your package to a vendor" on his cost breakdown statement. Customer is interested in how much it totally costs him to send the package. Customer wants to drill down, but does not want to go beyond a certain level of granularity. Therefore, the WBS presented to customer along with the cost estimates or cost break down statement looks a bit different. We do not have to prepare two WBS, but just roll up the activities to the control point level.

Another thing to consider is the two groups of tasks namely value adding tasks and non value adding tasks. What if the customer says, "I will not pay for the secretary's time, why can't the manager spare two minutes to send the package?" What if the customer says, "I won't pay for the project manager, let the programmers manage the project themselves." How do we handle such a situation? The solution is simple; we do not show any task on the cost plan that can be attributed to a single person. We instead show groups of tasks which together are value adding, a derivable or a tangible part of the derivative. Now the question is, is schedule a derivable? Of course it is. Then who says the tasks involved to create a schedule, pure project management tasks, are not shown on the WBS? Is CPI within some range and SPI within some range not a requirement? Then who says the tasks required to be done to achieve that are not shown on WBS?

To conclude, the 100% rule which states that WBS includes 100% of the work defined by the project scope and captures all deliverables - internal, external, interim - in terms of the work to be completed, including project management is no non-sense. It is simple and accurate.


  1. I agree with your sentiments, especially as I have spent most of my life as a vendor PM, and now I am a customer PM.
    The WBS should include all activities, no matter which stakeholder they add value to, but all activities should add value to some stakeholder.

  2. Hello Qazi, the Linked In discussion was very valuable but I cannot agree with your blog. Your "correct way" comes across as you not being clear on the concept that the project is a tool to make the customer or the enterprise more money. If you spend so much time putting "everything" on the WBS that you lose money on the deal you will not be in business very long. Putting tasks on the WBS takes time, time is money, so you better be sure every minute you spend on the project plan adss some value. By the way what does:"After all sometimes the correct way is not the best way." mean?? For the sake of all of us project managers please reconsider your approach and look at the WBS as a tool to achieve a goal and that goal is to maximize profit.

  3. Dear Pat

    Thanks for the comment.

    "After all sometimes the correct way is not the best way," means exactly what you are saying. Though, going by the book, we have to put each and every task on the WBS, sometimes that might not be the best way.

    However, I am not suggesting we remove it either. What I am saying is that a few very small tasks can be grouped together and put as a single task on WBS. Let us consider the example of "secretary's time to send your package to a vendor" once again. If we do not put this task somewhere on WBS, then where will it be put, in our minds? What if we execute the whole project well and in the end discover that the package that was supposed to be sent last month is still sitting in the secretary's closet and the vendor is claiming damages?

    If you are uncomfortable spending time and effort on this small task alone, why don't you group it with inspections? Then the WBS summary of the task will be "Testing, approval and dispatch of package xzy to the vendor," and the WBS dictionary can contain the details. WBS, anyway, does not contain any information on duration, schedule or resource, does it?

    I hope we are on same page now as I agree with you 100% when you say "you lose money on the deal you will not be in business very long." After all we are in such a competitive age right now that sometimes as little as a day of wasted effort can make us loose the competitive edge.

  4. could'nt agree with you more. Simply put WHAT IS IN THE PROJECT IS IN THE WBS. WHAT IS NOT, IS NOT.

    Great Post.

    Also visit Mathew on his blog PM4K at

  5. I would say deliverables only should be a part of the WBS.