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).


Beliebte Posts aus diesem Blog

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.

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

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?

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.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

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.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Führung weiterentwickeln mit Surflehrer Pepe (Pedro)

Führung weiterentwickeln mit Surflehrer Pepe  "Du bist für dein Board verantwortlich, ich bin für dich verantwortlich. Wenn du genau das tust, was ich dir sage, werden wir und alle anderen Leute hier sicher sein und wir werden eine wunderbare Zeit haben." - Pepe (Pedro) Surflehrer in Ericeira Gute Führung hängt stark vom Kontext und der aktuellen Kultur des Unternehmens ab. Der Stil von Pepe unterschied sich von den anderen Surflehrern, die ich zuvor hatte. In diesem Beitrag erzähle ich euch mehr von meinem Surfkurs, wobei ich mir nicht sicher bin, ob es eine Geschichte über meinen Surflehrer oder über Führung an sich ist.  Let’s grow, Michael

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.