Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a XP Day: Using cost of delay – Joshua Arnold
Semelhante a XP Day: Using cost of delay – Joshua Arnold (20)
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 @ joshua@ecolojic.com
- 4. “The Don”
- 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
- 86. Questions? Feedback? @joshuajames @ joshua@ecolojic.com
Notas do Editor
- 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…
- 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.
- 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
- 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.
- I’ll talk briefly about the organisation, it’s people and how they use technology to solve their problems
- 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
- 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 > IT? No problem!Few specialists…
- We were looking at the wholeonly going to cover two of the eight design principlesmostly the front-end of the process.
- So how did we start?
- 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 (<90 days) is the area we think we can get to without major investment in back-end engineering.
- 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.]
- 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
- 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
- and how they felt a more agile approach might solve these. Their expectationsRune, Adam & Susanne: Agile in a box
- 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)
- 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.
- People were really supportive, really believed we could make a difference.Some thought we were a bit crazy. Even quite senior people!
- 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.
- So, we’ve persuaded enough people to give this a go:to improve prioritisation using CoDWhat’s next?
- First step: Relative ordering of a list of RQs These were already planned for the next “fixed scope” release
- 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]
- Wanted to change the focus fromcost to valueSo, this is how we sped up the assessment of valueKey enabler for fast triage (< 1week)4 benefit types that a RQ can contribute to one or more of.<explain>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
- 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
- Not just sharing the value estimate per feature, but sharing assumptions.Make (and share) assumptionsValidate those hypothesis and fine-tune over time – use feedback
- The cost of the counterfactual – The “do nothing” scenario in the case of reducing costs.
- Accounts receivable (Money owed to the company)Cash conversion cycle (days)Enabling new investments…
- So,how to handle the peoplewhomightfeelliketheyaregoing to lose?
- 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!
- 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.
- 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
- 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.
- Assumes the same ramp-up to realise the benefits. This is the effect of being late.
- 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
- 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.
- 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.
- Thankfully, not only is this version the most common, it’s also the easiest to calculate.Parallelogram: base width = delay, height = peak benefits
- Cash conversion cycle = Accounts Receivable period (Receivables conversion period)
- 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.
- 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
- 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!<Choose B!>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.
- I could get it a few weeks earlier, but at a 20% increase in cost!<Choose B!>[For many greenfield projects, getting environments in place is a massive source of delay.]
- 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!<Choose A!>IBM/TCS vs Systematic/Thoughtworks
- $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.
- 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”
- Integral:While you’re delivering A, you incur the cost of delay of B & CCoD:B+C = $4+$5 = $9Duration of A = 5Therefore Cost of Delay for B&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
- Integral:While you’re delivering B, you incur the cost of delay of A, & CCoD:A+C = $1+$5 = $6Duration of B = 1Therefore Cost of Delay for A&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
- Debated at length with Chris
- Have to allow senior stakeholders to tamper, otherwise the approach collapses.Make the scale of tampering visible!
- 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
- 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
- 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
- So, we’ve pilotedWhat’s next?
- 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.
- 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
- FACT SAP team leads
- BPO wanted to use CoD across all of the SAP modules earlier, so we delivered this change to all them first
- November 23-24 Lisa in Kolkatavisting the IBM GCSS team and introducing LPD to IBM for FACT
- This was the situation as of May 2012.
- Kick-off for SOA teamsOctober 2011
- October
- Export Documentation team(Actually May 2012)
- Jrules Team (BRMS)November 24
- Feb
- Intermodal applicationsEmail from 10th May 2012
- 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
- 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.
- So, we’ve pilotedWhat’s next?
- The intangible benefits from using CoD & CD3…
- What’s in it for them?Less yelling and screamingTime is money!
- GCSS data showing good signsSource for Before: MLSP reportSource for After: FocalPoint
- Power Law Curve. Some features have really high CoDAll FACT RQs with CoD > 0.1 as of Focal Point Feb 28 2012(73 Requirements had CoD > 0.1 as of Feb 28th 2012…)
- As quartile averages…Average of the top quartile is worth 1000X Focal Point Feb 28 2012.
- 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.
- Source for Before: MLSP reportSource for After: FocalPoint
- So, we’ve pilotedWhat’s next?
- We’re still working some stuff out. Testing and seeing what the results look like.