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.
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.
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
An Intro to RADD
At Janeiro Digital, our ultimate goal is to help businesses better achieve their goals so they can in turn better…Read more
Three Project Pitfalls (And How To Avoid Them)
After months of vetting vendors, you've found a development partner to build your application. It’s all smooth sailing from here,…Read more