By Sergey Smetyukh and Artyom Vorobyov
One of the burning issues on the agenda for many technology project managers and pre-sales specialists is how to master the art of estimating app development projects. The key problem is how to make estimates as competitive and as accurate as possible, while involving a reasonable amount of team efforts and securing a fair chance of meeting the figures that you have come up with. An optimal estimate of development time and team efforts required to complete the project is not mere guesswork. By contrast, it’s a well-thought-out and well-grounded plan that allows for some risk assumptions.
You should avoid inflating your project estimates as well as avoid downplaying your figures at the same time. Following are a number of hands-on tips that could come in handy if you are a developer, project manager, or other professional in the software development arena.
1. Know Your Way Around: Understand What You Are to Estimate
It’s easy to estimate what you know.
It’s hard to estimate what you don’t know.
It’s very hard to estimate what you don’t know you don’t know.
Estimate accuracy hinges on the level of detail that you get from a client. The more input you get from the client, the more specific an estimate you can provide. If you have any gaps in understanding a project, don’t get down to assumptions head-on. Ask the client additional questions. Keep in mind four golden rules of a good estimation:
- A feature is taken into account only once;
- Only those features that were requested by a client are included into an estimation;
- Features that were not requested by the client are not included into the estimation;
- A feature should be estimated correctly.
These rules seem to be no-brainers, yet people who make estimates, let’s call them estimators, often focus on the last rule, while completely neglecting the previous three rules. However, failing to take into account 400 hours of back-end development is a far more serious oversight than miscalculating the development time of a user settings screen by four hours. That’s why it’s crucial for an estimator or a person assessing the final estimate to bear in mind all four of these estimation rules.
How We Deal with This:
- All questions should remain relevant to a client’s request. Each clarification may add to the estimation and therefore should remain within the boundaries of the client’s initial request;
- Each question covers only one point. Clarifying questions should be worded in a way that elicits an exhaustive answer to a particular question rather than a description of an entire system without covering anything in particular;
- We use definitions and terms that were used by the client during the initial contact.
2. The Team to Work on a Project Is the One to Estimate the Project
Ideally, the team members who will be later engaged in the project implementation should provide the estimates for it. This means that the estimation team takes responsibility for the figures in the final estimation from the moment they get down to assessing the client’s request.
Figure 1: Responsibility versus Involvement
No doubt, we don’t always follow this rule, especially at times when our pipeline is filled to capacity with clients’ requests. If one person is estimating four projects simultaneously, there is only a 25% chance that they will participate in any of these four projects. Let’s put it in a different way: 75% of these projects are developed based on other people’s estimations. That is the key stumbling block because people are prone to subjectivity and tend to make conclusions from their own experience. What a senior developer with in-depth domain knowledge is able to do in 100 hours will require 30% more time from a mid-level specialist. If you carry this example over to the final estimation figures, the problem may take menacing proportions and turn into a sword of Damocles hanging over you.
How We Deal with This:
In the majority of cases, we assign idle resources (the so-called “bench”) to estimation tasks. These are people who can set to project implementation and “sign on the dotted line” under the figures they provide. However, in many cases there are exceptions:
- Projects that require specific skills and knowledge. In this situation, we are forced to turn to unique holders of expertise necessary for a particular project even if these people are already engaged in other projects;
- Innovative projects, uncharted waters for all team members. Such requests are assigned to tech experts for an estimation.
In any case, the key to success is reasonable resource planning and management.
3. Don’t Go for It Single-handedly
Do invite more than one team member to give an estimation to a client. It’s crucial that each type of task is assessed by a competent person. Development is in the area of competence of a developer, art creation is approached by an artist, the scope of UI work is estimated by graphic designers, evaluating the time for management activities is entrusted to project managers, and so forth.
As to a competitive approach to estimating the same scope of work, there is no shared opinion on this matter. Sometimes, you can involve several people to increase accuracy of an estimation. In this case, chances are that you unearth more hidden risks and miscalculations. In addition, the risk related to human errors and the possibility that something will go unnoticed is reduced. This happens when the final figures received from all estimators are stacked up against each other.
Keep in mind that it doesn’t make sense to add extra people to an estimation team after a certain point in time. The efficiency curve will simply go down. If the size of an estimation team exceeds 10 people, miscommunication among all estimators is almost inevitable, and eventually has a negative impact on the accuracy of the estimation.
Alternatively, an estimation is made by a single tech specialist. If this person lacks necessary experience, a supervisor is assigned to such a person to guide them through the process, oversee it, and make timely changes to the estimation.
Figure 2: Optimal Size of the Estimation Team
How We Deal with This:
We assign from four to eight specialists to make an estimation of a project. Empirically, this team size has proved to be optimal for our company. Such an approach yields us the most accurate results with minimum efforts involved.
4. Assign a Person Responsible for Estimation Delivery
This advice is particularly relevant for big projects where more than one department is involved into the estimation process and several teams look into a work scope and give their assessments. Such a situation requires well-orchestrated communication. Hence, there should be someone at the helm to make up final figures, take into account all possible risks, and present the estimation to a client. That is where a knowledge holder—a person who is in the picture of all details about the project—steps in.
How We Deal with This:
We tend to adhere to this principle because we constantly handle projects that span competencies of several departments. For instance, one of our projects is focused on the development of a wearable bracelet. The solution monitors vital signs and caters to professional sportsmen undergoing rehabilitation after injuries. The project takes in the following development areas: hardware design (pcb, casing, and its components), firmware, mobile application that captures data from devices and visualizes stats for further use, web solution that includes admin panels to manage the solution, and cloud storages to keep user stats and other data. In such situations, a person who coordinates communication among several company departments and brings together the estimation info helps to eliminate possible chaos.
Moreover, the sales cycle and RFX process may last several months on big projects. That’s why there always should be a person who will manage project knowledge and give a prompt response to the client’s questions. It may take quite some time for a client to make the final decision. They can request changes—add or remove features—a few months after they got their estimation. Alternatively, the client can ask for so many changes within a short period of time that no one apart from the person who is in the know of all project details and completely immersed into the RFX process can provide well-timed estimation updates.
Pay attention to the fact that the person responsible for estimation delivery should give clear deadlines to estimators. In our practice, this person is a sales manager or an RFX coordinator in many cases. An RFX coordinator is a person who manages incoming requests processing (Request for X, where X is information, a quote, or a proposal).
5. Coordinate Nuances with All Estimators, Understand Estimation Scope
All estimators should have a clear vision both of the key functional units and of non-functional components of the project. The main idea here is that, when everyone has brought their estimation share to the table, the team should be able to compare apples to apples.
How We Deal with This:
- Before we get down to estimating a project, we not only sync on the scope of the functional part, but we also touch upon tasks related to documentation, unit tests creation, code review and QA activities, the set-up of training seminars, if necessary, and so on;
- Each estimator uses the same assumptions as a guideline and makes an estimation presuming that the project is assigned to specialists with certain experience;
- We sync on the project understanding not only prior to the start, but also as we progress through the estimation process.
Figure 3: Team Sync during Estimation
6. Keep a List of Common Estimation Mistakes at Hand; Sync on New Mishap Cases
Such mishaps are likely to be spotted during retrospectives when the project has come to an end, everything has been calculated, and you can see oversights of the initial estimation. To help estimators with different levels of competency make reasonable estimations, you should organize seminars and trainings as well as cement some basic rules in a written form. These guidelines vary from company to company depending on many factors, including your niche specifics. However, the most common mistakes are:
- Underestimating testing and QA activities;
- Underestimating efforts required for documentation creation;
- Underestimating expenses for business trips and meetings;
- Ignoring additional requirements and changes that arise during the estimation process;
- Overestimating the possibilities of tools, languages, methodologies, and the like, which leads to a team effort’s underestimation;
- Ignoring or underestimating efforts for project management and support activities.
How We Deal with This:
After some time of real-life practice, we’ve compiled our own list of common oversights. We go over them prior to the estimation start. At the same time, to tackle the problem in a more consistent way and embrace a larger picture, to level up team knowledge on the topic and to increase the accuracy of outputs, we take these measures:
- Organize in-house estimation workshops and bootcamps;
- Assign a knowledgeable estimator to supervise less experienced developers during the estimation process;
- Have written up and put in place a set of guidelines for performing estimations;
- Have introduced estimation templates with formulas. They allow us to automate calculations of resources required to complete a certain task. Such templates are used to eliminate possibilities of human mistakes.
The bottom line here is that choosing the right team and the number of estimation participants, shaping communication wisely both with your colleagues and the client, as well as keeping the process transparent for everyone involved will help you get off to a good start. In the next article, we’ll elaborate further the topic of software project estimations, revealing the secrets of how to manage risks and uncertainties, optimize estimation accuracy, and efforts required to perform the task.
About the Authors
 |
Sergey Smetyukh is a business development manager and one of the key RFX coordinators at Softeq, a provider of custom software development services across embedded, mobile, and Web areas. Softeq’s focus is highly integrated distributed enterprise Web applications, research-intensive consumer mobile apps, firmware, and hardware design for innovative gadgets. Sergey has extensive experience in managing service delivery and coordinating a pre-sales process, including project estimation activities. |
 |
Artyom Vorobyov is a technical lead at the Softeq game department—zGames. zGames provides its assistance with development and creative game design for corporate, education, and promo game initiatives as well as helps other game studios and publishers extend their portfolio. Artyom is a key person on the game development team, responsible for successful and accurate estimations delivery. |
