I would like you to build a WBS for the project you chose earlier in the class. Remember that I asked you to make sure that you had at least 30 task areas in your plan, and that translates to 30 work elements in your WBS. Remember that you build a WBS only down to the level that you will manage to in the project. Look closely at the examples in the book and the lecture notes to get some ideas. You can also do some independent research to if you want. In order to keep things simple, and easy to manage, please build your WBS as a Word document. You will be doing this in "Outline" form.... Ex. 1.0 Top Level 1.1 Next Level Down 1.1.1 Item 1 1.2 Item 2 etc. From a WBS perspective, the requirement of "30 tasks" is applied to the lowest level elements in your WBS (1.1.2 in this example). You cannot count "roll-up tasks" (higher level WBS elements) as part of the 30 tasks, because they are not really "tasks" - they are really group categories. Another example- To be clear, here is the format I am looking for in Word: 1. Project Name 1.1 Next Level Task 2 1.1.1 Subtask1 1.1.2 Subtask 2 Subtask 3 1.2 Next Level Task 2 1.2.1 Subtask 1 1.2.2 Subtask 2 From a WBS perspective, the requirement of "30 tasks" is applied to the lowest level elements in your WBS (1.1.1, 1.1.2, 1.2.1, 1.2.2 in this example). You cannot count "roll-up", higher level WBS elements, because they are not really "tasks" - they are really group categories. Go only down to level 3 in your WBS. This means lowest level element has number ID of the form X.X.X. I do not want a Graphical Version of a WBS (Connected boxes). The top level is the project, the next levl down are the major work areas, the next level down are the subareas under each work area, and so forth. Make sure you number each WBS element (see my ex. on page 8 of the slides and above). Also, make sure that you indent each WBS line, and that the indents line up (2nd levels line up vertically, 3rd levels line up vertically, etc). This will make it easier to read and understand.

An example of someone that did question 2:

Recently, I was part of an effort to help build a Work Breakdown Structure. While it was outside of my role, I was doing my best to assist my colleague who was going through various product documents to understand the workings, breakdowns, and steps involved on each page which we would then nee to repeatedly advise for clients. My assistance was to then go through these documents. The challenge of course was that each topic which was documented was not consistently formatted, nor was the information always straightforward to follow. Additionally, sometimes there were seemingly conflicting pages of documentation which described steps differently. So, for each page, I would have to think about the process being described, and then how to break it down so we could add it to our work break down structure. I would periodically check back with my colleague to discuss and present my progress. I would show the verbiage being used, the potential approvals and steps which would need to be taken for each section or sub-section and ask any questions for next steps or changes I would need to make. From her part, my colleague would then go through and adjust a few items as needed to help get a more final and complete version. From there, she took my document of findings, and merged them into the final copy of the WBS which she was working on. My takeaway from this exercise was to consider a products documentation when building out the WBS for its implementation. Often we look to those who may have done it before, or go online to find a shortcut, but to know the details and steps necessary, it can be helpful to go to the official source and adjust from there.