The pi rule

These days things are getting pretty busy on my end – so many cool projects to engage with and only 24 hours a day.

And you end up doing more things that you can accomplish. The reason often lies in the unrealistic assessment of the time it would take to complete a task, and I came across the “pi” rule, initially posited by my mentor Ken, with a pretty neat explanation from my colleague Val:

If you estimate it will take one unit of time to complete a task, the task will effectively take 3.14 (≈π) times more than you initially anticipated.

The reason for the difference between dream and reality  is that we generally do not factor in:

  • (1) the time it takes to ease into the task (e.g. collecting documentation, emails) and
  • (2) the time requires to document the work done (reports, emails)

Taken together with the times its take to accomplish a task, you end up with roughly a factor three – and you end up feeling terrible during the week-ends trying to catch up what you were set to do during the week, but got busy doing (1) or (2)

A corollary of the pi rule is the “next up” rule: if you work on project with a relatively large team, it generally takes the next unit of time to complete it (e.g. one hour become one day; one day becomes a week; a week becomes a months), generally because of the friction at the interfaces. Reducing these frictions at the interfaces should therefore be a priority.

Engineering interfaces in big science collaborations

I recently learned that my colleague Bertrand Nicquevert has worked extensively on a model to describe interactions between various counterparts:

Modelling engineering interfaces in big science collaborations at CERN: an interaction-based model
https://cds.cern.ch/record/2808723?ln=fr

Here are two salient excerpt from the paper:

And a descriptive schematic of the collective role of the middle managers.

One issue in the scientific enterprise is that we rarely hire project managers for projects (we take from the pool of scientists or engineers and give them superficial training at best.) This is particularly glaring in projects involving software engineering, where interfaces are very loosely defined – which is partly why things have moved from the waterfall approach to the agile method. But even for the agile method (maybe more acutely so) you need a project manager.

.:.

Here’s the complete thesis (in French)

Manager l’interface. Approche par la complexité du processus collaboratif de conception, d’intégration et de réalisation : modèle transactionnel de l’acteur d’interface et dynamique des espaces d’échanges

https://theses.hal.science/tel-00789791v2/document