Little’s Law for Product Development

This entry is part 7 of 21 in the series queueing theory

This post is part of a series on Queueing Theory. The other articles can be found here:

  1. Queueing Theory: Part 1
  2. Queueing Theory: Part 2
  3. Queueing Theory: Part 3
  4. Queueing Theory: Part 4
  5. What is Waste?
  6. On Time-Traps and Waste
  7. Call Centers as Queueing Systems
  8. Travel Time & Waste
  9. Little’s Law for Product Development

A queueing system is a model with the following structure: customers arrive and join a queue to wait for service given by n servers. After receiving service, the customer exits the system. A fundamental result of queueing theory is little’s law.

Theorem: for a queueing system in steady state, the average length of the queue is equivalent to the average arrival rate multiplied by the average waiting time. in other words,

L = λW

Little’s Law is a fundamental principle in business, mathematics, and has applications to many real-world problems. One of those real-world problems is in product development.

First, a definition:

For product development, we can use a transformation of Little’s Law, like the following:

[(Throughput) = (Things-in-Process) / (Average Completion Rate)]

What this equation tells us and what experience has shown time-after-time, is that the number one driver of Product Development Cycle Time are the “things-in-process”. There is no quicker way to reduce the cycle time by which your company can get a product from concept-to-delivery than through first prioritizing all the projects or products and focusing on the ones that make strategic and tactical sense, and killing the lower priority projects.

You might be thinking: “True, but couldn’t we also increase the average completion rate”? You’re right, but the impact of doing that is much lower than reducing the TIP — that is, influencing the average completion rate is rather difficult and is often a function of available resources, scope creep, market demands and changes, etc. Here’s the bottom line: the number one driver for shipping products quicker is by focusing on the important ones and killing the unimportant ones.

Product (Project) Selection Prioritization Matrix

One easy but effective way or prioritizing a list of projects or products is to group-rank them based on variables. Below is an example of a prioritization matrix that I’ve used in the past:

shmula.com, prioritization matrix, queueing theory

Here are some general steps:

  1. List all the projects/products
  2. As a group of core stakeholders and decision-makers, agree on a selection criteria, or list of variables on which to judge each item on the list.
  3. As a group, score each item against each variable. Use a likert scale that makes sense.
  4. Multiply the various scores across to get an overall score.
  5. Rank the projects and sort from highest overall score to the lowest. Then, review to see if the ranking makes sense.
  6. If done right, then the important initiatives rise to the top and the unimportant ones fall to the bottom.
  7. Decide as a group, based on available resources and strategy, where the cut-off score will be. Cut, then discard the items below that score and focus on the ones above that score. I don’t suggest you table or postpone items below the cut-off, because realistically they will be discarded.

Conclusion

To drive throughput, you can influence the size of WIP/TIP or increase the average completion rate. A balanced approach is good, but you’ll gain a higher yield by focusing on reducing WIP/TIP. In order to do that, you must decide as an organization what to focus on — on items that will bring the biggest return to your customer, shareholders, and the company.

Series Navigation«Queueing Theory: Part 3Psychology of Queueing & Build-A-Bear Workshop»

Short URL: http://bit.ly/14bGx

Share This Post:



  • Digg
  • Facebook
  • del.icio.us
  • Suggest to Techmeme via Twitter
  • StumbleUpon
  • LinkedIn
  • email

2-pizza teams (10)
3 C's (3)
5S (38)
A3 Report (9)
adoption (7)
agile/software (59)
ajax (4)
amazon (53)
apple (3)
apple iphone (7)
axiom (3)
Aza Raskin (9)
backcountry.com (2)
berlin (1)
bill gates (1)
bill marriott (1)
blog tag (1)
book reviews (4)
bullwhip effect (5)
business (394)
business plans (3)
busm361 (13)
BzzAgent (12)
call center and queueing (11)
car buying (2)
Carbonite (1)
change management (5)
chicago (1)
click fraud (1)
click-to-ship (21)
clocky (2)
colin powell (2)
community (2)
company interviews (18)
company interviews (6)
complexity (32)
costs (8)
culture (7)
customer experience (10)
customer obsession (52)
customer recovery function (1)
customer segmentation (8)
customer service (17)
design thinking (14)
digg (4)
drum-buffer-rope (38)
dublin (1)
dynamic systems (24)
eBay (6)
economics (3)
efficiency (4)
ethnography (29)
family (18)
featuritis (15)
flexibility (1)
forecasting (2)
four performance dimensions (2)
Fun With The 2×2 Matrix (1)
game theory (7)
Gemba (67)
genchi genbutsu (68)
general (135)
germany (1)
google (15)
heijunka (65)
holidays (1)
hoshin kanri (1)
how to be a human (1)
IDEO (2)
image uploading (1)
iphone (5)
ishikawa (69)
IT at Toyota (67)
just-in-time (4)
kaizen (4)
kanban (46)
law of instinct (1)
Leadership (43)
lean (165)
Lean Consumption Maps (98)
learning curve (1)
licketyship (1)
mark cuban (1)
martin luther king (1)
mary poppendieck (1)
metrics (73)
microsoft (6)
milton friedman (1)
moving average (1)
muda (68)
nba fines (1)
net promoter score (nps) (1)
obeya (39)
Off-Topic (1)
onstar (1)
operations (108)
pageviews (3)
pareto principle (39)
patent (1)
peanut butter manifesto (2)
philosophy (3)
Poka-Yoke (6)
poppendieck (3)
powerpoint sucks (2)
private equity (4)
process measures (6)
product development (20)
productivity (4)
quality (41)
quasimodal design (1)
queueing theory (41)
Raffle (1)
rational choice (2)
regression analysis (18)
respect for people (6)
root cause analysis (60)
sarah+palin (2)
seth godin (1)
simplicity principle (10)
six sigma (128)
snowboarding (2)
social media (3)
spam (1)
statistical process control (46)
strategy (46)
suburban (1)
supply chain (24)
takt time (8)
teaching (2)
team size (9)
technology (104)
the beer distribution game (1)
the profit tree (7)
The Visual Factory (11)
theory of constraints (41)
time (2)
timeline (3)
tony+hsieh (11)
toyota (75)
travel (1)
trump bankruptcy (1)
turnaround (5)
twitter (8)
uspto (1)
utah deal flow (2)
variation (69)
venture capital (1)
Visual Management (11)
waste (59)
website traffic (2)
Wing Chun (2)
wisdom of crowds (1)
wisdom teeth (1)
word-of-mouth marketing (18)
yahoo (2)
zappos.com (12)
zero defects (3)

WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.


If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

Comments

I posted an item on my blog about Little’s Law in the hospital:

http://kanban.blogspot.com/200.....pital.html

[...] Little’s Law for Product D… [...]

[...] shmula » Little’s Law for Product Development : Business, Technology, and Stuff in Between (tags: lean little law) [...]

[...] Little’s Law for Product Development [...]

best way to increase software dev productivity? do only the most important ones: http://tinyurl.com/y9xmgo

Leave a comment

(required)

(required)


Additional comments powered by BackType