The Dangers of Fluid Timelines

This week I’ve been working on a reset plan for a multi-year project. Its goal is to get multiple external websites, internal websites, and other miscellaneous data off an old web server and onto a new one. Because the project has been so long and included multiple pivots, entropy has set in and made our original approach to the project less effective. So I’m on a mission to update our approach to meet our new needs.

This has involved a good deal of reflection (with the help of Claude.ai), and I’ve realized some downsides to the way we’d been managing the project timeline. I’d like to share them with you, so you can make better timeline management decisions earlier in your projects.

When we started this project, estimating the timeline and having a sense of when we’d be off the old server mattered, but it was most important to simply get started and make continual progress. So we got a time estimate from our web developer for rebuilding each website, and the team agreed on the most logical order for rebuilding the sites. Then I represented each site in our project software with a task, giving it a start and end date that matched the estimates, and linking each task to the next with a dependency.

This worked great for a while. In monthly progress meetings, the tasks were a reference point for the sites being actively rebuilt that we needed to discuss. Based on status and progress, we’d update estimated completion dates for sites as needed. Because of the built-in dependencies, this would conveniently adjust the dates on the other sites and automatically give us a new ETA on the overall project. Just what we needed! Or so we thought.

Unfortunately, most of the sites have ended up taking far longer than estimated. Some variation would have been fine, but long delays have increased the budget impact of paying for the old server and the new server at the same time.

For a while I blamed our estimating technique for this problem—or perhaps, our lack of estimating technique. We’d asked one person for their best guess and went with it. There are many ways to estimate work timelines that generally lead to more accurate results. I have yet to write about estimating techniques, but the rest of the internet can certainly explain your options. I’d previously considered 3-point estimating as part of our reset for this project; now I’m leaning toward bottom-up estimating as a better fit.

Sound estimating techniques are a meaningful part of an effective timeline management strategy, but as I’ve sat down to seriously develop a project reset plan, I’ve realized they’re likely not the whole reason for delays in my situation.

The rebuild of one of the high-profile websites in this project has ended up being driven by somebody else in the company. Her clear, multi-stage plan for the site rebuild, combined with the importance and visibility of the project to leadership, have allowed the rebuild of this site to proceed entirely on time. I am learning from her approach—it is time for us to identify achievable but firm deadlines for the remaining sites and get buy-in on those deadlines from more leaders, so the deadlines become harder to move. It is time to give teeth to our timelines, and for us to adapt to them, rather than continually extending the timeline when the work happens to take longer.

And as I thought about how readily we’d extended our timeline in every project meeting, it dawned on me that maybe the ease of extending the timeline in the software was one of the reasons we did it so often. If I’d represented each site with a firm milestone date at the end rather than a dependency to the next site, it would have been more work to update the timeline…and it might have created natural pressure to simply catch up rather than push things later. I plan to harness this natural pressure in my project reset.

There are many approaches to timeline management that can work well. While we probably should have used an estimating technique at the beginning, our fluid approach to our timeline wasn’t wrong. But it was conducive to a much slower pace of progress than I realized. It set up delays to be the easy choice. Now that we’re ready to make efficient progress a priority and an end date for our old server firm, I’m going to use all the tools and factors at our disposal to support these goals.