The document outlines best practices for managing successful projects by emphasizing the importance of achieving alignment and a common definition of success among stakeholders. Key strategies include commitment-based estimation, tracking progress with metrics, and fostering collaboration between business and technology teams. It illustrates the process through examples of business process analysis and scenario development, aimed at ensuring project predictability and alignment with business objectives.

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

2. 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

3. 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”

4. 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?

5. 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?

6. 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?

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

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

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

10. WHEN IS THE PROJECT DONE?
1)
Alignment and Agreement across the business;
Common Definition of Success in the Form of Business
Objectives/Scenarios

11. 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.

12. WHEN IS THE PROJECT DONE?
2) Commitment Based Estimation

13. Common Objectives Across the
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.

14. WHEN IS THE PROJECT DONE?
3) Agreed Upon Approach To Tracking Progress

15. Common Objectives Across the
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.

16. Alignment
on a
Common
Vision

17. 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

18. 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

19. Common Vision: 3 Core Techniques
• Business Process
Analysis
• Business Process
Scenarios
• Lo-fi Complex Scenarios

20. 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

21. 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

22. 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?

23. 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

24. 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
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.
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.
Have a conversation and disconnect.
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.
Have a conversation and disconnect.
SCENARIO #4: Make a call using Call History.
a.
Select Call History.
b.
Select a number from Call History List.
c.
Dial a number, press call and connect.
d.
Have a conversation and disconnect.
SCENARIO #5: Receive a Call.
a.
The phone rings.
b.
The user presses talk and answers the call.
c.
Have a conversation and disconnect.

25. 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)?

26. 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

27. 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

28. Commitment
Based
Estimating

29. 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

30. 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

31. What does an Interface Catalog look
like?

32. Create the
Plan

33. 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

34. 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

35. What does a Release Plan look like?

36. Team Roles and
Accountabilities

37. Business Accountable For:
•
•
•
•
•
Defining what the project is
Prioritization of features
Budget / Time constraints
Choosing options to implement
Scope changes

38. 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/

39. 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

40. 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

41. 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

42. Execute on
Plan

43. 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

44. 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

45. Extra Work Uncovered in Detailed
Requirements

46. Staff
Changes
During the
Project

47. Technical Issues Discovered

48. Outside
Influences
Impact Your
Project

49. Business
Plans
Change

50. Mistakes Happen

51. Teams Get
Behind

52. Update the BDP When:
• Scope of the
project changes
• Process or
activities are
added or
removed

53. 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
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.
SCENARIOS
a.
Dial a number, press call and connect.
b.
Have a conversation and disconnect.
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.
Have a conversation and disconnect.
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.
Have a conversation and disconnect.
SCENARIO #4: Make a call using Call History.
a.
Select Call History.
b.
Select a number from Call History List.
c.
Dial a number, press call and connect.
d.
Have a conversation and disconnect.
SCENARIO #5: Receive a Call.
a.
The phone rings.
b.
The user presses talk and answers the call.
c.
Have a conversation and disconnect.

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

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

56. • Be open &
transparent
about issues,
delays
• Collaboratively
solve the
problems
• Celebrate
successes as you
go

57. 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