Section 9.2. Creating the Work Breakdown Structure

9.2. Creating the Work Breakdown Structure

If you recall from your earlier work, you developed three to five high-level objectives or deliverables for the project. You also defined functional and technical specifications. If you didn't create specifications that were defined, discrete, and measurable, you need to do so before you head into this detailed planning work. If you have a well-defined project, creating the Work Breakdown Structure will create a much clearer and more detailed picture of the project. If you haven't created defined, discrete and measurable requirements for your project, your WBS will wander and you'll most likely experience scope creep right out of the gate.

9.2.1. Quality and WBS

One key point to remember as you begin creating your WBS is that you should refer to your project scope and your project quality plan. The scope of the project will ultimately be defined by the WBS, so keeping scope in mind as you create your WBS will help keep you and the team focused. Also, keep in mind your quality plan and quality metrics. These can be used in two ways. First, you may want (or need) to define additional tasks related to quality planning, quality control, or quality assurance. Second, you can define entry/exit criteria and/or completion criteria (both explained in a moment) for tasks based on quality standards or metrics. Quality is built into a project from the ground up and as you develop your WBS, you should keep your quality goals in the forefront of your mind. By keeping an eye on quality during this planning phase, you will continue to build quality into the project rather than have to come back and try to add it later.

9.2.2. Breaking Down Your Project

If you have very clearly defined project parameters, creating your WBS will not only be easier, but the end result will be a breakdown of work that maps to your project's requirements and outcomes. Let's start by using a generic example to explain how we're going to break the project down into its components. To use a very tangible example, if you were going to build a house, your three to five objectives might be:

House plan
Foundation
Framing
Exterior
Interior

You know that each of these high-level objectives or deliverables has a set of activities that must be completed in order to deliver that element. For example, the foundation deliverable might include surveying and marking the property to determine the correct position/location for the foundation. The foundation area must be excavated and forms to mold the concrete must be built before the concrete is poured. These are discrete elements of work (tasks or work packages) to be performed in order to deliver the foundation part of this plan.

The same holds true in IT project planning. Each of your major deliverables has work associated with it that results in the successful delivery of that element. Breaking the major deliverables down into their component tasks or work packages is called creating the Work Breakdown Structure. The process of breaking the major deliverables into smaller units is formally called decomposing the WBS, but we'll keep it simple.

The IT Factor…
Your WBS "Inventory"

"Many people underestimate the benefits, not to mention the challenges, of developing a good work breakdown structure. A good WBS provides the critical link between defining a project and achieving project goals. A WBS is not complete until work packages have been identified for all the tasks in the WBS. It's the work packages that translate projects into reality," explains Ralph Spitzen, Director of the Metals Industry Practice and The Center for Learning& Professional Excellence at TDCI Inc., an Ohio-based consulting firm. "Most projects within a given organization will have similar life cycles and thus similar requirements for work packages in each phase. Building an inventory of reusable WBS's is an important part of every IT project manager's toolkit."

9.2.3. Major Deliverables to Major Tasks

The first step in developing your WBS is to take each of your major deliverables and break them down into the major segments of work required to complete this deliverable. Using the house-building example, it means breaking down the foundation deliverable as we did a moment ago. Clearly, there are numerous steps that go into each of those major tasks, but for now we simply want to identify the major tasks. In some larger or more complex projects, you may choose to divide up the major deliverables and assign them to subject matter experts so they can develop the major tasks. As the IT project manager, you job is not to do all the project work or to know everything about everything. Your job is to make sure the project gets completed successfully, and that typically means finding the right people to do the various jobs. This can also save time by having people work simultaneously (rather than a big group exercise). Another potential bonus to getting your subject matter experts to work on this task is that they may use prior expertise to streamline the project tasks or they may uncover a problem no one knew about.

IT Factor …
Organizing Your WBS

When developing your WBS, don't be concerned with the order in which tasks are listed at the outset. Make sure all tasks (work packages) are listed before you worry about the order, which will be developed later. If you start worrying about the order in which the tasks should be listed, you're likely to forget one or more important tasks. Most people think in a rather linear manner, so the task lists often come out in some sort of initial order and that's fine. Just don't spend time rearranging the list because sequencing comes later. Many IT project managers find it helpful to use a numbering system for tasks so that as they do move around later, it remains clear which tasks are part of a work package, master task or summary task. The most commonly used numbering system is as follows:

Table 9-1.
1.	Major task 1
	1.1.		Sub-task 1
	1.2.		Sub-task 2
	1.3.		Sub-task 3
		1.3.1.	Sub-sub-task 1
		1.3.2.	Sub-sub-task 2
2.	Major task 2
	2.1.		Sub-task 1
	2.2.		Sub-task 2
3.	Major task 3
	3.1.		Sub-task 1
	3.2.		Sub-task 2
3.3.		Sub-task 3

This type of number system helps because each major task is identified and all of the related sub-tasks are then numbered to keep track of their association with each other and with their major task. When the tasks are later rearranged to create the most optimal sequence and later, the schedule, it won't matter what order the tasks are in because your numbering system will help you immediately recognize their relationships. While you don't have to use this type of numbering system, it's one of the easiest to use to keep track of multiple layers of tasks, which most IT project have. When you later assign tasks to owners, you can assign by number and you can have task owners for major tasks and all subtasks or you can assign individual owners to sub-tasks, whichever best suits your project's and team's needs.

9.2.4. Major Tasks to Tasks

There's a project management tool called the 8/80 rule, which states that it usually is best to define tasks that take a minimum of 8 hours and a maximum of 80 hours. If you identify tasks that take 2 or 4 hours, you're headed toward a scheduling nightmare by creating unnecessary headaches for yourself. If you identify tasks that take less than 8 hours, you probably can (and should) roll them up into a slightly larger task that will take 8 or more hours. On the other side, you should avoid identifying any task (work package) that takes more than 80 hours. It's better to break those work packages down into smaller increments of work so they can be more effectively managed and tracked. So, the general rule of 8/80 applies here.

Taking your major tasks, have the team break them down into tasks that fall between 8 and 80 hours in duration. There may be additional, smaller tasks that must be accomplished, but for scheduling purposes, you should stick to the 8/80 rule. Let's look at an example. We'll use the house-building example again. If the house painter needs to paint the exterior, that might be a three-day job, so it would be listed as a task in the Exterior section of the project. That painter might break that task down into smaller tasks to help him or her complete the job. The painter might make a list that includes: prep all exterior trim, prime all exterior trim, paint all exterior trim, apply second coat to all exterior trim. Some of those tasks might take less than 4 hours and they don't have to be added to the project schedule. Paint exterior trim is the task on the schedule and the subtasks we just identified make up the task "Paint exterior trim." The task owner (we'll discuss task owners in a moment) will often break a task down into its components in order to complete the task, and that's a good thing. Trying to schedule all those subtasks would be akin to micromanaging the project and you'll create headaches for yourself and everyone else if you try to schedule and manage all those small subtasks.

Once you have delineated all your tasks, you should make a first pass at setting the duration for the task. Remember, duration and effort are not the same thing. A task might only take eight hours to complete, but you're allowing a duration of three days to allow the person to complete the task. If you can enter these durations for tasks now, do so. If you don't have enough data to determine duration for certain tasks, get the task owners busy (more on task owners in a moment) estimating the duration. You'll need duration for all tasks before you can determine your final project schedule.

As we mentioned earlier, you should not worry about the order or sequence of tasks at this point. Though there may be a certain amount of linear thinking that causes you to think of tasks in a particular sequence, you should not spend time now trying to place tasks in sequence as much as you should ensure that all the required work for the project is listed. We'll look at how to sequence tasks in just a bit, so for this exercise, just make sure all the work is listed and that they are somewhere between 8 and 80 hours in duration.

Cheat Sheet…
Defining Tasks Using Verbs and Nouns

The 8/80 rule helps you create tasks that are manageable and that's clearly your number one goal as IT PM. Another tip for managing your project is to have your team define your tasks using a noun/verb format. If someone is assigned the task of "Cabling," he or she may have no idea what that means. If he or she is assigned a task that says "Install CAT5 cable", he or she now has a much better idea of the nature of the task. It will help everyone and it's easy to have your team write up tasks in this format from the start. A project's success is created one task at a time, so make sure each task is clear and concise.

9.2.5. Scope Check

Once you have created your WBS, you and the project team should step back and look at your project's requirements including scope, time, cost, quality, and functional and technical requirements. Check to make sure the work defined by the WBS actually matches the work outlined by the project requirements. Often in IT projects, this is where the first disconnect happens. Any gap between the project's requirements and the WBS is a problem. On one hand, you may find that the WBS defines more work than is in the requirements. This is a classic example of one type of scope creep. Somehow, in defining the deliverables in terms of actual work packages, the scope of the project expanded. Sometimes this happens because you can't always know the extent of work needed until you create the WBS. However, if this happens, you have to carefully look at the project and determine if the original requirements were insufficient and the tasks in the WBS should be included in the requirements or if the WBS should be scaled back to better meet the project requirements. There is no right answer here because the ultimate test of the project is whether it meets user/customer requirements. It's possible that by defining your WBS, you identified elements of the user requirements that were not actually specified but are needed. An example of this might be something like the program contains all the user's requirements but you forgot about the user interface that would allow the user to use these features (unlikely, but just one example).

The bottom line here is that this is an excellent opportunity to ensure your project requirements and project work are aligned and that they haven't started to spread around the middle. Keep your project lean and mean and take steps here to address any disconnects, gaps, or creep.

Remember, too, that your WBS essentially defines your scope. As you recall, scope is defined as the total amount of work in the project needed to meet the requirements. So, your project requirements should match your WBS, and your WBS should include only the work needed to meet project requirements and not a speck more. If they're not aligned at this point, you're going to be way off track at the other end of the project.

9.2.6. Task Owners

After the major deliverables have been broken down into the component tasks, each task should be assigned an owner. The rule of thumb is: one owner per task or work package. That doesn't mean that a team or group won't work on that task, but that one person is held responsible for that task. A task owner, by definition, is the person responsible for the successful completion of the task. That does not mean that the task owner must perform the work in the task. It means that the owner is responsible for making sure the task is completed according to task specifications (scope, time, cost, and quality for the task). The task details determine how the task will be completed and the owner is often the best person to determine those details. The owner may delegate the development of task details to others, but ultimately it is the task owner who should be held accountable for delivering these task details and later, delivering the task successfully.

How do you assign owners? There are several criteria you might use in assigning owners and ideally, your IT project team members will select tasks to take on based on their own areas of expertise and interest. If you have to assign owners, you should look for one or more of these criteria:

Expertise Look for a subject matter expert who understands the components of the task. Those closest to the job often understand best what needs to be done. If you can get a subject matter expert (often called an SME) to own the task, its more likely the task will be well defined and well managed.
Experience If you don't have a subject matter expert to take on the task, the next criterion might be experience in related areas. If you assign tasks to experienced team members, they can either figure out the required information or they know who they have to go to in order to get that data.
Existing Technical or Team Lead This person may already have the formal authority on part of the project team and may be helpful in both defining tasks and determining to whom tasks should be delegated.

If you don't have a project team member with the expertise or experience to own the tasks, you have a problem. Remember, someone might be a peripheral part of the project team because he or she only works on one area of the project. How you define "project team" may flex and bend over the life of the project, so don't forget about people who might only participate in certain phases or steps of the project. If you need additional expertise, work with your project sponsor to identify resource needs to make sure you get the expertise you need. Lack of required expertise on a technical project can tank that project quickly. Having subject matter experts assist in developing task details (even if they don't later own them) might be your best bet in highly technical projects.

Cheat Sheet…
Task Ownership

The rule in project management is that a task should have one and only one owner. A task with more than one owner is less likely to be completed on time, on budget, and with the required quality. A task with no owners simply won't get done. More than one person can work on a task, but only one person should be assigned as the owner. If the task gets in trouble, you don't need a lot of finger pointing and "he-said, she-said." You need the task to be completed according to the specifications, period. One task, one owner.

9.2.7. Completion Criteria

Ideally, the task owner should create the completion criteria. Completion criteria are the standards or measurements used to determine that a task or job was completed according to specifications. These specifications include scope, time, cost, quality, and perhaps functional and technical requirements. Sometimes the completion criteria may be developed by a group or team or by the entire IT project team. You'll have to use your best judgment for which way to go, but often the task owner can create the completion criteria quickly and efficiently. The quality metrics you developed in Chapter 7 should be included in the completion criteria because it is through completion criteria that quality is managed (quality control) during the work phase of the task.

Let's go back to our painting analogy. The house painter knows how to do the job quickly and correctly (scope, time, cost, and quality) or you wouldn't be using this house painter. The painter is the best one to come up with the completion criteria for "Paint all exterior trim." He or she can make a quick checklist that can be used by anyone else to determine, beyond a shadow of a doubt, whether or not the job is completed within the scope, time, cost, and quality parameters. The completion criteria should be crystal clear: the job either was or was not completed success-fully. This is important because you don't want a lot of discussion and debate on whether or not a task was successfully completed. If the completion criteria leave room for doubt, they need to be revised. The house painter knows that if the wood isn't prepped, the paint won't adhere, so properly prepping all wood surfaces to be painted might be part of the completion criteria for the task. It's possible that even more detail is required to specify exactly how the wood should be prepped. Does it include filling in gaps and nail holes? Does it include sanding the surfaces? Does it include wiping or washing down surfaces?

As you can see, the degree of detail depends on several factors.

Who is performing the work? If someone more experienced is performing the work, the completion criteria typically do not need to be as detailed. An experienced network administrator will know to take certain steps that might have to be spelled out to a less experienced net admin.
How complex is the task? The more complex a task is, the more detailed the completion criteria should be. Leave no room for doubt.
How critical is the task to project completion? Sometimes a task or deliverable is very critical to the project and therefore has little room for error. In these cases, more detailed completion criteria may be appropriate.

Let's not confuse the complexity or level of detail with the quality of the completion criteria. Just because you might opt for shorter, more concise completion criteria, it doesn't mean you're sacrificing quality. The needed level of quality should be delivered no matter what. You and your team will need to verify that the completion criteria for tasks drive that level of quality. The complexity of the task and the expertise of the person working on the task will typically determine how detailed the completion criteria need to be, but they should be as detailed as needed to ensure quality. As the IT project manager, you will ultimately be held accountable for project deliverables, so be sure you agree with task completion criteria. As the liaison between the stakeholders and the project team, you may also have a better perspective as to stakeholder and project sponsor expectations and needs. Your job is to ensure these needs are reflected in the task completion criteria.

Completion criteria drive quality. In the chapter on quality, we discussed the sources of quality in a project and we mentioned completion criteria. Completion criteria are the best tool to manage quality on a task-by-task basis. That's why they're so important to define well and to use as the measurement for whether or not a task is complete. The time your team spends in developing clear, thorough completion criteria for each task is time very well spent.

9.2.8. Entry/Exit Criteria

Entry and exit criteria are used to define the entry into and exit from particular project milestones. When developing your WBS, you may want to define entry and exit criteria. These are different from completion criteria in that you are not defining successful task completion, but rather successful phase or step completion. For instance, suppose your project is to develop a new program. You should wait to complete your requirements development before you have programmers begin writing code. Therefore, the entry criteria for the code development phase of the project could be the completed, accepted requirements list (note that the completed, accepted requirements list can also be the exit criteria for the requirements development phase). Entry and exit criteria are typically used to define entry and exit into and out of phases or steps of the project, but some companies choose to create these for all major deliverables, all major phases, or even all major work packages. Your decision should be based on the complexity of the project and the way your company operates.

9.2.9. Project Management Software

You'll notice that this is the first time we introduce project management software. Why? Because having project management software doesn't mean you can manage a project anymore than having Microsoft Excel makes you an accountant. Project management software is simply a tool that can make it easier to manage the project. Notice we didn't say define or plan the project but manage the project. Once the project gets underway, you have to track a lot of moving parts and that's where having a software program can really help; that's why this is the first time we've referred to a software program. For smaller projects, you may be able to track the project in Microsoft Excel, Microsoft Outlook (with calendar and tasks), or on paper (gasp). For anything with a lot of moving parts, a project management software program is almost mandatory. Large projects managed in Excel or on paper end up taking a disproportionate amount of time to track and manage and the cost of a PM software package quickly becomes justified. There are numerous online programs you can rent (ASP model) as well as numerous software packages you can purchase and installeither as desktop installations or enterprise-wide installations. A discussion of those software tools is outside the scope of this book, but a bit of research on your part will yield a vast array of choices. Talk to peers in your company or industry to find out what tool(s) they recommend since every software program comes with its own set of challenges. For instance, Microsoft Project has a lot of basic capabilities that help manage the project schedule but it is somewhat lacking in reporting flexibility and capabilities. (Microsoft Project 2003 addresses some of these issues; older versions can be a challenge.) Each tool has its limitations so you really just need to figure out which limitations are easiest for you to work with.

Once you create your WBS, you may choose to enter your tasks into the software program. Some people like to define their tasks and put them in sequence before entering them into the software program. Regardless of when you enter your task data, make sure you don't confuse the software tool process for the project management process. The software tool won't necessarily help you with your IT PM processes, it will simply track what you enter. The most helpful part of any project management software program is the ability to manage a changing schedule and to identify risks to the project via the critical path. We'll discuss critical path more in just a moment. The outcome of this step should be a WBS with task owners and completion criteria. The document is listed in Figure 9.3 and this should be added to your project plan for sponsor approval. The entire plan will be presented for project sponsor approval prior to starting project work, and we'll discuss this at the end of this chapter.

Figure 9-3. Work Breakdown Structure, Task Owners, and Completion Criteria

9.2.10. Task Details

The WBS and the tasks that are developed should contain enough detail that the project is very well defined at this point. While you have not yet developed the schedule or the budget, the work to be accomplished during the project (scope and requirements) should be evident in the breakdown of project work. The tasks should contain needed detail, and the following list contains some of the elements you may want to include in your task detail. Depending on the nature and type of project you're working on, some of these details may not be helpful, but this will give you a starting point for developing a template of your own for required task detail. You can also download the task detail template from the Syngress website.

Task details help define the task, the quality expected, and other details including:

Task name (noun/verb format)
Task number (if used)
Task owner (one person)
Task contributors (one or more people who may work on task)
Task detail (longer description of task)
Completion criteria
Entry/exit criteria (if any)
Quality metrics
Requirements or specifications
Required resources
Task deadline (if any)
Estimated start date
Duration (length of time allotted for completion of task)
Effort (amount of actual work time needed for completion)
Estimated end date (based on duration)
Cost (historical or calculated)
Dependencies
Constraints
Related milestones or events (if any external events are tied to this task)
Approval/signature needed (if any approvals are needed, these should be noted)
Risks to task (if known)
Triggers for implementing risk management plans (contingency plans)
Amount of reserve needed (to be listed separately and not added to duration)
Lessons learned (to be completed at task completion)

You can see from this list of task details that there's a lot of information to be developed, which is why it's best to have the task owner develop (or delegate the development of ) these details. Remember, a task owner doesn't necessarily complete the work; he or she is responsible for ensuring the task is completed successfully according to specifications. If you're not sure the task owner will deliver, you've got to make some decisions about how to handle the situation because the success of the project is built upon the successful completion of tasks.

9.2.11. Functional and Technical Requirements

We discussed developing functional and technical requirements earlier in the book, but this is a good time to review those requirements. You may need to modify functional or technical requirements based on the development of your WBS. For instance, if your WBS defines a scope that is larger than your requirements, you've got scope creep starting. You should go back and modify your WBS so that the tasks only describe the total amount of work needed to meet requirements (scope, time, cost, quality, and functional and technical requirements). On the other hand, if your WBS doesn't fully address your functional or technical requirements, you have a disconnect and you'll need to modify your WBS to address all the requirements. This is where you have a great opportunity to check, double-check, and triple-check your project's scope and make absolutely sure it meets the functional and technical requirements. This is a stress point for projects and is a common point at which problems begin to develop. The problem is that when issues develop at this point, they often fly under the radar until they show up with a vengeance somewhere down the line. Identifying and correcting disconnects here is vital to project success.

Every IT project will have different functional and technical requirements, so there is no "one size fits all" in this case. However, functional and technical specifications do have common elements and if you'd like a framework against which to review your project's functional and technical specifications, you can download the requirements templates from the Syngress website.

Cheat Sheet…
Selecting Project Management Software Tools

Each project management software tool has its own "personality." The key to selecting the right program for you, your team, and your company is to look at the features and limitations of each and try to choose one that is the best fit. For instance, who will be entering and updating task information? One person or the whole team? Do you need a single desktop program or a shared, networked program? Do you need to facilitate collaboration or do you simply need to track task progress? Take a few minutes to create your own requirements document for your project management software solution and select one that will fill the bill.