ScopePlanning

THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE

• 1.5 Given a scope definition scenario, demonstrate awareness of the need to secure written confirmation of customer expectations in key areas.
• 1.6 Given a project initiation document (a project charter or contract), including a confirmed high-level scope definition and project justification, demonstrate the ability to identify and define key elements.
• 1.7 Given a project initiation document (a project charter or contract), including the client s highest priority between quality, time, and budget, estimate a number of elements.
• 1.9 Given a proposed scope definition and based on the scope components , assess the feasibility of the project and the viability of a given project component against a predetermined list of constraints.
• 1.10 Recognize and explain the need to obtain formal approval (sign-off) by the project sponsor(s) and confirm other relevant management support to consume organizational resources as the project scope statement is being developed.
• 1.11 Given an incomplete project scope definition, complete or rewrite the definition to (1) reflect all necessary scope components or (2) explicitly state which is included in the project and which is not.
• 1.12 Identify possible elements of a final project scope definition and the circumstances in which they would be appropriate.
• 1.14 Recognize the need to obtain consensus of stakeholders and to obtain buy in from the team to proceed to the planning stage of the project given a high-level estimate of scope, schedule, budget, and resources.
• 2.6 Given a project description/overview and a list of the project business and technical requirements, perform key tasks to ensure project success.
• 2.7 Describe the goals of a useful project requirements review with the client (e.g., verify mutual understanding of client s product delivery, product performance, and budget requirements, etc.) and describe when it is important to have such reviews.
• 2.8 Given the client s approved project requirements and the input of stakeholders, decompose these requirements into business and functional requirements while maintaining trace ability within strict configuration control.
• 2.9 Given a project planning scenario, demonstrate an understanding of and the ability to develop a phase-oriented WBS with high detail for an early phase and with low detail for later phases.
• 2.10 Given a scenario involving tasks, resources (fixed or variable), and dependencies for a multiphase IT project, demonstrate knowledge of the standards for creating a workable WBS.
• 2.11 Recognize and explain the need to obtain consensus and formal approval (sign-off).

Now that we have covered the initiation process and have an approved project charter, it is time to talk about project planning. Planning can be one of the most overlooked areas of project management. Once a project is approved, everyone just wants to run off and start working. As a project manager, you may even find that your organization does not support taking the time to do planning. If you have ever had an executive call you to task for wasting valuable time planning when there is work to be done, you know what we are talking about.

A good understanding of the planning processes will prepare you to communicate within your organization about the benefits of taking time up front to define all aspects of managing a project before the work actually starts. Starting with this chapter and continuing through Chapter 7, Creating a Comprehensive Project Plan, we will cover all the aspects of project planning. Our first planning topic is project scope.

Project scope is defined as the size of the work involved to complete the project. As a project manager, you need to be aware of what is included in the project as well as what is excluded. Scope planning will assist you in getting your arms around a project and setting the boundaries for what is included in the project.

You need to define and document three scope components to complete scope planning: the scope statement, scope management plan, and work breakdown structure (WBS). The scope statement provides a common understanding of the project by documenting the project objectives and deliverables. The scope management plan documents the procedures that you will use to manage any proposed changes to the project scope throughout the life of the project. The final component of scope is the work breakdown structure, which breaks the project deliverables down into smaller activities from which you can estimate task durations, assign resources, and estimate costs.

Scope Overview

Imagine trying to work on a project without knowing your expectations, limitations, or the nature of what you re producing. Would you even be able to begin a project without knowing these things? Luckily, in the project management business, there are rules and processes that help project managers define the limits of a project.

Scope puts boundaries around your project. Scope is like putting a fence around your property. The fence is a clear definition of where your property starts and where it ends. It is clear to anyone looking at your property what is included and what is excluded. Scope planning serves this same purpose for a project.

The project scope is the work that is done to deliver the product or service. Although this sounds simple and straightforward, a poorly defined scope can lead to missed deadlines, cost overruns, and unhappy clients . Good scope planning helps ensure that all of the work required to complete the project is agreed on and clearly documented.

Scope planning builds on and adds detail to the outputs you have created for the project charter. Scope planning is the starting point for defining the activities required to deliver the product requirements that were discussed in Chapter 2.

Depending on the detail of work completed for project initiation, scope planning may also include a more detailed analysis of the product, a cost/benefit analysis, and a look at alternative solutions. You may find that some of the work required for scope planning has already been completed during the initiation process. If that is the case, congratulations, as you are now ahead of the game.

The processes to define the scope planning elements are iterative, do not always occur in sequence, and can overlap. Regardless of the sequence, scope planning produces a scope statement, a scope management plan, and a work breakdown structure. Let s take a look at what is required to complete each of these.

It s important to understand that PMI s A Guide to the PMBOK defines scope definition as the process of breaking down the major deliverables from a scope statement to create the WBS. For the purposes of the CompTIA objectives and exam, scope definition is used in a much broader sense to cover several scope planning elements including the scope statement and the scope management plan.

Project Scope Statement

Have you ever received a bid to do remodeling work on your house? A remodeling bid typically includes a description of the work to be done, a list of the major deliverables, estimates for time and cost, and any assumptions and constraints. A contractor tells you in writing that he will remodel your bathroom (description) by replacing the countertops, flooring, and tile (deliverables) in six weeks at a cost of $4,550. The bid assumes no change to the existing bathroom fixtures and a stated grade of countertops and tile. The start of the project will be constrained by whether the chosen tile is in stock or must be special ordered. The bid documents the agreement between the contractor and the homeowner as to the scope of the remodeling work.

A project scope statement serves a similar purpose to the remodel bid. A project scope statement documents the agreement between the project manager and the stakeholders as to what is included in the delivery of the project. It is the foundation for defining the activities required to complete the project, and it will be used as a baseline to manage change requests to the project. Any major deliverable , feature or function, that is not documented in the scope statement is considered a change. Typically, the scope statement includes a project justification, product description, major deliverables, success criteria, time and cost estimates, assumptions, and constraints.

Let s take a closer look at what is included in each of these.

Project Justification

In the project justification portion of your scope statement, you must state the reason the project is being undertaken and document the business need that the project will address. You want to be clear what is driving the project request. Is the project creating a new product for external customers? Is the project developing a new system for an internal organization? Is this a legal mandate ? The project justification identifies the source of the project request.

It is very important that any legal requirement behind the project request be documented in this section. This alerts anyone reading the scope statement that this is not an optional project.

Product Description

In your product description , briefly describe the features or function of the product. The description is what makes the product unique . (Remember that uniqueness of the product is part of the definition of a project.) You need to be as precise as you can using all of the data you have available. It may be appropriate to include not only the features or functions the product includes, but features or functions it does not include, if doing so will add clarity to your description. You can use your existing product description from the project charter and make changes or refinements based on any additional information you have obtained.

Tip

By listing both included and excluded features, a product description narrows and clarifies the technical work that is required to produce this product ”and keeps customers from coming back at product creation time to ask you for more for goodies to be added.

Major Deliverables

In the major deliverables section of the scope statement, you will list the summary level achievements that make up the delivery of the product. It can be easy to get hung up on just the end result when you are listing the major deliverables. When you are putting together the deliverables section, make sure that you focus on the entire project. Your end result may be a new software application for the company s sales agents , but there are other deliverables besides the application itself. Do not overlook key areas such as user documentation, user training, or help-desk training, to name a few. If you include at least one deliverable from each organization represented on the project team, it will show the big picture of what is involved in completing this project.

Success Criteria

Under success criteria in the scope statement you will define the measurable business results the product is expected to produce. This section is where you address items such as an increase to corporate revenue, a higher productivity rate, compliance with regulatory procedures, or reduced staffing needs. This section is very important as a tool for evaluating the project after it is complete. This is the section the stakeholders can reference to compare the actual business impacts of the project with the projected impacts. You want to define the success criteria so that each one can be measured. Criteria such as become an industry leader or provide world class service may sound good, but aren t measurable. It is much better to state a sales figure, a revenue figure, or a customer waiting interval that can be measured and compared to that same data collected prior to the completion of the project. The idea behind success criteria is to supply metrics by which people can gauge whether or not the project was successful.

Completion Criteria

Completion criteria denotes what needs to be delivered. For example, you may stipulate in your scope documentation that the system will be fully functional at delivery time. Or, you may choose to stipulate that the project will be considered complete after a 3-month period of testing to make sure that all components are working correctly.

Time and Cost Estimates

In the time and cost estimate portion of the scope statement, you ll provide an estimate of the time it will take to complete all of the work and the current high-level estimates for the cost of the project. These will be order of magnitude estimates based on actual duration and cost of similar projects or the judgment of someone familiar with the work involved in the project. These do not have to be precise estimates. A high-level estimate may also use ranges for either time or cost, in some cases including a worst case, best case, and most likely scenario.

Note

Estimates made during scope planning may be stated in different ways depending on the estimating method used. An estimate made strictly from the actual time and cost of a similar project is stated: Based on the results of Project XYZ, it is estimated that New Project MAL will take three months to complete and cost $350,000. An estimate for the same project based on using ranges is stated: New Project MAL will take between one and six months to complete at a cost of $100,000 to $500,000. The most likely scenario is four months at a cost of $400,000.

The time estimate for a new product created by market demand may also be defined based on the window of opportunity to market the product.

Target Completion

You may be asked to provide an estimated or target date for project completion. You really do not have enough data at this point to make a precise estimate. If you are forced to provide an estimated date in the scope statement, use either a month or a quarter, such as July 2004 or third quarter of 2004 instead of a specific date. When providing a target completion date, always include an assumed start date; otherwise , if the project starts later than anticipated, your sixmonth estimate may become three months.

Level of Confidence

Project estimates may include a caveat regarding the level of confidence the project manager has in the accuracy of the estimates. Estimates made during scope planning are based on very little detail, so don t say you are 90 percent confident just because that is what your client or your sponsor wants to hear. Cost estimates made during scope planning are commonly as much as 75 percent off the actual budget figures. We will talk more about the different types of cost estimates and the typical range of accuracy for each estimate in Chapter 5, Cost Planning.

Assumptions

In the assumptions section of the scope statement, you ll document the beliefs the team shares regarding the project. An assumption is an action, a condition, or event that is believed to be true. The problem with assumptions is that they may not be common among all project team members or stakeholders. You may think something is obvious, but if it is not written down, chances are other players will have a different opinion. Assumptions must be shared, agreed on, and documented.

A key area to review in defining assumptions with your team is to discuss and document both what is included and what is excluded from the project. This is a good way to further clarify and bound the project scope. If you are developing software for a new desktop support system, you may assume that the software will be deployed on the existing computers at the client site. The client may assume that new workstations are part of the project. You will need to document in the assumptions section that the software will be deployed on existing workstations.

Constraints

The last part of your scope statement is the constraints list. A constraint is a restriction that will impact the outcome of the project. There are two types of constraints. The first are the constraints that apply to all projects. Every project faces potential constraints in time, budget, scope, or quality. From the start of the project at least one of these areas is limited. If you are developing software to support a new product with a very short market window, time will be your big constraint. If you have a fixed budget, money will be your constraint. If both time and money are constrained, quality may suffer. A predefined budget or a mandated finish date needs to be factored in to any discussion of project scope. Scope will be impacted if both time and budget are constrained. As the project progresses and scope changes are requested , scope may become a constraint that drives changes to time, cost, or quality.

Note

You may have heard the term triple constraint bandied about by project managers. Some project management books reference only three constraints: time, cost, and quality. Although you may still see the phrase triple constraint used in project management, be advised that most project managers think about project scope as a fourth constraint.

The second type of constraint is that specific to a project. These constraints may involve the schedule or previous commitments of human resources you need or the availability of a test system.

The push and pull of project constraints is an issue the project manager must deal with throughout the project life cycle. If a constraint is placed on time, cost, scope, or quality during up-front planning, now is the time to communicate with your stakeholder team regarding the impact of constraints. The project manager needs to have an understanding as to how the client prioritizes these constraints and be able to communicate possible scenarios that might occur as the project moves forward. As an example, if cost is cast in concrete during the planning phase, the client may have to give up functionality and scale down the scope of the project once more definitive cost estimates have been made. As you can see, the scope statement contains a lot of important project information. Let s take a look at a sample scope statement to help you put all the pieces together.

Real World Scenario ”Sample Project Scope Statement

Imagine you are a project manager for a wireless telecommunications carrier in charge of a project for a new consumer product called Voice Activated Dialing (VAD). The product is critical to the corporate strategy to become one of the top three carriers in the markets where your company offers wireless service. Using your high-level requirements, the project charter, and input from various team members and stakeholders, you are ready to create your project scope statement.

Here is what your project scope statement might look like.

Project Justification: Market research and customer feedback indicate that a demand for Voice Activated Dialing (VAD) has increased 40 percent over the past three months. One of our competitors has already announced a launch date for this product, and two others are expected to follow within the next two months.

Our market share growth is expected to decline by 20 percent if we do not add VAD as part of our product mix.

Product Description: The product features included in Voice Activated Dialing are dialing by speaking a phone number or name into the phone and the ability to create address book entries from a website. Voice Activated Dialing does not include the ability to add/edit/delete address book entries over the phone or an interface to personal information managers.

Major deliverables:

• Product requirements defined
• System requirements defined
• System requirements developed
• Sales training developed
• Customer service training developed
• System enhancements implemented
• 3,000 Sales consultants trained
• 500 Customer service technicians trained
• Marketing communication plans executed in all markets
• VAD available in all markets

  Success Criteria: The launch of VAD will generate $2.5 million in incremental annual revenue for the corporation.

  The additional training required for sales consultants to be knowledgeable in offering the VAD product will increase the total sales consultant training package time by no more than two hours.

  Time and Cost Estimates: VAD must be completed within six months for the company to be a viable player in this market.

  The development and launch of VAD is estimated to cost $750,000. This includes all IT work, sales consultant training, customer brochures , and the marketing campaign. This is a high-level estimate based on the schedule and cost of a similar new product. Estimates will be refined as more detailed data is available.

  Assumptions: IT has resources to implement system changes within the six-month time frame we need to start offering VAD.

  Fifteen percent of our customers will add VAD to their current service option. Product will have a 15 percent take rate. VAD will be priced at $4.95/month.

  Constraints: Billing releases are only done on a quarterly basis. The enhancement to bill for VAD must be scheduled within those parameters.

  The window to obtain a share of the VAD market is six months.

  As you can see, a lot of very important information is included in the project scope statement. From reading the VAD sample scope statement, you know the strategic value of the product, the features included and excluded in the product, the anticipated revenue the product will generate, and the aggressive schedule that must be met. This document can be used to give a clear and concise overview of the project to clients, team members, and other key stakeholders.

Review and Consensus

Once you have completed the scope statement, hold a review session with your entire project team to make sure that everyone is in agreement and there are no unresolved issues. Individual team members may have worked on specific sections of the scope statement, and a formal team review of the entire document will confirm that everyone is on the same page and prevent later misunderstandings of the project scope. Once the project team has resolved any outstanding issues, present the scope statement to all of the stakeholders and obtain approval from the project sponsor and the client. Other approvals may be required depending on the policies of your organization.

If any changes are made to the scope statement during the review with the client and the sponsor, you will need a follow-up meeting with the project team to cover the changes and discuss the impact on the project. One of your most important duties as project manager is to keep your team informed. We will talk a lot more about how to communicate with your project team in Chapter 6, Additional Planning Processes.

With our approved scope statement in hand, we are now ready to create a scope management plan.

Scope Management Plan

Now that you have an approved scope statement, the real work begins. You may have heard horror stories from other project managers. How do you keep this thing from growing out of control and choking any chance you may have to successfully complete the project? You need to master that dreaded demon that has plagued every project manager ” scope creep . Scope creep is the term commonly used to describe all those minor changes or small additions that just seem to happen out of nowhere, until suddenly you are not managing the same project anymore. The solution, of course, is having a plan.

The scope management plan documents how you will manage changes to the scope. Project scope change is inevitable with the majority of projects. The key to dealing with scope change is how you handle it. In our experience, you save yourself a lot of pain during project execution if you take the time at the start of the project to define the basics of how the team will handle requests for any changes to the defined scope.

If the project team defines the basic scope management framework early in the planning process, each team member has a point of reference to communicate with clients and stakeholders who may come to them with something they forgot to mention when the scope statement was approved. Everyone involved in the project needs to understand that the rules set up at project implementation time need to be followed to make a request to change the scope of any project. Without a documented plan, you will soon find that interested parties are talking to team members and changes are happening. The team members will, understandably, want to try to accommodate the client s needs. But without analysis of the impact these changes, adding 10 or 20 minor code changes may put your schedule or your budget in jeopardy.

Key items to consider when you are developing a scope management plan include:

Stability of the scope You probably have some indication at this point in the project as to how stable the scope is based on the work you have already done to define requirements, prepare and review the project charter, and define the scope statement. If you found major disagreement between stakeholders or gaps in the product description, you have a high probability for scope instability.

Impact of scope changes If you are constrained with a dictated finish date, any scope change can be critical. Adding to the scope of the project may also impact the budget. Do you have available resources to add to the project to complete the additional work? What is the process for securing additional funding?

Scope change process One of the primary reasons a project gets out of control is the lack of a documented process for scope changes. Clients and stakeholders will go directly to team members and before you know it, people will be working on deliverables that were never included in the scope statement.

Your scope change process needs at a minimum:

• A standard form to submit the request. Information required on a scope change request includes a description of the change, the reason for the change, and the originator of the request.
• An analysis of the impact of the request on the scope, budget, schedule, and quality of the project. The results of the analysis can be added to the form used to submit the request, so that all pertinent data in is one location.
• An approval process to accept or reject requests. This can range from ad hoc meetings called as scope changes are received to a formal change review board that meets on a regular basis.
• A communication plan to keep stakeholders informed of the status of requests.
• A method to incorporate approved changes into the project plan.

The implementation of your scope management plan will be discussed further in Chapter 9, Project Control.

Tip

You can see why project managers are so interested in making sure they ve established the scope of the project as best as they can before any work starts. Generally speaking, if you ve done due diligence and tightly defined the scope of the project, with the exception of very minor changes, most new requests for changes on an IT project should be considered for Version 2 of the product and included in a brand new project after the first one concludes.

The Work Breakdown Structure (WBS)

The final element of scope planning is the work breakdown structure (WBS), where the project team starts decomposing the project deliverables. Decomposition is the process of breaking down the high-level deliverables into smaller, manageable components from which you can do time estimates, resource assignments, and cost estimates. The WBS is a deliverables-oriented hierarchy that defines all of the project work. Each level has more detail than the previous level.

A WBS is one of the fundamental building blocks of project planning. It will be used as an input to numerous other planning processes. It is the basis for estimating activity duration, assigning resources to activities, estimating work effort, and creating a budget. Because the WBS is a graphical representation, it can be a better vehicle for communicating the project scope than the charter or scope statement. It also contains more detail to further clarify the magnitude of the project deliverables.

The WBS acts to put boundaries around the project. Any work not defined in the WBS is considered outside the scope of the project. A WBS is a tool that can be used to keep customers, team members, and stakeholders focused on what is included in the project scope.

Like a blueprint used to build a building, the WBS is the document that will be used to build your project s product.

It is important that the project team devote adequate time to develop the WBS. Development of the WBS should focus on all aspects of the project and all impacted areas of the business.

The team may go through several iterations to complete the WBS. Once the team concurs that the WBS is complete, review sessions are scheduled with the client, the sponsor, and key stakeholders to examine and approve the WBS.

Organizing the WBS

The quality of your WBS depends on having the right players involved in the development. Provide adequate notice when you schedule a WBS session. Involve as many project team members or functional representatives as possible. Project team members may not be named at this point, but you ll probably have a good idea of the various groups or departments that will be involved based on the list of project objectives and deliverables. Work with functional managers or if necessary your sponsor to get representation from each group . A WBS is not something that should be developed in a vacuum . A WBS developed in isolation by the project manager frequently misses key components of the project. It is also more difficult to get buy in on something people had no input on.

A WBS is typically created using either a tree structure diagram or an outline form. A tree structure is the best method to use with a project team. The structure can be created on a white board or easel paper using sticky notes to write the tasks. This allows for tasks to be moved around as you work though the process. Figure 3.1 is an example of a template that can be used to create a WBS.

Figure 3.1: WBS Template

The space you reserve to conduct the WBS development needs to be adequate to allow all participants to see the work in progress. You need to encourage brainstorming. You can always remove or move activities as you work through the process or when you do subsequent reviews. Make sure that all of the participants have reviewed all previous documentation like the charter and scope statement. Have copies of these documents available as reference. They will be your starting point for creating the WBS as well as a reference if there are questions.

Decomposing Major Deliverables

Decomposition, the breaking down of the project deliverables into smaller components, can be a challenge. Let s take a closer look at this tree diagram and how to work your way through the creation of a meaningful WBS.

The highest level of the WBS tree diagram encompasses the entire project. This level is referred to as level 1. The next level, level 2, relates to the high-level project deliverables defined in your scope statement. This level usually takes the form of listing the deliverables themselves . We have also seen this level show the phases of the project life cycle, the departments involved in the project, or a geographical focus. There is not one correct way to create a WBS, but the method you choose must be a logical way to break things down for your particular project.

Take for instance a simple home improvement project such as painting a porch. Figure 3.2 shows a few of the project deliverables for painting the porch. You ll notice that level 1 is the porch-painting project itself, and level 2 demonstrates the deliverables needed to paint the porch.

Figure 3.2: Starting a WBS

Project Planning Using the Tree Structure

You can begin brainstorming a WBS by utilizing the tree diagram and a bunch of sticky notes on a white board.

Recently we had to move 2,000 users from various places around the city into one centralized location ”a brand new 11-story building. Each of these groups of users had a different function in life, with different managers and move timelines . Imagine the complexity of making sure that you move all the users computers into this new building at different times and making sure that everything works. Now imagine that you re trying to figure out all the obstacles and tasks even before the building is complete ”you re trying to get an advance feel for what s involved.

Our project managers started this effort by getting various stakeholders into a room and then, as ideas were voiced, writing them down on sticky notes and pasting them to a white board. Another person began to arrange the notes into some sort of logical order. One stakeholder, for example, might cry out Make sure all monitors work! while another would say We need our email to work when we come in on Monday. Each of these sticky notes had something to do with powering up the machine and validating that it was connected to the network.

In time, as we fleshed out various components of the project, the white board looked just like a tree with yellow leaves all over it!

 

As Figure 3.2 illustrates, you should always work through level 2 before moving down to the next level of decomposition. This method will help you make sure you encompass all of the project goals.

Each subsequent level should be a breakdown of the previous level. In our porch-painting example, we have taken Prepare Porch and decomposed it as shown in Figure 3.3.

Figure 3.3: Decomposing a Major Deliverable

The process continues until a task does not need to be subdivided again. You need to get to a level of detail that generates manageable activities, but do not go down to a level of detail that you cannot track and control. PMI s A Guide to the PMBOK refers to the lowest level of the WBS as a work package . The work package is just how far down you need to go to decompose the deliverables.

Guidelines for Creating a WBS

Getting started creating a WBS can sometimes seem overwhelming. we ve found that a lot of people who struggle with this process are actually taking on more work than they should. Once you start breaking down your deliverables into activities, there is a temptation to immediately put the activities in order (called sequencing the activities) or estimate the length of an activity so you can just get people started on the work. Unfortunately, this type of behavior usually leads to a situation where key deliverables are missed or task sequences are incorrect because many tasks were not defined. The clock is ticking and people are working hard, but not necessarily on the right things, because time was not taken to create a thorough WBS. Although there is no one right way to complete a WBS, there are some tips on pitfalls you can avoid to help you be more successful. Here are some guidelines that we find helpful to review with project teams before diving into a WBS session.

Recruit knowledgeable as well as available resources. Do not try to complete the WBS yourself in the interest of saving time. If you are not an expert on the deliverables, you will miss key elements. You also want the team members to do the work so that they buy into what has been created. Involving knowledgeable team members in the creation of a WBS is far more effective at communicating what the project is all about than handing someone a completed WBS. If there are team members who will be involved in the project but who cannot participate in the session, make arrangements to get input from a representative at a separate session. Ideally, you want everyone in the same room, but if that is not possible make sure you get the input in some other fashion.

Work though all items at level 2 before you go down to the next level. You should be confident that the entire work of the project is represented at the high level. If you are completing the WBS as a team exercise, you will need to control the tendency the team may have to start decomposition immediately once a deliverable has been put up on the board. This is a natural inclination, once people see a deliverable, to start thinking of what it will encompass. As a project manager, you need to take control of the situation and remind the team to not decompose anything until all of the high-level deliverables have been identified. Otherwise you may end up putting tasks under a deliverable that are not really a part of that deliverable or worse yet miss a key component of the project. Keep referring the team back to the scope statement until everyone is confident that your high-level deliverables are covered. Then you can start decomposing.

Each item in a lower level is a component of the level above. Completion of all of the items in the lower level should mean completion of the higher level. As a checkpoint, you should always review the items at the lower level and ask the team if completion of those items will result in the task at the next higher level. If the answer to this question is no, than you have not identified all of the lower level tasks.

List all activities and continue to break them down to component parts . Make sure you get to a level where the team feels comfortable that resources can be assigned and estimates can be completed. Sequencing, assigning resources, and estimating are all separate activities that you will complete after the WBS is complete. We have seen many teams waste time doing separate tasks such as sequencing the activities while creating the WBS. These teams managed to break down the activities, but at the same time they got hung up with the sequence, which is not the goal of the WBS.

Do not create a To Do list. You should not decompose activities any further than to a level where they can be easily assigned, estimated, and produce a meaningful deliverable. Since the WBS will become the foundation for the project schedule, do not break down beyond a level that you can control. If you create a series of very short sequential tasks, you are expected to manage all of those tasks.

Let s take a look at the Purchase Materials deliverable for our porch project. Under Purchase Materials you could have just listed all the items you need to buy: sandpaper, sealer, paint, brushes, etc. But if you included your shopping list in your WBS, you would not have actually listed the activities that make the purchase complete. The items that you need to purchase to complete the porch project are only one of the activities associated with Purchase Materials. Your shopping list is referenced on the WBS by the activity Make a List, as shown in the completed Porch Project WBS in Figure 3.4.

Figure 3.4: Porch Project WBS

Use the appropriate number of levels for each leg. Each major objective will have a different level of decomposition to get to the point where you can do estimating and resource scheduling.

It is not uncommon for one leg to have three levels and another to have seven levels. You should be concerned about getting to a manageable activity, not on balancing the WBS. If you try to force an even number of levels across all deliverables, you will end up with some legs that are not broken down in adequate detail and others that end up listing all the steps to complete a simple task.

Create a numeric identifier for each item on the WBS. This is very similar to the format used for a numeric outline. Start at the left of the WBS and work across. Your major deliverables are 1.0, 2.0, 3.0, etc. As you move down a level, increment the second number. The level under deliverable 1.0 is labeled 1.1,1.2,1.3,1.4, etc. Figure 3.5 shows numeric identifiers added to the WBS we created earlier for the porch project.

Figure 3.5: WBS with Numeric Identifiers

Benefits of the WBS

The WBS is often listed as one of the most important components of a successful project. As you will see in later chapters, the WBS is an input to numerous project management processes. In our experience as a project managers, we have also found it invaluable in many other ways.

The WBS is an excellent tool for team building and team communication. With a graphic representation of the major project deliverables and the underlying activities, team members can see the project big picture and how their portion fits in. The direct link between a given activity and a major project deliverable can also help clarify the impact of an individual team member. As new resources are added to the project, the WBS can be used to bring these new team members up to speed.

A good WBS can be turned into a template for future projects. Software development projects frequently have a similar life cycle, and what was done on a previous project can be used as a starting point for a new project. This allows the team to take an existing structure and customize it to fit the new project. This is also an excellent way for teams to look at areas of the project they may not have thought about on their own.

The picture of the project scope the WBS provides is an excellent tool for communicating with clients and stakeholders. People do not always comprehend the magnitude of a project until they see the diagram of the project objectives and the activities required to reach those objectives. It also is an excellent tool to use when discussing staffing requirements or budgets . It clearly shows what work is included in the project. If something is not covered in the project objectives and supporting activities, it is not part of the project.

A detailed WBS will not only prevent critical work from being overlooked, it will also help control change. If the project team has a clear picture of the project objectives and the map to reach these objectives, they are less likely to go down a path unrelated to the project scope. We do not mean to imply that a WBS will prevent change; there are always changes during the project life cycle. But a WBS will clarify that a request is a change and not part of the original project scope.

Evaluating Your IT Project Scope

The scope of projects that IT project managers undertake should never deviate very far from the established deadline set down in the WBS. Yet there are elements within an IT shop that unexpectedly surface, serving to slip the scope far from its original moorings.

IT shops run into interesting twists and nuances that will very definitely impact the project scope and that may be beyond ordinary scope assessment and planning. Let s examine some things that you d want to think about when evaluating the scope of your IT project.

Size of the IT Shop

The size of an IT shop has a very direct impact on a project s scope. If you have a shop of only a handful of people, all of whom are constantly engaged on one project or another, then it s understandable that the scope of new projects depends highly on people s schedules. A major constraint is the limitation you have with human resources. Project priority comes into play in smaller shops as well. Suppose, for example, that all of your folks are working on a project when suddenly you re presented with a new project that s of much higher importance to the organization. What do you do ”drop everything you re working on and begin on the new project or wait until you finish the first? It s a tough call to make ”one that small shops are frequently faced with. If adequate assumption gathering hasn t been built into the first project (i.e., we assume that the project might be interrupted by more important work ) then you may be faced with a huge dilemma, one that impacts the scope, time, and cost (probably quality too, because it s tough for people to come back from a newer project and begin working on the old one without getting their sea legs back).

More importantly, IT shops that aren t heavily staffed might have a hard time simply maintaining the balance of the day s work, let alone take on new projects. And yet, in the interest of making sure that you meet your customer s needs (your end users are your customers, right?) you might be tempted to take on projects that you think you can effectively manage. In such situations, the server administrator also might be the one who manages the databases and so forth.

IT projects in minimally staffed environments such as the above often suffer from not having well- formed requirements and a well-developed WBS, never mind the rest of the support documentation.

For projects that have to be developed by folks in small or understaffed IT shops, it ll be key that you concentrate on making sure that the requirements are fully understood , that the WBS is very succinctly spelled out, and that your plan project fits within the confines of the schedules that the IT shop workers follow. In other words, you can t expect that a new Oracle database server project will be brought online in just a few days time by people who are busy running around with their hair on fire most of each working day. That is, unless you expect them to bring up the server during the night (which is precisely what some administrators do ”they re just too slammed during the day to finish projects).

Note

Communication with your business customers in such situations is very important ”you have to be sure that you communicate to stakeholders why the project can t be completed in the blink of an eye. Customers might suggest that some of the work be outsourced in the interest of time. But this recommendation (i.e., to bring in a vendor or consultant to help) might be met with some disfavor by the IT folks. The reasons for this are myriad. If the idea of outsourcing is acceptable to all concerned you should be quite sensitive to the way that you present the idea.

Definition of the Project Deliverables

Usually it s easier to define the deliverables of an IT project with obvious requirement outcomes . For example, suppose that you ve met with a business unit manager who wants a new software application written to meet a specific need. After some requirement-gathering efforts, you have a pretty firm idea of what the software s supposed to do. In talking with the folks in your IT shop you determine that the majority of your servers are Windows Server 2003, that the database of choice is Microsoft SQL Server 2000, and that there is plenty of room and hardware beef on which to host your application. From there the deliverables are pretty straightforward ”you just figure out how the program will be delivered to the user (thin-client? thick?), settle on a programming environment, and away you go.

But defining the deliverables when the outcome of the project is more esoteric can be challenging. For example, suppose that you have a project in which you re going to replace your current help-desk software system with one that s more robust. What are the deliverables? Well, they might include a new server or servers and certainly the new software. But other deliverables will also include conversion of the old help-desk database data to the new database, training the users how to use the new system, creating new custom reports that match reports you had in the old, and so forth.

It s like skeet shooting: it s easy to see that red clay disk when it s flying across blue sky, much more difficult to spot it when it s traversing the landscape. You have to think of all of the deliverables that a project is going to produce ”some of which aren t immediately obvious. As we mentioned earlier, for example, training stakeholders and creating support documentation are two of the deliverables you re likely to overlook if you don t really examine the complete output of your project.

Working with Your Business Clients

IT shops exist to serve the needs of the business unit end users. To that extent, an IT shop doesn t really have ownership in the organization s business processes and instead must rely on the input and expertise of the business unit to make a successful project. In other words you serve the business unit but you re not necessarily a part of it.

There are all sorts of things that fall out of this relationship that you might spot as adversely affecting the scope of your project. For one, consider the business unit director that loses interest in the project halfway through. Since the director is one of the project sponsors, how can you possibly proceed and satisfactorily complete the effort without her dedication?

Also, consider a business unit that s too busy to lend you an SME to help make sure that the deliverables actually match the unit s business needs. It s very difficult to simply assume that you know what your business unit needs when you don t have reliable input from those who actually do the day-to-day work. Many projects get done this way and they produce poor results.

What about the business unit that does all of its own research for a new COTS application, finds one that they think will work, then asks you at the last minute (almost as an afterthought) to implement the new program? The business unit stakeholders idea of the project s scope might very well be a whole lot different than your own!

You might handle these elements by putting them in the assumptions section of your scope statement. For example, It is assumed that marketing will lend the project team one full-time business representative for the first 30 percent of the project.

Success Criteria Tough to Define

Suppose that you are working on a new Internet-based e-commerce software application. One of the requirements of the application is that it must be guaranteed to be highly secure ”that transactions taking place on the system are well-secured and not privy to hacking.

How on earth do you evaluate such a requirement in order to provide evidence that the system is safe? Furthermore, what happens when, well into the system s creation, the operating system manufacturer reveals that there are known security gaps in the code and affected systems must be patched? How will this news affect the operation of the system you ve just created? Will the patching in some way affect your system s operation?

Like the items in the annual performance appraisal and report that your boss gives you every year, sometimes it s tough to put metrics to a subjective outcome. But you should try to pinpoint tangible reasons for why you re doing the project ”what your customers hope to accomplish by creating the deliverables.

Sidebar Systems and Undisclosed Process Elements

Perhaps the most devastating scope killers arise out of the belief that you ve completely uncovered the business processes only to find that your business end users are keeping track of some elements in their office automation software or, worse , they don t disclose all of their business processes because they either didn t think of them at the time you interviewed them, or they deliberately withheld some elements.

The first of these problems is what we call sidebar systems , meaning that users keep track of some things by using a spreadsheet or mini-database program, and then use that information to work with the primary system. For example, suppose that you have an old mainframe-based program that s been in use for 30 years. Its functionality isn t up to par with what the users require (and hasn t been for years ), so sidebar systems have been developed to overcome the system s shortfalls. At requirement-gathering, business-process-discovery time, users just don t reveal that these sidebar systems are in use ”they probably don t even connect the dots ”and as a result your system winds up missing some key functionality.

Alternately, users might not fully disclose all of the process elements involved in a business transaction for whatever reason. In some cases, a user might just be forgetful about all of the processes he or she goes through in order to successfully conclude a transaction. But sadly, in some instances, a user might be (subconsciously?) trying to sabotage the new effort. This sounds paranoid , but it actually happens. You can imagine the consequences when you get far down the implementation road only to discover that some pretty important process has been left out!

Mini Project Consultant Vendor Relationships

In projects that are smaller in scope, your relationship with a vendor or contractor may not be as important to them as ones with bigger budgets . While the vendor or consultant is certainly very anxious to assist you, they may have another project on the hook that has the ability to demand instantaneous use of their time, resulting in you being left high and dry waiting for them to return. This, of course, shoots your planned scope out into the stratosphere while you wait on the contractor to come back to finish something.

Real World Scenario ”The Sidebar System That Killed Your Scope

You re the applications development manager for your company s IT department. You ve recently been presented with a request from one of your business units to automate a function of theirs that currently takes a lot of time and person-hours to accomplish.

You assign a systems analyst to the project. She begins the business analysis methodology by working with users to identify the business processes involved and trying to firmly nail down the requirements of the project. She comes back with her standard well-drafted documentation, including DFDs that show the logical flow of the current process.

Everything looks great and you begin to go forward with your project. Halfway into the development of the system code, after going back to the stakeholders for routine communications updates, you find that little elements here and there are missing ”almost as though your systems analyst didn t fully perform her usual thorough discovery.

Upon re-interviewing some of the people that she initially sat with, you find a variety of sidebar systems that they evidently didn t bring up at the first interview. One man, for example, keeps a little Excel file listing of computations that he has done toward accomplishing the business function. These things are extremely valuable pieces of information that really should be included somehow in the new system. Another person keeps sticky notes on her desk blotter as she goes through the process. You realize that these step-monitoring activities actually are quite important for the new program and yet you had no knowledge of them when you began .

Now you must go back to the design drawing board and add in these fundamental processes.

Delivery of parts is another issue that can dramatically affect the scope of your project without you being able to adequately spot it at scope-development time. For example, we recently completed a large Storage Area Network/Network Attached Storage (SAN/NAS) project. A simple element such as the rails for a server rack held up completion of an important project phase for almost a month! The vendor sent the wrong rails (ordered through a third-party provider) and was very slow in correcting the order. Finally, just to get a set of rails installed we wound up borrowing a set of the correct rails from another IT unit just so we could bring closure to this phase of the project.

Senior Project Technician Quits or Leaves

Suppose that you laid down your WBS tasks relying heavily on one of your more senior people. Further, suppose that the person moves on to greener pastures. What then? Do you have a less capable junior person to take his or her place? Recall that some IT teams aren t very big. What if you don t have anyone to take his or her place until someone s hired ? Voila! The scope juts out like a cowlick on a kindergartner!

Again, in your assumptions statement, you d note that you assume a certain caliber of individuals will be available.

Project Goes across IT Shops

Perhaps you work for an organization that has several different IT shops that serve different business units. For example, maybe the manufacturing segment of your company is so big that it has its own IT arm. Ditto for the legal department. You handle the rest. Suppose that you have a project in which everyone in the company will use the primary deliverable ”for example, an electronic timesheet system that s going to be hosted through the company s intranet. You need the assistance and buy in from the other IT shops so that you appropriately meet the needs of the end users who will use the system. The manufacturing arm, for instance, is the only unit that has 24/7/365 workers, so their timesheet posting will be quite different from others.

In such instances, project management takes on a political diplomat flavor in which you work hard to garner buy in and cooperation from entities that don t necessarily have to play along (unless the CEO says make go! ).

Understandably, in a situation such as this, the scope is very much shaped by the priorities that each IT shop has weighed against the importance of the project. You might get Joe the graphics designer from marketing for 15 percent of his time per week, for example.

Testing Elements Need Good Definition

Lots of different IT projects require that you go through some testing elements to verify that the deliverables meet the requirements. Software development, for example, requires that you perform extensive testing to make sure that you re pushing out code that meets the user s needs as stipulated in the project requirements documentation. There are three forms of testing to be concerned with:

Unit Testing ” This test involves the technician performing tests on his or her modules or elements that are going to be included in the overall package of deliverables. For example, a server administrator might get done burning a server, then go through a litany of tests to make sure that it s working as it s supposed to. A programmer, after completing her module, might run through a variety of tests to validate that the module is performing as expected. When you think unit testing, think singular ”that is, usually a single person testing a single element. While this isn t a hard and fast rule, it gives you the flavor of what unit testing is all about.

Integration Testing ” When you perform integration testing, you re testing a bunch of elements that are combined together to form a whole. For example, perhaps you ve got several servers that are now burned and that will work together in an array of load-balanced Web servers. Integration testing would test these servers as a whole , rather than in distinct units. A programming team might test several modules that, when combined together, form a complete program element. For example, one programmer may have coded the print module, another the calculational elements, another the reporting. When they re combined, they should accurately calculate some figures, create a report, and print it out successfully. Integration testing would prove that this is so.

Case Study: Chaptal Wineries Email and Intranet Systems

Life is tough for you. You ve been forced to fly to Bordeaux to meet with Monsieur Fourche so that you can discuss the email server and intranet sites. You really needed to visit each site so that you could understand what the physical connectivity elements are like. For example, you need to get a picture of where the server could actually be placed. Additionally, you also need to understand what the telecommunications picture is like ”what wide area network prices are for, say, a T1 circuit (called an E1 in Europe), what the provision times are for such connectivity, and where the demarcation point will be at the Fourche site.

You have to do the same things for Senior Sanchez location and the Roo wines site.

On returning, you create a scope document containing the following elements:

Business Need The president of Chaptal Wines, Kim Cox, has requested that the three new offshore acquisitions be connected to share email and calendar information as well as vinovital information such as residual sugar (RS) and other viticultural data, vintage charts , wine blends, regulatory updates, and so forth. Two systems are required: an email system that connects all four sites together and a system that runs an intranet site.

Deliverables Description The deliverables will consist of the installation of a server or servers at each site. The servers will connect together via wide area networking technology. Email software will be installed on each server in such a way that all sites belong to a single email organization. Users will utilize conventional email software to keep their email and calendars online. Additionally, an intranet site will be created on a Chaptal winery server and key users in each of the offshore sites will be trained how to post important data to the intranet so that all employees have complete data at their fingertips.

Major Deliverables The deliverables include the following elements:

1. Installation of high-quality server gear at each site. Server gear will all be from the same vendor and each server will be identically equipped.
2. Installation of internationally well-known email software.
3. Wide area networking connectivity between sites.
4. Installation of appropriate internetworking gear such as routers and firewalls at each site.
5. Creation of an intranet site.
6. Training and documentation.

Success Criteria Your success criteria includes the following:

1. Server gear will be installed at each site, baselined, and certified 100 percent functional.
2. Email software will be installed on each site server, site connections with the other site servers validated , and languages installed 100 percent.
3. Connectivity between sites installed and baselined by a telecommunications company.
4. ISP for each site will be determined and contracted.
5. Routers installed and router tables built. Firewalls installed, configured, and baselined. Administrator will be able to ping each site server within the network and send a test email to each site server. Port sniff will show ports 20 and 21 (FTP), 25 (SMTP), 80 (HTTP), and 443 (HTTPS) open , all others closed.
6. Intranet site created and all initial elements requested by the business made operational.
7. Users will be trained and documentation provided and maintained .
8. Users in all sites will be able to send email to one another 100 percent of the time and access viti- vital information 100 percent of the time.

Assumptions You have the following assumptions:

1. No variance in the behavior of like hardware.
2. Telecommunications companies in each nation will have reasonable wide area network setup request procedures and installation timelines .
3. Average T1/E1 cost is assumed to be $350/month U.S. dollars.
4. Intranet development time is assumed to be 60 person days (30 working days, 2 persons)
5. All sites will provide reasonable access for installers and a secure, climate-controlled, power-conditioned room for the electronic gear.
6. Routers will use Open Shortest Path First (OSPF) routing protocol.
7. Contractual help will be used for configuration of the routers.

Constraints Your constraints for the email server and intranet sites are:

1. Language barriers
2. Availability of people at any given site to be able to help with setup due to problems with the winemaking efforts
3. Harvest and crush seasons

Work Breakdown Structure (WBS) Finally, this list represents your WBS:

1. 1.0 Hardware procurement ”Chaptal administrator

   1.10 Purchase servers and network operating system (NOS) licenses

   1.20 Purchase internetworking gear

2. 2.0 Wide area network telecommunications connection procurement ”Chaptal administrator working with site business managers

   2.10 Provision an E1 connection with French telco

   2.20 Provision a T1 connection with So. Australian telco

   2.30 Provision a T1 connection with Chile telco

   2.40 Provision a T1 connection with California telco

3. 3.0 Internetworking gear installation ”installed by contractor

   3.10 Contractor installs router and switches at French site, configures, baselines, and tests.

   3.20 Contractor installs router and switches at So. Australian site, configures, baselines, and tests.

   3.30 Contractor installs router and switches at Chile site, configures, baselines, and tests.

   3.40 Contractor installs router and switches at California site, configures, baselines, and tests.

4. 4.0 Server installation ”installed by Chaptal administrator

   4.10 Install server at French site. Baseline and test.

   4.20 Install server at So. Australian site. Baseline and test.

   4.30 Install server at Chile site. Baseline and test.

   4.40 Install server at California site. Baseline and test.

5. 5.0 Email software installation ”installed by Chaptal administrator

   5.10 Install email software on French server. Baseline and validate the software is working correctly.

   5.20 Install email software on So. Australian server. Baseline and validate the software is working correctly.

   5.30 Install email software on Chile server. Baseline and validate the software is working correctly.

   5.40 Install email software on California server. Baseline and validate the software is working correctly.

6. 6.0 Intranet development ”contractor

   6.10 Develop intranet pages

   6.20 Test intranet

7. 7.0 Training of users ”Chaptal administrator

   7.10 Train French users on the use of email.

   7.20 Train French users on the use of intranet.

   7.30 Train So. Australian users on the use of email.

   7.40 Train So. Australian users on the use of intranet.

   7.50 Train Chilean users on the use of email.

   7.60 Train Chilean users on the use of intranet.

   7.70 Train California users on the use of email.

   7.80 Train California users on the use of intranet.

8. 8.0 Unit, integration, and user acceptance testing

   8.10 Unit testing

   8.20 Integration testing

   8.30 User Acceptance Testing (UAT)

We ve also included part of what the tree structure diagram might look like for this case study as well. (See below.)

 

User Acceptance Testing (UAT) ” The final element of testing happens when designated users are brought in to give the system a test drive. This is also probably the most revealing of all the testing phases you ll go through because it points out how well the team has done its job, in terms of the way that the users interact with the system. Be prepared for brutally honest assessments of your product.

At any step in the testing, if things don t work correctly the folks working on the problem must, of course, correct it. Significant testing errors will undoubtedly result in out-of-scope scenarios in which you re burning time and money trying to solve a problem. This is why project managers really harp on the idea of pairing the correct person for a task ”so that you re sure the task gets done within the estimate that he or she provided.

Summary

Scope planning uses the output of the initiation process, the project charter, to create the scope statement and the scope management plan. The project scope statement is the basis for many of the other planning processes. It is also the basis for setting the boundaries of the project with the client and stakeholders.

A scope statement includes project justification, project description, major deliverables, time and cost estimates, success criteria, assumptions, and constraints. The scope management plan documents how you will manage changes to the scope. The work breakdown structure (WBS) is created by taking the major deliverables from the scope statement and decomposing them into smaller, more manageable components. The breakdown continues through multiple levels until the components can be estimated and resourced. Each lower level of deliverables includes the components that produce the next highest level in the tree. The lowest level of decomposition is the work package. The WBS includes all of the work required to complete the project. Any deliverable not listed on the WBS is assumed to be excluded from the project. The WBS is one of the most critical outputs of planning. A WBS is the basis for time estimates, cost estimates, and resource assignments.

Certain elements in IT shops need to be taken into account when dealing with IT projects. The size of the IT shop very definitely affects the projects time estimates, as do deliverables that may be challenging to define. Business clients may have some hidden processes sidebars that theyve not revealed when youre busy trying to discover the processes. Success criteria can be especially tough to define in IT projects. A key project team member leaving can have a remarkable affect on the status of the projects scope.

Exam Essentials

Understand the purpose of the scope statement. The scope statement is the basis of the agreement between the project and the client. It defines the project objectives and the deliverables that will meet those objectives.

Be able to list the components of a scope statement. A scope statement includes a project justification, product description, major deliverables, success criteria, time and cost estimates, a list of assumptions, and constraints.

Describe the purpose of a scope management plan. A scope management plan documents the procedures that will be used to manage proposed changes to the project scope throughout the life of the project.

Know how to define and create a work breakdown structure (WBS). The WBS is a graphical depiction of the work required to complete the project. The WBS is a multilevel tree diagram. You decompose the major deliverables into smaller activities and continue to create lower levels for each deliverable until you reach a point where a time and cost estimate can be provided and resources assigned.

Understand the level structure of a WBS. The highest level of the WBS is the project name . The major deliverables are the next level. The number of levels in a WBS will vary by project; however, the lowest level is called a work package.

Be able to name the constraints common to all projects. The constraints common to all projects are time, cost, scope, and quality. The constraints commonly referred to as the triple constraints are time, cost, and quality.

Understand the scope- impacting limitations that a small IT shop might encounter. Because IT shops arent heavily staffed, nor are they often staffed specifically with projects in mind, its important to understand how the scope of a project can be impacted.

Key Terms

Before you take the exam, be certain you are familiar with the following terms:

assumption	scope management plan
constraint	scope planning
decomposition	scope statement
integration testing	sequencing
major deliverables s	idebar systems
network operating system (NOS)	success criteria
order of magnitude	triple constraint
product description	unit testing
project justification	User Acceptance Testing (UAT)
scope	work breakdown structure (WBS)
scope creep	work package

Review Questions

1. Which of the following is NOT a key component of scope planning?
   1. Work breakdown structure (WBS)
   2. Scope statement
   3. Project charter
   4. Scope management plan
2. The scope statement provides which of the following?
   1. A basis for confirming a common understanding of the project and making future decisions regarding the project
   2. A detailed list of all resources required for project completion
   3. A schedule of all the key project activities
   4. A process for managing change control
3. Which of the following is a characteristic of a WBS?
   1. A cost center structure of the project
   2. An organization chart of the project team members
   3. Used primarily on large complex projects involving multiple departments
   4. A task oriented structure that defines and organizes the project
4. Which of the following are components of a scope statement?
   1. Assumptions
   2. Product description
   3. Constraints
   4. All of the above
5. A WBS is created using a technique called decomposition. What is decomposition?
   1. Matching resources with deliverables
   2. Breaking down the project deliverables into smaller, more manageable components
   3. Estimating the cost of each individual deliverable
   4. Creating a detailed To Do list for each work package
6. What is the lowest level of the WBS?
   1. Work package
   2. Level 10
   3. Milestone
   4. Product features
7. Which of the following is not a guideline for developing a WBS?
   1. Define the highest level of deliverables before you move down to lower levels.
   2. Make sure that each item in a lower level is a component of the level above.
   3. Sequence all your tasks .
   4. Involve project team members in the process.
8. Which of the following is a benefit of a WBS:
   1. A WBS is an excellent tool for team building.
   2. A WBS helps prevents critical work from being overlooked.
   3. The WBS can become a template for future projects.
   4. All of the above.
9. All projects work under constraints. Which of the following is not a constraint that is common to all projects?
   1. Time
   2. Scope
   3. Quality
   4. Equipment
10. Your team is working on creating a WBS for the ABC Software Release. Which of the following is an example of what might appear in level 2 of your WBS?
    1. User guide, training materials, training schedule
    2. Report layout, screen design, and screen mock-up
    3. Product requirements, detail design, development
    4. Project meetings, coding guidelines, test scenarios
11. Which testing element is typically performed by a single individual?
    1. Integration
    2. Delivery
    3. Unit
    4. UAT
12. You re the project manager for a medical research corporation. You ve been given a new project whose outcome will result in the formulation of a new cancer treatment involving precisely controlled mini-blasts of radiation using robots and computers. Which of these will most likely impact the scope of the project?
    1. Assembly of key team members
    2. Laws and government regulations
    3. News of a competitor working on the same thing
    4. Formulation of the requirements for the project
13. There are three project elements that remain in tension with one another. Your project client will stipulate which of the three is the most important to them. What are these three elements?
    1. Budget and costs
    2. Team members
    3. Quality of deliverables
    4. Anticipated time to produce deliverables
    5. Sponsors and stakeholders
14. Of the following list of constraints, which one is the most important to make sure you ve completely and accurately identified when preparing your scope statement documentation?
    1. A clearly defined project end date
    2. A clearly defined set of monetary resources or allocation
    3. A clearly defined set of product requirements
    4. Clearly defined testing methodologiess
    5. Clearly defined priorities
15. When communicating with the project sponsor about your project, which elements below will you have to take into account when considering the project? (Select all that apply.)
    1. The priority of your project as it relates to others
    2. The human resources available for the project
    3. The technology that will be used to create the deliverables
    4. The budget dollars that are available
    5. The equipment that will be required
16. Insert these project elements into the appropriate category to identify whether they are valid success criteria.

    Possible Success Criteria	Actual Success Criteria
    Save $1.25M in processing costs.
    All data entered into computer 100 percent of the time.
    Sales figures increase.
    Data entry efficiency increased.
    100 percent of drawings visible online.

17. Whose job is it to author the project charter?
    1. Customer
    2. Project manager
    3. Stakeholder representatives
    4. Project sponsor
    5. Options A, B, and C
18. You re developing a scope document for a customer request. A couple of the elements that the client wants might be tricky to accomplish, but after consulting with the project team, you think they can be done. These elements are not a part of the most important things the customer wants out of the product. What should you do?
    1. Include these elements in the scope document, trusting your project team to deliver.
    2. Include these elements in the scope document, denoting the problem elements as such in the document.
    3. Discuss the problem elements with the project sponsor. Obtain customer sign-off.
    4. Discuss the problem elements with the project sponsor and the customer. Obtain sponsor sign-off.
    5. Discuss the problem elements with the customer and the project sponsor. Obtain customer sign-off.
19. What are the functions of the Project Sponsor when it comes to the formulation of the Scope Document?
    1. Signs off on the project scope document.
    2. Has input into the project scope document.
    3. Does not interact with the project scope document.
    4. Authors the project scope document.
20. You re developing the scope document and project plan for a new project. What process group are you in?
    1. Initiation
    2. Planning
    3. Executing
    4. Controlling
    5. Closing

Answers to Review Questions

1. C. The key components of scope planning are the scope statement, the scope management plan, and the work breakdown structure. The project charter is created during project initiation.
2. A. The scope statement is a document that is referenced throughout the project to confirm whether the project is on the right track. It is also used to communicate with the client and stakeholders. A scope statement does not provide a detailed list of all resources required for project completion, a schedule for all the key project activities, or a process for managing change control.
3. D. A WBS is a grouping of project tasks around deliverables that defines the complete scope of the project. A WBS is not a cost structure, or an organizational chart of the project team. It can be used on projects of any size .
4. D. The sections of a project scope statement are project justification, product description, major deliverables, success criteria, time and cost estimates, assumptions, and constraints.
5. B. Decomposition breaks the major deliverables down into smaller pieces that can be used to do cost and time estimates and resource planning. Decomposition does not include matching resources with deliverables, estimating the cost of each individual deliverable , or creating a detailed To Do list for each work package.
6. A. The lowest level of a WBS is the work package. The number of levels will vary by project and complexity.
7. C. The purpose of a WBS is to identify all of the work required to complete a project. It is not important at this point to define the order of the tasks. That will come later when the schedule is developed. The project team members or subject matter experts are involved in creating the WBS.
8. D. There are numerous benefits associated with a WBS. It identifies all of the work associated with the project. It can be used for project team communication and team building. A good WBS can be reused in the future as a template for a similar project.
9. D. The four constraints that are common across all projects are scope, time, cost, and quality.
10. C. Level 2 of the WBS is the first level under the project level and represents major project deliverables, project life cycle phases, or departments involved in the project.
11. C. Unit testing involves testing that single element or thing that will contribute with others to make the whole.
12. B. When your project may attract visibility because it s entrenched in a regulated technology, you ll very definitely have to take into consideration the rules and regulations associated with what you re trying to do.
13. A, C, D. The time/budget/quality equilibrium says that if one element falls short, the other two have to stretch to make up the difference. Short on budget? Then in order to successfully conclude your project with a high-quality product, you ll need to extend the time the project takes.
14. C. It is important to understand all of these constraints. However, the other constraints can change if you have not thoroughly decomposed the new system s software and hardware components in order to arrive at well- understood requirements. If you do not accurately flesh out the requirements, everything else is subject to change.
15. A, B, D. The project sponsor will be concerned with the priority of the project as it relates to others that may be in the loop, and the resources, both budgetary and human, that will be available. It s you and your team s job to determine the equipment and technology that s required and put that in the project plan.

16. Actual Success Criteria

    Save $1.25M in processing costs.

    All data entered into computer 100 percent of the time.

    Success criteria means that you have some metric ”some numeric way of identifying that your project was successfully deployed.

17. B. It is the job of the project manager to synthesize the project charter. However, he does that based upon the collected input of the customers and the project sponsor.
18. E. When you re defining the scope, it s important that you and the customer understand the key areas that really make up project success. In this case, the sketchy elements may not matter to the customer and should be scrapped from the scope of the project. Or, it may be that the risks of not being able to get them accomplished are acceptable to the customer. However it goes, the main point here is that you interface with the customer when working out scope definition elements and make sure you understand the key areas.
19. A, B. The project manager is the one who authors the project scope document. But, keep in mind that it is the sponsor who has the ability to authorize the use of resources for the project, thus she must see the scope document, have input into the scope document, and most importantly, sign off on the scope document.
20. B. The planning process group is where you begin to define highly important documents such as the scope and project plan. The scope document arises out of the first important document that you develop, the project concept document, which is developed in the initiating process group .