Capabilities /

Software Self Defense 101: Improving Your Technical Estimates

By Josh Collins | February 11, 2016

photo credit J.King, ModernAnalyst.Com
photo credit J.King, ModernAnalyst.Com

Estimates are a necessary evil in every development organization. You have to size work in order to plan projects, but ever-changing scope and priorities will throw off even your best estimates. Nothing is worse than telling your client that what was estimated to take Y weeks will now take Y++ weeks and what would cost $X may now cost $X++. Not only are you behind in your timeline, you’ve also potentially compromised your client’s level of trust in you. Fortunately, these situations can be minimized and even avoided with some additional due diligence. Below are three guidelines toward feeling more secure in your estimates and your ability to defend them down the road.

1. Discover
Take the time to understand the scope, the problems you’re trying to solve, and the goals your stakeholders are looking to achieve. Ask questions that help you understand why your stakeholders are asking for the things they are. What sounds minor at first may have unforeseen tentacles — a simple request for a user interface change may predicate changes to a data model or a new backend web service. Take a little extra time now to avoid a lot of extra time later.

2. Get Real.
How often does your team get eight fully productive hours a day? That is, without meetings, or being slowed by a dependency, or being pulled away by the fire drill du jour? Estimate raw scope in terms of hours, but when you lay it on to the overall timeline, be sure to account for these real world demands. Set your team and your self up for success by being realistic.

planthework 2
photo credit Geek-and-Poke.Com

3. Assume Away.
As you walk through requirements and scope, break it down into as many granular line items as possible. For each line item, sketch out high level assumptions such as components needed or impacted. For example, a requirement may ask for two new fields to be added to a screen. This equates to changes to the UI but may also require additions to a database, adjustments to a backend service code, some minor business logic, and some tweaks to a report. Communicate these assumptions with your stakeholder, and if possible, have him or her validate them. Size the work based on these assumptions. Then document them in a level of detail such that you can explain the estimates weeks or months down the road. This will also help in managing scope later on in the project lifecycle. The bottom line is, it is much easier to explain a change in effort or duration, or navigate an unexpected issue when you can point to previously agreed upon assumptions.

A little extra time for research, a bit more respect for reality, and a lot more documentation can make a world of difference in your ability to plan and deliver at the standards, both of which your team is capable and of which your client deserves.


The Life of [A]PI: The evolving identity of the API, and how to leverage it for your business

In its simplest form, an API (Application Programming Interface) is a set of programming instructions that allows one application or…

Read more

How to Be Successful with Digital Transformation Spending

This post originally appeared on … Digital transformation technology spending continues to grow across all geographies and industries. IDC…

Read more

Why Microservices Should Factor into Your Architecture Planning

This post originally appeared on ... At every turn, it seems there’s a new technology trend with the potential…

Read more
// // //