During the initiating process you and the project customer created requirements that defined the basic ideas of the project. This document is elaborated upon, and the project scope is now created. In addition to the preliminary project scope statement, you’ll use the project charter, historical information if you’ve done projects like this one before, and approved change requests that may have trickled in. (Here’s an example of how you won’t have many change requests affecting the project scope early in the project, but as the project moves through its execution change requests can become more common.)
Technically there are two scopes when it comes to project management:
Product scope – This is all of the resources and work required to create the product scope and the ancillary deliverables of the project. This the labor, plans, blueprints, documents, and effort to create the vision the project customer possess.
The product scope and the project scope support one another. If the project team is doing work outside of the project scope then the customer is not going to get the product scope that she envisioned. If the customer doesn’t know what the product scope is then the project manager and the project going to have a tough time creating the project scope. These two scopes support one another. The project scope statement is identified by completing a product scope analysis, since it reveals what the project must create.
Real World Note: Often the product scope is already designed before the project manager and the project team get started on the project. The product scope is concerned with the features and functions of the project deliverable, while the project scope is concerned with the work to create the project deliverables.
Another tool the project manager can use to create the project scope statement is alternative identification. Alternative identification, just like it sounds, is a method to identify any other solutions, approaches, or deliverables that would satisfy the customer’s product scope. For example, a customer wants an email server. They don’t care if you use Microsoft Exchange Server or some home-grown POP3 mail server. All they want is an email server that allows their staff to send and receive email. Alternative identification would identify, compare, and contrast all the available solutions for the customer.
Finally, the last major approach, and probably the most realistic is stakeholder analysis. Stakeholder analysis involves the project manager, the project team, and often business analysts to interview the project stakeholders to create the project scope. Some folks call this process requirements gathering, and that’s fine, but it’s more than just understanding the requirements for the project. It’s also identifying quantitative metrics, conditions for project acceptance, and working with the project stakeholders to create a project buy-in and shared ownership of the project.
Real World Note: Involve your stakeholders. When I consult I often see an “us-against-them” mentality between the project team and the project stakeholders. I want to scream when I see it – and it’s not hard to recognize. Your project customers, your key stakeholders, and the recipients of the project should work together in harmony. It’s up to the project manager and the project team to facilitate that harmony.
Another tool the project manager can use to create the project scope statement is alternative identification. Alternative identification, just like it sounds, is a method to identify any other solutions, approaches, or deliverables that would satisfy the customer’s product scope. For example, a customer wants an email server. They don’t care if you use Microsoft Exchange Server or some home-grown POP3 mail server. All they want is an email server that allows their staff to send and receive email. Alternative identification would identify, compare, and contrast all the available solutions for the customer.
Finally, the last major approach, and probably the most realistic is stakeholder analysis. Stakeholder analysis involves the project manager, the project team, and often business analysts to interview the project stakeholders to create the project scope. Some folks call this process requirements gathering, and that’s fine, but it’s more than just understanding the requirements for the project. It’s also identifying quantitative metrics, conditions for project acceptance, and working with the project stakeholders to create a project buy-in and shared ownership of the project.
Real World Note: Involve your stakeholders. When I consult I often see an “us-against-them” mentality between the project team and the project stakeholders. I want to scream when I see it – and it’s not hard to recognize. Your project customers, your key stakeholders, and the recipients of the project should work together in harmony. It’s up to the project manager and the project team to facilitate that harmony.
Joseph Phillips Course: 35 contact hours 200 PMP exam questions. All for ONLY $55. For more info- Click here to view more details
You’ve got some formatting/typos on the page re: defining project scope. Refers to 2 types of scope but only bullets 1 type.
thank you for your kind correction.