The quality of resource estimates for computer system development can be improved. The methods for improving estimates, however are not simple. There will be no magic formulas derived which will crank out accurate estimates by the mere substitution of some known quantities.

Anyone who expects a quick and simple solution to the multi-faceted problem of project resource estimating is going to be disappointed. The reason is clear: System Development is a complex process; the phases and functions which comprise the process are influenced by dozens of poorly defined variables and most of the activities within the process are still primarily human rather than mechanical.

There are examples of competent system professionals independently estimating the same job and arriving at estimates which differ by over 100%. Such outcome is disconcerting, not just because of the discrepancy, but because both people believe their estimates to be reasonably valid.

Not all estimates are bad, At one end of the spectrum are small, well defined, assembly line web site and/or programming jobs done by programmers whose capability and productivity have been demonstrated over a long period of time. A competent and experienced estimator can estimate such programming tasks with a high degree of precision. At the other end of the spectrum are the behemoths of computer program system development, those projects requiring hundreds of man-months, thousands of computer hours, and millions of dollars to implement. Resource estimates for these super-systems are characterized more by an act of faith than by any semblance of scientific prediction.

Between these extremes lies the full spectrum of computer systems: From small to large, from simple to complex. Although no poll has been taken on all these systems, it seems safe to say that there have been more bad estimates than good ones, and more low estimates than high ones. In fact, the problem of estimating is more correctly defined as the problem of underestimating. Target dates of estimated schedules are missed: Machine time is in short supply, programmers add overtime on top of overtime to counteract the manpower deficiency: the budget runs out long before project completion. These are some of the manifestations for poor initial project estimates, perhaps best characterized by "too little and too early".

The problem of resource estimating of computer program system development is that even most IT/IS management professionals either are inexperienced in the process and don't understand what has to be estimated well enough to make accurate estimates.

Estimates will improve only when the estimators achieve greater insight and understanding of the system development process, and the functions which make up the process, and the interdependencies of these functions, and the factors which influence the resource requirements of these functions.

The System Process
The implementation of a system and associated programs is a complex process requiring the smooth transition through many chronological phases, the meshing of specialized support functions, the management planning and control of diverse talents to produce an integrated, tested, quality product. An estimator must attempt to predict the activities of this process and the required resources to perform the activities. He wants to produce an estimate of manpower and machine time required to complete the system within an estimated elapsed time.

It will be impossible for him to calculate manpower requirements accurately if he fails to recognize all of the human factors that must be performed to put the system together. It will be impossible to estimate the amount of computer time (or number of development systems) required if he fails to account for all of the myriad demands placed on the system during the implementation and testing. It will be impossible to project elapsed time for development if he fails to consider the requirements of each of the phases of the process

"Bad Estimates" can almost invariable be equated to "underestimates". Estimates are wrong not so much because of what was estimated, but because of what was not estimated. A bad estimate is more an error of omission than an error of commission. An estimator might accurately predict the resources required to produce a set of programs (program specification, flow charting, coding and unit testing), but he is prone to underestimate the pre-production activities (system analysis and design, component design, etc.), the post production activities (component testing, system testing, data loading, conversion, etc.) and the support function (documentation, test specification development, plans and controls, machine operations, etc.).

The total system development process is really the sum of a great many individual, diverse, interrelated activities. These activities -- coding the program, running a test case, drawing a flowchart, writing a document -- expend manpower, machine time and elapsed time. If these activities were done in isolation from one another, their resource estimates would be a relatively simple task.

Once these tasks become an integral part of a total system effort, each task is now dependent upon, and influenced by, many other tasks.

Systems development is a highly interactive process. Not only does the system being developed have intricate interfaces at every hierarchical level, but also the system doing the developing (the project organization) has a multiplicity of interfaces between individuals, groups, etc. In such an environment, even an overly simple task can take on an unsettling degree of complexity.

It is easy to discount this added complexity of system activity by labeling it bureaucratic inefficiency or parkensonian stupidity. If a project manager were to "run a tight ship", "get rid of the deadwood", and "crack the whip", there would not be an problem of low productivity or slipped deadlines, or so the critics contend.

Such simplistic solutions are wide of the mark. When estimators and managers finally accept the fact that a system is far more than the sum of its apparent parts, then estimated resources will begin to approximate the true job to be done.

Resource Analysis
The four basic resources to be manipulated in system development are manpower, machine time, money and elapsed time. No one resource can be analyzed in isolation of the others.

Manpower can be traded for elapsed time; machine time can be traded for elapsed time. The nature and limitation of the tradeoffs deserve careful analysis, because such tradeoffs are basic to the job of resource estimating, and, in a larger sense, to the job of program project management itself.

Product Definition
The end result of any system development is to produce a product which meets certain objective and requirements. These MUST have been specified in minute detail in a properly executed Needs Analysis and subsequent Engineering/Design Study/Specification based on that analysis. An estimate of resources required for a project can ultimately only be as good as the requirements data upon which it was based.

Web sites, databases, and programs are only part of the delivered product. They must be accompanied by documentation, specifications, flowcharts, program listings and other forms of paper. The second set of data on product definition is therefore the delivered documentation describing the system, its external and internal specifications, operating characteristics, data base specifications, operations and maintenance manuals, etc.

These two entities, programs and documentation make up the basic product definition: What is being produced by the system development. These are the quantities which must be estimated, and these are the end results of the resource expenditure during the system development.

The hypothesis underlying all estimating analysis is that there is some relationship between the resource required and the product produced. Estimating analysis reveals more and more levels of difficulty with deeper investigation. The risks inherent in bad estimates, and the benefits to be gained from good estimates certainly dictate that the problem be attacked with great emphasis, however difficult it may be.

For every line of code in the delivered system, there may have been several lines written during the system development; for every page of final documentation, there may have been several pages written during development. The internal programs and documentation have sometimes been referred to as "scaffolding". When a building is constructed, it is often necessary first to build a scaffold which aids the construction. When the building is finished, the scaffold is removed, and all that is apparent to the observer is the building itself. However, the construction project -- the system development -- required resources and time to erect both the building and the scaffold. The end product is not, of itself, a complete measure of the work required to produce it.

There are many possibilities of programs produced by the system development project which are required for the development, but not part of the system itself. Test cases are an obvious example. Other examples are production support programs, simulation models, data conversion or generations programs, file conversion programs, project control report programs, etc.

Scaffolding programs must be available for the corresponding development phases and functions which they are required to support. It doesn't help the schedule to have programs ready for testing, with no test cases available. Thus the development of support programs must be estimated and planned to mesh with the system development itself.

System and component specification, program and data specification, technical and procedural standards, operating notes, addition and revisions thereto, multiple distribution thereof, etc., can turn program system development into a very active publishing business. Once again, estimates which reflect only the final product of this activity will fall short of the actual resource expenditure required.

CRASH PROJECTS
One of the objectives of a detailed analysis of programming projects is to provide some insight into a very elusive phenomenon of system development: The "Crash" project.

A crash project is one in which the allowable elapsed time is less than optimum, thus requiring excessive resources for project completion. There are probably two main ways in which a project becomes a crash project. The more obvious one is caused bo the external imposition of unrealistic commitment dates. This situation occurs when commitments are established by policy edict rather than by rational planning. The more subtle creation of crash projects occurs when "rational planning" produces a gross underestimate of the required elapsed time to do a given job. It is interesting to speculate on how often project managers have blamed "somebody else" for an unrealistic commitment, when in fact the true cause was their own bad planning.

In either case, excessive resources are poured into the project in an attempt to meet the target dates, with a corresponding decrease in individual productivity and organizational efficiency.

The crash project phenomenon has a profound impact on estimating. In our present imperfect world, the level of sophistication of estimates can best be typified by a hypothetical, but not typical statement of a project manager: "You say the project would require three people for nine weeks? All right, I will give you nine people for three weeks." These nine people may take five or six weeks; the three week limit might require fifteen to twenty people; or worse, the three week limit might be impossible. Three basic elements exist in respect to any given system development life cycle. The are:

• Scope
• Resource
• Time

These elements exist in a fixed relationship to each other. Our goal is to maintain an effective balance among the three elements.

If any one of the elements is altered, we must compensate by adjusting the other two. For instance, if time is shortened, the resources must be increased (if the scope of the project is to remain constant); or if resources cannot be increased (say by adding more test time), the scope of the the project must decrease. Keeping these elements in balance is one of the greatest challenges facing the person responsible for development of the system.

Many factors affecting the basic elements, if left unchecked, will act as deterrents to the success of the system development. Some are:

• Programmers leaving the project
• Additional tasks being introduced
• Target dates advanced
• Changes in system definition

These forces could all work against the possibility of a system being completed on target date, and therefore negating the original estimate of resources. By their nature, they require constant monitoring and checkpoints along the way.