How to deal with underestimated projects

Photo by from Pexels

We’ve all been there. Who hasn’t had a project that was underestimated? There are many reasons this could happen. In this post, I will focus on how you can handle such situations, rather than looking for the possible causes – it’s not helpful talking about this when it’s already done, so I’ll leave that for another time. 

I will group underestimations as follows: 

  • The whole project is underestimated – this is the worst situation to be in.
  • A particular milestone is underestimated – not tragic, but not obviously not great.
  • Particular features or sets of requirements are being notoriously underestimated – an annoying situation, but possible to fix.

When the whole project is underestimated

This is something you can come across as you prepare for the project to start, or as you are already halfway through. If the project development has not started yet and you already have strong signals you don’t have enough time or resources to deliver it, you may still have some flexibility and a couple of moves to make.

First off, if you are a project manager, report the issue to your supervisor. Make them aware you don’t think it’s possible to meet the project schedule. Your supervisor may already be aware of the issue and the losses they will incur by completing the project. This may be something they are doing on purpose in a bid to win the maintenance work contract, which may be more lucrative than the initial development. They might also be holding on to a prestigious client for marketing and branding reasons, or maybe they badly need to deliver this specific project in order to achieve something else. 

Either way, you know you are covered because you have alerted them immediately and they are aware of the problem. The next thing you can do is lower the buffer between yourself and the management and the client. This will reduce the stress of running the project, and therefore the technical risk will be lower and the team will be happier. 

The situation is more problematic if your supervisors are not aware of the project being underestimated. Still, if you catch it at an early stage, there is a chance the project can be re-evaluated (which would be the best case scenario). If the manager decides to carry on with the insufficient budget, you should focus on the core deliverables and streamline the work so that eventually, when you reach the deadline, you have something that works for the client. It’s ultimately better to show less features that work, rather than a bunch of non-working screens. It is possible that the client is happy enough with what you deliver to agree to increase the budget for the project.

In case you are running a project for a set amount of time and at some point you realize that you are way above the budget, things start to get nastier. Depending on how bad the situation is, there are some options that can make it a little bit easier. But only a little bit –  you should still prepare for a hard landing

Regardless of the situation, you should notify the supervisor, and you must have a conversation with the client. Letting them know in advance is crucial. It is a bitter pill to swallow, but you must remember that they have trusted you and plan their business according to the plan you both have agreed on. Not letting the client know about the insufficient budget or missed deadlines is way worse than losing some revenue. Additionally, if you have reasonable arguments about why your original estimation wasn’t good, it may be relatively easy to extend the budget or deadline.

Firstly, assess how bad the situation is. Is the estimation short by 25%, or more? Everything below 25% is bad, but salvageable. Here’s what you should do in this case: 

  • Identify low priority, nice-to-have items that you can skip.
  • Focus on delivering the high priority items.
  • Move features to other milestones or group them with other. requirements

None of the above are supposed to cheat the client! You should always fix your mistakes in a way that favours the client. It’s more like when in accounting you move some items along the spreadsheet columns to get some breathing space. Eventually, the annual report WILL reveal everything. But what this will do is allow the project to keep going while you move features/requirements freely, keeping in mind they will have to be delivered in the end.

Any situation where you are missing more than 25% of the necessary time/resources is really bad. You may buy some time by doing the things I’ve mentioned above, but you most likely won’t be able to deliver on time or within the budget. In this case, it should be your priority to have a meeting with the client and inform them about the mandatory updates in the schedule and budget. I wouldn’t like to be in your shoes in this case but… These situations at least teach us and help us grow.

When a module or milestone is underestimated

This is a less dramatic situation, yet still unpleasant if the milestone is relatively big. Any of the solutions I will describe assume one thing: before you move forward, you must understand why the estimation was wrong, what you can do to avoid this in the future, and implement changes. Without doing this, you will end up in the same situation over and over again. 

If the project in question is ongoing and new milestones are set on a regular basis, the situation is relatively easy to solve. You may do nothing – just deliver the requirements as they were originally estimated. Apply improvements and quote properly in the next milestones. You could also deliver everything but adjust the next milestones to cover the extra expenses. But this strategy would only work if you have a longer timeframe. 

This may sound unfair to the client, but that’s not how I see it. If something is undervalued, the normal course of action is to do some things more quickly or with less attention to detail in order to fit into the budget. Such an approach of cost-cutting will end up as a technical debt, which will keep growing and eventually become bigger and more expensive than the additional costs you will incur in the original project. 

I believe that my suggestion is fair for both parties, as the client receives a quality product for its actual price and you are paid for your expenses. Of course, there is a threshold of how much you can move to other milestones. You should use common sense when doing such operations and always play them in favor of the client.

When features are underestimated

What I am referring to here are small updates that the clients occasionally request. These are usually small items that you can deliver within a day or a working week. They are often atomic, touching particular functionalities, and are the worst items to try to estimate as an initially small requirement can turn out to be something much bigger. That’s when you need a very strong Plan B.

There are three reasons that can drive you to this situation. 

  1. Your team is not estimating correctly. Maybe they are too confident, not experienced enough, or they are unaware of the whole scope of the project so they stumble on every edge case possible.
  2. Your client keeps adding new details to one requirement. For them, adding a simple checkbox seems like just 15 minutes work. 
  3. Edge cases are not explored enough. And if you have such expanding requirements, like the above checkbox, the problem grows exponentially when combined with weakness in the team. 

Following the above, to improve your estimates when it comes to features, consider the following:

  • Look at your team through a magnifying glass. You need to address any issues with their confidence and experience early on. 
  • Make sure you receive correct, in-depth, quality information from the client about what they want. Have a look at our GIGO blog for more information on how you can do that.
  • Make exploring edge cases a key part of your estimation process, giving yourself enough time to really explore all the possibilities.

It’s important to identify what went wrong in your case – keep in mind, every project has different weak spots!

In conclusion

At one point or another, you will end up in a situation where you are working on a project and realise you underestimated it – it’s simply inevitable. What you can do to avoid this as much as possible is to revisit your estimation process on a regular basis (eg. quarterly). 

If you have any golden rules about how to handle underestimated projects, please share them in the comments!

Leave a Comment