Capabilities /

Software Self Defense 101: Improving Your Technical Estimates

By Josh Collins | February 11, 2016

photo credit J.King, ModernAnalyst.Com http://bit.ly/1Q7pn9L
photo credit J.King, ModernAnalyst.Com http://bit.ly/1Q7pn9L

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 http://bit.ly/1TcwX9G

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.

RELATED CONTENT

Cyrus One Part 3: Reimagining efficient invoicing

CyrusOne offers data center solutions and colocation services for enterprise clients. Their global data storage centers allow customers to purchase…

Read more

CyrusOne, Part 2: Creating a portal for customers

For their very first project together, CyrusOne had come to Janeiro Digital with the unique challenge of figuring out how…

Read more

The UX Roadmap

The road to designing a great product is often paved with revisionary red ink. Over the years, we’ve found that…

Read more