Your developer’s price estimate * π = the actual cost of your project

Estimated reading time: 3 minutes

The whole thing takes longer

When software developers, 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 plugins that do not work, integrations to external 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 developer.
• 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 bigger.

For developers

• 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 developer cannot predict which changes and additions the task creator brings - therefore, software 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.