A clear project objective is both specific and measurable. Avoid vague objectives such as "Create state-of-the-art deliverables." A project's objectives may include:

• A list of project deliverables (deliverable: A tangible and measurable result, outcome, or item that must be produced to complete a project or part of a project. Typically, the project team and project stakeholders agree on project deliverables before the project begins.).
• Specific due dates, both for the ultimate completion of the project and for intermediate milestones (milestone: A reference point marking a major event in a project and used to monitor the project's progress. Any task with zero duration is automatically displayed as a milestone; you can also mark any other task of any duration as a milestone.).
• Specific quality criteria that the deliverables must meet.
• Cost limits that the project must not exceed.

For objectives to be effective, all project stakeholders (stakeholders: Individuals and organizations that are actively involved in the project or whose interests may be affected by the project.) must officially agree to them. Often the project manager creates an objectives document that becomes a permanent part of the project. If the document was created in a program other than Project, you can attach the document to your project file for easy access.

If you are using Microsoft Office Project Web Access 2003 (Project Web Access: The Web-based user interface that is used to access information in Project Server.), you can easily upload supporting documents at the start of a project. This is useful if your team doesn't have a shared folder or Web site that contains information that is relevant to projects or other corporate endeavors.

 Note   You can also place project-level information in the Comments box of the Properties dialog box for a project. This helps you locate documents and projects after a project begins.

To begin planning, you make educated guesses and then use those estimates to create your schedule.

It's important to keep track of the assumptions you make, so that:

• Project stakeholders can critique the assumptions and then formally agree to a set of project assumptions.
• You can update the schedule when you have additional information about these factors.

Consider these project areas when you identify your underlying assumptions:

• Handoffs from other projects or departments: If your project depends on the work of others, do they understand your dependency and agree to the handoff dates?
• Resource availability and usage (including people, materials, and equipment): If you do not manage some of the people who are working on your project, who does? And has that person approved your use of these resources?
• Task durations (duration: The total span of active working time that is required to complete a task. This is generally the amount of working time from the start to finish of a task, as defined by the project and resource calendar.): Are your task estimates based on solid information or guesses?
• Project costs (cost: The total scheduled cost for a task, resource, or assignment, or for an entire project. This is sometimes referred to as the current cost. In Project, baseline costs are usually referred to as "budget."): How important is cost to your project? Who has to approve your budget (budget: The estimated cost of a project that you establish in Project with your baseline plan.) or increase it if necessary?
• Available time: If you're working toward a known deadline (deadline: A target date indicating when you want a task to be completed. If the deadline date passes and the task is not completed, Project displays an indicator.), can you realistically complete all tasks with an acceptable level of quality?
• Deliverables: Does your list of project deliverables match what the customer and other stakeholders (stakeholders: Individuals and organizations that are actively involved in the project or whose interests may be affected by the project.) expect? If you must compromise on a deliverable, have your stakeholders agreed on what aspects of the deliverable would be compromised first?

These are just a few issues to consider before beginning any complex project. Ultimate project success depends on identifying assumptions and making backup plans as much as it does on carrying out what you have planned.

Typically, the three major constraints are:

• Schedule (schedule: The timing and sequence of tasks within a project. A schedule consists mainly of tasks, task dependencies, durations, constraints, and time-oriented project information.), such as a fixed end date or a deadline date for a major milestone (milestone: A reference point marking a major event in a project and used to monitor the project's progress. Any task with zero duration is automatically displayed as a milestone; you can also mark any other task of any duration as a milestone.).
• Resources (resources: The people, equipment, and material that are used to complete tasks in a project.), such as a predefined budget (budget: The estimated cost of a project that you establish in Project with your baseline plan.).
• Scope (scope: The combination of all project goals and tasks, and the work required to accomplish them.), such as a requirement that three models of the product be developed.

A change in one of these constraints usually affects the other two and can affect overall quality. For example, decreasing project duration (schedule) may increase the number of workers you'll need (resources) and reduce the number of features that can be included in the product (scope). The project manager then determines whether this trade-off is acceptable. This concept is called "the triple constraints of project management" or "the project triangle."

During the planning process, list your project's constraints to ensure that all project stakeholders (stakeholders: Individuals and organizations that are actively involved in the project or whose interests may be affected by the project.) are aware of them and have the opportunity to comment on the list.

It is also worthwhile for stakeholders to agree on how they would respond to unexpected constraints that arise during the project. For example, if labor costs turn out to be higher than anticipated, stakeholders may be willing to reduce the scope of the project in specific, predefined ways.

 Note   In Project, the word "constraint" means a restriction or limitation that you set on a task (task: An activity that has a beginning and an end. Project plans are made up of tasks.). For example, you can specify that a task must start on a particular date or finish no later than a particular date.

The project's scope is the combination of all project objectives and tasks and the work required to accomplish them.

The scope management plan is a document that describes how the project scope will be managed and how scope changes will be integrated into the project. This plan is helpful because project teams often must adjust their objectives during a project.

A scope management plan may include:

• An assessment of how likely the scope is to change, how often, and by how much.
• A description of how scope changes will be identified and classified. For example, in a construction project, you may decide that the work crew leader can approve the work if the client requests a design change that will cost under $1,000, but if the change will cost more than that, the project manager and client must reevaluate the scope of the project in terms of cost, resources, and other factors.
• A plan for what to do when a scope change is identified (for example, notify the sponsor and issue a contract change order).

A well-prepared scope management plan can serve as the basis for your project's contingency plan (contingency plan: A plan that identifies corrective steps to take if a risk event occurs.).