Executives and managers need deadline estimates to guide long-term strategy, but when it comes to day-to-day reality, Murphy's law reigns supreme. That's because top-down estimation never works. Leaders try to shoehorn big goals into small chunks, employees get frustrated, and everything ends up finishing late anyway.
Research backs this scenario. After analyzing more than 1,800 completed software development projects, McKinsey & Co. discovered that more than 30 percent of them missed their original deadlines. And even the 20 percent of projects that did cross the finish line on time only did so because the team removed features along the way.
To combat this, my company has converted entirely to bottom-up estimation for projects. That might sound scary, but when it's executed well, the benefits are enormous. By having employees self-develop their plans, leaders gain insight into how employees view their capabilities and how well teams work together. Further, managers have an easier time holding employees to deadlines when the employees make the deadlines themselves.
No matter who's responsible for setting deadlines, though, projects still run over when the people making the estimates don't account for all the variables. A manager might not account for the full difficulty of technical development, while an engineer might not anticipate how much administrative work the project requires. Bottom line: When people underestimate complexity and overestimate productivity, disappointment is inevitable.
Charting accurate timelines
Whether they're in large or small businesses, managers and developers must learn to make more accurate estimates of project timelines in order to keep projects on track. This eight-step process can help teams of all sizes and compositions do just that:
1. Provide high-level guidance.
Agile refers to this step as "epics." When an executive asks a team to build something within the quarter, that defines the broad scope of the project. General timelines indicate to development teams the importance of their projects and the expectations associated with those projects. During this first step, developers and their managers should communicate with the leadership team to understand the problem they are solving, clarify acceptable deliverables, and ensure everyone understands how success will be measured.
2. Identify individual work.
With the larger goal established, work with teams to parse out individual tasks. Team members should be free to make suggestions and adjust the timelines of tasks as needed. This step is critical to establish a sense of ownership within the team. Break down big pieces into user stories to communicate to developers what the product needs to do for users, not just a list of features.
3. Aggregate and prioritize.
By this point, everyone understands the work that lies ahead. Put all the tasks together, and discuss the full project as a team. Encourage developers to point out gaps to ensure all tasks are accounted for, and there will be minimal unexpected "gotchas" that pop up mid-project. Place tasks in order of priority and dependency to keep things running smoothly.
4. Agree on point values.
Rather than assign hours to tasks, have everyone involved in the project write down a value for each task at the same time. This allows managers to hear all voices and get a better idea of how the work will progress. Developers are notoriously bad at estimating timelines, so keep points related to complexity, not time. (We'll discuss how to translate those points to time later.) We've built a free tool, Points Poker, that's a great resource for doing this remotely.
5. Discuss discrepancies.
If developers put vastly different point totals on the same task, talk about it. This process fleshes out concerns and helps identify potential issues before they become bigger ones. For example, let's say the task is to create a select view of buying options. One developer might assign a low point value, but someone more experienced with the system might remember that unstructured data could make this task far more difficult. Following this process in the early stages gets the team talking and results in more accurate time estimates.
6. Break down big items.
If some tasks appear to be much larger than the others, break them into smaller components. The point of this exercise is to make things as granular and easy as possible. Refer to step three, and organize these smaller breakdowns by priority and dependency to keep the project on track.
7. Execute and track.
When every task carries a point value and the team agrees on a prioritization order, let developers begin work. Keep tabs on how many tasks the team completes and what their point values are. With these being very granular and previously discussed, there should not be too many surprises, but try to note patterns if they develop. Get regular status updates, and make sure to remove blockers that your team might be encountering.
8. Use velocity to set the schedule.
After a week, the team's velocity (number of points completed within the week) should become clear. Compare that velocity to the total task list to get an accurate assessment of how long the project will take.
If the team completed 20 points of a 100-point project, for example, you can fairly accurately project that it will take five weeks to complete. If the leadership team needs the project finished sooner, use the velocity estimate to adjust. Add more team members, incentivize employees, or deprioritize features that matter less. Put high-point tasks at the bottom of the list if the leadership team needs a working prototype sooner.
This process takes a bit of time, to be sure, but it's far more effective and reliable than the top-down systems practiced at so many companies. Use these steps to create the timeline for the next project and compare results to those of the past. Small business leaders can continue to refine the approach to work for their organizations, and before long, deadline extensions will become a thing of the past.