Agile Portfolio Governance

Transcription

1 Agile Portfolio Governance Kevin Thompson, PhD, PMP, ACP, CSP, CSM The leader in training and consulting for project management and agile development

2 Upcoming PMI Certification Classes: Project Management Professional San Francisco Area - Redwood City February 4 7, 2014 PMI Agile Certified Practitioner San Francisco Area - Foster City March 19 21, 2014 San Francisco Area - Foster City May 14-16, 2014 San Francisco Area - Foster City June 18-20, 2014 Portfolio Management Training San Francisco Area - Redwood City March 13-14, 2014 PMI Agile Certified Practitioner Online On Demand, Any where, Any time Get $100 Off our instructor led courses! Use Promo Code: cprime2pk_100

3 Who is cprime? ENGAGED FOR YOUR SUCCESS 3

4 What we will Cover Basic recipes for Agile Portfolio Management How to develop business cases How to estimate ROI How to make portfolio decisions How to evaluate Initiative status This approach incorporates Principles of Agile Governance Download Recipes for Agile Governance: The Enterprise Web from for much more detail 4

5 Agile Governance Governance: The formalization and exercise of repeatable decision-making practices Governance = how to decide what to do Agile Governance is an Agile style of governance Enables rapid decisions, based on lightweight artifacts developed with minimum effort Applicable to any process (Agile, Plan-Driven, Hybrid, etc.) Governance Recipe: A mildly prescriptive and customizable technique for making a specific type of decision 5

6 Classic perspective Levels of Governance Project: Temporary endeavor to deliver a fixed scope Program: Collection of linked projects Portfolio: Group of Programs/Projects to be managed together Classic definitions don t map well to Agile world, but Hierarchical organization is still relevant. Our levels for Agile Governance Project Level: Refers to work of a single Team, which is a persistent grouping of people Program Level: Refers to the collaboration between Teams Portfolio Level: Refers to the development and management of business Initiatives that lead to program- and project-level work 6

7 Levels of Governance 7

8 Portfolio Governance Defined We define Portfolio Governance to be about Deciding which Initiatives to undertake, and in what order Deciding whether to continue, modify, or cancel ongoing Initiatives We will examine how to make these decisions quickly and effectively 8

9 Our Portfolio Terminology An Initiative is an endeavor or project to produce a particular set of deliverables (i.e., a defined scope) An Initiative is approved, scheduled, executed, or rejected based on the Business Case that has been developed for it A Business Case provides the analysis and justification for an Initiative A Portfolio is a specific set of Initiatives that have been proposed, are in progress, or have been completed A Portfolio Backlog is a ranked (sequenced) set of Initiatives This is the first step in planning for Initiative execution 9

10 Portfolio Governance Summary The Area Product Owner provides draft Business Cases for review in Portfolio Grooming Meetings. Program Managers, technical leads estimate effort and give feedback. A Portfolio Planning Team, consisting of Portfolio Owner, Area Product Owners, and others, defines and manages the Portfolio. The Portfolio Owner works with the Portfolio Planning Team in Portfolio Planning Meetings to approve, reject, and schedule Initiatives for implementation The Portfolio Owner works with the Portfolio Planning Team in Portfolio Review Meetings to assess what to do with in-flight Initiatives, based on their value and status The Portfolio Planning Team conducts Retrospectives to ensure improvement over time 10

11 Portfolio Owner Authority over Initiative selection and prioritization Reviews Business Cases Sets ranking of Initiatives Decides whether to continue, revise, or terminate Initiatives in flight Runs Portfolio Planning, Review Meetings Area Product Owner Works with customers, stakeholders to define & prioritize user-facing features Develops Business Cases for Initiatives Estimates value factors for Initiatives Works with Program Manager, others to get effort estimates Runs Portfolio Grooming Meeting Roles Program Manager Ensures cross-team collaboration is done well Facilitates effort estimation for Initiatives Supplies Teams schedule, capacity information needed for Portfolio planning 11

12 Portfolio Grooming Meeting Purpose Ensure Business Cases are ready for next Portfolio Planning Meeting When: Monthly Who: Area Product Owner (facilitator), Team Product Owners, Business Analysts, Program Managers, Architects, Tech Leads (Dev & QA), Agenda Attendees provide feedback to Area Product Owner on clarity, quality, acceptance criteria, dependencies, ranking of Business Cases Attendees identify major components, areas of work, holes (esp. technical) to be addressed Follow-up actions APO revises Business Case Program Managers, Architects, Tech Leads, etc. estimate effort 12

13 Purpose: Approve, Rank, and Schedule Initiatives When: Quarterly Who: Portfolio Owner (facilitator), Area Product Owners, Program Managers, others as needed Agenda Portfolio Planning Meeting The Portfolio Owner discusses new Business Cases with Area Product Owners and Program Managers 1. Area Product Owners clarify details 2. Portfolio Owner may revise value-related factors (not effort) 3. Portfolio Owner decides which BC s to add to Portfolio Backlog 4. Group uses tools (such as Decision Matrices) to guide ranking 5. Program Managers provide guidance about when new Initiatives are likely to begin, based on current work status and Portfolio Backlog ranking. 13

14 Purpose: Review progress, revise plans When: Monthly Who: Portfolio Owner (facilitator), Area Product Owners, Program Managers, others as needed Agenda Portfolio Review Meeting Area Product Owners present status of in-flight Initiatives All discuss benefits and drawbacks of continuing, revising scope for, or terminating Initiatives The Portfolio Owner decides what to do with each Initiative 14

15 Purpose: Learn from experience, and improve When: Between Portfolio Planning Meetings Retrospective Meeting Who: Portfolio Owner (facilitator), Area Product Owners, Program Managers, others as needed Portfolio Owner facilitates, records, enforces time box Say, 60 minutes total: 30 for recording, 30 for discussion Agenda 1. Review status of work items from previous Retrospective 2. All participants describe What went well, that we should do again? What would we like to be better? 3. Specify follow-up actions 1. Prioritize improvements 2. Select top few to address 3. Select owners to drive improvements 15

16 How to Conduct a Retrospective Meeting How to capture went well, want to be better items Don t ask to give info one at a time Sequential query is slow Risks anchoring Do ask everyone to write items on sticky notes, post on board Parallel data collection is quick Minimizes anchoring How to define follow-up actions Consolidate similar items Use multi-voting to rank suggested improvements Discuss, re-vote as needed to get consensus Ask for volunteers to own each item that requires follow-up effort Stop when consensus is that we re tackling enough 16

17 The Initiative and its Business Case A Business Case is a document that Describes the concept, value, cost, scope of an Initiative Presents information needed to make decisions about whether or when to execute the Initiative A Business Case should be brief Purpose is to enable decision-making, not provide comprehensive requirements Try to get it on one page 17

18 Two Audiences for Business Cases People who estimate effort Like and need to dig into details Always want more information than can be provided Focus on one or a few Initiatives at a time Tend to agonize over estimates, worry about being wrong Risks: Underestimating effort due to optimism Overestimating effort to avoid criticism People who make Portfolio decisions Are busy people who like short meetings Have to read and understand a stack of Business Cases quickly Want short summary information that enables quick decisions Risks False confidence in numbers Limited understanding of details 18

19 How Business Cases are Developed Two Parts: 1. A description of the Initiative: Scope, benefits, issues, etc. Area Product Owner develops the description 2. Information used to inform decisions about executing the Initiative Area Product Owner drives the development of this information Area Product Owner provides value-related information Area Product Owner relies on others (Program Managers, Teams, Architects, Directors, ) to provide cost-related information More expertise, objectivity than Area Product Owner We will address the Initiative description first, and decision criteria afterwards 19

20 Title Business Case: Initiative Description Problem / Opportunity Any short and meaningful title What problem are we trying to solve for customers and ourselves? What are the opportunities for customers and ourselves? Benefits What are the benefits to customers and ourselves? Impact / Opportunity Missed if not done Why might we regret not doing this? Description Summarize the key deliverables Acceptance Criteria Summarize key things to validate 20

21 Title Upgrade embedded Agents to V2 Problem / Opportunity Business Case: Title Benefits Impact / Opportunity Missed if not done Description Acceptance Criteria 21

22 Business Case: Problem/Opportunity Title Problem / Opportunity Upgrade embedded Agents to V2 The large volume of network traffic produced by the Agents in our medical devices means only about fifty devices can be in one network. Thus our three largest customers cannot add more of our devices to their networks. They are unable to provide the benefits of our monitoring services to patients outside of Critical Care Units, and we cannot sell more units to these customers. Benefits Impact / Opportunity Missed if not done Description Acceptance Criteria 22

23 Title Problem / Opportunity Business Case: Benefits Upgrade embedded Agents to V2 The large volume of network traffic produced by the Agents Benefits This change will enable our large customers to expand monitoring capabilities to patients (typically outside CCU's) who are not well served by current solutions. We will be able to sell up to ten times as many of our medical devices to our large customers, and avoid negative press regarding current network limits. Impact / Opportunity Missed if not done Description Acceptance Criteria 23

24 Title Business Case: Impact if not Done Problem / Opportunity Upgrade embedded Agents to V2 The large volume of network traffic produced by the Agents Benefits This change will enable our large customers to expand monitoring Impact / Opportunity Missed if not done Our three largest customers will be frustrated with the current limits, and us, and we will not be able to sell more units to these customers. We can expect to be criticized in the press, and by our competitors, in Q3 and Q4 this year. Description Acceptance Criteria 24

25 Description Business Case: Description This upgrade will allow customers to tailor device parameters (through the Administration console, or locally) to optimize performance. Even with no customization, default configurations should allow at least ten times the number of devices per site than is currently possible. Reduction in network overhead is achieved by providing settable polling intervals (default is 500 ms), instead of the hardwired intervals (commonly 1 ms), and XML-based message formats that are richer and more customizable than current formats. The former reduces Agent transmission count by 500 (by default), while the latter reduces the number of queries the Administration and Monitor consoles send to Agents. Agents will be updated for all (32) device types, starting with the most critical devices. Changes to Administrative and Monitor products will also be required. 25

26 Title Business Case: Acceptance Criteria Problem / Opportunity Upgrade embedded Agents to V2 The large volume of network traffic produced by the Agents Benefits This change will enable our large customers to expand monitoring Impact / Opportunity Missed if not done Our three largest customers will be frustrated with the current limits Description This upgrade will allow customers to tailor device parameters Acceptance Criteria 1. System works with at least 500 active devices, 50 monitors, and 5 administrative stations on one local area network 2. Upgraded monitor and admin stations support new and previous Agents 3. SysAdmin can set new parameters (polling intervals, content of device reports) 4. Agent connection time < 30 seconds after restarts (is now 3 minutes) 26

27 Return on Investment ROI is a key driver for investment decisions A key driver, not only driver ROI = R I R = Return (some measure of value) I = Investment (some measure of cost) The larger ROI, the greater the benefit for our investment The challenge is in estimating R and I 27

28 How to Estimate ROI Steps are easy to understand 1. Estimate the Return 1. Total revenues from Initiative 2. Net Present Value 3. Etc. 2. Estimate the Investment 1. Effort 2. Cost 3. Compute ratio Sadly, this is not usually possible 28

29 Understand the Limits of what is Possible The Return is composed of many factors The Investment is composed of many factors Limitations All factors are highly uncertain No factors can be estimated reliably Most factors cannot be tied to real-world numbers What is achievable and sufficient Understand whether ROI is better or worse for different Initiatives Express Return as weighted sum of standard factors Express Investment as weighted sum of standard factors Define common scale for factors based on relative values 29

30 Example ROI Calculation 1. Select Return factors Value-related items NPV is often WAG 2. Select Investment factors Cost-related items 3. Select weights for factors Range: Select finite Rating scale for factors Return Factor Weight Net Present Value 1.0 Urgency 0.5 Regulatory Compliance 1.0 Investment Factor Weight Effort to implement 1.0 Technical Risk 1.0 Scale Values Fibonacci 0,1,2,3,5,8 Example: NPV=5, Urgency=3, Reg. Compliance = 1, Effort=8, Risk=1 ROI = =

31 Ranking Portfolio Backlog via Decision Matrix Items in Portfolio Backlog are Business Cases Items are ranked (sequenced) in order of decreasing ROI Analogous to Product Backlog in Scrum Do largest ROI items soonest Schedule for when bandwidth becomes available Minimize parallel Initiatives to maximize productivity 31

32 Tracking and Metrics Burn-Up Chart Per Initiative Per Release Relationship between Initiatives and Releases is Many-to-Many I 1 I 2 I 3 R 1 R 2 R 3 32

33 Decisions about Ongoing Initiatives 1. Continue Initiative Assumptions valid, progress on track 2. Cut scope Assumptions valid, but won t hit planned goals 3. Add scope Assumptions valid, but ahead of schedule 4. Change scope Value can be improved with scope changes Remove as much work as is added! 5. Cancel Initiative Changes in needs make planned value not worth pursuing, compared to alternatives 33

34 Portfolio-level governance is about Conclusion Deciding which Initiatives to undertake, and in what order Deciding whether to continue, modify, or cancel ongoing Initiatives Portfolio governance can be conducted with Roles: Portfolio Owner, Area Product Owner, Program Manager, Ceremonies: Portfolio Grooming Meeting, Portfolio Planning Meeting, Portfolio Review Meeting, Retrospective Artifacts: Business Case Tracking and Metrics: Burn-Up Chart Key insights Evaluate ROI as ratio of weighted sums of value- and effort-related factors Estimate factors with coarse-grained relative scale 34

35 Questions & Answers 35