Computer-Organized Cost Engineering - Taylor & Francis Group

COMPUTER-ORGANIZEDCOST ENGINEERING

COST ENGINEERING

A Series of Reference Books and Textbooks

Editor

KENNETH K. HUMPHREYSAmerican Association of Cost Engineers

Morgantown, West Virginia

1. Applied Cost Engineering, Forrest D. Clark and A. B. Lorenzoni2. Basic Cost Engineering, Kenneth K. Humphreys and Sidney Katell3. Applied Cost and Schedule Control, James A. Bent4. Cost Engineering Management Techniques, James H. Black5. Manufacturing Cost Engineering Handbook, edited by Eric M.

Malstrom6. Project and Cost Engineers' Handbook, Second Edition, Revised

and Expanded, edited by Kenneth K. Humphreys7. How to Keep Product Costs in Line, Nathan Gutman8. Applied Cost Engineering, Second Edition, Revised and Expanded,

Forrest D. Clark and A. B. Lorenzoni9. Managing the Engineering and Construction of Small Projects:

Practical Techniques for Planning, Estimating, Project Control,and Computer Applications, Richard E. Westney

10. Basic Cost Engineering, Second Edition, Revised and Expanded,Kenneth K. Humphreys and Paul Wellman

11. Cost Engineering in Printed Circuit Board Manufacturing, Robert P.Hedden

12. Construction Cost Engineering Handbook, Anghel Patrascu13. Computerized Project Control, Fulvio Drigani14. Cost Analysis for Capital Investment Decisions, Hans J. Lang15. Computer-Organized Cost Engineering, Gideon Samid16. Engineering Project Management, Frederick L. Blanchard

Additional Volumes in Preparation

COMPUTER-ORGANIZEDCOST ENGINEERING

Gideon SamidD & G Sciences

McLean, Virginia

Marcel Dekker, Inc. New York and Basel

library of Congress Cataloging-in-Publicarion Data

Samid, Gideon.Computer-organized cost engineering / Gideon Samid.

p. cm. — (Cost engineering ; 15)Includes bibliographical references and index.ISBN 0-8247-8339-51. Engineering economy. 2. Engineering-Estimates. I. Title,

n. Series: Cost engineering (Marcel Dekker, Inc.); 15.TA177/7.S26 1990 90-3804620' .00285--dc20 OP

This book is printed on acid-free paper.

Copyright © 1990 by Marcel Dekker, Inc. All Rights Reserved.

Neither this book nor any part may be reproduced or transmitted in anyform or by any means, electronic or mechanical, including photocopying,microfilming, and recording, or by any information storage and retrievalsystem, without permission in writing from the publisher.

Marcel Dekker, Inc.270 Madison Avenue, New York, New York 10016

Current printing (last digit):10 9 8 7 6 5 4 3 2 1

PRINTED IN THE UNITED STATES OF AMERICA

Dedicated to my FatherYa'acovSamid

A Fine EngineerA Remarkable Teacher

https://taylorandfrancis.com

FOREWORD

The book and the factory, the word and the deed, the plan and its execution, thedreams and their fulfillment... I credit my personal accomplishments in life to myeducation as a child, as a student, and later as a corporate executive, to keep theseaspects in balance, always. It is not easy. At times one is carried away by airydreams, neglecting to consider the cost of his accomplishment. Conversely, onemay be steam-carried by his daily rush, minding the trees, overlooking the forest.The balancing act is an act of art.

Computer-Organized Cost Engineering is a book that reminds its reader of thebalance and the interplay between the desired and the possible. To accomplishanything you may wish for will cost you resources, time, money, and attention.All are exhaustible and, if not managed properly, will run out before your goal isaccomplished. When this happens, it doesn't matter anymore how great your idea,how noble your wish-it is left unrealized. Running a major industrial corporation,I witnessed all too often the dichotomy between those who are good at setting uplofty goals but arc too haughty to mind the dollars and cents and those who knowthe price of all the parts but are blind to the value of the whole. When thisdichotomy is left unbridged, it spells disaster. I spent much of my corporate timebuilding those bridges.

With that perspective, I view Computer-Organized Cost Engineering as a bookthat fills a certain void in the engineering literature. There are plenty of textbooksthat tell how to design a machine or a process, but they rarely address the questionsof how to estimate the cost of their design, how to schedule the work realistically,and how to control the production once it rolls off the drawing board. Costengineering books, on the other hand, tend to dwell on such technicalities of bill ofmaterials, form management, and filing, which quickly bore the engineer whomistakenly perceives cost engineering as clerical in nature. And that is where thisbook is different. It emphasizes the integrity between plans and their cost. Itdescribes the unity between thinking outline and penciling details.

vi Computer-Organized Cost Engineering

This book expresses its cost engineering ideas through the craft of computerscience and information technology, and in that respect it is very timely. Yet itsbasic message of balance and the need to bring the goal, the plan, and its executioninto good harmony is timeless.

Max RatnerChairman of the Board

Forest City Enterprises, Inc.Cleveland, Ohio

PREFACE

Cost engineering spreads across the fertile ground between technology andbusiness. It is the challenge of balance: creativity and order teaming up to build,to put together, to establish. Computer technology unleashed the potential of costengineering. It serves as a platform from which good engineering judgment,experience, and insight can be heard.

This book was written for engineers, for students, and for everyone with theurge to build that which cannot be accomplished in an instant. It is about projectsthat take time, resources, patience, judgment, teamwork, and perseverance. It iswritten with the accent on the original turf on which the profession came into itsown: industrial and residential construction. Yet I have tried to reflect theuniversal appeal of computer-organized cost engineering, and to make the bookreadable to anyone interested in "getting there" within budget and on schedule.

The book reviews the practice, the procedures, and the philosophy of the craftof allocating limited resources to make unlimited dreams come true.

The tools change so fast, the techniques evolve more slowly, but the principlesendure. I learned the principles at home, the techniques in school, the tools atwork.

I was educated as a nuclear engineer and a chemical engineer. I worked in acoal mine, in oil companies, and in defense installations. I practiced with controlhardware, spacecraft, and computers. I was a glorified gofer, an overtitled director,and a satisfied chief engineer. I am proud to uphold a family tradition: anengineering way of life.

I am honored by every reader who turns to this book.

Gideon Samid

ACKNOWLEDGMENT

Always on my mind, my mother. In ways only her own, she encouraged me totake this commitment and see it through. She is not with us today to see the result.I do thank my father, whose actions are a wonder until this very day. My brother,Amnon, helped me with unlimited devotion. My wife, Dvorit, shared the trenchesand the the ups and downs. My daughter Anat, working within D&G Sciences,organized and filed, compiled and edited-with grace, insistence, patience, andstyle. Her contribution is reflected in the artwork, the typesetting, and the generallayout. My son, Yaron, kept me challenged. My editors at Marcel Dekker, Inc.,were forthcoming and supportive. In particular, I wish to mention Hugh Haggerty,who steered me through the last phases, never losing his patience. ProfessorKehat, Mr. Max Ratner, and David Rosoff found the time to review the manuscriptand enlighten me with their professional comments. And then, all the unnamedteachers who taught me a lesson a day throughout my diversified career: Yourfingerprints are all over this book. Thank you indeed.

INTRODUCTION

This book chronicles the spectacular growth of a newborn: computer-organizedcost engineering, an old profession fertilized with a new technology. Suddenly theenvelope of the possible is redrawn. Dormant opportunities are awakened. More isasked of the cost engineer; more is dependent upon him or her. Old ways must bereexamined; new ways must be duly adopted. Excitement is in order, but prudenceis, too. Throughout this book, I have tried to express both enthusiasm and caution,keeping an eye on the opportunity and the risk. Much like a powerful hammer: usefulin construction, but watch your fingers.

This is not a beginner's book. If you happen to be completely unaware of costengineering, cost estimating, scheduling, and cost control; if project management istotally out of your world; if resource allocation is Greek to you, reading this book mightprove quite confusing. On the other hand, it is not an expert-narrow, jargon-laden dryaccount. Having a rough sense of the above-mentioned topics will make you a targetreader. Some paragraphs may use a term that is not explained in the text, but the thrustof the text is not dependent on these terms (e.g., the term "head" in costing a pump).These are compromises needed to accommodate the professional cost engineer aswell as a wider circle of readers variably removed from the details of the profession.The reason for such a broad net is rooted in the new face of the profession. Computertools now allow more people to practice cost engineering, while professional costengineers are freed of the more clerical parts of their craft and focus on the morethoughtful elements. The changes imply new depth and new breadth. The book tries tofollow both. Attempting to capture the essence of the change in modern cost engineer-ing, yet living with the constraint of scope, the book had to leave out many valuabletopics.

Cost engineers, before the computer, simply ignored the true complexity of theirprofession because they could do nothing about it. They also largely avoided theuncertainty inherent in predicting the future (future cost or schedule) and resortedto deterministic, sometimes arbitrary, formulas. Complexity and uncertainty are thetwo dragons for which the computer is a fit match. But the cost engineer must learnto use the computer for what it's worth. This book tries to help.

Chapter Walk-ThroughThe book is structured in three parts. The first two describe cost engineering and computertechnology, each as viewed by the other, and the third part examines the practice, theprocedures, and the philosophy of integrating the two.

Part One, A Computer Technology View of Cost Engineering, is divided into twochapters: Elements and Business Considerations. Elements provides a run through thethree traditional categories of the profession: cost estimation, scheduling, and costcontrol. Cost estimation is viewed as the centerpiece. The chapter portrays theroutines of construction estimates, and industrial estimates, as well as estimates ofa softer nature. It ends with a section called The Rhythm, which features topics notfitting into one category or another. They show how the three categories are linkedtogether to create a rhythmic sequence. In the second chapter of Part One, Business

2 Computer-Organized Cost Engineering

Considerations, the sections describe the relationship between cost engineering andcontractual commitments, the competitive edge, and the ever-present uncertainty. At onepoint, the very essence of cost engineering—planning—is cast in the metaphor of a crutch:something to walk with but to run without The popular notion of "what iF is analyzed andcritiqued, and its reverse-"if what"-is suggested as a more challenging alternative. The lastsection in this chapter focuses on the dichotomy cost-results and the dynamics of therespective uncertainties: cost uncertainty and result uncertainty. It describes a method forreducing the two in a balanced way.

In Part Two, A Cost Engineering View of Computer Technology, the discussionruns through the practice, the procedures, and the philosophy of the new technology asseen by cost engineers. The first two chapters deal with the tools: tools of the costengineering trade and tools of the computer host. In Tools of the Trade, the sectionsdescribe the dedicated cost engineering software and the general-purpose softwareemerging as the stronger leg, riding on the phenomenal success of personal computers.The discussion is focused on computing software, database software, and graphicstools. The second chapter, Tools of the Host, comes with two sections: one under theheading of Sharing — sharing resources and sharing information; and the other underthe title Frameware — utilities and software aids that constitute a framework in supportof other programs. Naturally these two topics don't even come close to covering therange of computer tools that underlie cost engineering software. The two wereselected for discussion because both are important and seem to fall between the chairs,so to speak. Using a computer, the reader is necessarily using a particular operatingsystem and has probably more documentation about it than he cares to read. A similarpredicament holds for hardware. It is harder to find a good discussion on theavailable tools for sharing resources and sharing information, across the office oracross the globe. The same is true for the various utilities that make the life of acomputer user so much easier.

Procedures, Chapter 5, is in the same bind as the tools chapters. The scope requireda stark elimination of important topics. The selected topics are software engineering(a cursory discussion) and a handful of applications: archiving of cost engineeringdata (the History Accumulator), the power of stochastic processing (Monte Carlo),and then a topic that should not have been there: computer security. Computer crimeis a growing menace, and protection must be a concern at any level of usage. Anothersection brings a practical application for incoporating conflciting expert knowledgethrough a neural network. The section ends with a topic that may seem light: personalspace — the techniques of making our computer-burdened desk a more workableenvironment. The productivity impact is largely underrated.

The last chapter in this part, Concepts, features two sections. The first describessome of the "laws" of handling information mass that have emerged with computertechnology. Issues like data glut, data reliability, documentation, and artificial intel-ligence are assessed, explained, and concisely presented.

The second section of Concepts offers a discussion of the battle against complexity.The sheer number of details involved in some large projects, the interrelations, the

Introduction 3

everything-affects-everything syndrome - these components of the cost engineeringcomplexity are always a challenge. The section runs through the weapons that contain,manage, and ultimately defeat the complexity dragon.

In the third part, A Utility View of Organization, the discussion is about how to engage thenew technology with the old profession-how to use, not abuse, the power of combiningcost engineering with computer technology. The part offers two chapters: Chapter 7,Methodologies, talks about the how-to of computer-organized cost engineering, and Chapter8, In Focus, offers various specific designs the reader can use for programming his ownsoftware and integrating it into his cost engineering environment.

In Methodologies the discussion begins with some organizational principles thatmay serve as guidelines in the process of sorting out a good way to use computer powerwith all its variety vis-a-vis cost engineering through all its aspects. Later sectionsdiscuss the modes of such engagements and how they affect the job descriptionof certain cost engineers. The final section provides a checklist, a sequence of stepsthrough which a cost engineering need may be matched with a computer tool.

In Focus discusses a small variety of specific products. The polar elements repre-sentation of trees offers a practical way to represent a rich body of information aboutprojects and hierarchies in general. T*VIEW is a tool to manage projects that aredefined through one prime hierarchy, and Dispenser(Z) is a detailed case studyof the balanced reduction of uncertainty described in Part One (Business Con-siderations). Chapter 8 closes with a detailed design document for a cash flowproduct that can record transactions as well as manage contractual commitments.

/ hope this chapter walk-through will help some readers focus on their interest andbypass the rest. I also humbly hope that some will flip the pages from first to last and read,or at least scan, this book cover to cover.

Whatever your level of reading, please let me have your comments.

CONTENTS

Dedication HiForeword (Max Ratner) vPreface viiAcknowledgment viii

Introduction 1

Part One A Computer Technology View of Cost Engineering 7

1 Elements 8

2 Business Considerations 80

Part Two A Cost Engineering View of Computer Technology 141

3 Tbols of the Thide 1424 Tbols of the Host 1935 Procedures 2256 Concepts 271

Part Three A Utility View of Organization 307

7 Methodologies 3088 In Focus 346

Appendices 383References 385List of Organizations 392Bibliography 403Index 419

PART ONE

A Computer Technology View of Cost Engineering

Cost engineers are civil engineers, mechanical engineers,aeronautical engineers, and nuclear, chemical, and electricalengineers who take engineering a step further-into a costestimate, into a scheduled plan, into a world of limitedresources.

In the process, they may write a lot of numbers and sumthem up. To the uninitiated, the cost engineer looks like aclerk, or like an accountant. At times he looks like aneconomist. The term "engineering" seems out of place. Howwrong! It is subject-matter expertise that governs theprofession. That is why a new high-rise cannot be estimatedby a clerk, an industrial plant cannot be cost-assessed by aneconomist, and a nuclear reactor cannot be dollar-evaluatedby accountants. The people in these discliplines have theirhands full, and their contribution should not beunderemphasized, but they are not cost engineers.

Computers gave the cost engineer a tool that added a newdimension to the profession. The use of computers in itself isan engineering endeavor, and so today the term "(cost)engineering" has a dual meaning: expertise not only in thesubject matter but also in using computers in the process ofoptimizing resource allocation. The modern cost engineer isa central player in a competitive economy. His or herresponsibility is to find ways to extract more results fromfinite dollars and limited time. And, conversely, he or shetries to engineer a solution to the problem of achieving atarget result with a smaller investment.

Available resources are finite; expressive imagination isinfinite. This anomaly is the challenge of cost engineering.

1Elements

Cost engineering is a two-way window. Looking through this window thebusiness community relates to science and technology. Looking theother way, scientists and engineers hear and see what business wants anddoes.

Cost engineering answers questions: How much does it cost? Howlong will it take? And later, Does it really cost and take as much and aslong as predicted? The cost engineering components that handle thesequestions are cost estimation, scheduling, and cost control, the elementsof cost engineering.1

The difficulty or simplicity of handling these questions depends on (1)the complexity of the subject matter, (2) the prevailing constraints, (3)the extent to which 1 and 2 are given or known.

(1) A formal definition of cost engineering is given by Humphreys 1984,1987. Speaking officially as theexecutive director of the American Association of Cost Engineers Humphreys defines a costengineer as "an engineer whose judgment and experience is utilized in the application of scientificprinciples and techniques to problems of cost estimation; cost control; business planning andmanagement science; profitability analysis; and project management, planning and scheduling." It isinteresting to contrast this with an older definition given by Bauman 1964: "Cost Engineer Arelatively new designation for any graduate or professional engineer or equivalent employing histechnical skills in the practice of process cost estimation, cost control, profitability, or the generalengineering economics of capital investment." In most environments today, MBA's and economistswho are not engineers take hold of the overall business planning, and management, pushing thecost engineer into his core elements of cost estimation, scheduling and cost control.

Elements

When 1 and/or 2 comprise a great deal of data computers are calledfor. When they involve complex computations computers are relied onagain. When the data and computation are generally unknown or illdefined computers will help simulate the missing link.

Business does not let go. The answers to the three basic questions arenot enough, Can it cost less? Finish faster? Is it possible to anticipatedisagreements about estimates versus actual costs earlier? Cost en-gineers are put on the spot. General engineering is not shy, either. Canwe do more with the given budget, use the project time better, and allowearlier indication for surprises?

Both business and engineering tap the cost engineer's shoulder: with:If I change my mind later, can it be done without a cost or schedulepenalty?

These questions, driven by a competitive economy, place a greatchallenge at the door of cost engineering.

To meet this challenge, cost engineers had to grow from engineers whodo clerical cost to engineers who do cost as mathematical abstraction.Computers took over the endless summations, the massive data han-dling, even the data entry and data display, and cost engineers moved onto wrestle with the complexity of optimal resource allocation.

(1) One can hardly dispute the importance of resource allocation in any project, and economic activity,yet, it is quite an abstraction, and as a result cost engineering in general remains in relativeobscurity- Webster New World Dictionary 1980 has an entry for civil engineering, but not for costengineering. Even in the engineering community many confuse cost engineering with costestimating or cost accounting. Major Engineering handbooks don't mention cost engineering, noteven as an index entry. Among them Kutz 1986 Mechanical Engineering Handbook, Kong 1983Handbook of Structural Concrete, Grimm 1990 Handbook of HVAC, and Merritt 1983 StandardHandbook for Civil Engineers". On the other end, non-engineering estimators and appraisersfurther blur the distinction of the cost engineering profession. It sounds impressive when anarchitect, or an engineer says: I designed this... or I built this... What can a cost engineer say? Icosted this... I resource-allocated this... The situation is similar to that of an anesthesiologist whocan not claim that he performed the surgery, but it is a fact that his expertise or lack of it willdetermine the recovery of the patient.


A resource is anything one can run out of, primarily time and money.Equipment, materials, skills — even job opportunities are all resources.The modern cost engineer builds associations of resources: dollars-timeslots-crew-equipment-material-supervision.

Given n resources of one type and k resources of a second type, thereare n * k possible "pairs" (allocations). Add m resources of a third type,and the number of three parts allocations becomes n * k * m. It growsfast. If there are 10 resource types and there are 100 items of each, thenthe possible allocations become

10010

Given 10 day-long jobs, 10 crews, and 10 calendar days (all areresources), there are 10*10*10 = 1000 theoretical allocations. Some ofthem, taken together, are impossible; others are possible but make noengineering sense; and some that make engineering sense don't makebusiness sense. Some combinations taken together will constitute a goodoverall plan. One of them will be best. Which?

At first glance it may seem that computers, with their legendary speed,will be able simply to go through all the possibilities and offer a selection.A more careful review will show that even if computers becomethousands of times faster than they are today, they will still be far tooslow to crack the full-size allocation challenge. Therefore, it is neces-sary to use faith, experience, intuition, and heuristic — that which is notobjective and mathematical — and through these strive for the bestallocation. Computer-Organized cost engineering is not yet reduced to

(1) See Conway et al 1967 for a thorough discussion of the inherent complexity of scheduling. Also seeHu 1982 for a computer view of the same topic.

(2) Hu 1982 offers excellent examples of the limits of computability. The renowned Dijkstra in page 3in Dahl 1972 gives a simple but illuminating observation. See Gleick 1987 for an enthrallingdiscussion on the modem trend to express complexity with tools of apparent chaos rather than withtools of arbitrary order.

Elements 11

a recipe, expressed in formulas or software. There are recipes and thereis a lot of software, but common sense and judgment are still very muchin the game.

Much heat is generated from disagreements between the two types ofcost engineers: those who are intimidated by computers and rely onmethods that served them for years, and those who are wedded tocomputers and see the entire profession as software to run, or to bewritten. The literature mirrors this division. On one hand are the goodold-fashioned cost engineering books, which make cursory mention ofthe computer, and on the other hand, a new wave of computer books isflooding the market, with little mention of the virtues of classic costengineering.

The prospects of the profession and its good fortune lie in a balancedapproach.2

COST ESTIMATION

Cost estimation is the centerpiece of cost engineering. There are somany reasons costs will change, and prices will vary, that the life of a costestimator is never too cozy. Unlike the design engineer, who deals withlaws of nature — never finicky, constant, or reliable — the elements thatthe estimator manipulates are as dependable as the weather, as constantas a shoreline, and as avoidable as taxes.

Process engineers, architects, and designers can reach a point ofultimate accuracy. The cost estimator cannot. It is a frustration he orshe must bear and live with. The most that a cost engineer can hope for

(1) Some pre computer era books survive the times, see Popper 1970. The "Lang Factors" introducedby Lang in 1947 are still cited, but modern literature like Cheadle 1987, Koenigseker 1982, Clark1979, Jelen 1983, or Winklehaus 1982, as well as Tavakoli 1989, and Prerau 1987 reflect thestrong emphasis on mathematical abstractions, and computer technology.

(2) See Samid 1984, and Samid 1982 for some 'balance1 notes.


is a past-perfect estimate. This is a cost estimate based on a perfectanalysis of the past. It is 100% accurate if the future is a mere extrapola-tion of past events. To the extent that the future hides surprises, theestimate will bear discrepancies.

The estimator's goal is to draw the full body of conclusions from thepast and to be ready for anything the future might offer. Let us focus onthese two techniques.

Learning From The Past

From where else? The biggest rival tothe past as a teacher is "wishful think-ing." Keeping the past as the primeteacher is the duty and responsibility ofthe cost engineer. The dynamics areusually as follows. One track: wishfulthinking expects a result, and then his-tory is searched to support it. Tracktwo: history is learned from, but on theway from raw data to respective con-clusions, wishful thinking sneaks in andcontaminates the outcome.

Wishful Thinking

Blocking W

DATAESTIMATES

Data-to-ConclusionProcess

ArbitraryParameters

fig LI producing an estimate

In producing an estimate one tries to use allthe relevant data, avoid wishful thinking andminimize the amount of arbitrary input

The mathematical techniques thatlead to extracting a set of conclusions from a body of data are notwell-founded. They may never be. Therefore the cost engineer has toresort to techniques which are acceptable and thereby defensible. Twodangers loom: (1) that the estimator will overlook some of the con-clusion potential within the data, and (2) that he will see in the past whatis not there — draw conclusions that are not warranted on the basis ofwhat happened before. Often both discrepancies happen simultaneous-ly during the same estimate process. See insert "producing an estimate"(fig i.i).

The techniques in use are (1) sameness, (2) trending, and (3) inter-polations.

Elements 13

SamenessSameness is the most common, most automatic way to learn from thepast. An estimator will record a cost figure and assume that history willreplay itself in the future. In noninflationary times and when technologydoes not shake things too much, this simple method is also the best (whenit applies). It helps if the estimator has a constant supply of recenthistory, whether his own or from external sources. The challenge hereis to keep the massive amount of cost data in an orderly fashion so thatit can be found when needed and used for an estimate. The engineeringchallenge is to ascertain sameness validity; that is, in what case, is anhistorical price likely to be valid asa future COSt figure? { A time dependent variable

TrendingNext to sameness, trending is themost popular learning-from-the-past technique. But unlike same-ness it involves a host ofmathematical techniques that oftensharply disagree. When a cost fig-ure changed in a given pattern in therecent past, what does this say aboutits future behavior? If the es-timator is lucky and the pattern isthat of a straight line, then theprojection seems simple. If therecent pattern is more erratic, then depending on which mathematicaltechnique he uses, the projection will be different and in any case will bemuch less valid (because of diversity of opinions). See insert "forecastinguncertainty (fig 1.2)."

The computer challenge here is to program the various forecastingalgorithms, connect them to the database, and apply them properly. Insome forecasting methods, the trending is based on a simple time series,which are data of one variable (say the cost of a cubic yard of ready-mixconcrete) as it varies over time. In other cases the data of many variablesare taken into account. And the more variables, the more crucial is theconnection between the algorithm and the database.

time

fig 1*2 forecasting uncertainty

The three lines represent three valid options formodeling a trend out of the four data points. Eachmodel incorporates an arbitrary assumption aboutwhat is important and what is not. Often this ar-bitrariness is shrouded in heavy mathematics.


InterpolationsThis elaborate technique involves using two or more loosely relatedhistorical cost figures, combining them on an imaginary model of reality,and deducing from this model what a third cost figure should be. Theestimate in this case is only as good as the model. The variety ofmathematical offerings is enormous here, standardization is nonexistent,and the validity of the result is always open to debate.

The respective computer challenge is to keep the historical databasein good order, programming the interpolation model properly, and thentying the two together without a flaw.

Depending on the model itself, the programming challenge will havetwo parts: (1) to ensure that the program reflects what the modelintended, and (2) to write the program efficiently enough so that it doesnot take forever to produce the estimate. The degree to which onesucceeds with the latter challenge is readily obvious. The first challengeis difficult because flaws may thrive, like fungus in the marshes ofcomputer talk, and because of the cryptic appearance of programminginstructions. Read more about this in Chapter 6.

Surprise Readiness (Risk... Contingency...)

If the future holds a "step function" surprise, that is, a surprise withoutany advance notice, then there is no way to be ready for it before thesurprise fully presents itself. For these surprises, readiness is in the formof preconceived "what i f plans. Most surprises, fortunately, send some

(1) Surprise-readiness is discussed under topics of risk, contingency and decision analysis. See French1986 for a modern, analytical account of decision theory. See Saaty 1980,1982 as well as Weiss 1987fora presentation of AHP — Analytical Hierarchy Process — designed to handle complex policyand decision situations. See Brown for a simplified version of decision theory, and see Ghlaseddin1986 on developing a framework for decision support systems. See Graf 1984 for an overview ofcontingency considerations. See Stevenson 1984 for cost estimate contingencies, and see Cabano1989 on the same subject from the point of view of the investor. See Hertz 1983 for riskmanagement and its applications. See Curran 1989 for a recommendation on range estimates tohandle uncertainty. See Belev 1989 of minimizing risk in high-technology programs. See Mathur1989 on risk considerations in capital cost estimating. See Ahuja 198S on resource uncertainty andtheir impact on scheduling. Fischhoff 1981 contemplates the issue of acceptable risk. Wilson f982focuses on risk/benefit analysis. Rowe 1977 offers an insightful anatomy of risk. Gilbreath 1983provides a review of operational risk in managing construction contracts. Charette 1989 andBoehm 1981 do the same for software engineering management.

Elements 15

time dependent variable

telltale signs to announce their coming, and it is the duty of the costestimator to be alert to these signs and interpret them correctly.

The computer proved helpful on both accounts. What if analysis isnow feasible and fast. Advance notice signs can be captured and inter-preted even if they show up as little bits and pieces, scattered all over theplace. See insert "step-function surprise" (fig 1.3).

'What If?"Before the com-puter came to help,cost estimatorscould hardly finishthe most probablecase estimate, andthe notion ofdeveloping addi-tional estimatesbased on differentassumptions wastheoretical. Buttoday it is possible,without much extrawork, to assemblenumerous estimatesbased on many setsof assumptions. Ifsuch estimates areproperly docu-mented, then they collectively amount to surprise readiness. Should oneof the documented cases turn out to be reality, the plan for it will beready.

The problem of course is that there are always too many possibilities,too many tracks on which the future can approach us; it is impossible toplan for them all. A selection process is required, and if reality shows upas an unselected option then all the what if effort is in vain. To accom-modate this variety, some techniques implement a continuum of options.Other take the discrete way. The first approach covers more cases, but

fig 13 step-function surprise

A step-function surprise happens without advance notice, and can not besystematically predicted. Most changes, fortunately, send telltale signs,and some, as depicted, will happen gradually. It is then up to the estimatorto spot them.


each case is less defined and not as clearly thought out. The discretemethod covers fewer options but allows for in-depth analysis of each.1

Leading IndicatorsUnforeseen changes that send leading indicators pose a special challengefor the cost estimator. Some indicators come from the general economy,and the estimator can rely on economics experts and publications to alerthim and educate him on their meaning. Inflation, wholesale prices, andconstruction starts are but only three of a host of indices that may applyto a particular estimate and trigger a reevaluation of the figures.2

Other indicators are unique to a project, and the estimator must findthem on his own and do his own interpretation of their impact. If theunion is negotiating higher fees, if electrical subcontractors are over-loaded with work, if a test shows that the material of construction thatwas specified does not withstand the higher than expected reactortemperatures — all these are leading indicators, and the earlier they areallowed to affect the estimate, the better.

ATTRIBUTION VERSUS SUMMATION

There are two fundamental ways to assign a cost figure to an object: (1)attribution and (2) summation. The first is through one of the threemethods mentioned before: sameness, trending, and interpolation; thesecond is based on the simple premise that the cost of the whole is thesum of the cost of its parts. If the cost of the parts is known, then

(1) "What i f and multi-options considerations became very popular in modern literature. See forexample Haneiko 1983, Wilson 1982, Curran 1989, Zimmerman 1983, Mathur 1989, Ahuja 1985, orSamid 1989.

(2) ENR - Engineering News Record, Marshall & Swift (MAS), Nelson, and Chemical Engineering,as well as the Wall Street Journal and Business Week, are some well known publications whichtrack relevant industrywide indices.

(3) Ohlrichs 1981, Samid 1984, and Bullis 1987 offer discussion and illustrations for project-specificindicators. DuBois 1980 presents a study of cost indices. Patterson 1969 forwards a treatise onpreparing and maintaining a construction cost index. Review Winklehaus 1982 for indicatorsspecific to the construction industry. Also refer to Spinney 1985 and Luttwalk 1985 for an intruigingaccount of Pentagon usage of cost indicators.

Elements 17

summation will produce the cost of the original object without uncer-tainty. That is, the uncertainty of cost attribution is left to the parts. Andnow, instead of attributing a cost value to one object, we are faced withdoing the same to many objects. More work is involved but so is a greateropportunity for accuracy and what is often more important, a betterchance to convince others of the validity of the estimate.

This summation-attribution trade-off is reflected in the classes ofestimates: the first estimates, so-called conceptual, are long on attribu-tion and short on summation. At the other end of the spectrum, theopposite is true: extensive summation, and limited attribution. Thevarious estimates between these show a trend in which high-level costattribution is gradually replaced by breakdown to smaller parts andsubsequent summation.

Let us briefly review a simple example and then dwell a bit on thecharacter of summation that is innate to cost estimations.

Office BuildingIf a developer considers an office building in an office park, then veryearly in his considerations he will want a rough estimate. He would beeager to find if he is in the ballpark as far as his financial muscle isconcerned. Definitely this is not the time to do a lot of summations oflittle parts. To attribute a cost figure, one could use the "sameness"approach, that is, take an available cost figure of a similar office buildingin the same park, which was built recently enough, and attribute the samecost to the building being considered. If the office building has to bebuilt far into the future, the estimator can take into account sometrending techniques and plot the total construction cost of similar officebuildings that were built at different times in the past and then extrapo-late these figures to the desired future time frame.1

If the estimator relies on, say, the cost of a hospital in the area and thecost of a school building in the neighborhood, rather than the cost of an

(1) See Wade 1982, Koenigseker 1982, and Jain 1983 for further reading on methodologies for officebuilding indices.


office building, then he might use some form of interpolation to assessthe cost of the building in question. It is worth noting that the hospitaland school costs don't have to be actual historical figures: they can bedefinitive or appropriation estimates.

When the estimated ballpark or conceptual cost is within range, thedeveloper will gradually want to substantiate the figures (and if he doesnot care, the lender does), and this is when summation is in order. Theoffice building will be defined according to its parts; each part will beestimated separately, and the numbers added up. The breakdown maytake various forms. It is customary that the first level of breakdown willbe an accounting level, dictated by applicable accounting standards.Accordingly the total cost will be separated according to fixed capital;working capital, associated costs, like insurance and, taxes; and moneypaid to the construction contractor, which is where the heart of costengineering lies. Deeper breakdowns will go into bare site cost versusengineering and management items, and then into battery limit expen-ses, off-site expenses, steel structures, mechanical, instrumentation,electrical — all of which customarily cut along the material-labor-sub-contractor cost element.

Summation, Accuracy, And JustificationWhen the cost of an object is represented as a summary of cost figuresof many of its detail parts and those details are organized in an impressivehierarchy, then altogether the cost statement acquires status and"respect". The psychological impression is universal: a lot of work wasput into this — it must be right. The practical consequence is that if it isnot right one has a hard time proving it.

One line of logic will claim that merely pushing the cost attributionprocess down into the details will not necessarily improve the overallaccuracy. True enough, but on the other hand the details may be bettersuited for cost attribution, and their very multitude invokes a statisticalpremise that claims that the accuracy of the whole is better than theaccuracy of the parts. Without going into statistical formalities, thisimportant premise can be shown through a simple example.

Elements 19

Summation AccuracyLet objects A and B each cost exactly $10. Let us assume that anestimator is likely to estimate each with a 10% accuracy. Using onlyround numbers, each object is equally likely to be estimated as

9 10 11

dollars. Which means that a third of the time it will be estimated

correctly, or a probability of 1/3 for a 0% inaccuracy, and a probability

of 2/3 for 10% estimation inaccuracy.

The object C of which A and B are parts will be estimated through

summation. There are 3 *3 = 9 possible summary combinations, which

will yield the following possible cost estimates for C:

18 19 20 21 22

19 20 21

20

In 3 of the 9 cases, C will be estimated with 0% inaccuracy, which isthe same as for A and B. However there will be 4 of 9 cases (probabilityof 4/9) in which the estimate will be within a 5% range from the exactnumber. And only 2/9 (compared to 2/3) probability that the estimatewill be 10% away from the exact number. In short, the accuracy of thewhole is better than the accuracy of the parts. The same holds in thegeneral case, and thus the more ramified the breakdown, the morebranches in the cost tree, and the smaller the items undergoing costattribution (as opposed to summary), the more accurate the total es-timate. 1

(1) Refer to Paradine 1970, Fry 1965, David 1962, and Anderson 1984 for an in-depth discussion ofsummation accuracy.


CONCEPTUAL ESTIMATES

"Conceptual" in this context is euphemism for "inaccurate." These areestimates one prepares when he either has few data to base his estimateon, or not much time to prepare a more thorough estimate, or, of course,a combination of these. Yet these are the estimates that often make orbreak a company. Because it is here that projects are killed before theyare thoroughly looked at. And if you happen to kill your best, mostinnovative ideas, you inevitably retreat as a competitor. If a project isunderestimated in the conceptual stage there are still many milestonesat which it can subsequently be killed or modified, but an idea that waskilled on the basis of a misleading conceptual estimate has no morechances. The question is how to improve the speed and the accuracy ofthis type of crucial estimate. There are several ways: (1) better raw data,(2) better attribution, and (3) increased summary estimates.1

Better Raw Data

Since most conceptual estimates are very poor with cost algorithms andsince most rely on simple "sameness" or "trending" attribution, it iscrucial to have good relevant data. To achieve this, one can (1) build adatabase from common sources, or (2) develop his own private datasource. The selected method depends on the situation. If the estimatorhas to produce ballpark estimates on wide-ranging subjects (as ap-plicable for banks and other lending institutions), then it is impossibleto develop one's personal database. If, on the other hand, the range islimited and the estimates are similar in nature, then a private databaseis in order. It was customary for years to keep data for conceptualestimates in graphic and in book form. These noncomputerized methodsare still popular and probably will be for some time. The more generalthe spectrum of estimate, the more handy the computer becomes. Costnetworks allow anyone with a computer, a telephone, and a password toupdate himself with the latest cost figures on just about anything.

(1) See Bakewell 1985, Ponce 1985, Koenigseker 1982, and Humphreys 1987 for representativediscussions of conceptual estimates. See Page 1984 for a conceptual cost estimating manual. ReviewHollman 1989 for a case study report.

(2) See Samid 1984 for a discussion on the considerations for the build/buy decision.

Elements 21

Better Attribution

Factor estimation is the common name for those "quick and dirty"conceptual cost statements. The term represents the attribution methodwhich takes two or more related cost figures and interpolates them intoan estimate of the object in question. Thus if one wants to build arefinery, he may look at a graph of the cost of refineries of variouscapacities and find an estimated cost.

Prices per unit are another common means. Buildings and structureshave been traditionally expressed as cost per square foot, and this cost isthe basis of conceptual estimates for a building of a known area.

Some factors are so acclaimed in cost engineering tradition that thereis no point in arguing with them, even if better ones can be found. If youestimate an industrial plant, you factor your cost off the equipmentfigures, if you estimate labor, take the labor to material factor, and soon.2

If one is faced with estimates of the same nature over and over again,then it makes a lot of sense to revisit some of those "holy cows" and adjustthem based on recent history. It also makes a lot of sense to use modernpattern recognition techniques to plow relevant data for the purpose offinding new and powerful attribution ratios.

A good ratio or factor is one that ties together a known data item withan unknown one. Thus the price per square foot of building ties togetherthe known area with the unknown cost. Equipment cost is easy toascertain through a phone call to a vendor, and therefore it is a usefulbasis for estimating piping, insulation, electrical, engineering, etc. But

(1) See Means 1987,1988,1990 (different books for different topics). See Richardson 1984,1988,1989.See Marshall & Swift 1981,1982,1984.

(2) Lang, as early as 1947, introduced a set of factors for industrial estimates of chemical plants, andthe concept is alive today. Amazingly, some of the figures are carried over, too often, blindly. SeeLang 1947.

(3) See Naver 1989 for an excellent review of remote access to specific data. See Jordan 1990 for aninformative discussion on PC communication tools, and procedures. See Beardon 1988 for ageneral networks discussion, and see part two in this book under "sharing".


these traditional factors are by no means the only ones. Having good andreliable factors means improved conceptual estimates, which in turnmeans a sharper competitive edge.

Increased Summary Estimates

At first glance the idea of running summary rather than attributionestimates in the conceptual mode seems a bit out of place. There is notime to build a cost hierarchy and assign individual cost figures to thebasic elements and then summarize it all. Indeed not, if it is donemanually. The advent of computers gave the ability to create automatedcost hierarchies, feed them with unit prices of common materials andlabor rates, and then perform the summary instantly and produce a coststatement. Conceptual estimates are rough and inaccurate because thedesign engineer has not yet specified the details to be costed. Tominimize this deficiency, the cost estimator will take the role of thedesign engineer and come up with some nominal specifications andbreakdown structures, which are not likely to accurately correspond tothe eventual design but are very likely to produce a conceptual costestimate that is more accurate than plain attribution.

DEFINITIVE ESTIMATES

An estimate deserves the adjective "definitive" when it is a pure sum-mary estimate — when the challenge is to take off the details fromdrawings and specifications and add them up properly, not missing anydetail or double counting any. The computation is simple; the datavolume is the problem.

Often the difficulty in definitive estimates is not so much to sum thenumbers up, as much as it is to unravel them to defend a cost figurechallenged by a reviewer. The other practical difficulty is the flexibilityto accommodate changes. One has to maintain the data in a high degreeof order if he is to be ready for questions; what if we change the stainless

Elements 23

steel specification to a higher grade? But the more one is ready for suchwhat if questions, the more one has to invest up front in setting the dataaccording to a variety of keys. As always, there is a trade-off that needsto be balanced.

The different computer products that help the estimator in his defini-tive statement will compete more on the appearance of the report thanon anything else, although such emphasis is not generally justified.

Variety In Estimates

The conceptual estimate is the first cost statement; the fully definitiveestimate is the last. Between these, depending on the environment,there may be several others that are a hybrid cost statement, taking partsfrom the conceptual and parts from the definitive. Contractors havetheir own series of estimates, architects have theirs, and owners anddevelopers have different estimates, too. Bidders in various environ-ments have some unique in-between estimates, and banks go by theirprocedures and their preferences. It matters greatly whether the es-timate relates to a new, unheard of project or whether it is anotherinstance of a known quantity. It matters if it is a project to build or aproject to demolish; it is a different series if the estimates relate tobuilding a factory in a distant place where all utilities, support, andinfrastructure must be costed, as opposed to building the same in anindustrial park. A brand-new building is different from a revamp job.The size of the project impacts on the number and appearance of theestimates (and the number of people involved).1 Residential construe-

(1) See Humphreys 1987, and Stewart 1987 for a good exposition of organizing cost estimating data forlarge projects.


tion is one story (or more), commercial development is its own case,chemical plants are costed with idiosyncrasies unshared by others, andcosting the construction of an airplane or a nuclear reactor are different;they all come with traditional jargon and specialties. Their underlyingstructure is always the same, and it is this commonality on which this bookis focused (fig 1.4).1

Relative Usefulness ofEstimate

Mid-RangeEstimates

ConceptualEstimate

project process

Irecommended decision zones -

fig 1.4 upgrading class of estimate

As the project progresses it offers more raw data for its estimate. The original conceptual estimate is replacedwith one or more mid-range estimates which in turn are superseded by the definitive statement Points X and Yrepresent the switch over states when the next class of estimate becomes more effective. Throughout the seriesof estimates the owner will make successive go/no-go decisions.

(1) This account focuses on the two extremes: the conceptual estimate and the definitive. Thein-between types are numerous and non-standardized. The American Association of CostEngineers has proposed three types of estimates: the "order of magnitude" estimate with accuracyof -30% to +50%; the "budget" estimate ranging from -15% to +30%, and the "definitive": -5% to+15%. See Humphreys 1987 for a discussion on the various types of estimates. See Humphreys1984,1987 and Stewart 1984 for a clear discussion on types of estimates.

Elements 25

Logical Expressions

Inspired by accounting software, cost engineering was initially limited tousing computers as data containers and fast calculators. It was onlygradually that logic was welcome. When it comes to expressing a pieceof logic, computers excel. Logic and computers go hand in hand. Com-puter languages match or exceed any other language in their ability toexpress logic. Thus, all cost-related logic that appears elsewhere can betranslated into computer language and express itself in the eventualschedule, or cost statement. Such logic appears in contracts, codes,regulations, and standards.

A contract will stipulate conditional cost rates and payments, and thoseconditions can be programmed (see CASH* VIEW in Chapter 8). Thegovernment regulations FAR and DFAR are readily programmable, andso are various municipal guidelines.

Modern construction is inundated with regulations: equal oppor-tunity, safety, and visibility considerations are taken up by governmentbodies and by various independent institutions. The American Instituteof Architects issues General Conditions of the Contract for Construc-tion. Guidelines are published by the American Society for Testing andMaterials (ASTM), the American Concrete Institute (ACI), theAmerican Association of State Highway Officials (AASHO), andnumerous others. Codes like ACI 305-72, Recommended Practice forHot Weather Concreting, or ASTM A325-71, High-Strength Bolts forStructural Steel Joints, may all be translated into computer language.

Objectivity And Adversity In Estimates

Since every estimate is an opinion, it is also biased. Even if the estimatorhas no stakes in the outcome, he nonetheless comes to work with acertain background. If his recent and dominant experience is overes-timating, then he is likely to be wary of another case. The same holds forunderestimation. In practice, however, just about any estimator hassome stake in the outcome, even if it is not on the surface. The relation-ship between a biased estimate and the objective estimate is similar tothat between a subjective sense of justice and its corresponding objectivestate. In the justice system, we have come to realize that the best way toguarantee a minimum bias is the method of adversity: justice is supposed


to come through if two opposing attorneys argue for their subjectivepoints of view. Business practice was also refined to a similar solution:an estimator with an interest in a low-cost figure is pitched against anequal professional with an opposite interest. The two argue against eachother in written cost statements, presentations, and the negotiationstable between seller and buyer. This is a good idea when it is keptcivilized. It is important to stress that having two opposing estimators ofequal qualification is very important; otherwise the amateur will be easilyintimidated.

The arguments and counterarguments are best practiced if the twoopposing estimators use the same "sheet of music" — the same computersystem. If they don't, then settling differences may be a hopeless task,since who can tell if the difference is material or due to the software?Ideally the two will use the very same model, agreed upon beforehand,and focus on adjusting input parameters. In the event that an unsettledargument is forwarded to a third estimator, such a one-system approachis a good converging point: asking the two estimators to redefine theirinputs in terms of the selected one system. Since many estimates may betoo elaborate for the entire job, the arbitrator may circle the disagree-ment zone and only that part of the estimate will be imported to thesettlement system.

The Cost Of Estimates

Estimating a project increases its cost because an estimate is an expense,(likewise with regard to scheduling). It is possible to under- or over-dothat investment. It turns out that for smaller projects one tends tooverspend on cost estimating, and for larger projects, the trend is theopposite. The first case is easy to argue: it is not worthwhile to pay anestimator $500 to narrow down a cost of an activity which is rangeestimated between $4000 and $4500. But a $5 million project for whichthe estimator asks for an additional $5000 in order to provide a detailedbreakdown cost report, a sudden attack of frugality may becounterproductive. Imagine the following setting: an executive commit-tee in a city charged with building a new correction facility, will turn to

(1) See Samid 1982 for a discussion on the adverse effects of amateur cost estimating

Elements 27

a professional estimator to estimate the construction cost in order to beable to assess the incoming bids. Often the committee members willcompare total cost only. If a bidder came close enough to the inde-pendently estimated figure, then it looks OK. Why worry about thenumbers in the back pages? Why commission the estimator to provideboring details? A shrewd owner will know why: the total may be in line,but it came about through low-bidding on one account, and overbiddingon the other. A detailed comparison will spot the overbid account, say itwas carpentry, and use the independentlyestimated cost figure to negotiate the pricedown. Armed with details, the owner is likelyto recover the expense of the estimateseveral times over. See insert "The cost ofestimates" (fig 1.5).

%-ratio between cost of estimatesand estimated cost

0.1%

THE NATURE OF ESTIMATESJlOM

estimated cost

Although estimates are everywhere and fig u the cast of estimatespracticed by everyone, hard- core estimatesare reserved for the costlier and longerprojects, and also for projects with high public visibility. Out of the realmof estimates at large, one may cut off the adhoc, instant, "automatic"estimates, and this leaves us with estimates prepared in order, method,and formality and with visibility and justification of assumptions anddetails.

Methodical estimates may be categorized as those that require subjectmatter expertise and those that don't. Estimating the cost of a well-defined inventory is a matter of counting and some multiplication;estimating the cost of gas along a distance-defined trip is also a matterof reading mileage and multiplication. Gradually, and without any clearborderline, the subject matter may become quite complex and the basicrequirement for an estimator turns out to be subject matter expertise.

The subject matter expertise methodical estimates may in turn bedivided into estimates for projects that are large, tangible, and heavy, andto projects that are small, intangible, and light — the rest. For bothcategories one tends to find an S-curve relationship between the ac-


accuracy ofestimates

curacy of the estimate and the effort to develop it. See insert "effort andaccuracy of estimates" (fig 1.6).

Estimating a big structure of any size or purpose is of a certain nature.For one, these are the historically older estimates, the smoother, themore mature, the more methodical, and ingeneral they are quite accurate, since theirassociated uncertainty is relatively limited.Now, one can point to the NASA shuttleand claim that this large, tangible, andheavy item experienced legendary costand time overruns. Indeed there are toomany such examples, but in proportionthey are still minor and limited. Size,visibility, and high expenditure turn theseoverruns into media prey, and theirproblems are amplified out of proportion.Overall in the construction industry, con-tractors are remarkably accurate in es-timating cost. How many softwareprograms experience horrendous dead-line slippage and cost multiplication?How many books planned for a quick 4 to6 months' effort ballooned into 10 years ofunending struggle? How may decades andbillions of dollars ago did the NationalCancer Institute estimate beating cancer?

In general, construction estimates should serve as an example andinspiration for other estimate types. The technical terms "engineering"and "industry" have a certain aura of positive buildup, progress, and —construction. In an attempt to share the ring of the terms, others haveborrowed them handily. The insurance people are now an industry,laboratory work is today genetic engineering, etc. For these terms tojustify their migration, they have to carry over the spirit of the originalterms: construction under constraints, building something with limitedtime and money, quantifying progress — objective cost estimation.

effort to produceestimates ($,time)

fig 1.6 efforts and accuracy of estimates

Below a certain limit, more effort will notimprove estimate accuracy. Same for thehigh limit In between the effort is produc-tive. Point X is a good place to concludean estimate.

Elements 29

Large, Tangible, Heavy (Construction and Manufacturing)Estimates

Construction estimates follow a general pattern that transcends thecharacter of the construction itself. In every construction class, there isone basic physical quantity that carries on its back the result of theestimate as well as many interim cost factors. The most popular by faris the venerable SF (square foot): area. Buildings and structures of allsorts are first and foremost quantified by their total floor area. Cost persquare foot is a value currency that measures residential buildings,commercial establishments, warehouses, schools, and hospitals alike.The SF value is the basic factor in conceptual cost estimates and even indefinitive estimates (calculating marginal and operational costs: floorpolish, safety patrols). Multistory buildings carry a secondary measure:number of stories. In fact, the old image of a professional estimator isone who coughs up the price per square foot of any building specified bykind, location, and year of construction. Quality of building is sum-marized by this magic dollars per square feet: one number telling adifference composed of material difference and differences incraftsmanship. The dollar difference may be more than twofold.

Then there are items that strongly resist SF representation: pipelinesare measured through running feet, as is a fence. A post is captured byits bottom diameter and total height; a storage vessel is measured byvolume; a pump by gallons per minute and head. And if all else fails,there is always the unique case. Every time, however weird, can be

(1) There are plenty of good resources for large, tangible, and heavy construction and manufacturingestimates. See Halpin 1980, Kavanagh 1978, Stevens 1985, Barrie 1978, Winklehaus 1982, Vainner1984 for major construction projects. See Westney 1985 for smaller construction projects. SeeSamid 1989 for some aspects of estimating industrial construction under uncertainty. See Engelke1989 for transportation infrastructure cost. See Wilson 1989, Techwell 1985 for manufacturingestimates. See Langley 1983 for estimating air conditioning systems. See Varela 1989, and Ashford1984 for estimating airport construction. See Brown 1985 for aerospace construction. See Massey1982 for plumbing estimates. See Popper 1970, Bauman 1964, Schweyer 1955, Nelson 1966, Caldwell1975, and RodI 1985 for industrial chemical estimates. See Barrett 1989, Spinney 1985, and Luttwak1985 for weapon systems estimates. See Nigbor 1981 for electronic industrial estimates. SeeKrishnan 1984 for industrial electrical situation. See Halvorsen 1981 for environmental instances.See Doering 1985 for revamp and upgrade estimates. See Hannon 1990, Samid 1990, Kakade 1989,Allcott 1988, and Coen 1989 for estimates of power generation.


defined as a unit of itself. The drawback is that it cannot be comparedto other "weirdos."

The total cost of a construction project is expressed as the basicquantity times its per quantity cost (= unit price) plus "other," which arefixed costs unrelated to the quantity.

It is customary to represent cost component per SF Material per squarefoot, labor, engineering per square foot; "extras" and "breaks," too, arerepresented on a SF basis.

The reason that SF is so useful is rooted in (1) the laws of mechanicsand strength of materials, (2) the prevailing codes and regulation, and(3) economy of scale. These reasons also make it very convenient for thecomputer to step in and perform a detailed estimate.

To support a given load, under a given building code, the designer findshimself quite limited in his choices. Shape is a free parameter, but thequantities of concrete and steel are pretty much locked in throughestablished, time-honored formulas. These formulas allow a computerdesign (and a subsequent estimate) to size a building quite accurately.

The most important factor in any structure or building is the support-able load. Considering the natural laws for strength of materials, thesupport needed for a given load depends on the distribution of that loadacross the floor (or the building). Different distributions will requiredifferent minimum structures. Accordingly, a computer program or adesign engineer will have to know the exact location of each load item.Moreover, since load distribution strongly affects the required structure,the cost per square foot would not have been uniform (between variousbuildings) and, hence, not useful. See insert "residential cost figures in1989" (fig 1.7).

Cost/SF is useful and does not vary as implied above because buildingcodes step in and impose a design process based on load/SF. Thisimposition is for the sake of simplicity of calculation and is justified bythe hefty safety factor used for structural calculation. Once every squarefoot of area has to be designed to support a given lbs/SF, the designfreedom is vastly curtailed, and for various shapes, locations, and style

Elements 31

800 1000 1200 1400 1600900 1100 1300 1500

unit area <SF)

fig 1.7 residential cost figures in 1989

The more units in the building, the less the $lsf value.Same for larger size living units. Figures representaverage construction cost in the U.S.

options, the eventual price per square foot converges around the samenumber.

cost's* per unit and building size

In estimating the cost of astorage tank the volume is themost important factor, and thecost is measured per cubic foot orper gallon. Now if only geometrywas the rule, then a given volumecould be constructed in endlessforms. Even if one is limited to acylindrical shape, it is possible toachieve a given volume throughtall and narrow cylinders orthrough wide and short ones.Such design freedom would havemade cost per gallon a nonstarter.Structural considerations wouldkick in for the tall building and make it that much more expensive. Alas,the same structural considerations impose an optimum for thediameter/height ratio. This optimum is normally used, and therefore thecost per gallon is indeed a good index.

Since buildings are designed for people and people come with a narrowheight distribution, it so happens that the height of a given floor in abuilding also comes with a narrow distribution. And if one considers acertain class of building, then that distribution is even narrower. Accord-ingly, specifying floor area implies volume. And so cost items that arevolume dependent are also linear with the floor area (e.g., HVAC). X Thesame is true for wall area factors (e.g., tiles).

This fantastic cost per square foot linearity in buildings created com-petitive pressures for the "soft" cost elements. To be competitive,suppliers of services like various cleaning jobs, installment of publicaddress systems, even decorations and works of art (painting, sculptures,

(1) See Langley 1983 for HVAC estimates


and plants), are reduced, measured, and committed on a per square footbasis.

Life is not this easy. The bigger challenge is not in the estimate but inthe cost control process. The SF measure is virtually helpless when itcomes to assessing whether the cost to date is in an overrun state. Thefinal cost is linear with floor area, the cost during construction has almostno relation to the total area, and low productivity, unrelated, but ac-cumulating problems, and poor management may all combine in aninvisible cash crunch. The solution in this case is to devise variousprogress indices, and live by them. A given class of building will have asimilar cost per days since kickoff, similar costs for poured concrete, andso forth. In general, such indices reflect construction practice, and acontractor can use them from one job to the next. They are not souniform across contractors.

In estimating the construction of a chemical plant, the SF is replacedwith gallons per day — the throughput of the prime products. Thereactor in which the desired reaction takes place may be the functionalheart of the entire process. The know-how of the exact quantities of rawmaterials, catalysts, temperature and pressure variations, rates of masstransfer, heat transfer, etc., took perhaps years to research. But theydon't much affect the cost of the plant itself (a notable exception is thereaction control system). The heavy cost times are the containers of thematerials (usually fluids), the pumps that move them about, and the pipesthat facilitate the movement. These cost items are determined by thethroughout, and by the nature of the materials. A gamma radioactivematerial needs to be handled in a certain way that depends on itsradiation level. The size of the various storage tanks depends on storagepolicy, which is usually a consideration of the bigger economic picture,and operational continuity. Unlike the typical building, which is passiveonce built, an industrial plant requires heavy power, the facilities ofwhich have to be built. Since most chemical reactions are heat sensitive,such plants require heavy cost in heat exchangers, heating and coolingfacilities, and the power source to get it all moving. A plant will requirehigh-pressure steam, a high-capacity electrical substation, and possiblyvarious combustion facilities. All in all, it is an order of magnitude morecomplex than the geometry- controlled building estimate.

Elements 33

This industrial complexity is handled with the same approach: lookingfor a quantity to carry, define, and measure prices by. There is no easySF measure, and the common measure is based on the prime equipmentitems: the reactors, the storage vessels, the pumps, the substation, andso forth. Most of these items can readily be associated with a cost figurethrough standard tables or, better, by calling up a vendor. Then thepurchased equipment cost becomes the "carrier." Installing it will beestimated as a percentage of the purchased cost, the required foundationas another percentage, piping, instruments, paint, insulation — all thecost accounts are expressed as a cost ratio derived from the equipmentcost.

The explanation for the success of such ratios is not as solid as it is withbuildings. Generally more expensive equipment is heavier and biggerand thus requires a larger foundations and more paint area, more insula-tion, more instrumentation, and more piping. Since the materialspecified for the main equipment item is usually the same or similar tothe pipe specification, a more expensive item will require more expen-sive pipes. See insert "industrial construction cost breakdown" (fig 1.8).

These equipment cost factors are simply the best one could practicallyidentify. They predate the computer era and were used for years forconceptual, even appropriation-level estimates. 1 Today the idea is toquantify these "dressings" of the main equipment items through directdesign estimation (destimation), and the ratios are compiled to keep theold-timers happy. Also, these factors were meaningful with regard tomore standardized, so-called heavy industry. Not too many heavy instal-lations are built any more in the United States, and the trend today istoward specialty chemicals, pharmaceutical processes. (1) The old ratiosare no longer valid, and (2) new ratios are hard to come by since the costcenter of gravity shifts from tanks and pipelines to high-tech specialtyinstruments and modular reactors.

The per equipment cost ratio help estimate the immediate environ-ment of a major equipment item. To finish them all in place, one needs

(1) See Lang 1947, Ohlrichs 1981


bare plant cost

constructionoverhead

engineering and related Iservices I

field cost

Fringe Benefits, laborburdens, consumables, smalltools, miscellaneous,insurance, equipment rental,field services, temporaryconstructions, utilities, fieldoffice & plant start-up.

Basic engineering detailengineering procurement,home office services.

Equipment Asetting.

Piping

Civil

Steel

Instrumentation

Electrical

Insulation &Paint

Labor

accounts

\

/

contingency

prime contractorfee

special charges

material cost labor cost subcontractor

Seven major trade accounts estimated for material cost, laborcost, and subcontractor cost

fig 1.8 industrial construction cost breakdown

Using the installed equipment as base the estimator wilt figure out cost of the other accounts according tomaterial, labor, and subcontractor cost Together these accounts amount to total facility cost Then engineer-ing services are added, overhead, contingency, fee, and any additional charges.

a host of overhead equipment, cranes, derricks, and forklifts. Some ofthem are owned or purchased under the project account; most, though,are rented. The rental basis is time: the time is again tied into thepurchased equipment cost for each tool, and then the costs are sum-marized.

The site where the estimated equipment is located will house anotherlayer of overhead: area-based elements that serve more than one equip-ment item and thus cannot conveniently be tied to any of them. Thesemay be steel structures, cable trays, fences, gas lines, and so forth. In theconceptual stage all these can be factored off the total cost of the variousequipment items on the site. Some are measured in linear feet, which in

Elements 35

turn is based on site area, which once again leans on the installedequipment. So, in a very loose way, such a linear factor makes sense.Installing and constructing these area items also requires an overheadaccount for forklifts, cranes, etc., another factor.1

At this point the so-called battery limits have been accounted for. Inthe surroundings of the equipment, one finds the rest of the cost itemslocated within the perimeter of the total plant area. These are theadministrative building and control room, as well as work items likelandscaping, excavation, drainage, and demolition. In many instancesthese are based on the characteristics of the site and have little to do withthe nature or the cost of the equipment. These work items, like theprevious ones, require overhead cost in the form of service equipment.When all the site cost items are accounted for, it is time to top it all offwith cost elements that reference the entire project but are rather lesstangible. These are engineering services, home office follow-up, inven-tory, licensing, accommodations, start-up cost, royalties, insurance,taxes, spare parts, consumables, and finally contingencies andcontractor's fee. Some of these cost elements depend on the accumulat-ing cost so far, and others are fixed price.

This cost structure shows the centrality of the prime equipment items.All other cost elements are computed by their reference.

A similar situation is found in estimating military installations andmilitary forces: a prime unit is selected and is made the anchor for theentire estimate. Accordingly, navies measure themselves by ship count.The U.S. Navy is in the midst of a long debate over the 600-ship navyplan. For the outsider, the emphasis on ships is not too clear: ships comewith a variety of missions, sizes, and costs — what's the point of countingships? The point is simple: there is no better unit. Like the area of abuilding and the equipment items in an industrial installation, so areships to the navy: they carry the cost computation and the cost expres-

(1) See Halpin 1980 chapter 9 for a good overview of equipment cost considerations. See Dataquest1982 for equipment rental rates.


sions "on their backs." Similarly, the air force is talking airplanes orwings. What about the army? No clear-cut unit there. In fact, there aretwo competing methods: one that measures fighting units, like divisionsor tanks. The other counts people, since the army is the most people-in-tensive force. The army estimate begins with a war-fighting model foreach world arena. In the model only engagement units are counted, andit is assumed that the support is there. Once the fighting forces arequantified, the army uses established linear factors to assess supportrequirements. Repair units, medical units, military police units, etc., arecomputed and expressed as a ratio derived from the engagement unit.

Master Plan Estimates

In some industries, the estimator is called upon to develop a 20- yearmaster plan and carve the short-range estimates from it. An estimatereaching 20 years into the future will have to find ways to fight theuncertainty fog that gets thicker as the years go by. Forecasting istrickier, and the assumption list gets longer and harder to defend. Themajor danger of a master plan estimate is the spiral of endless meetingsand committee disagreements that bog it down, sometimes hopelessly.

However, once a master plan is approved it serves as a "Bible"document for the estimator now facing the task of detailed estimates forthe near future. The framework of the master plan dictates and deter-mines the parameters that otherwise the estimator would have had toassume or research on his own.

Typical master plan situations are military planning and airport en-gineering. Major weapons take may years to develop, and most of theheavy ones must rely on many budget years to reach completion; thus themilitary must extend its view 10 years ahead and prepare detailedprograms 5 years into the future. Airports become a transportationshopping center we soon will not be able to live without. The popularityof air traffic makes access to a a major airport an overriding consideration

(1) See Hillyard 1986 for an excellent presentation of these military methodologies.

(2) See Ashford 1984 for an illustration of master plan estimates.

Elements 37

when looking for a house or business place. But airports are land hogs,and airplanes are an environmental menace and require various handlingdevices, machines, and structures. Setting up to build a new airport isonly justified if it is preceded by a master plan, which itself is based onan intensive study of demand pattern and alternative options.

The first stages of construction in a master plan type of project areheavy on infrastructure: underground excavation, access roads, etc.; theyare also more expensive activities, and soon after the start the investmentis so big that even large cost andschedule overruns don't justify scrap-ping the project. Funding may dry up,and a huge incomplete layout mayremain on the ground for years untilpicked up by a new authority. Masterplan estimates are typically veryvisible, media pets, and very delicatechallenges for the cost engineer.

fig 1.9 distance from population centers AcostEstimating Land And Habitat

The money iS Where people are. And ™e rings represent population densities^ TheJ , , $/SF value of a given lot is a Junction of the sur-

W h e r e p e o p l e CrOWd, SO dOeS m o n e y , rounding activity centers and their distance

Our species among others (ants, bees) from the lotlives in large planned concentrations.We call them cities, or urban centers. A time phased picture of a citylooks like a spreading inkstain from a felt-tip pen left open in your shirtpocket. When the spreading happens, the land around the center in-creases its value and provides ample opportunities for rags-to-riches casestories. Estimating land prices is big business but poor science. All landconsistently increases its value. The question is how much, how fast, andwhen will the temporary setback occur? The premise lures the investorsin, the answers to the questions makes many of them sorry they did.Those that apply cost engineering science to land and habitat estimatesoften use it because they have to, or otherwise prefer not to talk aboutit. Urban planners will use sophisticated models for their programs toinsure a well balanced county, only to watch their political superiorstrade opportunities as political currency. A business person may use asuccessful estimating formula and keep it a secret.


In general the various estimating approaches are based on the notionthat the cost of land reflects the extent to which that land is about tosatisfy people's need. To quantify that need one could use a classificationmethod like the following one, dubbed P-TMRW (pronounce: P-tomor-row, or People Tomorrow). Accordingly: people's needs are expressedthrough five categories marked as: P,T,M,R,W. The fundamental ele-ment is R -residence. People have to live somewhere. W stands of Work—jobs. To pay for their housing people need a job which in turn requiresa facility, a building, a fence, a gate, etc. M- stands for maintenance andit accounts for all the must-have services that crowds of people require.Such are staple shopping, schools, police, hospitals, etc. P- "play" issimilar to M, but reflects a more flexible need: recreation facilities,cultural centers, outdoor parks etc. T represents the transportationelement: the need to access the places where the other needs are beingsatisfied. In any given culture these five needs have a certain balance(different from culture to culture). When that balance is disturbed, thesystem tries to re-establish it. Thus when more people come to live inan area (increased R), M,T,P, and W will all follow suit and move up inan attempt to bring back a good balance. Those who can quantify thatmovement first, and invest accordingly will emerge as winners. It ispeople's needs which is the driving force behind the $/SF of a real-estatedeal; it is that need that is represented through urban planning, and it isthe same need which translates into political pressure on local legislatorsto approve public facilities, and budget for roads, sewers, and powersupply. See insert "distance from population centers and cost" (fig 1.9).

The role of an estimator is to find a good way to quantify the five needcategories in order to express need dynamics in a scientific way. And inparticular to study historical correlations between these need categoriesand actual cost. It is easy to count dwelling units, or follow on laborstatistics. But how do you measure transportation? There are countlessdetailed models of course, but often their complexity becomes inhibitoryand despite their validity and accuracy they turn useless. A cost engineer,unlike a basic scientist can not be satisfied with an accurate quantification

(1) The trend of a system to restore a previously attained balance is found in many unrelated systems.In electricity it is called Lenz Law, in chemistry — Le Chatelter's principle.

Elements 39

method, he or she must mind convenience of use. Level of transporta-tion services in a given area can be roughly but effectively estimatedthrough selecting randomly (or semi-randomly) two points on the areamap, and then establishing (1) the direct distance between the twopoints, and (2) the distance along the existing roads. The ratio betweenthe two reflects accessibility. The random selection can be repeatedseveral times, and the average ratio figure will then express a T-level forthe area. One can repeat the process with old maps and thereby quantifya trend. Usually the more elaborate, more accurate-in-principle modelswill not have enough historic data to execute a similar trend analysis. Inthe distant past, official clerks did not know that a future scientist willdesign a fancy model that requires all sorts of detailed data. Yet roadmaps are available throughout the county history. I dwell a bit on thisexample because of its wide implications: accuracy and usability may gohand in hand, but not necessarily.

Using a stochastic approach requires certain sophistication not neededin deterministic estimates. One must be aware of the combinatorics ofthe case, and be able to defend the result before a knowledgeablereviewer. ,

Often the path to accuracy leads to softer measurements. In thetransportation example one could improve the index by measuring traveltime rather than travel distance. Albeit, while distance along a roadmapis a solid figure — travel time is soft, and takes more effort to estimate.Similar considerations appear with regard to M and P: the number ofhospitals or shopping centers in an area is a solid figure which is not asmeaningful as, say, number of beds for the first example, and retailsquare footage for the second. A more meaningful but softer measuremay be contact/visit time: how many people-hours per month are spentin grocery stores? A 300 beds hospital which is half empty most of thetime will be gauged accurately on the soft measure, and too high on thesolid one. An urban planner using an historic ratio of hospital beds topopulation figures may reason that so many hospitals are needed in his10 years master plan, and err in overplanning if he used the solid figure.

Need driven land and habitat estimates provide for long term trends,but an estimator is often under pressure to offer a number for a threemonths trend, and not for the entire area, but for a particular lot. Short


term real-estate estimates are as scientific as stock market predictions— no one has a consistent record of success. The factors are toonumerous: Mass psychology, panic, vanity, rather than durable need,determine the fluctuations. A "brute force" pattern recognition analysismay be the best choice out of a bad selection. Factors like shape, andrelative position of a lot, can be accounted for in a rather scientific way.Some methods offer great accuracy but require a lot of work, others aresimple and do the job if the stakes are not terribly high. Again, theestimator's challenge is to come up with simple and effective indices. Ashape of an odd lot may require a pageful of surveyor's notes, but anestimator may want to measure the shape by ratio of area to circum-ference and that may be representative for his aim.

Land and habitat estimates are strongly related to construction es-timates since a structure is real-estate, and for the final economic analysisone needs both land and construction cost figures. In urban centers landprices may soar so high that an owner would opt for demolition of alow-capacity building and re-construction of a high-capacity substitute.Both the demolition and the reconstruction will take place in a denselypopulated area with limited access. Safety considerations, and inter-ference with normal life in the neighborhood, may become the criticalcost factors. Such projects will not follow historic reference of open-landconstruction and must be cost estimated with particular care.

Land and habitat estimates are volatile, crucial, and very challenging.They are also highly rewarding for their successful practitioner.

Small, Intangible, Light Estimates

"Small" is the most important attribute of these estimates. Small andlight implies less attention and thus a greater likelihood of missingsomething important and getting away with it. The large, heavy construc-tion projects are visible and in general an order of magnitude or two moreexpensive than the small, light category. A mathematician may contendthat the seriousness of an estimate inaccuracy is based on the relativedeviation from the actual figures, but money people stress the absolutegap. A 2% inaccuracy in a $100 million project will attract much moreattention than a 200% accuracy in a $1,000 estimate.

Elements 41

Intangible projects tend to be less visible and less understood, and theyoffer fertile ground for excuses, explanations, and professional fog. Thusthey can better sustain poor estimates.

Many small, light, and intangible estimates don't come with a workbreakdown structure. There are no activities, no documented list ofresources, and fewer constraints. Also they tend to be one of a kind —or are perceived that way, and thus historical reference is of no influence.One person's guess is as good as another's. How much will the partycost? The party maker may have a vague figure in mind — a figure hemay not care to confirm even on the morning after. There is no list ofresources, and no formal approval process. If the party maker does runa pencil over his checkbook and is surprised by the figure, that costrealization may not last until his next party comes around. Consistentover- or underestimates are not rare at all.

This description refers to the low end of this category of estimates. Atthe other end this category touches or overlaps the former category oftangible, heavy, and large estimates.

In recent years a certain subset of this category moved intoprominence: estimating software projects. Software today is governedby an engineering discipline, and it follows the fundamental proceduresof statement of objective, strategy, detailed design, implementation,quality control, integration, and so forth. Still, software developmentcost estimates are notoriously off the mark. See insert "software projectscost breakdown" (fig 1.10).

Putting together software is different from putting together construc-tion materials. The geometry and laws of statics enforce a rather welldefined relationship between raw materials, their quantities, the orderin which they are put together, their quality, the skills required, and thefinal product: the house, the building, the industrial plant.

In software such a relationship is very poor. The software product hasa dynamic capability of handling information. There is no clear connec-tion between any measure of program size and its information- handlingcapability. It depends on the language and on the supporting environ-ment; it depends on the programmer and on his logical solution to the


data-handling problem. Construction procedures are governed by codesand regulations. Software is measured by what the program does withthe input, not by how it does it. It would be akin to a construction realityin which the spec will say that people have to be protected from rain andwind: everything else is up to the builder.

Construction laborers are licensed, monitored by unions, and live bywork quotas known to all Programmers are not licensed, do not obligeto any union, and defy any yardstick or quota measure. People don't callthemselves pipefitters if they aren't, but anyone who learned to write aBASIC program that says "Hi!" on the screen is in principle a program-mer. Thus when one counts programmers as "heads" and divides asoftware output by their number the resulting ratio is useless.

In desperation software managers tried a host of indices. The mostcommon among them is lines of code per hour. On many occasions anout-of-the-blue figure of 4 lines per hour was used in elaborate computa-tion of software estimates. That figure typically includes the design effortas well as the final testing. Programmers, typically, first estimate thenumber of lines of code and then use such a figure and hourly dollar ratesto arrive at a cost estimate for a software project. Estimates of lines ofcode per project come with a 50 to 500% accuracy rating. It depends onthe language, it depends on the amount of documentation built into theprogram, and it depends on the programming style. See insert "softwareproject work distribution" (fig 1.11).

Several software estimating packages require the user to specify a hostof parameters he does not even begin to know, and based on his wildguesses, the program will spit out a cost figure. (See COCO MO below.)Estimators try to quantify the number of logical nodes ("if statements)in a program, the throughput for data, and its quantity. They try to assessregimentation and the number of data relationships. Some of theseparameters can be intelligently guessed at the onset; others are purespeculation. Software work, unlike construction, comes with a great dealof specific learning . This is why a low-productivity programmer who isalready "in" is in most cases a better choice than a fast programmer whowill have to spend time up front learning the intricacies of the project.(In construction a carpenter will replace his peer in no time.) Suchentrenchment makes it in the interest of everyone not to clock the exact

Elements 43

The "softcore"of the estimate.

"other direct" cost: material,subcontractors, consultants,travel

plant overhead: cost ofmaintaining the work forcein their work environmentincluding any rent, utilities,and security services.

Direct labor: each laborcategory is added up(hourly rates timesscheduled work hours)

/

Escalation cost

General &Administration

prime contractor fee

fig 1.10 software project cost breakdown

Software projects estimates are based on hours of efforts per type of professional Everything else except"other" direct cost is computed off direct labor. Plant overhead may be 60% to 110% of direct labor depend-ing on how luxurious the office. Non-labor related costs are relatively firm. Escalation is only applied if theproject is scheduled to last more than 12 months. G&A includes work categories that are not allocated to aparticular project It may range atlO%-25% of all cost components except the fee which may be as low as1.5%

time per task, much less to compare the figures of actual cost estimates.The gaps may be so staggering that programmer and manager alike areembarrassed by them. In reality, most long-range software projectsundergo change in their requirements. These changes are used as a figleaf by the development team to justify cost and schedule overruns. Tostay within an estimate a programmer will wrap up unfinished code,


declare it complete, and count on the subsequent integration phase tohandle the already known bugs. Unlike inspection of a construction site,it is not easy for a supervisor to see through these postponements. Themain line logic is only a small part of the total programming effort. Thespecial cases, the handling of errors and wrong data consume the timeand the effort to complete a program, and so it is easy to hide incom-pleteness. X

Once the modules are integrated a bug is harder to isolate, and it iseasy to blame the net software module.This postponement phenomenon is onereason it often takes 10% of the time tobring a project to 90% completion, and ittakes 90% of the time to struggle throughthe last 10% of the effort.

work hours

The volatility of the software industrymeans that companies come and go,programmers move from one firm toanother, making it difficult for a companyto build its own software performancerecord, which will serve it in its own costestimates. Also, most of the commerciallyprogrammed code today is run as time andmaterials, or cost plus contract, and so theincentive for more accurate estimates isnot there.

20 36

1989 hourly rates (unburdened $)

fig 1.11 software project work distribution

Software work is performed by well paidprofessionals. They need relatively littlesupport of simpler work categories, and lit-tle project-allocated management. 100work hours represents maximum allo-cated per work category, (when onlyprogrammer/analysts are assigned to thejob. )

In analogy to the fast-tracking option in construction, the softwareindustry in recent years climbed down from the high tree of a stricttop-down design approach and embraced the notion of prototyping. Ayoung estimating approach is now making its way in using theseprototypes for the purpose of estimates much like pilot plants are usedby the chemical industry: scaling up a prototype to the full-fledged

(1) See Cheadle 1987 for a parametric approach.

(2) See Cerveny 1987, and Klingler 1986 for discussion on prototyping.

Elements 45

system is one way to wrestle with the apparent impossibility of softwareestimates.

For most software shops the first step, logging, is yet to be perfected.Cost estimates don't derive from abstract natural laws, they are alwaysbased on history. Before one attempts to project history into the future,it is necessary to clinch the unfolding events: logging the details of whodid what, when.

COCOMO etalSoftware development managers could not match project managers fromother disciplines and had to face cost overrun and schedule delay timeand again, until it became a bitter joke. Even the most prestigioussoftware developers could not afford a fixed price contract, and indeedthe federal government, the world largest software buyer, is currentlybuying software on a time and material basis. In the 1970s, the marketwas flooded with promising software and methodologies aimed at auto-mating cost engineering of software. The most popular among them isCOCOMO: Constructive COst MOdel.l COCOMO basic philosophyis to relate lines of code to level of effort. The relationship looks like:

LOE = A*LOCB

where LOE is Level-Of-Effort expressed as work hours or duration;LOC is Lines-Of-Code of the estimated product, and A, and B are twocoefficients which came from — you guessed it... COCOMO assumesthat the project enjoys good management. That is, if the actual projectexceeds the formula generated figure, then management, by definition,was not good enough. COCOMO further assumes that the requirementsof the product remain unchanged throughout the development phase. Ifthe project is of any length or complexity, (and desperately needs a goodestimate), the latter assumption becomes unrealistic. But finally, unlikea construction estimate where the number of stories in the building isknown, in a software project the number of lines of code is not a priori

(1) See Boehm 1981 for a detailed discussion of COCOMO. Other options are: RCA Price S model,Freiman 1979, IBM-FSD Model Walston 1977, the GRC model Carriere 1979 and SLIM Putnam1980.


known, and the effort to estimate them is the hard part of the entireprocess.

In summary, a multi-billion dollar industry is cranking along withoutany serious reliable means to estimate its own activities. The bulk of thesoftware industry is comprised of small enough projects and estimatesare ignored or avoided in the first place. Others once they start, imposesuch a penalty for termination that they continue regardless of costoverruns and schedule delays.

It is likely to be awhile before the small, intangible, and light estimatesapproach the level of the heavy, tangible, and large estimated projects,but the latter should serve as a role model for the former.

SCHEDULING

Scheduling seems to many a stepchild in the cost engineering family.Accounting for time, after all, is not the same as accounting for cost. Butsince we don't have a discipline called time estimators, scheduling, as anorphan of sorts, was adopted by cost estimators and cost controllers. Ibelieve this is a mistaken approach. Scheduling should be viewed a priorias a bona fide part of cost engineering activities. This view will impacton the way computers are used in a cost engineering shop, for three basicreasons: (1) time dependence of cost estimates, (2) time dependence ofcost control, and (3) time dependence of the quality of cost engineeringwork.

(1) See Conway 1967 and Hu 1982 for a mathematical review of the complexity of scheduling. SeeCheadle 1987 for an illustration of scheduling a software project. See Popper 1970, for variousdiscussions on chemical plant construction scheduling. See Toth 1985 for a practical guideline forusing CPM. See Zimmerman 1983, for a do-it-yourself programming option. See Kibler 1985,Stewart 1987, Halpin 1980, Piper 1982, Baker 1974, Rosenau 1984, Hamburger 1989, andHumphreys 1987 for an introduction and general discussions. See Pace 1985, Chambers 1990,Popisil 1990, Spencer 1989, and Ahuja 1985 for computer aspects. See Dodge 1989 for schedulingdata. See Ponce 1985, McCullough 1989 for legal, damage and dispute aspects of project scheduling.

Elements 47

SCHEDULING WITHIN THE COST ENGINEERINGFAMILY

A scheduler works much like a cost estimator and a cost controller. Thecurrency in one case is money, in the other time. Time is said to bemoney, only more so. (It never rolls back.) As discussed later, a timeplanner works his way from conceptual schedules to appropriation plansand eventually performs time control side by side with the cost controller(and it is hoped, with good communication between them). Both func-tions support and feed data to the project manager. Apart from form,time management is indeed an integral part of the cost engineeringfamily because of its effect on estimates, project cost management, andcost engineering quality.

The process of deciding which project activity starts when and for howlong is most challenging. Cost is a figure decided elsewhere, and the costengineer observes it. It is always a good idea to take the lower cost (fora given result). Activity duration, on the other hand, comes with a given"minimum", which is not always the optimum. At times, it is a good ideato prolong a certain activity, to split it into two (or more), or to shift it onthe calendar line, up or down. For a project comprising thousands ofactivities, such decision freedom is horrendous.

Prior to the computer era, scheduling was largely restricted to itsprocedural level: satisfying precedence conditions among activities. Bydrawing a Gannt chart, or a CPM, most projects could be mapped in timewithout help from automation. In theory the number of precedenceconditions can be quite high, and the resultant complexity may createunresolved loops. In practice the activities tend to line up in a nicesequence, and satisfying the precedence conditions is straightforward.

Even if the schedule resulting from such precedence satisfaction hasno float — that is, all activities are on the critical path, and any changewill prolong the project — it is still not necessarily the best schedule.First, the schedule in total could be moved on the time line, and by sodoing the project hovers over a different set of holidays, weekends, andpotential weather and funding aberrations. In addition, it may turn outthat it is beneficial to stretch a few activities, pause, or impose a sequenceinstead of a possible parallel action. Such distortion may lead to an


optimum project policy if it caters to other constraints. These "other"constraints are generally not as tidy as a simple precedence requirement.The most common constraints are the ceiling type: there can be onlythree cranes at a given time on the site, there are only four carpentrycrews, etc. Certain ceiling constraints are set in concrete; others arewritten on sand. The consequences of violating one constraint may betrivial, in other cases crucial. There is not necessarily a clear distinction;it may be a matter of judgment. Some constraints come from safety codesor from contractual stipulations, and some emanate from common senseand construction or project practice. It is always a problem to identifyall the constraints, and even if they are all clearly listed, there is not likelyto be a neat mathematical solution for an optimum schedule. Fortunatelycomputers can solve problems that elude pure and analytic mathematics(and thereby make themselves indispensable). Cost engineers in generalare just beginning to realize the power that computers lend to schedulemanagement. Computers turn time into a problem solver.

Time Dependence Of Estimates

Escalation and inflation are the two factors that come to mind when thetime dependence of estimates is mentioned. In today's internationalclimate one must add exchange rates. These factors come into play forprojects planned into the far future and/or for a long duration. Theyinvariably add uncertainty and are handled as a correction to estimatesthat were computed with today's prices.

An acute time dependence of estimates is evident in the definitive orclose to definitive stage of an estimate. Cost elements in a fiercelycompetitive environment tend to come with some strong time- depend-ent step functions. A firm quote for a pump will specify a date after whichthe price soars 20%; labor rates come with an across-the- board pay hikeat a given date; a subcontractor's agreement stipulates bonuses for earlyfinish and pay cuts for delays. All these are cost "step functions": theydictate a sharp change at a given point in time. And it these factors thatmake a schedule very pertinent for the definitive cost statement.

Time-dependent cost step functions have been part of competitiveconstruction for years, but without computer technology it was imprac-

Elements 49

tical to incorporate them into an estimate. Today we have the tool, andit is time to reemphasize what step functions can do to estimate accuracy.

Time Dependence Of Cost Control Activity

The important difference between a cost control engineer and an ac-countant is the "when" they do their similar jobs. The cost controllertries to anticipate a funding crunch; an accountant performs autopsieson the same crunch.

In construction practice, many disasters were brought about when aproject was "overall" healthy and had only "temporary" cash problems.When the global funding and cost situation is satisfactory, the projectmanager tends to pay less attention to how expenditures happen overtime. This may create financial holes: more money flows sooner, andless funding comes in or it comes in later. When an activity is prolonged,some of its associated cost grows proportionally. Unfortunately, not allcost items are productivity linked. If you rent a back hoe and it sits idle,the expenditure balloons. Salaried individuals waiting for a storm to passmay "break the bank." In short, a cost controller who does not payattention to the dynamics of the schedule is not doing his job responsibly.In fact, to let a time planner make his or her changes without priorconsultation with the cost controller may be a bankruptcy-level mistake.See insert "time vs. progress cash flow dependencies" (fig 1.12).

Time Dependence Of Cost-Engineering Quality

The premise is painfully simple, even primitive. Projects tend to wastetime up front and, later, race madly against a deadline. Cost engineeringactivity follows this pattern. These two facts of life create a typical bindin which the cost engineer runs out of time. Cost Engineers cannot carryout their functions, explore alternatives, or check into solutionsproposed to daily problems — they just rush to do a bare minimum.

Integrating cost engineers' time into the overall resource and timeallocation will give the professionals better control over the time neededto perform a quality job. My early experience as a consultant wasoverwhelmed by tired, disheartened estimators who said: "You havegood ideas, we have some too, but we never have the time to execute


them. So, even if your ideas are better than ours, it'll make nodifference; there is simply no time."

OVERHEAD SCHEDULING

Project specific resources are routinely committed to project activities.This also applies to crew members and skilled laborers. Although somevery important resources float over and above such specific tie-ins, thisdoes not mean that they are above schedule.

The home office staff, top executives, and safety inspectors are all busy,expensive, important resources that don't tie into one activity or anotherin any project.

Some transportation vehicles, conference rooms, and test laboratoriesare a similar material type of overhead.

The cost component of these floaters is readily accounted for in costaccounting: it is burden, general and administrative charges, and thenotorious "other." But to maximize their utility, these resources mustalso be time specific. No matter how unassigned a top executive may be,his day does not exceed 24 hours, and his week has only 7 days. Whenhe is somewhere, he is not elsewhere. When he reads the XYZ reportis does not read the ABC statement.

The conference room and the laboratory can be scheduled and as-signed. The executive types run their own schedules and resolve theirown conflicts. In some organizations in which the calendar problem wastracked down, the numbers were surprising. One air force generalemployed two captains full-time on no other task but the personalcalendar of himself and his aide. When an executive tries to arrange fora staff meeting, he is likely to run against calendar conflicts with many ofhis people. If he overrides them unilaterally he may cause an avalancheof consequences that will haunt him for days to come.

Single calendar systems are quite common in the computermarketplace. Surprisingly, at the time of this writing, there are no knowncommercial offerings for a multicalendar system. This is a classic ex-ample for in-house endeavor. Readily applicable to the local area

Elements 51

network environment, a multicalendar system will be aware of the timecommitments of the overhead resources (people and equipment) andrespond to scheduling requests by assigning the earliest convenient timeinterval. An executive trying to schedule a meeting with all his depart-ment managers will define the duration of the meeting and the requiredmeeting room. The calendar system will consult the individual commit-ment of these managers and come up with a suggested meeting time.Once approved, the time commitment will be noted on the individualcomputerized calendars of the managers.

The various managers and other resources can be assigned priority

indices to help break a conflict if the schedules are too crowded.

The main activity of a multicalendar arrangement is to avoid conflicts.

But on top of this, the system may fine-tune the time utilization of its

expensive resources. To do that it will need a host of soft rules that

express personal preference (e.g., "Don't schedule budget meetings on

Friday afternoon") and productivity boosters (e.g., "Schedule all the

meetings in the particular site in one day, to spare executive travel").

It gets quite complicated from a mathematical standpoint, and bruteforce computer power is not necessarily the answer. One of the age-oldunsolved math problems (the traveling salesman) is a seemingly trivialpersonal schedule question.

Personal time management is one of those items many of us decidedto look into it ASAP but never had the time to do.

COST CONTROL

Between cost estimating and project accounting there is a critical area

of tracking and control. Cost control is confused with cost reporting and


with the two neighboring disciplines. This confusion may cost onedearly. Computers may help, but only if the challenge is well under-stood.1

The objective of cost control is to avoid a cash crunch. The difficultyemanates from (1) the disorder factor, (2) estimate or budget inac-

Planned Cash Flow Actual Cash Flow

projectincome

projectexpenses

| A

IB

time

projectincome

projectexpenses

fig 1.12 time vs. progress cash flow dependencies

Project income is often driven by project progress. Expenses, on the other hand, may be calendar driven. Inthe original plan progress is expected at given calendar points, and the resultant cashflow remains positivethroughout the life of the project (As depicted in the left chart) When poor management or uncontrolledreasons slow down the pace of the project, the same series of payments will kill the project due to "temporaryinsolvency" which turns to be not temporary at all Slow progress delays income payments A and B while ex-penses remain in the planned rate.

(1) For a literature perspective of the cost control subject you may review the following sample: Bullis1987, Feay 1987, Tipton 1985, Vainner 1984, and Suhanic 1985. For construction accounts see-Williams 1982, Wade 1982, Querns 1981, and Halpin 1980. Wilson 1989 discusses cost control inmanufacturing, Clive 1986 offers an owner view, Thrush 1987 discusses control in designengineering. Drigani 1988, Cole 1989 are two examples for computer aspects. Krishman 1984portrays control in the electrical industries, and Cascio 1981 documents control aspects of off shorestructures.

Elements 53

curacies, (3) schedule inaccuracies, and (4) transaction linkage. Theseare distinct and independent factors and they are addressed as such.

The way to overcome these difficulties depends on the size and thenature of the project. These aspects may be categorized based on (1)remedy options, (2) the sameness or newness factor, and (3) fundingsource.

Remedy Options

If there is nothing one can do about cost overruns and time delays, onemight as well ask; why bother with cost or time control? In reality, justas there is always something that can be done, so there is always a caseof cost control. Conversely, the more corrective options at hand, thegreater the incentive for cost control. The options are numerous at anearly project stage, and this is the most important phase for cost control.

Remedies may range from option to cancel through request for morefunding or an option to renegotiate. All these are options for thecontractor to hand the ball back to the owner. In fixed-price, bindingcontracts, the incentive for cost control is to find the hidden causes forthe cost overruns and correct them.

The nature of the potential remedy also determines the time factor ofthe control action. For long, slow projects, monthly reports may besufficient; for fast-paced intensive jobs, a weekly, even daily report maybe required. This feedback dynamics has a dramatic effect on whichcomputer environment to choose.

In projects with heavy expenses on equipment rentals, accumulativetime delays may offer a simple remedy: buy the equipment. It is not tooinfrequent that rental fees far exceed outright purchasing price.

Very frequently cost overruns are a matter of incompetence on thepart of one or a few individuals, or a subcontractor. At other times it ispoor leadership overall, a low morale, an overly risky environment, arecent accident, and like problems. In these cases it is a matter of soft,human, corrective steps.


Sameness And Newness

If the current job is new in many ways, the validity of the original estimateis generally low. Any historical reference may be irrelevant, and it islikely that a big contingency block (of cost and time) was attached to theplan. Ample contingency tends toinduce apathy, although a runawayproject is capable of eating up anycontingency. Unfortunately, thetools available in the "sameness"mode are not available here. Themajor means of control is com-parison of actual costs to estimatesand a detailed search for a culprit.

project total

first levelaccount breakdown

V2-V1=I-E

V1,V2—account value at time points 1,2.I-income, E-expense (relative to 1 & 2).

fig 1.13 the accounting tree

In cost control one tries to break down theproject into control-oriented parts. Each part willsatisfy the above equation for any two points intime regardless of its nature. The equation willhold for tangible and intangible accounts as longas they are well defined This helps in tracking ex-pense-over-progress .

If the current project is similar to agiven relevant history, then on top ofthe estimate versus actual com-parison, the control action mayresort to a host of indices that com-pare similar projects as they were inthe same state of progress. Theseindices, in combination, become anindicator for the comparative coststatus and, more importantly per-haps, become a tool with which toproject the magic figure "cost to complete."

Source Of Funding

Often the owner of a project is very sensitive to completion date. If thecommissioned job is for a luxury office building, then early occupancymay translate into substantial income, which in turn will make the owner"soft" on handling cost control problems — approving change orders,waiving special construction elements —anything that may help to con-

Elements 55

trol the completion date. A contractor in this case will need not only tospot a cost control problem but also to explore, test, and evaluateremedies acceptable to the owner. The computerized tools appropriatefor the case are simulators, "what if," and "if what" programs. (Seechapter 2).1

The same softness is also exhibited in phased construction (fasttracking) in which the engineering specification is running only onephase ahead of actual construction to allow the builder to feedback fieldresponse to the designer-architect and suggest improvement or com-ment on the construction worthiness of a section. This modern, less rigidapproach enhanced the practice of value engineering in which costcontrol is a major player.

Unfortunately, larger projects are almost always commissioned by thefederal government and the government is required by law to bid com-petitively in the old-fashioned rigid way.

The General Contractor

A general contractor in a competitive environment will usually developa reputation in a particular type of construction and rigorously accumu-late his own performance history. Once the contract is awarded, somecontractors will totally disregard the estimate that got them the contractin the first place. They will prepare a detailed budget and compare it tothe running cost. Several independent methods will be used to track coststatus. One is the detailed actual costs and their relationship to thebudget plan; the other includes such indices as cost per square foot orcost per cubic yard or labor allocation per any unit of constructionprogress. The values of these indices are then compared to the values ofthe same indices in a similar recent project.

Cost control may not be limited to home office number crunching: themonthly meetings between all parties, all subcontractors, are a definitecost control tool. Reading and responding to the various problem

(1) See Yates 1990 and Collier 1984 for innovative construction financing techniques. See Samid (2)1984 for the supplier point of view.


reports from the field is another cost control tool. All these are basicimplements of good management, and those who don't do cost controlwithout a dandy computer system, won't do it with one.

You Are Not An Accountant

Performing a cost control function is not only not synonymous to beingan accountant, it is also an effort in which one often needs to resistaccountants in their classification impositions. Driven by their job re-quirements, accountants will want to classify transactions in strange andodd ways. Some of those classifications, if adopted by the cost controlengineer, will in fact mask the very issues which cost control is supposedto detect and correct. If productivity runs low, but some labor expensesare newly classified as overhead then the cost control engineer may notnotice his problem when comparing the current project to historicexpense-over-progress figures. When the tax authority changes its costreporting regulations, accountants will comply, but a cost control en-gineer should think twice. Their angle is different — continuity with thepast is of paramount importance. Historic comparisons produce theindicators of trouble, and must be kept unmasked and unambiguous.This is a legal and welcome case of double bookkeeping. In fact, the onlypiece of accounting which the cost engineer must adhere to at all timesis the simple rule that for every account, for every two points in time, thedifference in the value of the account must equal the difference betweenincome money and expenses. Armed with this "dollar-conservation" law,a cost control engineer will be able to define his own accounting tree.(See insert: "The accounting tree" (fig 1.13). ) The more risk in theproject, the smaller the elementary accounts should be. And for eachaccount one may want to graph cash flow past and present, and comparethe latter to the planned picture. Thus for a routine construction, it maybe sufficient to track the entire building as an account, but for a new andunique structure, the cost control engineer may want to define each flooras an account, or each trade, or even each trade in each floor. Theaccountant may be totally indifferent to these fine calibrations, but thatshould not deter the cost engineer. His or her consideration is theeffort/benefit balance: is the project unique and "crazy" enough towarrant the energy of maintaining detailed accounts?

Elements 57

TIMELINESS

Time is what makes cost control necessary. The cost estimator talksbefore the action, the accountant passes judgment after it's all over, andthe cost control engineer is the man of the present. He or she may beregarded as a front-end accountant, or a rear-end estimator. The costcontroller has to identify the estimate's inaccuracies, before the account-ant. The accountant can explain why a debacle happened; the costcontroller will warn that it approaches, and if he does it early enough toextend a remedy, then he does his job. Time, as much as money, istherefore what cost control is all about. One should remember this whena computer system is about to be selected.

When a project is well funded, cost control seems less crucial. Al-though this makes some sense, there is an inherent risk in underestimat-ing the cost-over-time factor. Funds are promised and contracted in aconditional way. These conditions may be time dependent or progressdependent. Expenditures, too, are conditioned both ways. If progressdeviates from its expected time frame, all sorts of cash inadequacies maydevelop. Some of them maybe easily overlooked but start a ripple effectleading to default.

The inherent reason for this inordinate sensitivity of the constructionindustry is in the unforgiving nature of some expenditures. Obligationsto subcontractors that bring laborers to the project may have littleflexibility. If the check is not cashed on a Tuesday, the sub cannot payhis people on Friday, and next Monday no one shows up. Large andestablished equipment suppliers may absorb a short delay, especially ifthe project on the whole is on solid ground, but daily laborers and smallsuppliers will pull the plug upon the first payment delay. In case of aserious no-show or shipment cancellation, a snowball effect may comeinto play and then, despite the on-paper health, the entire project comesto a screeching halt. This is one reason that lending institutions, insiston checking the reputation of the construction management firm.

All this adds to the responsibility of the cost control person. In oneview the sole goal of the estimator, following a successful project ap-


proval, is to make the job of the cost controller easier. The more accurateand representative the estimate, the fewer obstacles in front of the costcontroller.

DISORDER

A construction project is a big opportunity for disorder. There are toomany details and too many people, and too much is done in parallel fororder to happen without a considerable effort. At any given moment,managers across the construction spectrum will commit the project,order parts, material, equipment, and labor, and sign numerous compli-cated contracts to these effects. It is not easy to track down thesecommitments and then compare them to the countercommitments forresources.

To get a handle on this complexity it is necessary to issue and enforcevery clear, yet livable procedures: who is authorized to commit thecompany, who must be informed of what, and what should be reportedupward, laterally, and down the hierarchy. These procedures tend to beelaborate, and if they are too lax then no computer will be able to help.On the other hand, if they are too tight managers cannot live with themand ignore their directives, which again turns any tracking computer intoa useless instrument. Only if a cost control methodology is clear, com-prehensive, and realistic is there a chance for automation to be useful.

The computation factor in cost control is very trivial. The complexityis in the data: to enter it in time, to enter it in the right classification, andthen to summarize it all. Last but not least, it is always a challenge tomerge actual costs with estimates and project the difference over thetime line in order to spot "red zones."

MONITORS

Levied with the responsibility for a project, one is naturally preoccupiedwith the question of control. How to make sure that things don't go outof hand. Some take extra care with details, others serve their concern

Elements 59

with workholism, and some opt to be obnoxious with their subordinates.Often to no avail because of deficiencies in their situation monitors.Control is usually thought of as remedy or correction. But before anycorrection can be applied it is necessary to read the situation andunderstand the nature of the gap between the 'actual' and the 'planned'.A false or weak monitor can not be compensated with overzealouscorrection efforts. In fact, the quality of the monitors determines theupper limit of the quality of the control mechanism. When control is notup to par, the first place to look into, should be the monitor (people andtools). Do you really get a good picture of where you are versus whereyou planned to be? is the picture timely?

ESTIMATE INACCURACIES

Cost control is given the task of spotting and then handling any gapbetween the latest estimate and reality. The cost control engineer doesnot care whether such inaccuracy is the fault of the estimator or a forcemajeure. Such a distinction is someone else's responsibility. The con-troller's focus should be the gap itself and its effect on the cash register.The job requires (1) spotting the gap as early as possible, (2) projectingthe impact of the gap accurately, and (3) proposing corrective action, ifany. The decision about what action to take is the responsibility of theproject manager.

In reality many nontechnical factors tend to inhibit the cost controllerin his job. The gaps that cost control identifies are likely to be someone'sfault or oversight, and thus the cost controller has to withstand a greatdeal of pressure if he is to be faithful to the data and its conclusions.These political difficulties should be mentioned because it is not unheardof that a computer is made the scapegoat in such an attempt to preventproject clarity from coming through.

Spotting Estimate Gaps

The easy part is to compare estimates with actual costs. Paid costs arethe easiest to spot. A little bit more tricky is the committed "actual"costs, which do not yet appear as expenditures but their cost is fixedsomewhere in the depths of a complicated contract. When the commit-


ment was made verbally and recorded in meeting minutes, the challengeto find it early enough is even greater.

When a cost gap is identified, the immediate question should be: doesthis trigger more gaps that are not yet known? This is the type of questionthat requires engineering insight and is reason that cost control is anengineer's job rather than the work of an accountant.

If the estimate is simply lower on a unit price that is one thing. If thegap was due to an underestimated quantity, then one should look intowhat other cost items are dependent on that quantity and how they aregoing to be affected. If this is done right then the cash flow projectionwill be much more accurate much sooner. This is not easy, and there isdefinitely room for computer help. Proper modeling and constructionsimulation will be able to store the needed dependencies.

Even if clear-cut dependencies are not present, it is important to lookfor patterns. If labor rates and labor hours are consistently understated,a prudent cost control engineer might assume that the trend will coverthe rest of the project.

In inflationary times, suppliers will refrain from fixed price quotes andwill rather tie them to a general index. Naturally this complicates life fora cost engineer and again makes computers indispensable.

In summary, the well being of a project often depends on how good anengineer the cost control person is. This is definitely not a job for anapprentice or for a half-professional.

SCHEDULE INACCURACIES

Schedules more than estimates tend to make a cost control engineerquite miserable. Not only is it more difficult to project duration, butdelays of critical activities ripple and magnify themselves through theentire sequence of the project. And since many expenditures are directlyor indirectly time dependent, the cost implications may be of disastermagnitude. It is therefore that the cost control engineer has to keep analert eye on any apparent trivial disparity of schedule.

Elements 61

To fully extract the cost impact of a time delay requires a great deal ofdetailed work. Before the modern computer era, such implicationscould be talked about, guessed around, and appreciated in principle butthere was no way to quantify them. And this is where automation has itspotential impact in a very deep and fundamental way.

TRANSACTION LINKAGE

For a project to reach its finish line, all parties have to remain solventfrom beginning to end and through each phase: not only the lender, notjust the owner, not the contractor independently, but all of themtogether. This condition is not always simple and at times is hard toassess before it is too late. The fundamental reason for such difficulty isthe complexity that governs when and how money is to change hands.There are three major categories: time-linked payments, milestone-linked payments, and contingency-linked payments. But the link be-tween time and milestones is not without its uncertainties, andconsequently the financial health of any party at any given time is notnecessarily guaranteed. Contingency-linked payments are by definitionan unknown. Some of them hinge on general economic conditions (e.g.,inflation), and others are individual surprises (e.g., insurance payments).

The global financial picture is outside the scope of the cost controlperson, but his part is crucial. The cost control engineer must be awareof developing contingency costs and of the exact linkage of each cost itemto calendar time, project day time, or perhaps a milestone linkage. Thisknowledge is a prerequisite for effective projection of the future costpicture. In general it is required that conditions that are spelled out in"lawyerese" will be translated into "computerese" and integrated intothe total cost model.

THE RHYTHM

Cost estimation, scheduling and cost control, are the functional elementsof cost engineering. The heart and soul of this craft, is in the balance,


the interplay, and the communication between these three. The follow-ing topics will highlight the music of cost engineering.

PROJECT MANAGEMENT

Project management under various accounts is part of cost engineering.Strictly speaking, though, the project manager is organizationally supe-rior to the cost engineer. He assigns the costing assignments and reviewsthe results. The main distinction between a cost engineer and projectmanager is in the all-important notion of decisions. When the costfigures come back and the schedule is prepared, chances are that thereis not enough time and/or not enough money, and the project managerhas to inspire certain cuts. Before such a painful decision is made, theproject manager will often explore options. It is the cost engineer whofacilitates this exploration. As indicated before, the job of the costengineer is to make as many cost statements and schedules as possible,with maximum accuracy and great detail and documentation. The morehe or she does so, the more informed the decision, and the easier, andthe more objective is the job of the project manager. The technology ofthe computer offers the cost engineer the practical possibility of explor-ing very many design and construction options.

In its ultimate state, the decision making process of the projectmanager will be reduced to a computer algorithm. Since such a state isin the far future, no project manager needs to worry. Even if it doeshappen, it will only bite into the option selection process. The respon-sibility of a project manager stretches far beyond this. He or she first andforemost provides leadership. Leadership is the nonquantifiable part ofproject management, and no computer will compete for the job.

The slower the cost engineer, the less options he can explore, and themore judgment the project manager needs. When the cost numbers and

(1) Project Management attracted many writers. A small sample of this rich body of literature is:Vainner 1984, Sherman 1984, Woodworth 1989, Samid 1989, Daskal 1989, Hillyard 1986, Brown1984, Blanchard 1978, Sweet 1986, Willis 1989, Halpin 1980, Douglas 1989, Ludwig 1974, Rosenau1984, Cavendish 1982, Cable 1982, Cleland 1983, Drigani 1989 Parkinson 1957, and Drucker 1986,1980,1974.

Elements 63

schedule figures talk clearly the decision is obvious. When they don't,as is often the case, then it is one's years of experience, intuition, andlogic that lead to the decision. There is a chronic shortage of qualifiedproject managers, and therefore computer-organized cost engineeringwill have a great impact on the project manager's function.

Even if there were enough experienced project managers, the lessonsthey learned from past projects are highly applicable to similar projects,but when new things are designed, different construction methodsemployed, or pioneering materials used the historical experience be-comes less relevant, and often even misleading. Therefore, in a dynamicand changing construction environment, it is important to reduce theintuitive element of the decision process and fill the gap with good,defensible numbers. In summary, today's construction industry, com-petitive and dynamic as it is, relies on the cost engineer to work fast andmore accurately on more options and with clearer documentation thaneven before.

Old Ideas Versus Modern SophisticationMuch as some believe that any problem can be solved by throwing moneyat it, so there are those who maintain that any difficulty can be crushedby a high-tech bulldozer. Too many times, a project suffers from simplelogical disconnects but its captain steers it towards a fancier computer,a bigger database, a more lucrative consultant. High tech has its role,sophistication is crucial, but neither can compensate for lack of logicalconsistency. The notions are as old as thinking, but in need of reiteration:first determine the issue, then describe your goal with regard to thatissue, and toward that goal define your actions. Then revisit the issue— was it solved? Or alleviated? Maybe it was aggravated? Do the samefor the goal — what was accomplished? What are the lessons to belearned? The actions: have they been committed, as planned?

The simple cycle of forward stipulation and hindsight accounting is nonew idea, but not a stale idea either. Add to this cycle the concept ofhierarchy — each issue is broken down to sub-issues, each goal issubdivided to sub-goals, and each action is comprised of smaller actions


Forward Looking Forms: Hindsight Forms:

ISSUE forms

f Higher Level *" " '\ Issue

I If aggravatedI will lead to:I (list items)

Considerations& Assumptions

wilt lead to:(list items)

[Higher Level\ Issue

HindsightAnalysis

GOAL forms

I ProjectedObstacles:

I (list items)

I Higher Level\Goal

HindsightAnalysis

[ActualI Obstacles:I (list items)

I Higher LevelI Action

ACTION forms

Considerations]&Assumptions\

I ProjectedI deficiencies:I (list items)

I Higher LevelI Action

HindsightAnalysis

[Actualdeficiencies:

{(list items)

fig 1.14 T*VIEW(PM) Six Forms Summary

Elements 65

Higher Level

Prepared by:_

For:

Revision (date): _

Former Revision:

Additional Writing (No/Yes,where?)

T*VIEW(tm) ProjectManagement MethodologyGeneric Form(c) DAG Science! generic form 1GAGM2

fig US T*VIEW(PM) generic form


— and there you have it, a procedure which is simple enough to learn ina few minutes, and robust enough to last you a lifetime. The enclosedtwo pages (inserts "T*VIEW(PM) Six forms summary" and"T*VIEW(PM) generic form," fig1.14, 15) offer their peruser all that heor she needs to start practicing rightaway. R (result)

S (0,0) w C (cost)

fig 1.16 The Result-Cost Analysis Plane

Region (1) represents the "too good to be true"zone—g^eat results with little investmentRegion (2) represents high level of results and

THE R-C (RESULT-COST)ANALYSIS PLANE

The following graphic construct issimple enough to implement "byhand," but its full potential is realizedwhen combined with an automatedproject management system. TheClarity Of t h e g r a p h i c s h e l p s SOrt OUt cost Region (3) represents high cost and poor

J . results (the unfortunate case). Region (4) rep-VariOUS OptlOnS a l o n g t h e COSt ( r e s u l t ) resents the small case: little input, little output.

scale, brings up a sharp comparisonbetween competitive options, and depicts the value of a value engineer-ing analysis. The input/output dichotomy on which it is based is valid inprinciple for any transaction, deal, or contract.

A well-engineered project is one for which the result corresponds tothe cost: the return merits the investment; the output justifies the input.The range of possibilities between cost and results may be depicted onan R-C plane. See insert "The Result-Cost Analysis Plane" (fig 1.16).

Every project begins at the origin, point s\ no money spent, no resultachieved. It ends at a certain point e\ the result is at level b (theprojection of e on the result axis), and the cost is at level w (the projectionof e on the cost axis). The ratio b/w is the result to cost ratio.

Point b also represents the "ideal," free lunch case: getting resultswithout paying for them. Point w represents a total failure, payingwithout any return.

Elements 67

In a capitalistic environment it is generally possible to represent theresult or return of a project in terms of direct or indirect earning, andthus both cost and result can be expressed in dollars. However, this isnot a necessary requirement. The result of a project can be measuredthrough any desired units. It is nice if the value of the result is objectiveand easily measured, but even that is not an absolute requirement.

Every project end state e may be viewed as the intersection of two lines:

• The quantity line

• The quality line

The quantity line runs from the lower-left zone (compared to point e)to the upper right zone. It represents the normal options of pay more,get more, pay less, receive less. See insert "quantity and quality lines"(fig 1.17)..

Point n on the quantity line represents a project that costs less andbrings less in return, (compared to point e) such as a lower qualitybuilding. Point m represents the opposite: a more expensive project anda more luxurious outcome, n, e, and m represent normal options for fairnegotiations. The direction e to m represents an increased quantity; theopposite direction e to n represents a diminishing quantity: less project.

The quantity line always retreats topoint sy the trivial case of no cost in-curred, no return earned.

N-e-M represent fair negotiation options, thequantity line. L-e-K is the quality line.

R (result)

(0,0) w C (cost)

fig 1.27 Quantity & Quality Lines

Line n-e-m represents the common trade off be-tween input and output, cost and result —more of the first triggers more of the secondLine l-e-k represents breakthroughs — a newconcept offers better results for less cost

The quality line represents changein the quality of the project: produc-tivity gain or loss. The cause may bebetter management, change in moraleand motivation, or a new technique,innovative procedures, etc. Point k,relative to point e, represents a projectthat costs less and achieves more. Incontrast, point / represents a case inwhich the project costs more than thee case but produces less in result. Thedirection e to k represents improved


results

the competitive zone

fig 1.18 the competitive zone

The area between the two thicker lines rep-resents the edge one competitor offers overthe other. It can be viewed as a cost ad-vantage for similar results, or result ad-vantage for similar cost, or a combinationthereof

project quality; the direction e to / repre-sents a quality loss.

The Competitive Zone

The owner of a project, the buyer, maywish the bidder to present alternatives.The options represented by a given bid-der will define several possible end statesfor the cost-result balance, and the linethat connects these points will be thequantity line for that bidder. The nextbidder will do the same and chart a dif-ferent quantity line, reflective of his owncost-result balance. The area enclosedbetween the two lines is the competitivezone. See insert "the competitive zone"(fig 1.18). The competitive zone can beviewed in two typical ways: through mark-ing horizontal lines that say for the same result which bidder offers alower price, and through marking vertical lines that flush out for a giveninvestment (cost) which bidder offers more product (= result).

Two quantity lines of two bidders may run parallel (not close to theorigin, though), may diverge, may meet and continue congruent, or maymeet and then switch roles: the higher line becomes the lower. Themeaning of each configuration is rather clear. The last case, role switch-ing, is typical of the situation in which one bidder is small and the otherlarge. For small projects the small company may be more flexible andefficient and offer the same results for less cost, but when the size of theprojects (the results) becomes larger, the small firm reaches its limit andmust rely largely on subcontractors, which reduces its net income andpushes its price higher. At the same time the larger bidder comes to his"natural" size and turns more competitive.

If every project begins at the origin, point s (0, 0), and ends at its endstate e, then its progress can be marked as a progress line leading fromsto e. The progress line is a continuous stretch, and each of its pointsdesignates a potential end state reflecting an abrupt termination (before

Elements 69

planned completion). All the various progress lines will generally belined up below the diagonal leading from s to e, since otherwise it will bepossible to stop the project and attain a better R/C (result to cost) ratiothan the end point.

A diagonal progress line represents a project comprised of accomplish-ing a series of, say, similarly sized units, when the project calls forfinishing one or a few and then moving to the rest. In this case, stoppingthe project at any point will yield a similar result/cost ratio. If the caseis a construction project and the result is measured in occupancy oftenants, then the result will only be clocked at the end of the investment.

DECISION SITUATION

Making a decision is marking an option over countless alternatives. Aseries of questions arises: How many options have been identified?How much is known about each? Are proper selection criteria avail-able? Is there the power, the determination, to make the selectiondecision, stick with it, and accept responsibility for the consequences?

The scientist and the businessman write the options. The engineerdoes the rest. The steps toward the decision act are the domain of thecost engineer; the decision proper is the responsibility of the projectengineer or project manager.

Computers are not very useful in identifying fundamental options.They are powerful in assembling the data to describe these options. Theuse of computers in developing selection criteria is slowly gaining

(1) See French 1986 for a modern, though heavily mathematical decision theory account. See Brown1974 for an easier to follow decision theory for managers. Luce and Raiffa 1957 offer an old butvalid account on games and decisions. Raiffa 1970 offers a good account on decision analysis.Sprague 1986 discusses decision support systems. Sebestyen 1962 gives an insightful account onusing pattern recognition techniques in poor-insight decision making. Woods 1975 discussesfinancial decision making in the process industry. Ghlaseddin 1986 portrays an environment fordevelopment of decision support systems. Saaty 1980,1982 and Weiss 1987 discuss AHP —Analytical Hierarchy Process, which was developed by Saaty as a means for handling a multi-factordecision situation.


ground, and most surprisingly, the computer is offering invaluable helpwith regard to the very decision act. (The advent of AL)

Engineering options are normally studied through the now common"what i f tool, which most systems offer. The ideal case of the computerselecting "what's best" is touted in advertising, but the general methodol-ogy is not yet here. The reverse of "what i f ("if what") is an interimoption (see The Competitive Edge in Chapter 2). Someone, not thecomputer, usually asks the original what if question. The computerresponds with a detailed report of the consequences and the implicationsof the suggested what if. The problem is then "so what?". The computerspews a barrage of details regarding the various options, but which detailcounts, and how to interrelate, correlate, and evenly rate the facts, thefigures, the statistics, and specifications?

Selection criteria are a matter of a general model of the reality in whichthe decision has to take place. It is necessary that this model have afunction to optimize (profit, safety, and productivity), and then it isimportant that all options be reasonably tied to that optimization or goalparameter.

Every set of options to decide from will, at a bare minimum, comprise:

• 1. The positively identified options

• 2. The "otherwise" option

• 3. The option not to decide on any option (in 1)

Too often the positively identified options include "no-options"masquerading as bona fide options. An option look-alike may be onethat cannot be completed or leads to disastrous consequences that makeany other alternative more attractive. Options may also violate practicalconstraints that were not thought of before. To weed out these fakeoptions, a cost engineer will rely on simulation mechanisms that willforetell the results before reality tells them in too stark a language.

The "otherwise" option is a group name for all the options that failedto show up on the list. The more familiar one becomes with a projectand the more unattractive the identified options are, the stronger the

Elements 71

incentive to revisit the otherwise line, and hopefully peep through itsshades and extract more alternatives.

The volume of the available literature regarding the decision processtends to hide the simple reality that most engineering decisions are madeat a point where information is dismally lacking and intuition, judgment,and subjective feel must kick in and produce a preference ranking. Allthe above do not lend themselves to mathematization and don't appearin decision recipes.

Also noted is the situation when two or more options are virtuallylacking any discriminating factors, nothing much for even intuition tobuild a case. The hallways of engineering practice are filled with anec-dotal instances in which a vendor is preferred over an otherwise equalcompetitor because his offices are located in a favorite state or, conver-sely, the competitor's city address is a funny unpronounceable name. Itis human nature to stall in such no-information cases and wait for somediscriminating factor to show up and facilitate the decision. Trackingtime lost in hesitating over poorly informed options is rarely done, andthe faint-hearted should not try. In this case, computers can be quitehelpful. Computers can proceed with a random selection and then let theengineer react if he so desires. There are typical cases like this inscheduling. Apart from the critical path, allocating resources to two slackactivities may throw an engineer into a complicated reasoning based onno data, tormenting because a crew must be told exactly when to do what.A detailed construction plan cannot be carried out if most of its activitiescome with an oversized time tolerance.

(1) There are several sources which attempt to quantify the poor-insight decision situation- See Halpin1980 for contingency in construction. See Patrascu 1988 for a good chapter on contingency. SeeGraf 1984 for an overview of contingency consideration. See Stevenson 1984 for determiningestimate contingency. See Cabano 1989 for a discussion on cost contingency for investmentestimates.


Apart from the above mentioned random decisions, the actual,categorical decision act should be left as the prerogative and the duty ofthe engineer, not the computer, if for no other reason than psychologicalconsiderations. Letting the computer act as a large and very efficientstaff, and leaving the actual cut to humans, is a policy that renderscomputers into tolerable accessories and prevents a backlash: a revoltagainst automation.

COST ENGINEERING: THE MAGIC

Lost in the forest of numbers, disguised in the dust of construction, herehides the part of cost engineering computers have not yet offended,captured, or even touched. When it rises, software withdraws; when itspeaks, computers listen: this is the magic of the profession, the abilityof the seasoned engineer to project a cost figure, a time schedule, aresource requirement, which does not extrapolate from the details, doesnot agree with recent data, and defies simple logic.1

Anyone who has been long enough in a good cost engineering shophas this experience: the chief estimator disagrees with a cost figure butcan't really explain why. An old scheduler mutters, "this can never bedone in three weeks," and he turns out to be right. Sometimes it isproductivity, other times it is the skill mix, or the engineering component— some soft element of the cost or the schedule runs into disagreement.On one hand is the diligent junior engineer who compiled comparablesand quotes with established factors and notes; and on the other hand thenose of Mr. Old-Timer: no justification, no explanation, no idea why;"this number stinks" he will say, and we had better listen.

Some attempted to explain this as the distillation of years of ex-perience; instances the estimator himself does not remember, cases hecannot refer to: only the lesson remained, just the conclusion is left, andit all converged into the "nose."

(1) See Van Kirk 1983 for a different point of view of the cost engineer as an unknown specialist.

Elements 73

In less melodramatic terms, this is called judgment. As in any ptherengineering discipline, the critical factor is not the readily programmablelogic, not the software-ready formulas, but rather the foggy, spiritedreasoning conducted with not enough information to be precise, withoutsufficient data to defend the conclusion, with not enough background toexplain the decision. In cost engineering this judgment factor appears atthe start, at the conceptual level, long before appropriation, at the timewhen it is either/or: when owners make the go/no-go decision.

It appears again at the control level: when the data come in and theydeviate from the plan, when cost is overrun, or the schedule left behind.What to do? This is where the book comes to its last chapter, whereschool lessons have nothing to say. The remedy to a runaway project isa matter of leadership and motivation as much as it is a matter of insightand quick mindness. The solutions don't repeat themselves; the situa-tions are rarely similar. Judgment and flexibility are the pathway tosalvation, not a written procedure or a preset protocol. Here again, thereis no substitute for the experienced cost engineer, no computer will help,no software will offer a solution.

With all the time we spend on computers and automation, it is easy toget carried away. The young engineers wading in the software marshtend to ridicule the old-timer who fumbles at the keyboard, blinks atflashy screens. They should not.

COST UNENGINEERING

The skills, the implements, the tools, and the methods of cost engineeringare sometimes used in the practice of unengineering, that is, when a costengineer contributes a blanket of confusion rather than an air of clarity.It happens when data are skewed, facts are hidden in the depth of areport, cost breakdown is camouflaged in fast-coming screens, and un-pleasant facts are avoided through computer stalling and software "dif-ficulties." *

(1) See more on this aspects, and the consequential issues of damage and claims in McCullough 1989,Dieterie 1985, Richter 1983, and Ponce de Leon 1985.


The more computerized we become, the more vulnerable we are tothe ill-will of an unethical few. In times long past, the top engineeringexecutive was thoroughly familiar with the work of his cost engineers.He probably graduated from their shop sometime along in his career.Such intimate knowledge offered him close control and deterred theunscrupulous staff members from "playing games." Today the "topbrass" read the reports but have little sense of how they are prepared andwhat may go wrong. They generally lack the tools to appreciate astatement like: "It will take two months before we can change the reportsthe way you want them." More dangerous are the situations when thestaff prepares summaries that omit some numbers or facts to impress apoint of view. The bureaucracy gets its way through its control of theprocess: the numbers and the way they are summarized, handled, andsubmitted.

Computers allowed the cost engineer to add layers of numbers,integrate factors he never considered before, pull together details, facts,and rules, and in most cases this is all for the better: faster, more accuratecost and schedule statements. But in a minority of instances, this newcomplexity means new opportunities for mischief. A contrived selectionof true facts is considered a civilized lie. It is the truth, but not the wholetruth. It is unimpeachable, but at the same time unethical. It is limitedto the few, but those few may cause considerable damage.

It is up to the senior executive to worry about that. The managementlayer, which is above the details, must concern itself with the question ofhow to ensure that the summary he sees reflects the details he does notsee and, conversely, how to ascertain that his policy statement is dulyreflected in countless calculations and staff detailed actions.

One principle to use is hierarchy. Fixing one main hierarchy that tiestogether the summary and the details will allow an executive to zoomdown to any detail and check the backup to every figure. The same fixedhierarchy will also allow him to enforce policy decisions and followcompliance to general guidance. The BAROU methodology is one wayto achieve this top-down connection (see Chapter 2).

Elements 75

Heisenberg, Journalism, And Cost Estimates

Commenting on the realm of nuclear particles, the German physicistHeisenberg suggested that it is impossible to "see" the location of a givenparticle since the light beam that facilitates the "seeing" will bully theparticle out of its original position. This idea that neutral observationmay at times be impossible was later reiterated in areas far removed fromphysics. It has been observed that hijacking of aircraft is motivated byguaranteed media coverage; spontaneous rioting has been curiouslycoincidental with the appearance of TV cameras. Journalists, like ex-perimental physicists may be losing their claim for consistent, non-obtrusive, neutral observations.

Cost estimators are in a similar bind. On the face of it, an estimate isa neutral comment of the eventual actual cost. In practice, on manyoccasions, the estimate drives the actual cost. The phenomenon has itspositive side: a project implementor will be motivated to finish theproject below the estimate. This drive will change the cost as it wouldhave been otherwise. The opposite case is when an overestimated costcast the project manager in a lax mood and brings the eventual cost closerto the estimate.

In some environments the bureaucratic setup is such that estimatorsare driven to overstate cost and more so driven to overrun their estimate.Compounded year after year, the result is what Professor Parkinsondescribes in "The Parkinson Law": more people, more resources, moreinvestment — less results, less benefit, less return (and it is not limitedto governments).

TRACKING

From an abstract point of view every project, no matter how complex,may be viewed as a host of interrelated activities. An activity has aduration, it costs money, and it is associated with resources andparameters. The basic idea is to compare what was planned for theactivity to how the activity proceeds in actuality or how it is expected toproceed owing to problems or events in preceding activities.


This is the theoretical view. In practice this simple comparison re-quires a great deal of effort: data have to be collected, then regimentedinto a database, and a comparison routine has to be activated. Finallythe results must be reviewed by people, assessed by more people or moretime of the same people, and possibly a remedy has to be conceptualized,details designed, and resources allocated, carried out, and monitored —all by people. The art, if not yet the science of project management is indiscerning which activity needs how much tracking.

Activities discrimination is conducted on the basis of impact on a projectresource. A project resource is anything the project can run out of, mostnotably time and money, but also, field crafts, engineering skills, storagespace, and the like. If a slipping activity will endanger the projectbecause it drains a resource, that activity needs tracking — whatever theactivity, whatever the resource.

The second consideration is obscurity. If an ongoing activity is runningoff its finish date, the slippage is clear to all. If a commitment to a vendorexceeds budgeted allocation or if a long lead shipment has not arrived intime, the impact on the project may be less obvious and automatedtracking is that much more important. Automation will also help identifythe impact of the problem (which may not be very clear either).

The third consideration may be the ripple effect. When an activity islate or exceeds an estimated ceiling, the total impact is not limited to theactivity itself but includes all resources endangered for overruns due tosubsequent activities throughout the lifetime of the project. If theproject is large, spreads over many months, and the activities are stronglyrelated, then the ripple effect on resources may be quite a complicatedcalculation and the results may be mind-boggling.

Not only resources have to be calculated in the ripple effect; newsensitivities, new criticalities are to be evaluated in much the same way.A tardy activity may change the pattern of potential bottlenecks andthereby turn a future activity, which was not at all on the critical path,into a very critical activity. Criticality means that if such an activity isrunning out of estimated limits, the impact may be very serious. Thebelated activity does not per se imply that the formerly noncritical

Elements 77

activity (and now critical) is necessarily exceeding its estimates; what itdoes say is that the project is now so much more dependent on the newlycritical activity. It is an important pointer for management to pay specialattention to that activity (although it did not deserve that attentionbefore).

It is important to discern the difference between the direct impact onresource availability of a slipping activity and the indirect impact (due tothe ripple effect on other activities), and between these two and theimpact on redistribution of the bottlenecks of the project due to changingof criticality among activities.

Tracking all the above is a matter of computer capability. Makingsense of the results is a matter of human attention. Although it is possibleto employ a very fast and effective computer program so that all theimpacts and implications of a program that exceeds it limitations will beclearly spelled out, it is always a problem to allocate enough managementhours to digest the numbers, the probabilities, the danger of each andevery situation, and for large projects it becomes utterly impossible. Thisis why activities have to be prioritized.

In the ideal world the computer program will do an exhaustive implica-tion calculation for every activity registered as exceeding an estimatedparameter. The program will then rank the instances according to animpact algorithm that will sort the cases according to potential impacton the project. If time and money are concerned such an algorithm iseasy to devise: the longer the project will have to linger, the more criticalthe impact, and the more costly the project due to a problem with acertain activity, the more attention the problem deserves.

But when the endangered resource is a skill or a storage space, theimpact on stalling the project is less obvious, and this is where the impactalgorithm has to be smart enough.

This is in the ideal world. In practice most projects employ trackingsoftware that is not fast enough, not as exhaustive as one would like it tobe, and thus a comprehensive impact calculation of each and everyactivity for each and every overflow (of any allocated resource) is an


unreachable ideal. This means that managers have to a priori definewhich activities and which resources make up the attention calling list.

The list is often based on the critical path and on resource load.Activities that lie along the critical path deserve more attention thanthose that come with slack. Activities that require a great deal ofresources of various kinds are also good candidates for special attention.

One practical way to help facilitate effective tracking is categoricalcuts. The various activities are divided into categories and each categoryattracts the attention of a category monitor. Thus long lead shipmentswill be tracked by a specialist, vendor and subcontractor commitmentswill be tracked by their specialist, and a personnel person will focus hisattention on possible shortage of people of a particular skill. Of coursefor small projects, one person will wear all these hats, but for larger onessuch a division may help in spotting problems.

BIBLIOGRAPHY

There are tens of thousands of bibliographic entries fitting under the titleof this book. Even if there was enough space, it would still make no senseto list them all like names in a telephone book. Instead, one may builda bibliographic hierarchy. The list below is comprised of over 500references. Throughout the book, these entries here are pointed-towhere they apply. Thus a reader who is interested in a particular topicmay read about it in the text of this book, and then use the footnoteswhich point to further reading. The author name and publication yearmentioned in the footnotes, will guide the reader to the fully referencedentry in the list below which is arranged by author name as a primarysorting key, and a publication year as a secondary key. A major selectioncriteria for the entries below was the wealth of their own bibliographiclist. Thereby this book becomes a two-step source to those tens ofthousands of bibliographic items mentioned above. And in particularthis arrangement allows a reader here to quickly assemble the importantliterature regarding his or her subject of interest.

Illustration: a cost engineer may encounter the term neural networkswhich is quite popular these days, and wonder what exactly is it, and howdoes it impact his profession. Now, neural networks today are at the farend of the domain of computer organized cost engineering. Thereforethey are described only briefly in this book. The reader is offered a shortconceptual description, (Use the index or see chapter 3), and the respec-tive footnote sends him to additional resources. The footnotes generallyprovide a brief characterization of the identified reference, and so areader will know that the item identified as DARPA 1989 offers acomprehensive discussion on the subject, and a rich list of referencematerial. Locating the reference in the list below, and securing a copyof the publication, the reader will hold at his or her fingertips a libraryof information on this particular subject. The same procedure will servethe reader who happens to be interested in plumbing estimating data, inusing spreadsheets for financial analysis, in industrial equipment cost, inthe theory of scheduling, in SQL, in masterplans estimates of airports,and so on and so forth throughout the topics under the title of this book.

AACE 1989 "Cost Engineers' Notebook"Amereican Association of Cost Engineers Morgan-

Project Staffing" IEEE Trans. Software Engineer-ing Vol 15 No 2

townW.VAAbraham et al 1983 "A Summary of Existing Cost

Abdel-Hamid 1989 "The Dynamics of Software

403


Estimating Databases" US Dcpt of EnergyWashington DC

Adrian J. 1985 "Microcomputers In The Construc-tion Industry" Reston, Reston VA

Aho, Hopcroft, UHman 1983 "Data Structures andAlgorithms" Addison Wesley Reading MA

Ahuja & Walsh 1983 "Successful Methods in CostEngineering" John Wiley and Sons, NY

Ahuja et al 1985 "Calendar Date Scheduling onMicrocomputers" Cost Engineering Vol 27 No 2

Ahuja H. N. 1985 "Impact of Uncertain Resourceson Project Schedule and Cost" Cost EngineeringVol 27 No 10

Aleksander, 1.1989 "Neural Computing Architec-tures" MIT Press, Cambridge, MA

Allcott William 1988 "Power Pioneer" VirginiaBusiness April

Anderson Robert 1987 "77ie Destiny of DES"Datamation March

Anderson, T. W. 1984 "An Introduction to Multi-Variate Statistical Analysis. John Wiley & Sons, NY2nd Edition

Andrews Lisa 1988 "Building Cost Manual"Craftsman Book Company, CA

AndrioleS.1984 "Decision Support Systems" QEDInformation Sciences Mass

Andriole, S. 1985 "Applications in Artificial Intel-ligence" Petrocelti Books

Antill J. M., Woodhead R. 1970 "Critical PathMethods in Construction Practice" John Wiley andSons NY

Antill, Woodhead 1982 "Critical Path Method inConstruction Practice" John Wiley & Sons NY

Appleton D. 1987 "The Modem Data Dictionary"Datamation March

Appleton Daniel 1986 "Rule Based Data ResourceManagement" Datamation May

Aries, R. S., Newton R. D. 1955 "Chemical En-gineering Cost Estimation" McGrawHill,NY

Armenise P. 1989 "A Structured Approach to

Program Optimization" IEEE Trans. Software En-gineering Vol 15 No 2

Ashfoni N., Wright Paul 1984 "Airport Engineer-ing" John Wiley and Sons NY 2nd edition

Atcheson D. 1983 ^Estimating Earthwork Quan-tities'' Norseman Publishing Co. TX

Bacherl983 "Computer Assisted Estimating" CostEngineering Vol 25 No 3-A

Bajcsy, Tidhar 1977 'VsingA Structured WorldModel In Flexible Recognition of Two DimensionalPatterns" Pattern Recognition Pergamon Press Vol9

Baker K. R. 1974 "Introduction to Sequencing andScheduling" John Wiley and Sons, NY

Bakewell 1985 'Theoretical and Practical Aspectsof Conceptual Estimating" Cost Engineering Vol 27N o 2

Balcom G. S. 1986 "Professional Time Manage-ment in Engineering and Research" Cost Engineer-ing Vol 28 No 12

Banker, Kemerer 1989 "Scale Economies in NewSoftware Development" IEEETrans. Software En-gineering Vol 15 No 10

Barlow 1989 "Statistics" John Wiley and Sons, NY

Barnsley M. F. 1988 "A Better Way to CompressImages" BYTE January

Barrett 1989 "Operating and Support Cost Modelfor Military Helicopters" AACE Transactions Mor-gantown W.VA

Barrie D. S. 1978 "Professional ConstructionManagement" McGraw Hill, NY

Bauman C1968 "Fundamentals of Cost Engineer-ing in the Chemical Industry" Reinhold, NY

Beardon 1988 "Networks for the 1990s" JohnWiley and Sons

Beckman Frank 1981 "Mathematical Foundationsof Programming" Addison Wesley Reading MA

Beech David 1989 "New Life for SQL" Datama-tion Feb

Beeston 1983 "Statistical Methods for BuildingPrice Data" E. &F.N. Spon, London

Bibliography 405

Begeman, Conklin 1988 "The Right Toot for theJob" BYTEOct

Behnke, H. et al 1983 "Fundamentals of Mathe-matics", Vol 3, "Analysis", chapter 2. The MITPress, Cambridge, MA

Behnke, H.etal (2) 1983 "Fundamentals of Math-ematics", Vol 2, "Geometry" The MIT Press,Cambridge, MA

Beizer Boris 1983 "Software Testing Techniques"Van Nostrand Reinhold, NY

Belev George, C. 1989 "Minimizing Risk In HitfiTechnology Programs" Cost Engineering Vol 31 No10

Bent 1982 "Applied Cost and Schedule Control"Marcel Dekker New York and Basel

Bert, J. 1986 "CICS Made Easy" McGrawHill, NY

Bishop et el, 1975 "Discrete Multivariate Analysis:Theory and Practice", MIT Press

Bishop, Feinberg, Holland 197S "Discrete MultiVariate Analysis" MIT Press, Cambridge, Mass.

Blanchard B. S. 1978 "Design and Manage to LifeCycle Cost" M/A press, Portland OR

Boddie John 1987 "Crunch Mode: Building Effec-tive Systems on a Tight Schedule" YourdonPress/Prentice Hall Englewood Cliffs NJ

Boehm, B. W. 1981 "Software EngineeringEconomics" Prentice Hall Englewood Cliffs NJ

Bolocan David 1988 "Excel Simplified for the IBM"Windcrest Books, PA 17294 \

Brady Sharon 1987 "Getting a Hand on Main-tenance Cost" Datamation Aug. 15

Brannigan Mike 1986 "GKS: The New GraphicsStandard" Computer Language May

Bre maud 1987 "An Introduction to ProbabilisticModeling" Springer Verlag, NY

Brewerton David 1987 "Management ofParametric Cost Estimating Within the UK Ministryof Defense" Jr. of Parametrics Spt Vol 7 No 3

Brock, G.W. 1975 "The US Computer Industry—A Study of Market Power" Ballinger, CambridgeMA.

Brown J. A. 1985 "Cost Containment andAerospace Construction " AACE Transactions

Brown Joseph 1989 "Government Estimating vs.General Contractor Estimating" AACE Transac-tions Morgantown W.VA

Brown R. V. 1974 "Decision Analysis for theManager" Holt Rinehart & Winston New York

Brown, Yanuck 1985 "Introduction to Life-CycleCosting" The Fairmont Press Atlanta, GA

Bryan Marvin 1989 "Capacity Planning" Datama-tion March

Bryan Marvin (2) 1989 "ShoppingforaPCDBMS"Datamation March

Bullis Peter 1987 "EngineeringCost Control" CostEngineering Vol 29 No 4

Burke, IL1984 "Handbook of Bar Coding Systems"Van Nostrand Reinhold, NY

Bylander E. G. 1979 "Electronic Displays" Me-GrawHill,NY

Byrne J. 1987 "The United States GovernmentManual" Office of the Federal RegisterWashington D.C.

Cabano L. J. 1989 "Cost Contingency for Invest-ment Estimates Involving New/Evolving Technol-ogy" AACE Transactions Morgantown WV

Cable, Adams 1982 "Organizing for ProjectManagement" Project Management InstituteDrexel Hill, PA

Cabral 1982 "Techniques for Capital Cost Estimat-ing with Minimal Data" Cost Engineering Vol 24No5

Caldwell D. W. 1975 "Forecasting Capital ProjectEscalation in the Chemical Industry " AACE Trans-actions

Carbone, Makridakis 1986 "Forecasting WhenPattern Changes Occur Beyond The Historical Data"Management Science March Vol 32 No 3

Carriere, W., Thibodeau, R. 1979 "Developmentof a Logistics Software Cost Estimating Techniquefor Foreign Military Sales" Report CR-3-839,General Research Corporation McLean, VA

Cascio E. 1981 "Cost Control for Off Shore Struc-tures" Cost Engineering Vol 23 No 6


Cave, Maymon 1984 "Software Lifecycle Manage-ment" McMillan NY

Cavendish, P. , Norton 1982 "Negotiating andContracting for Project Management" ProjectManagement Institute Drexel Hill, PA

Cerveny Robert 1987 "Why Software PrototypingWorks" Datamation Aug 15

Chambers L.S. 1990 "TPIMS - A new EstimatingScheduling and Costing Computer System for Trans-mission Facilities" 12th Annual MidWinter Sym-posium of the AACE Salt Lake City Utah

Charette, I t 1989 "Software Engineering RiskAnalysis & Management" McGraw Hill, NY

ChasenS. 1978 "Geometric Principles and Proce-dures for Computer Graphic Applications" PrenticeHall Englewood Cliffs NJ

Chatfield 1983 "CostAccounting" Harcourt BraceJovanovich NY

Cheadle W. G. 1987 "ADA Parametric Sizing,Costing& Scheduling" Jr. of Parametrics Spt Vol 7No 3

Chetto, H, Chetto M. 1989 "Some Results of theEarliest Deadline Scheduling Algorithm" IEEETrans Software Engineering vol 15 No 10

Cho T. F. 1980 "The Design Concept of the IBM3380' IBM Disk Storage Technology Order No:GA 26-1665

Chorafas 1989 "Systems Architecture and SystemsDesign " McGraw Hill, NY

Chou T.,Tiley W. 1989 "dBASE IVHandbook"Que Corpoation Carmel, Indiana

Clark 1983 "Structural Concrete Cost Estimating"McGraw Hill, NY

Clark, D. , Lorenzoni A,B, 1978 "Applied CostEngineering" Marcel Dekker, Inc. New York andBasel

Clark, etal 1979 "CapitalBudgeting" Prentice HallEnglewood Cliffs NJ

CleJand, King 1983 "Project Management Hand-book" Van Nostrand Reinhold, NY

Clivc Francis D. 1986 "An Owner Approach toProject Control" Cost Engineering Vol 28 No 12

Codd E. F. 1988 "Fatal Flaws in SQL" DatamationSpt

Coen 1989 "PC-BasedEstimatingof Power Genera-tion Costs" AACE Transactions MorgantownW.VA

CoIeC.,BanszkyI.1989 "FACET—Oil and GasProduction Facilities Cost Estimation and ControlTechniques" AACE Transactions MorgantownW.VA

Collier 1974 "Fundamentals of Construction Es-timating and Cost Accounting" Prentice Hall, Inc.Englewood Cliffs, NJ

Collier, Halperin 1984 "Construction Funding:Where The Money Comes From?" John Wiley andSons, NY

Computer Language 1987 "Programming in the1990s" Computer Language December

Connel J., Shafer, L. 1989 "Structured RapidPrototyping" Prentice Hall, NY

Conway, Maxwell, Miller 1967 "Theory ofScheduling" Addison Wesley Reading MA

Cook P. J. 1985 "Biddingfor the General Contrac-tor" R. S. Means Co. Mass.

Coombs W., Palmer, W, 1989 "Construction Ac-counting and Financial Management" McGrawHill, NY

Cormier R. L et al 1978 "System/370 ExtendedArchitecture: The Channel Subsystem" IBM Jour-nal of Research and Development Vol 27, No 3,May

Cowlishaw 1985 "TheREXXLanguage" PrenticeHall Englewood Cliffs, NJ

Cressmanl983 "Pilot Plant Process Costing" CostEngineering Vol 25 No 1

Criner 1984 "Successful Cost Reduction Pro&amsfor Engineers" Van Nostrand Reinhold, NY

Crowston K., Malone T. 1988 "Intelligent SoftwareAgents" BYTE Dec

Curran Michael 1989 "Range Estimating: Manag-ing Uncertainty and Reasoning with Risk" Cost En-gineering Vol 31 No 3

Curran Michael 1990 "Range Estimating: Con-

Bibliography 407

quering The Cost Overrun " 12th Annual Mid WinterSymposium of the AACE Salt Lake City Utah

Curran Michael (2) 1989 "Range Estimating:Contingencies with Confidence" AACE Transac-tions Morgantown WV

Curtin R. 1987 "Managing Complexity in Automo-tive Engineering" Technology Today June

Czuchry A., Harris D. 1988 "KBRA: A newParadigm for Requirement Engineering" IEEE Ex-pert

D'AUeyrand, M. 1989 "Image Storage & RetrievalSystems" McGraw Hill, NY

Dahl, Dtfkstra 1972 "Structured Programming"Academic Press London

DARPA 1989 "Neural Network Study" ArmedForced Communication & Electronics AssociationFairfax VA 22033 703-631-6100

Daskal, S. 1989 "Project Socrates: Strategic Plan-ning for Advanced Technology" National DefenseJournal of the American Defense PreparadnessAsssoc.

Dataquest 1982 "Blue Boot Rental Rates Con-struction Equipment" Dataquest Inc. Palo Alto,CA

Date C. J. 1982 "An Introduction to DatabaseSystems" Addison Wesley London

David F. NM Barton D. E. 1962 "CombinatorialChance" Hafner Publishing Company NY

Davis Morton 1970 "Game Theory" Basic BooksNY

Davis P., Price, W. 1984 "Security for ComputerNetworks" John Wiley and Sons, NY

Davy M. 1989 "Capital Cost of Pulp and PaperCapacity" AACE Transactions MorgantownW.VA

Dean E. 1989 "Parametric Cost Estimating: ADesign Function" AACE Transactions Morgan-town W.VA

DeMarco, T. 1982 "Controlling Software Projects"Yourdon Press, NY

Dempster 1969 "Continuous Multi VariateAnalysis" Addison Wesley Reading MA

Dempster A. P. 1969 "Elements of ContinuousMula'variate Analysis", Addison Wesley, MA

Derfler Frank 1986 "The Software Key to LANS "PC Magazine Dec

Dcrfler Frank 1987 "Making Connections: LANAnalyzers" PC Magazine Dec 22

Derfler Frank 1988 'A Field Guide to LAN Operat-ing Systems" PC Magazine June 14

DiAntonlo, A. 1986 "Spreadsheet Applications inFinancial Accounting" Reston Books Reston, VA

Diehl, S-, ApikI S. 1988 "Plotters in Perspective"BYTE Dec

Dieterie 1985 "Damage Issues In ConstructionClaims" Cost Engineering Vol 27 No 2

Dodge 1985 "Dodge Construction Systems Cost"Dodge Cost Information Systems McGraw HillPrinceton, NJ

Dodge (2) 1989 "Dodge Guide to heavy Construc-tion Cost" McGraw Hill NY

Dodge (3) 1989 "Dodge Manual of Pricing andScheduling" McGraw Hill NY

Dodge (4) 1989 "Dodge Systems Costs for BuildingConstructions" McGraw Hill NY

Dodson 1983 "How To Make Accurate Initial CostEstimates" Marcel Dekker New York Basel

Doering G. and Ho, T. 1985 "Estimating and CostControl for Revamp and Upgrade Projects AACETransaction

Douglas C. JM Munger E. L. 1969 "ConstructionManagement" Prentice Hall, Inc. EnglewoodCliffs, NJ

Drigani Fulvio 1988 "Computerized Project Con-trol" Marcel Dekker NY and Basel

Drucker 1974 "Management: Tasks, Respon-sibilities, Practices" Harper & Row NY

Drucker 1980 "Managing in Turbulent Times"Harper & Row NY

Drucker 1986 "The Frontiers of Management"Harper & Row NY

DuBois 1980 "A Study of Cost Indices" AACETransactions


Dumond, Mabert 1988 "Evaluating ProjectScheduling and Due Date Assignment Procedures"Management Science Januaiy Vol 34 No 1

Dunn Robert 1990 "Software Quality" PrenticeHall, NJ

Ellison C.,Winn,I~ 1988 "Add-In Boards: GettingThe FAX" PC Magazine June 28

ElyE.S.1986 "Third Party Maintenance" Datama-tion Spt.

Engelke C , Rothrock, Shah 1989 "A HighwayConstruction Cost Estimation Workstation" AACETransactions Morgantown W.VA

Engelsman C. 1983 "Residential Cost Manual:New Construction, Remodeling anda Valuation"Van Nostrand Reinhold NY

Enrico J. F. 1984 "More Facts Less Time" CostEngineering Vol 26 No 6

Evans S. J. et al 1968 "National Security Manage-ment — Procurement" Industrial College of theArmed Forces Washington D.C.

FeayB. 1987 "All in a Days Work" Cost Engineer-ing Vol 29 No 4

Ferelli 1989 "Al leaves Ivory Tower" ComputerTechnology Review July

Finkelstein 1988 "Integrated Logistics Support"IFS Bedford UK

Finkelstein, Pascal 1988 "SQL Database Manage-ment Systems" BYTE January

FischhofTB. 1981 "Acceptable Risk" CambridgeUni. Press Cambridge London

Fisher G. H. 1971 "Cost Considerations in SystemsAnalysis" American Elsevier, NY

Flume E. 1989 'The Mathematical Structure ofRaster Graphics" Academic Press, CA 92101

Fleming, C. 1989 "Handbook of RelationalDatabase Desist" Addison Wesley

Forbus K. D. 1988 "Intelligent Computer AidedEngineering" Al Magazine Vol 9 No 3

Fox M. et al 1989 "Introduction to BusinessSoftware" Que Corporation Carmel, Indiana Car-mel, Indiana

Freiman, Park 1979 "Price Software Model - Ver-sion 3: An Overview" Proceedings IEEE-PINYOctober Catalog #TH0067-9

French, Simon 1986 "Decision Theory: An Intro-duction to the Mathematics of Rationality", JohnWiley & Sons, NY

Frisse Mark 1988 "From Text to Hypertext" BYTEOct

Fry T. C 1965 "Probability and its EngineeringUses" D. Van Nostrand Co. Princeton NJ

Gallagher 1982 "Paremetric Estimating for Execu-tives and Estimators" Van Nostrand Reinhold NewYork

Gallagher 1988 "Knowledge Systems for Business"Prentice Hall

Garbutt D. 1985 "How to Budget and ControlCash" Gower Publishing Co. BrookfieldVT

Garcia 0.1989 "Knowledge and Data Engineering"IEEE Trans. Knowledge and Data Engineering voll n o l

Garcia, A. 1987 "Computer Security" John Wileyand Sons, NY

Gates K-, Wickard 1989 "Construction-CAE: In-tegrated Planning and Cost Control" AACBTrans-actions Morgantown W.VA

Gelb, Arthur 1984 "Applied Optimal Estimation "The MIT Press Cambridge MA

Gerl, Gottlob, Wiederhold 1989 "EfficientDatabase Access from Prolog" IEEE Trans.Software Engineering Vol 15 No 2

GhlaseddinN.1986 "An Environment for Develop-ment of Decision Support Systems" Decisions Sup-port Systems Elsevier Science Publishing

Gido J. 1985 "Project Management Software Direc-tory" Industrial Press, NY

Gilbreath 1983 "Managing Construction Con-tracts: Operational Control for Commercial Risk"John Wiley and Sons NY

Gleick James 1987 "Chaos" Viking NY NY

Gobourne J 1982 "Site Cost Control in the Con-struction Industry" Butterworth Scientific London

Godel J. B. 1975 "Guide to Information Science in

Bibliography 409

the Construction Industry" Constructing PublishingCo.

GoldbergC. J., Kunkel G. 1987 "Chartinga CourseThrough Graphics Software" PC Magazine March10

Gosselin, R, McMullan L. 1989 "Parametric Es-timating — In Search of Expert System" AACETransactions Morgantown W.VA

Graf Mervin 1984 "An Overview of ContingencyConsiderations" Cost Engineering Vol 26 No 1

Greenberg Ross 1989 "Compress and Expand TheFiles On Your Hard Disk Automatically" PCMagazine Dec

Grimm, N., Rosaler, R. 1990 "Handbook ofHVAC" McGrawHUI,NY

Guthrie 1974 "Process Plant Estimating, Evalua-tion and Control" Craftsman Book Company ofAmerica Carlsbad, CA

Hackney J. 1989 "Accuracy of Hazardous WasteProject Estimates'' AACE Transactions Morgan-town W.VA

Halpin, D. Woodhead 1980 "ConstructionManagement" John Wiley and Sons

Halvorsen R. & Ruby 1981 "Benefit Cost Analysisof Air Pollution Control" Lexington Books Lexi-ngton MA

Hamburger 1989 "Scheduling for On-TimeProject" AACE Transactions Morgantown W.VA

HaneikoJ.B. 1983 "Material Cost Monitoring andForecasting" Cost Engineering Vol 25 No 1

Hannabaum Larry 1990Prentice Hall, NJ

"Landscape Design"

Hannon E. 1990 "The use of ComputerizedManagement Information Systems in US PowerPlant Operations" 12th Annual MidWinter Sym-posium of the AACE Salt Lake City Utah

Hannsgen K. B. et al 1985 "Steady State SizeDistribution of the Cell Division Cycle" SIAM augvol 45 No 4

Harker, Vargas 1987 "The Theory of Ratio ScaleEstimation " Management Science Nov Vol 33 No11

Harman, 1982 "Modem Factor Analysis", U. ofChicago Press

HechtJ.1988 "UnderstandingLasers" Howard W.Sams & Co.

Helms 1985 "Computer Language ReferenceGuide" Howard W. Sams & Co. Indiana

Henderson T. H., Buckholtz P. 1989 "ComparativeCost Estimates for Project Control" AACE Trans-actions Morgantown W.VA

Hertz D. a 1983 "Risk Analysis and its Applica-tions" John Wiley & Sons, NY New York, NewYork

Hessinger Paul 1987 "DBMS: Adding Value toVanilla" Datamation March

High Technology 1984 "Designing Molecules ByComputer" High Technology Jan

HilUer F. S. 1980 "Introduction to Operation Re-search", 1980

Hlllyard F. (editor) 1986 "Army Command andManagement" Department of the Army US ArmyWar College (10th edition)

Hink Robert 1987 "How Humans Process Uncer-tain Knowledge" AI Magazine Vol 8 No 3

Hoelscher R. 1952 "Graphic Aids in EngineeringComputation" McGrawHillNY

HofTman Robert 1987 "The Problem of Extractingthe Knowledge of Experts" AI Magazine Vol 8 No 2

Hofstadter D. 1979Vintage Books, NY

"Godel, Escher, Bach"

Hollman J, Dysert L. 1989 "Developing of Concep-tual Estimating Support Systems at Kodak " AACETransactions Morgantown WV

Holtz, H1983 "How To Succeed As An IndependentConsultant" John Wiley and Sons, NY

Holtz, H. 1988 "The Consultant Guide to WinningClients" John Wiley and Sons, NY

Howard Bill 1988 "Classified Intelligence: Manag-ing Personal Information" PC Magazine Dec

Howard P. 1988 "Guide of Software ProductivityAids" Applied Computer Research Phoenix, AZ


Hu T. 1982 "CombinatorialAlgorithms" AddisonWesley Reading MA

Humphreys Kenneth 1984 "Project and CostEngineers Handbook" Marcel Dekker New Yorkand Basel

Humphreys Kenneth, K, 1987 "Basic Cost En-gineering" Marcel Dekker New York and Basel

IBM 1982 "IBM Virtual Machine/System ProductCMS Primer IBM, NY Pub No. SC24-5236-O

IBM 1984 'VirtualMachine/System Product" IBM,NY Pub No. SX20-4400-2

Ironmonger, R. S. 1989 "An Analysis of Construc-tion Contracts: Types, Characteristics & Application "Cost Engineering Vol 31 No 2

Jain, Ved Prakash 1983 "Cost Conscious BuildingDesign " Cost Engineering Vol 25 No 4

James Mike 1988 "Pattern Recognition" JohnWiley and Sons, NY

Jelen F. C, Black, J. H. 1983 "Cost and Optimiza-tion Engineering" McGraw Hill NY

Johnson C. R. 1988 "Cognizers" John Wiley andSons, NY

Johnson Mark 1987 "Multi-Variate StatisticalSimulation" John Wiley and Sons, NY

Jones J. 1987 "Database in Theory and Practice"TAB Books PA

Jones L. R. 1970 "Estimating Cost Escalation forRefinery Capital Projects" AACE Transactions

Jordan, Churchill 1990 "Communications & Net-working For The IBM PC and Compatibles " BradyNY

Jordan, Keller, Tucker, Vogel 1989 "SoftwareStorming: Combining Rapid Prototyping andKnowledge Engineering" IEEE Computer Vol 22No5

Josin Gary 1987 "Neural Network Heuristics"BYTEOct

Kahaner, Moler, Nash 1989 "Numerical Methodsand Software" Prentice Hall, NJ

Kakade M. S. 1989 'Economic Analysis of PowerPlant Cost and Operation" Cost Engineering Vol31Nol

Kant E. 1988 "Interactive Problem Solving UsingTask Configuration and Control" IEEE ExpertWinter

KatayamaF.1989 "Who's Fuelingthe FAX Frenzy"Fortune October 23

Kavanagh, Muller, O'brien 1978 "ConstructionManagement" McGraw Hill, NY

Kay Emily 1989 "E-Mail for LANS" PersonalComputing Nov

Kelly K. H. 1984 "Software Legal Protection"InfoSystems Spt 1984

Kernlghan B., Ritchie D. 1978 "The C Program-mingLanguage' Prentice Hall, NJ

Kerr 1983 "Cost Data for Landscape Construction "Kerr Associates Minneapolis

Kerr Susan 1987 "New Wave of LAN Security"Datamation Nov

Kerschberg L. 1988 "Expert Databases Systems"IEEE Expert Winter

Keynes 1935 "The General Theory of Employment,Interest, and Money" Harcourt, Brace, & World,Inc., NY

Kiblerl985 "The Perfect Plan" Cost EngineeringVol 27 No 7

King, F. Evans, Cohen 1983 "Handbook of Struc-tural Concrete" McGraw Hill, NY

Kirchof, Adams 1982 "Conflict Management forProject Managers" Project Management InstituteDrexel Hill, PA

Kilngler Daniel 1986 "Rapid PrototypingRevisited" Datamation October

Klumpar 1985 "Preliminary Cost Estimating for theNuclear Industry" Cost Engineering Vol 27 No 12

Koehn 1983 "Work Sampling and Unit Manhours"Cost Engineering Vol 25 No 1

Koenigseker N. A-1982 "Parametric Estimating ofBuilding" Cost Engineering Vol 24 No 6

Krishnan K. 1984 "How to Minimize ConstructionCost For Motor Wiring and Control" Cost Engineer-ing Vol 26 No 5

Kryder 1987 "Data Storage Technologies for Ad-

Bibliography 411

vanced Computing" Scientific American Oct Vol257 No 4

Kutz,M. 1986 "MechanicalEngineers Handbook"John Wiley and Sons NY

Lang H. J. 1947 "Cost Relationships in PreliminaryCost Estimates" Chem Eng. 54 117-121

Langley B. 1983 "Estimating Air ConditioningSystems" Reston Publication Reston VA

Laughlin Edward 1989 "Roles and Trends: CostEstimating of New Technologies" AACE Transac-tions Morgantown W.VA

Law A., Larmey C. 1984 "An Introduction toSimulation Using SIMSCRIPT IIS' CACI, LosAngeles, CA

Lawrence Widman Loparo Nielsen 1989 "Artifi-cial Intelligence Simulation and Modeling" JohnWiley and Sons, NY

Lebov Myrna 1980 "Practical Tools & Techniquesfor Managing Time" Prentice Hall, NJ

Lecrame, O., Gart M. 1989 "Software Portability"McGrawHUI,NY

Lennark R. 1988 "The Cost Engineer As Manager"Cost Engineering Vol 30 No 9

Leonard-Barton 1988 "Putting Expert Systems toWork" Harvard Business Review March April

Lester, A. 1982 "Project Planning and Control,Industrial Project Management" ButterworthScientific London

Lewi, Paul 1982 "Multivariate Data Analysis inIndustrial Practice", Research Studies Press

Lewis, Handloser, Bose, Yang 1989 "Prototypesfrom Standard User Interface Management Systems "IEEE Computer Vol 22 No 5

Liu, Horowitz 1989 "A Formal Model for SoftwareProject Management" IEEE Trans Software En-gineeringvol 15 No 10

Lorin, H. 1986 "Systems Architecture in Transitions—An Overview" IBM System Jr. Vol 25, nos 3,4

Luce R. D. Raiffa 1957 "Games and Decisions"John Wiley and Sons New York

Ludwig 1974 "Applied Project Management for the

Process Industries" Gulf Publishing Co. HoustonTX

Luqi 1988 "Knowledge Based Support for RapidSoftware Prototyping" IEEE Expert Winter

Luqi 1989 "Software Evolution Through RapidPrototyping" Computer, IEEE Vol 22 No 5

Luttwak Edward 1985 "The Pentagon and the ArtofWar"

Madnick, Donovan 1978 "Operating Systems"McGrawHillNY

Mallik A. K. 1982 "A Computerized Cost Effective-ness Model for Energy Production Systems Under anInflationary Environment" Cost Engineering Vol 24No 3

Mallik Amp 1982 "Computerized Cost Com-parisons of Industrial Boilers" Cost EngineeringVol24No5

Marshall & Swift 1981 "Residential Cost Hand-book" Marshall and Swift Publication Co. LosAngeles

Marshall & Swift 1982 "Marshall Valuation Ser-vice" Marshall and Swift Publication Co. Los An-geles

Marshall & Swift 1984 "Computerized CostPrograms" Marshall & Swift Los Angeles

Martin J., Derer, R., Leben J. 1990 "IDMS/R"Prentice Hall, NJ

Martin J.,Chapman K., Leben J 1989 "DBTPrentice Hall, NJ

Martin James 1972 "Systems Analysis for DataTransmission " Prentice Hall, NJ

Martin James 1976 "Principles of DatabaseManagement" Prentice Hall Englewood Cliffs NJ

Massa R. V. 1983 "International Composite CostLocation Factors" Cost Engineering Vol 25 No 5

Massey, H. 1982 "Estimating Plumbing Cost"Crafstman Books, CA

Mathur K> S. 1989 "Risk Analysis in Capital CostEstimating" Cost Engineering Vol 31 No 8

Matthews 1983 "Estimating Manufacturing Costs,A Practical Guide for Managers and Estimators"McGrawHill,NY


McCabe et al, 1966 "Unit Operations of ChemicalEngineering", McGraw Hill, NY, 1966

McClain Gary R. 1988 'VM And DepartmentalComputing" McGraw Hill, NY

McClure C. 1989 "CASE in Software Automation"Prentice Hall, NJ

McCullough R. H. 1989 "CPM Schedules In Con-struction Claims" Cost Engineering Vol 31 No 5

McFadden J. 1971 "Physical Concepts of Prob-ability" Van Nostrand Reinhold Co. New York

McIntyre,Pechural985 "Data Compression UsingStatic Huffman Code-Decode Tables" Communica-tions of the ACM Vol 28 No 6

McLean, J. 1990 "The Specification and Modelingof Computer Security" Computer IEEE, January

McNeil T., Clark, D.S. 1966 "Cost Estimating andContract Pricing" American Elsevier, New York

McWilliams Gary 1988 "Application Develop-ment: Reverse Engineering Tools" DatamationFebruary

Means, R* & 1987 "Repair and Remodeling CostData" R. S. Means and Co. Kingston, MA

Means R. S. 1988 "Labor Rates for the ConstructionIndustry" R. S. Means and Co. Kingston Mass

Means, R. S. 1988 "Mechanical and Electrical CostData" R. S. Means and Co. Kingston Mass

Means, R. S. 1988 "SquareFoot Costs" R S. Meansand Co. Kingston Mass

Means R. S. 1988 "Site Work Costs" R. S. Meansand Co. Kingston Mass

Means R. S. 1989 "Means Building ConstructionCost" Robert Snow Means Mass

Means R. S. 1989 "Building Construction CostData" R. S. Means Co. Kingston Mass

Mendel 1989 "CaseHistory-ParametricEstimatingSystem" AACETransactions Morgantown WV

Mendel 0 .1985 "The Cost Engineer's Role in LegalProceedings" AACE Transactions MorgantownWV

Merrilt 1983 "Standard Handbook for Civil En-gineers" McGraw Hill, NY

Mettrey W. 1987 "An Assessment of Tools forBuilding Large KB Systems" AI Magazine Vol 8 No4

Meyer B. 1986 "Cepage: A Software Design Tool"Computer Language Spt.

Meyers, G. 1979 'The Art of Software Testing" JohnWiley and Sons NY

Miller C. 1988 "POP-UP help: Instant Answers atYour Finger Tips" PC Magazine Aug

Miller, R. 1990 "Computer Aided FinancialAnalysis" Addison Wesley

Myers Edith 1987 "Factory Automation" Datama-tion Feb 15

Naver Michael 1989 "Information Renaissance"Online Today Spt.

Nelson W. L. 1966 "Guide to Refinery OperatingCost" The Petroleum Publishing Co. Tulsa Ok-lahoma

NES 1982 "Dictionary of Estimating Terminology"National Estimating Society Huntsville, AL

Neumanivvon, Morgenstern 1953 "The Theoryof Games and Economic Behavior PrincetonUniversity Press Princeton

Nicholls Bill 1988 "Hitfi Performance GraphicsBoard" BYTE January

Nigbor 1981 "Engineering Cost Control for theElectronics Industry" Cost Engineering Vol 23 No6

O'brien Bill 1987 "Opening Windows" Scott,Fores man and Company Glen view, 111.

O'Hara R. P., Gomberg D. 1985 "ModernProgramming Using REXX" Prentice HallEnglewood Cliffs, NJ

Obrien 1984 "CPM in Construction Management"McGawHill,NY

Ohlrichs 1981 "A Discussion and Comparison ofMethods Used In Developing Estimating Factors"Cost Engineering Vol 23 No 6

OmuraG. 1988 "Mastering the AutoCAD" Sybex,San Franciso

Oracle 1987 "SQL*Froms Designer Reference"Oracle, Belmont, CA.

Bibliography 413

Orr 1983 "Orr Systems of Construction CostManagement" Constech Inc., TX

Orr Joel 1988 "Hitfi End CADD: Expanding toNew Dimensions" PC Magazine Aug

OSE 1984 "Impact Databases" Office of Scienceand Engineering Mclean, VA

Ostwald P. F. 1984 "Cost Estimating''Hall Englewood Cliffs, NJ

Prentice

Ostwald, P. 1983 "American Machinist Cost Es-timating Guide" McGraw Hill NY

Ozkarahan E. 1986 "Database Machines andDatabase Management" Prentice Hall, NJ

Pace Brian 1985 "Planning and Scheduling withPersonal Computers at PG&E" Cost EngineeringVol 27 No 6

Page 1984 "Conceptual Cost Estimating Manual"Guld Publishing Co. Houston TX

Pal, Sankar 1986 "Fuzzy Mathematical Approachto Pattern Recognition " John Wiley & Sons, NY

Paradine, C. G. el al 1970 "Statistical Methods forTechnologists", The English Universities Press Ltd,

Park D. 1983 "Fighting Computer Crime" CharlesScribner's Sons NY

ParkW.R.1973 "Cost Engineering Analysis" JohnWiley and Sons NY

Parkinson C. N. 1957 "Parkinson's Law"Northcote Parkinson Malaya

C.

Patrascu A. 1988 "Construction Cost EngineeringHandbook" Marcel Dekker, NY

Patten Neff William 1987 "Construction Produc-tion Forecasting: A Modeling Approach" Cost En-gineering Vol 29 No 4

Patterson W. H. 1969 "Preparing and Maintaininga Construction Cost Index" AACE Transactions

PC Magazine 1988 "Computer Viruses; Are theyReal?" PC Magazine June 28 1988

Peeples David 1989 "Cost Control in the Opera-tional Environment" AACE Transactions Morgan-town W.VA

Perry J. 1950 "Chemical Engineers' Handbook"McGraw Hill, NY

Perzanowski P. 1989 "From CAD to CPMSoftware" AACE Transactions MorgantownW.VA

Peters Lee A. 1983 "Performance Specifications forComputerized Cost Estimating" Cost EngineeringVol 25 No 4

Piper 1982 "ADMofPDM?" Cost EngineeringVol 24 No 2

Plum, T. 1984 "CProgramming Guidelines" PlumHall Inc., NJ

Ponce de Leon, G. 1985 "Planning and SchedulingConcepts in the Containment of Contract Claims"Cost Engineering Vol 27 No 6

Popescu, Hamianl 1985 "Directory of Microcom-puter Software for Cost Engineering" Marcel DekkerNew York Basel

PopisilC. 1990 "A PC Based Scheduling System fora Transmission & Distribution Construction Depart-ment" 12th Annual MidWinter Symposium of theAACE Salt Lake City Utah

Popper H. (Editor) 1970 "Modem Cost Engineer-ing Techniques" McGraw Hill, NY

Poulton, C. 1989 "The Dangers of Early Estimates"AACE Transactions Morgantown WV

Powers 1982 "Practical Accounting and Cost Keep-ing for Contractors" Frank and Walker Co. Chicago1982

Preib, Sayward, Shaw 1987 "Software Metrics"MIT Press, Cambridge MA

Prerau David 1987 "Knowledge Acquisition inExpert System Development" AI Magazine Vol 8 No2

Price, S. 1986 "Managing Computer Projects" JohnWiley and Sons

Prigoglne I., Stengers, I. 1984Chaos" Bantam Books, NY

"Order Out of

Purdum Jack 1986 "Benchmark Philosophy andMethodology" Computer Language

Putnam L. H. 1980 "SLIM System Description"Quantitative Software Measurement McLean, VA

Pyykkonen Martin 1987 "Putting LAN Plans towork" Datamation Nov.


Querns W. R. 1981 "Practical Control for FieldCost Engineers'* Cost Engineering Vol 23 No 4

Rad P. F. 1982 "A Graphic Approach to Construc-tion Job Site Planning" Cost Engineering Vo! 24 No4

RaiffaH. 1970 "DecisionAnalysis" Addison Wes-ley Reading, MA

Rathbone, T. 1985 "Computers and Construction "Reston, Reston VA

Reams J- 1990 "Sustantiation and Use of thePlanned Schedule in a Delay Analysis" Cost En-gineering Vol 32 No 2

Remer Donald al al 1984 "The State of the Art ofPresent Worth Analysis of Cash Flow Distributions"Engineering Cost and Production Economics Vol7No4

Rhodes & Binkley 1985 "Matrix Costing Techniquefor Emerging Technologies" AACE Transactions

Richardson 1984 "Process-Plant Construction Es-timating Standards" Richardson Engineering Ser-vices San Marcos, CA

Richardson 1988 "Process Plant Construction Es-timating Standards" Richardson Engineering Ser-vices San Marcos, CA

Richardson 1989 "General Construction Estimat-ing Standards" Richardson Engineering Services,San Marcos, CA

Richter 1983 "International Construction Claims:AvoidingandResolvingDisputes" McGraw Hill NY

Rlshe, N. 1988 "Database Desist Fundamentals"Prentice Hall

Roberts, Kane 1989 "Computer Security" Com-pute Books Greensboro, North Carolina

Rodl H ei al 1985 "Cost Estimating for ChemicalPlants" AACE Transactions

Roetzheim W. 1990 "Structured Design UsingHIPO-ir Prentice Hall

Rogers D., Adams, J. 1990 "Mathematical Ele-ments of Computer Graphics" McGraw Hill, NY

Roman, D. 1986 "Managing Projects" Elsevier,NY

RoschW. 1987 "Hard Disk Heavy Weights" PCMagazine

Rosenaul984 "Project Management for Engineers.Planning and Scheduling" Lifetime Learning Pub-lications Betmont, CA

Rosof David 1985 "Calculator Valuation Guide.Building Construction Cost Guide." BuildingEconomics Research Ltd. Woodbridge, VA

Rounds 1984 "The Electronic Spreadsheet: ASimplified Approach to Computer Assisted Estimat-ing" Cost Engineering Vol 26 No 6

RoweW. 1977 "An Anatomy of Risk" John Wileyand Sons NY

Russell, E. 1983 "Building Simulation Models withSIMSCRIPTIL5" CACI, Los Angeles, CA

Saaty 1982 "Decision Making for Leaders"Lifetime Learning Publications Belmont CA

Saaty T. L. 1980 The Analytic Hierarchy Process"McGraw Hill NY

Samid, Amnon, Samid, G. 1990 "Fall BackFlexibility in Power Station Master Plan " Proceed-ings 12th Annual Mid-Winter Symposium, AACE.Salt Lake City Utah

Samid, G. 1976 "Development of a Method ofRepresenting Different Processes in a Property Spaceand Sorting Them by Order of Priority", ResearchThesis, Technion — Israel Institute of Technology

Samid, G. 1978 "The Zero Law of Debugging, or:Structured Programming ~~ How Far Structured?"Computer, IEEE 1978

Samid, G. 1981 "Modified Top-Down Design: AProposedMethodoloQ?" Datamation Nov. 1981

Samid, G. 1982 "Overestimation and the Competi-tive Edge') Cost Engineering, Vol 24/No 5-A, Sep-tember 1982

Samid, G. 1983 "Complexity Reduction in MultiVariate Entities", Office of Science & EngineeringORSA Proceedings

Samid, G. 1984 "Cost Database: How to Build orBuy The One You Need". Cost Engineering, Vol26/No 2, April 1984

Samid, G. (2) 1984 "Forecasting: A Computer-AgePaper & Pencil Method: The Delta Triangle", CostEngineering Vol 26/No 3, June 1984

Bibliography 415

Samid, G. (3) 1984 "Credit Datamatics: A NewCredit Management Methodology" Credit andFinancial Management, May 1984

Samid, G. 1988 "T*VIEW: A Cost Engineer'sToolbox" D&G Sciences, Mclean VA

Samid, G. (2) 1988 "Uncertainty Reduction inIndustrial Planning" Seminar Presentation,Cambridge, England.

Samid, G. 1989 "Balanced Reduction of Uncertain-ty: A Project Management Methodology", Cost En-gineering, August 1989

Samid, G. (2) 1989 "Taking Uncommon — ButEffective — Steps for Computer Security", Com-puters in Banking, March 1989

Samid, G. el al 1985 "Force Generation ModelingSystem" Functional Description Publication, Dot)contract: MDA-903-84-C-0084

Sass Margo 1964 "Computer Augmentation ofHuman Reasoning" Spartan Books WashingtonDC

Schank, Hunter 1985 "The Quest to UnderstandThinking" BYTE April

Scheiling T. 1980 "The Strategy of Conflict" Har-vard Univ. Cambridge MA

Schwcyer 1955 "Process Engineering Economics"McGrawHillNY

Sebestyen G. S. 1962 "Decision Making Process inPattern Recognition" Macmillan Co NY

SeidmanA.H. 1984 "The Handbook of Computersand Computing" Van Nostrand Reinhold Co.

Seldon, M. R. 1979 "Life Cycle Costing" WestviewPress, Boulder, CO

SerlinO. 1989 "Toward an Equitable Benchmark"Datamation Feb

Seymour Jim 1988 "Software Delays: Truth orConsequences" PC Magazine June

Seymour Jim (2) 1988 "Programmable Databases"PC Magazine May 17

Shammas Namir 1988 "Personal REXX" BYTEJanuary

Sharp G., Haram W. 1989 "Autocad AdvancedTechniques" Que Corporation Carmel, Indiana

Shaw Richard Hale 1988 "SQL: An EmergingDatabase Standard for PC's" PC Magazine May 17

Sherman L. 1984 "Project Planning Tool" CostEngineering Vol 26 No 6

Shreider A. 1966 "The Monte Carlo Method"Pergamon Press Oxford

Simon, M. 1989 "Construction Claims andLiability" John Wiley and Sons

Simpson D. 1987 "New Technologies in SoftwareProject Management" John Wiley and Sons

Slemakerl985 "The Principles and Practice of CostSchedule Control Systems" Petrocelli Books Prin-ceton NJ

Smith B., Rinko-Gay, W. 1990 "EISA vs MCA "Personal Workstation Feb

Solkind, N. 1988 'The Power ofQuattro" JohnWiley and Sons

Somerson Paul 1987 "How to Handle Your HardDisk" PC Magazine

Sommerville, 1.1989 "Software Engineering" Ad-dison Wesley

Spencer G., Rahbar F. 1989 "Automation of theScheduling Analysis Process" AACE TransactionsMorgantown W.VA

Spinney Frank 1985 "Defense Facts of Life"Westview Press Boulder and London

Spradlin 1982 "Building Estimators ReferenceBook" Frank and Walker Co. Chicago 1982

Spradlin (2) 1982 "Pocket Estimator" Frank andWalker Co. Chicago 1982

Sprague J. C. 1985 "A Systematic Approach toReplacementAnatysis " Cost Engineering Vol 27 No12

Sprague R. 1986 "Decision Support Systems"Prentice Hall

Spruil, Popescu 1983 "Current Practice in CostEstimatingand Cost Control" American Society ofCivil Engineers NY

Stalling? William 1987 "Handbook of ComputerCommunication Standards" MacMillan PublishingCo, NY Vol 1,2,3


StalIings,W.1989 "When One LAN isnot Enough"BYTE Magazine January 1989

Stalhvorthy 1973 "Control of Investment in NewManufacturing Facilities." Gower Press Essex, UK.

Stamps David 1987 "CASE: Cranking OutProductivity" Datamation, July

Stark Robin 1989 "Encyclopedia of Lotus 1-2-3"Windcrest Books, PA 17294

Sterling Leon 1987 "Mathematical Reasoning"BYTEOct

Stevens J. 1985 'Techniques for Construction Net-work Scheduling" McGraw Hill, NY

Stevenson J. J. 1984 "Determining MeaningfulEstimate Contingency" Cost Engineering Vol 26 No1

Stevenson James 1989 "A Cost Control Programto Meet Your Needs" AACE Transactions Morgan-town W.VA

Stewart R. D. 1982 "Cost Estimating" John Wiley& Sons, NY

Stewart 1986 "Cost Estimating and Micro Com-puters" McGraw Hill New York

Stewart Rodney, Wyskfda R. 1987 "CostEstimator's Reference Manual" Wiley IntersciencePublication John Wiley & Sons, NY

Stone David 1988 "Remote Computing" PCMagazine January

Stonebraker 1989 "Future Trends in DatabaseSystems" IEEE Trans. Knowledge and Data En-gineering vol l n o l

StorerJ. 1988 "Data Compression" ComputerScience Press Rockville, MD

Struik, Dirk, 1967 "A Concise History of Mathe-matics", chapter 7, Dover Publications, NY,

Stukhart G., Pearce S. 1989 "Construction BarCode Standards" Cost Engineering Vol 31 No 2

Sugihara, Kikuno, Yoshida 1989 "A MeetingScheduler for Office Automation" IEEE Trans.Software Engineering Vol 15 No 10

Suhank George 1985 'Hie Cost Control Tree"Cost Engineering Vol 28 No 4

Sweet Frank 1986 "Milestone Management"Datamation October

Swift 1983 "Towards Developing a Model forForecasting Construction Labor Wage Rate In-creases" Cost Engineering Vol 25 No 2

Tanenbaum S. A. 1990 "Structured ComputerOrganization" Prentice Hall

Tanik Murat, Yun David 1988 "Al/Software En-gineering" IEEE Expert Winter

Tank, Hopfield 1987 "Collective Computation inNeuron Like Circuits" Scientific American Dec Vol257 No 6

Tavakoii 1989 "Bid Markup Assistant: An ExpertSystem" Cost Engineering Vol 31 No 6

Taylor Dave 1987 "Languages Past Present & Fu-ture" Computer Language December

Taylor J. 1987 "Spreadsheet Analysis" PCMagazine Dec 22

Taylor, A. 1989 "Introduction To dBASE IVProgramming" Compute Books, PA

Techwell 1985 "A Repricing Model for productionRate of Quantity Revision " Cost Engineering Vol27No4

Teller 1985 "Blasting Techniques: Estimating theBlasting Project" Explosives Services CorporationW.VA

Terino John 1989 "The Problems and Future ofAmericas Defense Industry" National Defense Dec

Thompson & Thompson 1985 "Inside An ExpertSystem" BYTE April

Thompson James 1989 "Empirical Model Build-ing" John Wiley and Sons, NY

Thrush K- B. et al 1987 "Project Control in DesignEngineering" Cost Engineering Vol 29 No 3

Tipton at al 1985 "Vie Living Schedule; Progressor Problem?" Cost Engineering Vol 27 No 6

Tompkins 1985 "Project Cost Control forManagers" Gulf Publishing Co. Houston TX

Toth S. 1985 "Practical Scheduling GuidelinesUsingCPM Computer Programs" Cost EngineeringVol 27 No 11

Bibliography 417

Toth S. D. 1983 "Field Progress MeasurementSystem - Direct Hire Job " Cost Engineering Vol 25No 2

Towner Larry 1989 "IDMS/R" McGrawHill, NY

Trust, S. Pomeranski 1983 l(Viskalc for Scienceand Technology" Sybex, Berkley

Traub, J. et al 1987 "Information Based Com-plexity" Academic Press, Boston

Tstchritris, C et al 1982 "Data Models", PrenticeHall, NJ,

Tyler, T., Barnett J. 1989 "Standardization ofEstimating Data bases" AACE Transactions Mor-gantown W.VA

USN 1958 "PERT, Pro&am Evaluation ResearchTask" Special Projects Office, Bureau of Or-dinance Dept. of Navy Washington D.C.

Vainner David 1984 "Efficient ConstructionProject Management" Cost Engineering Vol 26 No5

Valkenhoff B. H. 1981 "Cost Performance Meas-urement" Cost Engineering Vol 23 No 4

Vallabhanenl Rao 1989 "Auditing ComputerSecurity" John Wiley and Sons, NY

Valliere, D. 1990 "Computer Aided Design inManufacturing" Prentice Hall, NJ

Van Kirk 1983 "The Cost Engineer — The Un-known Specialist" Cost Engineering Vol 25, No 4-A

Vance 1982 "Building Cost: A Bibliography"Vance Bibliographies III

Varela L. 1989 "Airport Cost Evaluation in Bolivia "AACE Transactions Morgantown W.VA

Wade Philip 1982 "Cost Control in BuildingDesign " Cost Engineering Vol 24 No 6

Walston C, Felix C. 1977 "A Method of Program-ming Measurement and Estimation" IBM SystemJournal 16,1

Wayner Peter 1987BYTEOct

"Zero Knowledge Proof

Wayner Peter (2) 1987 "Building an EncryptionSystem" Computer Language December

Weinberg, Weinberg 1979 "On The Design ofStable Systems" John Wiley & Sons NY

Weiss, Rao 1987 "AHP Design Issues for LargeScale Systems" Decision Sciences Univ. of SouthCarolina

Wendes, H. 1983 "Sheet Metal Estimating Hand-book" Van Nostrand Reinhold NY

Westney Richard E. 1985 "Managing The En-gineering and Construction of Small Projects" Mar-cel Dekker New York and Basel

Wilde 1964 "Optimum Seeking Methods" PrenticeHall Englewood Cliffs NJ

Williams G. L. 1982 "Financial Control on a LargeConstruction Project" Cost Engineering Vol 24 No2

Willis Rod 1989 'Tom Peters On Managing Tech-nolo$y" Management Review Feb

Wilson & Crouch 1982 "Risk Benefit Analysis"Ballinger Cambridge Mass

Wilson, Frank 1989 "Manufacturing Cost Estimat-ing and Control" Cost Engineering Vol 31 No 5

WinklehausC. 1982 "Useof Non LinearRegressionEquations In Parametric Analysis of Cost, Man-power and Construction Times" Cost EngineeringVol24No4

Winston P. H. 1984 "Artificial Intelligence" Ad-dison Wesley Reading Mass

Wipper F. 1989 "Guide to DB2 & SQL/DS"McGraw Hill, NY

Wong, T. 1989 "TheSearch For Fault Free Produc-tion" National Defense Feb

Woodcock 1989 "Managing A Turnaround UsingComputerized CPM" Cost Engineering Vol 31 No7

Woods, Donald R. 1975 "Financial DecisionMaking in the Process Industry" Prentice Hall, Inc.Englewood Cliffs, NJ

Woodworth B. 1989 "Is Resource ConstrainedProject Management Software Reliable?" Cost En-gineering Vol 31 No 7

Wyden, P. 1985 "Day One" Warner Books NY


Yanoviak 1985 "Competitive Bidding Strategies"AACE Transactions Morgantown WV

Yates,K.199O "Innovative Construction FinancingTechniques" Cost Engineering Vol 32 No 1

Yourdon Edward 1986 "Managing The StructuredTechniques" Yourdon Press NY NY

Zadeh 1989 "Knowledge Representation in Fuzzy

Logic" IEEE Trans. Knowledge and Data En-gineering vol 1 no 1

Zimmerman S. W. et al 1983 "ProgrammingPERTin BASIC" Cost Engineering Vol 25 No 3-A

Zink Dwight 1985 "The Measured Mile: ProvingConstruction Inefficiency Cost" Cost EngineeringVol28No4

Computer-Organized Cost Engineering - Taylor & Francis Group

Documents

Transcript of Computer-Organized Cost Engineering - Taylor & Francis Group