Preparing estimates for software development projects is notoriously difficult. So, is there a scientific approach to making accurate forecasts of time and costs for new software? Given the variables you must consider when preparing an offer, estimations seem closer to works of art than to science, just like interior design. At the start of such a project, you have a vague idea of the result. You will have a list of colors, materials, sizes, and objects to choose from. As the objects come in many shapes and from lots of manufacturers, the project’s total cost may vary greatly with your choices. So does the time it takes to complete the project. For software solutions, the uncertainties come from the vaguely defined and constantly evolving specifications, the experience of the person making the estimate, and the composition of the development team.
What Makes Estimating Software Development Projects Hard?
All customers want to know how long their software project will take and how much they will pay for it. Unfortunately, no classes or training programs give us straight answers to these questions. The only certainty about the estimation process is its complexity. Yes, making spot-on estimations is more than difficult and unlikely. Research by McKinsey revealed total cost overruns of 66 Billion USD in the 5200 IT projects surveyed. Furthermore, “17 percent of IT projects go so bad that they can threaten the very existence of the company.” These numbers show our limits in estimating software development time. Given the nature of the process and the scarce information available at the time of the estimation, the overruns should not surprise us. Precisely assessing the duration of a project is next to impossible, as the estimator may know nothing about the project team.
Pitfalls in Estimating the Frontend of the Software Development Project
Frontend developers often rely on wireframes to estimate the projects. As a wireframe view fails to capture essential details of the design, the estimation will be inaccurate. Thus, a placeholder for a graphic element tells little about the time required to build the element. Most of the times, the estimator doesn’t have answers to important questions for the estimate. Will the client buy the pictures? Does the client need vector or pixel art? Furthermore, they are often unaware for which device types and screen sizes to optimize the frontend. Besides, the client usually prepares the content for the application long after receiving the estimate. Thus, the real content may demand changes to the mockups used for the offer. Differences in the font style and size and the length of the text will break alignments and grids within the page.
Why Is Estimating the Backend of the Software Development Project Difficult?
As a software development project has a front-end and a backend, the provider must estimate both components. In doing so, they usually rely on people with different technical and business know-how. Therefore, those specialists will build the estimates using different rules and skill sets. Furthermore, the client can provide too few details on the features for the project’s backend. Obviously, a person with little experience with your type of project can end up doing the estimate. To make things worse, that person may be unaccustomed to the 3rd-party services and some technologies the project should use. Another common pitfall is the tendency of people to use themselves as benchmarks when preparing estimations. Unfortunately, this habit adds imprecision to their predictions. Furthermore, the estimators may be overly optimistic about their capabilities and wish to please the client by telling them what they hope to hear.
Tips for Estimating Software Development Projects
Whether you can rely on past experience or not, estimating a software development project is tough. To overcome the hurdles and set yourself on the right track you can use a some of the following tips and tricks.
Do Not Rush Through the Estimation
Taking all the time you need to go through all the data you have is essential. Doing this might be the top factor in your estimation. Thus, to show the client useful values you must thoroughly calculate them. Rushing through the process will lead to useless numbers, so be patient, collect enough data and look at it from all angles. Therefore, do not treat lightly a question like “How much time will it take to build the user interface for my mobile application?”. Simple as this might seem, you must clarify all the requirements and ponder over them carefully before answering.
Split the Software Development Project Into Chunks of Manageable Sizes
When estimating a software development project, break down the work into small chunks. Thus, you will get a good understanding of the requirements. The smaller the workpiece, the easier it is to figure out what info you still need from the client. In addition, a manageable size helps you spot gaps in the specifications. For example, if the client asks for a one-page website, you may say this should take about 16 hours. If you break down the work, you will get more detail and increase the precision of the estimate. That page might need a sticky menu bar, a CTA, a contact form, and ten images. Each of them will take time. By breaking down the requirements into tiny pieces, you may double the time you estimated without splitting the work. You should aim at doing your estimates on five to ten-hour chunks of work.
Talk With the Client
Assuming you understand what the client wants is the worst mistake you can make when estimating a software project. To avoid this pitfall, better ask several times about each feature. You may easily interpret a requirement differently than the client, even when you go along well with them. Furthermore, you will often find many ways of solving a problem. Let us assume the client wants a modern vertical navigation bar in each blog post. You may consider this feature standard and set aside five hours for it. On the other hand, you may get deeper into the client’s mind by asking questions. For example, you can start with “Would you like the text to show all the time or only at mouse over?”. The answer can help you understand the client’s needs and make you turn the five hours into ten.
Use Any Help You May Need with the Estimate
For most software development projects, splitting the work into chunks yourself may not work. Of course, this may not be true for a small and simple application. A software application has a frontend or the presentation layer and a backend or the data access layer. Given the increasing complexity of the software products, different people handle these two sides of the application in most cases. Thus, you should involve a person from each area in the estimation. The high-level components to consider in the analysis include page flows, error pages, print and mobile versions, and the database. As for the main components of the software, do not forget the user interface, database architecture, server-side development, testing, development environment, deployment, and hosting. Each of these foundational tasks includes sub-tasks that you must assess. In short, the more specialists you can involve in the estimation, the better the results.
A Software Development Project is Far More than Writing Code
Software development means plenty of research, analysis, planning, and testing. Thus, code-writing takes less than half of the total project time. Therefore, do not omit from the estimation non-coding components of the software project like planning and communication with the client. There is a lot beyond coding that you must account for. Thus, meetings, the initial setup, revisions, bug-fixing, and deployment are pretty time-consuming and present in all software development projects. In short, each stage of the project includes a lot of thinking. Whether for architecture and design or planning, thinking will take time. Given the few tangible deliverables of thinking, you may tend to overlook this part. To produce a correct estimate, resist the urge to do that. Furthermore, if the project includes elements of novelty, factor in the time it takes the project team to acquire the missing know-how.
Be Realistic About Your Experience with Similar Software Development Projects
A frequent cause of inaccurate estimates is the unjustified high opinion of the person doing the estimate about their experience with similar software. Therefore, when asked to do an estimate, answer the following questions honestly.
- How many similar projects have I worked on?
- Do I have all the information I need?
- Have I made several other estimates for similar software development projects?
- How familiar am I with the technology stack?
Let us assume the client wants its users to log in to their application with their Facebook account. You might consider the feature easy to implement since it is the same as the LinkedIn login you did just last week. Given your fresh experience, you may want to estimate only 8 hours. Doing this is risky. The wise approach would be to say you have not worked with a Facebook API and go for 16 hours.
Consider Reusability and Predefined Modules to Save Time and Money
Use a Sequence in Agile Software Development Projects
The software teams estimate in a time format for projects based on traditional approaches. In Agile development, the preferred unit of estimation is the story point. Attlasian defines Story Points as “units of measure for expressing an estimate of the overall effort required to implement a product backlog item fully.”
Use Story Points to estimate issues quickly and include uncertainties. For example, one Story Point could take 4 to 12 hours, two Story Points 12–24 hours, and so on. What matters in an Agile development project is to get an idea of the time a product backlog item will take. Teams use the Fibonacci sequence or similar numbers to capture uncertainties in their estimates. Teams estimating in a time format can also apply such a sequence. Thus, they will never use 6 hours as an estimate but jump from 5 to 8.
Conclusions
This article is a guideline for the clients requesting estimates and the engineers preparing them. A key feature of the estimation process is its complexity, which results from the high frequency of incomplete specifications and scope creep, among other reasons. Thus, it is no surprise that roughly 30% of the software projects estimated upfront and built using the waterfall methodology were successful globally every year between 2000 and 2015.
With the increased popularity of agile development, respondents lately reported more successful projects and fewer failures. To minimize estimation errors, account for challenges in communication, missing information, delays from the client, building the know-how, and scope creep. As all these aspects bring risks, add at least 15-20% to your forecast. Furthermore, provide an optimistic and a pessimistic forecast, with a difference of no more than 20% between them. When using Agile methodologies, make sure you estimate each sprint.