Scope Definition

October 31, 2009

Detailed description of the project and or product is what defines the scope. The project scope statement really defines what exactly needs to be done and what need not be part of the activities. The project charter is obviously the primary source for the scope definition. The major deliverables, assumptions and constraints as indicated at project initiation time provide the foundation to the scope statement. You would need to analyze current assumptions, existing risks and constraints and review for inclusion any additional risks/constraints and related added assumptions.

The project charter, requirements document and organizational process assets are then used with the tools and techniques to generate detailed baseline scope document. Expert judgment, product analysis, alternatives identification and facilitated workshops to elicit as complete a set of requirements as possible are used to process inputs further. The project scope document and related updates created now becomes the baseline document.

Inputs for Defining Scope

The project charter usually contains a top level description of the project and product deliverables. A project charter typically contains a lot of related details- particularly about the goals to be achieved. Project purpose and justification, project objectives that are measureable and their success criteria, high level requirements, project description and associated risks, summary milestones and summary budget are some essentials. Additionally project approval requirements and assigned project manager and his level of authority and responsibilities need to be defined as completely as possible. The approval items include what constitutes project success, person responsible for deciding project success and who signs off on the project. Lastly the sponsor(s) and others authorizing the charter are included. Some organizations may not have such a charter but a document that defines the major issues needs to be created.

Requirements document correlates individual requirements with business needs. Initial high level requirements are refined progressively. They would be included in the baseline when the requirements are measurable and testable and thus are unambiguous. They need to be traceable to the original high-level requirements statements, consistent and obviously acceptable to stakeholders. The charter should generally include, but not be limited to, business need/ opportunity and why the project needs to be taken up, functional requirements (product features/definition of the service etc.), non-functional requirements such as level of service, safety and security etc., quality and reliability and availability (if applicable), acceptance criteria, impact on other areas of organization such as call center, sales force or technology group, impacts internal, support and training requirements etc. Lastly, but not the least, the assumptions and constraints are to be included.

Organization process assets that impact the scope definitions are policies, procedures and templates in use for scope document, project files form earlier projects and lessons learnt from older projects and earlier phases of the same project

Popularity: 2% [?]


Leave a Reply

Your email address will not be published. Required fields are marked *