Why Your Estimates Are a Disaster and How To Do It Right

Sometimes the greatest meals on vacations are the ones you find when Plan A falls through

– Anthony Bourdain

How long will it take?

One of the most common questions I receive that I always try to avoid answering (generally, I flat-out refuse) is, “How long will it take?”. It may seem like a straightforward question, and in many industries, this may be entirely possible, but how often do you hear about project overruns? In software development, I would argue that it is impossible to answer. Why? Well, many factors will get in the way of an accurate answer. The main issue for software development and any creative industry is what you are asking me to do has never been done before. If you are an entrepreneur, with an entirely new product or service, this is likely to be the same as well. If you have never done something before, then you won’t even have a feel for how long something will take. You don’t have another project that is the same, for which you can say we did that in 2 months last time. Note I said, ‘the same’, not similar. Similar means that there are differences and those difference could mean a week, a month, or a year of extra work.

Making an estimate

A basic option here is to apply a multiplier, that allows for extra time for unforeseen issues. Inflate your time, then you can under promise and over deliver! You finish early, and you win, you finish late you still lose, but at least you added extra time as a cushion, right? Another method, (which I used to use), is to break down the project into chunks and try to work out how long each part would take. Taking it a stage further, I would put it into a Gantt chart, and factor in work streams that were dependent on others to be completed. We even used to get each team member to estimate it, and then take an average, or even the longest estimate for each task, to make use of the wisdom of crowds. You must be thinking, surely this works:

• Break it down task by task
• Assign the longest time from a crowd
• Build into Gantt chart, to take account of dependencies
• Double it and add 10%

The last step may be a bit of an exaggeration, but you get the point. It was probably better to think of a number between 1 and 10, then apply a random multiplier than go through the waste of time of that process.

Why not plan out the full implementation?

The reason or one of them is, with something novel, like software design, unless you plan out exactly how something is going to work precisely, including every detail, then the unknowns that are left behind can make the rest of your careful planning look like a drop in the ocean. The last 1% can often take 90+% of the time. Why don’t we plan out exactly how it is going to work, in detail, and then give an estimate then? Well, that is most of the implementation time. For software development, and similar, that is the work; it is not the typing of the code. Anyone can type instructions into a computer; it is working out which instructions and how they all fit together, in the wider system, which counts. The unknowns in your business may not be how to make various versions of software libraries work together; it may be the availability of raw materials. In 2018, there was an unexpected carbon dioxide shortage, in the EU, affecting amongst others soft drinks manufacturers. It may be staff illness, staff shortages, or even the government creates a new bank holiday, and so on. There will be plenty of clever ways presented to you, on how to account for these types of setbacks, but in my experience, they are all a waste of time. Even long-term planning in itself is a waste of time. You could also invest time in keeping your client up to date at all times with setbacks and delays, so, that they are always in the picture. A regular dialogue may be enough to maintain a healthy relationship with some clients, but even if this is so, what was the point of the original plan if both parties know it was always fiction? If the client is yourself, as you are developing a new product to take to market without a specific end client (try to avoid this if possible), then do you inform yourself of the setbacks, then move the imaginary finish date back and forth on good and bad news? What does this achieve?

All plans aren’t equal

There are plans, and there are plans, and not all of them are equal. It may seem obvious but, the number of things that can go wrong will increase with the length of time that a plan covers. You can probably factor out several unforeseen circumstances in your 5 – 10 tasks on your to-do list for tomorrow, that would not be possible to see months out. It is not a guarantee that tomorrow will go as planned, but it is more likely to than a more extended period. Also, the most you can have lost is a day, you either do it tomorrow, or you don’t. As I get to my quarter level planning, when we are talking about higher level planning, rather than too much detail, I would typically put a handful of desirable but not essential tasks into the mix. Jobs that would be nice to get done, but that are not the end of the world if they jump to the next quarter or get dropped altogether.

Use a Scoping Project

So, getting back to the question, “How long will it take?” I give the honest answer, “I don’t know”. What I suggest instead, is to agree on an initial timescale or budget. As you get further into the project, firstly, the timeframe to cover with an estimate is shorter. Secondly, you will have already started to answer the questions posed; then you can give an idea of what you can reasonably achieve within the time. Keep this period short, and then suggest a follow-on project, as details emerge. Using a scoping project you can fix the timescale, it is the product or service that becomes fluid. That way key features can change if necessary without throwing out the whole ‘master-plan’, priorities can change, and you can be more responsive to changing situations.

Keep Agile

Without writing a completely different book, this type of planning is called agile project management. There are many great resources on how to implement the details of these planning techniques, so, grab yourself a book. Just remember, not having a detailed ‘master plan’ is not a way out of delivering. It is a way to deliver that sticks to timescales, that is flexible, that keeps the customer involved, and ultimately creates a better working relationship, and trust between you.

Don’t bury your head

So, we have discussed why you should waste time planning a project, in detail, for an extended period, concerning delivering for your client, but there are other reasons why you should be careful with long-term plans. When you have a plan, and you are working on completing it, then you can become so focused on the detail of the project, that you ignore the bigger picture. You become plan-blind. While this is great for powering through your workload, and in the short term (days or weeks) it is not the best strategy in the medium- (months) or long-term (years). When you bury your head, you don’t see the bigger picture; your plan doesn’t exist in isolation, there is an external context in which it resides. SwiftCase helps thriving businesses, swamped by growing demand, automate and organise, to focus on what matters — loved by 1000s of users across Insurance, Finance, Legal, Service & Contractor sectors.