1. Program
2. Project
3. Task
4. Subtask
5. Work Package
6. Level of Effort

• Improve the accuracy of cost, duration, and resource estimates
• Define a baseline for performance measurement and control
• Facilitate clear responsibility assignments

• An external event (e.g., a change in a government regulation
• An error or omission in defining the scope of the product (e.g., failure to include a required feature in the design of a telecommunicaions system).
• An error or omission in defining the scope of the project (e.g., using a BOM instead of a WBS).
• A value-adding change (e.g., an environmental remediation project is able to reduce costs by taking advantage of technology that was not available when the scope was originally defined).
• Implementing a contingency plan or workaround plan to respond to a risk.

• Scope changes - A scope change is any modification to the agreed-upon project scope as defined by the approved WBS. Scope changes often require adjustments to cost, time, quality, or other project objectives. Project scope changes are fed back through the planning process, technical and planning documents are updated as needed, and stakeholders are notified as appropriate.
• Corective action - Corrective action is anything done to bring expected future project performance in line with the project plan
• Lessons learned - The causes of variances, the reasoning behind the corrective action chosen, and other types of lessons learned from scope change control should be documented, so that this information becomes part of the historical database for both this project and other projects of the performing organization.
• Adjusted baseline - Depending upon the nature of the change, the corresponding baseline document may be revised and reissued to reflect the approved change and form the new baseline for future changes.

• Work Breakdown Structure Templates - A WBS from a previous project can be used as a template for a new project. Although each project is unique, WBSs can often be reused since most projects will resemble another project to some extent. For example, most projects within a given organization will have the same or similar project life cycles, and will thus have the same or similar deliverables required from each phase.
• Decomposition - involves subdividing the major project deliverables or subdeliverables into smaller, more manageable components until the deliverables are defined in sufficient detail to support development of project activities (planning, executing, controlling, and closing).

• Project justification - the business need that the project was undertaken to address. The project justification provides the basis for evaluating future tradeoffs.
• Project's product - a brief summary of the product description
• Project deliverables - a list of the summary-level subproducts whose full and satisfactory delivery marks completion of the project. For example, the major deliverables for a software development project might include the working computer code, a user manual, and an interactive tutorial. when known, exclusions should be identified, but anything not explicitly included is implicitly excluded.
• Project objectives - the quantifiable criteria that must be met for the project to be considered successful. Project obectives must include at least cost, schedule, and quality measures. Project objectives should have an attribute (e.g., cost), a metric (e.g. dollars / money), and an absolute or relative value (e.g., less than 100). Unqualified objectives (e.g., "customer satisfaction") entail high risk to successful accomplishment.

• Initiation - authorizing the project or phase
• Scope Planning - developing a written scope statement as the basis for future project decisions
• Scope Definition - subdividing the major project deliverables into smaller, more manageable components
• Scope Verification - formalizing acceptance of the project scope
• Scope Change Control - controlling changes to the project scope

• Project justification - the business need that the project was undertaken to address. The project justification provides the basis for evaluating future tradeoffs.
• Project's product - a brief summary of the product description
• Project deliverables - a list of the summary-level subproducts whose full and satisfactory delivery marks completion of the project. For example, the major deliverables for a software development project might include the working computer code, a user manual, and an interactive tutorial. when known, exclusions should be identified, but anything not explicitly included is implicitly excluded.
• Project objectives - the quantifiable criteria that must be met for the project to be considered successful. Project obectives must include at least cost, schedule, and quality measures. Project objectives should have an attribute (e.g., cost), a metric (e.g. dollars / money), and an absolute or relative value (e.g., less than 100). Unqualified objectives (e.g., "customer satisfaction") entail high risk to successful accomplishment.

• An external event (e.g., a change in a government regulation
• An error or omission in defining the scope of the product (e.g., failure to include a required feature in the design of a telecommunicaions system).
• An error or omission in defining the scope of the project (e.g., using a BOM instead of a WBS).
• A value-adding change (e.g., an environmental remediation project is able to reduce costs by taking advantage of technology that was not available when the scope was originally defined).
• Implementing a contingency plan or workaround plan to respond to a risk.

• Improve the accuracy of cost, duration, and resource estimates
• Define a baseline for performance measurement and control
• Facilitate clear responsibility assignments

1. Program
2. Project
3. Task
4. Subtask
5. Work Package
6. Level of Effort