Cost of Delay: An Economic Approach to Decision MakingRoger Turnau
Cost of Delay is a lightweight approach to feature and product prioritization that asks a simple question: how much does it cost you not to have something? Reinertsen has said that Cost of Delay is the most important thing to quantify when producing a product. Great, but how do you start? How do you assign a dollar amount to something you have not built yet? How do we make sure that our teams focus on building the most important thing right now? This talk will give you the tools you need to understand Cost of Delay, as well as a set of techniques, from simple proxies to more sophisticated real-dollar analyses to help you understand the impact of delays on your organization.
In this presentation, I talk of Donald Reinstern's original idea of quantifying using Money units per time unit. However, the Agile world has been comprised a bit by using Fibonacci series or a scale of 1 to 10. Are we compromising the original intent of the author?
A retrospective looking at the implementation of Cost of Delay as a means to improve decision-making, improve the sense of urgency and encourage the breaking down of work as well as scheduling or prioritisation using CD3.
Ever wonder why Agile teams swear by relative estimation? My teams improved sprint planning efforts by a factor or 3, once we started using relative estimation.
Without understanding Agile relative estimation, teams tend to fall back to using time-based methods. This often leads them to spend way too much time on obsolete estimates that will be made even more complex with all the unknowns and constant emergent requirements of an Agile world!
“It's better to be roughly right, than precisely wrong!”
~ John Maynard Keyenes
The Solution is simple: understand that relative estimation is only a rough order of magnitude estimate to quickly organize the product backlog. This empowers your product owners (PO) to quickly make value based trade-offs on backlog items and decide on what stories the team should work next. This gives the business the highest bang for their buck!
PROBLEMS WITH TIME-BASED ESTIMATES
-Teams spend too much time trying to get it right
-Lack of confidence/experience can lead to people being either optimistic or pessimistic
-Timeline you are estimating may be too far in the future
-Due to long timeline, there are too many risks, unknowns, changes or dependencies!
WHY USE RELATIVE ESTIMATION?
-Allows a quick comparison of stories in the backlog
-Allows you to select a predictable volume of work to do in a sprint
-Uses a simple arbitrary scale
-Allows PO to make trade-offs and take on the most valuable stories next
ESTIMATION TIPS
-Relative points or equivalent Tshirt sizes are used to estimate stories, leveraging the Fibonacci sequence modified for Agile.
-The team estimates the story, not management nor the customer.
-Story estimates account for three things: effort, complexity, and unknowns. Don’t short sell yourself by estimating effort alone, that’s where waterfall projects face issues.
-Remember to estimate all Stories, user stories or technical stories. Even estimate research or discovery spikes.
-Refine your backlog as a team on a continuous basis, to get your stories to meet the Definition of Ready.
-Only pull into your sprint, stories that are refined and estimated.
-Break down stories that are large, into smaller slivers of value to optimize your flow.
-Don’t sweat it if you get it wrong, teams often do early on but improve over time.
Cost of Delay: An Economic Approach to Decision MakingRoger Turnau
Cost of Delay is a lightweight approach to feature and product prioritization that asks a simple question: how much does it cost you not to have something? Reinertsen has said that Cost of Delay is the most important thing to quantify when producing a product. Great, but how do you start? How do you assign a dollar amount to something you have not built yet? How do we make sure that our teams focus on building the most important thing right now? This talk will give you the tools you need to understand Cost of Delay, as well as a set of techniques, from simple proxies to more sophisticated real-dollar analyses to help you understand the impact of delays on your organization.
In this presentation, I talk of Donald Reinstern's original idea of quantifying using Money units per time unit. However, the Agile world has been comprised a bit by using Fibonacci series or a scale of 1 to 10. Are we compromising the original intent of the author?
A retrospective looking at the implementation of Cost of Delay as a means to improve decision-making, improve the sense of urgency and encourage the breaking down of work as well as scheduling or prioritisation using CD3.
Ever wonder why Agile teams swear by relative estimation? My teams improved sprint planning efforts by a factor or 3, once we started using relative estimation.
Without understanding Agile relative estimation, teams tend to fall back to using time-based methods. This often leads them to spend way too much time on obsolete estimates that will be made even more complex with all the unknowns and constant emergent requirements of an Agile world!
“It's better to be roughly right, than precisely wrong!”
~ John Maynard Keyenes
The Solution is simple: understand that relative estimation is only a rough order of magnitude estimate to quickly organize the product backlog. This empowers your product owners (PO) to quickly make value based trade-offs on backlog items and decide on what stories the team should work next. This gives the business the highest bang for their buck!
PROBLEMS WITH TIME-BASED ESTIMATES
-Teams spend too much time trying to get it right
-Lack of confidence/experience can lead to people being either optimistic or pessimistic
-Timeline you are estimating may be too far in the future
-Due to long timeline, there are too many risks, unknowns, changes or dependencies!
WHY USE RELATIVE ESTIMATION?
-Allows a quick comparison of stories in the backlog
-Allows you to select a predictable volume of work to do in a sprint
-Uses a simple arbitrary scale
-Allows PO to make trade-offs and take on the most valuable stories next
ESTIMATION TIPS
-Relative points or equivalent Tshirt sizes are used to estimate stories, leveraging the Fibonacci sequence modified for Agile.
-The team estimates the story, not management nor the customer.
-Story estimates account for three things: effort, complexity, and unknowns. Don’t short sell yourself by estimating effort alone, that’s where waterfall projects face issues.
-Remember to estimate all Stories, user stories or technical stories. Even estimate research or discovery spikes.
-Refine your backlog as a team on a continuous basis, to get your stories to meet the Definition of Ready.
-Only pull into your sprint, stories that are refined and estimated.
-Break down stories that are large, into smaller slivers of value to optimize your flow.
-Don’t sweat it if you get it wrong, teams often do early on but improve over time.
Build Your Own Value Stream Map by Paul J. Heidema and Junbin HuangPaul J. Heidema
A workshop session facilitated by Paul J. Heidema and Junbin Huang at the Toronto Agile Community 2016 conference. It comprised of: what is a value stream, how to build a value stream map, hands-on exercise of building a value stream map in a small group, and debriefing at the end in a large group.
Agile is a philosophy for delivering solutions that embraces and promotes evolutionary change throughout the life-cycle of a product. Many teams and organizations have been using Agile to, deliver software more timely, increase quality, and ultimately increase customer satisfaction.
These planning levels were originally described by Hubert Smits in the whitepaper "5 Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up".
Brief, but descriptive tutorial of the Scaled Agile Framework (SAFe) 4.5. Starts with impetus for agility, overview of lean and agile thinking, definition of portfolio management, explanation of SAFe and its values and principles, etc. Then, provides a level-by-level overview of SAFe, including case studies, metrics, business case, adoption statistics, roles, responsibilities, and other considerations. Closes with a nice summary of key SAFe implementation principles ...
XBOSoft runs through the Top 10 Agile Metrics revealing the most fundamental data points Agile methodology requires to work effectively, and will put you on the highly targeted path to successful implementation of your Agile processes.
XBOSoft and Go2Group run through the top data points you should be measuring in your Agile Workflow. We’ll show you what to track, when and how often, and most importantly – why. Many believe that metrics are useless, but unless you measure, how can you systematically improve or know how you are doing? And with velocity as an overarching objective in agile, you should be tracking other things so that you know what else you could be impacting by going faster. But, with all the metrics so readily available to us today, how do we filter through to the most meaningful?
modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches.
Modern agile methods are defined by four guiding principles:
- Make people awesome
- Make safety a prerequisite
- Experiment & learn rapidly
- Deliver value continuously
The Product Management Vacuum and the 3 V'sDon McGreal
In between the larger organizational goals and the day-to-day work of Development Teams, exists a vacuum. The thing about any vacuum is that it has an innate need to be filled. If we are not careful, this 'Product Management Vacuum' will get filled with meaningless busy work and extensive task management. Being busy without clear direction.
This session introduces the 3 V's -- Vision, Value, Validation -- as a way to get out in front of this problem.
Lean Enterprise Transformation: The Journey Inside Large Organizations, Sonja...Lean Startup Co.
Large enterprises facing disruption struggle to transform quickly enough—from becoming more innovative to improving processes, culture, and ways of working. Transformation programs are often linear, multi-year engagements not focused on continuous learning and improvement. In this workshop, Sonja Kresojevic will share lessons learned from an award-winning Lean Enterprise transformation program at Pearson that will enable you to kick off and significantly accelerate your own organization's Lean Enterprise journey. She will uncover how proven approaches embodied in Lean Startup, Agile, and Adaptive Portfolio Management can be combined into a single cohesive framework that can serve as catalyst for powerful shifts in your organization.You will leave the workshop with an example of transformation roadmap ready to stimulate wide-ranging conversations and drive focused action, as soon as you return to your office.
20150808 tune into signals @ scrum day chile 2015César Idrovo
Changing our mindset and our practices to Agile, and specifically Scrum, can be quite a shock to the system. Is the organization ready for this change? In this workshop we look for the leadership and management signals that are present, that shouldn't be, and that might be completely missing. They can all influence our chances of success and we need to be tuned to them.
These slides were presented at ScrumDay Chile 2015.
Build Your Own Value Stream Map by Paul J. Heidema and Junbin HuangPaul J. Heidema
A workshop session facilitated by Paul J. Heidema and Junbin Huang at the Toronto Agile Community 2016 conference. It comprised of: what is a value stream, how to build a value stream map, hands-on exercise of building a value stream map in a small group, and debriefing at the end in a large group.
Agile is a philosophy for delivering solutions that embraces and promotes evolutionary change throughout the life-cycle of a product. Many teams and organizations have been using Agile to, deliver software more timely, increase quality, and ultimately increase customer satisfaction.
These planning levels were originally described by Hubert Smits in the whitepaper "5 Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up".
Brief, but descriptive tutorial of the Scaled Agile Framework (SAFe) 4.5. Starts with impetus for agility, overview of lean and agile thinking, definition of portfolio management, explanation of SAFe and its values and principles, etc. Then, provides a level-by-level overview of SAFe, including case studies, metrics, business case, adoption statistics, roles, responsibilities, and other considerations. Closes with a nice summary of key SAFe implementation principles ...
XBOSoft runs through the Top 10 Agile Metrics revealing the most fundamental data points Agile methodology requires to work effectively, and will put you on the highly targeted path to successful implementation of your Agile processes.
XBOSoft and Go2Group run through the top data points you should be measuring in your Agile Workflow. We’ll show you what to track, when and how often, and most importantly – why. Many believe that metrics are useless, but unless you measure, how can you systematically improve or know how you are doing? And with velocity as an overarching objective in agile, you should be tracking other things so that you know what else you could be impacting by going faster. But, with all the metrics so readily available to us today, how do we filter through to the most meaningful?
modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches.
Modern agile methods are defined by four guiding principles:
- Make people awesome
- Make safety a prerequisite
- Experiment & learn rapidly
- Deliver value continuously
The Product Management Vacuum and the 3 V'sDon McGreal
In between the larger organizational goals and the day-to-day work of Development Teams, exists a vacuum. The thing about any vacuum is that it has an innate need to be filled. If we are not careful, this 'Product Management Vacuum' will get filled with meaningless busy work and extensive task management. Being busy without clear direction.
This session introduces the 3 V's -- Vision, Value, Validation -- as a way to get out in front of this problem.
Lean Enterprise Transformation: The Journey Inside Large Organizations, Sonja...Lean Startup Co.
Large enterprises facing disruption struggle to transform quickly enough—from becoming more innovative to improving processes, culture, and ways of working. Transformation programs are often linear, multi-year engagements not focused on continuous learning and improvement. In this workshop, Sonja Kresojevic will share lessons learned from an award-winning Lean Enterprise transformation program at Pearson that will enable you to kick off and significantly accelerate your own organization's Lean Enterprise journey. She will uncover how proven approaches embodied in Lean Startup, Agile, and Adaptive Portfolio Management can be combined into a single cohesive framework that can serve as catalyst for powerful shifts in your organization.You will leave the workshop with an example of transformation roadmap ready to stimulate wide-ranging conversations and drive focused action, as soon as you return to your office.
20150808 tune into signals @ scrum day chile 2015César Idrovo
Changing our mindset and our practices to Agile, and specifically Scrum, can be quite a shock to the system. Is the organization ready for this change? In this workshop we look for the leadership and management signals that are present, that shouldn't be, and that might be completely missing. They can all influence our chances of success and we need to be tuned to them.
These slides were presented at ScrumDay Chile 2015.
What's the State of Agile Software Development?VersionOne
VersionOne’s 9th annual State of Agile survey is the ONLY agile survey with nine years of historical data from thousands of respondents every year. Go to www.stateofagile.com to download the full survey for insights on how to measure agile success, top tips for scaling agile, and much more.
DOES16 London - Pat Reed - Mind the GAAP: A Playbook for Agile AccountingGene Kim
Mind the GAAP: A Playbook for Agile Accounting
Pat Reed, Principal Consultant, iHoriz Inc.
With disruptive technology advances, software assets play an increasingly important role in creating competitive advantage through effectively managing business software assets.
As organizations leverage agile practices to deliver better customer value faster, they consistently fall into process traps that block success because agile labor cost accounting is misunderstood and misreported, impacting taxation, higher volatility in Profit and Loss (P&L) statements, and sometimes even dramatic, unnecessary staff cuts in an economy where talent retention is vital to innovation.
This session shares a practical playbook to avoid common pitfalls and gain awareness of what you can do to evolve accounting and reporting practices to leverage the financial advantage of agile and benefit from the significantly increased tax savings and bottomline benefits available with agile capitalization.
This session will unravel the pitfalls and benefits of agile capitalization and explain how to appropriately interpret and apply generally accepted accounting standard (GAAP SOP 98-1 and ASC 350-40) so your organization can increase its agile adoption to deliver more business value faster to customers.
DevOps Enterprise Summit London 2016
Using Cost of Delay to de-scale your organisation through decentralised decis...Michael Fagan
It isn’t enough to break down our portfolio into small pieces and execute them in isolation from one another. We must acknowledge that variance in knowledge work is a fact of life, specialists are scarce, people find new jobs, life happens. Rather than think of an organisation as individual parts to be managed, think of it as a living organism which adapts and responds as a whole.
By empowering people to take decisions based on objective data linked to a shared vision people are not simply playing a game according to a set of rules, they are responsible for the game.
Don Reinertsen in his seminal book "The Principles of Product Development Flow" states:
"If you only quantify one thing, quantify the Cost of Delay. "
In this talk I will present how the Cost of Delay can be derived from data your organisation has lying around how you can super charge decision making speed and consequently the flow of value.
“A dead ScrumMaster is a useless ScrumMaster,” echo the votary of Ken Schwaber (Co-Founder of Scrum) folklore. In this session hosted by Pat Reed (Agile Alliance Board Member) and Laszlo Szalvay (Executive at SolutionsIQ) we will explore how and why the accounting department needs to be your biggest champion as you embark on your next agile transformation. Pat and Laszlo will walk through concrete steps and real world examples of how capitalization works with Scrum and what you need to tell the accountants so they don’t shoot you. So don’t end up a dead ScrumMaster.
BizFlow - BPM at Jardine Lloyd Thompson for Sales, Document Handling, Custome...Garth Knudson
As far back as 2004, JLT EB started using business process management (BPM) to streamline a limited set of business operations. Use was confined to about 30 people in a “model office”. During that same time period, JLT acquired Profund, a leading provider of pension administration software in the UK. Customers included both in-house and third-party administrators. Profund had seen opportunities to expand its pension fund administration solutions into specific areas of process automation while helping customers to simplify the overall user experience. Deciding to use the current BPM tool, the company developed outward facing solutions that rolled out to end customers in 2007. BPM usage at JLT EB and Profund grew to about 300 users.
Between 2007-2010, JLT made more than 20 acquisitions globally across the group. JLT EB operations quickly became highly complex, distributed and paper-based. Employees were handling millions of documents annually covering Pension Administration, Payroll, Defined Contributions, Actuarial, Health and Risk, among other requests. Processes treated more than 16 million workflow elements, 300+ million rows of table data and 15 million SharePoint documents. The BPM solution covers 14 active offices in Europe and India, off-shoring and massive amounts of regulations. The company knew that in order to continuing growing at the same speed while containing costs, it would have to do more with less.
JLT EB accomplished its goals of increased revenues with lower costs with continual investment in BPM. JLT EB has worked with BizFlow and used the BizFlow BPM software to streamline >200 processes. From an ROI standpoint, this work has provided a key business component, contributing to JLT EB’s growth in trading profit by 50% in the last financial year. Revenue growth is enabled by more flexible solutions that can be highly tailored to internal client needs as well as end-customer engagements. Cost cutting is enabled through the use of process automation tied together with effective scanning, document handling and rule-based routing. Paper is largely removed, deadlines hit, and governance accomplished.
Benefits of Lean IT and it's importance.
The world is a merry-go-round and you can't get off. Customers are becoming more demanding, markets are becoming more customised, and product life-cycles that are getting shorter are just a few of the reasons why Lean could be important to you. As the demands on our processes increase they evolve and adapt accordingly which often results in processes that end up inefficient and wasteful. Lean is about challenging the way things are done and opening our eyes to that waste and inefficiency. The environment in which an organization operates will continue to change; Lean can help organizations meet the challenge.
Lean can provide an organization with a clear competitive advantage since the correct application of the Lean principles will realise substantial benefits that include:
- Greater productivity
- Greater throughput
- Improved quality
- Reduced cycle times
- Less fire-fighting
- Smoother operation
- Reduced operating costs
CTE Solutions' preferred Lean IT training provider Snowdon Consulting gave this amazing presentation in our Toronto Office on April 25th, 2014. Click the below link to get a copy of the presentation used during this seminar.
http://blog.ctesolutions.com/management/enterprise-architecture/understanding-lean-it/
Do you have an OEE calculator? TBM Operations consultants share their framework for demonstrating process improvements in financial terms so you can convince senior management that OEE improvement should be a top priority in 2022.
Value Driven Development by Dave Thomas Naresh Jain
Agile, OOP... are like good hygiene in the kitchen, it results in meals with consistent quality and predictable prep and service times. It doesn't result in great meals nor substantially impact the ROI! Lean Thinking clearly shows that the only way to make a significant impact is to improve the value chain by improving flow. If everyone is following best practices no one has competitive advantage. Major improvements in the value chain depend on continued disruptive innovations. Innovations leverage people and their ideas. We use case studies to illustrate the different business and technical innovations and their impact. We conclude with a discussion of how to build and leverage an innovation culture versus a sprint death march when dealing with high value time to market projects.
More details: https://confengine.com/agile-india-2017/proposal/3608/value-driven-development-maximum-impact-maximum-speed
Similar to XP Day: Using cost of delay – Joshua Arnold (20)
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
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?
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
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
63.
64. SOA Project Team: Problem
statements for validation, evaluation
and prioritisation using CoD & CD3
65.
66.
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
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
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.