5 App Dev Estimation Misconceptions

Jun 27, 2017 by Jared Faris

When clients ask “How long will this take and how much will it cost?” application development teams collectively shudder. Their ideas up to this point are hyper-focused on function and solution (not necessarily cost) which makes providing an estimate a cringe-worthy chore. These types of questions can also be dangerous. Clients tend to misinterpret estimations as hard deadlines, when in fact, estimates are liable and subject to change. As a result, application development teams have formed all kinds of misconceptions and objections about estimates to justify not doing them. Today, we’re setting the record straight.

It’s a classic catch-22. By their very nature, estimates are imprecise. But make no mistake, their accuracy is vital to product owners who are depended upon to make strategic business decisions. How do we improve the estimation experience for both application development teams and business leaders?

  1. We need to get better and more accurate at creating estimates
  2. We need to improve how we communicate estimate information with clients

Keep reading to learn the truth about application estimates and how to make them work for you, not against you.

Misconception #1: Estimates aren’t necessary.

Product owners can’t prioritize the expense of new application without an estimation of cost — period. If you don’t provide an estimate, someone else will, and that could be disastrous for your project timeline and budget. Like it or not, the estimate needs to come from the people who understand what it will realistically take to bring the application concept to life.

Misconception #2: There’s no such thing as being “good” at estimates.

You might never be perfect at estimating, but you will get better. A developer doesn't master coding overnight, nor does a business professional jump straight into leadership. Like anything else, creating accurate application estimates is a skill that must be developed over time.

Misconception #3: We can’t estimate because requirements change too often.

It’s true, requirements will likely change, but if you use this fact to justify not providing a application estimate, you will upset the delicate relationship between your development team and client. Without estimates, developers and designers unintentionally creep the scope line. Likewise, if the client doesn’t have a reference point that shows them the impact of change on cost and time, they will drive your team crazy with change orders that could send your project wildly out of scope and budget.

Misconception #4: If we don’t estimate, we won’t be held accountable.

Accountability is synonymous with good business. It’s how your application development team will earn trust, loyalty, and referral business. Plus, let’s face it, the client is going to hold your team accountable whether you estimate or not. With an accurate estimate, you’ll have documentation to support your project requirements.

Misconception #5: Accurate Estimates Are Impossible

An estimate will never be 100% spot on (hence the name, estimate). But there are several rules you can follow to ensure as much accuracy as possible:

Rule No. 1: Never give an answer without a formalized, detailed rundown.

Estimates aren’t an “off-the-cuff” undertaking. They require time and effort, just like coding.

Rule No. 2: You can only estimate with what you know right now.

Ergo, the more you know, the better your estimate will be. Here’s what you’ll need to build an accurate estimate:

  • Scope: Don’t get hung up on the requirements, here. Your scope is a description of the problem with as much granularity as possible. What will your application solve? How will it work? What specific project goals will you achieve?

     

  • Constraints: Any common instances outside your control that may impact the accuracy of the estimate (e.g. hardware requirements or possible timeline disruptions). These are similar to assumptions, but you have the foresight to know what they are.

     

  • Assumptions: For every piece of information you don’t know, you MUST make a detailed assumption. Fill the question mark with possibilities that might impact the estimate.

 

Rule No. 3: Account for every single effort required of your entire development team.  Think in terms of:

  • Planning
  • Requirements
  • Gathering
  • Designing
  • Developing
  • Testing
  • Documentation
  • Training
  • Deployment
  • Ongoing support

The bottom line:

When application projects get muddy, it’s usually because the development team isn’t understanding the business drivers and the client isn’t understanding the application development process. By accepting the responsibility of creating application estimates, working to improve accuracy, and clearly communicating with clients about what is and is not included in the estimate — it is possible for both parties to see eye-to-eye. Our last piece of advice — formalize your estimate with proper documentation. Your estimate will act as your baseline and benchmark for success. Let the client know that this document will change as new information becomes available, and share changes with the client to maintain transparency between parties.

how-long-will-it-take-jared-faris-webinar 
Load more comments