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.
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.
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.
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.
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.
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 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.
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.
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.”
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.
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.
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.
· 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.”
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