7. Understand project scope management

Question 1

7.1 Explain how to define scope in terms of outputs, outcomes and benefits (including use of product, cost and work breakdown structures)

Answer 1

Outputs (deliverables) are the tangible or intangible products typically delivered by a project.
Outcomes are the changed circustances or behaviour that results from the use of an output and leads to the realisation of benefits.

Scope management is the process of identifying, defining and controlling scope.

When defining scope - look at interfaces with projects / programmes.

■ A Product Breakdown Structure is used to identify the scope
of what will be delivered.
■ A Work Breakdown Structure is used to capture the activities
to be completed in order to deliver the project outputs,
comprising scope
■ Cost breakdown structure is the hierarchical breakdown of a project into cost elements, normally aligned with WBS.

Question 2

7.2 explain how to establish scope through requirements management processes (such as gather, analysis, justifying requirements, and
baseline needs)

Answer 2

■ Gather requirements – collect requirements from the various
project stakeholders (through workshops, surveys, focus groups, modelling & simulation). Agile approaches are designed to continuously gather and refine req. on the assumption that stakeholders are not sure of their needs.
■ Analyse requirements – assess the requirements, checking for
gaps and conflicts. Conflicts may need to be escalated to sponsor.
■ Justify requirements – prioritise the requirement set,
understanding the needs from the wants. MoSCoW - trading against cost and time
■ Baseline - the final step of the process. Allows all of the requirements to be documented, and prioritised in a single document. Presented to stakeholders for their agreement. Changes via formal change control.

Question 3

7.3 explain how to manage scope through configuration management processes (such as planning, identification, control, status accounting, and verification audit)

Answer 3

■ Planning – defining the procedures and processes to follow
for configuration management of the project and who is
responsible for these activities.
■ Identification – breaking down the project into configurable
items and giving each item a unique reference. Linked to PBS.
Once identified, this info will be baselined as will the description. It is important to identify interfaces.
■ Control – ensuring that changes to the items are controlled.
■ Status accounting - Documenting and reporting the changes to the config of the system. Normally produced at the end of a stage.
■ Verification - Independant review of the processes and compliance within your config management system.

Question 4

7.4 explain different stages of a typical change control process (such as request, initial evaluation, detailed evaluation, recommendation, update plans, and implement)

Answer 4

■ Request – documenting the change in a change request, so
that it is clear what the change is and who has requested the
change. Request may include unique ID, date, benefits / likely impacts. Captured on a register.
■ Initial / Detailed Evaluation – the project team makes a detailed impact assessment of what would need to change as a result of the
change request, including understanding the impact on the
project success criteria.
As detailed evaluation may require significnat investment in resources to review - an initial eval may be required first. Change will look at impact to TCQS + R.
■ Recommendation - presented by PM to sponsor - may need to verify with change committee or steering group. Accepted / rejected / further information required.
■ Update plans - may include schedule / QP, PMP, forecasts etc. Update change log.