Turk, . (2000). Construction IT: Definition, Framework and Research Issues, M. Fischiner (ed.

) Faculty of Civil and Geodetic Engineering on the doorstep of the millennium : on the occasion of its 80th anniversary. ISBN 961-6167-33-, pg. 17-32.

CONSTRUCTION IT: DEFINITION, FRAMEWORK AND RESEARCH ISSUES

iga Turk ABSTRACT Information technology in construction has been developing into a research discipline and teaching topic in its own right. Corresponding chairs and departments are being set up in the faculties all over the world. However, IT in civil engineering has many attributes of an immature science because its scope, vocabulary, methodologies are only loosely defined. It is a subject of influence from the technology push of computer science and technology pull of core civil engineering disciplines and therefore lacking a clear identity of its own. In the paper, the author presents a conceptual framework that can be used to define this discipline, its research issues, and can assist in structuring topics of the curricula. He claims that in order to understand the scope of information technology in construction, human activities must be well understood first. The presented framework is based on a combination of speech-act and process oriented view on engineering. A refocusing of research issues is suggested, based on 20th century philosophy, theory of science and education. KEYWORDS construction information technology, framework, research issues INTRODUCTION The industrial revolution in the 18th and 19th century resulted in a series of inventions and the broadening of the technical knowledge. The amount of knowledge in every technical field increased and no longer could a single individual master it all. Traditionally a master (master builder, master blacksmith, master carpenter...) would know everything about a product. The same person had controlled the design and build phases. Advances in technology required specialisation that resulted in the fragmentation of the manufacturing businesses and the need for information interchange between the fragments. Engineering products are tangible items and to exchange the information about their shape has been crucial. It is not a coincidence that the invention of technical drawing and its more fundamental science, descriptive geometry, concur with the industrial revolution. Descriptive geometry and technical drawings are old technical solutions (using ink and paper) to the very same functional requirements (information exchange) that modern information technology is tackling today.

Motivation An important attribute of any scientific discipline are its framework, vocabulary, methodology, paradigms and structure - as Kuhn (1962) calls them, the "conceptual boxes ... into which the scientists, by a rather a strenuous and devoted attempt to force nature into". Periodic table of elements provides such a structure for chemistry as a whole; tree of species has similar function in biology. Attributes such as spatial and time dimensions, theory of elasticity or plasticity, number of degrees of freedom, model of material etc. provide it to structural mechanics. In this paper, the paradigmatic framework for information technology in construction is proposed. In the paper, the author provides a framework for information technologies - a mental structure that required for a systematic overview of the field. It will then be used to identify where and which of them can be applied in engineering process automation, integration and process re-engineering. The framework is based on a study of construction works, but at a very abstract level, therefore the framework could be applied to other engineering disciplines as well. Specifics and particularities of construction industry, such as one-of-a-kind products, fragmentation of the industry and varying levels of IT penetration, will be studied as well. There are several motives for these kinds of studies: Any field of science and technology needs a definition of its scope and boundaries with other related topics. The term "construction information technology" has been around for about a decade, but is still often mislabelled. Any scientific field requires a framework for the organisation of knowledge. The applications include keyword sets and classification systems. Particularly in the fast paced disciplines, such as construction information technology, the transfer to practice is very important. Several research projects suggested the use of the Internet for the job (e.g. Esprit-SCENIC), but few have defined taxonomies or keyword systems that would enable fast and targeted searches. Construction IT specialists have often been accused of being solution driven - simply implementing the inventions the technology had to offer. Although it is clear that (Brandon and Betts, 1997) "market push" and "client pull" form a spiral, the study of the construction processes can result in the development of new technologies or identify gaps where opportunities for the application of technology still exist. One of the dominant research issues in construction IT today are product and process modelling. They are rarely based on solid theoretical foundations. Re-examining generic engineering processes could provide some basis for that. Analysis of the application of IT to construction processes could discover the gaps in the IT use. The resulting framework provides an overview of construction IT research field, which seems an appropriate topic for the monograph in which this paper is published. Related work Construction domain has seen few attempts to define the sub domain of construction information technology and a number of works that lead to setting up a more formal framework. One of the firsts attempts, literary to map this field, is a rising coastline drawing from VTT (Hannus, 1996). Fenves (1996) defines the topic by studying its historical development. Both approaches are illustrative, but informal. Brandon and Betts (1997) introduced a technology-oriented view on IT in construction. Technologies such as visualisation, intelligence, communication, and integration form a catchy acronym VICI - and describe the main application areas if IT. But to use IT to define construction IT is unsuitable for two reasons: (1) it is recursive and (2) the pace in which general IT is advancing is too fast to use it as a base for the structuring of civil engineering IT.

Probably the first formal attempt is the INFOMATE model (Bjoerk, 1996 and 1999). As the methodology he proposes formal IDEF0 models of generic construction processes their sub-processes. Author's work has been based on similar methodology (Turk, 1996). In this paper, the author will detail the approach by studying human works on an even more general level. DEFINITIONS Historically construction IT emerged form "computing in civil engineering". Today every civil engineering discipline is using computers, therefore the field should be defined more narrowly; any use of computers in construction is not construction IT. Two sets of topics, however, remained affiliated with it: Information technology oriented topics that span over several civil engineering disciplines (e.g. product modeling, integration, concurrent engineering). Engineering topics that span several disciplines or product's life cycle phases, such as construction documentation, management and economics, and could benefit from the use of IT. This section defines construction, information technology, and discusses various options for the design of IT solutions in civil engineering. To define how information technology can assist in construction, a clear understanding of the words, and of human "construction works" is required first. What is in a word? There is no universally accepted definition and relation among the terms "construction", "civil engineering", and "building". Most of my colleagues in the United Kingdom, for example, understand the term "construction" as the most generic of them all - and includes sub-disciplines, such as civil engineering (dealing with infrastructure products, such as roads, waterworks etc.) or structural engineering (dealing with hi-rise products). In the continental Europe, "civil engineering" is considered the most generic discipline. A sub-discipline "construction" deals with the actually making the products, but not with designing them. In the US, the acronym AEC (architecture-engineeringconstruction) denotes the three main disciplines involved in the shaping of our built environment. Architecture and engineering are considered primarily design-related disciplines, while construction is associated with the physical process of making the product or planning its production. In the phrase "construction information technology", as used in this paper, term "construction" is used in its most generic (British) sense. What is information technology Information technology is technology that is used to deliver data, information, and knowledge. It should not necessarily be affiliated with electronic computers, although today these provide the most powerful solutions. Technical drawings, descriptive geometry, copying machines, telegraph, telephone, fax etc. are information technologies as well. Today, information technology is defined as something which includes equipment, applications, and services that are used by organisations to deliver data, information, and knowledge to individuals and processes (Mentor, 1997). What is it that engineers do? To develop technologies assisting humans, it should be understood what humans, e.g. architects and engineers do. Fascinated by the 19th century's rapid progress of technologies, the traditional understanding of engineering has been influenced by the positivistic philosophy. Even the intellectual work of an engineer has been modelled in the same way as the Taylor's assembly line work: inputprocessing-output.

In an engineering context, "processing" usually means problem solving or decision making. Given a set of constraints an engineer or an architect applies his or hers knowledge to find a solution that satisfies the constraints and is objectively (engineering) or subjectively (architecture) the best. Human problem solving was believed to be a rational process; therefore, it has been argued, once we encode engineering knowledge in computer programs, computers will be able to solve objectivelyset engineering problems as well. What has been generally overlooked, however, was the importance of problem setting - "problems are not given, but must be constructed from a messy problematic situations" (Schn, 1983, pg.47). Computer programs have a fixed, predefined problem setting and are therefore blind for solutions that cannot be described by the setting. Humans, on the other hand, have the common sense and intuitive knowledge that allows them to step out of the problem setting and redefine it during the design process. Moreover, some of the most influential philosophers of the 20th century believed, that the basic ways of human action is pre-rational (Heidegger, 1962). Engineers know more than they can explicitly and rationally describe. With computers taking over a growing number of bureaucratic tasks, such as filing-in values into formulas and evaluating equations, we can appreciate the definition of intelligence given by Winograd and Flores (1997, pg. 98): "The essence of intelligence is to act appropriately when there is no simple pre-definition of the problem or the space of states in which to search for a solution". Therefore, in problem solving, computers can assist in bureaucratic tasks. They cannot, however, set problems, re-set problems or solve problems in a creative way. The development in the area of IT in construction calls for a re-thinking of the engineering curriculum. Simon (1972, pg. 57) claims that "engineering schools have become schools of physics and mathematics ... and have nearly abdicted responsibility for training in the core professional skill". Schn (1983, pg. 44) attributes such developments in academic education to the inadequate response to the dilemma that academic education is facing: rigor vs. relevance. The above hints some clear limits to the applicability of information technology in decision making, problem solving, and analysis. In some cases this would argue against the use of technology, because it blinds the designer. Unlike with pencil and paper, for example, the designers feel constrained with using computer drafting programs in early, creative phases of design. A more detailed argument was given by the author's previous work (Turk, 1998). Beyond problem solving Processing, such as decision making and problem solving, is not the only thing that humans do. The speech act theory (Winograd and Flores, 1987) would argue that the most important human activity is maintaining a network of "conversations for action" conversations in which requests and commitments lead to successful completion of the work. This also holds true for collaborative engineering activities in the construction business. Organisations, such as construction companies, are understood as networks of commitments between customers and performers. The customers require, and the performers fulfil certain tasks in the construction process. The baseline for such understanding of work is the speech act theory. A speech act is something like a message, but the term speech act has been used by the linguists (Austin, Searle) to stress the action perspective of language. The speech act theory does not understand messages as transmissions of information, but as the basis for action. The theory claims that the essential feature of speech acts is to create commitments. We do not send messages and information from one engineer to another to let him know about some design information, but to request his action and that he would either accept or reject a commitment.

What is construction information technology Construction information technology is equipment, applications, and services that are used by organisations to assist human communication, commitment negotiation, problem solving and decision making, and spans over several civil engineering disciplines. FRAMEWORK This section defines a model of construction and uses it to set up a framework for information technologies in construction. Often, construction discipline is partition according to the type of product (civil, hydrotechnic, hi-rise, etc.) or type of material (soil, concrete, steel, wood, masonry etc.). In the presented model, however, "construction" is understood as a series of "works" with a proclaimed goal of resulting in a construction product. Computers can assist humans in performing those works. It is the various types of works, all quite generic and not related to any construction technology, discipline, or material that are used to structure the applicable information technologies. Engineering works Engineering are "works" during which products, such as ships, cars or bridges, are built. Together they form a complex process that involves design, production planning, production etc. Due to its complexity, it is broken into several sub-processes, which recursively include other sub-processes etc.

manage design and planning

design

plan

manage building

build

Figure 1: Top level model of civil engineering works. There were some attempts to the categorisation of these processes. Koskela (1992) discusses design, material and work processes. Medina-Mora et al. (1993) classify the processes as material processes, information processes, and business processes. Bjoerk independently (1996) focuses on the first two. A very simple description of what civil engineering is all about could be summarised in the following statements (also see Figure 1): A client requests the making of some construction product such as a house or bridge. The product is first designed, then its building is planned and finally it is being

built. All phases of work are managed and controlled. For reasons of simplicity we are omitting steps like tendering, conceptual and detailed design, hand-over. Clearly there are big differences among the works listed above. The author proposes to (1) distinguish between co-ordination or commitment negotiation works and (2) processing works. The firsts focus on human to human interaction. The seconds follow the input-processing-output paradigm. The processing works can be further decomposed according to their dominant output. Construction processing works can be split into (2a) material processes that take raw materials, components and energy as input. Their results are material items such as components, materials or energy. They take similar material items as input. "build" is the only material process in Figure 1. The other type of processes are (2b) Information processes are those of which major input and output is information. The main information processes in Figure 1 are design and planning.

human
perform

workflow modelling
co-ordination

workflow technology manufacturing technology product material processing is-a product

is-a

activity
is-a

processing

process modelling
is-a

information processing

information technology

information

information

information modelling
Figure 2: Top level model of construction (works). The processing types are interrelated and the split is not entirely clean. For example, information is always stored on some material media that needs to be moved around - be it on paper, or as electrons. All processes create data that can be observed and used by information processes. Material processes are controlled by information processes e.g. design information specifies how much reinforcement should be placed into a concrete slab; production plan defines when and who will install the reinforcement; payment scheme calculates when and how much should be paid... Glue and base processes Processes are interrelated - the preceding process prepares the inputs of a follow-up process. But smooth transition of outputs into inputs is not always the case. Quite often the outputs need to be modified in order to be useful in the follow-up process. Therefore, the following distinction of the processes is possible (Figure 3, top): Base processes are the main value adding or core processes, for example calculating stresses in beams or positioning the reinforcement. Looking from the perspective of the item processed, the base processes are either information creation processes or information utilisation processes.

Glue processes make sure that the material items or information flow from creation process to utilisation process and that the utilisation process can use them. For example, getting the architect's drawing of the building and converting it into a format that can be used by the finite element analysis software, or moving the reinforcement from the factory to the building site. Because of their function, the glue processes are also referred to as "integration processes". They are sometimes referred to as "non value adding" and seen as an overhead that potentially could be reduced. Indeed in lean production stores and moves of components are being optimised.

Information processes Information processes manipulate information about material and information processes. Negroponte (1975) argued that "any (design) problem is a problem of lack of information". We may disagree with the word "any", however, in bureaucratic processes this is true. There are two possible reasons for this lack; (1) information does not exist and must therefore be created, or (2) the information exists and must be made available at the right time and place. Since 1960s, the computers were used in construction to create new information, first by structural analysis software and later by computer aided drafting tools, expert systems etc. The goal was to automate the base processes and reduce human interventions. This was leading to the "islands of automation" (Fenves, 1991). Since the late 1980s the computer integrated construction research has focused on the finding, moving and re-using the information. Reducing human intervention from controlling the glue processes leads to computer integrated construction. Reducing glue material processes is called lean construction. Reducing human intervention in both base and glue processes leads to computer automated construction (Figure 3, bottom). Restructuring process break-up, change of sub-process sequence, and elimination of process steps lead to process re-engineering.

IDEAL SITUATION: Integrated processes

input (base) process output/ input (base) process output

AUTOMATION

INTEGRATION

REALISTIC SITUATION: Glued processes

input base process output glue process input base process output

Figure 3: Integrated and not integrated processes Sub-processes of base and glue processes Information creation can be broken into (Figure 4) the following steps: Create. Information is created, most likely by processing the input. Typical approaches to information creation are analysis of the input, synthesis of information input, and through human input and intervention, for example, in drafting and 3D modelling. Edit. Editing involves quality control of the information, checking it against standards, requirements. The create and the edit steps may form a loop.

Record. Information which is finalised in the create and edit step should be recorded, for example, into a file, printed out ... Distribute. Information is distributed to the potential users. It can be sent directly to a person or placed on the Web, product database, library or company archive. In some cases the record and distribute steps are joined.

E.g. a draft plan is first drawn, then reviewed, then plotted on paper, and finally distributed to the engineers, who should know about the details in the draft. The glue process can be broken into the following steps: Find. Information needs to be found, for example, by searching a project database, the Web, local library ... Retrieve. Information is retrieved. The location of the information changes. Store. The information is stored locally. Convert. In order to be useful in the information use process, the information often needs to be converted. Store. The converted version of the information is stored. E.g. an engineer knows he needs architect's draft, finds that it is in his office, goes to his office, brings it to his and makes a copy.

synthesis, analysis

quality control, ISO 9000

product databases

communication, neutral file formats

create

edit

record

distribute

create process input processing output

integration process glue input processing

use process output

find

retrieve

store

convert

store

classification, product models, indexing

communication

product models

Figure 4: Sub-processes of the base and glue process. Actual steps taken depend on the information delivery component. Steps where communication technologies can be applied are marked with a star. Information process features There are several generic models of processes built into process modelling paradigms. Below is an attempt of a union. An information1 process has the following features: Input. Information entering the process. Output. Information exiting the process. Performer. Person or application performing the process.
1

The same attributes apply to material or financial process as well.

Customer. Person or application who requested this process to run. Performers and customers have roles. Method. Processes are performed using methods. which require tools Time frame. Processes take time, are scheduled etc. Has related processes (sub-processes, predecessors and follow-up processes).

Glue process features Interesting features of a glue process and the information attached include: Process intent. Processes are carried out on customer's request. Customer and performer negotiate when and how to start the process. The customer also takes part in the edit phase. Information scope. By scope, construction information can be classified into project specific information (e.g. information related to a design of a particular bridge), company specific information (e.g. organisational information, design templates, previous cases, company policies), industry wide information (e.g. building codes and regulations, standards, books and tutorials, events, enterprise directories...) and finally, general information which is not related to construction but which could be handy in construction process (phone books, dictionaries ...). Actors. The actors in construction process are humans, (dumb) machines, and applications (software). Information can flow between the actors of any type - one to one or one to many or many to many. Time. Information creation and information use may be linked sequentially or concurrently. Two different levels of concurrency are observed, weak and strong. The weak concurrency just reshuffles the processes and available performers in such a way that processes, which in fact do not require each other's information, are carried out at the same time. Strong concurrency, however, re-engineers the process methods in such a way that the "utilisation" processes guess or approximate the outputs of the "create" processes and verify the correctness of the guess afterwards. E.g. structural system and load are estimated during the design of the foundation, to speed up the beginning of the construction . Sequentially, the integration may happen (1) just-in-time, (2) just-in-case and (3) once-in-time. Looking up a design part the moment we need to know the detail is an example of just-in-time access. Going to school, reading a journal or visiting conferences is an example of just-in-case activity - we learn in case sometime the information might be useful. Watching TV or listening to the radio is an example of the once-in-time activity. If we missed it, it is gone forever. Framework of technologies Table 1 and figure Figure 4 summarise traditional and IT supported technologies used in the construction information processes, according to the criteria and structure outline in the previous subsections.

TABLE 1 TRADITIONAL AND IT SUPPORTED TECHNOLOGIES. item traditional technology information technology supported document management, product and process models data warehouses national construction information systems global IT networks email, video conferences visualisation, 4D, virtual reality, graphical user interfaces ... direct manipulation

information scope

project

drafts, folders

company country

archive, microfilm library, building regulations journals, conferences speech, phone, fax, mail

world actors man with man man with application

man with machine application with machine time just-in-time

NC tools, robotics, remote sensors book look-up, library look-up, phone call to expert ... reading books, magazines, journals, visiting conferences ... watching TV, listening to radio ... parallel work database lookup, Internet search, discovery and search agents ... subscriptions to customised content

just-in-case

once-in-time

not-archived discussion systems, push services ... parallel work

concur rency

weak concurrency strong concurrency

expert's experience, intuition

AI, data warehousing, case based reasoning

RESEARCH ISSUES More than thirty years ago, Champion(1967) wrote: "One of the problems which is important in relation to the use of computers generally in the building industry is that of finding a satisfactory coding system for information. Whereas in-

dividual firms can quite easily devise their own coding systems, the use of computer techniques throughout the industry as a whole will depend to a large extent on all parties agreeing on one generally accepted coding system. One of the difficulties is that different sections of the industry may require different forms of coding; what is ideal for the quantity surveyor for producing Bills may not be satisfactory for the architect for his own use, and vice versa." And after 30 years of research and development, particularly intensive in the last 15 years, very little has changed. Are we addressing the wrong problem? Is it solvable at all? Or is the field ready for a "scientific revolution"? Is the construction IT research method appropriate? In the sciences, two kinds of methods are practised, the so called scientific and a Socratic one. The differences are summarised in the table below (Dye, 1999). Socratic Method 1. Wonder. Pose a question (of the "What is X ?" form). 2. Hypothesis. Suggest a plausible answer (a definition or definiens) from which some conceptually testable hypothetical propositions can be deduced. 3. Elenchus ; "testing," "refutation," or "cross-examination." Perform a thought experiment by imagining a case which conforms to the definiens but clearly fails to exemplify the definiendum, or vice versa. Such cases, if successful, are called counterexamples. If a counterexample is generated, return to step 2, otherwise go to step 4. 4. Accept the hypothesis as provisionally true. Return to step 3 if you can conceive any other case which may show the answer to be defective. 5. Act accordingly. Scientific Method 1. Wonder. Pose a question.

2. Hypothesis. Suggest a plausible answer (a theory) from which some empirically testable hypothetical propositions can be deduced. 3. Testing. Construct and perform an experiment which makes it possible to observe whether the consequences specified in one or more of those hypothetical propositions actually follow when the conditions specified in the same proposition(s) pertain. If the experiment fails, return to step 2, otherwise go to step 4. 4. Accept the hypothesis as provisionally true. Return to step 3 if there other predictable consequences of the theory which have not been experimentally confirmed. 5. Act accordingly.

The scientific method in construction IT is typically applied like this: (a) follow the advances in general IT, wonder if some technology is any good in construction and find a problem it can solve; or select the technologies, which seemed appropriate for a problem in the construction industry, (b) hypothesis: a model of something has the role of hypothesis, also "the (a) stuff" is a good approach, it can be used ... (c) instantiate model the construction industry's products, processes or whatever in a way fit for the selected technology, do system analysis and design, produce diagrams ... (d) write the software an prove the hypothesis with a prototype.

There appear to be three major faults in this process. Firstly, the hypothesis is not well defined, measurable and verifiable. It is vague and inprovable with methods used in natural sciences. With the current approach, it is impossible to objectively prove right or wrong. Why? First and second order constructs Schutz (1962) distinguishes between first and second order constructs. Natural sciences concern itself with first order constructs. They are not changed or influenced by observation or intellectual manipulation. For example, in a limited context of a structural mechanics theory, a structural beam is a first order construct. No matter what kind of theory we set about its behaviour, in a lab, under weight, it would bend regardless of the theory. The second order constructs are "constructs of the constructs made by actors" and are therefore influenced and changed by the observer. In a broadest context of design, planning and construction (and this is the focus of construction IT), there is no objective definition of a beam or of the data that can describe it. Some technology with versatile handling of "beams" may invite us to think of all kinds of elements as beams. The constructs handled by construction IT (beams) and the concepts studied by construction IT (processes, works, engineers, technologies) are second order constructs. A model of how an architect and engineer collaborate, a new collaboration method or tool would change what was initially observed. A data structure describing a generic "beam" would influence the way this concepts is understood by the engineers. Construction IT is not concerned with what is objectively in the real world, but with models, which could be useful in describing it and which influence our understanding of the world. The interpretation of the models and prototypes is done by intelligent and flexible humans and not by, as with first order constructs, a beam in a laboratory. The value of research prototypes is therefore very doubtful. Some talk of them like of hiding mice and elephants (Augenbroe, 1999). They prove little until implemented by a CAD vendor and actually used by the industry. If this does not happen very soon after the research, it is very likely that the problem will be solved by the advances of general computing. But because most of point (c) and (as illustration) point (d) is very useful for scientific publishing, there has been a tendency of a growing complexity of models invented, rather than applying the principle of Occam's razor. The Socratic approach of cross-examination and refutation - trying to mentally argue for or against a proposed model - is almost non-existent in construction IT. Adding some Socratic elements to the scientific method would, it seems, contribute to the credibility of the work and provide a more balanced view on whether the research succeeded or failed. It would be useful in discussing phenomena that do not have physical existence, in particular product and process models that model human conventions and not some physical first order constructs. This is manifested by a multitude of different, correct solutions and almost zero failures. The zero failure rate, however, does not prove construction IT research successful. How is construction IT different from plain vanilla IT? Construction industry is different from other engineering disciplines as follows: It is involved in one-of-a-kind products; buildings and other facilities are usually unique. Construction products are designed, built and maintained in a one-of-a-kind processes. A process is carried out by a one-of-a-kind team of investors, contractors and subcontractors; Team members vary in size, budget and level of IT expertise and are typically small to medium enterprises (SME).

This makes construction IT a more challenging effort than IT application in the traditional hi-tech industries. However, the construction IT research community draw few consequences from the peculiarities. Doesn't all this say that modelling tools should be designed in such a way that they are easily adaptable for one-of-a-kind products; would not this argue for relatively minimalistic models composed of very generic items? Shouldn't the focus shift to handling data efficiently and not insist on having every bit of data "in formation" (sic!). Processing power and data mining techniques could be applied to get the right data at the right moment based on the current situation. The processes are unique and typically assemble a unique set of partners. Are the approaches that were conceived for the modelling of certain bureaucratic processes in banks and administrations, that are repeating millions of times, really suitable for something as chaotic as construction? What does happen in construction a million of times? The speech act theory and the communication workflow approach have not been sufficiently addressed so far. A particular problem in the implementation of IT is the varying IT capability of the team members. The co-called state-of-the-art could be available to some best practice firms, but how about the rest of them? How about the small subcontractor that should, on site, materialise a change in the product model. In particular if the goal is integrated construction, the benefits only come when the entire virtual enterprise can use new technologies. In summary, construction IT is different in the following ways: It should support products that cannot be described by standardised product models. It should encourage the transparency of the private models used in various applications rather than wait for the general adoption of the unified, standardised models (e.g. XML data exchange, publicly available EXPRESS files or component definitions). In "process" support it should focus on human-human communication and acknowledge improvisation as an important way of working in construction It should build a thin layer over a moderate technical and human-resource infrastructure. Web and browser based solutions that work with little overhead over phone lines seems the lowest common denominator. How much IT can construction companies absorb? It has been often noted that the intake of information technology in the construction industry has been slow, slower than in other industries. Researchers seem to live under the impression that they have all these fantastic solutions and that all that is lacking is a way to make the construction industry use them. Several research projects have tackled this issue from the perspective of educating the practitioners and tried to bring research results closer to the practice (e.g. SCENIC) or asking the practice what it wants (ELSEWISE). Suppose that an upgrade from AutoCAD 13 to 14 is a unit of technology enhancement effort (TEE). How many TEEs a year can companies afford. How many TEEs is worth an introduction of a commercial document management system? How many TEEs is the implementation of a state of the art integrated environment created in a multimillion EU project? How much overhead can they swallow to adopt a new technology? What should be investment return rate e.g. after how much time would the time invested in installing and learning a new technology return in time savings due to using the technology? Yes, computer assisted learning can speed up the learning process but without clear answers to the above questions, we don't know by how much. Intuitively it seems that due to the nature of the work, construction industry is very demanding in these matters. Evolutionary technologies that would build on existing knowledge and ones that would have a clear upgrade path would have an edge over revolutionary ones.

CONCLUSIONS The relative price of basic raw materials in civil engineering, such as steel and cement, has been steadily falling. On the other hand, the price of human work, in particular intellectual information oriented work has been rising. Information technologies have the potential to assist the information processes. There are several problem areas in engineering, where one or other technology could be applied. However, in order to get results, engineering process, as a whole, should be observed and human work, as such, better understood. In the past, the expectations from IT have been too optimistic, because the nature of engineering work was misinterpreted. For example, expert systems did not deliver the expected results and, so it seems, the product modelling approach is reaching its limitations as well. In the paper, the author has tried to show the potential, scope but also limits of information technologies. For most problems, a traditional, not electronic approach has existed for centuries. The analysis showed that product and project information form an important yet incomplete target area for IT application. Engineering processes can and should be modelled as business processes - integrally covering all facets of human work. Current directions of construction IT have been focusing on products, processes and state of the art technology. Research methodology was shaped on that of the hard sciences. Future directions of construction IT should include the human - the engineer, the architect, the technician - who is supposed to be assisted by the technology and who designs, engineers, learns and interacts with other humans. Objects of study are soft, second order entities. REFERENCES Augenbroe, G. (1999). Private discussion, Vancouver, 1999. Bjoerk, B-C. (1996). Information technology in construction, Proceedings of the CIB-W65 symposium, Glasgow. Bjoerk, B-C. (1999). Information Technology in Construction: Domain Definition and Research Issues, CIDAC, Vol. 1, No.1. Brandon, P. and Betts, M. (1997) Veni, Vidi, Vici; in Brandon P and Betts M (editors), The Armathwaite Initiative, ISBN 1-900491-03-6, University of Salford, UK. Champion, D. (1967). A proposed unified schema for AEC information vs. transaction-centered multi-schemas, Architectural Design. Dye, J. (1996). Socratic Method http://www.soci.niu.edu/~phildept/Dye/method.html and Scientific Method,

Fenves, S.J. (1991). Status, Needs and Opportunities in Computer Assisted Design and Analysis, Structural Engineering International, 2. Fenves, S.J. (1996). Information technologies in construction: a personal journey, in Z. Turk (editor), Construction on the information highway, ISBN 961-6167-11-1, CIB Publication 198, University of Ljubljana, Slovenia, pp. 20, http://www.fagg.uni-lj.si/bled96/ Hannus, M. (1996). Islands of Automation in Construction, in Z. Turk (editor), Construction on the information highway, ISBN 961-6167-11-1, CIB Publication 198, University of Ljubljana, Slovenia, pp. 20, http://www.fagg.uni-lj.si/bled96/

Heidegger, M. (1962). Being and time, Harper & Row. Koskela L (1992). Application of the New Production Philosophy to Construction. Technical Report # 72. Center for Integrated Facility Engineering, Department of Civil Engineering, Stanford University, 75 p. Kuhn, T.S. (1962). The Structure of Scientific Revolutions, Univ of Chicago Press, Chicago, USA. Medina-Mora R, T Winograd and P Flores (1993). Action Workflow as the Enterprise Integration Technology, Bulletin of the Technical Committee on Data Engineering, IEEE Computer Society, Vol. 16, No. 2. Mentor Group (1997). The role of http://mentorgrp.com/pubs/mrrison.htm IT in business process re-engineering,

Schutz, A. (1962). Common-Sense and Scientific Interpretation of Human Action, Collected Papers, Vol. 1: The Problem of Social Reality, Martinus Hijhoff, The Hague, Netherlands. Schn, D.A. (1983). The Reflective Practicioner - How Professionals Think in Action, Basic Books, UK. Simon, H. (1972). The Sciences of the Artificial, MIT Press, Cambridge, MA. Turk, Z. (1996). Internet as a Construction Information Technology, lecture at Information Technology in Construction, Taking Stock and Future Directions, International Conference, Glasgow, Scotland, August 14-16, 1996, http://www.fagg.uni-lj.si/~zturk/papers/glasgow.96/ Turk, Z. (1998). On Theoretical Backgrounds of CAD, in Artificial Intelligence in Structural Engineering, Springer, 1998. Winograd T and R Flores (1987). Understanding Computers and Cognition, Addison-Wesley.