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.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.

Pragmatisch oder nur “Quick and Dirty”?

“Wir müssen aber pragmatisch vorgehen”, drängt der Kollege. Hm… Im Wörterbuch finde ich für “pragmatisch” in etwa: sachbezogenes, praktisches Handeln. Klingt gut. Leider zeigt sich in meinen Erfahrungen, dass pragmatisch für viele doch eher “quick and dirty” bedeutet. Es soll schnell fertig werden. Aber auf welche oder wessen Kosten? Wo ist die Grenze? Warum steht “praktisch” im Konflikt mit einem langfristigen “Nützlich”? Muss das sein?

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Welches Motto für den Scrum Day 2025 würde Eure Arbeit am besten unterstützen?

Die Organisator:innen planen den nächsten Scrum Day. Wir wollen bei der nächsten Ausgabe ein paar neue Dinge ausprobieren. Wir haben uns Gedanken zu ein paar Themen gemacht. Welche haben den höchsten Nutzen für die Besucher:innen des Scrum Days 2025? Wir brauchen Feedback.