Project Management Scope Management e WBS

Size: px
Start display at page:

Download "Project Management Scope Management e WBS"

Transcription

1 Agenda Project Management Scope Management e WBS Eng. Giorgio Locatelli Introduction Scope management WBS 2 Project management definition Project management definition Turner A project is an endeavor in which human, (or machine), material and financial resources are organized in a novel way, to undertake unique scope of work, of given specification, within constraints of cost and time, so as to deliver beneficial change defined by quantitative and qualitative objectives SCOPE Burke The project manager is the single point of responsibility, it is the project manager job to set up a structure which meets the needs of the project, the needs of the organization, the needs of the stakeholders and the needs of the individuals working on the project. TIME Project COST If anyone of the three factors changes at least one other factor is likely to be affected 3 4 Project management body of knowledge Project Management Instruments 5 6

2 Corporate Investment Life Cycle Strategic Planning Project Life Cycle Feasibility Contract Realization Exercise Close Out Project Life Cycle LEVEL OF INFLUENCE VS COST OF CHANGES (front-end importance) Cost of making any changes due to design errors or the client changing the scope, were recognized as becoming increasingly more expensive as the project progressed Plant Life Cycle Project Exercise Dismantling Project Life Cycle Concept Design Implementation Commission 7 8 Project Life Cycle Project management body of knowledge LEVEL OF DETAIL The PM philosophy of sub-dividing the scope of work into a number of smaller units to increase the level of detail and control can also be applied to the project life cycle. Scope Management As the RFP requested it As the work statement specified it As it was negotiated 9 As engineering designed it As it was built Swings, a classic revisited What the customer wanted 10 Scope management Scope Creep and Gold Plating Scope management is defined as; the process required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. It is primarily concerned with defining and controlling what is or is not included in the project. Since most projects seem to be riddled with fuzzy definitions, scope management takes on a greater importance to avoid scope creep, and avoid adding features and functionality to the product that are not part of the original project contract without an appropriate increase in time and budget Scope Management is centered around: Defining the Scope Controlling Changes to the defined requirements of the project Scope Creep Efforting work not under contract or identified within the WBS Typically initiated by the client Impacts cost and schedule performance, and profitability (depending on the contract type) Combat by creating a Change Order and rebaseline (EVMS) Gold-plating IT/Systems version of Scope Creep characterized by the inclusion of additional function points within a specific release Typically initiated by the contractor Impacts cost performance, and profitability (depending on the contract type) Combat by requirements matrices auditing and compliance Managing Scope Creep 11 12

3 What impacts on the Scope Requirements the ultimate objectives of the project Constraints limitations such as: time, resource dependency, business, legal, organizational, technology, offsets and management Assumptions facts for planning purposes (e.g. a new system will not require to develop new software) Risks any business or technical factor that has reasonable potential to impact the project Project Charter It is a tool that formally authorizes a project, also called terms of reference or project mission It is especially important when project managers have no direct authority over project team members and other resources, but bear the responsibility for delivery of the project Project Charter Project Charter It should be a tightly worded document outlining what is to be done and the boundaries of the project It should also include: Background to the project Key assumptions Business commercial needs Scope of work Identify key activities, budgets and dates Comment on how the project is to be managed Role of the project manager Reporting structure Scope Statement It is a written narrative of the goals, work and products of the project What do we produce in this project? The answer thus creates a big-picture view of what the project is all about What is within these boundaries is the solution space within which the project team can operate There are many version of the scope statement Main phases Scope Planning creating a project scope management plan that documents how the project scope will be defined, verified, controlled, and how the work breakdown structure (WBS) will be created and defined. Scope Definition developing a detailed project scope statement as the basis for future project decisions. Create WBS subdividing the major project deliverables and project work into smaller, more manageable components. Scope Verification formalizing acceptance of the completed project deliverables. Scope Control controlling changes to the project scope

4 Project Scope Management Overview Scope Change Control Even if you defined the scope properly and the customer validated it. this does not mean that there will not be Change! Scope Change Control Change Control is a huge responsibility of a Project Manager. PMs must control changes to the project s Schedule, Scope, and the impact on its Resources Scope Creep is the tendency for the requirements of a project to grow past the initial Scope Statement Scope Creep is one of the reasons why a PM must: spend the necessary time in the definition of the project s scope verify the scope with the stakeholders Define with the customer a Scope Baseline through Scope Statement signoff Systemic impact of cost change Two important notes: You cannot have a change in Scope without some kind of impact on Cost and Time. It is much easier to implement a change earlier in the Project Life Cycle than it is in the later stages SYSTEMIC THOUGHT IS THE KEY! The cost of scope change Change Request Using a numbered change request form is the preferred method of motivating a scope change. The form should describe the scope change, list associated drawings and documented, together with the reason for the change. NUMBER: CHANGE REQUEST DATE RAISED: INITAITED BY: CHANGE REQUIRED (related drawings/work packages) REASON FOR CHANGE: APPROVAL: NAME POSITION APPROVAL DATE 23 24

5 Project Communication Then project communication form enable any stakeholders working on the project, to make a formal statement. This could be a question, identifying a problem or making a suggestion. Once the document has entered the system the configuration management system will ensure that is acknowledged and auctioned Different typologies of Scope Change Priority: CRITICAL project cannot proceed because the change is critical for project success IMPORTANT significant negative impacts or major opportunities missed if the change is not made DESIRABLE benefits outweigh costs, but project can succeed without the change POST-LIVE - the change should be evaluated for inclusion on the project evolution plan Work Breakdown Structure The purpose of the WBS is to sub divide the scope of work into manageable work packages which can be estimated, planned and assigned to a responsible or department. It is the best tool for quantifying the scope of work as a list of work packages since is a hierarchical form of mind map which helps to break complexity down to simple manageable components. Work Breakdown Structure It is not the activities needed to create the project deliverables; it's the stuff that the activities create. A WBS is not the work, but the deliverables. Microsoft Project suggests WBS as the activity list, but it isn't so. A WBS is not the activities but the actual deliverables that the customer expects from the project work. The project scope must be decomposed into things that the customer will get as a result of the project. Stuff, not activities. The end result of the WBS is a clear picture of what the customer will and won't get as part of the project Work Breakdown Structure Work Breakdown Structure A Work Breakdown Structure is a deliverable-oriented grouping of project elements that organizes and defines the total scope of the project: work not in the WBS is outside the scope of the project. As with the scope statement, the WBS is often used to develop or confirm a common understanding of project scope. Each descending level represents an increasingly detailed description of the project elements

6 Work Decomposition Work Decomposition Decomposition may not be possible for a deliverable that must be accomplished far into the future. The Project team usually waits until the deliverable is clarified to best develop the WBS. Different deliverables can have different level of detail: excessive decomposition can lead to non productive management effort and inefficient use of resources not exhaustive level of detail reduces the possibility of best managing and control. For practical purposes 3 or 4 level of detail should be sufficient to reach the desired planning and control approach. The number of levels can be influenced by: Level of detail Level of risk Level of control Estimate accuracy Work package value Work package dimension (cost, manhours, duration) Except for E&C companies with more than 4 levels, subproject are used, where the lowest level of WP of a project constitutes the highest level of another one Work Decomposition WBS example So how far should you break down the project deliverables? You can follow the "8/80 Rule" the work package equates to no more than 80 hours of work and no fewer than 8 hours of work to create that deliverable. You don't want to get so granular or so vague with your WBS that it's uncontrollable and useless WBS example WBS development methods TOP-DOWN APPROACH BOTTOM-UP APPROACH WBS (ORGANIZATIONAL) STANDARDS WBS TEMPLATES What development method to use? 35 36

7 WBS development methods WBS development methods TOP-DOWN APPROACH If the project manager and the project management team have little to no experience in developing WBSs If the nature of the project s products or services is note well understood If the nature of the project life cycle is not familiar or well known If no appropriate WBS templates are available. 37 BOTTOM-UP APPROACH If the nature of the project s products and services is well understood [For example, if the organization has developed very similar products or services on previous projects] If the nature of the project life-cycle is well known. [If the organization use always the same project life-cycle] Appropriate WBS templates are available. [If the organization has WBSs from projects with similar products or services and these can be reused] 38 WBS development methods WBS STANDARDS AND TEMPLATES In general, if WBS standards or WBS templates are available, they can be used, but the choice to use a sample WBS as template must be made carefully. If there aren t similarity between the new project and projects already performed, the WBS must be developed with the top-down approach. 39 Work Package (WP) It is the elementary unit of the project planning and control It constitutes of more elementary activities interrelated, with objectives and constraints univocally defined It is defined in relation with Product Breakdown Structure (PBS), Activity Breakdown Structure (ABS), and Organizational Breakdown Structure (OBS) For every WP, start/finish and available resource are defined Time, cost and quality objectives are measurable to control them A Description is associated to every WP (objectives, responsibility, authorized budget, start/finish, milestones, interactions, revisions of all these entries) 40 Work Package (WP) Crossing a WBS element and an OBS one, a WP it is obtained as elementary unit of project management RULE 1 (100% RULE) WBS development rules The sum of the work at the child level must equal 100% of the work represented by the parent and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work RULE 2 Every breakdown level must be developed adoptin a single rationale RULE 3 Different level of the WBS can be developed according to differente rationale 41 42

8 RULE 4 WBS development rules Every WBS level and every part of it must be coded to allow WP research/aggregation useful to planning and control RULE 5 To choose WP dimension it is necessary consider that at the diminishing of these dimensions, it increase: managerial capacities of the single responsible WP number with control complications RULE 6 WBS is the base to highlight interfaces among WPs, so the necessity of interactions among the correspondent organizational units that are the responsible of them 43 RULE 7 WBS development rules WBS may be developed according to specific needs of the project considered (WBS ad hoc) or according to a standardized reference scheme RULE 8 It is possible to aggregate elements of WBS according to different ways respect to those of the WBS hierarchical structure. For example: activities that determine jointly incomes and cash flow; materials that belongs to different part of the WBS but are transported on the same date through the same transport means; project aspects that involve different sub-systems of the plant. 44 Other Breakdown Structure Other Breakdown Structure Cost Breakdown Structure (CBS), which represents the financial breakdown of the project into budgets per work packages. Location Breakdown Structure (LBS), which is used to show the location of the work and would be appropriate for a project which as pockets of work dotted all over the place. Transport Breakdown Structure (TBS), which is used in projects characterised by large loads that may find transport and cranage limitations critical for the breakdown. Resource breakdown structure (RBS), which is a variation of the OBS and is typically used when work elements are assigned to individuals. Bill of materials (BOM), which presents a hierarchical view of the physical assemblies, subassemblies, and components needed to fabricate a manufactured product. Also called Product Breakdown Structure. Project breakdown structure (PBS), which is fundamentally the same as a properly done WBS. The term PBS is widely used in application areas where the term WBS is incorrectly used to refer to a BOM Other Breakdown Structure Other Breakdown Structure 47 48

9 WBS example WBS example WBS advantages 1. To identify the Project independently on who participates it 2. To clearly identify project objectives 3. To provide a scheme that guarantee objectives achievement through inferior objective most controllable 4. To obtain a different levels visibility 5. To univocally identify reference sectors of the documents relative to monitoring, controlling and reporting activities of the project 6. To highlight interactions rationale among project elements 7. To identify WP to assign responsibilities and resources 8. To identify innovative and repetitive components 51