best practices for successful projects
Post on 07-Jul-2015
80 Views
Preview:
DESCRIPTION
TRANSCRIPT
Best Practices for Successful Projects
By: Cathy Brunsting & JeannaBalistreri
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?
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.
WHEN IS THE PROJECT DONE?
2) Commitment Based Estimation
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.
WHEN IS THE PROJECT DONE?
3) Agreed Upon Approach To Tracking Progress
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-upon-
milestones will be driven by business
objectives and will be recorded and
tracked in a Commitment-Based-Release-
Plan.
Alignment on a
Common Vision
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
• One BPA per process area
Business Process Analysis
Project: Smartphone 1.0 Example
Business Process: Phone
Author: Joe Smith
Participants: 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. 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. Will voice activation require “training” the phone?
2. 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
• Word document, defining all business scenarios for the solution
• One BPS per process area
BPA – Smartphone
Version: 1.0
February 11, 2008
Business Process Scenario
Project: Smartphone 1.0
Business Process: Phone
Author: Joe Lanasa
Participants: 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. 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.
BPS – Assumptions and Issues
• Capture assumptions and issues for each BPS
ASSUMPTIONS 1.
2.
ISSUES
1. Will this phone have speaker phone functionality?
2. 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
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?
Create the Plan
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
Execute on Plan
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
Technical Issues Discovered
Outside Influences
Impact Your Project
Business Plans
Change
Mistakes Happen
Teams Get Behind
Update the BDP When:
• Scope of the project changes
• Process or activities are added or removed
Update the BPS When:
• New scenarios are added
• Scenarios are removed from a release
• Flow of the scenario changes
BPA – Smartphone
Version: 1.0
February 11, 2008
Business Process Scenario
Project: Smartphone 1.0
Business Process: Phone
Author: Joe Lanasa
Participants: 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. 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.
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
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
top related