Remember when you were a kid and you bought your first model car? You opened the box, sorted all the pieces, put the decals aside for safekeeping, and gathered all your tools. Of course, you read the directions completely and carefully assembled each piece of the model with just the right amount of glue, patiently waited for it to dry before proceeding, and then finally applied the decals with a pair of tweezers.

Doesn’t sound quite right? Were you more like the kid who ripped the box open, tossed the directions aside, and ended up gluing your fingers together? What’s the lesson here? With experience, you became more like the kid in the first example: meticulous, careful, patient, planning, and savvy with a tube of glue. The same is true with project management—except for the glue thing. You, the project manager, need a detailed plan of the work, what phases are required in the work, and then what tasks are required within each phase. Just as it was when building the model car, taking the proper steps won’t be easy, but if you plan for success, you will reach your goal.

Creating the Project Scope

Consider all the IT projects that you’ve ever worked on. Add to that pile of projects all the IT projects that fall outside your realm of experience, expertise, and concern. That’s a huge amount of hardware, software, databases, and network projects that have been defined, financed, planned, and completed. IT project management is a huge arena of endeavors, possibilities, and conditions. Each project is different from the next, but all projects must have boundaries that establish what the project will accomplish and what the project will exclude.

The requirements of a project define the boundaries. Requirements are the elements, conditions, services, and expectations that the project customers, stakeholders, and management expect the project to create. You can generally visualize the project requirements when you consider the current state of an organization and then examine the future, post-project state of the organization.

As a project manager, you may be responsible for gathering the requirements, though this responsibility often rests with a business analyst. It’s healthy for you to understand the process, techniques, and outputs of collecting requirements so that you can form a complete picture of how the project is defined and what the project stakeholders are anticipating from your project.

Gathering Requirements Through Communications

One of the most effective approaches to collecting project requirements is to get out there and talk with your stakeholders. This is true in both predictive and agile projects. Communication is a major part of project management, and it really starts when you and the stakeholders discuss the desired future state of the organization—the future state that your project will help create. Your organization may have a different approach to collecting requirements, and that’s fine; always follow the governance of your organization.

If you’re lucky enough to have a business analyst who will complete the requirements collection process for you, you’ll want to discuss the requirements in depth with the business analyst and the stakeholders to confirm that you understand the requirements. This discussion focuses first at a high level of what the customer wants, and then you can drill down into the individual components that contribute to the overall solution the business analyst has documented. You and the business analyst should create a partnership and identify your roles and responsibilities on the project, work together, and stay out of each other’s way.

If you’re not so lucky to have a business analyst, then it’s all up to you, the project manager, to collect and document the project requirements. One advantage of this approach, however, is that you’ll have an in-depth understanding of what the customer expects, and that will help you create the project scope, maintain quality, and address any threats or stakeholder concerns. Through interviews, focus groups, workshops, and requirements analysis meetings, you can discover, define, and document what the stakeholders expect the project scope to achieve.

If you’re dealing with a large mass of stakeholders, such as the end users of the software your project may create, then meeting with each stakeholder isn’t feasible. In these instances, the project manager can use surveys to interview the stakeholders. With web technologies, it’s a snap to compile and share responses. You might also elect to use representatives for large groups of stakeholders. Representatives of the stakeholder group and the project manager meet to discuss the requirements that will affect the large mass of stakeholders, given the representative’s input.

Finally, as introduced in Chapter 1, you might need to use observation, sometimes called job shadowing, to see how the stakeholders complete their work. Passive observation happens when the project manager quietly observes the work being completed to understand how the stakeholder performs the duties and processes that the project deliverable will affect. Active observation allows the observer to interact with the stakeholder—often stopping the work, asking questions, and even trying the work to fully understand how the stakeholder completes the work.

Whatever approach you take to document the requirements, you must ensure that the stakeholders are in agreement that you’ve captured the project requirements. You don’t want to create the project scope without having captured the project requirements or base the scope on requirements that are wrong.

The requirements documentation usually includes all of the following information:

•   Business need to solve or the opportunity the project will seize

•   Project objectives and goals that can be traced to the requirements

•   Functional requirements of the project deliverable, such as features and functions of the thing or condition the project will create

•   Solution design is needed for technical projects. This can be for software development, network infrastructure projects, and databases.

•   Nonfunctional requirements of the project deliverable, such as the level of service, performance objectives, security, interoperability, and support

•   Quality requirements

•   Factors for project acceptance

•   Effect of the deliverable on the organization, departments, or lines of business

•   Effect of the deliverable on entities outside of the organization

•   Need for education, training, and ongoing stakeholder competency support

•   Identified assumptions and constraints

One method that can help track the requirements from the requirements document to the finished product is a requirements traceability matrix (RTM). An RTM identifies the project requirements, documents when each requirement is to be created in the project life cycle, and records when the deliverable was actually created. The RTM can also help control and evaluate changes to the project scope. At the end of a project phase and at the end of the project, the project manager can examine the RTM as part of scope verification to confirm that the requirements that were expected were created.

You can also use the matrix to record attributes about each deliverable, such as a globally unique identifier, a description of the requirement, the requirement’s owner, the versioning information, and the status of the requirement. All of this information can help with stakeholder management and communication throughout the project. You and the project team can use this information as you plan each phase of the project and to confirm that you’ve completed all of the requirements that the customer asked for. And then you’re everyone’s hero.

Creating the Product Backlog

In an agile project, the project scope is represented as the product backlog. The product backlog is a prioritized list of all the features, functions, and requirements that the final product should have. The product owner represents the project customers and is responsible for sorting, prioritizing, and maintaining the product backlog. The product backlog items are gathered by a business analyst, customer representative, the product owner, the project manager, the project team, and other stakeholders depending on the size of the project and the formality of the organization.

Throughout the project, any stakeholder can add items to the product backlog, but only the product owner may prioritize the items in the backlog. The team is always developing the most important items in the product backlog. Items that are not as important are shifted to the bottom of the list, and it’s possible, due to time and financial constraints, that not all items in the product backlog will be created in the project. This isn’t a bad thing, as the most important items in the product backlog are created first, and the items of lesser importance, and lesser value, are created last.

Working with the Balanced Scorecard Approach

Many organizations use a strategic tool called the balanced scorecard to align their projects to the organization’s vision and strategy. If your organization uses this approach, you’ll work with management to ensure that the project requirements and its scope are in alignment with the organization’s balanced scorecard.

The balanced scorecard has four categories that are scored based on key performance indicators (KPIs):

•   Financial  Increase profits by lowering costs and increasing revenue.

•   Customer  Reduce customer wait times and improve customer retention for the organization.

•   Internal process improvement  Increase organization efficiency and lower the process cycle time to complete activities.

•   Organizational capacity  Improve the organization’s knowledge and skills and improve tools and technology.

A project in a balanced scorecard organization would address how the project will be in alignment and supportive of these four specific factors as part of its project scope statement.

Writing the Project Scope Statement

In Chapter 2, I detailed the process of writing the project scope statement. This is one of the most important documents you’ll create in the project. Once you’ve captured the project requirements, you’re ready to write this important project document. Remember that the project scope is all of the work, and only the required work, that the project must complete in order for the project to be done. In this document, “work” doesn’t refer to the physical activity but to the deliverables that the project team will create. Think of work, in this sense, as you would the works of Mozart.

The details of the project scope statement are based largely upon the work you, the project team, and the business analyst have already done through requirements gathering. The project scope is often based on forms and templates that your organization or project management office (PMO) uses to capture these requirements. You might also use expert judgment through your project team, consultants, and other experts internally in your organization. The goal is to take the requirements document and elaborate on the requirements to define the exactness of the project deliverables.

Sometimes the project requirements are wide and broad—for example, to create a website that allows customers to log in to a secure area of the site. While this requirement does define the functional attributes of the deliverable, the intricate details, the behind-the-scenes programming, and the interface are left to interpretation. The creation of the project scope statement allows the project team to elaborate on this information and define exactly what the customer would like. Through the project scope statement, you can define the web services software, the database type, and the security expectations of the web server. It’s typically easier to get customer approval of a concept than a physical, working deliverable. Figure 4-1 depicts this concept: changes early in a predictive project aren’t as difficult and costly as changes late in the project.

Figure 4-1  Changes early in a predictive project are easier and less costly than changes later in the project.

The project scope statement defines these items:

•   Product scope description  Remember, the project will ultimately create the product scope, or the deliverables. It’s essential that the project scope statement define the product scope either directly or refer the reader to a specific document where the existing and approved product scope resides. You’re basically confirming that your project will create the product, service, or condition defined in the product scope documentation and the requirements documentation.

•   Product acceptance criteria  You need to know what it will take for this project to be considered done. You and the customers, the project sponsor, and any other key stakeholders need to define in the project scope statement the conditions that must be met for the project deliverables to be accepted and the project to be closed.

•   Project deliverables  These are the products, services, or conditions the project will create for the project customer and for the organization. For example, the customer may be expecting new software from the project, but the creation of the software will require your project team to buy certain resources, acquire hardware, and the like. You’ll be creating all sorts of project plans, templates, and reports that can be used by other project managers in your organization. Not all project deliverables go to the project customer.

•   Project exclusions  The project scope statement defines what’s included in scope and what’s out of scope. By establishing the boundaries of the project, you’ll eliminate many assumptions and disappointments when your project is near closure.

•   Project constraints  A constraint is anything that limits the project manager’s options. You can usually see a constraint when the word “must,” “required,” or “mandatory” is included in the description. Common constraints are budgets, schedules, and contractual terms.

•   Project assumptions  An assumption is anything that you believe to be true but that hasn’t been proven to be true. Assumptions can have huge impacts on the project’s success if they prove false. For example, you might assume a vendor will be available for the duration of the project or make assumptions about software compatibility and data security. These assumptions are difficult to prove in IT, but you often have to accept them to get moving on the project work.

Creating the project scope statement is not an easy process, but organizational process assets, in the form of historical information, also called artifacts, can be helpful. If you’ve completed similar projects in the past, just adapt past scopes to the current project to save time, to ensure accuracy, and to follow a proven approach. The project scope statement creation may also require that you create a constraints log and assumptions log rather than listing all of the constraints and assumptions directly in the project scope statement. You might also need to update or create a stakeholder directory that includes all of the stakeholder contact information, project details, and other information about each stakeholder and the project expectations.

Agile projects utilize the product backlog to represent all of the requirements prioritized from most valuable, at the top of the list, to least valuable, down at the bottom of the backlog. Early in the project, the project manager and stakeholders do establish the project vision; it isn’t as formal as the project vision for a predictive or waterfall project, but it helps everyone understand what the end result of the project should be. Along with the vision, the team works towards the DoD—the Definition of Done. The DoD is utilized throughout the project to communicate when the project is complete, when each requirement is complete, and when each work activity is complete. The DoD is a great tool to communicate what constitutes done in the project. It’s a clear, simple concept that keeps everyone committed to the project work and the desired future state of the project.

Defining the Work Breakdown Structure

Once the project scope statement is approved, you’re ready to move forward with project planning. An approved project scope statement is needed in order to begin creating the project’s work breakdown structure (WBS). A WBS is a deliverables-oriented collection of project components used in predictive projects. It is a categorization and decomposition of the project scope statement. And, yes, it’s called “decomposition,” because you’re breaking down the massive project scope statement into smaller, more manageable components. Each component is subdivided again and again until you reach the smallest element of the WBS: the work package. A work package is a WBS element that you can schedule in your project, estimate the costs from, and monitor and control.

Consider a project to establish a new network. The WBS could offer high-level deliverables such as LAN, WAN, extranets, and intranets. Each of these high-level deliverables would be broken down into more defined deliverables that make up the high-level components. At the lowest level of the structure, you have the work packages. Work packages will be further decomposed into activities in the project schedule. If you think about the project, each assigned activity should relate to a work package. The sum of all the work packages, when they’re created by the project activities, will equate to the project scope. The project scope, when it’s completed, will fulfill the product scope. And all of that equates to a completed project.

A WBS is important in all projects. It is necessary because it serves as input to five key project management activities:

•   Cost estimating

•   Cost budgeting

•   Resource planning

•   Risk management planning

•   Activity definition

Later, in Chapter 10, we’ll get into the juicy business of managing changes to the project scope. When there are changes to the project scope—and they do happen—you’ll also have to update the WBS. When you update the WBS, it often triggers changes in all areas of the project, but especially in costs, schedule, resources, risks, and activity definition. They’re all related.

Working with a WBS

There’s no right or wrong way to create a WBS. You can draw an elaborate decomposition on a whiteboard, sketch it out on a cocktail napkin, or be more technical and use software such as Microsoft Project or even Excel, Visio, or PowerPoint. It is best, however, to use some common terminology when addressing your WBS.

A project, of course, is a temporary endeavor that has a definite end date, produces a defined set of deliverables, and is an investment by an organization. For example, the software application that allows web users to search a database requires a scope, a defined deliverable, a commitment of resources, and a targeted end date.

Within the project there are phases. A phase is a portion of the project that typically must be completed before the next phase can begin. Phases make up the project life cycle, and the completion of a phase usually creates a milestone that shows progress in the project. For example, a database project could have four phases: creation of the database, creation of the application, creation of the web interface, and troubleshooting and implementation. Typically phases do not overlap each other in execution, but it is possible that phases could overlap to save time or if the nature of the project work allows phases to happen in unison.

The work within each phase is linked to the work packages of the WBS. The project’s activity list is derived from the work packages that the decomposition of the project scope creates. For example, a phase to create a database encompasses several work packages required for completion. A database administrator needs to create the database with the application designer to ensure consistency, a system needs to be built to enter the different attributes of the database items for searching, and there could be connection hooks between this database and existing databases that production uses.

The point is that it’s often easiest and most logical to create a WBS based on the nature of the project work. In a project where it’s easy to see and relate to the phases of the project, you should decompose the project scope accordingly. In other projects, where the focus of the project execution isn’t as clear, it may make more sense to categorize the project components and then decompose. The right way to create a WBS is what’s right for the specific, unique project.

Coordinating WBS Components

Some project managers would recommend that you continue to break down each component until you cannot possibly break down the deliverable any further. However, conventional wisdom contradicts a continual decomposition of any deliverable, as it eventually leads to units of work that are too small to measure, assign, and manage. While some control over the work to be completed is required, a project manager needs to put faith in their team to complete the tasks necessary to finish the job.

As a rule, find an acceptable amount of time that will serve as the smallest increment of work. For example, with a small project, you may only break work down into what equates to days of labor. With a larger project, you may choose to break work down into weeks. The key is not to continue to break down each deliverable into tiny, unmanageable work packages but to break them down into assignable, realistic chunks of deliverables. A heuristic you can rely on is the 8/80 Rule, which suggests that the smallest work package should take no less than 8 hours and no more than 80 hours to complete. While this rule can apply to most projects, it’s not always applicable. For example, you may have a work package that represents a subproject or part of your project that you’ll be outsourcing to a vendor. The group completing the activities will likely decompose these work packages into their own WBS components.

As you plow through the decomposition of the project scope to create the work packages, you’ll likely find that you need to rearrange elements, add deliverables, and refine the WBS several times. This is expected—don’t get frustrated with your efforts. Over time, the refinements you and the project team add to the WBS will help you plan the execution of the project, create more accurate time and cost estimates, and effectively close the project.

One element you can use through the WBS is a code of accounts to help keep things organized. A code of accounts is a numbering system that shows the different levels of WBS components and identifies which components belong to which parts of the WBS. For example, suppose that I have a project named Data Center and it’s been assigned a project code of 507 in my organization. Within this project are four major categories of deliverables: database, network, application, and hardware. Each of these categories would append the assigned project code and would look like this:

•   507.1 Database

•   507.2 Network

•   507.3 Application

•   507.4 Hardware

When my project team and I decompose these elements, we’d continue to branch off the elements within the code of accounts. For example, I could decompose 507.2 Network a bit more and created this:

•   507.2 Network

•   507.2.1 Routers

•   507.2.2 Switches

•   507.2.3 LAN

•   507.2.4 WAN

You can see how each element can be decomposed again and again into related but separate deliverables. Each deliverable, in this instance, can be subdivided again, and I can continue to append to the code of account numbers. Finally, I might end up with a work package of J-hooks for the LAN deliverable, which could have a code of accounts identifier of 507.2.3.2.1. That identifier would be used only once in the entire project, and it would reference only the J-hooks that are needed for the LAN. There’s no confusion as to which deliverable I’m discussing with my project team, and it’s easier to track time and costs for just that one particular project element.

Defining a WBS Approach

There are two broad methods used to create a WBS: top-down and bottom-up. The top-down approach uses deductive reasoning because it starts with the general and moves to the very specific. Bottom-up moves from the very specific toward the general. Figure 4-2 depicts the difference between the top-down and bottom-up methods.

Figure 4-2  There are two general methods for creating a WBS.

Both methods have their advantages. The bottom-up method is ideal for brainstorming a solution to a problem. Imagine that a project team is trying to find a solution to connect a network in Chicago to a network in Phoenix without having to spend much money. The bottom-up method would call for very specific solutions without delving into all of the details of each solution. The method could investigate the use of new software, a new service provider, or practically any implementation that is still open for discussion on the actual work to be implemented.

You might also use the bottom-up method when a stakeholder with lots of influence and power over your project is demanding a very specific feature in the project. With the bottom-up approach, you could start at the specific deliverable the stakeholder is demanding and work backward to the rest of the project scope.

The top-down approach requires more logic and structure, but it is generally the preferred method for creating a WBS. A WBS using the top-down approach would identify a solution first and then dissect the solution into the steps required to implement it. You probably use the top-down approach in your daily life. For example, when making a decision to purchase a car, you’d decide what kind of car to buy: SUV, sports car, sedan, minivan. And then what can you afford? What color? What about the bells and whistles? This process of thinking begins with a broad approach and then narrows to specifics.

The Mechanics of Creating a WBS

The process of creating the WBS is not a solo activity. Typically it requires the involvement of the project manager and the project team. On some occasions, it may require the project sponsor or other stakeholders—though typically by this juncture the team has been given the go-ahead and management supervision is not required. It is, however, a good idea to involve your key stakeholders to create shared ownership of the project and to keep them involved. Depending on the size of your project team, gathering around a computer screen to build a WBS is not ideal. What is ideal is to assemble the team and lead them through the process of creating the WBS together. Here’s how.

For starters, make certain you have a whiteboard, plenty of markers, sticky notes, and control of the meeting. You’ll start with the top-level requirements first. These are usually the phases of the project, but they can also be the major deliverables, categories of the project that may span the calendar phases, and so on.

For this example, we’ll assume that the deliverables are contained within each logical phase. If your budget has not been created or did not include project phases, determine what the project phases are by asking these questions:

•   Are there logical partitions within this project such as deadlines, milestones, or activities based on the calendar?

•   Are there business cycles within your organization that need to be considered?

•   Are there financial obligations or constraints within this project that could signify phases?

•   What processes are currently in place for system development within your organization?

Once you have the phases identified, write each one on a sticky note and attach it to the whiteboard in the order of the phases. Now within phase 1, you’ll decompose the components into smaller deliverables. You’ll continue to decompose the project deliverables until they are at a manageable work package.

Decomposing the project deliverables requires some fine-tuning; you do not want to get too granular with the tasks, but you do want to break down the components so that you may allocate time and resources to the activities that must be completed to create each component. This is where you’ll reference the 8/80 Rule: no task should take less than 8 hours or more than 80 hours to complete. If you remain general and acknowledge the work to be completed rather than describe the actual activities required to create each component, you’ll be fine.

After you finish phase 1, or the first major deliverable, move on to the next component and repeat the process, and so on, until all of the deliverables have been broken down into work packages and the work packages have been broken down into the necessary tasks. What you’ll have on your whiteboard may appear to be a very messy collection of sticky notes, but in reality, it represents your project from start to finish.

From here, document the WBS and let the structure cool for a day or two. Chances are you and the project team will think of other elements that need to be added to the WBS or you’ll think of a better approach to organizing the project work. You can create the WBS in a software package such as Microsoft Visio—but Word and Excel can work just as well. Some project managers go immediately to Microsoft Project, but Project is really good for organizing the activity list and not so much the WBS deliverables that you’re concerned with here. Whatever approach you take to create the WBS, it’s important to document and structure the WBS to reflect all of the project requirements.

Why You Need a WBS

You may be tempted to skip the process of creating a WBS—especially on smaller projects. Don’t yield to that temptation. By creating a WBS, even on small projects, a project manager can help accomplish several things in a project:

•   A WBS defines the work required to complete the project. How many times have you started a project only to uncover deliverables that you had totally forgotten about? Or worse, you realized that a component was needed that didn’t exist and had to be created before your project could continue? A WBS ensures that a project manager knows all of the required deliverables that must exist for the project to be considered complete.

•   A WBS creates a sense of urgency. By creating a WBS, a project manager and the team are working toward the project deliverables. Because the WBS is broken down at its lowest level into work packages—and the activity is derived from the work packages—the tasks can then be assigned start and end dates. The WBS is needed to ensure proper scheduling and sequencing for the identified activities to create the project deliverables. The project can maintain its momentum—and its schedule—if all members complete their tasks on time. A WBS allows a project manager to track the success or failure of team members based on the completion of activities, which in turn creates the deliverables the WBS identifies.

•   A WBS can help prevent scope changes. When management and departments try to add new features for an existing project, a WBS can ward them off. Because a WBS defines all the project deliverables based on the project scope and identified requirements, it becomes easier for a project manager to rule out additions and new features to a project that has already started. It is possible, however, to add new features to the project scope, but there are ripple effects into the project schedule, cost, quality, risks, and other areas of the project that must be considered and managed.

•   A WBS provides control. As a project manager, you may be in charge of several different IT projects. A WBS can allow you to graphically view the status of any project and how much progress is being made. You can easily home in on a particular phase, work unit, or task and make adjustments, counsel team members, or adjust the schedule as needed. Control is good.

•   The WBS is a portion of the scope baseline. The scope baseline is the combination of the project scope statement, the WBS, and the WBS dictionary (discussed next). Your goal is to manage the project team to create all of the things defined in the scope baseline. Basically, deliverables that are not in the WBS are not in the project. The scope baseline provides a point of agreement between the project manager, the customer, the sponsor, the team members, the vendors, and other stakeholders on what is and is not in the project.

Creating a WBS Dictionary

The WBS dictionary, as its name implies, is a dictionary that defines each work package in the WBS. You’ll use the WBS dictionary to identify clearly what the components of the WBS are and how they relate to the project scope. The WBS dictionary is a great place to define each element of the WBS in simple-to-understand terms that all project team members and stakeholders can reference. Think of all the acronyms you use in your organization or as an IT project manager and the terms your project team members use as part of their work. By defining these terms, you assure that if they’re part of the WBS, there’s no confusion as to what’s what.

The WBS dictionary typically defines, at a minimum, all of the following about each WBS element:

•   Code of accounts number

•   Description of the WBS element

•   Person, vendor, or other organization responsible for the WBS element

•   Scheduled creation of the WBS element

•   Resources required to create the WBS element (resources are people, materials, and facilities)

•   Cost to create the WBS element

•   Quality requirements

•   Criteria for acceptance of the specific deliverable

•   Technical references, drawings, and other supporting detail

•   Contract terms and information

•   Milestone schedule

You’ll use the WBS dictionary throughout the project for reference. You’ll likely need to update the WBS dictionary as more information becomes available during the management of the project or when changes are introduced and approved for the project scope. Updates to the WBS and the WBS dictionary are called refinements.

Obtaining Stakeholder Approval

Once the WBS has been initially created, it must pass through management for a final sign-off. In some instances, such as when the project manager and the project team are consultants or vendors integrating the technology into an existing enterprise, the project manager probably won’t have to pass every work unit within the WBS through management for approval. Stakeholders will need to approve the WBS in most projects. They’ll need guidance from the project manager and often experts to guide them through the WBS, but they’re usually just looking for confirmation that your WBS is linked to the requirements they’re expecting from the project.

Because agile projects don’t use a WBS, there is less formality with the sign-off of documentation and project planning. But this doesn’t mean that agile projects don’t have rules and obligations for the stakeholders and team members. The product backlog is managed by the product owner. Anyone in the project can add items to the product backlog, but the product owner approves or declines the change, prioritizes the added items, and maintains the integrity of the backlog throughout the project.

Presenting to the Project Sponsor

The project sponsor, the advocate of the project, will be the first stop on the road to approval of the WBS. The project manager must be prepared to explain any component of the WBS or WBS dictionary to the project sponsor. If the project manager has fully researched and skillfully planned the WBS with a focus on the project requirements and has identified deliverables and business cycles, there should be few revisions to the schedule.

However, if the project manager has failed to work with the team, to consider business needs, or to take into account other implementations within the organization, the project sponsor can (and should) work with the project manager to correct these issues. You can imagine the frustration that could ensue if the WBS had to be re-created because of poor planning and an inadequate understanding of other activities within the IT realm of an organization—not to mention that failure in creating the WBS does nothing to gain the confidence of your project sponsor and the project team.

Presenting to Key Stakeholders

Once the project sponsor has approved the WBS, the project manager should present the WBS to the key project stakeholders. Depending on your organization, this may be the customer of the project, another department within your organization, or management. As always, tailor the presentation for the audience you are speaking to. The WBS presentation does not need to go into great detail for each deliverable represented within each phase or component. To begin the presentation of the WBS, start with the deliverables of the project. By again reminding the stakeholders what the project will produce, you’ll be reinforcing their decision to move the project forward. The whole point of presenting the WBS to the stakeholders is to confirm that your project includes all of the requirements they’ve requested for the project.

Once you’ve established the deliverables, reveal the phases required to reach them. It would be most effective to show a milestone schedule or a high-level overview of the project schedule. Figure 4-3 is an example of a milestone chart for a project that’s already in motion. As each phase is revealed, you can superimpose an arrow over the timeline to show where each phase will put you in relation to the project completion. You could also detail the requirements traceability matrix along with the WBS to show the relationship between the project requirements and the components in the WBS. This will allow your audience to visualize how your plan has been well conceived and how each phase will produce a deliverable, moving your team, and the organization, toward the end result of the project.

Figure 4-3  Milestone charts track planned targets and actual fulfillments of milestones.

Within each phase, you may wish to show a few of the highlights to convey the core activities that are required. It is not, however, necessary to illustrate every task required to complete each phase unless the stakeholders explicitly ask for it. You should be prepared to discuss each phase in detail, and it would serve you well to have an alternative presentation that does include each task of each phase of the project if your project is planned to that level of detail.

Generally, stakeholders do not want to know about each activity associated with installing a network, replacing workstations, or upgrading a dozen servers. You should, however, always share with management any phase of the project that may require any downtime of IT components, even if it is over a weekend. The WBS dictionary should address these downtimes, if they exist, so that the stakeholders are aware of the impact. Always take into consideration, through audits and logging, the type of activity that occurs over weekends or at night by remote users, international users, and users who work late and long hours. Don’t assume anything.

If management does not approve the WBS, the project manager should immediately address any areas of concern. In some instances, management may approve on the condition of a few revisions. In other circumstances, management may delay your approval in order to study the WBS in detail. Plan your management approval meetings in accordance with what the norm is in your environment. If management always delays decisions to begin projects, don’t let their delay infringe on the implementation. Plan the WBS approval meeting with ample time for management to review and revise the WBS.

If your WBS needs to be approved immediately, stress to the stakeholders that the schedule must be implemented within x number of days. If there are no concerns with the first phase of the schedule, then perhaps at least that part of the plan can begin while management reviews the later details.

CompTIA Project+ Exam Highlight: Managing Project Scope

The primary focus of this chapter is the project scope and planning the project work. It’s been said that projects fail at the beginning, not the end, so it’s no surprise that you’ll need to clearly identify what the project is intended to create as early as possible. The project scope, for predictive and agile projects, maps to the project vision and the business value of the project. Each item the project creates as part of the scope must have business value. Business value correlates to why the project work is being done. If you can’t identify the business value for an item in the project scope, the item likely doesn’t belong in the project.

You wouldn’t create a project scope document without a charter—there’s no authority for the project to exist without the charter. The project scope document, or what’s more commonly known as the project scope statement, defines the boundaries of the project. Recall that the boundaries of the project establish what is included in the project scope and what’s left out of the project scope. This helps to alleviate assumptions, establish ground rules, and set the expectations of the project.

2.1 Explain the value of artifacts in the discovery/concept preparation phase for a project  You can utilize artifacts to help you manage and plan the current project. Artifacts are sometimes called historical information, project archives, organizational process assets, or past project files. Whatever you call it in your organization, the concept is the same: leverage similar projects to better manage the current project. With the historical information, you can better create the business case, create the project scope statement, and plan for the cost expectations of the current project.

All projects should define the current state of the organization and what the future state of the organization will look like when the project is done. A current state analysis can be time-consuming, and a future state analysis is really just a prediction of what you think may happen. Historical information, however, is proven information, so it can help you better predict what will happen in the project and throughout the project. Of course, no one really knows what will happen, but the historical information can increase the likelihood of project success.

2.2 Given a scenario, perform activities during the project initiation phase  During project initiation, much of the focus is on launching the project and creating the project charter. However, this exam objective includes three subobjectives discussed in this chapter:

•   Identify and assess stakeholders  Stakeholder identification is done early in the project and the assessment of stakeholders is done to determine who has the influence, power, and authority for the project decisions.

•   Review existing artifacts  The historical information from past projects to better manage the current project.

•   Determine solution design  Technical projects require a good technical design to meet the expectations for performance, reliability, scalability, and other success factors.

Applying these three exam subobjectives can help the project manager and the team complete the project successfully. The identification of the key stakeholders will directly affect the solution design of the project scope. Existing project artifacts can save time, cost, and frustration as this historical information is proven information for the project team to utilize.

2.3 Given a scenario, perform activities during the project planning phase  In this chapter, I talked about the final project acceptance criteria and how you and the stakeholders need to establish early in the project how you’ll know the project’s done. The details of the project scope, the detailed objectives, and the project acceptance criteria all need to be documented and agreed upon between the project manager, the project sponsor, and the key stakeholders. Recall that the project scope statement actually has six components:

•   Product scope description  The features and functions of the product, service, or result your project will create

•   Product acceptance criteria  The conditions that must be true for the project deliverables to be accepted by the stakeholders and for the project to be considered done

•   Project deliverables  The things your project will create; remember, project deliverables can be more than just the product scope fulfillment

•   Project exclusions  The things and conditions your project won’t create

•   Project constraints  The limitations the project manager must deal with in the project; time, cost, and resources are common constraints

•   Project assumptions  The things that are believed to be true but have not yet been proven to be true

The project scope must be approved by the project sponsor and the key project stakeholders. When changes enter the project, the project scope likely will need to be updated to reflect these changes. Changes to the project scope will cause changes in the project’s WBS and WBS dictionary, too.

The WBS is a visual decomposition of the project scope statement. The WBS dictionary is an indexed definition of every component of the WBS document. You’ll need the WBS and WBS dictionary throughout the project, not just during project planning. The process of creating the WBS dictionary can happen by identifying project phases, milestones, or major deliverables within the project and then subdividing these elements into smaller, more manageable components. The smallest element in the WBS is the work package; work packages can be cost-estimated, scheduled, monitored, and controlled.

The WBS is not an activity list, but consists of deliverables that in turn will equate to the project scope. The work packages in the WBS will help the project team create the activity list. Each element of the WBS, from the largest to the smallest work package, can be identified by using a code of accounts numbering system. The code of accounts uses a sequential approach of appending a globally unique identifier to each element of the WBS. For example, a project that has a project code of 431 and includes a deliverable of three print servers could identify each print server as 431.1, 431.2, and 431.3. Each print server could be subdivided again if there were additional deliverables in the server that you needed to account for.

The subdivision of project elements should generally follow the 8/80 Rule, which states that deliverables in the WBS should not be decomposed smaller than the equivalent of 8 hours of labor or larger than 80 hours of labor. This is a general rule and doesn’t, of course, apply to all situations.

Chapter Review

Every predictive project demands a project scope statement, a work breakdown structure, and a WBS dictionary. These three project documents compose the scope baseline, and the project manager and project team will rely on the scope baseline to consider every major project decision going forward. At the heart of the scope baseline is the WBS—it’s a detailed look at the things your project will create for the stakeholders and for the organization. Agile projects are less rigid in planning and utilize the product backlog.

Decomposition is the process of breaking down the project deliverables into a logical order. As a rule, work packages do not need to be broken down into granular step-by-step tasks, but rather tight, individual units that can be scheduled, can have costs estimated, and can be monitored and controlled. The 8/80 Rule can help the project team gauge how large or small the work packages should be in the WBS.

A code of accounts is a numbering system that can provide order to the WBS. The code of accounts is a unique identifier for each element in the WBS to pinpoint each element in each of the major deliverables of the WBS. The code of accounts should also be included in the WBS dictionary for each WBS element so that it’s easier to match up the conditions, characteristics, and other attributes of an element from the WBS to the physical creation of the deliverable.

There are multiple ways to create a WBS, and any combination can be used as long as the end result depicts the exact project deliverables and expectations of the project stakeholders. A WBS, once completed, needs approval from the project sponsor first to confirm the scope decomposition and how the scope meets the project scope requirements. Once you and the project sponsor are in sync on the scope, WBS, and WBS dictionary, the key stakeholders need to sign off on the WBS to ensure that all of the project deliverables are accounted for as they’re defined in the project scope statement.

Exercises

These exercises allow you to apply the knowledge you have learned in this chapter and are followed by possible solutions.

Exercise Solutions

The following offer possible solutions for the chapter exercises.

Questions

1.   You are the project manager for a project that will develop in-house software used to monitor a computer parts inventory. Your project sponsor asks that you begin working on the WBS. What is a WBS?

A.   A breakdown of the project work activities

B.   A decomposition of the project scope

C.   Weekly deadlines for the project

D.   A topology of the project team’s responsibilities

2.   You are the project manager for the NQQ Project. You have been working with the project team to create the WBS and have now decomposed the project down to work packages. What is a work package?

A.   A unit of work that must be completed before the next unit can begin

B.   The smallest unit of work that can be performed by the team as a whole

C.   The smallest decomposed object in the WBS

D.   One of the three parts of any project: the introduction, the implementation, and the project wrap-up

3.   You are working with your project team to decompose the project scope down to the work packages. Some of the project team members are concerned that you’ll want to subdivide the deliverables to a very granular level rather than trust the project team to do their work. You assure them that this won’t happen, because you’re using the 8/80 Rule. What is the 8/80 Rule?

A.   How long a phase should last

B.   A heuristic that says a project should not last more than 8 months or less than 80 days

C.   A heuristic that says a task should not last more than 80 hours or less than 8 hours

D.   A description of a collection of tasks within one phase

4.   Grace is the project manager of a small project for her organization. You are serving as a project management consultant to this project. Grace tells you that because her project is so small, she doesn’t feel the need to create a WBS. You tell Grace that it’s in the project’s best interest for her to follow through and create the WBS. Why must Grace and the project team create a WBS?

A.   The WBS allows the project manager to work backward from the targeted date to assign tasks.

B.   The WBS allows the project manager to assign resources to tasks.

C.   The creation of the WBS ensures that all of the project deliverables are fully identified and decomposed so that the necessary resources may be obtained and assigned to the work.

D.   The WBS allows the project manager to assign multiple team members to multiple tasks to speed up the implementation.

5.   You are leading a project to create a new application. Todd, a key stakeholder, wants to review your project’s work breakdown structure. You report that there is not a WBS in this project. Todd is upset and demands that you create a WBS. Why would you not create a WBS?

A.   To ensure maximum billable hours.

B.   Because the project is too small to warrant a WBS.

C.   All of the requirements haven’t been gathered yet.

D.   You are utilizing an agile approach in the project.

6.   You are the project manager for your organization and are reviewing the requirements for your new project. The business analyst has completed the requirements and is consulting with you on what each requirement is and why it’s important to the project stakeholders. You would like to create a table that maps each requirement, its characteristics, when the requirements will be created, and other information. What type of a table would you like to create?

A.   RACI chart

B.   Roles and responsibility chart

C.   Requirements traceability matrix

D.   WBS dictionary

7.   You are the project manager for your organization, and you and the project team are creating your WBS for a software development project. You are mapping the WBS to phases within your project. Of the following, which one is the end result of a phase that can help in the WBS creation?

A.   Milestones

B.   Project management life cycle

C.   Deliverables

D.   Project funding

8.   All of the following components are part of the scope baseline except for which one?

A.   Project charter

B.   Project scope statement

C.   Project WBS

D.   WBS dictionary

9.   You are the project manager for your organization and are working with your project team to create the project scope statement. Part of the scope statement is to define the constraints and assumptions that you must work with in the project. Which one of the following is an example of a project assumption?

A.   A predefined schedule

B.   A predefined budget

C.   Interoperability of the software and existing hardware

D.   A requirement to include scalability in the hardware you add to operations

10.   What is the name of the numbering sequence a project manager can use to identify the components of a WBS?

A.   Code of accounts

B.   Chart of accounts

C.   WBS dictionary index

D.   Project glossary

11.   Nur is the project manager for the NAA Project in her organization. She is about to create the WBS based on the approved project scope for her project. She would like to include several key stakeholders in the creation of the WBS. What is the primary benefit of including the stakeholders in the WBS creation process?

A.   Including stakeholders ensures that all of the requirements are identified and captured.

B.   Including stakeholders ensures that the stakeholders know who the project manager is and who the project team members are.

C.   Including stakeholders ensures that the stakeholders see that all of the requirements have been identified and are accounted for in the project.

D.   Including stakeholders helps to promote shared ownership of the project.

12.   Which one of the following is not needed when creating a WBS?

A.   Project team members

B.   A preferred sequence of project activities

C.   A project scope

D.   Identified project deliverables

13.   You are the IT project manager for a project to install a new mail server. Which of the following describes the best approach to creating the WBS?

A.   Create a sample WBS and give it to the project team to complete.

B.   Work with the project team to create a sample WBS and give it to management.

C.   Work with the project team and the key stakeholders to create the WBS.

D.   A project of this size does not need a WBS.

14.   One of your primary concerns with the project scope is that the stakeholders may add requirements once the project is in motion. Why should the project scope be guarded against even simple additions?

A.   It adds team members to the project.

B.   It distracts the team members from the project.

C.   Additions, even simple ones, can greatly impact the success of a project.

D.   Additions, even simple ones, must be approved through the project sponsor.

15.   What should signify the end of each phase?

A.   A milestone that has been reached

B.   A party for the project team

C.   A date that has been established within the WBS

D.   A definite deliverable result

Answers

1.   B. A WBS is a decomposition of the project scope. It serves as input to five key processes within a project: cost estimating, cost budgeting, resource planning, risk management planning, and activity definition.

2.   C. A work package is the smallest decomposed object in the WBS. Work packages can be scheduled, cost estimated, monitored, and controlled.

3.   C. The 8/80 Rule is a guide that says a project activity should not take less than 8 hours or last more than 80 hours.

4.   C. A WBS is deliverables-oriented decomposition of the project work. It is a process to ensure that all of the required deliverables are identified and broken down into manageable components so that resources and labor may be assigned to complete the project work.

5.   D. The best choice is that you are utilizing an agile approach in the project so there is not a WBS. Agile projects have a prioritized product backlog and welcome changes throughout the project. Predictive projects use a WBS and are averse to changes. Agile projects don’t have the same upfront planning that traditional waterfall projects rely on.

6.   C. A requirements traceability matrix is a table that traces the individual project requirements to the actual creation of the requirements. It can include information about the requirement, such as the owner, the phase when the requirement is expected to be created, and other information.

7.   A. Milestones are typically the end result of phases, and they show progress toward project completion. Once you have identified the project milestones, the project life cycle phases used in the WBS can become more clear and distinct.

8.   A. The project charter is not part of the scope baseline. While you’ll need a project charter to authorize the project and identify the project manager, it’s not part of the scope baseline. The scope baseline includes the project scope statement, the WBS, and the WBS dictionary.

9.   C. Of all the choices presented, only the interoperability of the software and existing hardware could be an assumption. The predetermined budget and schedule are constraints, as is the scalability requirement. Assumptions are things that are believed to be true though they may not have been proven to be true.

10.   A. A code of accounts is the numbering sequence project managers use in the WBS to identify the various components of the project scope decomposition.

11.   D. A valuable benefit of including stakeholders in the creation of the WBS is to promote the idea of shared ownership between the project team and the stakeholders.

12.   B. The WBS is not concerned with the order of activities. Activity sequencing and scheduling, however, will be the process that helps the project manager determine the correct order and relationship of activities.

13.   C. Creating a WBS is not a solo activity. The project manager should work with the project team and any key stakeholders to create a WBS.

14.   C. Additions to the project scope can have huge impacts on the deliverables of a project. Often additions are tossed into the plans without adequate foresight or care, so their consequences can throw a perfect plan off balance. Do not change the scope of an existing project unless it is absolutely required.

15.   D. Just as each project produces a definite deliverable, so should each phase. A milestone does not necessarily signify a phase has ended, because there can be multiple milestones within each phase. A party for the project team (while always an excellent idea) does not prove that a phase has officially ended. Dates, while targets for completion, do not signify the end of a phase—the deliverable proves the end of a project phase.