III PMF MANAGEMENT SOLUTIONS. Scope Management

Transcription

1 III PMF MANAGEMENT SOLUTIONS Scope Management

2 Session Objectives Define the term scope, meaning scope of a project: Product scope the features, functions and characteristics of the project product. Project scope the work required to be undertaken to deliver the project product. Clarify the purpose of scope within a project. Identify how scope management is critical to the successful delivery of the project. Identify how the scope is identified, defined, approved and managed throughout the project lifecycle.

3 Definition of Scope Scope is defined as all the work that must be undertaken in order to create the purpose of the project (product): Product scope the characteristics, features and functions of the project product. Project scope the work required to be undertaken to deliver the project product. The scope of a project is the sum total of all of a project's products (often referred to as the deliverable or objective) and their requirements, specifications and/or features. PMBOK The process of developing a detailed description of the project and product (p 104). Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project. Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI

4 Purpose Defines the project scope of work in terms of deliverable output (product and/ or service, in regards to both: What is in and out of scope. Internally and / or externally generated. Further decompose the deliverable into components to support configuration management: Configuration Management establishes and maintains (develops, records, stores and tracks) the versions or different revisions to the design, blueprints, technical specifications, and notes which one is the latest revision of the project product. Provide a framework for: Integrating intermediate deliverables and work packages with other aspects of initiation, planning, execution, monitoring and controlling, and closing. Managing and communicating accountabilities and responsibilities, schedule, risk, performance, dependencies, budget, project status and progress. May require progressive elaboration of scope over project lifecycle. Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI 4

5 Value of Scope PwC Pricewaterhouse Coopers (PwC) measure project management and organisational success via five key performance indicators, delivering projects: On time; Within budget; To scope; To quality standards; and With the intended business benefits. PwC, (2012). Insights and Trends: Current Portfolio, Programme and Project Management Practices. 5

6 Value of Scope PMI Project Management Institute measure success based on: On time; To scope; Within budget; Focusing on execution and alignment, to include: Maturing portfolio management practices to improve the balance between investment and risk; Improving organizational agility to allow flexibility and quick response; and Tracking benefits realization past the end of a project through operations to verify return on investment. PMI, (2013). PMI's Pulse of the Profession: The High Cost of Low Performance. 6

7 Process of Scope Scoping is a communication and information gathering exercise. Scoping takes information from the client brief, and other relevant sources as determined by the Project Organisation, reviews the proposed benefits then sets about determining the how to address the brief. Scoping aims to clearly define the project product in specific detail to ensure there is no point of disagreement between the Client Organisation and the Project Organisation. 7

8 Scoping in Practice Scoping the project defines all the work to be carried out: Listed as inclusions. Scoping the project defines what work is not to be carried out: Listed as exclusions. Establishes the boundaries or the parameters of the project. Enables the performance of the project management process to be measured. 8

9 AS ISO Configuration Mgt Configuration: interrelated functional and physical characteristics of a product Configuration item: entity within a configuration that satisfies an end use function (includes both management and specialist products) Product configuration information: requirements for product design, realization, verification, operation and support Configuration baseline: approved product configuration information that establishes the characteristics of a product at a point in time that services as a reference for activities throughout the product lifecycle Configuration management: coordinated activities to direct and control information Standards Australia. (2003). AS ISO 10007: Quality management systems Guidelines for configuration management. Sydney: Standards Australia. 9

10 Configuration Management Processes Configuration Identification: Specifying which items will be subject to configuration control and to what level. Configuration Control: Managing (including authorizing and implementing) changes to the configuration items and baselines. Configuration status accounting: Recording and reporting the configuration information, including configuration identification, status of proposed changes, implementation status of approved changes, etc. Configuration verification and audit: Reviews and configuration audits comparing the actual status of configuration items and against the authorized state included in configuration item records. Project Management Institute. (2008). A guide to the project management body of knowledge (4th ed.). Newtown Square, Pennsylvania: PMI, pp Office of Government Commerce. (2009). Managing successful projects with PRINCE2. London: The Stationery Office, pp

11 PMBOK Scope Processes 5.1 Plan Scope Management The process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled. 5.2 Collect Requirements The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives. 5.3 Define Scope The process of developing a detailed description of the project and product. 5.4 Create WBS The process of subdividing project deliverables and project work into smaller, more manageable components. 5.5 Validate Scope The process of formalizing acceptance of the completed project deliverables. 5.6 Control Scope The process of monitoring the status of the project and product scope and managing changes to the scope baseline (p 104). Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI 11

12 PMBOK Scope Mgt Overview Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI, p

13 5.1 Plan Scope Management Process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled. Fundamental components include: Development of the project charter Provides a preliminary delineation of roles and responsibilities, outlines the project objectives and benefits, identifies the main stakeholders, and defines the project manager s authority. It serves as a reference of authority for the future of the project. The terms of reference generally form part of the project charter. Development of the project management plan A formally approved document that used to guide project execution and control. Identification of the integrated change control process to oversee amendments to the approved project management plan. Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI 13

14 5.2 Collect Requirements Process of determining, documenting, and managing stakeholder s needs to meet the project objectives. Simply, defining precisely what is included and what is not included in the project to clarify the parameters of the project. It can be counter intuitive: Project Organisations often attempt to deliver more than was agreed upon, to exceed the Client Organisations expectations: This places undue pressure on: Schedules; Budgets; Project personnel; and Increases risks. Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI 14

15 Requirements Traceability Matrix A document that helps correlate and trace project product requirements through their implementation, testing and/ or completion. It evaluates the relationship between different system components and provides the status of project requirements in terms of their level of completion. Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI 15

16 5.3 Define Scope Process of developing a detailed description of the: Project the process that will deliver the product; and Product the output (asset, objective, deliverable of the project). Initially outlined as a basic statement of what is required. Developed in granular detail to ensure definition. Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI, p

17 5.4 Create WBS The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project, and represents the work specified in the current approved project scope statement (p 125). Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts (p 126). Deliverable is any unique and verifiable product, result or capability to perform a service that must be produced to complete a process, phase, or project. Often used more narrowly in reference to an external deliverable, which is deliverable that is subject to approval by the project sponsor or customer (PMBoK 2006, p.4). Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI 17

18 Part of the Organisational Part of Part the of Project the Part Organisational Part Project Management of of the the Project Project Project Management Management Lifecycle Maturity (Initiation Lifecycle Lifecycle Framework Phase) Order of PMBOK Activities Enterprise Environmental Factors (Organisational Culture) (Planning (Planning Phase) Phase) Described in Section Industry specific WBS standards, relevant to the nature of the project, may serve as external reference sources for creation of the WBS. For example, engineering projects may reference ISO/IEC on Systems Engineering System Life Cycle Processes [6], to create a WBS for a new project Create WBS: Inputs Organizational Scope Management Process Plan Assets Described in Section in The The organizational scope management process plan assets specifies that can how influence to create the WBS Create from WBS the process detailed include, project but scope are not statement limited and to: how the WBS will be maintained and approved Project Policies, Scope procedures, Statement and templates for the WBS; Described Project in files Section from previous The projects; scope and statement describes the work that will be performed and the work that is excluded. It also lists and describes the specific internal or external restrictions or limitations that may Lessons affect the learned execution from of previous the project. projects Project Requirements Scope Statement Documentation Described in Section in The Detailed project requirements scope statement documentation describes is the essential work for that understanding will be performed what needs and the to work be that produced is excluded. as the result It also of lists the and project describes and what the needs specific to be internal done to or deliver external the restrictions project and its or final limitations products that may Enterprise affect the Environmental execution of the Factors project. Described in Section Industry specific WBS standards, relevant to the nature of the project, may serve as Requirements external reference Documentation sources for creation of the WBS. For example, engineering projects may reference ISO/IEC Described on in Systems Section Engineering Detailed System requirements Life Cycle Processes documentation [6], to create is essential a WBS for a understanding new project. what needs Organizational to be produced Process as the result Assets of the project and what needs to be done to deliver the project and its final Described products. in Section The organizational process assets that can influence the Create WBS process include, but are not limited to: Scope Policies, Management procedures, Plan and templates for the WBS; Project files from previous projects; and Described Lessons in Section learned from previous The projects. scope management plan specifies how to create the WBS from the detailed project scope statement and how the WBS will be maintained and approved. 18

19 Scoping the Project PMBOK stresses the need for deciding what a project should deliver and how to plan to deliver that objective with a predominance for scoping a project using a work breakdown structure (WBS) approach (PMI, 2004). Developing the WBS essentially relies on a large number of well understood and well identified components that can be grouped into assemblies and these configured into subsystems, and thence into systems. Aproject becomes the summation of these systems that are required to deliver the need. The delivery must then move beyond the delivery of things to include services, such as: Knowledge of how to most effectively use the thing ; and How to optimise performance of the thing (Hobday, 2000). Steinfort, P and Walker, D 2007, 'Critical success factors in project management globally and how they may be applied to aid projects', in D. Baccarini (ed.) Proceedings of the PMOZ Achieving Excellence 4th Annual Project Management Australia Conference, Brisbane, Australia, August

20 5.5 Validate Scope Validate Scope is the process of formalizing acceptance of the completed project deliverables. The key benefit of this process is that it brings objectivity to the acceptance process and increases the chance of final product, service, or result acceptance by validating each deliverable (p 133). The verified deliverables obtained from the Control Quality process are reviewed with the customer or sponsor to ensure that they are completed satisfactorily and have received formal acceptance of the deliverables by the customer or sponsor (p 134). The Validate Scope process differs from the Control Quality process in that the former is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for the deliverables (p 134). Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI 20

21 5.6 Control Scope Control Scope is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. The key benefit of this process is that it allows the scope baseline to be maintained throughout the project (p 136). Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the Perform Integrated Change Control process (p 137). Control Scope is also used to manage the actual changes when they occur and is integrated with the other control processes (p 137). Project Management Institute (PMI), (2013), A guide to the project management body of knowledge (5th ed.), Newtown Square, Pennsylvania, PMI 21

22 PMF Scope Processes Establish a Scope Statement Identify Project Requirements Initiation Generate Product Breakdown Structure (PBS) Identify Detailed Scope of Work Generate Work Breakdown Structure (WBS) Planning Verify Scope of Work Implement Scope Management Plan Monitor Scope of Work Control Scope of Work Execution Validate Scope of Work Finalise Responsibility Transfer Review Scope Functional Processes Finalisation 22

23 Initiation Phase Scope Processes Establish a Scope Statement Identify Project Requirements Initiation Generate Product Breakdown Structure (PBS) Identify Detailed Scope of Work Generate Work Breakdown Structure (WBS) Planning Verify Scope of Work Implement Scope Management Plan Monitor Scope of Work Control Scope of Work Execution Validate Scope of Work Finalise Responsibility Transfer Review Scope Functional Processes Finalisation 23

24 Scope Initiation Actions Project Close (Start) Business Case / Project Brief Business Case / Project Brief Clarify the requirements of the project Not Approved Decision Gate Approved Proceed to to Planning Phase Assess technical components for compatibility Project Charter Project Charter Record project scope statement Initial Project Scope Project Manager Develops Initial Scope as part of Project Charter Project Office (Project Assurance) Potential Suppliers Supply Rep Advice Record assumptions constraints and dependencies Historic Lessons Learned Logs Conditions of of Approvals 24

25 Establish Initial Scope Statement The initial scope statement is a guide for the Project Management Team to utilise as they prepare the comprehensive scope of work. This process aids the elimination of ambiguity amongst the stakeholders as to what contributes to the project and its product, and what work doesn t not. Provide an example. 25

26 Identify Project Requirements The Project Management Team must clearly describe the product and all of its contributing components. The product breakdown structure (PBS) developed as part of the PC will aid in the identification of the product through breaking up the project into smaller parts. This process will also identify what external project approvals are required to support the continuance of the project: Primary approvals approvals that allow the project to be undertaken. Secondary approvals approvals that can be obtained in the planning phase, known as dependencies. 26

27 Dependencies Any external aspect that the project is dependent on to be delivered. This is generally limited to secondary approvals. Secondary approvals: Are required prior to planning the project. Are not likely to be disapproved. Are applied for during the planning phase to ensure limited resources are invested into the project prior to formal approval being granted. 27

28 Generate Product Breakdown Structure (PBS) Identification of the project product. Product base planning to divide work into smaller chunks. Develop a product breakdown structure (PMP): A breakdown of all the components of the product required to deliver the project product, deliverable or output. A hierarchical structure of the components or sub products. Identifies the relationships with other components (not time based). May be grouped under key stages (more manageable). Decomposition should be based on order of delivery requirements. Assists in the development of the WBS. 28

29 PBS Development Guidelines Is deliverable oriented therefore project activities are not listed. All PBS element names are nouns (descriptions), not verbs (actions). Include only sufficient and necessary deliverables (components). Not based on timing. Not structured strictly by process or organization Beneficial if arranged in chronological / sequenced structure. Aids the identification of: Product milestones. Performance targets. Top down estimates of the initial schedule and budget. Payment points. The make / buy analysis (internal and/ or external development). 29

30 Example PBS Conference PBS Office of Government Commerce. (2009). Managing successful projects with PRINCE2. London: The Stationery Office, p

31 Dombkin s WHOW Matrix Uncertainty WHAT are the Objectives Low Uncertainty High Design Type B Type D Implementation Somewhat Complex Concept Design Implementation High Extremely Complex Design Type A Uncomplicated Concept Type C Highly Complex Uncertainty HOW to Achieve Objectives Concept Design Implementation Close Dombkins, D. H. (2007). Complex Project Management: Seminal Essays. North Charleston, South Carolina: BookSurge Publishing, p Low 31

32 Planning Phase Scope Processes Establish a Scope Statement Identify Project Requirements Initiation Generate Product Breakdown Structure (PBS) Identify Detailed Scope of Work Generate Work Breakdown Structure (WBS) Planning Verify Scope of Work Implement Scope Management Plan Monitor Scope of Work Control Scope of Work Execution Validate Scope of Work Finalise Responsibility Transfer Review Scope Functional Processes Finalisation 32

33 Scope Planning Actions Project Close (Start) (Start) Approved Project Charter Project Charter Specify project product in detail Not Approved Decision Gate Approved Proceed to Proceed to Execution Phase Potential Suppliers Expand PBS into a comprehensive WBS Note all inclusions and exclusions Identify and record all assumptions Detailed Project Project Scope Scope Project Manager Develops Detailed Scope as part of Project Management Plan Project Management Plan Project Office (Project/ Quality Assurance) Engaged Supplier(s) Identify and record all constraints Supply Rep Advice Conditions of of Approvals Obtain all dependencies Potential Product Delivery Team Resource Potential Potential Product Product Delivery Delivery Team Team Manager Potential Potential Individual Individual Product Delivery Resource Product Delivery Resource Historic Lessons Learned Logs 33

34 Identify Detailed Scope of Work The scope section of the PMP must at a minimum identify: The project product, the deliverable or output. Performance targets, using SMART goals. Details of project constraints. Details of any assumptions made as part of developing the scope. A full list of inclusions, in granular detail. A full list of exclusions: Note which of these may be added at additional cost, if any. Details of the handover criteria. The remanding project details will be outlined in detail in the relevant sections of the PMP, i.e. time and cost. 34

35 Project Product Defining the project product is an important aspect for identifying and detailing the specific requirements (form and function) of that product. This will include the description of the products physical appearance, characteristics, features, and/or functions. This action will often require extensive input from the end user, Supplier Representative and/or Product Delivery Resources. Defining the project product should focus on how the product will best deliver, post project, the intended benefits of the project. 35

36 Performance Targets Performance targets should be noted using SMART goals: Specific Measurable Attainable. Realistic. Time bound. Performance targets are also known as critical success factors (CSF). The CSF should look beyond the iron triangle: of time, cost and project output (quality of scope). CSF provides additional insight for the management of the project and must be determined by the Client Organisation. 36

37 Constraints To manage successfully it is essential to know the environment in which you are managing. Identify all the constraints: Internal External Client imposed Identify the potential impacts of these constraints. Provide an example. 37

38 Assumptions Although you need to know the environment in which you are managing, you can t know what you don t know. Identify all things that had to be assumed in order to prepare the scope of work. Be specific you may need to rely on it later. Provide an example. 38

39 Inclusions REMEMBER Note it in Granular Detail! To manage the project successfully it is essential to know the what you are managing. Client s often assume that just because it is not listed in the inclusions does not mean its excluded; if they seen it, its included. Be specific to, colour, type, model and standard. This will also assist in the prevention of scope creep. Please Note, add annotation: If it is not listed in the inclusions list it is automatically excluded. 39

40 Exclusions To manage successfully it is also essential to know what you are not managing. Client s may assume that if it is not listed in the exclusions list then it must be included. Be very specific, but enable the Client to request this work if the Project Organisation has the capacity to deliver it. It is not acceptable to apply the old adage of buyer beware. Please Note, add annotation: If it is not included in the exclusions list it is automatically excluded. 40

41 Handover Criteria List the details of the physical items that will be handed over to the Client Organisation upon acceptance of the project product. This may include: As constructed plans / drawings / designs. Keys and remote controls. Warranty cards, terms and conditions. Equipment operating and maintenance manuals. Responsibility for the product. Responsibility for post project benefits realisation. Relevant information that may be of assistance to the asset or operational management team. 41

42 Generate Work Breakdown Structure (WBS) The Work Breakdown Structure (WBS) is: A graphical portrayal of the necessary work actions (activities, tasks and work packages) to deliver the project product. Is a hierarchical structure of the actions. Identifies the relationships with other actions (not time based). May be grouped under key stages (more manageable). Decomposition should be based on project resources maturity levels. These different levels of detail assists in determining estimate accuracy. Simply, and at a minimum, it must: Capture all main actions (activities, tasks and work packages). Note the natural progression of the work to be undertaken. 42

43 WBS Development Guidelines Is action oriented therefore project activities, tasks and work packages are listed. The WBS utilises the PBS nouns (descriptions) to identify verbs (actions). Include sufficient and necessary detail of activities, tasks and work packages; listed under the deliverables (components). Arranged in hierarchical structure which must contains at least two levels of decomposition: Components; and The activities, tasks and work packages required to deliver the component. Not based on timing. Not structured strictly by process or organization Beneficial if arranged in chronological / sequenced structure: Aids the identification of: Bottom up estimates of the detailed schedule and budget. The make / buy analysis (internal and/ or external development). 43

44 Example PBS Conference WBS Office of Government Commerce. (2009). Managing successful projects with PRINCE2. London: The Stationery Office, p

45 Hierarchical Representation 1. Venue 1.1 Venue requirements 1.2 Candidate venues 1.3 Venue assessment 1.4 Selected and booked venue 2. Attendees 2.1 Mail list (external) 2.2 Responses (external) 2.3 Booking arrangements 2.4 Final attendee list 3. Speakers 3.1 Speaker options 3.2 Speaker invitations 3.3 Booked speakers 4. Publicity 4.1 Mail shot 4.2 Press release 5. Delegate handouts 5.1 Covers 5.2 Printed agenda 5.3 Slides and notes 5.4 Satisfaction survey form 6. Conference logistics 6.1 Selected subject matter (external) 6.2 Agreed date(external) 6.3 Agreed programme 6.4 On the day staff 7. Previous conference lessons and materials (external) Office of Government Commerce. (2009). Managing successful projects with PRINCE2. London: The Stationery Office, p

46 WBS Creation Method Advantages Challenges Top Down Bottom Up Structures project conveniently for status reporting Helps ensure projects are logically structured Is valuable when brainstorming/discovering project deliverables Can accommodate additional deliverables as they are uncovered Starts with all deliverables and works backwards into a project Confirms that all work packages are included WBS Standards Formats are predefined Enhances cross project WBS consistency WBS Templates Provides a starting point for WBS creation May help determine appropriate level of detail required Enhances cross project WBS consistency Requires constant attention that no work packages are overlooked WBS needs to be elaborated to sufficiently detailed level to permit management oversight and control Identifying all deliverables before producing the WBS Making sure work packages are logically grouped Can lose focus on big picture Making a project fit the standard Can lead to inclusion of unnecessary deliverables or failure to include project specific deliverables Not all projects fit into a highly structured set of WBS standards Requires a project fit the standard Can lead to inclusion of unnecessary deliverables or failure to include project specific deliverables Not all projects fit into a highly structured set of WBS templates Project Management Institute. (2006). Practice standard for work breakdown structures (2nd ed.). Newtown Square, Pennsylvania: PMI, p.29 46

47 WBS Data Dictionary Sample Data Dictionary Template Project Management Theory and Practice By Gary L. Richardson, Copyright Taylor and Francis Group, LLC 2010, Publisher: CRC Press Project Duration Cost $ WBS Task No. Person Responsible Task Work Description (What work is authorized) Task Deliverable Acceptance Criteria Deliverables Total Due Date Preceding Activity Team Member Assigned Succeeding Activity Resource Assigned Purchasing Approved by Project Manager Date Team Member Assigned 47

48 A General Approach Development Models Waterfall Spiral Vee Development Method 1 Lump Modular Development Method 2 Linear Spiral Linear Spiral Delivery Method Single Single Multiple Single Multiple Single Multiple Forsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing Project Management (3rd ed.). Hoboken, New Jersey: John Wiley & Sons, p

49 Verify Scope of Work Verification and validation have very different meanings: Verification refers to the Project Organisation s responsibility to confirm the project product complies with the Client Organisation s requirements. Validation refers to confirmation the project product meets the needs of the end user (whom forms part of the Client Organisation). Verification of the scope of work seeks to proactively ensure the scope of work is, and will be, an effective definition of the project product and all project work. It should be verified by all relevant stakeholders prior to the submission of the PMP for approval. Scope verification is simply concerned with two questions: Is every component in the scope statement included in the WBS? Is every component in the WBS included in the scope statement? 49

50 Consequence of a Poor WBS Incomplete project definition leading to ongoing project extensions Unclear work assignments, goals, objectives, or deliverables Scope creep or unmanageable, frequently changing scope Budget overrun Missed deadlines on scheduled deliverables, or timeline slippage Unusable new product or feature Failure to deliver on some elements of project scope. Project Management Institute. (2006). Practice standard for work breakdown structures (2nd ed.). Newtown Square, Pennsylvania: PMI, p.13 50

51 Role of Organisational Breakdown Structure 51

52 Do Not! Mislead the Client Organisation by hiding details in extensive document (PMP) and tell them to read it and approve it if they are happy: Caveat emptor. Tell a good news story simply to get the project approved. Miss anything important. Be unethical! Don t Just Don t 52

53 Execution Phase Scope Processes Establish a Scope Statement Identify Project Requirements Initiation Generate Product Breakdown Structure (PBS) Identify Detailed Scope of Work Generate Work Breakdown Structure (WBS) Planning Verify Scope of Work Implement Scope Management Plan Monitor Scope of Work Control Scope of Work Execution Validate Scope of Work Finalise Responsibility Transfer Review Scope Functional Processes Finalisation 53

54 Scope Execution Actions Project Close Mothball / Terminate Decision Gate Continue (Start) Approved (Start) Approved PMP PMP Control Action Plan Proceed to to Finalisation Phase Assurance Report Contracted Contracted Product Product Delivery Delivery Resource(s) Resource(s) Project Manager Implements PMP through Allocation of Work Plans Work Plans Product Delivery Product Delivery Team Team Manager Product Delivery Product Delivery Team Team Resource Individual Product Individual Product Delivery Delivery Resource Resource Control Scope of Work X Iterations to Complete Non Conformance WBS Monitor Scope of of Work Undertake Required Work Actions According to Work Plan Project Reports Scope Performance Product Delivery Resource Advises Work Completed Conformance Project Office Project Office (Project/ (Project/ Quality Assurance) Quality Assurance) 54

55 Scope Baseline Remember the scope management plan is an ancillary plan of the project management plan. Once the scope is approved it becomes: The baseline of the scope of work. A benchmark to measure actual performance against, throughout delivery of the project. Most importantly it will become the litmus test of the project management team s, lead by the project manager, ability to effectively manage the project. 55

56 Implementation Implementing scope actions is generally undertaken in collaboration with the other functional areas of project management. It is simply the process of enacting scope actions in strict accordance with the information contained within the PMP. The scope management plan is one of the ancillary plan that collaboratively forms the PMP. The work breakdown structure (WBS) will ensure scope actions are undertaken in chronological and/ or coordinated fashion. Implementing the scope actions will require the Product Delivery Resources to be notified of when they are required to commence work and the arrangement of all necessary resources, to complete said work. 56

57 Monitoring Routinely monitor the progress of the project delivery process and the product being produced. Monitoring the project s delivery processes will inform the Project Management Team of actions that may need to be taken to keep scope actions on track and aligned with the planned actions within the PMP. Monitoring the product delivery progress will inform the Project Management Team of actions that may need to be taken to keep the product within scope, in accordance with agreed parameters. Delivering unapproved work, outside of the scope, is referred to as scope creep. This includes requested or unrequested work. 57

58 Scope Performance Outstanding (over performance) > 100% Satisfaction (agreed performance) = 100% Dissatisfaction (under performance) < 100% 58

59 Scope Creep Scope creep is the movement away from the approved scope baseline: Under delivery scope creep that benefits the Project Organisation. Over delivery scope creep that benefits the Client Organisation. Controlling the scope is the process of monitoring the status of the project and/or product and managing any changes to the approved scope baseline. It is controlled via a rigorous integrated change control process, that requires authorisation for any amendments to the baseline scope. 59

60 Causes Scope Creep Misinterpretation of the project brief. Incorrect choice of product development and / or delivery method. Poorly defined project scope. Incomplete recording of the project scope. Too much influence from in direct stakeholders who will not utilise the end product. Lack of monitoring and controlling of project work. 60

61 Controlling Taking control action is done in order to address any nonconformance that has been identified as part of the monitoring process. Non conformance is recognised as any variance to the scope of work that is outside of agreed tolerance levels. Control actions are those actions planned, approved if necessary, and implemented to bring the project and/ or project product back on track as outline within the scope management plan, and any approved amendments. Control actions that require an amendment of the scope management plan must be requested via the integrated change control process. 61

62 Change / Variation Control There are two elements to Integrated Change Control: 1. Change request. 2. Variation request. Change request is the process where the client or external stakeholder may seek a change to the project scope: Project organisation approval is required, then client approval. Variation request is the process where the project organisation or resource may request a variation to the project scope: Client approval is required. Discussed in detail as part of Integration Management. 62

63 Validate Scope of Work Aims to confirm the project product conforms to the requirements, standards and specifications of the product requested (form and function). It should also aim to confirm the product is fit for purpose by the end user (whom forms part of the Client Organisation). This process should work collaboratively with other project management processes such as quality control, assurance and procurement. It assists in formalising the acceptance of the completed product by the Client Organisation. 63

64 Finalisation Phase Scope Processes Establish a Scope Statement Identify Project Requirements Initiation Generate Product Breakdown Structure (PBS) Identify Detailed Scope of Work Generate Work Breakdown Structure (WBS) Planning Verify Scope of Work Implement Scope Management Plan Monitor Scope of Work Control Scope of Work Execution Validate Scope of Work Finalise Responsibility Transfer Review Scope Functional Processes Finalisation 64

65 Scope Finalisation Actions Client Organisation Receives PPBRP Not Approved Decision Gate Approved Execute PPBRP Not Approved Decision Gate Approved (Start) (Start) Client Acceptance Agreement Acceptance Agreement Project Manager Prepares Post Project Benefit Realisation Plan (PPBRP) Project Manager Conducts Post Project Review Post Project Post Project Report Post Project Assurance Report Post Project Benefits Post Project Realisation Benefits Realisation Plan Plan Post Project Post Project Scope Scope Functional Functional Review Review Project Close Archive Project Documents Project Office (Project/ Quality Assurance) Product Delivery Team Manager Contracted Product Delivery Resource(s) Product Delivery Team Resource Product Development Documents Individual Product Delivery Resource 65

66 Finalise Responsibility Transfer Once the Client Organisation has accepted the project product, and final payment has been received and processed, the Project Management Team must formally handover the business operational and maintenance responsibility to them. This includes the responsibility for achieving the post project benefits, identified prior to the commencement of the project. If it is a physical asset the asset has been transferred though the relevant product documentation has not. If this is a non physical item, discussions with the Client organisation may assist in determining the information that may prove beneficial to maximising the benefits of the project. 66

67 Review Scope Functional Processes Reviewing the processes involved in scope management must, as a minimum, investigate the following: At handover, was the project product fit for purpose? Did it address the business criteria? Did it address the technical criteria? Did it address the functionality criteria? Were all the pre delivery project benefits achieved? Where all of the project amendments approved via the integrated change control process? Could any of the amendments be avoided through better planning of the scope of work, including identification of the product requirements? Was the Client Organisation satisfied with the product of the project? 67

68 Reviewing the Project Was the scoping process formalised? Were all plans (scope and ensuing amendments) approved? Did the project management team: Provide up to date information on progress of the project? Provide sound advice to aid decision making processes? Ensure all amendment (change / variation) requests and approvals document appropriately? Make unnecessary requests for approval? Keep records? 68

69 In Summary Defined what is meant by the term scope, meaning scope of a project. Clarified the purpose of scope to a project. Discussed how scope management is critical to the successful delivery of the project. Identified how the scope, or scope of work is identified, defined, approved and managed throughout the lifecycle of a project. 69

70 Copyright Intellectual Property: The material contained within this lecture slide comply with the guidelines for educational use and is copyright 2015 by: PMF Management Solutions. All rights reserved: Should any person, organisation or entity require the written permission to use this material please contact PMF Management Solutions via: pmfmanagementsolutions.com or 70