5) SCOPE Management

 |  SCOPE Management

• ensure the inclusion of all and only the work required to complete the project successfully
• Product Scope – requirements needed to be fulfilled to create the product, assessed against the product requirements and WBS
• Project Scope – activities and processes needed to be performed to deliver the product scope, assessed against the scope baseline (scope statement, WBS and WBS dictionary), e.g. including testing & quality assurance, assessed against the PM plan
• scope management to prevent scope creep (additional requirements added without any proper control)
• The completion of project scope is measured against the project management plan whereas the completion of product scope is measured against the product requirements/WBS
• gold plating – additional requirements initiated by the team members to exceed expectation, considered a subset of scope creep
• Scope Baseline: scope statement + WBS + WBS dictionary
• WBS includes only the deliverables/outcomes/results (not actions)

Project Scope Management PITTOs:

Processes	Inputs	Tools & Techniques	Output
Plan Scope Management	Project Management Plan Project Charter Enterprise Environment Factors Organization Process Assets	Expert Judgments Meetings	Scope Management Plan Requirements Management Plan
Collect Requirements	Scope Management Plan Requirements Management Plan Stakeholder Management Plan Stakeholder Register Project Charter	Interviews Focus Groups Facilitated Workshops Group Creativity Techniques Group Decision-making Techniques Questionnaire and Surveys Observations Prototypes Benchmarking Context Diagram Document Analysis	Requirements Documentation Requirements Traceability Matrix
Define Scope	Scope Management Plan Project Charter Requirements Documentation Organization Process Assets	Expert Judgments Product Analysis Alternatives Identification Facilitated Workshops	Project Scope Statement Project Document Updates
Create WBS	Scope Management Plan Project Scope Statement Requirements Documentation Enterprise Environment Factors Organization Process Assets	Decomposition Expert Judgments	Scope Baseline Project Document Updates
Validate Scope	Project Management Plan Requirements Documentation Requirements Traceability Matrix Verified Deliverables Work Performance Data	Inspection Group Decision Making Techniques	Accepted Deliverables Change Requests Work Performance Info Project Document Updates
Control Scope	Project Management Plan Requirements Documentation Requirements Traceability Matrix Work Performance Data Organization Process Assets	Variance Analysis	Work Performance Info Change Requests Project Management Plan Updates Project Document Updates Organization Process Assets Updates

Plan Scope Management

• Scope Management Plan: how the scope will be defined, validated and controlled
• including how to prevent scope creep, how to handle change requests, escalation path for disagreement on scope elements between stakeholders, process for creating scope statement, WBS, processing CR, how the deliverables will be accepted
• Requirements Management Plan: how the requirements will be managed, documented and analyzed,
• including how to process requirements, address missed requirements, configuration management, prioritize requirements, metrics (and rationale) for defining the product, define the traceability structure (in RTM), authorization level for approving new requirements
• important: primary means to understand and manage stakeholder expectations

Collect Requirements

• Requirement: a condition/capability that must be met /possessed by a deliverable to satisfy a contract/standard/etc., including quantified/documented needs, wants, expectation of the sponsor/stakeholder/customer
• Business requirements – support business objectives of the company
• Stakeholder requirements
• Solution requirements - functional (product behavior) and nonfunctional requirements (reliability, security, performance, safety, etc.)
• Transitional requirements : temporary capability including data conversion/tracking/training
• Project requirements : actions/processes/conditions the project needs to met
• Quality requirements : quality criteria defined by stakeholders

• Requirements Collection Tools
• interviewing (expert interviewing)
• focus groups (with SME and pre-qualified stakeholders)
• facilitated workshops (QFD (Quality Function Deployment) – capture VOC voice of customer, translate customer needs into requirements; JAD (Joint Application Design) – facilitated workshop for IT and knowledge workers)
• questionnaires and surveys
• observation (shadowing or Gemba)
• prototypes
• context diagrams (diagrams showing input/source and output, to show how people interact with the system)
• document analysis
• Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis
• Group Creativity Techniques: brainstorming, nominal group technique (to rank brainstormed ideas by voting anonymously), mind-mapping, affinity diagram (KJ method – group ideas into larger categories based on their similarity and give titles to each group), Delphi technique (for experts with widely varying opinions, all participants are anonymous, evaluation of ideas funneled by a facilitator), Multi-criteria Decision Analysis (with a decision matrix)
• Group Decisions-making Techniques: Analytic Hierarchy Process (AHP, for complex decisions, give different weighs to factors to build an hierarchy), Voting (unanimous, majority >50%, plurality, dictatorship)
• Requirements Traceability Matrix tracks requirements from origins to deliverables, including source of requirements and completion status, effective to prevent gold plating (also work with work authorization system)
• requirement documentation needs to be unambiguous, traceable, compete, consistent and acceptable to key stakeholders and is approved by the customer and other stakeholders

Define Scope

• project & product scope, outlines what will be and what will NOT be included in the deliverables, including details of risks, constraints and assumptions
• vs project charter which includes high-level descriptions
• provides alternatives if the budget and schedule could not meet management’s expectations
• value engineering is a part of the product analysis technique (Value Engineering (value analysis, value management, value methodology) – finding alternatives to constraints to improve product/reduce cost without sacrificing the scope)
• project scope statement includes objectives, (project and product) scope, requirements, boundaries, deliverables, acceptance criteria, constraints, assumptions, milestones, cost estimation, specifications, configuration management requirements, approval requirements, etc.
• The scope statement is progressively elaborated

Create WBS

• the WBS must be created (if take on a running project without WBS, stop the project and prepare the WBS first)
• WBS is a structured hierarchy created by the organization/stakeholders, can be in an organization chart or table form, based on the project deliverables (not tasks needed)
• can be a template in OPA
• a higher level above a work package is ‘control account‘ (control point where scope, cost and schedule are compared to earn value for performance measurement), a work package can have only ONE control account
• WBS includes 100% of scope (100% rule)
• code of accounts: a numbering system to identify WBS components
• chart of accounts: a list of all account names and numbers
• 1.1 for the 2nd level, 1.1.1 for the 3rd level
• WBS is a decomposition tool to break down work into lowest level manageable (time and cost can be estimated, work package can be assigned to a team member) work packages, e.g. by phase or major deliverables
• different work packages can be at different levels of decompositions
• WBS does not show dependencies between work packages, but a WBS dictionary does (WBS dictionary clarifies WBS by adding additional information)
• the major deliverables should always be defined in terms of how the project will actually be organized, for a project with phases, the decomposition should begin with the phase first
• scope baseline, an output from Create WBS, is created by the project team
• the work packages are broken down enough to delegate to a staff, usu. 8 – 80 hours work

Validate Scope

• gain formal acceptance of deliverables from customer/stakeholders (e.g. obtain customer sign off, requirements validations, etc.) near the end of project/phase/each deliverable, e.g. user acceptance test
• work performance data tells how the deliverables were created, work performance data includes non-conformance and compliance data
• change requests may be an output
• if no formal sign off is received as stipulated, follow the pre-defined process in PM plan, e.g. escalation to management
• often preceded by Control Quality Process to give the verified deliverable as input to this process, verified deliverables is fed from the control quality process
• vs Control Quality: the process of monitoring/recording results of executing quality activities to assess performance and recommend necessary changes, e.g. unit testing -> high quality vs low quality
• need to perform even in case of early termination/cancellation of the project to save any usable deliverables for other projects

Control Scope

• assessing additional requirements by the customer or proactively overlooking the project scope
• measure the work product against the scope baseline to ensure the project stays on track proactively, may need preventive, corrective actions or defect repair
• to prevent unnecessary changes (either internally or externally requested) to the project
• a documented and enforced change control process
• the customer has the ultimate authority to change scope while the senior management can make use of management reserves
• variance analysis – method to compare planned (baseline) and actual work and determine the causes/actions e.g. update baseline (keep the variance) or preventive/corrective actions, both need CR
• work performance info – scope variance, causes, recommended action
• may update the inputs – requirements documentation & requirement traceability matrix & lessons learnt in OPA
• in general, disagreement should be resolved in favor of the customer

4) INTEGRATION Management

 |  INTEGRATION Management

• Integration management is needed when processes interacts
• to identify, combine, unify and coordinate various processes/activities and manage the inter-dependencies
• communication is most important
• a PM Plan not meeting requirements is a defect

Project Integration Management PITTOs:

Processes	Inputs	Tools & Techniques	Output
Develop Project Charter	Project SOW Business Case Agreements Enterprise Environmental Factors Organization Process Assets	Expert Judgments Facilitation Techniques	Project Charter
Develop Project Management Plan	Project Charter Outputs from Planning Processes Enterprise Environment Factors Organization Process Assets	Expert Judgments Facilitation Techniques	Project Management Plan
Direct and Manage Project Work	Project Management Plan Approved Change Requests Enterprise Environment Factors Organization Process Assets	Expert Judgments PMIS Meetings	Deliverables Work Performance Data Change Requests PM Plan Updates Project Document Updates
Monitor and Control Project Work	Project Management Plan Schedule Forecasts Cost Forecasts Validated Changes Work Performance Info Enterprise Environment Factors Organization Process Assets	Expert Judgments Analytical Techniques PMIS Meetings	Work Performance Reports Change Requests PM Plan Updates Project Document Updates
Perform Integrated Change Control	Project Management Plan Work Performance Reports Change Requests Enterprise Environment Factors Organization Process Assets	Expert Judgments Meetings Change Control Tools	Approved Change Requests Change Log PM Plan Updates Project Document Updates
Close Project or Phase	Project Management Plan Accepted Deliverables Organization Process Assets	Expert Judgments Analytical Techniques Meetings	Final Product/Service/Result Transition Organization Process Assets Update

Develop Project Charter

• formally authorize the project and allow the PM to apply organizational resources
• well-defined project start and project boundaries
• project charter is a several page document including high level information of the project: project background, business case, goals (S.M.A.R.T. specific, measurable, attainable, realistic, time-bound), who is and the authority of the project manager, budget, risk, stakeholders, deliverables, approval criteria, etc.
• can link the project to other works in the organization through portfolio/program management
• signed off by the sponsor (the one who supply the money/resources)
• agreements: either a contract (for external parties), letter of intent, service level agreement, etc. (can be legally binding or NOT)
• a charter is NOT a contract because there is no consideration
• PMO may provide the expert judgment
• Facilitation techniques includes brainstorming, conflict resolution, problem solving, meeting, etc.

Develop Project Management Plan

• the project management plan is a formal written document on how the project is executed, monitored and closed, including all subsidiary management plans (scope, requirements, change, configuration, schedule, cost, quality, process improvement, human resource, communication, risk, procurement) and documents (cost baseline, schedule baseline, scope baseline, performance measurement baseline, cost estimate, schedule, responsibility for each deliverable, staff requirements) and some additional documents/plans (selected PM processes and level of implementation)
• the contents to be tailored by the PM (tailoring) to suit each project
• created by PM, signed off by destined KEY stakeholders (e.g. project sponsor, project team, project manager)
• may be progressively elaborated in iterative phases (outputs from other processes), this must be the final process/iteration to consolidate the PM Plan
• when the project management plan is baselined (i.e. validated and then signed off by key stakeholders), it is subject to formal change control and is used as a basis for comparison to the actual plan
• after base-lining, the senior management must be consulted if these high level constraints are to be altered (whether to use the management reserves)
• can be re-baselined if significant changes are seen (scope change, internal changes/variances (for the project execution), external factors) <- needed to be approved by sponsors/stakeholders/senior management, must understand the underlying reasons first (built-in costs is not usually a legitimate reason)
• cost baseline (specific time-phased budget), schedule baseline (-> knows when to spend money), scope baseline (includes scope statement, WBS, WBS dictionary): whether preventive/corrective/defect repair actions are needed
• the performance measurement baseline (PMB) is an approved scope-schedule-cost plan for the project work (to use in earned value management), it includes contingency reserve but excludes management reserves
• configuration management (works with change control management plan), document all change versions of project deliverables and completed project components, PMIS includes: Configuration Management System (contains the updated deliverable/project specifications and processes) and Change Control System (contains formal documents for tracking changes)
• configuration management system contains the most updated version of project documents
• other project documents NOT included in the project management plan:
• Kick-off Meeting: at beginning of the project/phase, participants including project team+stakeholders, element including project review, responsibility assignment matrix, participation of stakeholders, escalation path, frequency of meetings
• Microsoft Project is considered by PMI as close to a bar chart, not an PMIS

Direct and Manage Project Work

• create project deliverables, acquire/assign/train staff, manage vendors, collect data for reports, document lessons learned
• implement approved process improvement plans and changes, change requests include corrective actions, preventive actions, defect repair and updates (all considered to be change requests)
• if the PM discovers a defect, he/she should instruct the team to make defect repair during this process (need change request but may be approved by the PM only (if stipulated in PM Plan for minor change))
• approved change requests – approved in the perform integrated change control, may include preventive, corrective and defect repair actions
• change requests may arise as a result of implementing approved change requests
• PM should be of service to the team, not a boss
• a work authorization system (part of EEF) defines approval levels needed to issue work authorization (to allocate the work) and is used to prevent scope creep as formal approval must be sought before work begins
• Stakeholder risk tolerance is part of EEF
• Face-to-face meeting is considered to be most effective
• The PM Plan can be considered as a deliverable
• most of the time of project spends here

Monitor and Control Project Work

• validated changes – actions taken as a result of the approved change requests are validated against the original change requests, to ensure correct implementation
• corrective and preventive actions usually don’t affect the baseline, only affect the performance against the baseline
• defect repair: considered as rework, deliverable not accepted, either rework or scrap, strongly advise defect prevention to defect repair
• the work performance info is fed from all other control processes (e.g. control schedule, control stakeholder engagement, control communications, control costs, control quality, etc.)
• variance analysis is NOT a forecast method
• Perform Integrated Change Control
• the PM should influence the factors that cause project change
• changes arises as a result of: missed requirements, views of stakeholders, poorly designed WBS, misunderstanding, inadequate risk assessment
• all the process is documented in the change log
• tracked using a change management system, also affect configuration management system
• configuration control: changes to deliverables and processes
• change control: identify/document/approve changes
• configuration management activities: configuration identification, configuration status accounting, configuration verification / audit to ensure the latest configuration is adopted and delivered
• for a change request: 1) identify need, 2) assess the impact, response and alternatives, 3) create CR, 4) Meet with stakeholders, 5) obtain approval from CCB (change control board) or PM as defined in roles and responsibility document/PM Plan, 6) request more funding if needed
• customers/sponsors may need to approve certain decisions by CCB (if they are not part of CCB)
• communicate the resolutions (approve or reject) to change requests to stakeholders
• Burnup chart vs Burndown chart

Close Project or Phase

• ensure all procurements are closed (in the Close Procurements Process) before formal closure of the project/phase
• create the project closure documents
• formal sign off by designated stakeholders/customer
• obtain formal approval to close out the project/phase (administrative closure)
• obtain approval and deliver the deliverables (maybe with training)
• finish and archive documentations, lessons learnt and update to organizational process asset
• if the contract comes with a warranty, make sure that changes during the project are evaluated against the origin clauses, ensure alignment of the warranty and changes
• to close a project as neatly and permanently possible
• for multi-phase projects, this process will be performed once for every phase end and once for the whole project (5 times for project with 4 phases)
• litigation can be further pursued after the closure