There has been extensive research and development in estimation techniques for software development projects, resulting in a number of formal methods and toolsets. These models suffer from a variety of weaknesses:
- The most objective methods, such as Lines of Code, Function Points and Feature Points have the inherent disadvantage that a great deal of design effort is required to get to a point where the estimate can be made, raising the question of “How much is it going to cost to give me an estimate of how much it is going to cost?”
- In trying to solve this problem by moving the estimate earlier in the project life-cycle, the solution becomes “less known”, and therefore the estimation error rises. However, the better the estimators understand the business domain, the more reliable the estimate. If the estimators don’t have a good understanding, the risk is sometimes not in the breadth of the scope, but in the intractability of one or two component – “Nobody told me that this project required curing world hunger!”
- Team productivity can be highly variable. If the estimators know who will do the work, they can produce better estimates. But often the estimators have been given that job because they are very good developers, and they then estimate how long it would take them to do it, and not the mere mortals who will be actually be assigned to the project.
- Simple estimator bias: optimistic estimators vs. pessimistic estimators.
- Unstated assumptions, misunderstanding etc.
For the SMB, the relative cost of an IT project can be very significant, and so the necessity to get a good estimate as early as possible is essential, as is the need for a reliable estimate. There are several things that can be done to achieve both of these, using a set of formal techniques, and taking advantage of the typical limited complexity of SMB projects.
The estimation activity is split into three distinct phases. These phases should be ideally kept sequential, though some backtracking frequently occurs. The phases are:
- Assessment: understanding and sizing.
- Estimation: turning the size into an estimate of effort
- Adjustment: reviewing and adjusting the estimate and the risks
In the Assessment Phase estimators analyze the software solution to be estimated. Time pressure typically constrains the estimators’ ability to understand the scope of the task, so a focus on ramping up the estimators’ knowledge of the business problem is essential. The general approach is to model the solution, to identify the components, and then estimate their size and complexity. Finally, tasks that are not strictly mapped to components are added. The essential point is that effort is not estimated at this point – just size and complexity. Here we introduce the first bias reduction mechanism: the “sizing” should be performed independently by more than one person. If the SMB has never developed a system like this before, analogical estimation will be a problem. Looking at similar implemented solutions implemented by competitors can help with understanding the complexity (for example, there are many details in the shopping cart checkout process: change quantities, cancel item, shipping options, calculating shipping costs etc. etc.)
The Estimation Phase consists of turning the output from the assessment phase into effort. Doing so requires analogical estimation. For example, “How much time will it take to develop the detailed requirements for, and to design, construct and unit test this shopping checkout module?” This is both a function of the size and complexity of each task, but also of the developers’ knowledge and experience. For example, if it developed in house, the in-house team may have a better understanding of the business, but less experience of the technology.
The Adjustment Phase focuses on two aspects of the estimate. First is the difference between the estimates of individual estimators; second is assessment of risks. In comparing the estimates of individual estimators it is frequently found that estimates of experienced estimators for the same task can vary widely for any number of reasons, but chief among them are general optimistic/pessimistic bias, and differing assumptions. So this part of the adjustment activity is a dialog, which is better if mediated by an independent third party to reduce the risk of one estimator dominating the result. Finally, the “riskiest” activities should be identified, and potentially adjustments made to the estimates. You can think about this as identifying the unknowns. For example, does the solution require the purchase and integration of a software component that we have no experience of? This activity can often uncover risks that need to be mitigated as early as possible in the project, and perhaps before the project is committed. This could be done earlier in the estimation process, but these risks frequently only get uncovered when estimation differences are discussed and an unstated assumption is unearthed.
Pricing and laying out a timeline are typically the final activities. At this stage, staffing options sometimes have to be evaluated. For example, can this project be outsourced, and if it is, what are the assumed offshore rates and the additional project management oversight required.