There are all kinds of reasons it’s useful to create a project timeline. It forces you to think carefully through each step and clarify dependencies, and it gives everyone a shared goal to work towards. You may need a timeline to get budgets approved and staff allocated, and it helps get the right people ready to pay attention at the right time.

But in the realm of technology builds, timelines are most helpful if we can all admit that they are, by nature, an initial best guess.

Why? Because at the outset of the project you don’t actually know exactly where you’re going, even if you think you do, (a well established principle of lean development). Nor do you know what your priorities will end up being at the end, nor what you will encounter along the way. 

You also probably don’t know who are the specific human beings assigned to each task and their particular availability, skill sets, and challenges (the idea that all human “resources” with a certain job title are interchangeable in terms of skills and effects on timeline is a particularly ludicrous notion, to be elaborated on in an upcoming post.) Neither do you know what other competing priorities your organization will grapple with during that time. 

And you certainly don’t know the feedback and ideas that will emerge once people start using the thing you’re building. Once you can lay your hands and eyes on the product, new questions, puzzles, and ideas arise daily. And that’s exactly how it is supposed to work. That’s where all of the juicy stuff is that makes the difference between mediocre and great. 

Sure, you could plug your ears, ignore everything you’re seeing, and stick to the pre-set plan. But is that really worth it, if it means ending up with something mediocre? That is, in fact, the predictable result of the widely-discredited system of “waterfall” planning.

If you want to build something great, each puzzle along the way requires careful problem-solving, scenario planning, and sometimes even all-hands-on-deck solutioning. Sometimes it means choosing the lesser of two non-ideal options, other times going with an entirely unforeseen new option to address the challenge. But the benefit of all of this work is a much stronger, more effective product in the end.

This doesn't mean that a well-run project is devoid of urgency. Some projects may even demand countless high-urgency sprints strung together, in order to hit a series of sequenced goals.

Many people think the solution is to pad the timeline, but that's the wrong medicine. When the project is drained of realistic, meaningful urgency, people tend to pay only partial attention, and generally relax when they need to be putting their backs into the work. 

So by all means, let’s establish a realistic timeline that we can all look at together and use as a strong, guiding light. 

But when choices arise that threaten the timeline, let’s not be so focused on timeline that we lose sight of the whole point of what we’re building. You need to be constantly making choices that weigh the tradeoffs of timeline (and level of investment) versus functionality and fixes. That’s simply a cost of doing business in this world of limitless complexity, limitless options, and game-changing improvements out there waiting to be made. 

We just have to be ok with the uncertainty of the journey that gets us there.