When you review your plan, you might find that you cannot complete your project within the allotted timeframe, the budget, or both. You can try redefining the scope of your project. The scope of your project defines where your project work starts and ends. For example, suppose your project is intended to develop a new computer system. Your scope statement might read something like: "This project involves designing, developing, and testing a new computer system. It does not include implementing the system or training people to use it."

After tugging at your project plan, let’s say you simply can’t find a way to finish the project within the allotted timeframe and budget. So you can re-evaluate the scope of your project. You might be able to reduce the number of products you are expected to deliver. For example, if the project stakeholders are willing to sacrifice some of the features of the computer system you’re designing, you might be able to finish the project on time and within budget. In reality, you’re reducing the products you plan to deliver if you take this approach of scaling down the computer system. If you change the scope, you might design and develop the computer system in one project, and establish a second project that handles testing.

Both approaches can help you fit your project within time and budget constraints, but you’ll need to make sure that your project stakeholders understand and accept the changes you propose. If you propose to eliminate features, you effectively reduce the quality of the initial delivery. But if all the players can agree that the features can be added to the system later, this approach might be the way to please most of the people in the most cost-efficient manner. And it’s entirely possible that your stakeholders will decide that some features were "nice but not essential" and that those features could be eliminated from the system or possibly revisited at some time down the road. Those features might not ever make it into the computer system.

If you change the scope of the project to eliminate a phase and establish another project to handle that phase, the chances are quite good that you’ll need to sell the project stakeholders on a longer schedule. Why? Because the amount of work to be done before the computer system can be delivered hasn’t been reduced; it’s simply been split apart into two projects. However, your project stakeholders may want the complete system delivered, even if you need more time to deliver it in its entirety.

Regardless of the approach you take to resolving the issue, don’t eliminate tasks until you copy them into another project. If you opt to eliminate products to deliver, it’s quite possible that your next project might be to enhance the one you deliver with those eliminated products. If you opt to divide your project into two or more projects, you can save the work you’ve already done in another project, and you can even link the projects together to track the overall cost and time you need to complete the project at hand. See 13, for details.