How To Scope A Project?: CODL-BIT (External) University of Moratuwa

How to Scope a Project?
Reference: Wysocky, 2014, R.K. Effective Project

Management : Traditional, Agile, Extreme. 7th Edition, Wiley.
Lesson 3:
---------------------------------------------------------------------
CODL- BIT( External)
University of Moratuwa 1
Learning Outcomes
•After learning this chapter, you will be able to:
•Understand what managing client expectations really means

•Explain the Conditions of Satisfaction (COS) development process
•Develop the COS document
•Recognize the importance of maintaining the COS throughout the entire project life cycle
•Plan and conduct the Project Scoping Meeting
•Build the Requirements Breakdown Structure (RBS)
•Diagram business processes
•Know what a prototype is and when to use one
•Validate a business case
•Outsource project work
•Understand procurement management
•Define the basic parts and function of the Project Overview Statement (POS)
•Write a saleable POS for your project idea using the language of your business
•Understand the role of the POS in the project management life cycle (PMLC)
•Write clear goal and objective statements
•Establish measurable criteria for project success
•Identify relevant assumptions, risks, and obstacles
•Discuss attachments to the POS and their role in project approval
•Understand the approval process for the POS
•
2
Lesson Outline
• Managing client expectations
• Conditions of satisfaction
• Planning and conducting a project scoping meeting
• Gathering requirements
• Diagramming business processes
• Prototyping your solution
• Business validation
• Procurement Management
• Writing an effective Project Overview Statement (POS)
• Approval to Plan the Project 3
How to Scope a Project
Tools, Templates & Processes used to Scope a Project
 Conditions of Satisfaction
 Project Scoping Meeting
 Requirements Gathering
 Diagramming Business Processes
 Prototyping
 Validating Business Cases
 Procurement Management
 Outsourcing
 Project Overview Statement
 Approval to Plan the Project
Client Wants vs. Client Needs Dilemma
NEEDS
WANTS
What your client wants may not be what your client needs.
Your job is to make sure that what they want is what they
need and that you will deliver what they need.
Who is Our Client?
Good Client Not So Good Client

• Know what they want  Not sure of what they want
• Know what it takes to deliver  Constantly change their mind
• Work towards best solution
 Not interested in solving
project problems
• Easy to work with  Hard to satisfy
• Meaningfully involved  Not very involved
Project manager & team (PT) must satisfy the needs of both.
Walk in the Shoes of Your Client - Scoping Process
• Client thinks:
• Scoping exercise is anxiety-ridden
• Scope definition must be complete from the start
• Change will not be welcomed during the project
Tips to Managing Client Expectations During Scoping
 Make sure you understand what your client

wants/needs/expects
 Make sure the client understands what you will do
 Assure yourself that what your client wants is what
your client needs
 Actively include your client in scoping the project
 Put yourself in the shoes of your client
 Meaningfully involve your client wherever possible
 Keep your client informed of project status
Establishing Conditions of Satisfaction
Clarify
Request
Request Response
Agree on
Response
Negotiate agreement and

write Project Overview Statement
Planning and Conducting the Project Scoping Meeting
 Purpose
 Document requirements
 Project Overview Statement
 Attendees
 Project Manager
 Client Group
 Core Team Members
 The Facilitator & Technographer

 Agenda
 Introductions
 Purpose of the Meeting (led by Facilitator)
 COS (conduct or review if done earlier)
 Description of current state (led by client representative)
 Description of problem or business opportunity (led by client
representative)
 Description of end state (led by client representative)
 Requirements definition and documentation (led by facilitator)
 Discussion of the gap between current and end state (led by
project manager)
 Choose best-fit project management approach to close the
gap (led by project manager)
 Draft and approve the POS (whole scope planning group)
 Adjourn
 Deliverables
 COS
 Requirements Document
 Best-fit project management life cycle (PMLC)
 POS
What Are Requirements?
A requirement is something the product/project should

do/produce or a quality that it must have.
Different Perspectives on Requirements
How the customer How the project How the analyst How the programmer How the consultant
explained it leader understood it designed it wrote it described it
How the project What operations How the customer How it was What the customer
was documented installed was billed supported really needed
Categories of Requirements
• Functional
• Non-functional
• Global
• Product/project constraints
Definition: Functional Requirement
Functional requirements specify what the product or

service must do.
Give an example of a functional requirement.
“The service shall accept a scheduled time and place for delivery.’’
Definition: Non-Functional Requirement
Non-functional requirements demonstrate properties

that the product or service should have in order to do
what must be done.
Give an example of a non-functional requirement.
‘‘The product shall be packaged so as to be attractive to senior citizens.’’

Definition: Global Requirement
Global requirements describe the highest level of

requirements within the system or product. They can be
thought of as general requirements.
Give an example of a global requirement.
‘‘The system shall run on the existing network.’’

Definition: Product/Project Constraints
Product/project constraints are those requirements that,

on the surface, resemble design constraints or project
constraints.
Give an example of a product/project constraint.
‘‘The total out-of-pocket cost plus five-year maintenance must not exceed
$35 million.’’
Approaches to Requirements Gathering
• Facilitated Group Session

• Interview
• Observation
• Requirements Reuse
• Business Process Diagramming
• Prototyping
• Use Cases
Facilitated Group Session Method
Strengths
1. Excellent for cross-functional processes
2. Detailed requirements are documented and verified immediately
3. Resolves issues with an impartial facilitator
Risks
1. Untrained facilitators can lead to negative responses
2. Time and cost of planning and executing can be high
Interview Method
Strengths
1. End user participation
2. High-level description of functions and processes provided
Risks
1. Descriptions may differ from actual detailed activities
2. Without structure, stakeholders may not know what information
to provide
3. Real needs ignored if analyst is prejudiced
Observation Method
Strengths
1. Specific/complete descriptions of actions provided
2. Effective when routine activities are difficult to describe
Risks
1. Documenting and videotaping may be time consuming,
expensive and have legal overtones
2. Confusing/conflicting information must be clarified
3. Misinterpretation of what is observed
Requirements Reuse Method
Strengths
1. Requirements quickly generated/refined
2. Redundant efforts reduced
3. Client satisfaction enhanced by previous proof
4. Quality increase
5. Reinventing the wheel minimized
Risks
1. Significant investment to develop archives, maintenance
and library functions
2. May violate intellectual rights of previous owner
3. Similarity may be misunderstood
Business Process Diagramming
Strengths
1. Excellent for cross-functional processes
2. Visual communications
3. Verification of “what is/what is not”
Risks
1. Implementation of improvement is dependent on an
organization open to change
2. Good facilitation, data gathering and interpretation
required
3. Time-consuming
Prototyping
Strengths
1. Innovative ideas can be generated
2. Users clarify what they want
3. Users identify requirements that may be missed
4. Client–focused
5. Early proof of concept
6. Stimulates thought process
Risks
1. Client may want to implement prototype
2. Difficult to know when to stop
3. Specialized skills required
4. Absence of documentation
Use Case Scenarios
Strengths
1. State of system described before entering the system
2. Completed scenarios used to describe state of system
3. Normal flow of event/exceptions revealed
4. Improved client satisfaction and design.
Risks
1. Newness has resulted in some inconsistencies
2. Information may still be missing from scenario
description
3. Long interaction required
4. Training expensive
Building the Requirements Breakdown Structure
Project goal
and solution
Requirement 1 Requirement n
Function Function Function Function Function Function

1.1 1.2 1.3 n.1 n.2 n.3
Sub-function Sub-function Sub-function

1.2.1 1.2.2 1.2.3
Feature Feature Feature Feature Feature Feature Feature Feature

1.2.1.1 1.2.1.2 1.2.1.3 1.2.1.4 n.3.1 n.3.2 n.3.3 n.3.4
RBS – The Reality
Project goal
and solution
Requirement 1 Requirement n
Functional
Function Function Function Function Function
Requireme Function
1.1 1.2 1.3 n.1 n.2nt n n.3
Sub-function Sub-function Sub-function

1.2.1 1.2.2 1.2.3
Feature Feature Feature Feature Feature Feature Feature Feature

1.2.1.1 1.2.1.2 1.2.1.3 1.2.1.4 n.3.1 n.3.2 n.3.3 n.3.4
Characteristics of the RBS
• The RBS is intuitive and most meaningful to the client

• The RBS is a deliverables based approach
• The RBS is consistent with the PMI PMBOK
• The RBS remains client facing as long as possible into the
planning exercise
Advantages of using the RBS
• Does not require a trained facilitator

• Does not require learning one of the contemporary approaches to
requirements gathering
• Presents an intuitive approach to gathering requirements
• Allows the client to work with the project team in an environment
familiar to them, i.e., to stay in their own comfort zone
• Paints a clear picture of the degree to which the solution is clearly
defined
• Provides the input needed to choose the best fit PMLC Model
Verifying Attributes
• Completeness – Are the requirements essentially complete or are

some missing?
• Clarity – Are the requirements clear? Are they ambiguous or
imprecise?
• Validity – Do the requirements reflect client intentions?
• Measurability – Does the requirement have a fit criterion
(measurement)?
• Testability – Can the criterion be used to test whether the
requirement provides the solution?
Verifying Attributes (continued)
• Maintainability – Will the implementation be difficult or easy to

understand or maintain?
• Reliability – Can the reliability and availability requirements be
met?
• Look and Feel – Have all human factors been met (GUI,
ergonomics, etc.)?
• Feasibility – Can the requirements be implemented?
• Precedent – Has a requirement similar to this been implemented
before?
Verifying Attributes (continued)
• Scale – Are the requirements large and/or complex?

• Stability – How often and to what degree might the
requirements change?
• Performance – Can the performance be met on a consistent
basis?
• Safety – Can the safety requirements be fully demonstrated?
• Specifications – Is the documentation adequate to design,
implement and test the system?
The Challenge of Requirements Management
• Not always obvious

• Come from many sources
• Not always easy to express clearly in words
• Many different types of requirements at different levels of detail
• Number of requirements can become unmanageable if not
controlled
• Requirements are not independent and may create conflict
situations
• Many interested and responsible parties
• Change as a result of changing business conditions
• Can be time-sensitive
What to do to get requirements gathering started
Sometimes the client has trouble envisioning

a solution or senior management is not
convinced that this project makes business sense.
If so, then consider:
 Diagramming business processes

 Prototyping
 Business validation
What is a Business Process?
A business process is a collection of activities that take
one or more inputs from one or more different sources
and produces a change of state that delivers business
value.
Input A
Input B Change
of state
Input C
Business Process
The Top-Down Left to Right Format
The Swim Lane Format
Context Diagramming Process
Outsourcing to Vendors and Contractors
• You do not have the necessary skills and competencies on your staff
• Buying the solution is less costly and more effective than building the solution
• There is a commercial product available that will meet your needs
• It is more cost effective to have a specialist provide the service
• It is not part of your core business activity
• You would like to develop the skills by first using a contractor

Lesson 02: Project Life Cycle Processes
Procurement Management – The Life Cycle

Vendor
Solicitation
Vendor
Evaluation
Vendor
Selection
Vendor
Contracting
Vendor
Management
Procurement Management Life Cycle

Vendor
Solicitation  Publish Request for Information (RFI)
 Advertise
Vendor  Rent a targeted list
Evaluation  Include previous vendors
 Attend a trade show where potential vendors
Vendor
are likely to have a booth
Selection
 Manage RFP responses and questions
 Vendor meeting
Vendor  Respond online
Contracting  Answer questions individually
 Hold a bidders conference
Vendor
Management

Vendor
Solicitation  Establish Vendor Evaluation Criteria
 Evaluate responses to RFP
Vendor  Reduce list of companies
Evaluation  Conduct onsite presentations
Vendor
Selection
Vendor
Contracting
Vendor
Management
Evaluation Criteria – Forced Ranking
Consultant A B C D Rank Forced

Sum Rank
Vendor
1 2 3 2 4 11 3
2 4 1 1 2 8 1
3 6 2 5 5 18 5
4 1 5 3 1 10 2
5 3 4 4 3 14 4
6 5 6 6 6 23 6
Evaluation Criteria – Paired Comparisons
1 2 3 4 5 6 SUM RANK
1 X 1 1 0 1 1 4 2
2 0 X 1 0 1 1 3 3
3 0 0 X 0 0 1 1 5
4 1 1 1 X 1 1 5 1
5 0 0 1 0 X 1 2 4
6 0 0 0 0 0 X 0 6

Vendor
Solicitation  Select the final vendor(s)
Vendor
Evaluation
Vendor
Selection
Vendor
Contracting
Vendor
Management

Vendor
Solicitation
 Negotiate the final contract
 No award
Vendor  Single award
Evaluation  Multiple awards
 Types of Contracts
Vendor  Fixed Price
Selection  Time and Materials
 Retainer
Vendor  Cost Plus
Contracting  Discussion points for negotiating final contract
 Final negotiation of contract
Vendor
Management

Vendor
Solicitation  Expectation setting
 For whom does the vendor work?
Vendor  What is expected of the vendor?
Evaluation  What tools and facilities are available to
the vendor?
 What training is available to the vendor?
Vendor
 What must the vendor deliver?
Selection
 When must it be produced?
 Who will receive the deliverables?
Vendor  How will the deliverables be evaluated?
Contracting
Vendor
Management

Vendor
Solicitation  Monitor Progress and Performance
 Monitor Requirements Change Requests
Vendor  Monitoring the Performance of Standard
Evaluation Project Activities
 Labor hours
 Cost (Earned Value)
Vendor
 Schedule (Earned Value)
Selection
 Frequency of change requests over time
 Incidence of bugs
Vendor  Risks
Contracting  Issue resolution
 Staffing levels and changes by position
Vendor  Transition form Vendor to Client
Management
Purpose of the Project Overview Statement
A one-page description that is:
A general statement of the project

A reference for the planning team
A decision aid for the project
To get management approval to plan the project
Ss
PO
Contents of the Project Overview Statement
PROJECT Project Name Project No. Project Manager
OVERVIEW Office Supply Cost Reduction PAUL BEARER

STATEMENT
Example POS
Problem/Opportunity
Our cost reduction task force reports that office supply expenses have exceeded budget by an
average of 4% for each of the last three fiscal years. In addition an across the board budget cut of
2% has been announced and there is an inflation rate of 3% estimated for the year.
Goal
To implement a cost containment program that will result in office supply expenses being within
budget by the end of the next fiscal year.
Objectives
1. Establish a departmental office supply budgeting and control system.

2. Implement a central stores for office and copying supplies.
3. Standardize the types and brands of office supplies used by the company.
4. Increase employee awareness of copying practices that can reduce the cost of
meeting their copying needs.
Success Criteria
1. The total project cost is less than 4% of the current year office supply budget.
2. At least 98% of office supply requests are filled on demand.
3. At least 90% of the departments have office supply expenses within budget.
4. No department office supply expense exceeds budget by more than 4%.
Assumptions, Risks, Obstacles
1. Central stores can be operated at or below the breakeven point.

2. Users will be sensitive to and supportive of the cost containment initiatives.
3. Equitable office supply budgets can be established.
4. Management will be supportive and consistent.
5. The existing inventory control system can support the central stores operation.
Prepared By Date Approved By Date
Olive Branch 9/2/04 Del E. Lama 9/3/04

POS Problem/Opportunity
A problem needing resolution or an

untapped business opportunity.
A statement of fact that everyone

would agree to. It stands on its own.
This is the foundation on which the

proposed project will be based.
POS Project Goal
A one or two sentence statement of

how you intend to address the stated
problem/opportunity.
A scoping statement that bounds the

project you are proposing.
POS Project Objectives
 5 or 6 brief statements that further

bound your project goal statement.
 From these statements it is clear what

is in and not in the proposed project.
 These statements might identify major

project deliverables.
 These statements form a necessary and

sufficient set of objectives.
POS Project Success Criteria
IRACIS
IR Increase Revenue
ACAvoid Costs
IS Improve Service
Use quantitative metrics only!

How much and by when?
POS Assumptions, Risks and Obstacles
• Technological
• New to the company
• Obsolescence
• Environmental
• Management change
• Staff turnover
• Interpersonal
• Working relationships
• Cultural
• Fit to the company
• Causal Relationships
• Will the solution solve the problem
POS Attachments
• Risk Analysis
• Financial Analyses
• Feasibility studies
• Cost/benefit analysis
• Breakeven analysis
• Return on investment
Gaining Approval to Plan the Project
 Expected Review Questions from Management
 How important is the problem or opportunity to the organization?

 How is the project related to our CSFs?
 Does the goal statement related directly to the problem or opportunity?
 Are the objectives clear representations of the goal statement?
 Is there sufficient business value as measured by the success criteria to warrant
further expenditures on this project?
 Is the relationship between the project objectives and the success criteria clearly
established?
 Are the risks too high and the business value too low?
 Can senior management mitigate the identified risks?
Participants in the Approval Process
 Core project team
 Project team
 Project manager
 Resource managers
 Function/process managers
 Client
 Senior management

How To Scope A Project?: CODL-BIT (External) University of Moratuwa

Uploaded by

Copyright:

Available Formats

How To Scope A Project?: CODL-BIT (External) University of Moratuwa

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Scope A Project?: CODL-BIT (External) University of Moratuwa

Uploaded by

Copyright:

Available Formats

How to Scope a Project?

Reference: Wysocky, 2014, R.K. Effective Project

•Understand what managing client expectations really means

Good Client Not So Good Client

 Make sure you understand what your client

Negotiate agreement and

Planning and Conducting the Project Scoping Meeting

Planning and Conducting the Project Scoping Meeting

A requirement is something the product/project should

Functional requirements specify what the product or

Give an example of a functional requirement.

Non-functional requirements demonstrate properties

Give an example of a non-functional requirement.

‘‘The product shall be packaged so as to be attractive to senior citizens.’’

Global requirements describe the highest level of

Give an example of a global requirement.

‘‘The system shall run on the existing network.’’

Product/project constraints are those requirements that,

Give an example of a product/project constraint.

• Facilitated Group Session

Function Function Function Function Function Function

Sub-function Sub-function Sub-function

Feature Feature Feature Feature Feature Feature Feature Feature

Sub-function Sub-function Sub-function

Feature Feature Feature Feature Feature Feature Feature Feature

• The RBS is intuitive and most meaningful to the client

• Does not require a trained facilitator

• Completeness – Are the requirements essentially complete or are

• Maintainability – Will the implementation be difficult or easy to

• Scale – Are the requirements large and/or complex?

• Not always obvious

Sometimes the client has trouble envisioning

If so, then consider:

 Diagramming business processes

• There is a commercial product available that will meet your needs

• It is more cost effective to have a specialist provide the service

• It is not part of your core business activity

• You would like to develop the skills by first using a contractor

Procurement Management – The Life Cycle

Procurement Management Life Cycle

Procurement Management Life Cycle

Consultant A B C D Rank Forced

Procurement Management Life Cycle

Procurement Management Life Cycle

Procurement Management Life Cycle

Procurement Management Life Cycle

A one-page description that is:

A general statement of the project

OVERVIEW Office Supply Cost Reduction PAUL BEARER

1. Establish a departmental office supply budgeting and control system.

Assumptions, Risks, Obstacles

1. Central stores can be operated at or below the breakeven point.

Prepared By Date Approved By Date

Olive Branch 9/2/04 Del E. Lama 9/3/04

A problem needing resolution or an

A statement of fact that everyone

This is the foundation on which the

A one or two sentence statement of

A scoping statement that bounds the