The whole thing takes longer
When programmers, project managers, or even CIOs estimate development tasks, they often forget to allocate time for:
- Solving problems that unexpectedly occur as the project progresses, such as hosting issues, third party modules that do not work, integrations to external customer/vendor systems, etc.
- Minor corrections and changes. There is a 100% certainty that changes and additions will be made to a project after it starts. Allocate 20-40% more time in the budget for these tasks.
- Set 15% for meetings, status reports, and the like.
- Set 20% for testing to be done by an actual software tester and not by the same programmer.
- Training on how to use the system. 8 out of 10 clients need help in the start-up phase, so make sure to allot time for it.
Important reminders for task creators and developers
For task creators
- Review the estimates. Are meetings, minor changes, testing, trainings etc. taken into account? If not, add it.
- If you are collaborating with a supplier−may it be a freelancer, a company, or even your neighbor's son−do not let them know that they sometimes unintentionally estimate fewer hours than they should to get the job (though there are also cases that they do this on purpose). They know that when the task has started, it's hard for you to switch supplier. Be sure to always go with the lowest and cheapest deals.
- Be hands-on. Make sure you are briefed by the person responsible for the development of your project, at least twice a week, per week, by phone, or face to face. You need to know what's going on all the time, so you do not get unpleasant surprises.
- When a problem arises, take the bull by its horns and find a solution. If the problems are pushed under the carpet, they end up getting much bigger.
- Always set extra time for meetings/status updates, testing, changes, and additional features. Remember to explain to the task maker why you should spend extra time. You know why, but often the task creator doesn’t know about it.
The task creator never knows all the needs of the project before it starts.
The needs arise as the project progresses, when users try the system, or when markets change. The programmer or developer cannot predict which changes and additions the task creator brings - therefore, IT projects always take longer than you expect.
By making small and short projects, you reduce the risk of losing money, as you can change courses after each small project if what has been finished turns out to be wrong.