The Project Clock

Introduction

Continuously improving a project will necessitate making changes (among others) to the meeting structure(s). Oftentimes, “new” meetings such as Daily Standups or Retrospectives are met with resistance due to their perceived cost while established meeting such as weekly (aka Jour Fixe) meetings are considered to be indispensable. An objective view of the costs might be helpful (value is clearly important as well).

The costs that we have in mind arise from

Idea

We compress the total effort of a release into one day, to be precise 8 hours, e.g. from 8 a.m. to 4 p.m. This works very well with a quarterly release, which is why we use this as an example – you can of course also compress annual releases in this way, for example.
To illustrate, we’ll use a clock we call the project clock. Eight hours on the clock correspond (to a rough but extremely effective approximation) to 60 days, namely 12 (instead of 13) weeks of 5 days each. We will now look at how the expense categories listed above can be translated to our project clock.

Translations

It is surprisingly easy to transfer expenses from the above categories to a period of time on the project clock.

• Daily meetings are taken over 1-on-1
  • Example: A daily standup lasting 20 minutes corresponds to exactly 20 minutes on the project clock.
• Weekly meetings are covered 5-to-1
  • Example: 1 weekly one-hour project meeting corresponds to 60/5 = 12 minutes on the project clock.
• One-off meetings (of all employees) are covered 60-to-1 because there are 60 project days. So the translation is from hours to minutes.
  • Example: A two-hour training course for all employees corresponds to 2 hours / 60 = 2 minutes, i.e. 2 minutes on the project clock.

For a team of 8 (full-time), this applies additionally:

• One-off efforts by an employee in PT are taken care of in minutes. So the translation is from days to minutes.
  • Example: 5 days of effort for bug fixing corresponds to 5 minutes on the project clock.

The Project Clock

Category	Frequency and Duration	Duration on the Project Clock
Daily Standup	20 minutes daily	20 minutes
Project Jour Fixe	60 minutes weekly	12 minutes
Retrospective	2 hours, monthly, i.e. three retrospectives per quarter	6 minutes
User Story Mapping	Once per release, 2.5 hours	2.5 minutes

So far, we have been seemingly translated durations. Actually, they have been different representations of cost. Realizing that, we can also translate the cost incurred by sub-team meetings or individual efforts. Let’s look at two examples.

Category	Frequency and Duration	Duration on the Project Clock
Queue Replenishment	20 minutes weekly, 4 team members of an 8-member team	2 minutes
Single Bug Fix	5PT (combined development, test and release effort)	5 minutes

The meetings and further activities take less than an hour. So, let’s use a clock and display the minutes used by each meeting or activity within the first hour. There are seven more hours to go but they are not of interest here.

A few notes:
The focus here is only on meetings. Nevertheless, the length of time is revealing, because the costs of “new” meetings are (principally rightfully so) often viewed critically. Here it helps to see the relationships. The weekly project jour fixe for instance incurs more costs than monthly retrospectives, a release story mapping session and weekly queue replenishment sessions combined.

If you contrast the cost of a single (severe) bug fix with the cost of regular retrospectives, you see that they are almost identical. So, investing time into regular retrospectives seems to be a smart move since it — among other improvements — might result in a reduction of costly production issues.

The representation in minutes should not lead to efforts being “downplayed”. For a 100-person project (and a calculation basis of 1,000 euros per person-day), one minute on the quarterly clock costs a company 12,500 euros. The relationships are of interest.

Losing time at the start

Unfortunately, many projects cannot start at 8 a.m. (on the project clock) because they are busy with activities from the previous day (previous release) or days before. Problems from past releases, especially bugs from production that require subsequent deliveries, are costly.

• Example: If the entire team should spent a week after a release fixing the production issues, work on the next release will be delayed by a week. The effort therefore amounted to at least 1 team week = 40 team hours. On the project clock, the next release started 40 minutes late, at 8:40 a.m.

There is apparently no substitute for product quality.