10

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 ?

5

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.

  • Your answer includes all I wanted. I am sure now that I am following the wrong way in creating a WBS, but this makes me wonder.. what about "Documentation" and "Testing" ? "Testing" is not a deliverable and "Documentation" must be created for me and not the client. – Radolino Jun 25 '13 at 6:48
  • That's exactly what I've seen on PMBoK, +1! In regards to Roberto comment, I believe that both Documentation and Testing have proper outcomes to be delivered (and then confirming that the work package is completed), not as a repeated action as communication would be. Here's the point: communication would work as a cyclic working package, whereas testing and documentation are self closed working packages. – Tiago Cardoso Jun 25 '13 at 9:27
  • @todd-a-jacobs I came here for my original question. As the reference you gave of the WBS from Wikipedia in the Aircraft System, there is a deliverable Project Management. As far as I can observe, coordinations and communication are part of the planning, but not of the WBS – Maximus Decimus May 23 '18 at 22:21
  • Errata, program management – Maximus Decimus May 23 '18 at 22:59
5

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?

  • As far as I can understand what you're saying is that the WBS's nodes are consequences of doing work ? That means that "Cabling" is something that refers to work that must be done to be completed. That makes sense, but where would you put "Call X for Y" ? If the task list derives from the WBS, then where does communication belong ? – Radolino Jun 23 '13 at 14:22
  • The "Y" is the relevant piece. The WBS should include the Y. So if you want to capture the activities under "Y", maybe your next level down might be "Procure" which would include calling (might take 3 calls instead of 1), emailing, ordering online, smoke signals. – David Espina Jun 23 '13 at 14:43
  • 2
    Calling is the consequence of getting Y. So focus on the output as it relates to the WBS. – David Espina Jun 23 '13 at 14:44
  • This is simply my approach. It makes sense to me and seems to work for me. Play with it and see if it works for you. And also wait for others to opine here. There are some smart folks who contribute daily here. – David Espina Jun 23 '13 at 14:45
  • It's a great way of thinking. I have been thinking the opposite as the only way to work, but it seems I am not thinking outside the box ! – Radolino Jun 23 '13 at 15:09
4

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.

  • 1
    I am actually missing the connecting link between the WBS and the task list. – Radolino Jun 24 '13 at 8:40
  • The lowest level in your WBS is the work package; each Work package results into an output that is either a delverable for your project or an intermediate deliverable that is needed for something bigger. Work Packages are translated into your schedule (or task list) into the required tasks. – Stephan Jun 24 '13 at 11:09
  • Roberto -- imagine that your project is a machine. In one end goes money and time. Out the other end comes a bunch of outputs. The WBS is a breakdown of that output. It's not a blueprint or description of how the machine works: that's where planning comes in. – Jacques Chester Jul 1 '13 at 1:27
2

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.

  • Wouldn't it be the risk register that is a deliverable in your WBS, and not the required discussions to create it? – Stephan Jun 24 '13 at 11:12
  • True. I think I tend to include these kind of 'high level' meetings because (a) they often involve a lot of people and are therefore a scheduling risk and (b) they are often the first step in a large piece of work that will ultimately generate the deliverable. But it is a bit of sliding scale I suppose. I think it depends a little on how decision-making and comms work in an organisation. If it's highly structured you might need a more structured representation of communication. – Willl Jun 24 '13 at 11:41
0

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.