When a potential client asks me, “How much and how long?” a million questions start rushing to my head. A seemingly obvious thing to do first is to figure out what exactly it is that they want; however, that’s very rarely well defined. Let’s assume though that you have at least a decent idea of what it is that they want, estimating the costs involved is such a delicate balance.

Over and underestimation:

You don’t want to underestimate the number of hours too much because then the client suffers from the loss of predictability. Depending on how the contract is worked out, someone is going to lose money. If it is a fixed cost project, then the developer loses because he has to spend more hours but doesn’t get paid extra for those hours. If an hourly cost, then the client loses even more since he has to pay for that extra amount on top of the delayed project. (This applies to in-house developers as well as they are often hourly).

At the same time, overestimating isn’t a great idea either as it can prevent development from ever starting if it’s too expensive or it could lead to dissatisfaction of the client. It might not be as bad though if the contract is hourly based, since you will beat the client’s expectations.

I would say that the majority of contracts are underestimated, in which case both parties can lose. At first, everything seems easy, which is a primary reason for this, but in reality, even the simplest products can require a lot of work. This is mostly due to the lack of planning. When you first hear of something, you are not really going through all of the possible cases that might occur. It’s not until you really sit down and write it all out do flaws or issues appear, and this is a step that I often see overlooked by engineers or clients.

Simply not planning isn’t all of it though; the other side is being honest with yourself. A lot of times you can talk an engineer down from some number of hours by saying something like “It’s only PHP.”, but what’s happening is that they are really just kidding themselves. An experienced engineer knows that problems always arise, no matter what, and they should know how fast they work better than anyone. When it comes to estimating the hours, you simply need a bit of buffer. Whether you’re truthful with yourself or not, the project is going to take the same amount of hours. There is also a temptation to say a smaller number in order to win a project or appease someone else. There should be a bit of play in the numbers, but if you’re lying, then you are only going pay for it later.

For the Developers:

My advice to all developers is to be honest with yourself and the client, and the best way to do that is do the research first. I find that simply re-writing all of the requirements given from them in my own words really helps to flush out potential problems. Even if they have given me a requirements document, I will still rewrite the important portions to make sure that I am clear on what is being asked. This also prevents misinterpretation, which thus prevents wasting development on the wrong aspects. For problems found, I include my suggested solutions or any questions that I have in the document, and I send that to the client to get their conformation or feedback. After which it should be clear to both you and the client as to why it will take as long as you say it does. I also find it easier to estimate the hours once it is all written down because then I can just apply an estimated number of hours to each requirement and merely sum them all up.

For the Clients:

To the clients my advice is to understand that if an estimated number of hours seem rather low, then it probably isn’t realistic and expect to pay more and/or have a longer delivery date.

Of course, everyone wants the cheapest price, but I can’t stress this enough, integrity is perhaps the most important factor when it comes to estimating projects.

Tweet This Post