Direkt zum Hauptbereich

Measuring time efficiency in projects

We commonly rate a project’s success based on whether it is on time and in budget. But, as common as these KPIs are, they may not be good measures. As Jan Fischbach has shown, delays and budget overruns can look like project failure even though the benefits vastly exceed the costs and vastly outmatch the benefits of an on-time project./1/ Furthermore, a project can be on time, but lousy at using the available time efficiently. Isn’t something wrong when a project only requires small total effort, but takes months to finish?


Fortunately, there is a simple way to measure the time efficiency of projects. I’ll call this indicator “project duration efficiency” (PDE), which compares effort (hours or days worked) with duration (calendar time)./2/

In an ideal world, all effort would flow seamlessly from task to task, and in optimally matched, parallel streams. Thus, the project duration would be the sum of the effort of one stream: 20 days invested by 3 persons each of would result in a finished product in 20 days’ time (and a total effort of 60 person days). Put another way, every hour spent on the project contributed productively to the product’s creation. This utopia would look like this:


The PDE is a simple calculation:
PDE = normalized effort /  duration

To keep the results comparable, we normalize the effort by dividing the number of people involved by the total effort./3/ A project with 6 persons working a total of 120 person days would have a normalized effort of 20 days. If this project takes 8 weeks (40 workdays) in duration to complete, its PDE equals 20/40 or 0.5. It might look like this:

So, the final, full equation would be:
PDE = (total effort / number of people working on project) / duration

The best possible result is 1, although this value is rare.

Why is this KPI important? It shows us how efficiently we are using calendar time for delivering our results. It is based on the premise “fast delivery means early benefits”. PDE thus helps us see the cost of delay (CoD) in a project. CoD occurs when we deliver a project’s results later than they could have been delivered. It is equal to the benefits we forego by not having the product on the market. For example, a company is developing an innovative widget. If it forecasts selling €10,000 worth of new widgets each day, then each day that the project is late incurs a CoD of €10,000./4/

In the project example above, the “possible completion” date is the point at which we could have started reaping the benefits if the work had been organized to eliminate the gray days. I am aware that this ideal situation will appear impossible to many readers./5/ But, Scrum teams achieve massive productivity gains precisely through the compression of the gray boxes to near zero./6/

The measure does not distinguish between time lost due to poor scheduling, from project delays whatever their cause. From a CoD perspective, it doesn’t matter why we deliver late, our customers still can’t buy the widget. PDE is thus the starting point for the investigation. Of course, every project manager or team feels any delay with full force. We’re under pressure to deliver, and trivial delays like scheduling a workshop can drive us bats. We know it’s endangering the delivery date, and we know this long before the steering committee has asked about it. So why do we need to calculate the PDE?

PDE has many uses. With it, we can compare projects to each other objectively, since PDE is calculated from simple, observable facts. In a status report, it highlights schedule slippage to the steering committee, hopefully provoking a thoughtful discussion about priorities. And, in a large project, it might signal trouble ahead before it is too late. Across the whole company, the PDE can reveal that overall throughput is suffering. The cause is likely too much work in progress. Again, a review of priorities is in order.

PDE also helps in evaluating and adjusting estimates. Let’s assume, for example, that a company completed 25 projects last year. The average PDE value was 0.15, with most projects falling between 0.10 and 0.20. This company’s projects will thus have durations of 5 to 10 times their normalized efforts. If a director says, “we’ve budgeted 5 people for a total of 200 days, I expect this project to be finished in 2 months”, we can show that this is unrealistic.

This approach is similar to and compatible with velocity calculations in agile methods. Please note, PDE does not attempt to measure productivity in terms of completed items (say, story points). Rather, it’s focus is on time slippage only. Like velocity, however, it gives a transparent view of our schedule performance. That way, we know what we’re able to do under the current circumstances. Like any good KPI, it's just an honest measure. What we do with the result is up to us.

As always, feedback is welcome.  What is the PDE of the projects in your organization?

Part 2 of this series, you may find here: Measuring Project Duration Efficiency pt. 2 – a practical example


/1/ Jan Fischbach, Die zwei wichtigsten Regeln für IT-Projekte, Wie Sie mit zwei Regeln mehr Erfolg und weniger Stress haben, appearing in HR Performance, S. 60-63, Ausgabe 6/2014, which can be ordered at www.datakontext.com.

/2/ This metric is similar to value stream calculations in Lean approaches.

/3/ Who do we include? I recommend including everyone who is invoicing or actively recording her time for the project. The project manager should be included. The steering committee will usually be excluded. Most important for cross-project comparisons is a consistently applied definition.
We can find the data for PDE easily. Most companies a system for recording time, and the project manager is often responsible for controlling the time and/or preparing the data for invoicing. If no time recording is available, a simple tally sheet could be posted in the project office. To figure the duration take a look at a calendar: when was the kick-off and what’s the date today?

Note, we count the persons involved and not the number of planned FTEs. To understand why, let’s assume the example above is going exactly according to plan. Thus, each person is working a scheduled 50% for the project. With that we would tempted to divide the total effort by 3 FTEs instead of 6 persons.  The result would be 40 days of normalized effort, for a PDE of 1. With that, the index tells us nothing.

/4/ The best source on CoD is Donald G Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (Redondo Beach, Calif.: Celeritas, 2009).
Cost of delay is a vital measure for prioritizing products (or projects). The product with the highest cost of delay should be finished first, so that we can deliver it as early as possible.

/5/ Perhaps, you might argue, the team is working effectively on a second project during the gray days. Yes, of course, this seems efficient from a resource point of view. But, from a benefits or a cost-of-delay perspective it is not. We need to recognize that project 2 is also delayed, namely, during the colored days of project 1. So, why not dedicate the whole team first to project 1 and then to project 2? That way, we start to realize the benefits from project 1 after 20 workdays. The benefits from project 2 come after 40 workdays in either scenario.

/6/ The compression is possible for main two reasons: 1) the teams are dedicated to a product and are thus not distracted by multiple projects; 2) the teams are cross-functional, so that when one person gets delayed, others can step in and take on their tasks. See Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time (New York: Crown Business, 2014).

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Selbstbewertungsfragen für den Alltag in Arbeitsgruppen aus Sicht von Mitarbeitenden

Welche Fragen können wir Mitarbeiter:innen stellen, um herauszufinden, ob agiles Arbeiten wirkt? Es gibt bereits eine Menge an Fragebögen. Aber ich bin nicht immer zufrieden damit.

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Microsoft Lists: mit Forms und Power Apps komfortabel mobil arbeiten

In meinem Kundenkreis sind viele Menschen, die den Arbeitsalltag nicht vorwiegend auf dem Bürostuhl sitzend verbringen, sondern "draußen" unterwegs sind. Vielleicht in Werkstätten oder im Facility-Management. Es ist so wichtig, dass die Schnittstellen zu den Abläufen im Büro gut abgestimmt sind. Microsoft 365 hat so einiges im Baukasten, man muss es nur finden und nutzen.  In diesem Artikel spiele ich ein Szenario durch, das auf Microsoft Lists, Forms und - für die Ambitionierteren - Power Apps setzt.

Wie Agilität den Kundennutzen steigert - Einige Argumente für Berater:innen

In Zeiten wirtschaftlicher Unsicherheit fragen sich viele, ob agile Beratung noch eine Zukunft hat. Die Antwort liegt in der konsequenten Orientierung am Kundennutzen. Qualität setzt sich durch, wenn sie messbare Verbesserungen bei Umsatz, Kosten und Leistungsfähigkeit bewirkt, anstatt sich in Methoden und zirkulären Fragen zu verlieren. Dieser Artikel zeigt, wie agile Beratung nachhaltige Veränderungen in Unternehmen schafft und warum gerade jetzt gute Berater:innen gebraucht werden, um Organisationen widerstandsfähiger zu machen.

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.

Warum eine Agile Transformation keine Reise ist

Die agile Transformation wird oft als eine Reise beschrieben. Doch dieser Vergleich kann viele Unternehmen in die Irre führen oder Bilder von unpassenden Vergleichen erzeugen. Transformationen sind keine linearen Prozesse mit einem klaren Ziel, sondern komplexe und dynamische Entwicklungen. Dieser Artikel zeigt, warum Agilität kein Weg mit einem festen Endpunkt ist.

Warum bringen Warum-Fragen so wenig?

Frust! Wieder gibt's am Ende des Meetings keine Lösungen, sondern nur Diskussionen darüber, wer was warum verbockt hat. Wieder geht nichts voran. Warum passiert uns das immer wieder? (Ha! Da ist sie wieder, die Warum-Frage.)