Plan Scope Management is the process of creating the scope and requirements management plans that document how your scope will be defined, validated, and controlled. For a test project this may consist of several process documents that, together, define your scope and requirements management plans.
By the time the test manager arrives on the project there are usually substantial project assets that can be used to analyse and assess the various components of the proposed scope. By knowing what is in your scope, you can create plans for managing it. Assets may include:
- Your test charter
- The outline of your test strategy
- WRICEF registers
- Project change control boards
- Stream project plans and deliverables
- Blueprint process design documents
- Fit / Gap analysis and Requirements Traceability Matrix
- Architect’s To-be models
- Data team load objects
- Lessons learned knowledge bases
- Existing test tools and internal business processes
Many of these will be recognised as part of the overall project scope and requirements management plan.
Developing the test-specific scope and requirements management plan for how you manage change into the test phase may require meetings with stakeholders (including project management and team members) to confirm your approach. For example, your defect management process may need to define the difference between a defect and a change request and the process for managing each; the project culture may accept minor change requests as acceptable scope creep but major ones as requiring change control board approval – in which case, what are your definitions of “minor” and “major” changes, and who has the delegated authority to approve minor changes directly?
Questions that you should ask for your scope and requirements management plan should include:
- How are changes throughout the project being identified and recorded?
- How will I know what approved changes to my scope are being made?
- Who approves such changes?
- How are the changes being released for testing? Is this different to the usual process for this project?
- How will I inform my stakeholders of scope changes?
- How and by whom will the formal acceptance of deliverables of scope be made?
- Do the answers to any of the above change depending on what phase the project is is? For example, pre-UAT vs post-UAT?
The answers to these questions can be as informal as a meeting invite to the change control board, or can be more formalised through the use of process flow slides and change documentation.
|Previous Page - 5.1 Plan Scope Management||Next Page - 5.3 Define Scope|