1

Chapter 4:Project Scope Management

adopted from PMI’s PMBOK 2000 and

Textbook : Information Technology Project Management

(author : Dr. Kathy Schwalbe)

2

Contents

• Importance of scope management• Project Scope Management Processes (Initiation, Scope

planning, Scope definition, Scope verification, Scope change control)– Initiation (init phase)

• key tools: selecting project based on financial methods (NPV, ROI and Payback analysis)

– Scope Planning (planning phase)– Scope definition (planning phase)– Scope verification (control phase)– Scope change control (control phase)– methods to improve

3

Screening a project

4

What is Project Scope Management?

• Scope refers to all the work involved in creating the products of the project and the processes used to create them

• Project scope management includes the processes involved in defining and controlling what is or is not included in the project

• The project team and stakeholders must have the same understanding of what products will be produces as a result of a project and what processes will be used in producing them

Chapter 4

5

Project Scope Management Processes

• Initiation: beginning a project or continuing to the next phase

• Scope planning: developing documents to provide the basis for future project decisions

• Scope definition: subdividing the major project deliverables into smaller, more manageable components

• Scope verification: formalizing acceptance of the project scope

• Scope change control: controlling changes to project scope

Chapter 4

6

Project Initiation: Strategic Planning and Project Selection

• 1st initiation phase process• Initiation is the process of formally authorizing a

project or that an existing project should continue on the next phase.– The first step in initiating projects is to look at the big

picture or strategic plan of an organization– Strategic planning involves determining long-term

business objectives– IT projects should support strategic and financial

business objectives

Chapter 4

7

Inputs to Project Initiation

• Product description– documents the characteristics of the products or service that the project was

undertaken to solve. It also documents the business need that created the project.

• Strategic plan– describes the origination’s mission, vision, and goals for the future. Everything

in projects management supports the strategic business plan of the origination.

• Project selection criteria– defined in terms of the product, this covers the full range of management

concerns. They are typically defined in terms of specific benefits of the project to the business.

• Historical information– results of previous decisions and performance. – For example: a) relevant lessons learned from past projects; b) the history with

a particular customer; c) the history with similar projects.

8

Identifying Potential Projects

• Many organizations follow a planning process for selecting IT projects

• First develop an IT strategic plan based on the organization’s overall strategic plan

• Then perform a business area analysis

• Then define potential projects

• Then select IT projects and assign resources

Chapter 4

9

Tools & techniques

• Project selection methods– they are techniques, practices or procedures for selecting a project

that best supports the organization’s objectives. – Project selection methods generally fall into two broad categories:

• a) benefit measurement methods – corporative approaches, scoring models, and benefit-contribution and entomic models;

• b) constrained optimization methods – mathematical models using linear, dynamic, integer, and multi-objective programming algorithms.

• Expert judgment– Subject experts with specialized knowledge or training assess the

inputs to this process. Results of this analysis are a documented opinion or recommendation.

10

Methods for Selecting IT Projects

• There are usually more projects than available time and resources to implement them

• It is important to follow a logical process for selecting IT projects to work on

• It is often difficult to provide strong justification for many IT projects, but everyone agrees they have a high value

• “It is better to measure gold roughly than to count pennies precisely”

• Three important criteria for projects:– There is a need for the project– There are funds available– There’s a strong will to make the project succeed

Chapter 4

11

Categorizing IT Projects

• One categorization is whether the project addresses– a problem

– an opportunity, or

– a directive

• Another categorization is how long it will take to do and when it is needed

• Another is the overall priority of the project

Chapter 4

12

Financial Analysis of Projects

• Financial considerations are often an important consideration in selecting projects

• Three primary methods for determining the projected financial value of projects:– Net present value (NPV) analysis– Return on investment (ROI)– Payback analysis

Chapter 4

13

Net Present Value Analysis

• Net present value (NPV) analysis – a method of calculating the expected net

monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time

• If financial value is a key criterion– projects with a positive NPV should be

considered – the higher the NPV, the better

Chapter 4

14

Figure 4-2. Net Present Value Example

Excel file

15

Return on Investment

• Return on investment (ROI) is income divided by investment– ROI = (total discounted benefits - total

discounted costs) / discounted costs

• The higher the ROI, the better• Many organizations have a required rate of

return or minimum acceptable rate of return on investment for projects

Chapter 4

16

Payback Analysis

• payback analysis– is another important financial consideration

– Payback occurs when the cumulative discounted benefits and costs are greater than zero

• Payback period is the amount of time it will take to recoup, in the form of net cash inflows, the net dollars invested in a project

• Many organizations want IT projects to have a fairly short payback period

Chapter 4

17

Figure 4-3. NPV, ROI, and Payback Analysis for Project 1

Excel fileChapter 4

18

Figure 4-4. NPV, ROI, and Payback Analysis for Project 2

Excel file Chapter 4

19

Weighted Scoring Model

• No single methods is the best for all, a holistic evaluation of previous methods can be combined!

• A weighted scoring model is a tool that provides a systematic process for selecting projects based on many criteria– First identify criteria important to the project selection process

– Then assign weights (percentages) to each criterion so they add up to 100%

– Then assign scores to each criterion for each project

– Multiply the scores by the weights and get the total weighted scores

• The higher the weighted score, the betterChapter 4

20

Figure 4-5. Sample Weighted Scoring Model for Project Selection

Excel file

21

Project Charters

• After deciding what project to work on, it is important to formalize projects

• A project charter – a document that formally recognizes the

existence of a project and provides direction on the project’s objectives and management

• Key project stakeholders should sign a project charter to acknowledge agreement on the need and intent of the project

Chapter 4

22

Sample Project Charter

Project Title: Information Technology (IT) Upgrade ProjectProject Start Date: March 4, 200 Projected Finish Date: December 4, 2002Project Manager: Kim Nguyen, 691-2784, knguyen@abc.comProject Objectives: Upgrade hardware and software for all employees

(approximately 2,000) within 9 months based on new corporate standards. See attached sheet describing the new standards. Upgrades may affect servers and midrange computers as well as network hardware and software. Budgeted $1,000,000 for hardware and software costs and $500,000 for labor costs.

Approach:       Update the IT inventory database to determine upgrade needs       Develop detailed cost estimate for project and report to CIO       Issue a request for quotes to obtain hardware and software       Use internal staff as much as possible to do the planning, analysis, and installation

23

Table 4-2. Sample Project Charter (continued)

Name Role Responsibility Walter Schmidt, CEO Project Sponsor Monitor project Mike Zwack CIO Monitor project, provide

staff Kim Nguyen Project Manager Plan and execute project Jeff Johnson Director of IT Operations Mentor Kim Nancy Reynolds VP, Human Resources Provide staff, issue memo

to all employees about project

Steve McCann Director of Purchasing Assist in purchasing hardware and software

Sign-off: (Signatures of all above stakeholders) Comments: (Handwritten comments from above stakeholders, if applicable) This project must be done within ten months at the absolute latest. Mike Zwack, CIO We are assuming that adequate staff will be available and committed to supporting this project. Some work must be done after hours to avoid work disruptions, and overtime will be provided. Jeff Johnson and Kim Nguyen, IT Information Technology Department

Roles and Responsibilities:

24

Scope Planning

• 2nd of 21 planning phase process• Score refers to the boundaries of the project. • two approaches in scope planning: Top-down

approach; Bottom-up approach. – In top-down approach, planning start with largest

items, or most-generalized description, of the project and break them down to the finest level of detail.

– In bottom-up approach, planning start with the detailed tasks and roll them up to higher levels of detail

Chapter 4

25

Input to Scope Planning

• Product description– Documents the characteristics of the project or service that the

project will create. It is less detailed in the early phases.

• Project Charter– The document that formally recognizes the existence of a project.

It is issued by a manager who is external to the project and at a level appropriate to the needs of the project.

• Constraints– factors that limit the project management team’s options

• Assumption– factors that, for planning purposes, will be considered to be true,

real, or certain.

26

Tools for Scope Planning

• Product analysis– involves developing a better understanding of the product of the project.

It includes techniques such as system engineering, value engineering, value analysis, function analysis, and quality function deployment.

• Benefit/cost analysis– estimating tangible and intangible costs and benefits or various

alternatives and using financial measures to assess the relative desirability of their alternatives.

• Alternative identification– any technique used to general different approaches to the project (e.g.

brainstorming or lateral thinking)

• Expert judgment– may be provided by subject experts with specialized knowledge or

training.

27

Output from Scope Planning

• Scope statement– provides a documented basis for making future project decisions and

for confirming or developing common understanding of project scope. The scope statement is an agreement made between the client and project manager.

– Major sections of the scope statement include: a) Project justification; b) Project product; c) Project deliverables; d) Project objectives.

• Supporting details– include all identified assumptions and constraints. The specifications

define the expected performance of a deliverable.

• Scope Management Plan– describe how the project scope will be managed and how scope

changes will be integrated into the project. It may be formal or informal.

28

Scope definition

• 3rd of 21 planning phase process• After completing scope planning, the next step is to further

define the work by breaking it into manageable pieces• Scope definition divides major project deliverables into

manageable components. It provides a baseline and assigns responsibilities. A scope baseline is the original plan, plus or minus approved changes.

• Good scope definition– helps improve the accuracy of time, cost, and resource estimates– defines a baseline for performance measurement and project control– aids in communicating clear work responsibilities

Chapter 4

29

Inputs to Scope definition

• Scope statement– The scope statement is an agreement made between the client and

project manager. It is an output from Scope Planning Process.

• Constraints– factors that limits other options

• Assumptions– factors that are considered to be true, real, or certain.

• Other planning output– Outputs from processes in other knowledge areas should be

reviewed for possible impact on project scope definition.

• Historic information– information from similar or previous projects.

30

Tools & techniques for Scope definition

• WBS template– use templates from previous project for a new

project.

• Decomposition– subdividing the major project deliverables into

smaller, more manageable components.

31

Outputs of Scope definition

• WBS– A fundamental project document that has a great

emphasis in project management methodology. It provides the basis for planning and management the project. It is a deliverable-oriented grouping of project elements that organizes and defines the total scope of the project. Work not contained in the WBS is outside the scope of the project.

• Scope statement update– refinements of the scope statement.

32

Figure 4-6a. Sample Intranet WBS Organized by Product

33

Figure 4-6b. Sample Intranet WBS Organized by Phase

34

Table 4-3. Intranet WBS in Tabular Form

1.0 Concept1.1 Evaluate current systems1.2 Define Requirements

1.2.1 Define user requirements1.2.2 Define content requirements1.2.3 Define system requirements1.2.4 Define server owner requirements

1.3 Define specific functionality1.4 Define risks and risk management approach1.5 Develop project plan1.6 Brief web development team

2.0 Web Site Design3.0 Web Site Development4.0 Roll Out5.0 Support

35

Figure 4-7. Intranet WBS and Gantt Chart in Project 2000

Project 98 file

36

Figure 4-8. Intranet WBS and Gantt Chart Organized by Project Management Process Groups

37

Approaches to Developing WBSs

• Using guidelines– Some organizations, like the DOD, provide guidelines

for preparing WBSs

• The analogy approach– It often helps to review WBSs of similar projects

• The top-down approach– Start with the largest items of the project and keep

breaking them down

• The bottoms-up approach– Start with the detailed tasks and roll them up

Chapter 4

38

Scope verification & Scope change control

• It is very difficult to create a good scope statement and WBS for a project

• It is even more difficult to verify project scope and minimize scope changes

• Many IT projects suffer from scope creep and poor scope verification

39

Scope Verification

• 2nd of 8 controlling phase process• Scope verification is the process of formalizing

acceptance of the project scope by key stakeholders, especially the customer and sponsor

• It requires reviewing work products and results to ensure that all product or service features and functions are complete, correct and satisfactory.

Chapter 4

40

Inputs to Scope Verification

• Work results– deliverables have been fully or partially

completed, as well as what costs have been incurred or committed. They are the outcome of activities performed and are fed into the performance reporting process.

• Product documentation– any paperwork describing the project’s

products must be available for review.

41

Tools & techniques for Scope Verification

• Inspection– activities such as measuring, examining, and

testing undertaken to determine if results conform to requirements.

– The purpose is to identify any particular on variances, omissions, deficiencies, gaps, and errors.

42

Outputs from Scope Verification

• Formal acceptance– documentation of approving the project of the

project, or phase, needs to be prepared. Often the client or sponsor needs to sign off on formal documents as a part of wrapping up the project.

43

Scope Change Control

• 3rd of 8 controlling phase process• Change control procedures enable project manager

to understand and manage change requests. • Project manager need to control the scope of both

the product and the project. – The big change requests are easy to spot because they

happen all at once. – When there are small multiple change requests, these

are known as scope creep and it can be a difficult to detect.

44

Inputs to Scope Change Control

• WBS– a scope definition tool that organizes the work and provides a basis for

project estimates.

• Performance reports– alert the project team. Status reports describe the project’s current

standing. Progress report describes the team’s accomplishment.

• Change requests– the result of external events such as government regulations, error or

omissions in scope definition, and value-added changes.

• Scope management plan– part of the Project Plan. It describes how the project scope will be

managed, how changes will be identified and classified, how changes will be integrated into the project, and what the required procedures are form making changes.

45

Tools & techniquesfor Scope Change Control

• Scope change control system– defines the procedures by which the scope of the

project may be changed. It includes the paperwork, tracking systems, and approval levels necessary for authorizing changes. (e.g. change request form)

• Performance measurement– techniques to assess the magnitude of any variations

that occur in the performance of the project.

• Additional planning– activities that may be necessary to the project plan or

subsidiary plan in order to adjust to changes.

46

47

Outputs from Scope Change Control

• Scope changes– any modifications to the authorized project scope as defined

by the approved WBS. It often requires adjustments to cost, time, quality, or other project objectives.

• Corrective action– anything that bring the performance back in line with the

project plan.

• Lessons learned– assessments that include the causes of variances, reasoning

behind corrective actions, and other types of lessons learned as a result of scope change.

48

Table 4-4. Factors Causing IT Project Problems*

Factor Rank Lack of user input 1 Incomplete requirements and specifications 2 Changing requirements and specifications 3 Lack of executive support 4 Technology incompetence 5 Lack of resources 6 Unrealistic expectations 7 Unclear objectives 8 Unrealistic time frames 9 New Technology 10

*Johnson, Jim, "CHAOS: The Dollar Drain of IT Project Failures," Application Development Trends, January 1995, www.stadishgroup.com/chaos.html

Chapter 4

49

Suggestions for Improving User Input

• Insist that all projects have a sponsor from the user organization

• Have users on the project team

• Have regular meetings

• Deliver something to project users and sponsor on a regular basis

• Co-locate users with the developers

50

Suggestions for Reducing Incomplete and Changing Requirements

• Develop and follow a requirements management process

• Employ techniques such as prototyping, use case modeling, and Joint Application Design to thoroughly understand user requirements

• Put all requirements in writing and current

• Create a requirements management database

• Provide adequate testing

• Use a process for reviewing requested changes from a systems perspective

• Emphasize completion dates

Chapter 4

51

Summary

• Importance of scope management• Project Scope Management Processes

– Initiation– Scope planning– Scope definition– Scope verification– Scope change control

• Initiation: selecting project– needs, category, financial (NPV, ROI and Payback

analysis) and weight score

Chapter 4

52

Summary (2)

• Scope planning– Charter to define objective– key project stakeholders should agree and sign the charter

• Scope definition– Scope statement, WBS is a tool to define scope

• Scope verification and change control– very difficult, common problem in IT– scope creep and change of user requirement

• methods to improve: – prototyping, case modeling, put requirement in writing, provide

adequate testing, incorporate change request review, emphasis on completion dates

Chapter 4