President and Founder @Rich Larson Watermark Learning …€¦ · Enhanced Performance. Enduring...

Enhanced Performance. Enduring Results.1

Richard Larson, PMP, CBAP, PMI-PBAPresident and FounderWatermark Learning

@Rich_Larson

bapmtraining

Enhanced Performance. Enduring Results.©

Training organization established in 1992, offering private and public classes and certification preparation in:• Business Analysis• Project Management• Agile-Scrum• Business Process Management • “Influencing Skills”

Courseware licensing Consulting and mentoring services Industry Partnerships

• An “original” PMI® Global RegisteredEducation Provider

• A Charter IIBA® Endorsed EducationProvider

• Offering BA, PM, and Agile Certificateprograms through Auburn University

Enhanced Performance. Enduring Results.© 3

The top 5 reasons for scope creep on projects and their causes.

At least one solution per cause that will work in your environment.

How Project Managers, Business Analysts, and Sponsors can work together effectively to manage scope.

When finished with this session, you will learn:


Why is Scope Creep so Bad? Top Five Causes

#1 – Lack of Scope Definition#2 – Requirements and Scope not Managed#3 – Inconsistent Requirements Processes#4 – Lack of Involved Sponsor#5 – Length of Project

Solutions


What is your Primary Role on Most Projects?

1. Project Manager 2. Business Analyst3. Both PM and BA4. Other


1. What is Scope Creep?2. Why is it a Problem?

Discussion


Item: What it Sounds like:Additional features or functions of a new product

“…it would be cool to …”

New requirements “… we have to have …”

Work not authorized beyond the agreed-upon scope

“… I think I will go ahead and …”

Scope creep is adding:


“Uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.” PMBOK® Guide, 5th edition

In short:• Unapproved changes on

projects• Unintended additions to

projects.

What is Scope Creep?


Extra time and cost devoted to unauthorized changes


Projects must typically be finished with same cost and time constraints• Leaves less time for approved parts of the scope,

hurting quality• Approved features may not get completed • End-product is not what was chartered• May not meet business needs • May not even be used (“gold-plating”)• Time and cost overruns to finish the authorized

parts of the scope.

What Harm Does it Cause?


Executives and Sponsors Project Managers Business Analysts Team Members All of the above?

Discussion


What has your experience shown to be the top cause of scope creep?

1. Ambiguous Scope Definition2. Scope/Requirements Not Managed3. Inconsistent method for requirements elicitation 4. Lack of sponsorship/stakeholder involvement5. Project Length


Overview – New Energy, Inc. Project – Sales Commission System Progress – Selected Solution

New Energy™


Don – Sponsor Mary – Project Manager Chris – VP of Sales Bob - Systems Analyst New Energy™

Don Mary Chris Bob


Sure, Mary. I’m really busy right now, but I trust your work. I’m sure you’ll do a

good job.

Hi, Don. Here’s the plan for the

new Sales Commission project In a

nutshell…OK?

DonMary

Guess what the scope-creeper would say:

PROJECT STATUS:• Package took

months to decide and install

• Stakeholder contention

• Behind schedule


Sponsor View• Focused on the business, not “Scope”• Not familiar or comfortable with Charters• Rarely think their scope is undefined – the PM

and team just don’t understand it.


Project View• Focused on projects• Define high-level scope: best documented in a

charter and expanded in scope statement • Elaborated using a WBS (Work Breakdown

Structure).


Outcomes• Skipping detailed decomposition and

requirements analysis: scope remains ambiguous

• Typically resolved by:1) The team interprets the requirements and builds

what it thinks is right, or 2) The team clarifies the scope by eliciting

requirements directly from stakeholders and subject matter experts (SMEs).


Recommendations1. Initiating

a. Work with Sponsors to develop own chartersb. Define the business need for a project

2. Planninga. Scope statements should include both features in and

out of scopeb. WBS decomposed into detailed work packages is a

mustc. Include time for detailed requirements work


Recommendations3. Execution

a. BAs – use variety of elicitation methodsb. Analyze and document clear, complete

requirements. c. BAs – use scope models and diagrams (e.g.,

context diagrams and Use Case diagrams) for visual clarity and alignment

d. PMs – work with sponsor to negotiate realistic deadlines (later delivery, chunk scope, etc.).


Example Use Case Diagram

TellerPay

Withdrawal

CashCheck

Customer System

Make Loan Payment

MakeDeposit

Banking System

Out of Scope:

Write Money Order

Issue Travelers Checks

Actor

System

Use Cases (in scope)

Use Cases (out of scope)


Great! I don’t want our staff to spend too much time in requirements

meetings.

Hi, Don. We don’t need to worry

about defining requirements …we’ll let the

vendor do that.

DonMary


PROJECT STATUS:• Discovery of new

interfaces needed• Bob is assigned to

define them all• No budget for

more help


Case Study Summary • Fixed date• Undefined requirements

undefined scope. • Under resourced

New Energy™

NOTE: Mary did not adequately define the scope. Because of time pressures, she is over-relying on the vendor for requirements.


Sponsor View• View the approved scope like a contract• Deliverables usually take more time to learn

and discover than was planned• “Discovered” features can become scope creep• Sponsors may abdicate small decisions.


Project View• Most projects have many new requirements • Easy to stray and let “rogue” ones in • Lack of clear scope management and decision-

making make it difficult to determine what is in and out of scope.


Recommendations1. Planning

a. Include a change management process in your planb. Include contingencies for changes

2. Executiona. Use effective scope management processesb. Use Agile/Scrum, if appropriate c. Clear roles and responsibilities for decision-makingd. Scope Management = “Ensuring that all new

features and functions requested are handled in away deemed satisfactory by all stakeholders.”


Recommendations3. Execution (cont).

a. BAs make sure to review all requirements with stakeholders and get approvals

b. Employ requirements traceabilityc. Consider using a Defect Management process

Project LifecycleBusiness Objectives

Project Objectives

Reqs Baseline

Traceability

Changes Approved Design Test Deploy


Process/ Phase RResponsible

AApprove

CConsult with

IInform

Plan Project Project Manager

Sponsor Subject Matter Experts (SMEs)

Team, Stakeholders

Plan Requirements

Business Analyst

Project Manager

SMEs Sponsor, Quality

AssuranceAnalyze Requirements

Business Analyst

Project Manager

SMEs, End-Users,

Developers

Project Manager

Add Requirements –High-Level

BA, PM Sponsor SMEs, Developers

Team

Add Requirements –Detailed

BA, PM Lead SME SMEs, Developers

Sponsor, Team

RACI: Clarify Roles and Responsibilities


Requirement Source Objective References

Design References

Test Case References

1.0 Change Order system

Sponsor Interview

BO1, PO2 TD1

1.1 Replace daily inventory updates with immediate stock level updates

2.0 Change Customer system

RW1 BO2 TD2 TC2

2.1 Integrate with Order2.1.1 Add age/gender info

Traceability Matrix: Manage Requirements

LEGEND: BO = Business Objective, PO = Project Objective, RW = Requirements Workshop, BPM = Business Process Model, TD = Technical Design, TC = Test Case

Enhanced Performance. Enduring Results.© 30


How’s this look? Our job

is to make sure you are delighted!

Bob, how’s the conversion? Say, any chance you

can you give us a web page for data

entry?

Bob

Mary said no…but it

wouldn’t be that difficult.

Chris


PROJECT STATUS:• Bob is behind

schedule on his interface analysis

• Chris is concerned there won’t be a web interface


Case Study Summary• Business problem not defined

• Requirements not traced to problem and objectives

• Changes process not planned

• Changes not tracked or communicated

New Energy™

NOTE: The business problem was never defined, so all requirements are considered equal. There was no process for handling and communicating changes.


Enhanced Performance. Enduring Results.

Reason Best Practices1. Ambiguous Scope

DefinitionCharter, Business Requirements, Product WBS

2. Scope and Requirements not Managed

Traceability and Change Process,Agile/Scrum

3. Inconsistent Process for Collecting Product Requirements

RMP with processes to plan, track, document, authorize, report.

4. Lack of Sponsorship and Stakeholder Involvement

Sponsor role, accountability and ownership, shared expectations and risk.

5. Project Length Develop iteratively and release incrementally.

Top 5 Factors


Sponsor View• Sponsors assume the project team has a

consistent method for requirements• Do not think much about “elicitation”• Not eager for the team to take much time to

refine detailed requirements.


Project View• High-level requirements have fuzzy boundaries and

are open to misinterpretation• “Scope drift” occurs when porous boundaries let in

additional requirements • Unauthorized stakeholders – providing their

requirements, adding to scope creep.


Recommendations1. Planning - PMs: plan time in project for

requirements and change management 2. Execution

a. BAs – create scope models early in projectb. Build on them as product is progressively

elaboratedc. Collect and analyze requirements in

categories and “layers”d. Three iterations deep: Scope layer, Expanded

layer, and Detailed layer.


Code Design

Scope Diagrams

Detailed Process

Maps

Scope

SIPOCsSwim Lanes

Expanded Detailed DesignScope Expanded Detailed Design


Case Study Summary• Requirements omitted

• Business process changes have not been considered

New Energy™

NOTE: Project scope didn’t include analyzing affect of system on business processes or whether the organization was ready for these changes.


Sponsor View• Sponsors are busy• Not even aware they are not “involved”• May become disinterested• Negative events tend to refocus them.


Project ViewTop 3 contributors to project failure* include:

1. Lack of User Involvement - Vacuums, scope creep result.

2. Lack of Executive Support - Disengaged sponsors are more likely to abdicate, leading to potential scope creep.

3. Unclear Statement of Requirements – see Cause 3!4. Changing Requirements and Specs

* Source: Standish Group 2014 Chaos Report



a. Sponsors should develop project charters to keep ownership where it belongs

b. Proper vehicle to describe vision and benefits2. Planning

a. PM - include lack of stakeholder participation as a risk

b. Build in contingencies


Recommendations3. Execution

a. PMs should do reporting to keep sponsors engaged

b. Focus on progress towards deliverablesc. Quick, visual displays of statusd. PM and BA - use RACI to manage roles and

responsibilitiese. Clarify decision-making and confirm SME

participation.


But, we’ve discovered things we need your

opinion on!

Talk to Alison in A/P. I’ve

“empowered” her to make decisions.

I’m very busy.I’ve gotta go…

Don, I’d like to meet with you to review

progress.

Don (on phone)Mary


PROJECT STATUS:• Bob is behind

schedule on his interface analysis

• Chris is concerned there won’t be a web interface


Case Study Summary• Disengaged Sponsor:

Decision-making Communications

• New stakeholder identified new requirements

New Energy™

When the business is not fully engaged but wants to keep the end date, shortcuts are often taken and inappropriate decisions are made by the wrong people.


Sponsor View• The longer a project, the more time they

have to expand scope• Business changes over the life of a long

project

Sponsor needsa Sprint

Sponsor gets a Marathon


Project View• Larson’s Law:

“The longer a project, the greater the chance for scope creep to occur.”

• Longer projects always have more proportionate scope creep

• Agile methods help this issue.



a. Educate sponsors to chunk projects into shorter sub-projects with tight deliverables

b. Consider an Agile approach2. Closing

a. As sub-projects finish, close them out, conduct lessons learned, and celebrate

b. Reinforce benefits of deliverables and maintain momentum.


Case Study Lessons Learned• Long delays increased chances the business

would change (and it did)• Project teams had more time to add

unauthorized features

New Energy™

NOTE: Organizations will change during long projects. Plan how the project will deal with change. Adding features incrementally can help.


Enhanced Performance. Enduring Results.

Reason Best Practices1. Ambiguous Scope

DefinitionCharter, Business Requirements, Product WBS.

2. Scope and Requirements not Managed

Traceability and Change Process. Defect Management.

3. Inconsistent Process for Collecting Product Requirements

RMP with processes to plan, track, document, authorize, report.

4. Lack of Sponsorship and Stakeholder Involvement

Sponsor role, accountability and ownership, shared expectations and risk.

5. Project Length Develop iteratively and release incrementally.

Top 5 Factors


List the top 5 reasons for scope creep on projects and their causes.

Describe at least one solution per cause that will work in your environment.

Discover how Project Managers, Business Analysts, and Sponsors can work together effectively to manage scope.

Now that we are done, you should be able to:


Copies of Presentation • We will send a personal copy of the presentation if you

provide a business card or email address

Visit our web site for free industry resources:www.WatermarkLearning.com/Resources

Articles Templates

Blog Bibliographies

Webinars eNewsletterContact:[email protected]: @Rich_Larson

President and Founder @Rich Larson Watermark Learning …€¦ · Enhanced Performance. Enduring...

Documents

Transcript of President and Founder @Rich Larson Watermark Learning …€¦ · Enhanced Performance. Enduring...