how to effectively estimate software projects. In
practical terms, the ability to estimate software
projects well depends on how much knowledge or
uncertainty exists about the project being estimated
(Laird, 2006). Estimation should focus first on
deriving size estimates and then utilize these size
estimates to compute effort and cost estimates
(Galorath, 2006); (Laird, 2006).
Software estimation has different stages and they
can be aligned with the development lifecycle
stages. The initial estimation occurs at early stages
of the lifecycle and this is a stage where uncertainty
is still quite high. Planning estimation occurs when
the product is better defined and more detailed
requirements are known, but there is still a high
degree of uncertainty (Minkiewicz, 2009). During
the development lifecycle stage, a lot of the
uncertainty has been removed and the preliminary
commitment estimates can be made. This paper
focuses on helping a project manager to develop
estimates at the planning stage of the development.
Estimates are a communication vehicle that
allows the whole organization to have a meaningful
dialogue about the project and its significance to the
organization (Muir, 2009). The process of approving
an estimate involves two very distinct sides in the
organization, the business side and the technical
side. The goal is to balance both the business and
technical perspectives. A friction point arises over
the gap between the business’ target for the project
and the technical staff’s estimate of project
completion. The gap between the two views
represents the organizational risk. Frequently, the
organization resolves the organizational risk by
adopting the target as the plan. For many
organizations, the debate over the gap between the
target and the estimate can degenerate into strife, or
a “negotiation”, instead of an open discussion. This
can “poison” the project and make the organization
lose sight of the “estimation process” and focus only
on the end result of the estimation process. This
means that the organization focuses on the certainty
of the estimation outcome, downplaying and de-
emphasizing the risks and uncertainty that could
prevent success. This situation short-changes the
organization by taking away the opportunity to
develop an in-depth understanding of the project in
terms of the risks, rewards, and benefits.
As seen above, conflict arises because of the
difference between the “target” and the “estimate”.
This situation pits the project planning team against
the business management team. Frequently, Senior
Management seeks to resolve the situation by
imposing the target on the project planners.
A “savvy” Project Manager knows how to utilize
the estimate to promote a business discussion
focused on the gap between the estimate and the
organization’s target. At the end, this discussion will
serve to make the organization aware of the level of
risk in the project and to frame a discussion around
how to creatively mitigate the project risk and thus,
the gap between the target and the estimate.
A good presentation of an estimate includes the
description of the estimate’s scope, the estimation
methods utilized, the accuracy, and the inherent
uncertainty of the estimate. Planning estimation is
most successful when multiple methods and
different people are employed to develop the
estimate. Convergence in the estimation is an
indication of the accuracy of the estimate and it also
provides higher level of confidence in the estimate.
A fundamental concept in software estimation is
the Cone of Uncertainty (McConnell, 2006). The
Cone of Uncertainty represents the uncertainty
intrinsic to any project and shows how estimation
should become more accurate as the development of
a product moves from early development lifecycle
stages towards later stages as shown in Figure 1. The
“Y” axis in Figure 1 shows the degree of error in the
estimate and it is closely correlated with the
uncertainty that exists in every project. Estimates
created early in the development lifecycle have a
higher degree of uncertainty and estimates improve
rapidly after the first third of the project. It is
important to notice that the most important business
decisions related to the software project are made at
the time when there is minimum knowledge about
the project and hence maximum uncertainty
(McConnell, 2006). The Cone of Uncertainty
represents the best-case accuracy that is possible to
have in software estimates at different points in a
project. The Cone represents the error in estimates
created by skilled estimators. If the project is not
well controlled or the estimators are not very skilled,
estimates can fail to improve and the uncertainty
instead of being a well defined Cone, is a Cloud that
persists until the end of the project as shown in
Figure 1. Hence, the Cone of Uncertainty is
narrowed by making decisions that remove
uncertainty from the project. Studies show that
estimators who start their estimates with single point
estimates often do not adjust their minimum and
maximum values sufficiently to account for the
uncertainty (McConnell, 2006).
The Cone of Uncertainty should be used to
derive estimates taking into consideration the
software development lifecycle stage. A way in
which the Cone of Uncertainty can be utilized is to
ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies
404