The next difficult thing after predicting the cost for products you make is calculating an implementation time for them. When the client asks how long it will take, you probably reply that it will depend on many factors and approximately will take… So, what makes you say “approximately”? We’ll tell you about real software development estimation difficulties.
When you do the first estimation you already know that product wouldn’t be ready by this time. And when the time will come, your engineers will tell you the next estimated time to fix bugs/test/finish or eventually launch the project. So, in the end, you will receive the total estimation time that equals the sum of the infinite estimates given by the engineering team over time.
What is interesting you could hardly predict those all additional estimates were going to be. And because of this you can not see the whole picture and predict the end time to finish your project.
This article is the hint for your further estimates and assumptions you will include in the proposal for the client. What factors can affect your project schedule and how to calculate them? They’re below:
- Optimism: Engineers think that they work faster than real life indicates. Usually, it takes longer. So listen what they say and add at least 30% (or more if you better know your engineers).
- The unknown: Random things are always unpredictable. Maybe an earthquake caused an outage in a data center. The engineers might all attend some protest action. We just don’t know. Factor it in.
- Time off: Even if the engineers typically don’t take vacations, they maybe need time off to recover/ to visit relatives/ to spend some time with family and manage their own business. Consider that project managers take vacations often and tend to turn off their phones, so for engineers to stay on track you need to think of other people for constant reminding and monitoring.
- Team offsites: Nothing creates better productivity than motivation. To provide motivation we need to spend some time to grow team loyalty. Consider that on too.
- Meetings: Where would organizations be without meetings? The more meetings there are, the more productive the organization is. But meetings also take time (including requisite pre-meeting meetings and post-meeting meetings) detracts from time actually spent writing the product code, so we factor it in.
- Mentoring: A healthy organization is constantly hiring and growing new talents. And these new people usually don’t know the important things about their new roles. So the company needs to draw upon the vast experience and limited time of the experienced engineers to train these new recruits.
- Turnover: Sometimes engineers will leave the company and this dynamic shouldn’t be seen as a negative. It should be rationalized with upper management as an opportunity for the organization, paving the way for fresh energy and cheaper salaries for new employees. This item is related to the previous one because turnover creates places in the group for new talent, which must be mentored. But here the time should also be spent recruiting and interviewing.
- Re-scoping: Engineers always take the customer at their word. And often the project’s goals and functions change during the development process. Sometimes they were not clear enough, so you need to start from the beginning again. When the project needs to be re-scoped the implementation time lengthened accordingly.
- Fudge Factor: Sometimes some circumstances are beyond our control. There’s nothing worse than under-estimating the schedule, especially if that means under-billing for the job. So please add a final fudge-factor to account for these inherent inaccuracies.
You have to know that each of these factors should have a doubled time. If you will succeed with your project in less time – congrats! These will make everybody happy including your client. And your team will gain a status of super-professionals who can do work faster. So don’t underestimate your software development schedule. You always think you spend less time than history indicates, so take this into account.