More planning doesn’t mean your product will succeed

A recent article in the Wall Street Journal stated that 99% of big projects fail and only 0.5% of large projects are delivered on budget, on time, and with the projected benefits.  

It’s tempting to read statistics like this and think more advanced planning is the answer. But as someone who’s done project work for a few decades, I’ve found that to be a misnomer. Of course we need planning—but product teams in today’s fast-paced business landscape should instead focus on “just enough planning” to be successful. Here’s why.  

Long ago, and far away

The very first job I had after university was as a software engineer at a large telecommunications firm. My group wrote software for specialized communications hardware. Unfortunately, we couldn’t start programming until our system specification was completely approved and signed off on. This could take months—and sometimes even a year. The experience scarred me for the rest of my career. 

Many of us knew that the “spec” was already out-of-date as soon as it was approved. Change orders were then continuously made to keep it up-to-date—even up to the last minute of shipping product (and sometimes after). The QA team used it to test the system, sometimes to extraordinary levels. A clever QA engineer once wrapped wire around a power drill and plugged the other end of the wire into one of the input jacks of our controller and pulled the trigger. The entire system crashed, with lights blinking everywhere. 

When asked why he did that, he replied that the spec didn’t say he couldn’t. 

The reality was that the monolithic, multi-hundred-page software specification was not an optimal way to define the project. Excessive planning didn’t mean more certainty.  

A new, agile of way thinking

How should teams change the way they think about advanced planning?  

Consider the Agile Manifesto, created in response to the era of massive, monolithic design documents. The manifesto authors uncovered a better way of working that included “Working software over comprehensive documentation” and “Responding to change over following a plan.” The focus needs to be away from the specification and toward working product. We need to embrace change and not erroneously assume a static version of a completed system. 

Professor Bent Flyvbjery, an expert in the planning and management of “megaprojects” who uncovered the statistics outlined in the Wall Street Journal, suggests thinking slow and acting fast. One example that Flyvbjery gives is architect Frank Gehry experimenting with designs and tinkering with models in his studio for two years before doing anything else. Building models and running experiments is a great way to learn and mitigate potential risk. He also recommends: “Find the Lego that simplifies your work and makes it modular.”  

In other words: Break up the work into the simplest tasks. I often ask my team, “What is the simplest, valuable thing we can create?” Let’s build that, learn from it, and ask the question again the next day. 

Let’s get started 

As I said earlier, I was scarred by having to wait until the entire design specification was approved before beginning to develop. Yes, we need planning. Yes, we need documentation—but only enough to get the team started. Start by aligning around a shared idea of what we want to accomplish: for instance, by implementing an OKR (Objectives and Key Results) framework.  

Once we can identify the simplest thing we can create, I vote for building, delivering, and learning—as soon as we can.