Benefits Analysis & WinWin Negotiations

1. Benefits Analysis & WinWin Negotiations Nupul Kukreja16thSeptember 2013

3. Agenda • Part 1: Benefits Analysis • Deficiencies of Project Management Mindset • Evolution of IT Applications • Adoption of Program Management Mindset • Program Model • Benefits/Results Chain • Part 2: WinWin Negotiations • WIOA Model of Negotiations • WinWin Sessions in 577

4. Agenda: VBSE 4+1 View 5a, 7b. Options, solution development & analysis Dependency Theory Utility Theory 3. SCS Value Propositions (Win Conditions) 2a. Results chains 2. Identify SCS 3b, 5a, 7b. Cost/schedule/ performance tradeoffs 4. SCS expectations management Theory-W:SCS Win-Win 3b, 7a. Solution Analysis 5a, 7b. Prototyping 5. SCS WinWin Negotiation 6, 7c. Refine, execute, monitor & control plans 1. Protagonist goals 3a. Solution Exploration ControlTheory DecisionTheory 7. Risk, opportunity, change management 5a. Investment analysis, Risk analysis 6a, 7c. State measurement, prediction correction; Milestone synchronization

5. Project Management “The project was delivered on time and within budget and scope and thus was a resounding success” • What’s wrong with the above claim? • Difficult to ascertain if the project was indeed beneficial to the clients/stakeholders • Just delivering the project doesn’t guarantee benefits • Benefits don’t turn on automatically after project delivery • Parochial IT-centric view i.e. delivery of IT system is the start-all and end-all

6. ‘Silver Bullet’ Thinking • Belief in the power of IT alone to deliver business results • Businesses purchase/install/create complex IT “silver bullet” packages with the belief of “benefits found inside”  • IT applications have evolved from simple automated systems to complex IT-enabled business transformations – demands new approach to management

7. Evolution of IT Applications

8. Automation of Work • Few manual jobs were automated and few new jobs created • Limited change to people’s jobs or to business processes • Overall change to nature of work not significant • Learning requirements: simple and focused on technology use • If the application ran correctly most of the benefits would be realized • Designed, operated and managed by IT experts

9. Information Management - 1 • Information was by-product of automated applications • Information used to make operational/tactical/strategic decisions owing to the proliferation of desktop computers • Slight change of jobs with training for taking predetermined action based on information • More Information  Benefits gained from analysis and application of information the job

10. Information Management - 2 • Automated information bases provided opportunities for designing new products • Mutual Funds • Discount Plans • Coupons etc. • Delivering a correctly functioning application no longer sufficient. For benefits to be realized: • Nature of people’s work changed • Business processes restructured and better integrated • Change in reward systems • Significant learning other than just technical usage • Increased number of potential IT applications (many conceived outside IT by business managers etc.)

11. Business Transformation • Information management applications enable organizations to rethink and redesign their business processes and how they carry out business • Example(s): • Internet and virtual banking redefining financial industry • Airlines offering passengers direct access to reservations systems • Amazon.com

12. Strategic Importance of IT High Low Evolution of IT Applications

13. Traditional Project Management Blindspots

15. Key Takeaways • ‘IT’ by itself, no matter how technically powerful cannot deliver business results • Benefits don’t just happen– benefits stream flows and evolves overtime as people learn to use the system • Benefits rarelyhappen according to plan – initial forecast is only an estimate. One has to ‘keep checking’ them like financial assets • Benefits realization is continuous process – involves envisioning results, implementing and checking intermediate results and dynamically adjusting path leading from investments to business benefits • Paradigm shift required: • Project Management to Program Management

16. Paradigm Shift

17. Paradigm Shift - Examples

18. Program Model • An ‘intermediate’ model to help articulate and capture ‘program vision’ • Created to facilitate easy creation of the Results Chain Model • Ease of use for communication amongst stakeholders • Helps see the ‘broader vision’ and all encompassing view of the ‘program’

19. Program Model Assumptions: Under what assumptions is this model true? Initiatives that need to be undertaken to help beneficiaries derive value from the expected benefits/value propositions Initiatives that need to be undertaken to help deliver value to the beneficiaries (i.e. “how” will the benefits reach the beneficiaries?)

20. Program Model Assumptions: Under what assumptions is this model true?

21. Example – Volunteer Management System • Assumptions • Growing needs of volunteers • Continuously growing volunteer pool • Increasing activities requiring more volunteers

22. Assumptions • Growing needs of volunteers • Continuously growing volunteer pool • Increasing activities requiring more volunteers

23. MEDIC-ated Value Propositions • Articulate and capture Value Propositions/Goals to be measurable… …so that you’ll know “how much” to achieve AND if/when you’ve achieved them • MEDIC-ated goals force early consideration of measurement influenced thinking:

24. Creating The Results Chain • Directly derivable from Program Model • Explicitly shows causal linkages between the various entities • Makes explicit the 4 management blind-spots mentioned earlier • Helps identify missing initiatives, stakeholders, benefits in the Program Model

25. Results Chain Diagram - Legend DMR/BRA* Results Chain Assumption(s): -Order to delivery time is an important buying criterion • Stakeholder(s) OUTCOME OUTCOME INITIATIVE Contribution Contribution Implement a new order entry system Reduced order processing cycle (intermediate outcome) Increased sales Reduce time to process order Reduce time to deliver product *DMR Consulting Group’s Benefits Realization Approach

26. Volunteer Management System – Program Model • Assumptions • Growing needs of volunteers • Continuously growing volunteer pool • Increasing activities requiring more volunteers

28. Rules for Creating Results Chain • Every initiative must be followed by an outcome/benefit • Intermediate outcomes link to other intermediate outcomes (final outcome has no outgoing links) • Initiatives/outcomes can link to more than one outcome • Stakeholders are linked to the Initiatives • Links are labeled with ‘contributions’ i.e. what does the particular initiative contribute towards attaining a particular benefit (use only if not explicit from context) • The “graph” is fully connected (assumptions are shown in a separate disconnected box) • Keep asking “so-what” for every outcome to uncover other outcomes and “what-else” to see if necessary initiatives are taken to realize the outcome(s)

29. Formalizing the Results Chain • For each benefit that matters capture at least the following: • Metric: How will the benefit be measured? • Measurement Method: What is the process of capturing the metric? • Frequency: How frequently the benefit should be tracked? • Baseline Value: What’s the current (baseline) value of the benefit? • Target Value: What’s the target value ‘range’ of the benefit? • Target Date: By when should the target be realized? • Mitigation: Action(s) to take if target value isn’t achieved? • Accountability:Who’s responsible for helping realize the benefit? • Trend: How have the benefits realized over time?

32. Workshop Problem Statement USC needs an online course reservation system to automate the registration process and to use the registration data to understand which courses to offer when and to improve their overall course offerings thereby increasing quality of the program • Get together in your teams and create: • Program Model • Results Chain • Brainstorm with your team the various elements of the program model and convert it to a results chain • Note the questions you may have or difficulties encountered • Time: 10 minutes

33. Problem Statement USC needs an online course reservation system to automate the registration process and to use the registration data to understand which courses to offer when, to improve their overall course offerings thereby increasing quality of the program Assumptions: Under what assumptions is this model true?

34. Workshop Q&A

35. Part 2: WinWin Negotiations

36. WinWin Taxonomy (a.k.a. WIOA Model) • Win-Win Equilibrium: • All win conditions covered by agreements • No outstanding issues Win Condition: Stakeholders’ desired objectives stated in a form understandable by users, customers and other stakeholders and formalized only where necessary Issue: captures conflicts between win conditions and their associated risks and uncertainties Option: candidate solutions to resolve an issue Agreement: captures shared commitment of stakeholders with regard to accepted win conditions or adopted options

37. WinWin Negotiation Primer • Refine and expand negotiation topics • Collect stakeholders’ win conditions • Converge on win conditions • Define glossary of key terms • Prioritize win conditions on: Business Value vs. Ease of Realization • Reveal issues and constraints • Record issues and options • Negotiate agreements Shared taxonomy of topics to understand project scope Record first draft of stakeholder’s needs/wants for all to view Disambiguation and de-duplication Domain vocabulary to develop mutual understanding Degree of project success dependent on win condition Technological, social, political or economic feasibility Variance in prioritization provokes discussion of issues/constraints Issues recorded along with possible resolution tactics We also capture a 3rd dimension of “Relative Penalty” – Degree of project failure if WC not deilvered Mutually agree to win conditions/options Above steps accelerated by a “Shaper” i.e. a facilitator who guides the negotiation

38. WinWin Negotiation in 577 • Two (possibly 3) sessions to be held in the coming week(s) (client required for only 2) – moderated by TAs • Part 1: • Create Program Model • Capture Value Propositions (Benefits) in Winbook • High level breakdown of desired capabilities (top-level decomposition) • Capturing win conditions for various aspects of the desired system: functional, levels of service, project, budget, language/tools etc • Part 2: • (Disambiguation/Deduplication before session) • Prioritize Win conditions (possibly broken into 2 sessions) • Revealing Issues/Constraints and other new win conditions and actually conducting the ‘negotiation’

39. Winbook and WinWin Negotiations • Based on the WinWin Negotiation Framework and directly supports the WIOA Model • Winbook is a tool to ‘log’ the negotiation and show its ‘status’ as function of time • “Functional” Win Conditions to be captured in the user-story format (As a <role>, I can <activity> so that <business value>) • Dynamic prioritization of win conditions with sensitivity analysis capability • Winbook Tutorial available on class-website under “Tools & Tutorials” • WinWin Sessions are HUMAN centric and highly iterative. A tool like Winbook only helps ‘document/augment’ the process and not execute it

40. WinWin Participation • The ENTIRE TEAM attends (includes clients ) • DEN students and remote clients should “Skype” into the conference • Set up an account on freescreensharing.net or join.me or TeamViewer etc., so as to share screen with remote participant(s) • Bring your laptops to the session(s) – at least 3 laptops (You may check-out laptops from SAL) • Be sure to practice the ‘setup’ prior to the session • Feel free to bring snacks and drinks (no alcohol please )

41. References • The Information Paradox – John Thorp • Business Model Canvas – Osterwalder & Pigneur • Value-Based Software Engineering Biffl et. al.