Estimation Uncertainty:
Software development consists of making literally thousands of decisions about how
the software will function. Uncertainty in a software estimate results from uncertainty
in how the decisions will be resolved. As you make a greater percentage of those
decisions, you reduce the estimation uncertainty.
The Cone of Uncertainty (below) shows how estimates become more accurate as a project
progresses. The horizontal axis contains common project milestones and the vertical
axis contains the degree of error that has been found in estimates created by skilled
estimators at various points in the project.
As you can see from the graph, estimates created very early in the project are subject
to a high degree of error. Estimates created at Initial Concept have a total range
from high estimate to low estimate of 4x divided by 0.25x, or 16x. As you can see
from the picture above, estimation accuracy improves rapidly for the first 30% of
the project improving from ±4x to ±1.25x. This is because the milestones shown tend
to be front-loaded into the project’s schedule.
Reducing Uncertainty:
The more refined the project definition, the more accurate the estimate. The reason
the estimate contains variability is that the software project itself contains variability.
The only way to reduce variability in the estimate is to reduce the variability
in the project. The picture below shows what happens when the project does not focus
on reducing variability – the uncertainty is not a Cone but rather a Cloud that
persists to the end of the project. The issue is not really that the estimates do
not converge, the issues is that the project itself does not converge – that is,
it does not drive out enough variability to support more accurate estimates.
The Cone narrows only as you make decisions that eliminate variability. If a project
is not well controlled or well estimated, you can end up with a Could of Uncertainty
(above) that contains even more estimation error than that represented by the cone.
When Is An Accurate Estimate Possible?
Meaningful estimates are not possible in the early, wide part of the cone. Effective
organizations delay their commitments until they have done the work to force the
Cone to narrow. Meaningful commitments in the early-middle part of the project (about
30% of the way in) are possible and appropriate.
Our Project Design and Estimation Process:
Our project design and estimate process consists of the following steps:
- Initial Concept Discussions with Client
- Vision and Scope Documentation
- Software Requirements Documentation
- Use Cases Documentation
- User Interface Design Documentation
- Project Construction (Code written here)
By using this iterative project design and estimation approach we are able to work
closely with the client to clearly define their project before any code is written
(Project Construction phase). Spending the upfront time necessary in planning will
go a long way to speed up the development timeline and reduce development costs
by minimizing the need for rework. This does not mean that the requirements are
“set in stone” just that proper forethought has been invested into the project to
make it a success. If the requirements change, then we can be flexible and adapt
to the changing needs of our client’s organization and revise our estimates accordingly.
The following is a breakdown of the steps involved and the costs associated with
each:
- Initial Concept Discussions with Client: In every case our process begins
with the client approaching us with a project for which they need help. Our response
is to work with the client and spend the time necessary to understand the major
components that make up the project. These are “high-level” discussions about the
purpose of the project and often take place via the phone and email. This is a free
service we provide to make sure we understand our client’s needs before moving forward
with the project. After the Initial Concept has been defined we are able to produce
an estimate for the Vision and Scope Documentation. If the client decides to move
forward with the project then we require they sign our software consulting agreement
and all future time spent on the project is billable.
- Vision and Scope Documentation: In this phase we help the client define their
business requirements that represent the high-level objectives of the organization
as they related to this project. Business requirements typically come from the funding
sponsor for a project, the marketing department, or a product visionary. Business
requirements describe why the organization is implementing the system – the objectives
the organization hopes to achieve. Defining the scope and limitations of the initial
and subsequent releases is also part of this step. After the Vision and Scope Documentation
are approved by the client we are able to produce an estimate for the Software Requirements
Documentation.
- Software Requirements Documentation: This is the most involved phase of project
planning where we delve into the specifics of each feature. We also define the different
classes of users that will be using the application and their relationships to one
another. After the Software Requirements Documentation is approved by the client
we are able to produce an estimate for the Use Cases Documentation.
- Use Cases Documentation: Use Cases refer to a description of the applications
behavior as it responds to a request that originates from outside the system (i.e.
user input). So for example, a use case may be a customer making a purchase or a
store manager refunding an order. In this phase we will document the different common
use cases that will arise under normal operation and how the application will respond
to each request. After the Use Cases Documentation is approved by the client we
are able to produce an estimate for the User Interface Design Documentation.
- User Interface Design Documentation: In this phase we will create “wire frame”
mockups of each screen in the application. This will allow the client to visualize
how each screen will look and behave and modify them as necessary. Modifying a screen
mockup is much quicker and less expensive then modifying code and allows our developers
to know exactly how the client would like each screen to look and behave before
they begin coding. After the User Interface Design Documentation is approved by
the client we are able to produce an estimate for the Project Construction (the
remainder of the project).
- Project Construction: This is the final phase where our developers actually
write the code necessary to make the project a reality. Typically this phase makes
up about 70% of the entire project. By the time we get to this phase we should be
able to produce an estimate for the remainder of the project. If requirements changes
during this phase we will revise our estimates accordingly.
The bottom line regarding the estimate is that we typically have to get about 30%
of the way into the project in order to remove enough variability to create an accurate
estimate for the entire project. While everyone would like to get an accurate estimate
early in the project this simply is not possible. After each planning phase we will
produce a documentation deliverable that clearly outlines the plans we have completed,
with the help of the client, in that phase. The client will need to sign off on
the documentation before we begin estimating the next phase. We can provide examples
of the sort of documentation we will produce in each phase upon request. Below is
a flowchart that further illustrates this process. Please do not hesitate to contact
us with any questions.
References:
McConnell, Steve. "Chapter 4 - Where Does Estimation Error Come From?" Software
Estimation: Demystifying the Black Art. Redmond, WA: Microsoft, 2006. Print.
Wiegers,Karl Eugene. "Chapter 1 - The Essential Software Requirement." Software
Requirements. Redmond, WA: Microsoft, 2003. Print.