Making good estimates and ways to reduce delivery dates

Making good estimates is very important because it keeps the project goals, dates and budget in a healthy state. Sometimes we take the easy path and just throw numbers for the budget and the time that it takes to deliver the project, but that's a bad practice, we must review documentation, experiences and the people involved in order to give a good estimate and support our numbers. The best way to obtain support data is through old projects and similar situations, this information should be easy to obtain if we keep track of what was the real budget and the real dates of delivery of all the projects.

First I will talk about the required steps to have good time estimates:

• Divide the project in tasks. This is the first thing you need to do. Each task should take around two through five hours to complete, some tasks might take more time or less time, for example, certain tasks are very important and they need to be isolated, or it could also happen that they need to be completed all at once. Something else to take into account when dividing tasks, is to keep them as self independent as possible, meaning that there's no dependency on another tasks. It's always easy to estimate the time required for small items than the one required for big items, this can keep you focused and find additional requirements/documentation/people that you will need to complete each task. This also helps when you're looking for similar situations in the past, it's easier to find a matching similar situation when tasks are divided properly. Another good thing about this is that it helps in understanding if some tasks should be made by another team, for example, in some cases, testing accounts can be provided by another department because they know better what are the things that they want to test.

• Review old projects and find similar situations. This is the best way to know how much will it take to create a similar project. Take into account that if the new project is really similar, we may end up finishing it sooner than expected. This is because in most projects, there's a learning curve for items that needs discovery and reading documentation.

• Poker game. When deciding the amount of time required for a task, it's a good idea to have the opinion of one or two experimented members of the team, they always see something that is missing for the other individuals, and that could be key to set the estimate for the task. Keep in mind that if the estimates provided are very different, is a smell of insufficient data to set the required time for completing a task.

• Pre-steps, Post-steps. It's important to know if there are another things needed to start and to finish the task and add it to the estimate. For example, you might need to create a branch for working on the task, set up a new account for a system, wait for a testing environment, etc. Those are the pre-steps, but when you finish the action items of the task, there might also be another post-steps, like creating release notes, sending out an email to the business owners, deleting testing accounts, etc.

• External factors. Network team is too busy to set up a testing environment? Working with the financial area in a time that they cannot provide information fast? Can you release the software project in the date you selected?. This and many other questions are important when creating an estimate and deciding on dates of delivery, if you have been in a similar situation before, it could be easy to know when some external factor will be affecting the date of delivery.

There are many things to take into consideration! but something to keep in mind is that you should stay as "optimistic" as possible, meaning that you cannot put as a support to your estimate, the fact that there could be an "Armageddon" tomorrow, and your project might not be completed on time.

There will be situations that can delay the delivery date of the project, but they should be addressed at the moment that they happen, and the project should be reorganized accordingly. Another thing that I would like to talk about is ways to deliver the project in less time, and with less effort:

• Get all the team interested in the project involved. Software projects are not completely developed by the software team. If there are going to be changes to the some department systems, it's a good idea to have them involved as much as possible, and even assign some tasks to them (like finding testing accounts, providing data analysis, etc). The outcome of this will be early checking the requirements of the departments and based on that, planning the next steps, on the other hand, the departments can know how's the project going, what are the expectations, provide early feedback about features, and give relevant data for testing.

• Buying systems. Many projects are similar to current systems in the market. If you can buy a system that has a decent trade-off between cost/value/quality, think about buying it and customizing according to your needs. You should buy a very known system in order to trust that it has been deeply tested and that can reduce the time required for delivery.

• Request help from another company. If you have the budget, it can be useful to have another company help you, specially if they're experts on the system you want to develop, this can be cheaper than expected, because they have passed the learning curve and can save you a lot of time, and allow you to focus on another projects that can only be developed by your team.

That's it for now. I hope you enjoyed this entry. Let me know if you have any questions or if you would like me to talk about another topic. Many thanks readers!