Navigating the Cone of Uncertainty

Software estimation -- the phrase inspires fear in some, mania in others, and exhaustion for those all too familiar with the infernal guessing game that it is. Most experienced developers have spent many a sleepless night toiling in agony over the cost of a complex software product. But why is estimation such a hassle? For many, the answer lies in the cone of uncertainty.

The cone, first described by programming guru Steve McConnell, is like the software development equivalent of the Bermuda Triangle. It describes the low confidence a developer has at the beginning of a project regarding how long it will take and, more importantly, how much it will cost. Here’s an example of the cone, from Construx.

Cost being the Y axis, you can see that there’s a very wide range of potential price points at the beginning when the developer has little to no knowledge of how challenging or time-consuming a project will be. Once development starts it becomes easier to see the finish line, but that doesn’t matter to a customer who wants a price tag upfront.

And that’s where the biggest problem with estimation lies. Clients don’t always understand these difficulties, and there are pitfalls that can come along with bad estimation. Aim too low and you might be stuck with an enormous project on a tight budget. Fly too close to the sun and you might scare off business. So how do you find a warm spot? Here are a few strategies that help us navigate the cone of uncertainty.

Part One: For Clients

Respect The Cone

Estimation anxiety is an unfortunate reality of any software development process. Unless you’re working with a developer offering turnkey, commercial off-the-shelf (COTS) software platforms, there is always going to be an element of the unknown. If you really want custom software development and not a templated, pre-built solution, the process is going to come with an extra layer of complexity resulting in a bit of guesswork at the beginning of a project. This is practically unavoidable. More experienced developers can give you a more accurate estimate, but it can still only be an educated guess. The fact is that when it comes to custom software development, your app is like a car at a mechanic (hopefully without questionable sales tactics). Before opening up the hood, a mechanic can’t accurately tell what’s wrong with the car, just like a developer can’t accurately predict what’s going to go wrong (or right) with your software project. The estimation phase is difficult for this reason, so it’s important to understand that from day one, you might not be able to get a complete estimate.

Know what you want

Have you ever been in a restaurant with a person who waits until the last second in line to figure out their order? Then you know how it feels to be a developer trying to elicit requirements from a withholding or uncertain client. As a customer, one of the best ways you can help in avoiding problems with the cone is to know exactly what you’re looking to have built from the start of the process. Before you even start contacting developers, do research on your own. An app idea needs to be more than just “Uber for X.” Software developers break down projects in terms of features and both functional and non-functional requirements, so draft a list of all the things you want your app to do. A good way to start is to compare existing platforms. Telling a developer that you want “Yelp-style interactive maps” is a lot better than saying “a way for people to find (insert service here).”

Trust Your Dev Team

If you’ve found a developer who’s got a great track record, awesome testimonials and an open and transparent process, congratulations, you’re probably in good hands. This means that you should feel comfortable trusting them to give you the full picture and price the project honestly and openly based on what information they have access to. If a developer tells you that they can’t give you a complete estimate, it’s because they don’t want to mislead you. A dev team telling you that is much better than a developer making golden promises that they later can’t keep. When you’re in the estimation phase, a developer who knows what they’re doing will explain the cone, and hopefully, after reading this, you’ll be up to date.

Part Two: For Developers

Don’t make promises early, if at all

One surefire way to get yourself into a development pickle is to make big promises at the very beginning of a project that you either can’t keep or can’t keep on the initial budget. The estimation phase of a project should be a time for just that: estimation. Explain to your customers that it’s nearly impossible to predict exactly how much a product will cost, but that you’re doing your best to get as close as possible. Hopefully, they’ll realize that you're not in a position to be making concrete promises and that an educated guess is the best you can really do. Be sure to mention that once you start you’ll have a much better idea of what the scope of the project is and what the final bill will look like.

Give yourself some wiggle room

This strategy (when implemented correctly) can work very well at mitigating the risks associated with estimation. It involves padding your estimates so that you have a bit of room to play with when it's time to get programming. Pricing with a bit of cream on top can lower your risk of getting burned on a project that ends up taking longer than expected. But don’t get greedy. Your clients will know what you're up to and hightail it to the next agency in town. Be transparent and honest and explain the issue the way it is and why it’s a problem. They’ll understand. And if they do take their business elsewhere, you haven’t lost much besides a potentially frustrating project.

Compare and contrast

A reliable way to figure out how long a project will take is to compare it to ones that you’ve executed in the past. Does the product resemble something you’ve built before? Do you suspect you’ll be using a familiar framework? Are there existing tools or platforms that will allow you to iterate more quickly? These types of things can shave time off of a budget. The same goes for projects you know will be difficult. If a customer wants features you know are a pain to implement, you can give yourself some time to deal with them. Overall, comparing to past projects and itemizing a list of components can give you a pretty good picture. This is where time tracking tools like Toggl really come in handy, because you can use previously collected data from past projects to help you measure what everything will cost.

Be clear about definitions and requirements

This part is important. Defining requirements well can be the difference between a smooth project execution and a development nightmare. Work closely with your client to figure out exactly what it is that they’re looking for. Break the product down into components; lay out what features they absolutely need and which are “optional.” That way you’ll know what their expectations are, and using the methods above, you can more accurately price their product. Also make sure you get everything they want during the estimation phase, and tell them to be candid. You don’t want to become mired in feature creep, with a client continuously requesting new features and additions.

Take it as it comes

Take a trick from any freelancer’s book. Get a small deposit before you start, and you’ll have something to start with that you can use to get a better idea of how long the ultimate project will take. Some clients will like this because the payments are spread out. The danger here is that you may take a deposit thinking you’ll be in the clear, and then stumble into complications that severely hike up the price. This is where padding comes in. Make sure to give them your best estimate of the total price, and don’t ever sign with a client who may run out of money before you’re able to finish. That’s why it’s important to get your clients to be upfront about their own budgets. If everyone understands each other when it comes to budgeting, nobody’s time is wasted and nobody’s feelings are hurt.