How many times have you worked on a project and felt it was doomed from the beginning?
Do you often feel that your business stakeholders are out of alignment?
That the development team has no idea what the business stakeholders really want?
That project estimates are done by picking numbers randomly?
Come explore techniques that can be used to help your stakeholders get aligned on the scope of the project and to define in a clear way what success looks like.
By getting alignment and defining success at the very beginning a project, the project team can make commitment- based estimates and release planning that makes sense in a reasonable (2 - 6 week) timeframe.
NewBase 19 April 2024 Energy News issue - 1717 by Khaled Al Awadi.pdf
Best Practices for Successful Projects
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.
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
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
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
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
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
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
Notes de l'éditeur
Required by conference
How many of you believe:The business objectives of the project(s) that I am supporting are very clear to me?That there is confusion around what the business is asking for on your projects?That you know what the project success criteria are?That the business views IT as a valued, trusted partner and critical to the company’s success?Your project is doomed right from the start?There is a lack of clarity around team roles and accountabilities.How many of you are frustrated with getting the business to clearly state and commit to project objectives?Write down the color you think of for each day of the week????Draw a house????(I’ll have notebooks and pens on the chairs with Geneca’s name that they can use to draw the house)Still need to finalize this …
Includes both business and IT respondents!!
There is good news too
High priority projectGood executive supportStandard estimating processProject plan created and followed Detailed requirements gatheredChange process followed
Just a ‘little’ misalignment between what the business asked for and what IT has delivered!!
First step is creating a common vision Amongst business stakeholders Between stakeholders and ITRemove barriers from the team to deliverCreate trusted partnership between business and IT
First step to predictable delivery is creating a common vision amongst the business stakeholders without that IT cannot be successful in what it delivers\At start of most projects, there are a lot of different agendas, etc. around the project. Traditional scope definition and requirements definition can falsely lead the team to believe that they are aligned. There is an appearance of alignment, but still hidden spell checkersHow do you know that you are in alignment?
Talk about common vision (summary – reference last years talk)Call out “spell checkers” Talk about techniques to get alignmentFacilitated sessionsBuy in from all impacted stakeholdersDefinition from stakeholders – if they don’t know what they want how can IT deliver it????Give example of asking 2 companies to create a spell checker for work processing toolSpell Checker example:Microsoft responds 2 people for 2 weeksWordPerfect responds 4 people for 6 weeksWhy are they different?
How many of your projects go awry because different business users have different ideas on what the value of the project is?How often does your IT team misunderstand what needs to be delivered? Or “gold plates” the delivery from the business perspective.
3 core techniques that I use at Geneca.Business process analysis – getting the business aligned on what the problem isBusiness Process Scenarios – defining success around the projectLo-Fi’s – clarifying murky areas
Project Charter statement with the processes and activities – keeps the business users focused on what problem they are solving.Defines both what is in scope and out of scope – marked in a clear wayCan be used to identify lower priority processes/activities that will be addressed in future releases, not the current project release
Defined in the language of the businessEnable IT QA to define testing strategy even before detailed requirements are captured
Also capture issues and assumptions
Focus on how BA collaborates with PM and Architect now … to use the common vision in an effective way to estimate project, plan project work and then mange change throughout the project.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
How is a Interface Catalog built:CatalogingComplete list of artifactsIdentify complexitiesCountingBottom up-estimatesReality checksLoadingAccount for additional tasks (e.g. framework)PlanningRelease Plan inputLegos for developer time to be used as input in the Release Plan
Focus on how BA collaborates with PM and Architect now … to use the common vision in an effective way to estimate project, plan project work and then mange change throughout the project.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
Who is involved:Geneca Analyst (usually the Scribe)Provide input into BA/QA time and assumptionsGeneca ArchitectProvide input regarding legos built from Interface CatalogGeneca Project ManagerBuilds the Release PlanWhat makes it successful?Account for NFRsSDLC, Client process Gates, Training, Transition, Performance testing etc.State Assumptions the plan is built onCR process triggered when assumptions changeTraceabilityBPD/BPS/Interface Catalog/Release Plan
IT should *NOT* commit to building a solution that they are not capable of building Not the right people Not enough people period Technically not feasible as requested Etc.Business owns what they getIf they don’t know what they want, can’t expect IT to commit to deliveryIT owns commitment to what can be done for time & cost availableIT says how long it will take IT doesn’t decide what to cut or changeIf what is asked for can’t be done within time and cost constraints, business decides what is / is not importantBusiness doesn’t decide how long it takes to developBusiness can’t tell IT how long dev on a piece of functionality will takeForced commitment is not really a committmentIllustrate with example of project where IT tells the business what they are getting; business tells IT how long it will takeWho is accountable for requirements?Who owns requirements?Talk about business responsible for defining what success means to themInvested stakeholders – need to be involved and own their ‘what’Talk about IT responsible for telling business how long it will take to deliverOptions to meeting time/budget constraintsCommittments
IT should *NOT* commit to building a solution that they are not capable of building Not the right people Not enough people period Technically not feasible as requested Etc.Business owns what they getIf they don’t know what they want, can’t expect IT to commit to deliveryIT owns commitment to what can be done for time & cost availableIT says how long it will take IT doesn’t decide what to cut or changeIf what is asked for can’t be done within time and cost constraints, business decides what is / is not importantBusiness doesn’t decide how long it takes to developBusiness can’t tell IT how long dev on a piece of functionality will takeForced commitment is not really a committmentIllustrate with example of project where IT tells the business what they are getting; business tells IT how long it will takeWho is accountable for requirements?Who owns requirements?Talk about business responsible for defining what success means to themInvested stakeholders – need to be involved and own their ‘what’Talk about IT responsible for telling business how long it will take to deliverOptions to meeting time/budget constraintsCommittments
Facilitator is usually a Client Partner or Project Manager or Business AnalystScribe is usually a Business Analyst (could be a PM or other role)
At Geneca we have 4 key roles on projects
At Geneca we have 4 key roles on projectsNOTE: The definition team and execution team can be different people. But, there needs to be a handoff in understanding from those who created the artifacts in definition and those who maintain them in execution. If the execution team finds issues or variations, they need to make these visible ASAP and adjust the artifacts and the team members expectations.
Setting a team up for success doesn’t insure successNeed to follow thru during implementation and make sure everyone stays aligned
Follow your development life cycle. The definition artifacts are applicable regardless of the methodology used.At Geneca we generally do an iterative approach, but no proscribed flavor