A mistake that many developers (including myself) have made in the past is to over-promise and under-deliver in terms of the absolute deadline or the number of hours taken on a project. Getting to the “missing the deadline” or “being over budget” stage can be especially demotivating – you’re costing yourself (or your company) time, which is valuable, and also the client is likely to be getting slightly irritated (if you are late). The steps or methods to reduce the chances of this happening in the first place are simple, and easy to use.
1. Make sure you understand the problem in full.
Generally, when we are presented with a problem by either a client, or a project manager, the problem has been simplified somewhat. A 15 minute phone conversation or meeting is condensed in to a three sentence paragraph asking you the best way around a problem. In my eyes, there are a couple of approaches to avoid this.
- Be involved in the meeting, or the phone conversation. This is not always possible – not every developer wants to be interrupted every 30 minutes by client questions, and not every developer is necessarily comfortable talking to a client. But listening in on (and not participating in) a conversation could always be an option! This means that you get to hear everything that the client has said about the problem. It’s to be expected that the person relaying the message will miss out minor (but not necessarily insignificant) details. After all, repeating every phone conversation in full could get a bit tiresome, you’d imagine!
- Know to ask the right questions. A client asks to make their delivery fee increase with every product added. Let’s say, increase the delivery fee by 30% for every additional product that needs delivering. This is simple enough, until you consider that the delivery fee could easily escalate way out of control. A £10 standard delivery fee could soon escalate to around £50 if someone bought a large amount of products. This could discourage a purchase. So should a limit be introduced for the maximum delivery fee? Remember, the client probably hasn’t thought around this issue. Asking the question and getting an answer before work starts could save you from having to rewrite a chunk of code.
2. If dealing with unfamiliar technology… allow some research time!
If you’ve been asked to implement an unfamiliar technology, take 10 or 15 minutes to research how it all works. 15 minutes spent now could stop you from estimating that something will take 5 hours when it might take 20, or from estimating 20 hours when it might take 5! Additionally, when estimating how long the work will take, remember that you will probably spend a fair chunk of time reading documentation and not actually writing code. In many places this would be considered billable time – and it should certainly be taken in to account when working out how soon you could deliver the work.
3. Remember to allow time for testing and bug fixing.
Not everyone does this, but in my opinion it is essential. Allow some time for proper testing and the time it’ll take to fix bugs (this can only be estimated) as well as the time taken to write the code in the first place.
4. If dealing with third party services, you can’t accurately promise a deadline.
A lot of the work I do involves integration with third party services – payment gateway services, SMS services, etc. These all involve an account application and signup process, and sometimes this process depends on the client completing a form, or submitting payment for the service. I have found that it is almost impossible to accurately estimate a “go live” date when an aspect of your application depends on a third party service being ready for use. If you do provide an estimated go live date, it could be worth putting in a note that it depends on the client’s service X application being complete by date Y.
5. If you feel out of your depth, don’t be afraid to say!
This is a very important point. If you are not confident about working with and fully understanding the technology that you will be using, tell your manager or your client! It’s better to say at this stage than to blindly assume that you will be able to work something out during the work. They will be a darn sight happier this way around than if you go out of your depth and then the project is late or massively over budget. Saying now typically will have one of three results:
- Your company will turn the work away to avoid a problem (or, your client will go elsewhere).
- Measures will be put in place to avoid the issue. Billing by the hour, or using another developer, for instance.
- The project will be quoted anyway at an estimated rate, and your company will take a risk. In this case, you at least said something at the start – the risk taken was by someone above you.
These are only very basic steps that can be taken to avoid a problem. But one thing is for certain. It is typically better to under promise and over deliver rather than the other way around. You just have to be careful that you don’t fall in to the habit of *massively* over-quoting projects, because this can have a detrimental effect in terms of reducing the percentage of accepted quotations.
