Why We Insist on Planning

Teams that spend more time planning spend less time executing.

That’s what the research shows. And yet, we’re constantly asked to skip the planning step and get straight to executing. We get it! It can be terrifying to watch engineers work (and bill hours), but not produce tangible engineering.

Nevertheless, for any fixed bid project, Geocene insists on an initial scoping project, which usually takes about two weeks, and involves a ton of research, planning, and question-asking. After that, the only output of the scoping project is a detailed bid to do the rest of the project.

For many of our clients (or, perhaps, their CFOs), these scoping projects are scary. We ask for an investment of time and money, but don’t promise anything tangible in return. In other words, we’re asking clients to give us their trust, and they may not yet feel ready for that.

Although it might initially seem easier and less expensive to skip this step, we know that a scoping project is necessary for a project’s long-term success. We respect the importance of ensuring our subassembly works seamlessly with our client’s existing product, and we do it because it helps our clients build the right product.

And, believe it or not, I first learned this lesson from a lego-building contest in business school.

Dean’s Lego Lesson

By the end of class, I would end up resenting the hell out of the exercise. But, at the start, I was revved up and ready to win. I was in organizational behavior, a required first year class at the USC Marshall School of Business.

It was the last class before lunch and we had been broken up into small groups. My group of five competitive teammates studied the Lego brick figure my professor was holding up. We’d been given up to ten minutes to plan how we’d recreate it, after which we’d be operating only from memory—not unlike many projects that kick off after a short meeting with the client.

Within the first minute of my team’s planning time, we’d broken the project into parts and assigned each person a clear responsibility. Then, in less than two more, we’d each memorized the part we’d be responsible for.

“Why wait the remaining seven minutes?” I asked, “Let’s get to work and finish the assignment!”

Others in the group hesitated but quickly relented. We started the timer, spread the Legos on the table, and made the exact parts of the statue we’d just studied. When it was finished, I was sure my part was perfect, as was everyone else about the features they’d made. We were the first ones done! Or so I thought.

While we were the first to complete a submission, we’d made mistakes in the process, so the professor sent us back to find and fix them. Then we did it again. And again. It still wasn’t right. We blamed each other. We were each certain that our part was perfect. We were each right, but yet the submission was repeatedly wrong. Eventually, after much fretting and repeated submission attempts, we found the issues: they were in the joints - the places where our work came together and coordination was a challenge. The places it was unclear who was in charge.

Finally, we finished, but we had performed poorly. It took over 15 minutes for 5 people to make a simple thing. I sank into my chair and seethed as I watched our professor add our time to the bottom of the list on the whiteboard. We were dead last. And not coincidentally, we’d spent the least time planning of any team in the room. Our professor drew a graph on the board, plotting each teams’ planning time against execution time. The relationship was linear. Teams that spent more time planning spent less time executing.

Earlier in the class I’d asked, “why wait the remaining seven minutes?” and here our professor was, effectively answering my rhetorical question. We should have spent that time planning because we would have executed faster and finished sooner.

Of course, the type of planning matters, and the way the group organizes itself matters, but that’s a subject for another article. Even so, this lesson was as simple as it gets: plan more, execute faster.

The Impact

I resented the assignment because I performed poorly. Indeed, I’d fallen into the very trap our professor set for us, and my initial instinct was to blame our professor for my mistakes.

Fortunately, I learned the lesson, and the only actual cost was my bruised ego. Many startups and other organizations fall into the same trap, but at the expense of their product’s success. The need to hustle, to move fast and break things—these are all important in a startup. Long hours and the constant pressure to deliver features and bug fixes before a midnight deadline are part of what makes excellent startups great.

There is a flip side to that coin, however. Rushing to the execution without taking time to plan can be a lethal mistake for a startup. A little extra time spent coordinating and communicating up front can save months and hundreds of thousands of dollars (or more!) down the line.

How Planning Helps our Clients

Our clients almost always reach out to us because they need help building a part of their project. For example, they might have a feature they want to develop, and need engineering companies to execute the development. It’s like they’re a part of my team back in business school, and they’re nominating us to build the left arm.

Unlike my business school blunder of rushing into something blind, however, we insist on a scoping project before we begin working on anything new and unfamiliar. This provides many benefits for our clients, one of which is ensuring the completion of a planning phase that allows us to correctly execute the assignment in less time.

During the planning phase, we look at existing code and design files as well as available technologies. We ask key stakeholders and other developers a lot of questions in order to identify the “joints” and other hidden problems. In other words, we do our best to overcome what organizational behavior researchers call “the curse of knowledge,” which refers to the human tendency to overestimate our ability to communicate what we have in our head.

Unfortunately, the curse only gets worse the more specialized our expertise becomes. As specialized device engineers, we used to find ourselves in these situations all the time. It was like living in the classic “tree swing comic.” Our clients, experts in their product, would assume that we understood their product. Simultaneously Geocene, experts in device development, would assume that our clients understood device development.

Eventually, we discovered that the fastest way through the problem was exactly what my professor suggested: Planning. While planning, we identify and communicate the necessary tradeoffs our clients need to make. Then we learn what is vital to the project by talking about those tradeoffs. As a result, we create shared expertise, improved coordination, and increase by orders of magnitude the likelihood we’ll produce the output our clients need.

Summary

People assume they communicate their expertise better than they actually do, leading to enormous challenges in execution, especially if little time was spent upfront talking through potential pitfalls during the planning phase. Luckily, the solution is simple: spend more time planning, and when you do, focus on coordination. This will lead to faster execution and lower costs down the road.

Further Reading

Coordination Neglect: How Lay Theories of Organizing Complicate Coordination in Organizations