Should communication be included in a WBS?

Question

I am trying to create my first WBS for the relocation of my company's offices as an IT person. So far, I broke the jobs that have to be done down to parts:

1 Documentation
1.1. Infrastructure
1.2. Floor plan
1.3. People plan
1.4. Software & build analysis
1.5. Fixed assets

2 Cabling
2.1. Network
2.2. Electrical
2.3. Voice

3 Infrastructure
3.1. Barcode scanners
3.2. Routers/switches
3.3. Workstations
3.4. Printers
3.5. Telephones

4 Services
4.1. File server storage and files
4.2. Print server

5 Testing
5.1. Connectivity
5.2. Workstations
5.3. Phones

I would like to listen to your opinion from an Infrastructure and Network department's perspective for my project. Also, as I have to communicate with several managers, colleagues, office owners etc. do you suggest I should include this as a section in my WBS ? Let's say :

• Communication
  
  • Discuss risk management with manager
    
  • Ask for orders of new network equipment
    
  • Call support agent for overtime costs
    etc.

Communication is a huge sector in moving offices to another place. Should I include it ?

Answer 1

TL;DR

Communication plans or communication activities should only be included in a work breakdown structure if they are the deliverables. Even in such cases, the breakdown should reflect steps in the project rather than daily calendar items of interest only to the task performer.

Define Your Level of Granularity

Your question is not directly answerable because the granularity of the milestones you're breaking down is not well-defined. In common usage, a work breakdown structure is essentially a list of discrete tasks that directly relate to a deliverable or milestone. Some of your communication items don't appear to fit into that category, but it's certainly possible that (in the abstract) some communication tasks might.

The art of creating a work breakdown structure comes from understanding what level of granularity is required, and whether the goal is to communicate about things people need to do or about estimated hours needed to do those things. I generally use a WBS for the former, and use other mechanisms to radiate information about the latter.

Part of good project management is having an effective communications plan. However, it is rare to see the communications plan as part of the work breakdown structure--not so much because it can't be, but because the purpose of the WBS is primarly a task analysis tool.

Your Specific Communication Items

You list the following three items:

• Discuss risk management with manager
• Ask for orders of new network equipment
• Call support agent for overtime costs

All three items seem outside the scope of a WBS because they seem like they each fall below a useful level of granularity for the project. The task performer certainly need to track those individual tasks, but the utility of breaking down "order new equipment" into "ask my boss for permission to call Bob in accounting for the paperwork to send to Alice in purchasing" seems unnecessarily detailed at the project level. Your mileage may definitely vary, though.

In addition, setting aside time in the project plan for risk analysis or risk mitigation is certainly useful, and belongs somewhere in the project plan. However, while WBS items belong in the project plan, a project plan is not simply the sum of WBS items. Semantically, scheduling a discussion is neither a work product nor a useful decomposition of risk management; I'd recommend using a different mechanism for risk management, such as:

1. A risk management log.
2. Adding a risk assessment phase to your project plan.
3. Building risk management into your entire process, rather than having a one-off procedure for it.

The specifics of how you control risk will depend a lot on your project and your organization. Those controls should be part of your time or effort estimates, but (in most cases) probably not your assessment of the steps needed to perform a given task like running cables. Again, your mileage may vary.

Resources and References

As defined on Wikipedia, the following WBS design principles argue against including your communication items in the work breakdown structure:

• Plan outcomes, not actions

  [D]efine WBS elements in terms of outcomes or results, not actions.

• Level of detail

  One must decide when to stop dividing work into smaller elements.

Based on these principles, and for the reasons I described above, your communications items don't belong within the WBS. However, you should definitely radiate information and provide project status. Such activities belong in your project plan; just not in a work breakdown structure.

Answer 2

There are two types of communications, in my view. One as a consequence of doing work, the other as specific outputs or deliverables. For the former, I would not exhibit it in the WBS because it does not buy you anything from a measurable point of view. I would consider this type of communication--risks, meetings, troubleshooting, design discussions--in my basis of estimate for all of those work packages to build up costs and time.

For the latter, I would exhibit it in the WBS as these are outputs that should be measured and tracked. These could include quarterly town hall meetings, newsletters, JAM events, etc.

So the question to ask is, is this communication a consequence of doing work or a deliverable?

Answer 3

In Effective Work Breakdown Structures, Haugan has "Project Management Elements" as a toplevel WBS item and moves all such work under that element. A lot of people don't consider process documentation to be an output of a project -- but it is. Such documents form inputs to other projects and to analysis. They're clearly a tangible output, and so belong in a WBS.

That's not quite what you're asking. You're listing a series of planned activities. None of these look like outputs. They do belong in a plan, but a WBS is about the outputs only.

Answer 4

Given that some communication activities will create dependencies and extend the overall project schedule I think it's essential that the communication overhead is taken into account in the WBS. However, for the most part I wouldn't say that all of it needs to be explicitly included.

One of your example activities is the meeting to discuss project risks. If your Project Charter (or other start-up documentation) includes the requirement for a risk register then the conversation about risk with your manager and/or other stakeholders should probably be a task in the WBS since the rest of the project cannot proceed without it and any changes in the schedule of this activity may push the overall schedule back.

The other tasks feel a bit more like 'day-to-day' activities to me. If you break the work down into such minute detail I think you'll spend more time monitoring and reporting against the work than you will actually doing it. Instead, I'd suggest that the required communications are built into the overall estimate for each task.

I'd generally agree with the other answers here - if there is a tangible output from the communication activity or it can be fairly described as a milestone (e.g. a sign-off meeting) then it should probably be included in the WBS. Otherwise, just build the communication overhead into your task estimates.

Answer 5

My best resource on how to create a WBS is Herding Cats; I've linked to an article on capabilities based planning, but I confess that Mr. Alleman is more thorough than he is succinct. I haven't yet found a terse sound byte that really conveys his notion of how to do planning.

Based on what I've learned from Mr. Alleman, "Communications" is a tool used to accomplish work, and doesn't belong in the WBS any more than "Wire Crimper" or "kneepads" belong in the WBS. The WBS should center around capabilities that are of value to the customer/consumer. Furthermore almost every source I have consulted suggests that WBS lines be structured as "Verb Noun"

Communication would have to either be a verb "Communicate plans to stakeholders", or a noun "Draft Communications", "Send Communications". I think the second would lead to an unmaintainable and inaccurate WBS; I think the first is good, but asking whether communications should be in the WBS is now a non-question.

Answer 6

Communication is an essential part of completing almost every task.

But think of your WBS more along the lines of dividing responsibility and collecting costs. Don't make it too detailed unless you want to track costs in such detail. You will want to assign responsibility and budget for design, build and test of Subsystem A, and function A.1.

Everybody is responsible for some amount of communication. [Ha, ha, even if you keep geeky developers behind closed doors and shove flat food underneath, they will have questions.]

Documents are a major, important method of communicating requirements, designs and test results. The documents for Subsystem A are part of the overall cost of creating it, and I think they belong underneath it in the WBS.