An Accurate and
Believable Estimate
When generating a level-of-effort estimate for a software product, there are two outcomes that everyone wants
to achieve: They want the estimate to be accurate and they want it to be believable. Interestingly enough, most
everyone recognizes that any estimate, no matter how well it was developed, is not likely to have pin-point
accuracy. In fact, it is commonly accepted that most estimates are a best guess and that somewhere down the
lifecycle line, a new estimate will need to be developed.
Conceding the fact that there is agreement about the issue of accuracy, is there at least an opportunity to strive
for an estimate that is believable? The difference between being accurate and being believable is perhaps
nuanced, but if the customer (whomever requested the estimate) believes in the current estimate (that it is as
close to accurate as possible, based on current information), understanding that it may change, aren’t we in a
better position to manage the project than if they had simply dismissed the estimate outright?
Creating a Believable Estimate
The question then becomes how best to produce a believable estimate. The proven approach is to create an
estimate whereby both the developers and the customer provide input and are involved in the process. The
result is that all parties are confident that the basis for the estimate is reasonable, logical and well thought out.
The first step in this process is for the developer to demonstrate to the customer that they fully understand their
requirements. And furthermore, the developers have to make it clear that they have taken all of the customer’s
requirements into consideration when generating the estimate. The goal is to avoid the customer questioning
the resulting estimate because they believe that the developers “didn’t understand what was requested.”
To demonstrate knowledge and understanding of the customer’s requirements, and at the same time provide
the estimator with a valuable piece of input to their estimating model, the next step is to perform a functional
analysis and sizing of the customer’s requirements. The industry best practice for this process is a technique
called Function Point Analysis.
Function Point Analysis
Function Point Analysis is an ISO-accepted software sizing practice based on the features and functions that
make up the customer’s requirements. The resulting function point size can be shared with the customer in
terms that they understand and that is in their own language. How does this technique lead to a more
believable estimate? It demonstrates an understanding of what the customer wants, using that information as
the basis of the estimate. So, it stands to reason that the customer is going to be more comfortable in
accepting the estimate.
The Function Point Analysis methodology identifies the key functional elements of a customer’s requirements.
Those key elements include transaction-based functions (defined as inputs, outputs and inquiries) and data
functions (defined as logical groups of maintained data and all interfaces). That’s it – well, almost. Following
well-defined guidelines, the Function Point Analyst will seek to identify all unique occurrences of these five key
elements. Each one of these elements is identified as a unit of functionality that relates specifically to a stated
requirement and is readily understood by the customer.
Once identified, the Function Point Analyst then assesses the complexity of each unique element based on a
set of standards and guidelines. For example, not all inputs are treated equally, and so each unique input is
evaluated for its level of complexity and assigned a function point value based on that. After assigning function
point values to each unique element, a total sizing is computed. This size represents the functional value
(function points) for the software as stated by the customer in the requirements document.
The House Analogy
Sizing software using function points is often described as being analogous to using a square-foot measure to
communicate the size of a house being built. When developing a cost estimate for building a new house, the
builder takes onto consideration the number of square feet. However, there are many other factors that are
also considered when building a new house. For example, the condition of the land that the house is being built
on, the number of rooms and windows the homeowner wants, the type of materials being used, etc. The same
is true of developing software; knowing the size of the software is important, but there are other variables and
risks to be considered.
To be a realistic and believable estimate, we certainly want to demonstrate the fact that we understand the
features and functions (size) of the deliverable, but we also want to indicate that we have considered all the
known variables and risks that can potentially impact the delivery and the cost of the software. Those variables
can be many, and often include technical considerations, environmental impacts and issues related to
available resources. Having the ability to identify and assess these variables helps to make a more believable
estimate.
Going back to the house analogy, a builder considers many of the risks that may be encountered while building
a home to the proposed specifications. When developing a projected cost for the new homeowner, the builder
identifies all of the risks that are known at that time that would impact the cost and the completion date. These
risks are communicated to the new homeowner and serve to foster a greater understanding of the believability
of the estimate and the chance of alternative outcomes.
So too with developing software; there are always a number of unknowns. Historically, estimators have quietly
“padded” their estimates, knowing that they are likely to encounter some problems and delays along the way.
The hope is that they have overstated the estimate enough and can end up coming in under budget and
deliver sooner than planned. However, it seldom works out that way, and instead, cost overruns and delays are
incurred, much to the chagrin of the customer (and in turn, the developer).
Alternatively, it makes more sense to avoid these guesstimates and be transparent with the customer,
indicating that there are known risks and that those risks have been taken into account as much as possible in
the current estimate. By making the customer aware of potential pitfalls, it not only informs them of what may
occur, but it also serves to set expectations as to what may happen if all does not go as planned.
There are some excellent, commercially available estimating tools that provide a selection of risk indicators
and predictors for a given software project. These tools allow the estimator to generate different what-if
scenarios depending on the impact of the various risks that have been identified. This creates a mindset with
the customer that helps them to understand that risks are a fact of life, but that they can be managed and
accounted for.
The key to generating manageable estimates is to make them believable. Demonstrating a knowledge of
functional requirements and sizing those requirements is an industry best practice. Identifying the risks and
their impact on the project and then communicating that information to the customer makes for a believable
estimate.
www.softwarevalue.com
| +1.610.644.2856 | [email protected]
Measure. Optimize. Deliver.