Differences

This shows you the differences between two versions of the page.

--- what_is_wrong_with_100_utilization_thinking [2016/03/30 09:14] – [Now What Are You Going To Do?] hpsamios
+++ what_is_wrong_with_100_utilization_thinking [2020/06/04 11:19] (current) – Removed LINKBACK hans
@@ Line 1: / Line 1: @@
 ====== What Is Wrong With 100% Utilization Thinking? ======
-====== Premise ======
 As a person who has spent way too many years managing many projects, working with a lot of financial people, and who has worked to improve the results of a lot of organizations, one thing I was expected to focus on was "utilization rates" for people. The thinking seems straight-forward - if we are paying a certain amount of money for a person we can increase the return (value produced) associated with that person by making sure, at a minimum, that the person is working all the time and is always busy. As result I'd work to ensure that people were 90%, 100% utilized and be happy when people reported 110% utilization.
@@ Line 9: / Line 6: @@
 ====== Understanding Real Cause and Effect of Utilization ======
-I want you to have a look at the following chart:
+{{ :cycle_time_vs_utilization_rates.jpg?500 |}}
-{{ :cycle_time_vs_utilization_rates.jpg?600 |}}
+I want you to have a look at the chart((this version of chart results come from [[the_principles_of_product_development_flow_second_generation_lean_product_development_-_don_reinertsen|The Principles of Product Development Flow: Second Generation Lean Product Development - Don Reinertsen]] which was originally from the Kingsman Formula, although it has been liberally interpreted to aid in understanding.)):
 This is what actually happens when you increase the utilization rate beyond a certain threshold. Basically it says that "as we approach 100% utilization the time it takes to process something becomes exponentially large." This is an application of "queuing theory". It turns out that every time you halve the amount of excess capacity, you double the time it takes to process something. So as you move from 60% to 80% utilization you double the time it takes to process something, and moving from 80% to 90% will double it again.
 What does this say about loading up a person's work to 100% utilization? Basically if you are focussing on utilization rates there will come a point when you are valuing someone being "busy" over someone producing something in a timely manner.
+Interestingly you instinctively understand this effect even if you have not applied this to software. If you have a road system filled to capacity with cars and you are a car trying to get from point "A" to point "B" what are your chances? A "road system filled to capacity" is a traffic jam and so you will take a long time to get to your location.
 ====== Now What Are You Going To Do? ======
@@ Line 29: / Line 28: @@
 The first step along the way is education. People need to be made aware of the problem. Then we can start working the issue. There are lots of approaches we can take (for example, reducing the amount of work we have in progress thereby also increasing the focus we have on high priority work), but the first step is to make this thinking clear to all. If you have an organization that "believes" high utilization rates are required for success, then you have a problem until that view can be changed.
-Once you have this in place queuing theory gives us six rules for reducing software development cycle time:
+Once you have this in place queuing theory gives us six rules for reducing software development cycle time ((List of things you can do comes from [[http://www.leanessays.com/2010/11/managing-pipeline.html|"Managing the Pipeline" by Mary Poppendieck]])):
   - Limit work to capacity (don't try to take on too much at a time)
-  - Even out the arrival of work
+  - Even out the arrival of work (budgeting, approval and contracting processes tend to mean arrival of work is in big lumps and not even)
   - Minimize the number of things-in-process (work-in-progress, or WIP)
   - Minimize the size of the things-in-process (small batch sizes - see [[What is the Effect of Batch Size on How Long Something Takes to Get Done]])
-  - Establish a regular cadence
+  - Establish a regular cadence (establishes a predictable workflow and a reliable pace, allows for faster feedback and for staged delivery)
   - Use pull scheduling
 ====== Want to Know More? ======
   * [[http://www.amazon.com/gp/product/0767907698?keywords=slack&qid=1455823504&ref_=sr_1_1&sr=8-1|"Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency"]] by Tom DeMarco. Discussion about the counterintuitive principle that explains why efficiency efforts can slow a company down. Fights against the concept that, for example, 100% utilization of people is the most efficient way to get something done.
+  * [[http://www.leanessays.com/2010/11/managing-pipeline.html|"Managing the Pipeline"]] by Mary Poppendieck. Mary is one of the original thinkers in the are of lean principles applied to software development. Her essays are always useful and get more useful as you need to grow your implementation of agile and lean to the overall organization.
   * [[http://brodzinski.com/2015/01/slack-time-value.html|Economic Value of Slack Time]]
+  * [[https://observablehq.com/@troymagennis/how-does-utilization-impact-lead-time-of-work?collection=@troymagennis/agile-software-development|How Does Utilization Impact Lead Time of Work]]: Excellent interactive model by @TroyMagennis allowing you to explore different how the Kingman formula works.
   * [[http://brodzinski.com/2012/03/myth-of-100-utilization.html|A Myth of 100% Utilization]]
-Note: Results come from [[the_principles_of_product_development_flow_second_generation_lean_product_development_-_don_reinertsen|The Principles of Product Development Flow: Second Generation Lean Product Development - Don Reinertsen]]
 {{tag>Enterprise Utilization Slack Risk RiskManagement FAQ PresentationIdea}}