Introduction
If you’re a leader in a growing business, you have probably considered commissioning custom software for your organization. You’ve thought through what purpose it would serve and who your target audience would to be. You may have even considered your marketing rollout strategy. You are already envisioning happy clients clicking away, making purchases or carrying out other actions on your new platform—and, of course, recommending this awesome app to their friends. Or maybe you’re imagining a brand new internal system that streamlines operations, making employees more productive and engaged while minimizing unnecessary expenses. Whatever your vision, you can’t wait to bring it to life.
The first step, of course, is to approach a software development company and request a cost estimate. Before you do, let us familiarize you with what this estimation process will entail, and why it may not be as simple as you think.
Estimating the cost of a new product might sound easy. After all, if your app is similar to an existing app that already has a lot of users and followers, how hard would it be to estimate? As a matter of fact, the process can be time-consuming, and it will require significant efforts on the part of a team of qualified professionals.
Even if the app you’ve envisioned is based on an existing solution, the team will need to thoroughly research and document that solution to understand what’s “under the hood,” so to speak. And despite any similarities, the reality is that every custom software project is unique, and simply “copy-pasting” one into another won’t get you the results you’re looking for. The team of specialists who will need to consider your unique solution carefully in order to provide an estimate might include project manager, business analyst, front-end developer, back-end developer, software architect, DevOps, quality assurance engineers, and others.
The Foundation of the Estimate: In-Depth Documentation
Let’s take a look at some of the documents a software development team might be basing their estimate on.
Vision & Scope
This document outlines the business requirements for the new product. Typically, this information would come from the client’s team, as it needs to describe how they conceived of the product and why they set out on this journey to create it in the first place. Sources of information for this document could include the organization’s top management, the concept or product owner, an industry field expert, and/or the company’s marketing team.
Software Requirements Specification
This document is a complete description of the expected behavior of the product, and it contains specific product requirements including the following information: overall description of the product, user roles, assumptions and dependencies, functional requirements, non-functional requirements, and interface requirements. This document is instrumental for the development team, as it is a great source of information about what is expected from them. Project milestones, as well as individual tasks, are based on this document.
Prototypes & Designs
Prototypes are visual models of the product. They are often clickable, giving the viewer an excellent idea of the look, feel, and user experience of the product. Prototypes provide information on what elements are located where on each screen, exactly what the product design will look like, and how different elements interact. The user could complete a whole mock flow using a clickable prototype in order to fully understand how the product will work. These prototypes also provide a lot of valuable information to the development team in terms of what they need to accomplish.
Though exact documentation needs may vary depending on the circumstances of a specific project, these are usually the foundation of a strong estimate—and the development that follows. If you don’t already have these documents prepared, not to worry. A professional software development team can help you pull all this together in what’s known as a discovery phase. This phase is a smaller, standalone commitment that enables the developer to elaborate on the idea of the project alongside the client in order to document features, dependencies, user roles, etc.
What Will Your Software Development Estimate Look Like?
Now that we have discussed the input documents software development teams might use to analyze and estimate a project, let’s take a look at the output—besides the estimated cost—you may expect as a result of this estimation process.
WBS (Work Breakdown Structure)
This document includes a detailed list of features to be included in your app, including everything from the big picture down to the smallest features, like user registration, login, and password creation procedures. This breakdown also typically includes an indication of the effort—expressed in human work hours— required to complete each feature.
Assumptions
This part of estimation includes any suppositions the team has made in the absence of more concrete data. These could include, for example, planned load, acceptable down time, assumed number of simultaneous users, screen resolutions and operating systems most likely to be popular among target audience, development team working hours, acceptance criteria of a ready version of the product, target response time by the development team, and target response time by the ordering client for questions and clarifications. Assumptions are an integral part of any estimation, as they set the “background” that the whole project is to be based on. Any change in assumptions might lead to a change in the estimate itself.
Timeline
As the name suggests, the timeline describes the timing of the project. This might include development milestones as well as timing and correlation of several versions of the product, with different parts of the development team working in parallel. The specifics of the timeline are to be determined based on the needs of each project.
Risks
A strong, professional estimate will include an overview of risks to the project. These might originate from involving third-party integrations and services, which are out of the control of both the development team and the ordering client. For example, should a third-party service change something that would affect successful integration just as the project is almost complete, the team would need to adjust on the go, and this might alter the deadlines and/or the budget. Risks might also originate from incomplete or unclear requirements, or from requirements that change when development is already underway. In any case, a professional vendor will walk you through risks and consult with you on the best possible approaches to mitigating those risks.
As we see from the description above, estimating a software development project is a complex procedure. It is far more complex than estimating something like shipping a box of oranges from a farm to a supermarket. In such an example, where shipment and delivery are standard procedures, all risks are known and can be included in the price with a high degree of certainty. With software development, the process is much more complex. The subject matter of a custom software development system is a combination of factors, both known and unknown. The estimation process includes first elaborating on all such factors and then analyzing them in order to produce a number that factors in every moving part.
