Estimating by Percentages

"Remember, it's Ready, Aim, Fire; any othermore time spent in the early phases for better clarity
sequence is counterproductive."of requirements definition and for producing better
- Bryce's Lawspecifications for the programmers and DBA's to
Having been involved with the systemsfollow. Under this scenario, I see as much as 60% in
methodologies field for over 30 years I have beenthe early phases involving systems analysis and
occasionally asked what percentage of time in adesign, 15% in programming, and 25% in
project should typically be devoted to a specificimplementation and review. You heard right, 15% in
phase of work, for example a Phase 1 Feasibilityprogramming. Why the disparity? Simply because
Study, Phase 2 Systems Design, etc. Basically, theprogrammers have long suffered from the lack of
reason the person wants to know this is to use it asdecent specifications and end up spinning their wheels
a means for estimating the remainder of the project.over and over again trying to deliver what is needed.
For example, if I were to say Phase 1 representsBut if you concentrate on better specifications
10% of the overall project, they would simplyupfront, the guesswork is eliminated for the
multiply the amount of time spent in Phase 1 by ten.programmer.
This is an unreliable approach for estimating which isSome people consider the upfront work to be
why I usually balk at giving out such figures.somewhat frivolous, that the "real work" is down in
Systems development projects vary in size fromprogramming. I don't know why this is, perhaps
large to small and although statistics should certainlyprogramming is more tangible since screens and
be maintained, I still consider this an erroneousreports can be visibly shown to people. But I do not
approach to estimating. Instead, I recommend basingsubscribe to this notion, and believe the vital work to
an estimate on a rough design of the product to bebe in the early phases, but then again, I am
built (the system), including all of its pieces and parts,considered a dinosaur by the "Agile" methodology
such as inputs, outputs, files, records, data elements,people. Regardless, if you have to build anything of
etc. Some of these components may be reusedsubstance, be it a bridge, a skyscraper, an
from other systems, some may require modification,automobile, or a system or a single program, you
and some may be entirely new. This is calledhave to do your homework first, otherwise you find
estimating based on the system's "Bill of Materials," ayourself constantly tearing things down and rebuilding
simple concept derived from engineering andthem over and over again. If we built bridges the
manufacturing. Even if a project only involves a singlesame way we build systems in this country, this
program (as opposed to a major system), I wouldwould be a nation run by ferryboats.
still examine the types and number of componentsOne last word on applying percentages to project
affected by the assignment.estimates, the danger here is that you might
Having said all of this, let me give you my spin on thecalculate you are 90% complete; inevitably you will
proportion of work in the typical systemsdiscover the last 10% will take forever. So, my
development project. I have seen many companiesrecommendation is to avoid the percentage trap and
skip through the early phases in order to get to theconsider the Bill of Materials you are going to work
programming phases which is considered theon instead.
important work. Under this scenario, programmingIf you would like to discuss this with me in more
represents 85% of the project. Instead I advocatedepth, please do not hesitate to send me an e-mail.