7. Understand project scope management Flashcards
7.1 Explain
how to define scope in terms of outputs, outcomes and benefits (including the use of product, cost and work breakdown structures)
Scope - The totality of the outputs, outcomes and benefits and the work required to produce them.
Scope change - Any change in a project scope that requires a change in the project’s cost or schedule.
Scope creep - The term sometimes given to the continual extension of the scope of some projects.
Scope management - The process whereby outputs, outcomes and benefits are identified, defined and controlled.
Scope of work - A description of the work to be accomplished or resources to be supplied.
Scope statement - A documented description of the project that identifies the project boundaries, its output, approach and content. It is used to provide a documented basis to help make future project decisions and to confirm or develop a common understanding of the project’s scope by stakeholders.
Scope verification - A process that ensures that all identified project deliverables have been completed satisfactorily.
Output The tangible or intangible product typically delivered by a project. Used interchangeably with deliverable and product.
Outcome - The changed circumstances or behaviour that results from the use of an output and leads to realisation of benefits.
Benefit - A positive and measurable impact of change.
Product breakdown structure (PBS) - A hierarchy of deliverables that are required to be produced on the project. This forms the base document from which the execution strategy and product-based work breakdown structure may be derived. It provides a guide for configuration control documentation.
Cost breakdown structure (CBS) - A hierarchical structure used to organise the project costs according to category, often aligning them with the organisation’s budgeting system. It facilitates tracking the budget performance of the project.
Work breakdown structure (WBS) - Defines the total work to be undertaken and provides a structure for all control systems. It allows a project or programme to be divided by level into discrete groups for programming, cost planning and control purposes.
Product - A tangible or intangible component of a project’s output. Used interchangeably with deliverable and output.
Work - The total number of hours, people or effort required to complete an activity.
Impact The assessment of the effect on an objective of a risk occurring.
Brief The output of the concept phase of a project or programme.
Activity - (1) A task, job, operation or process consuming time and possibly other resources. (2) The smallest self-contained unit of work in a project.
Activity duration - The length of time that it takes to complete an activity.
Activity ID - A unique code identifying each activity in a project.
Activity network - See Network diagram.
Activity status - The state of completion of an activity.
Work package - A discrete element of project scope at the lowest level of each branch of the work breakdown structure. Collectively, the work packages specify all the work and products included in the project.
- be clear on boundaries and interfaces with adjacent projects - avoid duplication, conflicts, omission of work, within a prog or portfolio, other standalone projects or BAU
Define scope in terms of OBS
- requirements gathering - sponsors wants and needs
- options
- chosen option
- PBS - hierarchical structure - main output at top / next level down shows higher level components and so on -until have individual products
- each product has defined acceptance criteria and quality control methods
- PBS used to do initial scope verification with stakeholders - agree expectations and what’s in/out of scope to avoid later misunderstanding, issues, change control - and revisit during project
- incomplete scope definition = time delays, cost growth, benefits reduction
- once categorised project to create products agreed - define WBS
- WBS - activities to be scheduled and resourced to meet all requirements and benefits
- activities / work packages then cost estimated, scheduled, and people/material/equipment etc resourced
- activities / work packages given coded references to track in business systems
- CBS is result - hierarchical breakdown of a project into cost elements
- WBS prepared in relation to who will be responsible for carrying out work in WBS
- OBS - organisation breakdown structure - describes structure of organisation required to complete work-packages
7.2 Explain
how to establish scope through requirements management processes (such as gathering, analysing, justifying requirements and baseline needs) [GAJRBN]
Requirements The stakeholders’ wants and needs clearly defined with acceptance criteria.
Requirements definition A process that ensures the project includes all the work required to complete it, and then defines that work.
Requirements management The process of capturing, assessing and justifying stakeholders’ wants and needs.
Baseline - The reference levels against which a project, programme or portfolio is monitored and controlled.
Baseline cost(s) - The amount of money a project or activity was intended to cost when the project plan was baselined.
Baseline date(s) - The original planned start and finish dates for a project or an activity when the schedule was baselined.
Baseline plan - The fixed project plan. It is the standard by which performance against the project plan is measured.
Baseline schedule - The fixed project schedule. It is the standard by which project schedule performance is measured.
Value - A standard, principle or quality considered worthwhile or desirable. In value management terms, value is defined as the ratio of ‘satisfaction of requirements’ over ‘use of resources’.
Functional analysis - The identification and analysis of the functional attributes of different solutions.
Functional analysis and system technique (FAST) - An evolution of the value analysis process. FAST permits people with different technical backgrounds to effectively communicate and resolve issues that require multi-disciplined considerations. FAST builds on value analysis by linking the simply expressed verb-noun functions to describe complex systems.
Minimum viable product - A product with just enough features to satisfy early users and to provide feedback for future product development.
Establish scope through requirements management
- ensure clear link between benefits, project success criteria, project objectives and project requirements
- requirements are clear, unambiguous and expressed as simply as possible
- high level requirements defined during concept phase - sufficient to make investment decision / proceed to definition phase
- ongoing through project life cycle
- requirements = principal project outputs/deliverables - and so helps define project scope
- 1st step - gathering - interviews, surveys, workshops, focus groups, modelling - agile approach enables continuous gathering and refinement of requirements (stakeholders not sure of needs)
- 2nd step - analysing - functions such as scheduling and investment appraisal - with value-based techniques such as function analysis and function cost analysis = results in a thorough understanding of requirements and tests assumptions
- product owner vital role to ensure requirements are aways seen relative to business need and advises on acceptance criteria
- value represents the amount of benefit from the requirement - can use to justify priority
3rd step - justifying requirements and baseline needs - when more requirements are requested than feasible to deliver = prioritisation - MoSCoW (in agile S and C sacrificed if project was predicted to go over budget or be late)
- worst case scenario project just delivers MVP - minimal viable product
Requirements management The process of identifying, capturing, assessing and justifying and agreeing ICAJA stakeholders’ wants and needs.
- requires capture via a structured process
- process incrementally breaks down requirements in hierarchical manner considering different conditions and scenarios
- once defined validate requirements with sponsor to ensure full scope has been validated
- mitigates risk over disputes in completion and transition of deliverables into use
7.3 Explain
how to manage scope through configuration management processes (such as planning, identification, control, status accounting and verification audit) [PICSAVA - Picture savalon]
Configuration The functional and physical characteristics of a product as defined in its specification and achieved through the deployment of project management plans.
Configuration management encompasses the technical and administrative activities concerned with the creation, maintenance, controlled change and quality control of the scope of work.
Configuration identification - The unique identification of all items within the configuration. It involves breaking down the project into component parts or configuration items and creating a unique numbering or referencing system for each item and establishing configuration baselines.
Configuration control - A system to ensure that all changes to configuration items are controlled. An important aspect is being able to identify the interrelationships between configuration items.
Configuration status accounting - A record and report of the current status and history of all changes to the configuration. It provides a complete record of what has happened to the configuration to date.
Configuration audit A check to ensure that all deliverables (products) in a project conform with one another and to the current specification. It ensures that relevant quality assurance procedures have been implemented and that there is consistency throughout project documentation.
Configuration item - A part of a configuration that has a set function and is designated for configuration management. It identifies uniquely all items within the configuration.
Version control - The recording and management of the configuration of different versions of the project’s products.
- version control of document and information
- discipline of CM more complex
- PBS plus detailed descriptions of each product = project configuration
- once PBS + descriptions baselined is subject to change control and config mgmt
- planning, identification, control, status accounting and verification audit) [PICSAVA - PICture SAVAlon]
- planning - Configuration Management Plan includes procedures, roles and responsibilities - often part of Quality Management Plan
- identification - breakdown project into configuration items
- control - ensures all changes to items are controlled
- status accounting - reports and records in relation to a deliverable and its configuration information - enables traceability - configuration record identifies status of item (version control) - what when who made changes
- verification audit - at end of life cycle phase/ deliverable finished / transitioning output into use (at minimum) - determines if a deliverable conforms to its requirements and configuration information - could also carry out audits during life cycle during change control to check products were being used according to their current configuration status
KEY OUTPUTS
- confidence that current version of any configuration item is known (doc, drawing, software or other asset)
- ** documented traceability** between versions
- closely aligned to change control
- change control and configuration ensure deliverables meet the required specification, changes are beneficial and there is an audit trail
- apply to key management documents as well as products of a project or programme - e.g. business case and PMP subject to version control and audit to ensure they are fit for purpose and all changes recorded
- project team responsible for ensuring config management info is suitable for transfer to those who will be maintaining the product
7.4 Explain
different stages of a typical change control process (such as request, initial evaluation, detailed evaluation, recommendation, update plans, and implement) [RIE DE RUPI]
Change control The process through which all requests to change the approved baseline of a project, programme or portfolio are captured, evaluated and then approved, rejected or deferred.
Change request - A request to obtain formal approval for changes to the approved baseline = arise from issues, new stakeholder requirements, new regulations or changes in context - make it clear who requested and why
Change - A change to a project’s baseline scope, cost, time or quality objectives.
Control - Tracking performance against agreed plans and taking the corrective action required to meet defined objectives.
Request for change (RFC) - A proposal for a change to the project.
Change register or log - A record of all project changes: proposed, authorised, rejected or deferred.
Change control board - A formally constituted group of stakeholders responsible for approving or rejecting changes to the project baselines.
Change authority An organisation or individual with power to authorise changes on a project.
Change freeze A point after which no further changes to scope will be considered.
Change management - The overarching approach taken in an organisation to move from the current to a future desirable state using a coordinated and structured approach in collaboration with stakeholders.
