5questions

Project Scope Management

Project Management in the Information Age MASY1-GC 1250

Session 2

V21.1

Project Scope

The Scope of a Project • Scope (The ‘What’)

o Desired ‘products’ / end results of the project o The processes used to create them o What is to be done o High level goal(s)

• Deliverables o The tangible products or services produced o Measurable objectives o The process life cycle o The development life cycle

3

Project Scope Management Processes

• Plan Scope Management

• Collect Requirements

• Define Scope

• Create Work Breakdown Structure (WBS)

• Validate Scope

• Control Scope

4

The Four Aspects of Scope

• In scope

• Not in scope

• Scope creep

• Change management

5

Well Defined Scope

• Represents the expectations of stakeholders • Helps assess the resource requirements • Is sensitive to constraints • Helps to make realistic commitments • Defines the boundary of the project • Facilitates the planning process

How easily can this be done????

6

Out of Scope

• A description of deliverables that will not be considered part of the boundaries of this project: o Features o Functions o Business processes o Products o Services

7

Scope Creep

• Uncontrolled growth of functionality • Requirements churn and expansion • Inadequate prioritization • Schedule delays • Cost increases • Quality problems • Misdirected energy and morale

8

Project Components Define the Scope

• A clear statement of purpose

• Requirements

• Specifications

• Deliverables

• Objectives

9

Establish the Project Objective

• Project objective o Establishes what is to be accomplished o Defines the tangible end product o Indicates the primary deliverables o Date required to be completed o Resources needed o Budget required o Expected benefits

11

Project Objectives

• Specific (Clearly defined) • Measurable (Objective analytic measures) • Attainable (It can be achieved) • Relevant (Alignment to the mission) • Time Sensitive (Deadline) • Extending (Risk taking) • Rewarding (The ‘Wow’ effect)

Why Bother Planning Scope?

• To improve the accuracy of time, cost, and resource estimates

• To define a baseline for performance measurement and project control

• To aid in communicating clear work responsibilities

12

Collect Requirements

• Information Gathering

• Clarify features and functions

• Establish look and feel

• The User Expectations

• Document the requirements in sufficient detail

• Prioritize requirements

• Trace their status from the planning, to the execution, to the delivery of results

13

Defining a Good Requirement

• Correct

• Complete

• Clear

• Consistent

• Verifiable

• Traceable

• Feasible

14

Rules for Effective Requirements

• Define objectives

• Verify the requirements against the objectives

• Apply scenarios…against requirements

• Apply use cases…against requirements

• Perform a consistency review

15

The Value of Requirements Management

• Enables prioritization

• Facilitates product designs

• Facilitates estimation

• Accelerates development

• Enables effective testing

• Necessary for project monitoring and control

• Enables requirements traceability

16

Requirements Gathering Techniques

• Interviews

• Focus groups

• Workshops

• Questionnaires / surveys

• Prototyping

• And more!!!!

Requirements gathering is often iterative!

17

Define Scope: The Scope Statement

• Project scope description o Progressively elaborated as needed

• Project deliverables o Product o Process

• Acceptance criteria

• Project exclusions

• This establishes a baseline from which progress and future changes are measured

18

The Work Breakdown Structure (WBS)

• Foundation for defining work as it relates to product and project deliverables

• The decomposition of scope into a hierarchical, logical classification structure

• The WBS Dictionary: a data repository for the WBS

19

Validate Scope

• Designated stakeholders validate that deliverables provide what was agreed upon in the scope statement and requirements documents

• Secure formal agreement in some form

20

Control Scope

• How to handle requests to change requirements and scope? oDeny them? oAccept / accommodate them?

21

Change Management

• A process to clearly define alterations

• Make changes during the execution process

• Help ensure project goal(s) are being met

• The project plan is being adhered to

• Scope-creep does not occur

• A change control process is invoked

22

Reasons To Accept Changes

• Added value • Clear need established

• Acceptable ROI

• Acceptable impact on schedule, budget

• Offers competitive advantage

• Little or no liabilities or risks

23

Reasons To Deny Changes

• Too much cost for too little value • Too much impact on schedule, budget

• Unacceptably low ROI

• Competitive risks

• Too much complexity

• Legal / regulatory risks

24

The Agile Approach to Scope Management

• Scope uncertainty is accepted – scope is allowed to evolve

• “Product owner” defines and prioritizes features

• Product owner manages scope changes

25

The Product Owner Role

• Voice of customer

• Maximize product value

• Maximize value of project team effort

• Creates and maintains the product backlog o A list of features ordered by priority o A living document subject to change o Multiple views: Product, release, increment

26

User Stories – An Agile Approach to Requirements Documentation

27

As a <type of user>,

I want to <goal>

so that <reason>

(Who?)

(What?)

(Why?)

User Story Example

28

As a book shopper,

I want to read reviews of a selected book,

so that I can decide whether to buy it

User Stories – Alternate Format

29

Given <a condition>,

When <a context>,

Then <an action or result>

User Story – Alternate Format Example

30

Given that the credit card expiration date is invalid

When the user enters it,

Then warn the user that it is invalid and allow a different one to be entered

User Stories – Best Practices

31

• Goal oriented • The INVEST requirements: • Independent • Negotiable • Valuable • Estimatable • Small • Testable

• Keep using diagrams!

Acceptance Criteria

32

• Provide meaningful acceptance criteria for all user stories

• Criteria MUST be translatable into tests! • Write tests BEFORE creating the product • Provide data for testing • Write criteria until they don’t add any more value