In the aftermath of challenging projects, team members commonly wish they had invested more of their smarts at the outset. For example, one team we worked with realized that a better launch could have revealed an important lack of connection between project goals and the priorities of the rest of the organization early enough for it to have cultivated crucial sponsorship and alignment. Another uncovered disastrous internal disagreement about project strategy so late in the process that the team had few options for refocusing the work. Had they discussed work plans, deliverables, and goals at kickoff, the team later realized, they would have surfaced the conflicts early enough to resolve them. Three common failure modes occur at the outset of projects—relying on hindsight– not foresight, forgoing planning in favor of action, and designing work only for execution, not learning.
Hindsight Instead of Foresight
Again and again, we are surprised by how often it happens: in the cold light of hindsight, spurred by the pain of disappointing final results, teams look back with candor and openness at their experience and their analysis reveals new truths. In this moment, given the right opportunity, teams can be very skilled at detecting the seeds of their project’s lackluster results. Yet far too frequently, the resulting hard-earned insights and resolutions recede into the background when the next project is launched.
Perhaps it’s human nature. It’s true that failure spurs deeper thinking than success, at least up to a point. The kicker is that such examination necessarily happens at the end of a project—when the bad news is in. At the start of the next effort, the mood is more optimistic and the conversations forward-looking, and few want to dwell on what went wrong last time (or speculate about what could go wrong this time). The team may not have the same members and the work may differ, complicating the task of applying lessons from the past to the future.
Just Do it, and other “No Planning” Approaches
Then there’s the constant tug-of-war between planning and thinking on the one hand and action on the other. In many projects we’ve studied, the combination of ambitious goals and constrained resources created pressure to get visible results quickly. There are many advantages to “just doing it.” Examples of rapid-action approaches include scrum and other agile methods popular in the software industry today, and new versions of lean and quality-inspired approaches that are reshaping manufacturing and start-ups. You’ll see their influence in our methods. But the buzz about these high-speed iteration techniques may heighten the pressure to get things done, making you feel as if it’s better to act than to prepare. Unfortunately, there’s no guarantee that the requirements for an effective project—activities and deliverables that are aligned with organizational priorities, access to the resources required to carry out the needed work, and more—will work themselves out in the rush to action if your efforts are not guided by some careful forethought.
Setting Up a Project for Execution, Not Learning
There’s one more reason it’s all too easy to skimp on the critical work of laying the groundwork for your project. One of the biggest barriers to project impact is operational: most teams don’t know how to launch their projects in a way that primes them for learning and refinement. Teams launch onto linear, monolithic paths with a specific deliverable in their crosshairs, without surfacing assumptions, linking actions to larger outcomes, and asking the right questions.
The good news is there are specific actions team leads can take today to overcome these traps, and launch for better project outcomes. Check out our Method Overview for ideas on how.