5 - Project Scope Management - 5 *Unit 5 - 5

Agenda Project Scope Management .Collect Requirements .Define Scope .Create Work Breakdown Structure .Verify Scope .Control Scope .

. . . . . .*

5- Scope Management5 - Project Scope Management :Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. : .*

5- Project Scope Management5 - 5.1 Collect Requirements:The process of defining and documenting stakeholders needs to meet the project objectives.5.2 Define Scope:The process of developing a detailed description of the project and product.5.3 Create WBS:The process of subdividing project deliverables and project work into smaller, more manageable components.5.4 Verify Scope:The process of formalizing acceptance of the completed project deliverables.5.5 Control Scope:The process of monitoring the status of the project and product scope and managing changes to the scope baseline. 1-5 : .2-5 : .3-5 : .4-5 : .5-5 : .*

Scope Describes Product & Project - Project Scope Product Scope :The features & functions of what to be produced ( The product to be delivered ).Completion is measured against the requirements.Project Scope :The work required to deliver the product ( The project process ).Completion is measured against the plan. : ( ) . . : ( ). . *

Why Scope Management ? Influenced Area : Schedule, Cost, quality, Risks. : , , .*Amount of EffortRequired Potential Savings Cost To Change Life Cycle PlanDesignDevelopment/ Construction/ OperationDemolition

Planning is Fortune Telling Planning is reading the future.It is just guessing what is will happen in the future.It is up to the project manager and project team to turn this guess into reality.The team should not affect the future, but should minimize the chances of going wrong.The project manager sometimes acts as the Fortune Teller. . . . . . : *

5.1 Collect Requirements ( Planning ) 1-5 ( )Collect requirements is the process of defining and documenting stakeholders needs to meet the project objectives. They become the foundation of the WBS. . .*

*Source: PMBOK Guide Fourth Edition, page 1055.1 Collect Requirements5-1

Collect Requirements Project Charter: The project charter is used to provide the high-level project requirements and high-level product description of the project so that detailed product requirements can be developed.Stakeholder Register: The stakeholder register is used to identify stakeholders that can provide information on detailed project and product requirements. : . : .*

5.1 Collect Requirements1.5 Interviews Focus groups Facilitated workshops Group creativity techniquesGroup decision making techniquesQuestionnaires and surveys Observations Prototypes . . . . . . . .*

Interviews A formal or informal approach to discover information from stakeholders by talking to them directly.It is typically performed by asking prepared and spontaneous questions and recording the responses.Interviews are often conducted one-on-one, but may involve multiple interviewers and/or multiple interviewees.Interviewing experienced project participants, stakeholders and subject matter experts can aid in identifying and defining the features and functions of the desired project deliverables. . . / . .*

Focus Groups Bring together pre-qualified stakeholders and subject matter experts to learn about their expectations about a proposed product.A trained moderator guides the group through an interactive discussion, designed to be more conversational than an one-on-one interview.

. .*

Facilitated Workshops Requirements workshops are focused sessions that bring key cross-functional stakeholders together to define product requirements.Workshops are considered a primary techniques for quickly defining cross-functional requirements and reconciling stakeholder differences. Issues can be discovered and resolved more quickly than in individual sessions. . . .*

Group Creativity Techniques Brainstorming. A technique used to generate and collect multiple ideas related to project and product requirements. Nominal group technique. This technique enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization. The Delphi Technique. A selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity. Idea/mind mapping. Ideas created through individual brainstorming are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas.Affinity diagram. This technique allows large numbers of ideas to be sorted into groups for review and analysis. . . . . . . . . . . .*

Group Decision Making Techniques Unanimity. Everyone agrees on a single course of action.Majority. Support from more than 50% of the members of the group.Plurality. The largest block in a group decides even if a majority is not achieved.Dictatorship. One individual makes the decision for the group.. .. 50 % .. . . .*

The Delphi Technique It is an anonymous way to reach a consensus of experts on a subject.It involves the following: Questionnaire to solicit ideas from the experts .Responses are submitted anonymously, compiled, and then circulated to the experts for review .A consensus may be reached in a few rounds.

, . : . ( ) ( ) . ( ) .*

Questionnaires and Surveys Questionnaires and surveys :are written sets of questions designed to quickly accumulate information from a wide number of respondents. Questionnaires and/or Surveys are most appropriate with broad audiences, when quick turnaround is needed, and where statistical analysis is appropriate. : . / .*

Observations Observations Provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements. : . .*

Prototypes Prototyping :is a method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it. Since prototypes are tangible, it allows stakeholders to experiment with a model of their final product rather than only discussing abstract representations of their requirements. : . .*

Balance Stakeholder Requirements Requirements documentation .Balance Stakeholder Requirements .Resolve competing Requirements By :Business case .Project charter .Project scope statement.Project constraints .Customer satisfaction . . . : . . . . . *

5.1 Collect Requirements1.5 Requirements documentation Requirements management planRequirements traceability matrix . . .*

Requirements Documentation Requirements Documentation describes how individual requirements meet the business need for the project.Requirements may start out at a high level and become progressively more detailed as more is known. Before being base lined, requirements must be unambiguous, traceable, complete, consistent, and acceptable to key stakeholders. . (/ ) . ( ) .*

Requirements Management Plan It documents how requirements will be analyzed, documented and managed throughout the project. It contains the following components:How requirements activities will be planned, tracked and reported.Configuration management activities such as how changes to the product, service or result requirements will be initiated, how impacts will be analyzedRequirements prioritization process.Product metrics that will be used and the rationale for using them.

. : . . . .*

Requirements Traceability Matrix The matrix is a table that links requirements to their original business objectives. This process includes:Requirements to business needs, opportunities, goals, and objectives.Requirements to project objectives.Requirements to project scope/WBS deliverables.Requirements to product design.Requirements to product development.Requirements to test strategy and test scenarios.High-level requirements to more detailed requirements.

. : . . / . . . . .*

5.2 Define Scope ( Planning ) 2.5 ( ) Define Scope is the process of developing a detailed description of the project and product. .*

*Source: PMBOK Guide Fourth Edition, page 1125.2 Define Scope2.5

5.2 Define Scope2.5 Project charterRequirements documentationOrganizational process assets:a. Policies, procedures, and templates for a project scope statements.b. Project files from previous projects.c. Lessons learned from previous phases or projects. . . . . . .

*

5.2 Define Scope2.5 Expert judgment Product analysisAlternatives identification Facilitated workshops . . . .*

Product Analysis Each application area has one or more generally accepted methods for translating high-level product descriptions into tangible deliverables.Product analysis includes techniques such as:Product breakdown. Systems analysis. Requirements analysis. System engineering. Value engineering. Value analysis.

. .*

Alternatives Identification Identifying alternatives is a technique used to generate different approaches to execute and perform the work of the project.A variety of general management techniques can be used such as brainstorming lateral thinking, pair wise comparisons, etc. . .*

5.2 Define Scope2.5 Project scope statement Project document updates . .*

Project Scope Statement The statement describes, in detail, the projects deliverables and the work required to create those deliverables.It also provides a common understanding of the project scope among project stakeholders.It may contain explicit scope exclusions that can assist in managing stakeholder expectations.It enables the project team to:Perform more detailed planning.Guides the project teams work during execution.Provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the projects boundaries. . . . : .*

Scope Statement Content Product scope description. progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation.Product acceptance criteria. Defines the process and criteria for accepting completed products, services, or results.Project deliverables. Deliverables include both the outputs that comprise the product or service of the project, as well as ancillary results, such as project management reports and documentation. The deliverables may be described at a summary level or in great detail.Project exclusions. Generally identifies what is excluded as from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders expectations. . . . . . . . . . .*

Scope Statement Content Project constraints. Lists and describes the specific project constraints associated with the project scope that limits the teams options, for example, a predefined budget or any imposed dates or schedule milestones that are issued by the customer or performing organization. When a project is performed under contract, contractual provisions will generally be constraints. Information on constraints may be listed in the project scope statement or in a separate log.Project assumptions. Lists and describes the specific project assumptions associated with the project scope and the potential impact of those assumptions if they prove to be false. Project teams frequently identify, document, and validate assumptions as part of their planning process. Information on assumptions may be listed in the project scope statement or in a separate log. . . . . . . . .

*

Scope Statement Content Project exclusionsProject constraintsProject assumptions

. . .*

Constraints and Assumptions Constraint is a known factor that limits the project teams options. Assumption is a factor that, for planning purposes, is considered to be true, real, or certain.

: . : , , , .*

Identifying Constraints ( ) Examples of constraints that may be faced during a project:BudgetSchedulePeopleFacilities and equipment : . . . .

*

Identifying Assumptions Assumptions are identified and documented during the planning process as they affect all aspects of planning. They need to be verified to ensure that they are true.If proven to be false, then re-planning is neededThey always carry a certain degree of risk , . . . .*

Unquantifiable Expectations Some expectations requirements may be difficult to quantify, like:Customer satisfactionCompany ImageCommunity PerceptionThey need to be quantified as much as possible. ( \ ) , : ( ) . . . .*

5.3 Create WBS ( Planning )3.5 ( )Create WBS is the process of subdividing project deliverables and project work into smaller, more manageable components.The work breakdown structure (WBS) is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. With each descending level of the WBS representing an increasingly detailed definition of the project work. . (WBS) . .*

5.3 Create WBS3.5 The WBS organizes and defines the total scope of the project and represents the work specified in the current approved project scope statement.The planned work is contained within the lowest level WBS components, which are called work packages.A work package can be scheduled, cost estimated, monitored and controlled.In the context of the WBS, work refers to work products or deliverables that are the result of effort and not to the effort itself. . ( ) . ( ) . .*

Work Breakdown Structure (WBS) Acts as a vehicle for breaking the project down into smaller elements.Provides greater probability that never major & minor activity will be accounted for.Multi level presentation of project objectives. Multi level communication tool among stakeholders.

. . . .*

*

WBS Example with Code of Accounts *ProgramProjectPhasesTasksWork Packages

*WBS Example with Code of Accounts ProgramProjectPhasesTasksWork Packages

WBS *

WBS *

Work Breakdown Structure (WBS) Bridge Project - StructureFoundationPilesSafety ItemsPilesFootingsBridge ConstrictionProcurementBridge ProjectGirdersSlab1-15 days~~~SignBoardGuard RailDriving RigPiles~~*

*Sample Work Breakdown Structure (Work Packages) ( ) 1 Hardware1.1 Servers 1.1.1 Head Office Server 1.1.2 Branch Server 1.2 Network 1.2.1 Switches 1.2.2 Routers 1.2.2.1 Head Office Router 1.2.2.2 Branch Router2 Software2.1 Application 2.1.1 Portfolio Management 2.1.2 Real Estate Management 2.1.3 Asset Management

3. Licenses3.1 Windows Server3.2 SharePoint Portal 3.3 Office 2003.

4 Training4.1 Windows Training4.1.1 Windows Server Admin4.1.2 Office Training4.2 Application Training4.2.1 DB Admin 4.2.2 Application Admin

Sample Work Breakdown Structure (Work Packages) ( ) * . 1. 1 .1.1.1 1.1.2 . 1.2 .1.2.1 .1.2.2 .1.2.2.1 .2.1 .2.1.1 .2.1.2 .2.1.3 .

( ) . 1. 3 .2. 3 .3. 3 2003 .

.4.1 .4.1.1 .4.1.2 .4.2 .4.2.1 .4.2.2 .

*WBS is the Basis for Many Other Project Components / . . . , , . , . . .

Work Packages The lowest level of the WBSWork unit at level where work is performed.Discrete WBS tasks with :A definable end result ( A specific objective ).Can be measured, for example, in manhours.Generally, the scope of biddable size.Assignable to a single organizational element ( Work Center ).Measurable Schedule & Cost :Duration is limited to relatively short time.Has scheduled start & end dates.Has budget .SP/$ ,Manhours, etc..Integrated with engineering & manufacturing schedules. . . ( ). / . , () . : : : . . / ...... .*

WBS Dictionary *

Control Account ID No :Work Package No :Date of UpdateResponsible Organization/IndividualWork Package Description Acceptance Criteria ( How to Know if the Work is Accepted )Deliverables for the WorkAssumptionsResources Assigned Duration Schedule MilestoneCostDue Date Interdependencies : Before This Work Package After This Work Package

Approved By : Project Manager :

WBS Dictionary *

: ) ) ( ) : : : : : : ( ) : : : ................................................. : .................................................

.

*5.3 Create WBS3.5 Source: PMBOK Guide Fourth Edition, page 115

5.3 Create WBS3.5 Project scope statement Requirements documentation Organizational process assets . . .*

DecompositionIt is the subdivision of project deliverables into smaller, more manageable components until the work and deliverables are defined to the work package level.Decomposition of the total project work into work packages generally involves the following activities:Identifying and analyzing the deliverables and related work.Structuring and organized the WBS.Decomposing the upper WBS levels into lower level detailed components.Developing and assigning identification codes to the WBS components.Verifying that the degree of decomposition of the work is necessary and sufficient. ( ) . : . . . .*

5.3 Create WBS3.5 Work Breakdown Structure (WBS)WBS dictionary Scope baseline Project document updates . . . .*

Work Breakdown Structure The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables.With each descending level of the WBS representing an increasingly detailed definition of the project work.The WBS is finalized by establishing control accounts for the work packages and a unique identifies from a code of accounts.A control account is a management control point where scope, cost, and schedule are integrated and compared to the earned value for performance measurement. (WBS) . . ( ) . . *

WBS Dictionary The WBS dictionary provides more detailed descriptions of the components in the WBS including work packages and control accounts. It may contain the following information:Code of account identifiesDescription of workResponsible organizationList of schedule milestonesAssociated schedule activitiesResources requiredCost estimatesQuality requirementsAcceptance criteriaTechnical referencesContract information . . : .*

Scope Baseline The scope baseline is a component of the project management plan. The components of the scope baseline includes:Project scope statementWBSWBS dictionary : . . . *

Other Breakdown Structures The WBS should not be confused with other kinds of breakdown structures, like:Organizational Breakdown Structure (OBS) Bill of Materials (BOM) Risk Breakdown Structure (RBS)Resource Breakdown Structure (RBS). : (OBS) . (BOM) . (RBS) . (RBS) .*

5.4 Verify Scope ( Controlling ) 4.5 ( )Verify Scope is the process of formalizing acceptance of the completed project deliverables. Verifying scope includes reviewing deliverables with the customer or sponsor to ensure that they are completed satisfactorily and obtaining formal acceptance of deliverables by the customer or sponsor. . .*

Scope Verification Vs. Quality Control Scope verification:Concerned with acceptance of work results(Tied to project objectives & WBS).Quality Control :Concerned with the correctness of the work results (Tied to product quality tests and standards). : ( ) . : ( ) .*

*5.4 Verify Scope4.5 Source: PMBOK Guide Fourth Edition, page 123

5.4 Verify Scope4.5 Project management plan Requirements documentation Requirements traceability matrix Validated deliverables . . . .*

Inspection ( ) Inspection includes activities such as: measuring, examining, and verifying to determine whether work and deliverables meet requirements and product acceptance criteria. Inspections are sometimes called reviews, product reviews, audits and walkthroughs. . .*

5.4 Verify Scope4.5 Accepted deliverables. Change requests. Project document updates. . . .*

5.5 Control Scope ( Controlling )5.5 ( ) Control Scope is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the Perform Integrated Change Control process. . .*

*Source: PMBOK Guide Fourth Edition, page 1255.5 Control Scope5.5

Scope Change Considerations Will the request to change project scope affect the project schedule?Will the request to change project scope affect the project cost?Will the request to change project scope affect the project quality?Is the total impact a significant change to the project overall?What is the impact of no change?What are all the alternative methods of accommodating the requested change?Does the individual requesting the scope change have the authority to approve resulting changes to project cost, schedule, quality, or other considerations? ( ) .*

5.5 Control Scope5.5 Project management plan Work performance information Requirements documentation Requirements traceability matrix Organizational process assets . . . . .*

Project Management Plan Scope baselineScope management planChange management planConfiguration management planRequirements management plan

. . . . .*

Variance Analysis ( )Project performance measurements are used to assess the magnitude of variation from the original scope baseline.Important aspects of project scope include determining the cause and degree of variance relative to the scope baseline and deciding whether corrective or preventive action is required.

. .*

5.5 Control Scope5.5 Work performance measurements Organizational process assets updatesChange requestsProject management plan updates Project document updates . . . .*

Scope Change Control System A scope change control system is used to define the procedures by which the project scope can be changed. It may include the paper work, tracking systems, and approval levels necessary for authorizing changes. . ( ), , ( ) .*

*Change Control Process ( )

Title

Start

Urgent?

Raise Change Control Form

Identify Change

Assess Priority

Assess Impact of no Change

Assess Impact on Cost (Resources)

Assess Impact on Schedule

Assess Impact on Quality

Propose Change to the Baseline

Accepted?

Negotiate Proposal

File the Change

End

Change the Baseline

Implement Change

Yes

No

Yes

No

*Change Control Process ( )

Title

()

5.5 Control Scope5.5 * - ()

Questions? *

****Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides**Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*******Project Management Slides*****Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides**Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides*Project Management Slides***