<iframe src="//www.googletagmanager.com/ns.html?id=GTM-N34J73" height="0" width="0" style="display:none;visibility:hidden">

The world's largest changemakers rely on NGP VAN campaign technology Find Out More

  • people-data-action-2-1

Planning Your Trip Well

Dave Berman

Last year, we completed a massive project, Action Platform, which our CTO, John Lee, describes here. Needless to say, we consider this project to be a huge success. One reason for that is alluded to in John's third Lesson from his post: "Plan Your Trip Well". He discusses the importance of milestones, which are really a component of a more important process: Estimation. Estimating large software development projects is hard, but necessary. 

Because estimation is hard, people tend to avoid it. Sometimes organizations that practice Scrum use it as an excuse to not estimate more than a sprint in advance. That approach doesn't work very well for many business stakeholders, and it certainly doesn't work for projects of a large magnitude  that cross teams. Stakeholders want to know when you can reasonably expect to deliver something. Some organizations attempt very rough estimation at the beginning of a project, but I often find those efforts to be somewhat meaningless and possibly inaccurate. Early estimates are often worthless not only because the scope frequently changes after the initial rough estimate is given, but also because if you only take five minutes to estimate something that takes longer than five minutes to describe, you've already lost the battle.

This is a good time to take a break and read this article: The Cone of Uncertainty. The gist of the article is that it is difficult to estimate accurately how long software projects will take before you start them, because they have inherent variability. The only way to reduce the uncertainly of the estimates is to start reducing the number of variables, which can most effectively be done by actually starting on the project itself. As the project moves toward completion, the variability of the estimates narrows, hence the "cone". This fact drives the need for the iterative planning and estimation process I outline herein. (I should point out that I think the cone is too balanced - it should probably be more heavily skewed to the underestimating side of things.)

A key point of the "Cone of Uncertainty" article is that you can't get good estimates without moving toward the right on the cone. In order to do that, I recommend an ongoing estimation and refinement process that is a give-and-take between product and engineering. It needs to be an iterative process, and there needs to be trust between the two parties. Product managers need to understand that these are just estimates, and are often going to be subject to change. Engineers need to be as honest as possible with themselves and with their estimates, and not pad things unnecessarily. They also need to accept that the earlier they receive requirements, the more likely those requirements are to change. And both parties need to be extremely proactive about anything that might affect the milestones and attempt to keep them updated, whether those things are scope changes by product or new discoveries by engineering.

This table outlines the process that we used to plan long, cross-team components of the Action Platform project:

Screen Shot 2017-08-18 at 1.05.46 PM.png

Screen Shot 2017-08-18 at 1.06.07 PM.png

Screen Shot 2017-08-18 at 1.06.24 PM.png

Without this process, I don't believe Action Platform would be seen nearly as successfully as it is.

It may well have been completed, but the milestone process provided both key visibility for stakeholders and an important roadmap for developers. For large projects, it's clear that the more time you invest in estimating, the further to the right you get on the Cone of Uncertainty. Frequent communication with product is a must. it's useful to keep Scrum practices in mind (ship early; first things first - meaning asking "is this really MVP?"), but having the big picture can help your plan your trip well.