Probably the most important method for the analysis and plan phase for UX project in my opinion, is a work breakdown structure. We're going to spend some time looking at what a work breakdown structure or a WBS is, when you would use it, what the best practices are for creating them. Looking at some tools for creating WBSs, and then also considering some other uses that you can use the structure for once it's done. The Work Breakdown Structure is not difficult to do, can take anywhere from a couple of hours to process over days, again, depending on how complex the project is that you're trying to plan for. It's a great tool for planning, it's also good for communication. It's basically a hierarchical decomposition of work so that each level in a work breakdown details out more and more of the deliverables that you're going to be creating. Your goal in a WBS is usually to define the total scope of a project, and again, each level deeper in the project represents more detail around what the work is. The process originally came from the DOD and NASA. Here's a picture of one, this is a generic work breakdown starting with projects, going into phases, going into deliverables, sub-deliverables, work packages, activities, tasks, sub-tasks. Your WBSs probably won't have this many levels of detail but you could have, and this is the way WBSs generally look in a graphical presentation. You can also do a work breakdown as a textual or outline view, so here's that same WBS presented with a line numbering scheme to represent the elements in the structure. Again, depending on how complicated and how many levels you have this might not be a good way to represent it, but if it's a simpler structure this might work out. So why did WBSs matter? If you go through the PMI trainings to work on project management, the thing that you will learn is the most important thing you have to control is deliverables. And what a WBS does for you is it helps you figure out what deliverables are, who's going to do them, when they're do, what do they cost, and how do you know when they're done. And by identifying the project scope and deliverables, you have a much better chance that a successful delivery. The WBS process also can provide for team building and buy in when you go through the project in detail and you recognize who's doing what, and you talk about what it is they are delivering, you can get to a point where everybody is in agreement on what it is you're going to do, and again it increases the chance of success. The other thing a WBS can do for you is reduce scope creep. If you create this WBS and you say what it is you're going to do and also what you're not going to do, it provides a baseline for future changes to the project. And finally by using the WBS in these manners, you're controlling your deliverables, and that's really the goal that you have for any project. So let's go through some best practices for creating a WBS. The focus should be on scope and deliverables initially you shouldn't worry about time or resources, who's going to do what. You really just want to specify what has to be done initially you can come back later and look at the who's, and the whens, and the cost. There's a rule called the 100% rule for WBSs and again, what we're seeing here is a WBS should represent 100% of the work. Anything that's not represented in that WBS isn't going to be done in your project, and it should be considered out of scope. A project WBS ideally will cover all the cross functional things that impact the deliverables, so that could be things like ordering equipment or waiting for someone to approve something or what have you. You could also include project management tasks like presentations and reporting. You want to capture all the work. Ideally the lowest level of the WBS should be the elements that you're going to manage, estimate, and measure. Usually you want to represent these things by nouns, what the deliverable is. And each of the elements represent a single deliverable, whether its internal or external, internal to the project team or external to a delivery you're making this on. The things that are highest costs or highest risk, you should break those down enough that you feel that you can control the parts of those deliverables. Another best practice for WBS is the 80 hour rule, this rule says that your low level tasks should be no more than 8 to 80 hours each, and the reason for that is slip. If you slip a task that's two weeks long, you probably going to slip it by a couple of days. If it's a task that's three months long, slip could be much larger, and therefore your overall schedule and your work becomes more uncertain. You may have to think about how to break each level into elements, the suggestion is five to sevev for readability. If you think back to that graphical display, you might have to do different types of breakdowns to make that all work and make it readable. Like most project documents, a WBS should be version controlled because eventually it will change and it should be reviewed regularly. You don't want to create a WBS in vacuum. You want to create it with the project team so that everybody can have input about what you're doing and how you're doing it. And a WBS should come before any kind of a schedule again, figure out the what before you figure out the who, and how long. How is it organized and presented? Well we talked a little bit about the textual outline versus the graphical outline. It really depends on the tool you're using. So the question more is, how much detail do you have to have in it? And really, that's up to you, a lot of times especially for a user experience effort, you might just look at activities, tasks and maybe some subtasks, but you can make it deeper if you need to. You could include phases and projects and etc. What you want to do though is just make sure that the lowest level of the diagram shows the things that you're going to be keeping an eye on, and you're going to manage. There are a lot of tools out there for making a WBS, certainly one way to do it is a white board and a camera, and this is a great way to do it if you're working with a team. I've used specialized app called WBS schedule pro quite a bit. I have a link here for it in a picture of it, really great tool for putting together a nice graphical view and it integrates with Microsoft Project if you have to run that WBS into a Gantt chart for control. There are web tools out there, there are Excel templates I would look at the Smartsheet templates for your class project. They're very easy to work with, to create WBSs, visio. Microsoft Visio has a brainstorming diagram, there's also tools called mind mappers that create a diagram that's very similar to a WBS. You might want to take a look at those to see if it works better for you. It's very easy to take that bottom layer of tasks from a WBS and create the stories or cards or deliverables that you're going to attract in an agile, scrum or a Kanbun. Once you've got those tasks now you can start to do estimates of time, of cost. For estimating time, the recommended way to do it is T shirt sizing. Set effort durations to small medium large, and extra large and this is up to you depending on the size of the project may be a small is a day, medium is two or three days, large is a week, extra large is 2 weeks. Then you can assign those durations to the individual tasks, and you can roll the entire WBS up to figure out what the timing and the project will be. Tasks can be easily assigned to resources and you can see where you're missing resources for a project. In use, the WBS again is more accurate if the tasks are small, the 8 to 80 hour rule and they're owned by one person. They're great for estimating again, you can use the T shirt sizing for timing. But you could also do a cost roll up if you need to figure out how much money you're spending for individual tasks, either in terms of people, or equipment, or what have you. You could fill that out and then roll it all up from the bottom, and you'll get a great preliminary budget. They're really excellent for alignment on the actual work that you're going to be doing. Especially when you can walk through it with the stakeholder and let them know that this is what you're planning to do. You can and I have used the WBS to track progress without any other tools. But usually in most projects you're going to be tracking the tasks in a Scrum, or Kanban, or in a Gantt chart. Again, for more information, take a look at the project management institutes WBS practice standard. Also, out on the web, the CDC, the government agency has a really nice WBS usage guideline and some good templates and examples. The whole point of this process is controlling deliverables. And again by doing that, getting to a successful project delivery. So, thank you.
