Technical Estimations: The Love-Hate Relationship Story

http://maginfo.com/wp-content/uploads/2015/11/AdobeStock_64170691-300×205.jpeg

Estimations Are Hard

 

For software developers, creating a meaningful technical estimate is one of the most difficult things you will ever do on a regular basis. A good estimate must take into account so many (often vague) variables like the technologies being used, the scope of work and even the client themselves. On top of that,  any attempt to propose a solution based on a development-level understanding of a client’s needs often differs from what the client actually thinks they want (or need) in the first place, especially when they don’t have a technical background.

How developers create and present technical estimations also has consequences, both good and bad. Overestimation can scare a client and lead them to place a project on hold, or even find another firm to do the same job. Underestimation may initially cause the client to accept your proposal, but will put the integrity of your team and business in jeopardy. Unfortunately, even the smallest miscalculation can lead to confusion and with so much at stake, no wonder developers cringe at the thought of putting together a technical estimate. Now while an estimate is rarely perfect, there are still a number of ways to make estimates as accurate as possible.


 

Reaching A Common Understanding:

Without exception, when your dev team begins the estimation process, they’re naturally hesitant to put together a proposal broken down by days and hours on a piece of paper. Turning a request for proposal (RFP) into a meaningful estimate takes time, research and analysis; questions are also always bound to arise ranging from intended functionality to the true meaning of user stories. But this is good, developers should be asking questions!

Considering that most clients are not “technical individuals”, what I’ve noticed is that many clients view an estimate as an unchangeable oath written in blood. In contrast, developers tend to view an estimate as nothing more than the definition of the word itself, a rough calculation based on what is known at the time. That said, developers often change estimates as new information and requirements are discovered, often to the dismay of the client. While a software engineer may understand that even the smallest feature or change in functionality can impact the scope of an entire project, most product owners simply don’t see it that way.

Presentation Is Key: Knowing your Audience

Being able to distinguish between whether your client wants a rough order of magnitude (ROM) or a true request for proposal (RFP) can save a lot of time otherwise spent on unnecessary work. Depending on the project, various members of your team may also bring a different point of view (POV) that will impact the estimation approach being used. Believe me, product managers, developers, quality assurance and sales all see things a little differently. While this can be a good thing, having an understanding of your audience is arguably the biggest factor impacting how a technical estimate is made, presented and what level of accuracy is needed –  knowing whether your estimate is going to another engineer or to your average joe makes a huge difference here.

In the past, we’ve experimented a bit with different types of technical estimates and have found that other dev teams, technical individuals or companies requiring SAAS solution want the most comprehensive estimate you can give. On top of a comprehensive estimate, they want a list of technologies, the justification for these technologies, and an hour-by-hour breakdown on every individual task – these proposals took a stupid amount of time to create, but that’s what the client wanted, that’s who our audience was. On the flip side, some of our clients were small businesses, they did not have a technical background and simply wanted a web or mobile application. The estimation approach used for them consisted of 1-3 pages where we reiterate their needs and provided a summary of the sprints each broken down by hours. The difference in terms of time spent between these two types of estimates is sometimes multiple weeks or even months.

Margin for Error:

Developers never make mistakes and everything is done correctly the first time around.. (said no one ever!). Even with the absolute best dev teams, not including a margin for error in a technical estimate can be disastrous. In a sense, if you’re not including some wiggle-room for reworks, you’re underestimating the total effort needed for completing your deliverables. When possible, give estimates as a range when it makes sense and be more precise when a range is not needed. Mockups are a great example here because clients tend to have their own idea of what looks good and rework is almost always necessary. However, once mockups are approved by the client, the margin for error contributing to rework is not nearly as high – taking this into account when making an estimate can significantly improve accuracy.

 

Example:

Phase 1.
Mockups & Design: 2-6 days

Description: At this step, Maginfo will prepare mockups and designs for the project. Upon completion, approval of mock-ups will be needed prior to moving to the next step of development.

 

Phase 2.
Development: 6 days

Description: At this step, Maginfo will implement the project based on approved mockups and specifications.

The Benefit of a Good Estimate:

For product owners and clients specifically, having an itemized breakdown of functionality at the granular level makes it easier to weigh and prioritize different aspects of the project and even put “nice-to-have” features on the backburner… At the end of the day, it’s way easier just to sit down, write some code and bill for the hours, but even developers understand that this is unrealistic from a client perspective. Nevertheless, reaching a mutual understanding between the client and the dev team regarding the scope of work should be the #1 priority before kickstarting any project.

 

The post Technical Estimations: The Love-Hate Relationship Story appeared first on Maginfo.

from Maginfo https://themaginfo.wordpress.com/2015/11/19/technical-estimations-the-love-hate-relationship-story/
via IFTTT