Best Practices for Successful Projects

Best Practices for Successful
Projects
By: Cathy Brunsting & Jeanna
Balistreri

Learning Points
• Learn how to get alignment and a common
definition of success at the beginning of your
project.
• Understand how this definition can be used
to create a commitment-based estimate and
release plan before detailed requirements
• Understand how to use the definition
artifacts to control change throughout the
project lifecycle

Start of Project
• “The Project will cost
$1.3 million and will take
7 months to deliver.”
• “The project will deliver
25 new business
features”

7 Months Later – Project Not Done
• How much is it really
going to cost?
• How much longer will
the project really take?
• What’s left to do?

7 Months Later – Issues in UAT
• Who defines success?
• How do we ensure that
what the business
expects is what IT
delivers?
• How do we align IT with
the business vision?

7 Months Later – “Done” with
Reduced Scope
• Who determines which
features to include?
• Who determines which
features to delay?

• How do we know business
value is achieved?

How do we turn these situations
around and bring predictability
into what is delivered and when it
is delivered?

Getting Predictable is a collection
of best practices that set project
teams up for success from the very
start

We focus in 3 areas to help us answer:
WHEN IS THE PROJECT DONE?


1)
Alignment and Agreement across the business;
Common Definition of Success in the Form of Business
Objectives/Scenarios

Common Objectives Across the
Organization
1. Drive alignment across business
stakeholders creating agreement
around project success in the form of
business objectives and business
scenarios.


2) Commitment Based Estimation

Organization
2. Facilitate the project team to create
an approach they can commit to and
hold themselves accountable to deliver
on the business objectives stated in
the business scenarios. We do this using
the Commitment Based Estimation.


3) Agreed Upon Approach To Tracking Progress

Organization
3. Define a common approach and
metrics, between the business and
delivery team, that will track the
progress of the project against the
business objectives. These
agreed-uponmilestones will be driven by
business
objectives and will be recorded and
tracked in a Commitment-Based-ReleasePlan.

Creating Alignment
• Drive alignment across Business Stakeholders
• Facilitated sessions
• Make sure everyone is heard
• Get buy in from all impacted stakeholders

• Create a Common Vision of Success
• Based on business objectives
• Understood by both Business & IT

• Call out spell checkers
• Transparency

Goals of a Common Vision
• Define success in a measurable way
• Reasonably accurate in a reasonable amount of time
• Definition in weeks, not months
• Define scope, not detailed requirements

• Alignment and ownership created amongst the business
stakeholders
• Expressed from the business perspective, in business
terminology
• Foster a partnership between
business and technology

Common Vision: 3 Core Techniques
• Business Process
Analysis
• Business Process
Scenarios

• Lo-fi Complex Scenarios

Business Process Analysis
• Define the business objectives
• Facilitated discussion to create a common vision
• 2-4 half day sessions

• Identifies the width of project
• Language is business-oriented,
not technical

Business Process Diagram (BPD)
• Visio diagram
showing the
process areas and
activities for the
client’s business
• Project charter
statement that
includes what is
in scope, out of
scope, and
undecided

Business Process Activity (BPA)
Document
• Word document,
defining the
process areas and
activities

Business Process Analysis
Project:

Smartphone 1.0 Example

Business Process:

Phone

Author:
Participants:

Joe Smith
Susan Williams, Joe Smith, Steven Jones

EXECUTIVE OVERVIEW
The phone process allows the user to make simple phone calls. Phone functionality includes call waiting, traces the
callers information such as name and caller Id. This process excludes speaker phone functionality.

BUSINESS PROCESS ACTIVITIES
1.

• One BPA per
process area

Make and receive calls.
The user can make or receive phone calls.

2.

Call Waiting
The user can receive a call while already on another call, and choose whether or not to answer it

3.

Caller ID w/number and name
The phone displays the number and name of the calling person.

4.

Ignore Call
User can decide not to answer a call, either during a previous call or not. The new caller will be sent to voice mail

5.

Call History
User can look at a historic list of calls, and tell if they were incoming, outgoing, or missed

6.

Voice Activation – Out of Scope
User can perform phone functions, such as calling or looking up contact information, by speaking into the phone

ASSUMPTIONS
ISSUES
1.
2.

Will voice activation require “training” the phone?
Will phone get phone number from the phone system network, as well as the name? If the name is not
available from the network, will the phone search for the number in the Contacts database, and display the
associated name?

Business Process Scenarios
• Identify the business scenarios and workflows
that capture the intent of the system
• Define what success looks like
• Provide the critical acceptance criteria for UAT

• Created in facilitated sessions
• 5-10 half day sessions
• From Business stakeholders, not IT

Business Process Scenario (BPS)
Document
BPA – Smartphone
Version: 1.0
February 11, 2008

• Word document,
defining all
business
scenarios for the
solution

Business Process Scenario
Project:
Business Process:
Author:
Participants:

Smartphone 1.0
Phone
Joe Lanasa
Bob Zimmerman, Joe Lanasa, Jenya Steinberg

PURPOSE

SCENARIOS
SCENARIO #1: Make a call using keypad.
a.

Dial a number, press call and connect.

b.

Have a conversation and disconnect.

SCENARIO #2: Make a call using Contacts option.
a.

• One BPS per
process area

Select Contacts option,

b.

A list of existing contacts gets displayed.

c.

Select a name of the contact. The screen with the phone numbers for that name is displayed.

d.

Select the phone number and press dial.

e.


SCENARIO #3: Make a call using Voice Activation option.
a.

Initiate voice activation by selecting voice activation option.

b.

Say a name of the person of interest.

c.

The voice system prompts for the confirmation of the name and the location of the number (home,
work, etc). Confirm name.

d.

The system dials the selected number.

SCENARIO #4: Make a call using Call History.
a.

Select Call History.

b.

Select a number from Call History List.

c.


d.


SCENARIO #5: Receive a Call.
a.

The phone rings.

b.

The user presses talk and answers the call.

c.


BPS – Assumptions and Issues
• Capture
assumptions and
issues for each
BPS

ASSUMPTIONS
1.
2.

ISSUES
1.
2.

Will this phone have speaker phone functionality?
Should the Caller ID on call history display just a phone number or all of the information: number, name, and
the location identification (e.g. home, cell, work)?

Lo-Fi Complex Business Scenarios
• Low-fidelity (paper) prototype of a scenario
(screen or report) in a system
• Lo-fis for all screens/reports are not necessary
• Ambiguous business scenarios
• High risk business scenarios
• An example of each type of interface

• Created in facilitated sessions
• Users illustrate intent of a system
• 2 – 4 half day sessions

Example Lo-Fi
• Use paper,
scissors, post it
notes and a pen
• Business user
creates their
vision of the
solution
• Not intended to
be a final design
for the screens

Commitment Based Estimating
• Define work effort using an Interface Catalog by identifying:
• User Interfaces
• System Interfaces (APIs)
• Engines
• Reports
• Identify effort level (high, medium, low)
• Adjust estimation values based
on the environment
• Driven by Technical Architect
• Supported by Facilitator/Scribe

What is an Interface Catalog?
• A complete list of artifacts required to
complete construction
• Record of assumptions related to the
artifacts

• A tool used to estimate development
time to be used as input to the Release
Plan and proposal
• Takes into account functional
requirements as well as non-functional
requirements

What does an Interface Catalog look
like?

Agreed Upon Approach to Tracking
Progress
•

Create a Release Plan based on the
common vision

•

Track business functionality, not IT tasks

•

Agreed to by both business and IT

•

Focus on development effort

•

Adjust for other factors
•

Detailed Requirements

•

Testing (Integration, Performance, UAT)

•

Deployment

•

Vacations and Holidays

What is a Release Plan?
• A high-level plan showing:
• The expected cost of the project
• The expected duration of the project
• Resources needed to support the plan

• Created by Project Manager
• In collaboration with BA and Architect

• Successful Release Plans:
• Account for system and
organizational constraints
• State assumptions clearly
• Traceability to BPA, BPS and
Interface Catalog

What does a Release Plan look like?

Team Roles and
Accountabilities

Business Accountable For:
•
•
•
•
•

Defining what the project is
Prioritization of features
Budget / Time constraints
Choosing options to implement
Scope changes

IT Accountable For:
•
•
•
•
•

How to build the project
How long it takes to build
Presenting Options for implementation
Communicating the cost of scope changes
Assigning the right team

Photo from muir.ceardach’s photos stream on Flickr: www.flickr.com/photos/ceardach/4549898798/

Definition Team Key Roles
• Facilitator
• Identify and clarify spellcheckers
• Foster collaboration

• Business Stakeholders
• Provide input about their vision & needs
• Empowered to make decisions and commitments

• Scribe
• Capture processes & scenarios
• Create definition artifacts

• Architect
• Commitment-based estimates
• Technical assumptions & constraints

IT Team Key Roles & Responsibilities
• Senior Business Analyst
• What are we building…
• Business Proxy; Empowered

• Senior Quality Analyst
• Is It Ready?
• Defines and Protects SLAs: What is “Good Enough”

• Architect
• Technical Approach & Does It Work

• Project Manager
• Transparency; Schedule & Cost
• Traffic Cop; Communication
• Holds Roles Accountable

IT Team Execution Key
Responsibilities
• Senior Business Analyst
• BPD / BPS Documents &
• Detail Requirements

• Senior Quality Analyst
• Test Plans, Scripts,
• Defect Management,
• UAT

• Architect
• Interface Catalog,
• Logical Architecture, Frameworks, Builds, etc…

• Project Manager
• Release Plan,
• Project Plan,
• State of the Union

Now What Happens?

By Marekventur (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)],
via Wikimedia Commons

By Peter Kemp / Paul Smith (Adapted from Paul Smith's work at
wikipedia) [CC-BY-3.0
(http://creativecommons.org/licenses/by/3.0)], via Wikimedia
Commons

Manage to the Vision and Plan
• Know your destination your Business Scenarios
which define success
• Tie detailed requirements to
the Business Scenarios
• Tie UAT test scenarios to
Business Scenarios
• Manage change to the
defined vision
• Make course corrections as
you go

Extra Work Uncovered in Detailed
Requirements

Staff
Changes
During the
Project

Outside
Influences
Impact Your
Project

Update the BDP When:

• Scope of the
project changes
• Process or
activities are
added or
removed

Update the BPS When:
BPA – Smartphone
Version: 1.0
February 11, 2008

• New
scenarios are
added

Business Process Scenario

• Scenarios are
removed
from a
release

SCENARIO #1: Make a call using keypad.

• Flow of the
scenario
changes

Project:
Business Process:
Author:
Participants:

Smartphone 1.0
Phone
Joe Lanasa
Bob Zimmerman, Joe Lanasa, Jenya Steinberg

PURPOSE

SCENARIOS
a.


b.


SCENARIO #2: Make a call using Contacts option.
a.

Select Contacts option,

b.

A list of existing contacts gets displayed.

c.

Select a name of the contact. The screen with the phone numbers for that name is displayed.

d.

Select the phone number and press dial.

e.


SCENARIO #3: Make a call using Voice Activation option.
a.

Initiate voice activation by selecting voice activation option.

b.

Say a name of the person of interest.

c.

The voice system prompts for the confirmation of the name and the location of the number (home,
work, etc). Confirm name.

d.

The system dials the selected number.

SCENARIO #4: Make a call using Call History.
a.

Select Call History.

b.

Select a number from Call History List.

c.


d.


SCENARIO #5: Receive a Call.
a.

The phone rings.

b.

The user presses talk and answers the call.

c.


Update the Interface Catalog When:
• Technical
assumptions
change
• Scenarios change
• Detailed
requirements
uncover
additional
technical work
that was not
accounted for

Update the Release Plan When:
• Staffing changes
• Scenarios change
• Interface Catalog
changes
• Any delays occur
• With actuals as
work is
completed

• Be open &
transparent
about issues,
delays
• Collaboratively
solve the
problems

• Celebrate
successes as you
go

Best Practices for Successful Projects

Best Practices for Successful Projects

Recommended

More Related Content

Similar to Best Practices for Successful Projects (20)

More from meghantaylor (6)

Recently uploaded (20)

Best Practices for Successful Projects

Editor's Notes