116
edits
Flow metrics: Difference between revisions
Jump to navigation
Jump to search
→Throughput: clarify derived values
No edit summary |
(→Throughput: clarify derived values) |
||
| (18 intermediate revisions by the same user not shown) | |||
| Line 9: | Line 9: | ||
'''Inventory-Euro-Days (IED)''' | '''Inventory-Euro-Days (IED)''' | ||
Effectiveness is calculated in Inventory | Effectiveness is calculated in Inventory Euro-Days. | ||
* Calculated as: | * Calculated as: Euro value of inventory × Number of days held | ||
* Example: If $100,000 worth of products sits in warehouse for 30 days, this creates 3,000,000 inventory- | * Example: If $100,000 worth of products sits in warehouse for 30 days, this creates 3,000,000 inventory-euro-days | ||
* Lower IDD indicates higher effectiveness. The ultimate goal would be 0 IDD. | * Lower IDD indicates higher effectiveness. The ultimate goal would be 0 IDD. | ||
Because almost all of our work is being done by people on laptops, we calculate the inventory based on the hours invested into a project, times an hourly rate. The hourly is set in advance and can vary per person. The primary determinant of your hourly rate is your experience level, as we generally expect a senior engineer to be more productive than a junior engineer, and thus their work to lock up greater value while sitting on the shelf. This implicitly means it becomes more important to get your work into production faster, as you gain more experience. | |||
==Reliability== | ==Reliability== | ||
Reliability measures commitments fulfilled to the external world, particularly focusing on timely delivery. | Reliability measures commitments fulfilled to the external world, particularly focusing on timely delivery. Once work is past the deadline and has not been delivered, we count the value of that work in the reliability metric. | ||
'''Throughput-Euro-Days (TED)''' | '''Throughput-Euro-Days (TED)''' | ||
* Calculated as: Value of late orders × Number of days late | * Calculated as: Value of late orders × Number of days late | ||
* Example: A $50,000 order delivered 5 days late results in 250,000 throughput- | * Example: A $50,000 order delivered 5 days late results in 250,000 throughput-euro-days | ||
* Lower TDD indicates higher reliability. The ultimate goal here too, is 0. | * Lower TDD indicates higher reliability. The ultimate goal here too, is 0. | ||
| Line 40: | Line 42: | ||
* Average revenue, trailing four quarters. | * Average revenue, trailing four quarters. | ||
In essence, these all measure the same thing; in theory, only the daily revenue matters. As we are a smaller company, though, we don't send hundreds of invoices per year or get invoices paid to us every working day. For example, we could get 1.000 on Monday, nothing on Tuesday, and 3.000 on Wednesday. That doesn't necessarily imply that Monday was a good day, Wednesday was a great day, and that we failed in our work on Tuesday. | |||
Effectiveness and Reliability go up and down each day in semi-predictable amounts because they mostly directly result from the work you're doing and not doing as a team. But Throughput can be very "spiky". That makes graphs harder to read and interpret. We use the revenue per quarter and average four quarters trailing revenue to smooth out the graphs. | |||
=A sidenote on quality= | =A sidenote on quality= | ||
| Line 59: | Line 63: | ||
|- | |- | ||
! Day !! Effectiveness (€D) !! Reliability (€D) !! Throughput (€) | ! Day !! Effectiveness (€D) !! Reliability (€D) !! Throughput (€) | ||
|- | |- style="text-align:right;" | ||
| 1 || 1.000 || 0 || 0 | | 1 || 1.000 || 0 || 0 | ||
|- | |- style="text-align:right;" | ||
| 2 || 2.000 || 0 || 0 | | 2 || 2.000 || 0 || 0 | ||
|- | |- style="text-align:right;" | ||
| 3 || 3.000 || 0 || 0 | | 3 || 3.000 || 0 || 0 | ||
|- | |- style="text-align:right;" | ||
| 4 || 0 || 0 || 3.000 | | 4 || 0 || 0 || 3.000 | ||
|- | |- style="text-align:right;" | ||
| 5 || 0 || 0 || 0 | | 5 || 0 || 0 || 0 | ||
|- | |- | ||
| Line 74: | Line 78: | ||
== Late delivery == | == Late delivery == | ||
We sign a new customer for a project that is expected to take 3 days of work and be billed at 1.000 € per day. The customer agrees with the fixed-price quote we give her. However, we think the project will take us 2 days, so we decide to start the work on day 2. | We sign a new customer for a project that is expected to take 3 days of work and be billed at 1.000 € per day. The customer agrees with the fixed-price quote we give her. However, we think the project will take us 2 days, so we decide to start the work on day 2. | ||
(Note: this is a rational decision because it results in lower effectiveness. You can do that math yourself and see that starting work earlier than strictly results in worse (higher) effectiveness.) | |||
It turns out we were wrong and the work actually takes us 4 days to deliver. The customer is slightly upset, but they added a little buffer for this possibility so they can still use the work. We send the invoice on day 5 and the customer pays the invoice on day 7. | It turns out we were wrong and the work actually takes us 4 days to deliver. The customer is slightly upset, but they added a little buffer for this possibility so they can still use the work. We send the invoice on day 5 and the customer pays the invoice on day 7. | ||
| Line 81: | Line 87: | ||
|- | |- | ||
! Day !! Effectiveness (€D) !! Reliability (€D) !! Throughput (€) | ! Day !! Effectiveness (€D) !! Reliability (€D) !! Throughput (€) | ||
|- | |- style="text-align:right;" | ||
| 1 || 0 || 0 || 0 | | 1 || 0 || 0 || 0 | ||
|- | |- style="text-align:right;" | ||
| 2 || 1.000 || 0 || 0 | | 2 || 1.000 || 0 || 0 | ||
|- | |- style="text-align:right;" | ||
| 3 || 2.000 || 0 || 0 | | 3 || 2.000 || 0 || 0 | ||
|- | |- style="text-align:right;" | ||
| 4 || 3.000 || | | 4 || 3.000 || 3.000 || 0 | ||
|- | |- style="text-align:right;" | ||
| 5 || 4.000 || | | 5 || 4.000 || 6.000 || 0 | ||
|- | |- style="text-align:right;" | ||
| 6 || 4.000 || | | 6 || 4.000 || 9.000 || 0 | ||
|- | |- style="text-align:right;" | ||
| 7 || 0 || 0 || 3.000 | | 7 || 0 || 0 || 3.000 | ||
|- | |- style="text-align:right;" | ||
| 8 || 0 || 0 || 0 | | 8 || 0 || 0 || 0 | ||
|- style="text-align:right;" | |||
|} | |||
== Cancellation == | |||
We sign a new customer for a project that is expected to take 3 days of work and be billed at 1.000 € per day. The customer needs this work on day 4 because their annual trade show is on day 4. We agree to a contract for guaranteed delivery on day 4 at the latest. We think the project will take us 2 days. We decide to start the work on day 1 because we want a buffer for if we're wrong about the estimate. | |||
It turns out we were very wrong, and the work actually takes us 5 days to deliver. The customer sends us a very angry email, explaining they will never work with us again. As per the contract, the customer does not pay for the work. | |||
(Note: this scenario presumes that we do not stop work on the project once it becomes apparent that it cannot be finished in time. In real-world scenarios, you would stop work once it becomes useless; but you would also generally apply much larger buffers.) | |||
{| class="wikitable" | |||
|+ The metrics behave as follows | |||
|- | |- | ||
! Day !! Effectiveness (€D) !! Reliability (€D) !! Throughput (€) | |||
|- style="text-align:right;" | |||
| 1 || 1.000 || 0 || 0 | |||
|- style="text-align:right;" | |||
| 2 || 2.000 || 0 || 0 | |||
|- style="text-align:right;" | |||
| 3 || 3.000 || 0 || 0 | |||
|- style="text-align:right;" | |||
| 4 || 4.000 || 3.000 || 0 | |||
|- style="text-align:right;" | |||
| 5 || 5.000 || 6.000 || 0 | |||
|- style="text-align:right;" | |||
| 6 || 0 || 0 || 0 | |||
|- style="text-align:right;" | |||
|} | |} | ||
= | =Observations on the metrics= | ||
These three metrics are interconnected: | These three metrics are interconnected: | ||
| Line 108: | Line 138: | ||
* Strong reliability (low TDD) enables consistent delivery and higher customer satisfaction. | * Strong reliability (low TDD) enables consistent delivery and higher customer satisfaction. | ||
* Improved throughput often requires balancing effectiveness and reliability | * Improved throughput often requires balancing effectiveness and reliability | ||
Numerically: | |||
* After the deadline, reliability behaves roughly as the first-order integral of the current effectiveness value. | |||
* Effectiveness and Reliability are measured in euro-days and go up quite rapidly over time. Values in the millions of euro-days are not uncommon. That doesn't mean you're making millions of euros in throughput, though! | |||
= See Also = | = See Also = | ||
| Line 117: | Line 151: | ||
= Further reading = | = Further reading = | ||
* [https://flowchainsensei.wordpress.com/2018/03/06/reliability-and-effectiveness/ Effectiveness Framework, Bob Marshall] | * [https://flowchainsensei.wordpress.com/2018/03/06/reliability-and-effectiveness/ Effectiveness Framework, Bob Marshall] | ||
* [https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/ The Phoenix Project, Gene Kim] | |||
* [https://www.amazon.com/Unicorn-Project-Developers-Disruption-Thriving/dp/1942788762/ The Unicorn Project, Gene Kim] | |||
* [https://www.amazon.nl/-/en/Eliyahu-M-Goldratt/dp/0884271951 The Goal, Eliyahu M Goldratt] | * [https://www.amazon.nl/-/en/Eliyahu-M-Goldratt/dp/0884271951 The Goal, Eliyahu M Goldratt] | ||
* [https://www.amazon.nl/-/en/Eliyahu-M-Goldratt/dp/0884271668 Theory of Constraint, Eliyahu M Goldratt] | * [https://www.amazon.nl/-/en/Eliyahu-M-Goldratt/dp/0884271668 Theory of Constraint, Eliyahu M Goldratt] | ||
* [https://www.amazon.com/Beyond-Goal-Eliyahu-M-Goldratt-audiobook/dp/B000ELJ9NO Beyond the Goal, Eliyahu M Goldratt] | * [https://www.amazon.com/Beyond-Goal-Eliyahu-M-Goldratt-audiobook/dp/B000ELJ9NO Beyond the Goal, Eliyahu M Goldratt] | ||