Time estimate against money
Once I had a taxi driver who was working for me for more than a year. He was always on time to pick me up and his estimation about arrival time at the final destination was always accurate. His estimation and reliability was important for me to get to meetings on time. At some point his personal troubles reflected on his work - he was not in time anymore and his estimations diverged. This has led to situations in which I was late for my meetings - a few times. So I ended working with him. I would conclude that time estimation is important to every business.
When we talk about time estimations for a software development project we actually talk about money and “happy clients” as one of the most important software development targets. Time estimation is the ability to correctly plan the amount of work against time for software development team efforts. The purpose of this “exercise” is to build trust with your clients through providing a correct timeframe and make it possible for the client to plan their schedule and especially their budget.
It is extremely important for a client to have a realistic idea of the money that they need to spend on their project. Just imagine what would happen if you presented a wrong estimation to the client at the beginning of a project. For example you say the software development team can do the work in three Sprints, so in a three - month timeframe, as a Scrum team works in one month sprints (check if you are really Scrum or rather Scrumbut through answering the questionnaire). Then some unexpected issues arise during the software development work, which leads to missing the original estimated deadline. Add angry clients to this situation who put under suspicion your professionalism and… congratulations, you just got the lowest rank as a software development company.
The conclusion of the above situation: the client's dissatisfaction is due to the fact that their plans to get their working product on the initially agreed time are spoiled and what is more disturbing - the client will probably need to pay extra money.
What to do in cases of software development underestimation… or better said: overpromising.
Although such situations in an experienced team with a good project management are rather exceptions, you still need to always be smart and have your own methods to avoid such cases.
Here are some ideas on how to react in case of a wrong time estimation given to the client, no matter of the reason, and eventually have a happy client.
First do your best to prevent it:
- Add extra time to the actual time estimated - discuss with the developers the option to always add some extra time to the time they consider that would be necessary and enough to complete a task. Agree on this rule at a company level and make it a standard to be observed, especially by developers.
- Include a clause in the contract with the client - every software development company is expected to agree with a client about terms and conditions before starting the software development work. Use the contract with a client to add a special clause that warns about possible delays in the software development process due to unexpected issues. The client will be prepared for this scenario and would not have a reason to argue.
If it turns out impossible to prevent, then surmount it:
- Communicate regularly with the client – when they are involved in the whole development process (update them on the project status, issues, bug fixes, etc.), they feel more comfortable and build trust in you. On the other hand when you have closer relations with them, you will feel more comfortable to inform them that their project development will be delayed due to some specified reason. They will be fine with this because you have already proved the software development team is trustworthy and your company has always succeeded in resolving any issue in the best way.
- Compensate the client - if the software development team misses the deadline or is due to exceed the initial time estimate provided and you realize that it is your fault no matter the reason. How to make the client happy - compensate them through free work until the software development team completes the project- after the deadline or beyond the time estimate given
- Always keep track of new or changed client requirements and update the time estimate given accordingly (see lso article: documentation vs company failure) - create a first draft of a specification and agree on it with the client. All new requirements, even the most insignificant, also every amendment on the requirements needs to be recorded in a new specification version. In most of these cases the time estimate is affected and often needs to be increased. Send those new specs to the client, thus they will be informed in a timely manner about the expected delay and the new time estimations.
Support software development work with smart tools
A software development company would be helpless without tools, especially the tools created to support the developers and their work on projects and tasks. When we talk about the time estimate of a software development project we will mention the Burndown chart. It is a regularly updated chart that represents the quantity of work left to be completed against time elapsed since the start of the project. For Scrum teams the work amount displayed in a chart could represent work remaining to be ‘Done’ in a single sprint, or another option is a representation of the work remaining to be completed for an entire project.
This graphical visualisation of work should be transparent- placed on an easily accessible place not only for the whole team but also for the client. Therefore everybody will be informed and even if it is visible that you are not on a good track, at least the client will know about that and you can take actions in time to improve the situation.
Planning and time estimating a project is not easy because the software development team needs always to be ready to expect the unexpected (see also article: Planning poker cards). Software companies should do their best to provide an as accurate as possible time estimation.
Select the best working approach for the software development team to be accurate when making time estimations and based on management decisions create rules in the company that will guide the team on how to react in case of underestimations.
The winners are those who make the client happy, satisfied and trusted. Always put yourself in the client's shoes and think in terms of the client's budget.
What are the proportions between accurate project time estimations against underestimations in your company?
How do you cope with situations where the client is unhappy about wrong time estimations provided by your team?