Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
By Sergey Smetyukh and Artyom Vorobyov
In the previous article, we discussed how you can get down to estimating software projects and nail it down from the very start. The key points are to involve the right number of people, assign the task to teammates who will later take care of this project, and to manage the client’s requirements from the initial stages. Following the topic, let’s try to find out how to assess assumptions and keep them in check, and how to reach optimal estimation accuracy within reasonable amount of efforts.
1. Remember: Any Uncertainties or Risks Are Extra Time and Resources in Your Final Estimation
Understanding the nature of risks—their origins and reasons why they arise—is the key to effective risk management. The need to involve extra resources may occur at the final stages/iterations of a project, result from interdependent tasks, or may be included into iterations intended for solving unexpected project issues, and so forth.
How We Deal with This:
First off, we have done our best to clarify the nature of risks for all team estimators. Before we introduced our workshops, many people on the team had only a vague understanding of the essence of risks.
On the majority of our projects, we make use either of PERT (Program Evaluation and Review Technique), also known as the three-point estimation technique, or plan an estimation buffer to allow for later adjustments connected with risks. These techniques represent different approaches to communicating risks to a client.
When you use the PERT technique, risks are included into each task. The final estimation is calculated as:
Final estimation = (optimistic estimate + 4* most likely estimate + pessimistic estimate)/6
In the latter case, when you have a budget buffer to allow for possible risks, all project tasks in an actual estimate are calculated without any risks.
The choice of a technique depends on a client’s preferences and their expectations. Regardless of which risk communication technique we choose, our risk budget for a project remains unchanged.
Empirically, our team has worked out a regularity that a one-figure risk estimation is likely to be the most optimal. However, there are various factors to be taken into account to choose a technique that works in a particular situation.
2. Try Different Approaches to Wind up with the Most Accurate Estimation
Every approach has its pros and cons. By combining several of them and chipping in on the pros of each, you reduce the risk of making a mistake in your estimation.
How We Deal with This:
Our team mainly relies on these two combinations:
- Analogy-based formal estimation model combined with a WBS-based (bottom-up) expert estimation;
- Parametric formal estimation model combined with a group expert estimation.
One of our successful cases employs the second combination. We received a request from a company tapping the rapidly developing drone-based industrial automation market. By that time, we had already accumulated hands-on knowledge in the area. We had experience in creating drone stabilization systems based on the previously created helicopter horizontal stabilizer solution. Our team could also draw on our expertise in developing comprehensive drone-based systems for similar use cases in business automation areas. However, the client explicitly let us know that an analogy-based estimation wouldn’t do in that situation. Instead of just comparing the complexity of projects, the company wanted us to put quite a lot of efforts into R&D and analysis activities to get as accurate an estimation as possible.
First off, relying on our previous experience, the team had to find out how well we could meet the client’s time and budget expectations—and everything with minimum efforts on our side. That is where the analogy-based approach came in handy. We started with our usual practice of asking specifying questions. After getting a clear vision of what we would have to estimate, we identified which part of the project correlated with our previous experience. Then, we assessed all the uncertainties that we would have to clarify during the consequent estimation stages. Only after that, we provided the client with a budget range, justifying the chances of reaching both the highest and the lowest figures in the range. After getting their feedback on our proposal, we were on the same page regarding the scope of work and could carry it over to the budget range, timeframe, and expectations. But the most exciting part was yet ahead—we had to get down to a detailed estimation.
The main idea here was that our detailed bottom-up estimation should specify the rough analogy-based one. In this case, the initial analogy-based estimation part served as a benchmark to check our WBS estimation outputs against. To assess a work scope using the bottom-up model you have to break down the entire scope into single tasks. By doing this, you will make sure that no important details are overlooked by the estimation participants. The next step is to take into account general assumptions that make an intrinsic part of the estimation. The detailed final estimation should complement the initial analogy-based estimation and by no means should be in conflict with it.
3. Give a Price Range, Reasoning Both its Cap and Bottom Figures
Know how to manage clients’ expectations and communicate with them in terms of budget ranges at the initial stages of an RFX process. One thing you have to remember at this point is to screen a client for financial resources they have for the project and make sure that the range you are offering is in line with their expectations. When you speak in terms of budget ranges, you give estimation ranges and not mere predictions, which means that you have a good understanding of uncertainty limits.
How We Deal with This:
An estimation based on budget ranges can be provided for a client within a rather short timeframe and with minimal team efforts involved. A common solution for us is to make use of any formal estimation model for this purpose—be it an analogy-based or a parametric approach.
4. Calibrate Your Estimations with Each Iteration if You Stick to Agile
Initial estimations are based on the experience of a company/team and the vision of a planned scope of work, which hasn’t been confirmed yet. At the same time, at the outset a budget and a timeframe of a project depend on an initial estimation. With a constantly growing level of detail of the project domain and a team performance tracking routine in place, you gradually improve the accuracy of project estimations as you progress from sprint to sprint.
Figure 1: Influence on Estimation Accuracy
How We Deal with This:
As our team gets more input about project details and its specifics, we tune effort estimations and project release dates based on this information and updated team performance data. In this case, the main focus is on incoming data used to specify each consequent estimation rather than on the initial estimation.
5. Don’t Store Your Estimations Locally. Solve the Problem with Versioning
Local copies of your documents is not just a problem, it’s the source of all evil on a project. Here is why:
- If each estimation participant gives their estimation in a separate file, a person responsible for RFX process coordination unreasonably will spend a lot of time to make sense of single estimations provided by each estimator. Moreover, this approach is error-prone;
- If documents, their versions, and their copies are spawned, notes like “final version” in the file name won’t guarantee that you are working on the latest document version;
- People can take sick leaves, go on holidays, or simply forget project details with time. Equipment can get out of order. Documents stored online will help you solve both of these problems, which is already a big deal.
How We Deal with This:
Our solution is simple—we use online documents.
- Each project phase estimation is provided on a separate tab in a document; for example, in Google Spreadsheets;
- All tasks are categorized into groups called features to facilitate later changes to a document. Sometimes, several task nesting levels are required (we usually have up to four: Programming -> UI -> Screens -> Settings Screen);
- Applying formulas to calculate time required for certain tasks can be more convenient. For instance, time for game content creation tasks such as character art and programming depends on the number of characters. For such game-related tasks we use this formula:
Characters modelling = Number of Characters * Time per Character Model
Characters programming = Number of Characters * Time per Character Mechanics
These tasks should include a common value used for same-type content elements (in this case, characters). Then, any changes to both this value and to the number of characters will automatically update estimations.
6. Don’t Go Past the Finish Line
Don’t get too overwhelmed and don’t go too far with your estimations. Keep a check on an estimation progress to make sure that you stop when you achieve a level of detail sufficient for giving the most accurate estimation with a reasonable amount of effort. After all, when it comes to estimation outputs, we deal with approximations and predictions of a planned work scope. At some moment in time, you reach the point when the best approximation output you can get equals to 1-10% of a possible final estimation figure. But, to reach such level of detail, you will use from twofold to fourfold of the time you had spent to come up with a 90-99% approximation.
Figure 2: Diminishing returns
How We Deal with This:
Usually, it doesn’t take us more than two iterations to process RFQs that come in. We often manage to give the final estimation from the first attempt. To succeed in doing this, you need to get estimations from all participants with a variation of up to 20%. If the variation exceeds 20%, you need to discuss with estimators the reasons for such deviations. After the discussion, all participants reiterate the estimation process (update the latest estimation version). Normally, two iterations are enough to get an estimation with a budget range of south of 20%. Eventually, we take the average value and present it to a client.
Estimating a software project may look like a completely unruly endeavor and a patchwork of guesses at the very beginning. But, in fact, it is not! Once you know the nitty-gritty of the process, it becomes a well-structured routine rather than shots in the dark. The hands-on tips shared in this article will help you master the art of project estimations and will drive your team to “on time, on budget” project delivery paradigm.
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, and 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 helping other game studios and publishers extend their portfolios. Artyom is a key person on the game development team responsible for successful and accurate estimations delivery. |
