McKinsey found that 66% of Enterprise Software Projects Have Cost Overruns! We are officially an industry that is terrible in software development time estimation.
McKinsey also quoted:
“As staggering as these findings are, most companies survive the pain of cost and schedule overruns. However, 17% of IT projects go so bad that they can threaten the very existence of the company.”
In this article, let’s find out why software time estimates go wrong and how do you correctly estimate the time required for a software development project.
We are in the software development business for more than 8 years now, but still, if anyone asks me “How long does it take to build a custom software”?, my answer would be “It depends”.
This is because Custom software development is when specific software is tailor-made to fit business’ unique requirements. Different businesses will have different kinds of requirements and thus time will also vary.
There is an ongoing discussion on whether custom software development is equivalent to building a house or not. This metaphor makes sense on the surface but if you dig deep, this loses momentum.
With a house, the scope doesn’t change according to changing requirements, sudden complexities in development don’t creep up and there is no need for testing every part of the house, over and over again. So, software development is not exactly similar to building a house!
In this article, we will cover :
Time is a commodity that everyone desperately needs, but there is never enough of it. So, a software project cannot go on indefinitely.
Estimating software time is advantageous to both Software vendors as well as clients.
1. They get to picture the whole scope of work and accordingly decide the launch date.
2. They get to know the cost associated with software development.
3. They can accordingly plan for acceptance testing, product launch etc.
4. If the client is outsourcing software development, there will be optimal transparency in the whole process.
1. They know what to prioritize
2. They can dedicate resources according to the time estimate
3. If they are multi-tasking, they know where to spend their time and how much
As you can see, accurately estimating software development time is advantageous to everyone associated with the software project. However, estimating time correctly is not an easy task.
Again going with the house reference, you ask a real estate agent to build you a house. He agreed. Your pre-conditions were -
- 1 bedroom, 1 drawing and dining, 1 kitchen, 1 attached bath, and a balcony. It would take him 10 months.
- U come back and say, nope! Make it 2 bedrooms. It would take him 12 months.
- After a few days, you are like, Nah! I need 3 bedrooms, 2 attached baths, 1 drawing and dining, 1 kitchen and a huge balcony. The development time increases to 24 months in this case.
See what happened here. Estimations will change every time a new criterion is added to the initial requirement. Software development is challenging! More than often estimates fail and costs overrun.
What difficulties can put software development estimates at risk? We’ll list some factors that make software development time estimation challenging for the software development company.
1. Constant changing business requirements make it really difficult to stick to the estimates. This is why the “Business Requirement Document” should be your holy grail. Anything that marginally deviates from the requirements and needs re-development will need additional time to develop.
2. The time associated with R&D is sometimes not taken into consideration while providing a mockup or it takes more time than what was estimated. A way to avoid this is to carry a basic RnD to figure out how long the actual RnD might take.
3. Designers and developers availability is also a major reason for project delays. The software development company that you hire might have a crisis situation and run out of software developers or they might be at capacity. Expect a project delay in such cases.
4. Not testing the software from Day 1 largely attributes to software project delays. The bugs that are caused after a finished product is delivered will take too long to fix and will be complicated too. Thus, the time estimate won’t match with the initial one.
We have divided the time-estimation process for custom software development into 4 parts. We are proud of the fact that BinaryFolks has been very successful in adhering to time estimates and has never faltered on what we promised. Take a look at the software development timeline estimation process below :
NOTE: This marks the most critical phase of the time estimation process. Keep in mind, the more fleshed out this stage will be, the more precise the time estimation will be.
Every custom software development is the result of some unique business requirements. Knowing and understanding the complete requirement is a necessity in custom software development, not a luxury - that a company can afford to skip.
How do you ensure that you made the detailed requirement analysis?
[a] After receiving the RFP from the client, go through it and note down each and every logical gap that you see.
[b] Prepare the software flow in your mind and write it down in an agreed format, as detailed and precise as possible. Compare the RFP with the flow and see if some more logical gaps come out.
[c] Meet the client either face to face or over audio/video and discuss the RFP. Ask him all your questions and close any logical gap that you had.
[d] Repeat this process until both the parties are absolutely clear with the requirements. Then draft the final Business requirement document (BRD) and get it approved by the client. Tell him/her very frankly that any extra changes or additions will lead to more expenses, both in terms of budget and time.
This process will avoid questions like - Why you didn’t deliver this feature, we are supposed to have this, no? A focused and detailed BRD acts as an informal contract that you can always go back to in crisis situations like this.
Documenting the requirements also help the software development company assess the timescales and resources needed to complete it.
Remember, it's usually much quicker to fix a problem at the analysis stage than it is when the finished software is delivered.
The requirement analysis part of the project takes around 1-4 weeks depending on the scale of the project.
Before any coding actually takes place, it is very important to thoroughly plan the software architecture - both for Front-end and Back-end. This will help largely in developer and designer collaboration and ensure that the software is stable and scalable from the very beginning.
Whatever architecture you choose for the software, always keep in mind that the structure of the code must satisfy each and every requirement of the software. Choose software architecture keeping flexibility, scalability, feasibility, reusability, and security in mind.
Planning and architecture generally comprise of the stack selection, database selection, class diagram, ERD, third-party libraries, APIs, etc. The deployment architecture needs to be kept in mind too.
Also, if your software project is to be divided into milestones, that flow needs to be completed in this phase too.
Depending on the size and complexity of the application, planning, and architecture takes about 1-2 weeks.
Now that your developers and designers are aware of the requirements and the architecture, adding flesh to the skeleton is the next job. This is the longest and the most time-consuming part of software development.
The design should be modern, intuitive and user-friendly. Following the milestones, the development parts need to be broken into smaller chunks so that the client can preview what has been done during the process. This is crucial as the client will be involved throughout the process and your developers will not have any last minute surprises once the product has been developed.
Designing and development takes about 2-3 months for small scale projects and 4-6 months for medium scale projects and can take up to a year for large scale projects.
All the projects must undergo end to end testing and user acceptance testing. Cross-browser testing is also something that must be kept in mind. If the application has many users logging in and using the system simultaneously, load and performance testing must be considered.
QA needs to be involved from the very beginning. This is because when QA is involved since the beginning, the no. of unexpected bugs are lower and are identified sooner. This means a lower impact on risk, cost, and timelines.
Depending on the size of the application and on the extent of testing required, it might take 2-4 weeks to run complete tests.
Now that you have a rough idea of the time software development takes approximately, take a look at a few best practices every software development company must keep in mind before providing a time estimate.
The business analysts usually deal with project requirements and analysis. It is very important that they know every requirement, every user flow by heart so that they can communicate well with the developers and designers.
Let me explain with an example :
Client - I need users to login.
If you say - okay, done; this vague sentence can vary greatly when it comes to the time estimate.
- What type of login - email and password or social accounts. If social accounts, what all social accounts?
- The fields need restrictions or not?
- How does password security look like?
Etc etc….. Every time a new point is added, time estimate increases. Keep this in mind!
Ask the team members to individually provide their own individual estimation and then discuss with the team and settle on the most doable man hours (Planning Poker method)
Work Expands to Take The Time Allocated to it: This is a very famous quote called Parkinson’s Law. This means if know a time estimate for work, you would take up the whole time awarded for that work; even if you don’t need the time.
To avoid this kind of situations, divide the whole project into milestones and keep time estimate for each milestone as short as 1-2 weeks.
Every one to two weeks, the team regroups and based on the progress moves ahread with the next milestone.
This is advantageous because when tasks are granular, it is possible to estimate time better and correctly than estimating the same for a project.
*** PRO TIP: At Binaryfolks, we break our milestones into other smaller sub-tasks to make the software time estimate for accurate.
Based on the requirements, choose the best team composition for the project. It is always favorable and recommended to choose a small team. Communication overhead increases exponentially when the team is bigger and with it, the estimation inaccuracy.
Along with small and compact teams, Binaryfolks has an added advantage of direct one-to-one communication with the CXO level employees.
If you have experience in working in a similar project previously, draw up the references first. See what work was done, how many man-hours were estimated, how many man-hours did it take to complete it. Take a look carefully at which areas time estimates went wrong and where time estimates were lesser than what was documented.
Then based on the data and the facts, take a call.
Always keep a 15-20% time buffer for unavoidable situations. For ex: If Company A that you worked for had a production emergency and you have to take out resources from the ongoing project and dedicate them for company A. Or, say, the lead technical architect falls sick and that delays the project for a few days.
A buffer will help you deal with these unforeseen circumstances and make your software estimate for realistic.
Read more : A complete guide for Startup Product Development
How much time software will take to be built depends on the size of the software and what all functionality and features it will incorporate. The no. of features pages, level of UI, Users & Accounts integration, dates and location integration, CMS, social media integration, billing and eCommerce, analytics, External APIs and Integrations and finally security - everything will affect the timeline estimation.
For a custom software development company, it is advisable to take a look at the past experience and historical data for a similar kind of project. See how it did w.r.t time estimation. Keep that in mind. Ask a lot of questions. Make sure that you are 100% sure of the requirements and project flow. Document everything. Keep a buffer in hand.
Keep the estimate realistic. Understand that your designers and developers have two hands each. Prioritize activities and tasks. Communicate well.
Looking to develop something? Have an idea in mind? We have some time. Talk to us over a free consultation and we will help you out.
We will never spam or share your email ID with others.