It seemed, oddly enough, that no one in our firm lined up for the role of contract administrator. In fact, it seems that this may be a common occurrence in many architectural firms. The tasks related to managing the construction phase of a project, especially the financial aspects of that phase, appear to be completely at odds with the image of the designer/architect. It certainly is not on the curriculum in schools of architecture.
However that may be, the challenges presented by fee proposals, billings, accounting, staff costs and the like are paralleled in contract administration. We developed computer tools to deal with design, CAD and internal costs. So we used them for external costs as well, applying them to projects.
Fortunately or not, the primary responsibility and expertise in these areas became mine.
The basic approach to contract administration evolved out of the use of DB and spreadsheet programs. The replication available made it possible to create templates and use the copy command liberally. The same approach yielded fairly good results with specification. With early computers and similar boat anchors, there was little sophistication in programming. As computers and software evolved, automation became possible. Out with the calculator.
The caveat to all of this was that error checking was difficult. Programming a spreadsheet to error trap was difficult. So the odd certificate might be missing some minor but important bit of data. Holdback values come to mind.
It must be evident that contract administration and income taxes share many similarities. There is one influence. Seeing an entire specification done on a mainframe word processor certainly formed a potent early desire for a man-machine interface in other aspects of architectural practice. The most telling and powerful influence was the realization, on one particularly large project with over twenty change orders, that certificates 5, 6, and 7 were incorrect and certificate 8 was several days overdue.
Although most clients and contractors stay on opposite sides of the table, occassionally they become more closely allied. It is an all too human temptation to "adjust" some components of the project, most particularly the financial components. Usually they do so with little or no accounting background. The process does not lend itself easily to such manipulation of the project finances, all of which are in the interest of expediting the work and keeping things upbeat. It can be perilous to attempt to change schedules of values, revise change orders and so on with a stroke of the pen. The true method that allows tracking is more involved, requires more paperwork and gets little client or contractor support. And it takes time.
There are two easy answers: the design stage, and total performance. Both of these stages involve a good deal of a very important job component: positive reward. However, the rest of the lot in between can be dealt with using good tools. Hence our use of StatsLog during contract administration.
There are many improvements in use in architectural firms today, including CAD, 3D modelling, BIM, wp, and a wide range of electronic support programs. Contract administration is mired in the human factor and physical factors. Any of us working this phase of the project know what it can be like to have drawings open, specs open, email open, accounting software open, and the phone to our ear all at once in order to solve or walk through an issue. Linking these software packages with fast spool up and interconnectivity would help. At least, perhaps, we would not go over the same ground as often.