Define Scope is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the product, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope.
Since all of the requirements identified in Collect Requirements may not be included in the project, the Define Scope process selects the final project requirements from the requirements documentation delivered during the Collect Requirements process. It then develops a detailed description of the project and product, service, or result.
The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation. During project planning, the project scope is defined and described with greater specificity as more information about the project is known. Existing risks, assumptions, and constraints are analyzed for completeness and added or updated as necessary. The Define Scope process can be highly iterative. In iterative life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one iteration at a time and the detailed planning for the next iteration is carried out as work progresses on the current project scope and deliverables.
Inputs
1) Scope management plan: a component of the project management plan that establishes the activities for developing, monitoring, and controlling the project scope.
2) Project charter: provides the high-level project description and product characteristics. It also contains project approval requirements. If a project charter is not used in the performing organization, then comparable information needs to be acquired or developed, and used as a basis for the detailed project scope management statement. Organizations that do not produce a formal project charter will usually perform an informal analysis to identify the content necessary for further scope planning.
3) Requirements documentation: will be used to select the requirements that will be included in the project.
4) Organizational process assets: can influence how scope is defined
- Policies, procedures, and templates for a project scope statements;
- Project files from previous project; and
- Lessons learned from previous phrases or projects.
Tools & Techniques
1) Expert Judgment: used to analyze the information needed to develop the project scope statement. such judgement and expertise is applied to any technical detail.
2) Product Analysis: Each application area has one or more generally accepted methods for translating high-level product descriptions into tangible deliverables. Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, system engineering, value engineering, and value analsyis.
3) Alternatives Generation: used to develop as many potential options as possible in order to identify different approaches to execute and perform the work of the project. A variety of general management technique can be used, such as brainstorming, lateral thinking, analysis of alternatives, etc.
4) Facilitated Workshops: The participation of key players with a variety of expectations and/or fields of expertise in these intensive working sessions helps to reach a cross-functional and common understanding of the project objectives and its limits.
Outputs
1) Project Scope Statement: description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes, in detail, the project's deliverables and the work required to create those deliverables. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions that can assist in managing stakeholder expectations. It enables the project team to peform more detailed planning, guides the project team's work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project's boundaries.
2) Project Document Updates: may be include
- Stakeholder register
- Requirements documentation and
- Requirements traceability matrix.
댓글 없음:
댓글 쓰기