The Danger of Pilotitis

In the aftermath of waterfall development, organizations worldwide have embraced agile methods. Today's complex world requires quick pivots, adaptability, and feedback cycles with customers and stakeholders. This article is not an attack on this movement but rather a warning about when we can take agility to the extreme.

To make a solid argument, let’s consider why pilot projects are good and, more importantly, why people like to do them.

Quick proof of value: Instead of committing many resources to a giant project, trying to get a prototype running can show if the idea holds any water and avoid sinking resources into a lost cause. A successful pilot project can generate enough trust for a follow-up larger-in-scope initiative.

Generates excitement: Pilots allow teams to work on new, often trendy topics. Building a fresh product from scratch and quickly showing it to users can be extremely rewarding both for individual contributors and the managers steering and selling the work.

The small scope allows for easy activation: By working in a greenfield environment, developers can avoid thorny legacy software issues, postponing almost inevitable integration and deployment challenges down the line.

Pilotitis: the disease of over-focusing on pilot projects.

Those are all valid points for pursuing pilot projects. So, what’s the problem? If taken to the extreme, managers can over-focus on such work and ignore topics that are essential for long-term, sustainable success. The loop of excitement and rapid speed postpones the demanding work required to scale a digital product and the tremendous work required to support it. Furthermore, a multitude of fragmented initiatives can lead to a lack of tracking of progress and resources from the business side and reinventing the wheel from the software side.

We can visualize the problem:

How can we avoid contracting pilotitis or cure ourselves from it? If you are a regular reader of mine, you wouldn’t be surprised to see Nassim Taleb’s wisdom here as well. I advise taking a portfolio approach, which gives you an overview of projects, the distribution of risk and resources, and a framework for measuring impact.