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.
How To Win As You Build Your IoT Process
Whether you’re in the midst of your IoT journey or just figuring out how to begin, you must be able…Read more
Want to build flashy apps? You need to fix your core first.
Does this scenario sound familiar? Your company’s legacy systems have been running for a long time. They hold a large…Read more
8 Ingredients for Crafting a Service Level Agreement
Whether augmenting your current development team or leveraging third-party vendor resources for application management, a clearly defined Service Level Agreement …Read more