Fast Starts; Part 1 of 2
If you’ve been involved in any number of big projects, you’ll have seen some that started fast, with great early success and a lot of initial progress. But often these same projects got bogged down as unexpected issues arise, complexities are found, and deadlines are missed.
Why do large projects that start well and show great promise so often go bad?
It’s true that each project can have its own unique challenges, often clearly visible in hindsight. But in many cases it is not a question of a good project ‘going bad,’ but rather of initial success leading to overly optimistic projections and masking the need for level-headed planning. If you have ever seen a product demo generate massive excitement and get mistaken for being almost production-ready, you know what I mean. Too often, a good start is taken as an indication of an easy project.
Initial Momentum
Projects often start with a lot of momentum. There are a number of reasons for this:
• When faced with a project comprised of a mix of simple and complex tasks, people often begin with the easier and better understood tasks. This pushes the more difficult work later into the project.
• Sometimes a project must be ‘pitched’ (sold to stakeholders) in order to be adopted, and so its most visible or impressive aspects are prototyped and hyped at the start of the project. In many cases, part of the pitch is about how simple the project is, or how quickly it can be completed. In this way, expectations are unrealistic from the start.
• Greenfield projects, projects that are fundamentally new, are not initially held back by constraints imposed by prior work. Because of their newness, potential difficulties may not be initially recognized.
• Early challenges might be ignored in the hope that they will disappear. Sometimes they do! But more often, a small challenge ignored early on grows into a bigger problem.
To be clear, I’m not arguing that a quick start to a project is necessarily a bad thing. Projects can start with a lot of momentum for good reasons. For example, the work is trivial, or the team is executing at a high level! Rather, I am pointing out that there are many ways in which a project can appear to be starting well, while problems lie hidden. Problems can be easier to hide at the start of a project. But as time goes on they will become evident, and the project will appear to stall.
Bumps in the Road
The challenges that can slow momentum are the same things you might expect to encounter in any project of at least moderate complexity. Here are some examples.
• Non-trivial issues, edge cases, and unanticipated challenges can be encountered as work progresses past the obvious cases.
• Overall project complexity can be greater than initially assumed, particularly after initial success.
• Changes to the team, the project plan, or the overall goals can make the initial work less valuable, can add complexity, and can make it harder to discern the best way forward.
• Adding more people to the project can actually slow progress (see The Mythical Man Month).
• Existing or external constraints can take on greater significance as a project moves from a demo stage to production-ready.
This stuff is normal. Almost any project can encounter such challenges. But when a project starts fast, stakeholders are often convinced that these challenges won’t appear, or have already been taken into account, so their disillusionment and disappointment is that much greater. What should be minor bumps in the road become roadblocks.
Adobe Illustrator
My most extreme example of an apparently fast start followed by an extended, painful reality check occurred years ago, when I was working at Adobe as an engineer on the Illustrator product. At that time software was still primarily released on DVD, with included documentation. Because the release was so expensive and involved (including the production and shipping of physical materials), each new version was a major effort.
We started with meetings, planning, and prototypes—we literally spent months on these efforts. The start of a release cycle was a glorious time, full of great ideas, rapid progress, and cool demos. Everyone from the lowliest intern to our CEO was excited about the upcoming release. For a while.
That release was expected to take about two years, but dragged on for close to three! For the better part of a year, users were expecting to buy a new release of Illustrator and Adobe was expecting to profit from it, but nothing was released. For the final few months my engineering team worked nights and weekends trying to get back on schedule, handle changes, deal with unexpected complexity, and fulfill the early promises.
We eventually released Illustrator, but along the way we made every one of the mistakes I have listed above. The project was so long and complex that we made most of them multiple times, and added a few others!
Maintaining Momentum
The state of the art in software methodology has improved since those long-ago days. But good, useful techniques are valuable only if they are appropriately, thoughtfully, and regularly applied.
In the second part of this post I will talk about some of the many ways that project pitfalls can be avoided, or at least ameliorated. If you have made a fast start, you want to maintain your momentum. I will discuss some strategies that can help turn your fast starts turn into fast finishes.