The Problem: Estimating Project Duration
by Ray Baron
A problem arises. No one knew this was going to be a problem.
The engineers and project staff said there was no way they could have foreseen this latest
problem as an issue. This will put us behind schedule, however, there is a possibility that we
could recover if there are no more surprises. That was nearly two years ago. We encountered
many more snags. The project was supposed to be completed last year. We are probably 6
months to a year from being done. We are numb to schedule issues. Credibility is at stake. If we
had been able to foresee that this project was going to drag on this long, I’m quite sure the ROI
would not have been favorable enough to get the project approved. Now there is speculation
whether the vendor can even make the machine perform as promised. There is talk that we
should quit spending money on it and abandon the project to minimize our losses. Someone
should have known that schedule risk was too high since every aspect of this project had never
been done before by any of the key players. Have you ever been involved with a project that with
every successful step there is another hurdle looming on the horizon for which no one was able to
foresee that continues to drive the project further behind schedule? These types of unforeseen
delays are commonplace in development or
unique equipment projects. The norm of unique projects is cost and schedule overruns. Has
NASA ever had a project that went according to budget and schedule? Plans for unique highly
technical projects often go awry. It should be expected. Many technical projects are a
combination of technologies that have never been put together the same way or in the same
format before. These types of projects are breaking new ground.
Project teams do their best to forecast schedule impacts based on past experience. However,
from design to implementation project teams often encounter setbacks that could not have been
easily foreseen. This paper will endeavor to look at the issues that drive project delays and how
to better quantify the propensity for delay in a given project. There are many reasons for delays
that must be discussed before looking at project complexity such as management politics, and
the degree of “breaking-new ground”
technology of a project.
Politics and Projects
Invariably, most readers of this article will say to themselves (or grunt audibly) that the writer has
no understanding of how self-serving their decision-makers are. Proper project execution is more
of an art in dancing around manager-imposed obstacles and inflated egos than the science of
implementing automation. That being said, I believe it is imperative that the individual or team
accountable to a schedule estimate has
a documented intelligent honest assessment of project duration to
completion. Project estimates are made up of the four ‘Fs’; Fact, Fiction, Fib, and Fudge.
Obviously the most accurate estimate is based on Fact. With very technical unique ‘breaking-
new-ground’ types of projects, estimates will contain some percentage of Fiction. It is unavoidable
and necessary, however, the failure of many estimates to properly reflect actual project duration
results with the final two ‘Fs’. Fibs often happen when the project owner reduces the estimate in
order for the project to qualify based on ROI rules. When questioned, this individual merely
comments that the estimate in his/her opinion was inaccurate. “After all, this is an estimate.”
Consequently, cost overruns and requests for more capital occur. Generally, Fudge is a
percentage of the total project estimate. Typically this amount is somewhere around 10% and is
often a given line entry on a capital request form. This 10% fudge is to cover unexpected ‘Acts of
God’, material delays, shipping problems, etc. Realistically, however, the real fudge is the
cushion that fattens numbers in other areas of the estimate. This is a result of
perceptions/opinions (gut feelings) by the project team that there will likely be cost/schedule
problems in other areas that are impossible to foresee at this point. The amount of hidden fudge,
or fat, in an estimate is directly proportional to the amount of Punishment meted out to those who
fail to stay within budget. Project proverb #1
Management positioning to minimize career risk is another issue to be considered, however,
about which no one seems to be accountable. So why mention it here? Because “it’s often
therapeutic to put one’s soapbox into print”. Many times a project gets a late start because the
project authorization signature journey takes longer than the project. Not because the company
mail system is slow but because signing onto a project that has
some risk requiring positioning and maneuvering to ensure that success smiles on the manager’s
door and failure points its ugly finger in other directions. If a project decision-maker cannot trust
the honesty of the estimate then the rest of this discussion on estimating project complexity will
be an exercise based on myth and distortion.
Off-the-Shelf vs. Development Projects
An Off-the-Shelf project for the sake of discussion here will be defined as a Production driven
request for automation to reduce costs based upon schedules for increased production rates.
Development projects are those unique, highly technical, R&D projects for which there is a
perceived future need for a given automation technology to be implemented sometime in the
future. Between these two definitions there exists a shadowy gray area that most projects fall into.
Often the automation project requires the modification of existing technology or equipment. The
degree of this modification is the gray shadowy area that requires a more careful approach at
estimating cost and schedule as the unknown elements can make or break a ROI decision. The
most tragic scenario is one where the selected production project, that must be introduced into
production driven by an aggressive production schedule, is based on new technology that neither
the company nor the vendor has much experience implementing. Consequently, schedule/cost
risk
is high. In order to reduce this risk the project team should try an approach that utilizes
technology that is more off-the-shelf. The determination of this risk is not always easy to assess
especially when there are multiple vendors with completely different technical automation
approaches. This assessment of schedule risk is directly proportional to the complexity issues
involved in the project. One such determinant is where the project would fall on a
continuum based on off-the-shelf to new design of the automation.
Should schedule impacts be expected? What are some ways to
minimize these schedule impacts?
Listen to your experienced people. Often they will not be able to tell you in layman’s terms
exactly what they foresee as roadblocks,
however, they have a gut feeling that the project is headed into rocky terrain. If you don’t have
people experienced in this type of project then you are highly disadvantaged to say the least.
Often internal estimators honestly believe their completion times are accurate. You may want to
consult with an outside firm that has experience in your type of project who can do a sanity check
on your expectations with regard to cost and schedule.
Be very careful in accepting the word of ambitious marketing folks
looking for work. They tend to oversimplify and be overly optimistic
with regard to project completion times in order to win your business So, how does one more
accurately forecast a high-risk schedule/cost project for time and resources? A more intelligent
guess will tell a better tale. Having faith in that estimate and being able to sell the ultimate users
of the new offing as well as the bean counters that the project will actually take twice as long as
was first thought is not an easy task. Therefore, having a model that illustrates the issues of
complexity to better define the estimate
with respect to schedule/cost impact will help establish credibility with upper management
decision-makers.
The Complexity Model
Complex projects have a budget and schedule risk that is not often
recognized until after completion or abandonment. This model attempts to better quantify
schedule times in an attempt to more intelligently assess project cost/savings estimates. More
accurate estimates lead to better opportunity cost decisions. This model is based upon some
assumptions that will require much more testing, however, using the model will lead the estimator
to consider many elements that have a great potential to drive delays and cost overruns. One
such assumption for this model is that the most complex project will take twice as long as an off-
the-shelf project. Thus, mathematically, the Complexity factor will be from 1 to 2.
The basic premise of the model is that after the estimate has been
developed, the appropriate amount of contingency cost or percentage should be variable
depending on many complex factors such as, vendor ability, newness of design or technology
etc.
The key point of success for most projects (most clearly seen in
hindsight) is the selection of the best vendor. In highly technical projects there may be a wide
variety of vendor approaches to an automation solution. In order compare approaches to
minimize risk to project success requires a detailed analysis of many factors beyond the bottom
line bid. One very important aspect of this apples-to-oranges disparity is risk associated with
project complexity. Thus, the basic purpose of this model is to create an
apples-to-apples comparison of each vendor’s abilities with regard to the technical nature of the
project. For example, the highest cost bid may involve a vendor whose approach is to install off-
the-shelf equipment with small variations while the lowest cost bidder has a reinvent-the-wheel
approach which has a higher degree of schedule impact risk. The decision may be driven by
whether cost or schedule, is the most critical element.
The Model
TTP(Total Time of the Project) = [Nominal Project Estimate]
[1+Complexity factor (Cf)]
TTP = NPE(1 + Cf)
Nominal Project Estimate = Normal Expected Time for Project
Implementation
(Specification + Bid Process + Design + Acceptance Testing + Facilities Preparation +
Installation)
Nominal Project definition (Cf = 1): A nominal project time estimate is based on
historical times from projects of similar size and scope.
There may be several estimates from different sources. The equation below is a method
for average several estimates.
*Complexity Factor (Cf ) = (w1 CDesign + w2 CVendor + w3 CIS + w4 CMfg)
____________________________________________________________________________
(w1 + w2 + w3 + w4)
*Each of the complexity factors can be weighted depending on the importance of a
particular factor Typically, the most affective determinant of schedule risk is level of
technology and uniqueness of equipment/automation design.
CDesign = w1Vendor + w2Customer
_________________________________________________________________
w1 + w2
Vendor continuum:
0 .5 1
Typical Design/Size Typical Design – New Size New Design and Size
Typical Size – New Design 6 ) ( 4 Highest Medium Lowest NPE + + =
Customer continuum:
0 .5 1
Typical Design/Size Typical Design – New Size New Design and Size
Typical Size – New Design
A critical area to understand is the Vendor Entity. To assume a
level
of performance from a particular vendor no matter how excellent its
previous track record can be disastrous. It is essential, at the very least, to
examine the contributing factors to the uniqueness of the project.
CVendor = w1 Projmgr + w2Subs + w3Intl + w4Size + w5Histperf
________
w1 + w2 + w3 + w4 + w5
Projmgr continuum:
0 .5 1
Cust/VendProjMgr NewVendor ProjMgr. NewCust/VendProjMgr workedtogetherbefore
(CustProjMgr never workedtogetherbefore worked with Vendor before)
Subs continuum:
0 .5 1
Vend/Subworkedtogether Vend/Subworked Vend/Subnever worked onthismachinebefore
togetherbefore togetherbefore
*Intl continuum:
0 .5 1
NoInternational InternationalSubcontractor Internationalprimecontractor
*It’s important to note here that different countries are known for their engineering and technology
abilities. Research into the customs of the country is an essential task before making a
determination here.
Size continuum:
0 .5 1
Typical Size/Technology Typical Size/New Technology LargestProjectSize/
New Technology
HistPerf continuum:
0 .5 1
Vendor History Positive Vendor History Average Perf VendorHistoryNegative
CIS = w1Hardware + w2OTS + w3VendSoft
_____________________________________________________________________________
___________________
w1 + w2 + w3
Hardware Continuum:
0 .5 1
No Compatibility DifferentSystems/OpSys Issues
Off-the-Shelf Continuum:
0 .5 1
All Software Off-the-Shelf All Vendor Coded
VendSoft Continuum:
0 .5 1
One Software Vendor Multiple Software Vendors
CMfg = w1MfgOps + w2MfgVar
______________________________________________________________
w1 + w2
MfgOps Continuum: Quantity and Complexity of Mfg Tasks
0 .5 1
Few Simple Operations SeveralOperationsand/or ManyComplexOperations Few Complex
Operations
MfgVar Continuum: Material and Mfg Process Variability
0 .5 1
One Material Type SeveralMaterialTypes Great Variety of Materials Standard Mfg Processes
Some Mfg Process Variation High Mfg Process Variability
There is a concept that begs to be discussed here. If in the process of determining the cost and
schedule one discovers that the adjusted time from expectations to accomplish this project is
nearly double, then the technical nature is probably best described as a new frontier. This project
must be viewed as a development project (R&D) where there exists time to work out technical
issues while developing new expertise, methods, and procedures for manufacturing rather than a
means to increase production capacity in the near term. As a rule, therefore, if production
requires new machines to increase production capacity in the near term then the selection of
machines must be closer to off-the-shelf where cost/schedule risk is less.