Abstract image of a woman sitting on books and studying on a laptop

XP Day: Using cost of delay – Joshua Arnold

J
Joshua Arnold

This document discusses implementing an economic decision framework using lean product development techniques at a large container logistics company. It describes piloting the approach on one portfolio to demonstrate benefits, then rolling it out more broadly. Key elements included improving prioritization based on cost of delay, breaking down work into smaller batches to smooth workflow, and limiting work in progress. An initial pilot showed benefits of $9 million from earlier delivery and $4 million from better prioritization. Refinements were needed as the approach was applied repeatedly to help the concepts stick within the organization.

1 of 86
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
Cost of Delay: A retrospective Implementing an economic decision framework Joshua Arnold
Safety First! These are merely the views of Joshua Arnold • My experience, viewpoint, thoughts • YMMV @joshuajames @ joshua@ecolojic.com
Together > Σ(parts)
“The Don”
Context & Scope Company, Culture, Technology, Process
A Container Logistics Company • >600 vessels • 3,800,000 TEU • 35,000 port calls • $26B Revenue
People & Culture • Logical Reasoning • High sense of urgency • Open, but structured • Willing to learn • Generalists
The IT Department • ~$500m Budget • ~$100m Development • Thin outsourcing • Legacy & SOA • Standard process? Demand > Supply
Scope: Lightbulb to live Prioritise new Reduce batching Break down Limit the Work ideas quickly to smooth flow the work in Progress Triage Dynamic Refine Realise Release Priority <1 week List Prioritise by Manage Get the point Increase knowing the capacity with of writing quality with Cost of Delay a pull system code quickly fast feedback The end-to-end innovation process
Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
Oct 2010 600 Long value pipeline Cycle-time from Lightbulb to Live # Requirements 400 200 0 Days
Oct 2010 Portfolio Work-in-Progress State # RQ Idea! 729 New 897 Being Drafted 416 Ready for Review 422 Ready for Guesstimation 181 Ready for Prioritization Analysis 2980 335 Ready for Estimation 68 Ready for Authorization 219 Authorized Estimation 502 215 Development Initiated 242 Development Complete Development 326 84 Testing (total of all states) Testing 395 395 On Hold Waiting 471 471 * Requirements currently work-in-progress
Oct 2010 Demand is increasing IT Development Budget (forecast) Scaling up might help but won‟t be enough to deal with the forecast increase in demand 2010 2011
XP Day: Using cost of delay – Joshua Arnold
XP Day: Using cost of delay – Joshua Arnold
SLT: Prune the Tree: Selected Lean/Agile Practices
Business Case Details What impact is this problem having on our customers/the business/the employees? What are the key deliverables to be expected? What other indirect benefits may arise from this work? > $9m by delivering functionality earlier due to delivering in smaller more frequent increments. Development expenditure in 2010 is $62m. MLSP Benefits Tracking team found that the hard benefit to cost ratio for IT investment was 1.8. Therefore the current hard benefits (over three years) for expenditure of $62m is approximately 1.8 X $62m = $111.6m Therefore the benefits per year are approximately $111.6 ÷ 3 = 37.2 By delivering half of the functionality in half of the time, we release value earlier and gain benefits earlier. The formula for this is: Additional benefits = ½(1-Cn/Co) x Original Benefits – where Cn=New Cycle Time, and Co= Old Cycle Time. When Cn/Co = ½ then the additional benefits are ¼ of the original benefits = ¼ x $37.2m = $9.3m > $4m by improving prioritization of work Key assumptions: • Development budget continues at 2010 levels ($62m) • Project have same hard benefits:cost ratio as the MLSP Benefits Tracking team measured in 2009 (1.8) • Benefits derived from an increase in value without any significant change in the cost of IT development. • Improvement in prioritisation will have a similar effect (+3.4%) as that seen on X-leap project. Soft benefits: > Flow improvements – a measurable improvement in cycle time, enabling MLIT to be more efficient – delivering an increase in development throughput with the same resource. > Quality improvements – a measurable improvement in VoC due to increased feedback cycles ensuring alignment of solution to expectations Nov 2010 All rights reserved © 2008
Planning next steps • Objective: begin to apply lean product development techniques to a specific portfolio: • Probably focus on AMC as pathfinder portfolio because: – Contains System A • steady flow of development, • “notoriously” slow cycle time with significant waiting waste • will be a visible win to the whole organization if we improve this – Contains other smaller applications too – Close to coaching team – Enthusiastic Portfolio and Delivery Manager Dec 2010
“I thought you were nuts trying it on [Sys A]” Board Member
Dec 2010 Seeking Business Partner support… 1. Participation • Steering Group • Kaizen/Retrospectives 2. Help us to reduce work package size • Express benefits for each Feature (not just Release level) • Break large Requirements down into smaller ones • Help adjust the approval process & funding model so that we approve/fund individual requirements/features. 3. Test the prioritisation approach • Help in putting together a backlog • Use Cost of Delay / Duration as an initial priority order
Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
Jan 2011 Improve Prioritisation
Jan 2011 Dynamic Priority List 1. Safe waiting place 2. Pull system • Flexible • Visible • Value driven To improve E2E speed, needed Faster “Triage”
Jan 2011 A framework for thinking about Value Increase Revenue associated with either improving our profit margin or Revenue increasing our market share Protect Sustaining current market share or Revenue revenue figures Reduce Costs that we are currently Costs incurring, that can be reduced Avoid Costs we are not currently incurring Costs but may do without action
Jan 2011 Estimating value per feature If we can‟t work out the value, is it worthless? (Need some idea of value in order to compare) WHY? WHY? Increase Protect Reduce Avoid Revenue Revenue Costs Costs
Making assumptions visible
Jan 2011 Getting to $ figures: A couple of tactics 1. Make the value equal to cost of alternatives Example: Automating a process Faster = Less Current waiting for the manual cost Cost of customer human errors Increase Protect Reduce Avoid Revenue Revenue Costs Costs
Jan 2011 Getting to $ figures: A couple of tactics 2. Estimate the value of the effects of the change Example: Improving invoice clarity and accuracy Reduce Make it easier for Use less employee payment customers to pay time processing delays the correct amount customer inquiries and complaints Increase Protect Reduce Avoid Revenue Revenue Costs Costs
Feb 2011 Jan/Feb 2011 – Key Learnings • Adding work-in-progress limits effectively reveals problems but can choke flow if set too agressively • Need to actively ensure all stakeholders feel this is managed appropriately • Need a firm hand • A new prioritisation approach creates winners & losers • Losers need active management (KPIs can make this worse) • Unclear role definitions/expectations hampers the taking of ownership by the permanent team • Too much of the change is still being driven by the Lean-product-development coaches • Need to repeat it many times for it to stick • Lean Product Development concepts are deceptively simple but applying them consistently take time for people to understand
Feb 2011 What are we trying to accomplish? development pipeline ^ ^ ideas
Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
Mar 2011 Cost of Delay Putting a price-tag on time How that value $ Business decays over time Information Value of the discovery value feature Cost of Delay While you may ignore economics, it won‟t ignore you
Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Time For ideas with a very long-life, with peak unaffected by delay
Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Late Entry Time For ideas with a very long-life, with peak unaffected by delay
Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Cost of Delay Late Entry Time For ideas with a very long-life, with peak unaffected by delay
Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Reduced Peak Cost of Delay Late Entry Time Short benefits horizon, and reduced peak due to late delivery
Mar 2011 Cost of Delay Putting a price-tag on time Reduced $ Benefits Realised Peak Cost of Delay Late Entry Time For ideas with a very long-life, with reduced peak due to later delivery
Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Cost of Delay Late Entry Time For ideas with a very long-life, with peak unaffected by delay
Mar 2011 Cost of Delay – Example 1 RQ-9076 Improve invoice accuracy leading to: • Reduction in number of customers paying late, worth an additional $4,000,000 per annum • Reduction in number of calls currently costing 5 FTEs at $20k per FTE Increase Revenue: $4,000,000 p.a. Reduce Cost: $100,000 p.a. Delaying this requirement by 1 week is worth $4.1m/52 weeks Cost of Delay = $78,846 per week
Mar 2011 Cost of Delay – Example 2 RQ-9077 Automating a process to satisfy new regulation that will be effective from 1st Sept 2012, in order to: • Avoid the additional manual processing resource which is estimated to cost about 20 FTEs at $20k per FTE Avoid Cost: $400,000 p.a. It‟s going to take about 13 weeks to automate, so delaying the start by 1 week beyond the last responsible moment of 1st June 2012 is worth $0.4m/52 weeks Cost of Delay = $7,692 per week
Mar 2011 Cost of Delay – Example 3 RQ-5942 Change required to satisfy a new customs regulation effective immediately, in order to avoid: • Fine estimated to be about $XXX,XXX per vessel per week x XX vessels that are calling at certain ports. • Estimated probability of being fined ~20%. The total benefits have been calculated as $0.Xm x XX x 20% = $Xm per week Avoid Cost: $X,XXX,XXX per week Cost of Delay = $Xm per week
Mar 2011 Cost of Delay: Trade off decisions Example: Development team Option A Option B Offshore team In-house team Cost: $5,000 Cost: $10,000 Time: 6 weeks Time: 4 weeks Cost of Delay = $10,000 per week
Mar 2011 Cost of Delay: Trade off decisions Example: Infrastructure supplier Option A Option B Usual Tier 1 supplier Alternative supplier Cost: $50,000 Cost: $60,000 Time: 5 weeks Time: 2 weeks Cost of Delay = $10,000 per week
Mar 2011 Cost of Delay: Trade off decisions Example: Vendor selection Option A Option B Usual supplier Alternative supplier Cost: $100,000 Cost: $50,000 Time: 10 weeks Time: 20 weeks Cost of Delay = $10,000 per week
Mar 2011 Scheduling decisions If these take the same amount of time to deliver: Requirement Cost of Delay RQ-9076 $78,846/week RQ-9077 $7,692/week RQ-5942 $X,000,000/week When the time required to deliver varies, then use: Cost of Delay Divided by Duration (CD3)
Mar 2011 CD3: Cost of Delay Divided by Duration How value decays Business value over time Information of the feature discovery value Cost of Delay CD3 Score Duration
Mar 2011 First In First Out Scheduling Project Duration Cost of Delay CD3 A 5 $1 0.2 B 1 $4 4 A C 2 $5 2.5 Cost of B Delay $50 C Time
Mar 2011 CD3 Scheduling Project Duration Cost of Delay CD3 A 5 $1 0.2 B 1 $4 4 C 2 $5 2.5 B Cost of Delay In this simple example: 27% reduction in Delay cost C compared to using CoD only $8 A 84% reduction in Time delay cost vs FiFO
Mar 2011 Cost of Delay Divided By Duration (CD3) The mathematics… Two possible features, A and B that have: • Cost of delay of CODa and and CODb ($ per week) • Each blocks the pipeline for Ta and Tb (weeks) Scenario 1 (B then A) Scenario 2 (A then B) B A Tb A Ta B Opportunity Cost: CODa x Tb Opportunity Cost: CODb x Ta If Scenario 2 is better than Scenario 1, then the opportunity cost incurred by choosing Scenario 1 will be bigger than the first: • CODa x Tb > CODb x Ta, rearranging this (divide everything by Ta x Tb)... • CODa/Ta > CODb/Tb
Mar 2011 Prioritisation in the real world Sometimes the data doesn‟t tell the full picture Additional levers? Organisational Technology Strategy Strategy In the real world… Start with CD3 Adjust CoD to State reasons “initial triage” reflect strategy for adjustment
Mar 2011 Why divide by Duration, not Cost? In product development, which of these three is typically the most limited? Money Capacity Time
Mar 2011 Why divide by Duration, not Cost? In product development, which of these three is typically the most limited? Money Capacity Time Can beg, borrow, steal Hard to scale Irreplaceable
Mar 2011 Why divide by Duration, not Cost? Knowing how long the development pipeline is blocked is more valuable information Money Capacity Time Can beg, borrow, steal Hard to scale Irreplaceable
Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
Jul 2011 End of “pilot mode” Process Measures Enable smaller batches  From 12wks between releases to 7wks by Sep Establish dynamic prioritisation  Process established by April Improve prioritisation Process established by April  Actively manage WIP  Process established by April Reduce size of requirements  No max, to max 5 guesstimate points by April Get to prioritisation faster  From 100 days to 7 days by April Currently 14 days Results Measures Cycle time from Pull Baseline: 210 days, Goal 90 days. 102 days by July Requires 12 months to gain data but should get to 140 days  by July by summing process segments. Voice of Customer Requires 12 months to gain data. Quick survey to CUS BPO  staff will give indication (Apr) Improved ROI Requires 12 months to gain data Measurement has begun
Nov- LPD Roadmap Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Jan Mobilise & Analyse M+A Teams Pilot (CSBPO & AMC) Red: Core team Yellow: Team 2 Pilot A (System A) Envision + Realise (A) Green: Team 3 Pilot B (System C) B Pilot New Proj. (XX) New Project Wider IT Roll out Sys D Assessment A Engage OPS + FIN M System B 1 OPS Applications 2 D2I & FBR 3 DCF 4 N&P Applications Key Assumptions: 5 • 8 Groups of Applications (+Pilot) 6 SAL Applications • Most effective to order by BPO Large Project X • 3 support teams required 7 • A team can start supporting a new Other smaller Apps Business Area every 3 months 8 Stabilise & Kaizen VFQ Education Value, Flow, Quality Education Kaizen Coaching Follow-up Coaching and Ad-hoc advice
May 2011 Jorge & Matt working with the Sys C Team
September 2011. Kicking off the Sys B Team
System B LPD Rollout Improve Prioritisation Team 1 Rollout to one area Triage Refine Realise Release Live
November 3 FINBPO Prioritisation Session I.
Vendor team in Kolkata
System B – (SAP Finance) 125+ requirements evaluated using Cost-of-Delay Features 25 released with CoD 120+ employees coached in process and practises 60+ attending daily stand-ups Major 4 Releases 6 Kanban boards 3 Teams doing Retrospectives
XP Day: Using cost of delay – Joshua Arnold
SOA Project Team: Problem statements for validation, evaluation and prioritisation using CoD & CD3
XP Day: Using cost of delay – Joshua Arnold
XP Day: Using cost of delay – Joshua Arnold
London teams From: Özlem Yüce Subject: Update from the London team Date: 1 February 2012 Hi all, We had the kick-off session this afternoon; BPOs, DM team and the vendor participated. The session was interactive and the team is very engaged. Especially the BPOs are impatient about applying COD which is great. Tomorrow we will teach them about plan Cost of Delay. We will also have the first prioritisation session (relative) and start identifying the data to be gathered for CoD calculations before the end of this week. Ozzie & Jorgie
Ops Applications From: Jorge Migueis Subject: Update on Ops Date: 10th May 2012 Hi all, Good news. METS+ BPO is building the DPL (see attached picture, red magnets). Cost of Delay is computed before coming to I.T. for sizing :) Best Regards, Jorge
Enterprise Architecture Subject: Prioritising EA requests using Cost of Delay Date: 15 May 2012 All, Please share this within your team as appropriate. In order to serve you better and provide you with a clearer picture on who to go to in EA we have strengthened the EA Customer Engagement. We will be operating as LPD like as possible which means that work tasks will be pulled from a Dynamic Priority List (DPL) when capacity is available. Tasks will be prioritised based on Cost of Delay Divided by Duration (CD3). When requesting a service from us please also provide us with: • Requested Delivery Date • Cost of Delay per week – i.e. the cost to the project/pipeline if we do not deliver by the date requested by you. Once a task is pulled from the DPL, you will be informed if we cannot deliver to the requested date and you will receive a Promise Date from us which we will do all to keep Head of Enterprise Architecture
Senior Management Sent: Monday, May 07, 2012 1:52 PM We are eagerly awaiting a change to [System A] and I cannot understand why it takes this amount of time to go through the review process!? The cost of delay for this change is USD XM per week With kind regards
 Head of Operations BPO
Author: Joshua Arnold & Chris Berridge
Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
Benefits for I.T. Headache: Controlling demand for scarce resources • Create clear focus on priorities • „less yelling and screaming‟ data-driven, more visible • Manage dependencies between teams • Change the conversation… Delivering “on time” Delivering value quickly Cutting I.T. costs
Benefits for the wider organisation Headache: Getting changes fast enough • Focus across business - the most profitable ideas or problems • Recognise urgency in prioritisation • Uses a language that everyone can understand • Encourages action to reduce time-to-market
Improved visibility of benefits $44.80 6x Average System A GCSS FACT (Before) (After) Benefits per dollar invested
System A: Value distribution (truncated) $2,800,000 $2,600,000 A small number of $2,400,000 features have a very $2,200,000 high Cost of Delay $2,000,000 Previous $1,800,000 Average $1,600,000 $1,400,000 Cost of Delay / week $1,200,000 $1,000,000 $800,000 $600,000 $400,000 $200,000 $0 0 10 20 30 40 50 60 70 80 Requirements sorted by Cost of Delay
System A: Value by quartile Average $ Benefits Per Requirement Next 25% Next 25% Bottom Top 25% of RQs 25% $220/wk $18,600/wk $5,200/wk $230,000/wk
System B: Value distribution 100000 90000 80:20 80000 Pareto Principle “the vital few” 70000 60000 Cost of Delay 50000 (US$ per week) 40000 30000 20000 10000 0 0 10 20 30 40 50 60 Requirements
Improved visibility of benefits 10x 6x Average Sys A Sys B (Before) (After) Benefits per dollar invested
Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
What went well? 1. Piloting with one application/business area 2. Quid pro quo - quality and speed 3. Flexibility via Dynamic Priority List 4. Softly, softly, catchy, monkey approach 5. Relative first; using economics to inform 6. Four benefit types help guide thinking about value 7. Dial up the use of numbers 8. Drive to dollars (what data is needed?) 9. Manual to Automated 10.CoD at Feature Level
What should we do differently? 1. Apply CoD/CD3 to support and maintenance work first? 2. In parallel? 3. Get EA using it earlier? 4. Make the CoD for each team/project more visible? 5. Get help to work out the Ave. Lifetime Value of a customer? 6. Leverage segmentation data, geographical customer value? 7. Teach more about benefits that are probabilistic in nature? 8. Coach senior stakeholders – train them to ask the Q? 9. Visualise the value/ROI for each delivery streams earlier? 10. Develop guidance on refining ideas, value mining?
What did we learn? 1. It works! Synergy with other Lean-Agile practices 2. Getting to numbers and $ isn’t as hard as you think 3. The four buckets cover well the type of benefits IT delivers 4. It works for Support and Maintenance, upgrades etc. 5. Assumptions can be standardised more than you think 6. CoD for dependencies between features and teams works 7. Some people really want to standardise duration units 8. It changes the focus and conversation between people 9. Senior stakeholders get it (and use it to escalate)! 10.CD3 encourages breaking down of requirements
What still puzzles us? 1. Will it survive without on-going support. How? 2. How to easily support other benefit profiles? 3. Dependencies between delivery streams which Duration? 4. Do items on the DPL need to have integrity? Duplicates? Real Options? Linking and updating of dupes? 5. Does Portfolio level CD3 need common units for duration? 6. CD3 for the Refine/breaking down stage? 7. How to handle Information Value in a consistent way 8. How to consistently represent Technical Debt using CoD 9. Do we need to do CoD at project level – scope? 10. How to speed up the feedback loop to know it‟s working?
Final thought • Typical situation in product development • Go hunting: try looking at the „Fuzzy Front End‟ PoC Dev & Test Captured Go Live! (24 hrs) (82 hrs) 18 weeks waiting 11 weeks waiting 9 weeks waiting Cost of Delay = $210,000 per week
Questions? Feedback? @joshuajames @ joshua@ecolojic.com

More Related Content

PDF
Cost of Delay: An Economic Approach to Decision Making
Roger Turnau
 
PDF
STATIK (Systems Thinking Approach to Introduce Kanban) Workshop Meetup
H. Javier Castillo Suazo
 
PPTX
Kanban - Back to Basics
Helen Meek
 
PDF
Implementing Kanban to Improve your Workflow
Jennifer Davis
 
PDF
Scrum and Kanban Sitting In A Tree...
Yuval Yeret
 
PPTX
Design thinking - IDEO
Ahmed Alaraj
 
PDF
Design Thinking - Bootcamp
Jan Schmiedgen
 
PDF
Solving Design Problem in 2.5 Hours with Google Design Sprint
Borrys Hasian
 
Cost of Delay: An Economic Approach to Decision Making
Roger Turnau
 
STATIK (Systems Thinking Approach to Introduce Kanban) Workshop Meetup
H. Javier Castillo Suazo
 
Kanban - Back to Basics
Helen Meek
 
Implementing Kanban to Improve your Workflow
Jennifer Davis
 
Scrum and Kanban Sitting In A Tree...
Yuval Yeret
 
Design thinking - IDEO
Ahmed Alaraj
 
Design Thinking - Bootcamp
Jan Schmiedgen
 
Solving Design Problem in 2.5 Hours with Google Design Sprint
Borrys Hasian
 

What's hot (20)

PPTX
Innovation at 50x 031616
Stanford University
 
PDF
LKCE19 Klaus Leopold - Flight Levels in Action
Lean Kanban Central Europe
 
PPTX
Patterns of Kanban Maturity
David Anderson
 
PPTX
Design Thinking
lmittler
 
PDF
James Shore: FAST: An Innovative Way to Scale — Hands-on Agile #45
Stefan Wolpers
 
PDF
Product Roadmapping Workshop
Fresh Tilled Soil
 
PPTX
Lean Agile Center of Excellence LACE – Drink our own Champagne
CA Technologies
 
PDF
Agile Product Discovery
Dr. Tathagat Varma
 
PPTX
Intro to design sprint
Angelene Jessy
 
PPTX
Lean Agile Center of Excellence - Agile2017 Talk
Deema Dajani
 
PDF
Design thinking
Manik Choudhary
 
PPTX
Extreme Programming
Erkan Erol
 
PDF
10 types of Innovation for Business
M-innovation Australia
 
PDF
An introduction to Cost of Delay
Glenn Smith
 
PDF
Agile Transformation v1.27
LiminalArc
 
PDF
The Principles of product development flow - a summary
Sebastian Kamilli
 
PDF
Lean Product Discovery
David Hawks
 
PPTX
Design thinking
Ashprvt
 
PDF
How to Define Your Product Roadmap by Dan Olsen
Dan Olsen
 
PPTX
Cost of delay (WSJF) - Roni Tamari
AgileSparks
 
Innovation at 50x 031616
Stanford University
 
LKCE19 Klaus Leopold - Flight Levels in Action
Lean Kanban Central Europe
 
Patterns of Kanban Maturity
David Anderson
 
Design Thinking
lmittler
 
James Shore: FAST: An Innovative Way to Scale — Hands-on Agile #45
Stefan Wolpers
 
Product Roadmapping Workshop
Fresh Tilled Soil
 
Lean Agile Center of Excellence LACE – Drink our own Champagne
CA Technologies
 
Agile Product Discovery
Dr. Tathagat Varma
 
Intro to design sprint
Angelene Jessy
 
Lean Agile Center of Excellence - Agile2017 Talk
Deema Dajani
 
Design thinking
Manik Choudhary
 
Extreme Programming
Erkan Erol
 
10 types of Innovation for Business
M-innovation Australia
 
An introduction to Cost of Delay
Glenn Smith
 
Agile Transformation v1.27
LiminalArc
 
The Principles of product development flow - a summary
Sebastian Kamilli
 
Lean Product Discovery
David Hawks
 
Design thinking
Ashprvt
 
How to Define Your Product Roadmap by Dan Olsen
Dan Olsen
 
Cost of delay (WSJF) - Roni Tamari
AgileSparks
 
Ad

Viewers also liked (8)

PDF
Busyness geekfest
Adam Yuret
 
PDF
20150808 tune into signals @ scrum day chile 2015
César Idrovo
 
PPTX
Estimating value through the lens of cost of delay
agilebydesign
 
PPTX
Joshua Arnold – Using Cost of Delay
Joshua Arnold
 
PPTX
Estimating value through the lens of cost of delay
Jeff Anderson
 
PDF
Kata in the Classroom
Mike Rother
 
KEY
Estimating Cost of Delay
Jason Yip
 
PPTX
What's the State of Agile Software Development?
VersionOne
 
Busyness geekfest
Adam Yuret
 
20150808 tune into signals @ scrum day chile 2015
César Idrovo
 
Estimating value through the lens of cost of delay
agilebydesign
 
Joshua Arnold – Using Cost of Delay
Joshua Arnold
 
Estimating value through the lens of cost of delay
Jeff Anderson
 
Kata in the Classroom
Mike Rother
 
Estimating Cost of Delay
Jason Yip
 
What's the State of Agile Software Development?
VersionOne
 
Ad

Similar to XP Day: Using cost of delay – Joshua Arnold (20)

PPTX
Deloitte lean agile state of the nation
Alexis Hui
 
PPTX
DOES16 London - Pat Reed - Mind the GAAP: A Playbook for Agile Accounting
Gene Kim
 
PDF
Using Cost of Delay to de-scale your organisation through decentralised decis...
Michael Fagan
 
PPTX
Agile ncr pramila hitachi consulting_future_coaching
AgileNCR2016
 
PPTX
Fear and Loathing in Agility: Long Live the Accounting Department
Accenture | SolutionsIQ
 
PPTX
BizFlow - BPM at Jardine Lloyd Thompson for Sales, Document Handling, Custome...
Garth Knudson
 
PDF
Agile Improvement Method - Andrew Griffits (Lamri)
Paula Gomes
 
PPTX
Gears agile
ajit.alwe
 
PDF
Agile NCR 2013 - Archana Joshi - maintaining agile equilibrium v4
AgileNCR2013
 
PPTX
Agile at enterprice level
Jan De Baere
 
PDF
Free Up Your Time For Strategic, Value-Added Activity
Performance Analytics Corporation
 
PDF
Sgin2013 scrum accomplished-industrialagilecasestudy-avinashrao
India Scrum Enthusiasts Community
 
PDF
Understanding Lean IT
CTE Solutions Inc.
 
PPTX
How to Calculate the Financial Impact of OEE
SafetyChain Software
 
PPTX
Improve Performance with Enhanced Insight into Profitability and Costs using ...
Alithya
 
PDF
Doug Groves Shell S O A Symposium
SOA Symposium
 
PDF
Agile QA report for the State of Washington
Arun Kumar
 
PDF
Agile for Business Analysts
John Goodpasture
 
PPT
Five Step Methodology To Implement Bpr
Roy Antony Arnold G
 
PDF
Value Driven Development by Dave Thomas
Naresh Jain
 
Deloitte lean agile state of the nation
Alexis Hui
 
DOES16 London - Pat Reed - Mind the GAAP: A Playbook for Agile Accounting
Gene Kim
 
Using Cost of Delay to de-scale your organisation through decentralised decis...
Michael Fagan
 
Agile ncr pramila hitachi consulting_future_coaching
AgileNCR2016
 
Fear and Loathing in Agility: Long Live the Accounting Department
Accenture | SolutionsIQ
 
BizFlow - BPM at Jardine Lloyd Thompson for Sales, Document Handling, Custome...
Garth Knudson
 
Agile Improvement Method - Andrew Griffits (Lamri)
Paula Gomes
 
Gears agile
ajit.alwe
 
Agile NCR 2013 - Archana Joshi - maintaining agile equilibrium v4
AgileNCR2013
 
Agile at enterprice level
Jan De Baere
 
Free Up Your Time For Strategic, Value-Added Activity
Performance Analytics Corporation
 
Sgin2013 scrum accomplished-industrialagilecasestudy-avinashrao
India Scrum Enthusiasts Community
 
Understanding Lean IT
CTE Solutions Inc.
 
How to Calculate the Financial Impact of OEE
SafetyChain Software
 
Improve Performance with Enhanced Insight into Profitability and Costs using ...
Alithya
 
Doug Groves Shell S O A Symposium
SOA Symposium
 
Agile QA report for the State of Washington
Arun Kumar
 
Agile for Business Analysts
John Goodpasture
 
Five Step Methodology To Implement Bpr
Roy Antony Arnold G
 
Value Driven Development by Dave Thomas
Naresh Jain
 

XP Day: Using cost of delay – Joshua Arnold

  • 1. Cost of Delay: A retrospective Implementing an economic decision framework Joshua Arnold
  • 2. Safety First! These are merely the views of Joshua Arnold • My experience, viewpoint, thoughts • YMMV @joshuajames @ [email protected]
  • 5. Context & Scope Company, Culture, Technology, Process
  • 6. A Container Logistics Company • >600 vessels • 3,800,000 TEU • 35,000 port calls • $26B Revenue
  • 7. People & Culture • Logical Reasoning • High sense of urgency • Open, but structured • Willing to learn • Generalists
  • 8. The IT Department • ~$500m Budget • ~$100m Development • Thin outsourcing • Legacy & SOA • Standard process? Demand > Supply
  • 9. Scope: Lightbulb to live Prioritise new Reduce batching Break down Limit the Work ideas quickly to smooth flow the work in Progress Triage Dynamic Refine Realise Release Priority <1 week List Prioritise by Manage Get the point Increase knowing the capacity with of writing quality with Cost of Delay a pull system code quickly fast feedback The end-to-end innovation process
  • 10. Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
  • 11. Oct 2010 600 Long value pipeline Cycle-time from Lightbulb to Live # Requirements 400 200 0 Days
  • 12. Oct 2010 Portfolio Work-in-Progress State # RQ Idea! 729 New 897 Being Drafted 416 Ready for Review 422 Ready for Guesstimation 181 Ready for Prioritization Analysis 2980 335 Ready for Estimation 68 Ready for Authorization 219 Authorized Estimation 502 215 Development Initiated 242 Development Complete Development 326 84 Testing (total of all states) Testing 395 395 On Hold Waiting 471 471 * Requirements currently work-in-progress
  • 13. Oct 2010 Demand is increasing IT Development Budget (forecast) Scaling up might help but won‟t be enough to deal with the forecast increase in demand 2010 2011
  • 16. SLT: Prune the Tree: Selected Lean/Agile Practices
  • 17. Business Case Details What impact is this problem having on our customers/the business/the employees? What are the key deliverables to be expected? What other indirect benefits may arise from this work? > $9m by delivering functionality earlier due to delivering in smaller more frequent increments. Development expenditure in 2010 is $62m. MLSP Benefits Tracking team found that the hard benefit to cost ratio for IT investment was 1.8. Therefore the current hard benefits (over three years) for expenditure of $62m is approximately 1.8 X $62m = $111.6m Therefore the benefits per year are approximately $111.6 ÷ 3 = 37.2 By delivering half of the functionality in half of the time, we release value earlier and gain benefits earlier. The formula for this is: Additional benefits = ½(1-Cn/Co) x Original Benefits – where Cn=New Cycle Time, and Co= Old Cycle Time. When Cn/Co = ½ then the additional benefits are ¼ of the original benefits = ¼ x $37.2m = $9.3m > $4m by improving prioritization of work Key assumptions: • Development budget continues at 2010 levels ($62m) • Project have same hard benefits:cost ratio as the MLSP Benefits Tracking team measured in 2009 (1.8) • Benefits derived from an increase in value without any significant change in the cost of IT development. • Improvement in prioritisation will have a similar effect (+3.4%) as that seen on X-leap project. Soft benefits: > Flow improvements – a measurable improvement in cycle time, enabling MLIT to be more efficient – delivering an increase in development throughput with the same resource. > Quality improvements – a measurable improvement in VoC due to increased feedback cycles ensuring alignment of solution to expectations Nov 2010 All rights reserved © 2008
  • 18. Planning next steps • Objective: begin to apply lean product development techniques to a specific portfolio: • Probably focus on AMC as pathfinder portfolio because: – Contains System A • steady flow of development, • “notoriously” slow cycle time with significant waiting waste • will be a visible win to the whole organization if we improve this – Contains other smaller applications too – Close to coaching team – Enthusiastic Portfolio and Delivery Manager Dec 2010
  • 19. “I thought you were nuts trying it on [Sys A]” Board Member
  • 20. Dec 2010 Seeking Business Partner support… 1. Participation • Steering Group • Kaizen/Retrospectives 2. Help us to reduce work package size • Express benefits for each Feature (not just Release level) • Break large Requirements down into smaller ones • Help adjust the approval process & funding model so that we approve/fund individual requirements/features. 3. Test the prioritisation approach • Help in putting together a backlog • Use Cost of Delay / Duration as an initial priority order
  • 21. Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
  • 22. Jan 2011 Improve Prioritisation
  • 23. Jan 2011 Dynamic Priority List 1. Safe waiting place 2. Pull system • Flexible • Visible • Value driven To improve E2E speed, needed Faster “Triage”
  • 24. Jan 2011 A framework for thinking about Value Increase Revenue associated with either improving our profit margin or Revenue increasing our market share Protect Sustaining current market share or Revenue revenue figures Reduce Costs that we are currently Costs incurring, that can be reduced Avoid Costs we are not currently incurring Costs but may do without action
  • 25. Jan 2011 Estimating value per feature If we can‟t work out the value, is it worthless? (Need some idea of value in order to compare) WHY? WHY? Increase Protect Reduce Avoid Revenue Revenue Costs Costs
  • 27. Jan 2011 Getting to $ figures: A couple of tactics 1. Make the value equal to cost of alternatives Example: Automating a process Faster = Less Current waiting for the manual cost Cost of customer human errors Increase Protect Reduce Avoid Revenue Revenue Costs Costs
  • 28. Jan 2011 Getting to $ figures: A couple of tactics 2. Estimate the value of the effects of the change Example: Improving invoice clarity and accuracy Reduce Make it easier for Use less employee payment customers to pay time processing delays the correct amount customer inquiries and complaints Increase Protect Reduce Avoid Revenue Revenue Costs Costs
  • 29. Feb 2011 Jan/Feb 2011 – Key Learnings • Adding work-in-progress limits effectively reveals problems but can choke flow if set too agressively • Need to actively ensure all stakeholders feel this is managed appropriately • Need a firm hand • A new prioritisation approach creates winners & losers • Losers need active management (KPIs can make this worse) • Unclear role definitions/expectations hampers the taking of ownership by the permanent team • Too much of the change is still being driven by the Lean-product-development coaches • Need to repeat it many times for it to stick • Lean Product Development concepts are deceptively simple but applying them consistently take time for people to understand
  • 30. Feb 2011 What are we trying to accomplish? development pipeline ^ ^ ideas
  • 31. Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
  • 32. Mar 2011 Cost of Delay Putting a price-tag on time How that value $ Business decays over time Information Value of the discovery value feature Cost of Delay While you may ignore economics, it won‟t ignore you
  • 33. Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Time For ideas with a very long-life, with peak unaffected by delay
  • 34. Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Late Entry Time For ideas with a very long-life, with peak unaffected by delay
  • 35. Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Cost of Delay Late Entry Time For ideas with a very long-life, with peak unaffected by delay
  • 36. Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Reduced Peak Cost of Delay Late Entry Time Short benefits horizon, and reduced peak due to late delivery
  • 37. Mar 2011 Cost of Delay Putting a price-tag on time Reduced $ Benefits Realised Peak Cost of Delay Late Entry Time For ideas with a very long-life, with reduced peak due to later delivery
  • 38. Mar 2011 Cost of Delay Putting a price-tag on time $ Benefits Realised Cost of Delay Late Entry Time For ideas with a very long-life, with peak unaffected by delay
  • 39. Mar 2011 Cost of Delay – Example 1 RQ-9076 Improve invoice accuracy leading to: • Reduction in number of customers paying late, worth an additional $4,000,000 per annum • Reduction in number of calls currently costing 5 FTEs at $20k per FTE Increase Revenue: $4,000,000 p.a. Reduce Cost: $100,000 p.a. Delaying this requirement by 1 week is worth $4.1m/52 weeks Cost of Delay = $78,846 per week
  • 40. Mar 2011 Cost of Delay – Example 2 RQ-9077 Automating a process to satisfy new regulation that will be effective from 1st Sept 2012, in order to: • Avoid the additional manual processing resource which is estimated to cost about 20 FTEs at $20k per FTE Avoid Cost: $400,000 p.a. It‟s going to take about 13 weeks to automate, so delaying the start by 1 week beyond the last responsible moment of 1st June 2012 is worth $0.4m/52 weeks Cost of Delay = $7,692 per week
  • 41. Mar 2011 Cost of Delay – Example 3 RQ-5942 Change required to satisfy a new customs regulation effective immediately, in order to avoid: • Fine estimated to be about $XXX,XXX per vessel per week x XX vessels that are calling at certain ports. • Estimated probability of being fined ~20%. The total benefits have been calculated as $0.Xm x XX x 20% = $Xm per week Avoid Cost: $X,XXX,XXX per week Cost of Delay = $Xm per week
  • 42. Mar 2011 Cost of Delay: Trade off decisions Example: Development team Option A Option B Offshore team In-house team Cost: $5,000 Cost: $10,000 Time: 6 weeks Time: 4 weeks Cost of Delay = $10,000 per week
  • 43. Mar 2011 Cost of Delay: Trade off decisions Example: Infrastructure supplier Option A Option B Usual Tier 1 supplier Alternative supplier Cost: $50,000 Cost: $60,000 Time: 5 weeks Time: 2 weeks Cost of Delay = $10,000 per week
  • 44. Mar 2011 Cost of Delay: Trade off decisions Example: Vendor selection Option A Option B Usual supplier Alternative supplier Cost: $100,000 Cost: $50,000 Time: 10 weeks Time: 20 weeks Cost of Delay = $10,000 per week
  • 45. Mar 2011 Scheduling decisions If these take the same amount of time to deliver: Requirement Cost of Delay RQ-9076 $78,846/week RQ-9077 $7,692/week RQ-5942 $X,000,000/week When the time required to deliver varies, then use: Cost of Delay Divided by Duration (CD3)
  • 46. Mar 2011 CD3: Cost of Delay Divided by Duration How value decays Business value over time Information of the feature discovery value Cost of Delay CD3 Score Duration
  • 47. Mar 2011 First In First Out Scheduling Project Duration Cost of Delay CD3 A 5 $1 0.2 B 1 $4 4 A C 2 $5 2.5 Cost of B Delay $50 C Time
  • 48. Mar 2011 CD3 Scheduling Project Duration Cost of Delay CD3 A 5 $1 0.2 B 1 $4 4 C 2 $5 2.5 B Cost of Delay In this simple example: 27% reduction in Delay cost C compared to using CoD only $8 A 84% reduction in Time delay cost vs FiFO
  • 49. Mar 2011 Cost of Delay Divided By Duration (CD3) The mathematics… Two possible features, A and B that have: • Cost of delay of CODa and and CODb ($ per week) • Each blocks the pipeline for Ta and Tb (weeks) Scenario 1 (B then A) Scenario 2 (A then B) B A Tb A Ta B Opportunity Cost: CODa x Tb Opportunity Cost: CODb x Ta If Scenario 2 is better than Scenario 1, then the opportunity cost incurred by choosing Scenario 1 will be bigger than the first: • CODa x Tb > CODb x Ta, rearranging this (divide everything by Ta x Tb)... • CODa/Ta > CODb/Tb
  • 50. Mar 2011 Prioritisation in the real world Sometimes the data doesn‟t tell the full picture Additional levers? Organisational Technology Strategy Strategy In the real world… Start with CD3 Adjust CoD to State reasons “initial triage” reflect strategy for adjustment
  • 51. Mar 2011 Why divide by Duration, not Cost? In product development, which of these three is typically the most limited? Money Capacity Time
  • 52. Mar 2011 Why divide by Duration, not Cost? In product development, which of these three is typically the most limited? Money Capacity Time Can beg, borrow, steal Hard to scale Irreplaceable
  • 53. Mar 2011 Why divide by Duration, not Cost? Knowing how long the development pipeline is blocked is more valuable information Money Capacity Time Can beg, borrow, steal Hard to scale Irreplaceable
  • 54. Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
  • 55. Jul 2011 End of “pilot mode” Process Measures Enable smaller batches  From 12wks between releases to 7wks by Sep Establish dynamic prioritisation  Process established by April Improve prioritisation Process established by April  Actively manage WIP  Process established by April Reduce size of requirements  No max, to max 5 guesstimate points by April Get to prioritisation faster  From 100 days to 7 days by April Currently 14 days Results Measures Cycle time from Pull Baseline: 210 days, Goal 90 days. 102 days by July Requires 12 months to gain data but should get to 140 days  by July by summing process segments. Voice of Customer Requires 12 months to gain data. Quick survey to CUS BPO  staff will give indication (Apr) Improved ROI Requires 12 months to gain data Measurement has begun
  • 56. Nov- LPD Roadmap Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Jan Mobilise & Analyse M+A Teams Pilot (CSBPO & AMC) Red: Core team Yellow: Team 2 Pilot A (System A) Envision + Realise (A) Green: Team 3 Pilot B (System C) B Pilot New Proj. (XX) New Project Wider IT Roll out Sys D Assessment A Engage OPS + FIN M System B 1 OPS Applications 2 D2I & FBR 3 DCF 4 N&P Applications Key Assumptions: 5 • 8 Groups of Applications (+Pilot) 6 SAL Applications • Most effective to order by BPO Large Project X • 3 support teams required 7 • A team can start supporting a new Other smaller Apps Business Area every 3 months 8 Stabilise & Kaizen VFQ Education Value, Flow, Quality Education Kaizen Coaching Follow-up Coaching and Ad-hoc advice
  • 57. May 2011 Jorge & Matt working with the Sys C Team
  • 58. September 2011. Kicking off the Sys B Team
  • 59. System B LPD Rollout Improve Prioritisation Team 1 Rollout to one area Triage Refine Realise Release Live
  • 60. November 3 FINBPO Prioritisation Session I.
  • 61. Vendor team in Kolkata
  • 62. System B – (SAP Finance) 125+ requirements evaluated using Cost-of-Delay Features 25 released with CoD 120+ employees coached in process and practises 60+ attending daily stand-ups Major 4 Releases 6 Kanban boards 3 Teams doing Retrospectives
  • 64. SOA Project Team: Problem statements for validation, evaluation and prioritisation using CoD & CD3
  • 67. London teams From: Özlem Yüce Subject: Update from the London team Date: 1 February 2012 Hi all, We had the kick-off session this afternoon; BPOs, DM team and the vendor participated. The session was interactive and the team is very engaged. Especially the BPOs are impatient about applying COD which is great. Tomorrow we will teach them about plan Cost of Delay. We will also have the first prioritisation session (relative) and start identifying the data to be gathered for CoD calculations before the end of this week. Ozzie & Jorgie
  • 68. Ops Applications From: Jorge Migueis Subject: Update on Ops Date: 10th May 2012 Hi all, Good news. METS+ BPO is building the DPL (see attached picture, red magnets). Cost of Delay is computed before coming to I.T. for sizing :) Best Regards, Jorge
  • 69. Enterprise Architecture Subject: Prioritising EA requests using Cost of Delay Date: 15 May 2012 All, Please share this within your team as appropriate. In order to serve you better and provide you with a clearer picture on who to go to in EA we have strengthened the EA Customer Engagement. We will be operating as LPD like as possible which means that work tasks will be pulled from a Dynamic Priority List (DPL) when capacity is available. Tasks will be prioritised based on Cost of Delay Divided by Duration (CD3). When requesting a service from us please also provide us with: • Requested Delivery Date • Cost of Delay per week – i.e. the cost to the project/pipeline if we do not deliver by the date requested by you. Once a task is pulled from the DPL, you will be informed if we cannot deliver to the requested date and you will receive a Promise Date from us which we will do all to keep Head of Enterprise Architecture
  • 70. Senior Management Sent: Monday, May 07, 2012 1:52 PM We are eagerly awaiting a change to [System A] and I cannot understand why it takes this amount of time to go through the review process!? The cost of delay for this change is USD XM per week With kind regards
 Head of Operations BPO
  • 71. Author: Joshua Arnold & Chris Berridge
  • 72. Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
  • 73. Benefits for I.T. Headache: Controlling demand for scarce resources • Create clear focus on priorities • „less yelling and screaming‟ data-driven, more visible • Manage dependencies between teams • Change the conversation… Delivering “on time” Delivering value quickly Cutting I.T. costs
  • 74. Benefits for the wider organisation Headache: Getting changes fast enough • Focus across business - the most profitable ideas or problems • Recognise urgency in prioritisation • Uses a language that everyone can understand • Encourages action to reduce time-to-market
  • 75. Improved visibility of benefits $44.80 6x Average System A GCSS FACT (Before) (After) Benefits per dollar invested
  • 76. System A: Value distribution (truncated) $2,800,000 $2,600,000 A small number of $2,400,000 features have a very $2,200,000 high Cost of Delay $2,000,000 Previous $1,800,000 Average $1,600,000 $1,400,000 Cost of Delay / week $1,200,000 $1,000,000 $800,000 $600,000 $400,000 $200,000 $0 0 10 20 30 40 50 60 70 80 Requirements sorted by Cost of Delay
  • 77. System A: Value by quartile Average $ Benefits Per Requirement Next 25% Next 25% Bottom Top 25% of RQs 25% $220/wk $18,600/wk $5,200/wk $230,000/wk
  • 78. System B: Value distribution 100000 90000 80:20 80000 Pareto Principle “the vital few” 70000 60000 Cost of Delay 50000 (US$ per week) 40000 30000 20000 10000 0 0 10 20 30 40 50 60 Requirements
  • 79. Improved visibility of benefits 10x 6x Average Sys A Sys B (Before) (After) Benefits per dollar invested
  • 80. Making the case Pilot: getting to $ benefits Pilot: Cost of Delay and CD3 Looking back Roll out to other teams Results to date What went well? What should we do differently? Looking fwd What did we learn? What still puzzles us?
  • 81. What went well? 1. Piloting with one application/business area 2. Quid pro quo - quality and speed 3. Flexibility via Dynamic Priority List 4. Softly, softly, catchy, monkey approach 5. Relative first; using economics to inform 6. Four benefit types help guide thinking about value 7. Dial up the use of numbers 8. Drive to dollars (what data is needed?) 9. Manual to Automated 10.CoD at Feature Level
  • 82. What should we do differently? 1. Apply CoD/CD3 to support and maintenance work first? 2. In parallel? 3. Get EA using it earlier? 4. Make the CoD for each team/project more visible? 5. Get help to work out the Ave. Lifetime Value of a customer? 6. Leverage segmentation data, geographical customer value? 7. Teach more about benefits that are probabilistic in nature? 8. Coach senior stakeholders – train them to ask the Q? 9. Visualise the value/ROI for each delivery streams earlier? 10. Develop guidance on refining ideas, value mining?
  • 83. What did we learn? 1. It works! Synergy with other Lean-Agile practices 2. Getting to numbers and $ isn’t as hard as you think 3. The four buckets cover well the type of benefits IT delivers 4. It works for Support and Maintenance, upgrades etc. 5. Assumptions can be standardised more than you think 6. CoD for dependencies between features and teams works 7. Some people really want to standardise duration units 8. It changes the focus and conversation between people 9. Senior stakeholders get it (and use it to escalate)! 10.CD3 encourages breaking down of requirements
  • 84. What still puzzles us? 1. Will it survive without on-going support. How? 2. How to easily support other benefit profiles? 3. Dependencies between delivery streams which Duration? 4. Do items on the DPL need to have integrity? Duplicates? Real Options? Linking and updating of dupes? 5. Does Portfolio level CD3 need common units for duration? 6. CD3 for the Refine/breaking down stage? 7. How to handle Information Value in a consistent way 8. How to consistently represent Technical Debt using CoD 9. Do we need to do CoD at project level – scope? 10. How to speed up the feedback loop to know it‟s working?
  • 85. Final thought • Typical situation in product development • Go hunting: try looking at the „Fuzzy Front End‟ PoC Dev & Test Captured Go Live! (24 hrs) (82 hrs) 18 weeks waiting 11 weeks waiting 9 weeks waiting Cost of Delay = $210,000 per week

Editor's Notes

  • #2: Looking back over the last tHopefully you can glean some ideas for how to give this a go where you are.I also have some puzzles that you might have some ideas about…
  • #3: I would like to create a safe environment,so I can speak freely and shareAnswer your questions honestlyMy names is JoshuaI am an EngineerI’m from New Zealand, sorry if my accent is difficult to understand.We have optimised the English language, by only have one vowel “uuuh”Do stop me if I’m going too fast or I’m not clear enough.
  • #4: So, whilst these are my views, of course, I didn’t do any of this on my own.We built a great team – Diverse backgrounds –Different strengthsGreater than the sum of the partsThanks to these guys I’ve got anything to say today
  • #5: And of course – a hat-tip to “the Don”, who pointed us in the right direction.How many people here have read Don’s blue book? Principles of PD Flow”What about Managing the Design Factory?The purple book (Developing products in half the time?)You’ll see some of his visualisations that we’ve used to get the ideas across.But we’ve also extended and adapted – and most importantly we’ve actually implemented it.
  • #6: I’ll talk briefly about the organisation, it’s people and how they use technology to solve their problems
  • #7: You may or may not have heard of them (predominantly B2B)But the banana you ate this morning was probably delivered in a refrigerated container on a Maersk vesselOne port call every 15 minutes
  • #8: Aptitude tests: Problem solving skillsAssertive, Challenging decision-makers – but also rather impatient. They want you to just tell them “how” to do it. Tend to skip quickly over the why, and the fact that the how is context specific.Low PDI, but quite a hierarchical org. KPIs flow down…Individuals typically learners, but the organisation learns slowly, skipping to wrong conclusions.Have a generalist culture. Sales &gt; IT? No problem!Few specialists…
  • #10: We were looking at the wholeonly going to cover two of the eight design principlesmostly the front-end of the process.
  • #11: So how did we start?
  • #12: We started with an assessmentlooked at a lot of data interviewed peopleAttempting to understand the problems.One issue was long CT E2ELet’s try to understand why this might be…In Maersk Line: on average, getting value delivery pipeline from the IT solution takes a long time.GCSS was taking a very long timeData Notes:Star is the MEDIAN (150 days)Average is 245 daysThere are HUNDREDS of RQs that have a cycle time of 0 days (not likely given the SLAs with suppliers)There is also a large skew to the longer side, with a StdDev of more than 260Green (&lt;90 days) is the area we think we can get to without major investment in back-end engineering.
  • #13: So when we look at the WIP – there is a lot going onEspecially analysis upstream of Prioritisation!Get to the point of prioritisation fasterControl demand through better prioritisation.[There is a lot of rubbish in this data, old RQs that have been delivered but for which the state hasn’t been updated. There is also quite a bit of left over from when focal point was first set up for different workspaces. It should be fairly easy for each workspace owner to clean up – but before now, we haven’t actually measured e2e cycle time, so it hasn’t been a concern.]
  • #14: Demand was already exceeding supplyIt was only going to get worse.And this is the budget, it doesn’t reflect all of the potential demandonly what they are looking to actually fund
  • #15: To get some insight into how the IT leadership team were thinking,we ran some “Serious Games” to understand what they felt was holding them backMOBILIZE: SELECTING PRIORITIESMLL IT Senior Leadership Team – Serious GamesIdentification of enablers and constraints to agile adoptionOct 2010
  • #16: and how they felt a more agile approach might solve these. Their expectationsRune, Adam &amp; Susanne: Agile in a box
  • #17: To get their buy-in to a potential solution set, we asked them to prioritise a set of lean-agile practices that we had selected and prepared.Improve Prioritisation was at the very root of the treeImproving Visibility of economic tradeoffs was also considered fundamental to improving.The timing of when we can start using Heijunka Levelling boards was was argued aboutHave previously made funding difficult, now to be easierEstimation accuracy not prioritised highly (surprisingly given amount of effort spent on it at the moment)Strangely little disagreement with any of the apples/ideas (including the “rotten” apples (roll out scrum, decide which projects should use agile)
  • #19: And then we went hunting for a guinea pig!To test whether this might work.Choosing the global booking system (GCSS)…Not ideal from the perspective of implementing Cost of Delay.And it was risky. High chance of failure.
  • #20: People were really supportive, really believed we could make a difference.Some thought we were a bit crazy. Even quite senior people!
  • #21: Having buy-in from IT wasn’t enough thoughIn order to change the way we prioritise Needed support from the BPO.responsible for feeding requirements into IT.It is these guys who controlled what was done and in what order.
  • #22: So, we’ve persuaded enough people to give this a go:to improve prioritisation using CoDWhat’s next?
  • #23: First step: Relative ordering of a list of RQs These were already planned for the next “fixed scope” release
  • #24: No workbeing done on these.So wewant to do twokeythings:Get to dollars(to enable CoD and compare Apples with Apples)Understand the valuemore quicklyso wecanreduce the time to prioritise.Lessanalysis on the specifics of whatwasneeded and how it shouldbe done, how long it wouldtake, the cost etc.[The samesheets of A5 that had beenusedwere transferred to the MLIT team’sarea]
  • #25: Wanted to change the focus fromcost to valueSo, this is how we sped up the assessment of valueKey enabler for fast triage (&lt; 1week)4 benefit types that a RQ can contribute to one or more of.&lt;explain&gt;Each and every requirement was discussed using these terms.Like a scaffolding for thinking about the value to the organisationRevenue associated with either improving our profit margin or increasing our market share- Increase in sales as a direct or indirect result of a new functionality (new customers, new products)Increase in margin as a result of a new functionality.Performance/delighting features that solve customer problems that they didn’t know they had. Increase share of wallet…Sustaining current market share or revenue figuresBasic/”maintenance” features so that you don’t annoy existing customers and push them elsewhereCosts that we are currently incurring, that can be reduced- Employee time we can reduce or redeploy- Non head-count costs including overhead, equipment etc. costs- IT Simplification i.e. decommission local applications Costs we are not currently incurring but may soon- Additional head-count that might be needed- Fines that might be levied- Loss of reputation, brand damage
  • #26: Keep asking “Why?” until you arrive at a point where you can identify one or more of the four benefit types…If there are no identifiable benefits should we bother doing it?Make (and share) assumptionsValidate those hypothesis and fine-tune over time – use feedbackDon’t fall into the trap of giving all regulatory or legal changes a different routeThese have varying impacts on the businessThe risks can be quantified
  • #27: Not just sharing the value estimate per feature, but sharing assumptions.Make (and share) assumptionsValidate those hypothesis and fine-tune over time – use feedback
  • #28: The cost of the counterfactual – The “do nothing” scenario in the case of reducing costs.
  • #29: Accounts receivable (Money owed to the company)Cash conversion cycle (days)Enabling new investments…
  • #30: So,how to handle the peoplewhomightfeelliketheyaregoing to lose?
  • #31: Reiterate that we were optimising for Maersk Line. Help that person to operate within the new paradigm (focus on value for Maersk Line rather that your own KPIs).If not, get help to change suboptimal individual KPIs!
  • #32: So, now we have numbers, great!How do we go further?I love BCR, it’s really great for Civil Engineering and Infrastructure projects. But it’s poorly suited for Product Development and Innovation.
  • #33: So, we’ve done a great job getting to $ benefitsThis is how we explained to people what CoD ishow to turn the $ benefits into a CoD figure
  • #34: The benefits realisation with respect to time typically look like this.New revenue streams, where there is no competition, market saturation (inelastic market). We’re ignoring discounting to simplify a bit.
  • #35: Assumes the same ramp-up to realise the benefits. This is the effect of being late.
  • #36: So what happens when you enter the market late? You would still have the expected peak but lose the amount of benefits due to late entry.. Cost of Delay quantifies the opportunity costThe economics impact of slow or late delivery
  • #37: With market loss due to late delivery and in markets where the shelf-life is short this is what the benefits might look like. FMCG (Fast Moving Consumer Goods) retail, where you are introducing a new product typically have this profile.This is more likely in markets where the shelf life of the product is fairly short, e.g.fashion, consumer electronics.
  • #38: Examples – wherever first mover advantage can produce lock-in and a near (or total) monopolye.g. PC operating systems, search engines, Cola-flavoured soft drinks.
  • #39: Thankfully, not only is this version the most common, it’s also the easiest to calculate.Parallelogram: base width = delay, height = peak benefits
  • #40: Cash conversion cycle = Accounts Receivable period (Receivables conversion period)
  • #41: Need to include change management – training users etc.We also have algorithms to work out the LRM across multiple delivery streams (say GCSS + SOA services) and for situations where there are multiple dependencies in terms of prerequisite components.
  • #42: Risk adjusted, probabilistic benefitsStochastic models – where the innovation is intrinsically non-deterministicInnovation is a stocastic process. It involves known unknowns AND unknown unknowns. Things we can’t determine until after the fact. Ex-post vs Ex-ante assessment
  • #43: How to use this information:One key use is to inform downstream decisions.Get it a couple of week’s earlier, but it’s gonna cost twice as much!&lt;Choose B!&gt;For instance, we can get some contractors, with specialist knowledge and experience to build this thing faster.e.g. different technology or components, or perhaps different resource: in-country specialists who are available immediately, contractors.
  • #44: I could get it a few weeks earlier, but at a 20% increase in cost!&lt;Choose B!&gt;[For many greenfield projects, getting environments in place is a massive source of delay.]
  • #45: These other guys reckon they can do it for half the price!Of course, it’ll take them a bit of time to pull a team together and get set up, but hey half price!!!1111!&lt;Choose A!&gt;IBM/TCS vs Systematic/Thoughtworks
  • #46: $20,000 p.a. = $385/wkIn fact, we should only delay a release for an additional feature if that feature has a higher CoD than the combined CoD of all the features ready for release.(Benefits: $500,000)How to use this information:One key use is to inform downstream decisions.For instance, we can get some contractors, with specialist knowledge and experience to build this thing faster.e.g. different technology or components, or perhaps different resource: in-country specialists who are available immediately, contractors.
  • #47: In what order? Prioritisation is effectively a scheduling problem.How do you guys prioritise? BCR, Value over Effort? Product Owner decides?If each of the earlier examples took the same amount of time to deliver, we should start working on the idea with the highest cost of delay first.CD3 is the specific case of WSJF – we weight using Cost of Delay. We also wanted people to empahsise the Numerator (Cost of Delay), the top line is the “higher order bit”
  • #49: Integral:While you’re delivering A, you incur the cost of delay of B &amp; CCoD:B+C = $4+$5 = $9Duration of A = 5Therefore Cost of Delay for B&amp;C during delivery of A is $10 x 5 = $45Then: while you’re delivering B, you incur the cost of delay of CCoD: C = $5Duration of B = 1Therefore Cost of Delay for C during delivery of B is $9 x 1 = $5Total Cost of Delay given FIFO scheduling = $50[Old calculations, with previous numbers!]5 x 8 + 3 x 5 = 40 + 15 =Cost of Delay = 55
  • #50: Integral:While you’re delivering B, you incur the cost of delay of A, &amp; CCoD:A+C = $1+$5 = $6Duration of B = 1Therefore Cost of Delay for A&amp;C during delivery of B is $6 x 1 = $6Then: while you’re delivering C, you incur the cost of delay of ACoD:A = $1Duration of C = 2Therefore Cost of Delay for A during delivery of C is $1 x 2 = $2Total Cost of Delay given CD3 scheduling = $8
  • #51: Debated at length with Chris
  • #52: Have to allow senior stakeholders to tamper, otherwise the approach collapses.Make the scale of tampering visible!
  • #53: Dividing by cost assumes that the limiting factor is available fundingIn most product development settings, it is time and the capacity of the development pipeline that is the limiting factor - time is an irreplaceable resourceKnowing how long the machine will be busy, blocked/unavailable is more valuable informationDuration takes account of key-man dependencies (e.g. 100 hours of work that can only be done by one person will block throughput for 100 hours)Other costs (e.g. Infrastructure) are typically of less concern than the opportunity cost incurred from blocking the pipelineNB: Benefit Cost Ratio should still be monitored and used as a means for rejecting ideas – just not for scheduling work
  • #54: Dividing by cost assumes that the limiting factor is available fundingIn most product development settings, it is time and the capacity of the development pipeline that is the limiting factor - time is an irreplaceable resourceKnowing how long the machine will be busy, blocked/unavailable is more valuable informationDuration takes account of key-man dependencies (e.g. 100 hours of work that can only be done by one person will block throughput for 100 hours)Other costs (e.g. Infrastructure) are typically of less concern than the opportunity cost incurred from blocking the pipelineNB: Benefit Cost Ratio should still be monitored and used as a means for rejecting ideas – just not for scheduling work
  • #55: Dividing by cost assumes that the limiting factor is available fundingIn most product development settings, it is time and the capacity of the development pipeline that is the limiting factor - time is an irreplaceable resourceKnowing how long the machine will be busy, blocked/unavailable is more valuable informationDuration takes account of key-man dependencies (e.g. 100 hours of work that can only be done by one person will block throughput for 100 hours)Other costs (e.g. Infrastructure) are typically of less concern than the opportunity cost incurred from blocking the pipelineNB: Benefit Cost Ratio should still be monitored and used as a means for rejecting ideas – just not for scheduling work
  • #57: So, we’ve pilotedWhat’s next?
  • #58: In order to roll out to other teams, we needed the pilot to work.By July, we had started to see the success from other changes, and we had enough confidence that it was going to work.
  • #60: First out was the Hermes teamCustoms Manifest applicationLots and lots of regulatoryrequirementsFines and or loss of ability to operate in particularcountries or ports were the mainorder for evaluatingbenefits and CoD
  • #61: FACT SAP team leads
  • #62: BPO wanted to use CoD across all of the SAP modules earlier, so we delivered this change to all them first
  • #63: November 23-24 Lisa in Kolkatavisting the IBM GCSS team and introducing LPD to IBM for FACT
  • #65: This was the situation as of May 2012.
  • #66: Kick-off for SOA teamsOctober 2011
  • #67: October
  • #68: Export Documentation team(Actually May 2012)
  • #69: Jrules Team (BRMS)November 24
  • #70: Feb
  • #71: Intermodal applicationsEmail from 10th May 2012
  • #72: mid-MayEven EA got in on it!From: Head of Enterprise ArchitectureSubject: Prioritising EA requests using Cost of DelayDate: 12 May 2012All,Please share this within your team as appropriate.In order to serve you better and provide you with a clearer picture on who to go to in EA we have strengthened the EA Customer Engagement. Whenever you require EA engagement in the MLIT core processes, please turn to the relevant team lead directly or to myself.We will be operating as LPD like as possible which means that work tasks will be pulled from a Dynamic Priority List (DPL) when capacity is available.Tasks will be prioritised based on Cost of Delay over Effort wherefore when requesting a service from us please in addition to the actual request also provide us with:Requested Delivery DateCost of Delay per week – i.e. the cost to the project/pipeline if we do not deliver by the date requested by you.Once a task is pulled from the DPL, you will be informed if we cannot deliver to the requested date and you will receive a Promise Date from us which we will do all to keepHead of Enterprise Architecture
  • #73: We built it in to a checklist for people to score themselves – primary use was as a means to generate ideas for improvement in their retrospectives.
  • #74: So, we’ve pilotedWhat’s next?
  • #75: The intangible benefits from using CoD &amp; CD3…
  • #77: What’s in it for them?Less yelling and screamingTime is money!
  • #78: GCSS data showing good signsSource for Before: MLSP reportSource for After: FocalPoint
  • #79: Power Law Curve. Some features have really high CoDAll FACT RQs with CoD &gt; 0.1 as of Focal Point Feb 28 2012(73 Requirements had CoD &gt; 0.1 as of Feb 28th 2012…)
  • #80: As quartile averages…Average of the top quartile is worth 1000X Focal Point Feb 28 2012.
  • #81: SAP distributionMore than 100 requirements with Cost of Delay.20-40 BPOs priortising.Serving two separate different Businesses. (Damco being the smaller logistics Company.)Only two with “Adjustments” so far. Since these are standard system (SAP) changes, nearly all of them are small (Template changes) and takes less than 4 weeks to deliver.Benefit cost ratio.
  • #82: Source for Before: MLSP reportSource for After: FocalPoint
  • #83: So, we’ve pilotedWhat’s next?
  • #85: We’re still working some stuff out. Testing and seeing what the results look like.