Best Practices for Successful Projects
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Best Practices for Successful Projects

on

  • 132 views

How many times have you worked on a project and felt it was doomed from the beginning? ...

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.

Statistics

Views

Total Views
132
Views on SlideShare
132
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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
  • Required by conference

Best Practices for Successful Projects Presentation Transcript

  • 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