Before I go into the inputs for this first process in the Scope knowledge area, let me go over some key concepts that are described on p. 131-133
Product scope vs. project scope
The product scope refers to the features and functions that characterize a product, service, or a result, whereas the project scope refers to the work performed to deliver that product, service, or result.
Life cycle–predictive and adaptive
The life cycle is the approach you take when planning and managing the scope of the project. A traditional or predictive life cycle is, as the name implies, one where the scope is defined at the beginning of the project. In an adaptive or agile cycle, the overall scope is decomposed into a prioritized set of requirements (the product scope) and work to be performed (the project scope) called the product backlog . At the beginning of each iteration, the team will work to determine how many of the highest-priority remaining items on the product backlog can be determined during the next iteration.
Another important difference between the predictive and the adaptive life cycle is the process of Validate Scope. This is the process where the customer is shown the deliverables and formally signs off and approves them. In a predictive life cycle, this is done at the end of the project when the final deliverable is completed, whereas in an adaptive life cycle, it is done at the end of each iteration.
Requirements
Project management is increasingly focused nowadays on the management of stakeholder requirements. Business analysis is the role that comes up with business requirements, and although a project manager may not have to create documents such as the business case, it is important than the project manager understand them. Why? Because if conditions change such that the assumptions embedded in the business case are no longer valid, the justification for the project’s continuance may no longer exist.
Now let’s talk about inputs to this process
5.1.1 Plan Scope Management: Inputs
5.1.1.1 Project Charter
The parts of the project charter that are relevant to scope management are:
- Project purpose
- High-level project description
- Assumptions
- Constraints (budget, schedule, or others)
- High-level requirements
5.1.1.2 Project Management Plan
Components of the project management plan that are relevant include the project life cycle description and development approach (predictive, incremental, or adaptive/agile), as well as the quality management plan. The scope covers the completeness of the work, but quality covers the correctness of the work.
5.1.1.3 Enterprise Environmental Factors
An organization’s culture and infrastructure are among the factors that can affect the management of scope.
5.1.1.4 Organizational Process Assets
An organization’s policies and procedures are important for any management plan, and historical information and lessons learned repositories may help guide the development of the scope of the project if it is similar to one done in the past.
The next post will cover the tools & techniques of this process.
Filed under: Uncategorized |
4squareviews 
Jerome, pmbok 6thed calls out quality management plan as input to scope develop scope management plan. I was trying to understand this but pmbok and other writers are short on good explanation. You mention above that quality management plan covers correctness. What part of that is and how is it carried into scope management plan.
Thanks for reply
The statement “scope management covers completeness, while quality management covers correctness” is a general theme that covers the ENTIRE management plan. In a traditional project management environment, the scope is broken down into deliverables by the Work Breakdown Structure and the deliverables are broken down into activities to complete the deliverables. The deliverables have requirements, which are derived from the Quality Management Plan.
If all of the work is done, then the scope is considered 100% completed. However, the next steps are then a) Quality Control, so the final product is inspected internally by the project team to see if the work was done CORRECTLY, meaning that it meets the original quality requirements as agreed to with the customer (or sponsor, if it is an internal project). If everything is satisfactory, then you go on to b) Validate Scope, where the CUSTOMER inspects the product to see if it meets the requirements. Hopefully, the customer says OK and the project is complete. If not, it has to be reworked to correct any discrepancies of the deliverables to meet those requirements. So if you understand the work has to be complete (by doing all the work laid out in the WBS) AND it has to be correct (by inspecting it against the requirements), you can see how the scope and quality management plan work together.