Estimating Software Development Projects – Science and Art

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.

Challenges of giving estimations of the Software Development Project

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

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.

Pitfalls in Estimating the Backend

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

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.

Discuss 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.

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

When predefined components for the software you are estimating exist, do not be afraid to propose them to the client. Doing so can greatly improve your estimate and lower the total cost of the software development project. Using existing assets in the software product development process is one of the two approach you may rely on. “Such assets are products and by-products of the software development life cycle and include code, software components, test suites, designs, and documentation.”  (Source: Wikipedia ) The second approach is the use of predefined free and open-source components. Of course, the license terms for those components should not make you give the software’s source code to its end users. To screen the components, analyze their license terms thoroughly. Then, tweak the requirements if necessary, making sure the client gets all the features they want in a more effective way.

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.

Conclusion

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.