Information technology-enabled BPR in the construction industry

Knowledge and Process Management Volume 5 Number 3 pp 172–184 (1998)

" Case Study

Information Technology-enabled BPR inThe Construction Industry

Paul Hayes*, Yacine Rezgui, Grahame Cooper and Natalie Mitev

University of Salford, UK

The paper gives a comprehensive overview of the European ESPRIT Condor project. The project aims atbridging the gap between current information systems and future ones, and provides a migration path fromdocument-based, to model-based approaches to information representation and structuring. After a briefoverview of the project’s aims and objectives, the paper gives the state of the art of electronic documentmanagement (EDM) systems in the construction industry, followed by a description of the three legacy EDMsystems used within the Condor project. A strategy towards the integration of these systems is then given.The paper presents the overall Condor system architecture and discusses how distributed object technology(through the use of the architecture) can be used as a powerful instrument to potentially facilitate there-engineering of business processes within the construction industry. The project is ongoing and supportedby a user interest group, which involves representatives from a variety of non-construction industry companiesall over Europe. ? 1998 John Wiley & Sons Ltd and Cornwallis Emmanuel Ltd.

INTRODUCTION

Industrial processes are characterized by the intensive useand production of knowledge and information. Most of thisknowledge and information, even when produced usingcomputers, is still exchanged and conveyed on a paper-based medium. This can be viewed as a limitation topotential opportunities for construction process innovationas information is constrained by what can be achieved usingpaper. In fact, the format and layout of most documents wasshaped before the proliferation of personal computers, andhas not yet changed in response to more recent ITdevelopments. There is a growing demand on flexibleinformation systems that are flexible enough to accommo-date continuous business process improvements. Thesesystems must support the complexity needed for increas-ingly finer levels of granularity of information context,content and structure. However, even if many internationalstandards have been developed to solve information prob-lems within separate business sectors (STEP: ISO 10303and SGML: ISO 8879), the problems of enterprise-wideinformation compatibility remain.

CCC 1092-4604/98/030172-13$17.50? 1998 John Wiley & Sons Ltd and Cornwallis Emmanuel Ltd.

In the construction process, there are diverse and com-plex information flows (using documents) between actors.These documents need to be highly consistent in order toprovide a reliable basis for actors to perform their design,construction and maintenance activities. Document manage-ment has become a crucial issue within modern constructioncompanies. The various solutions proposed by some soft-ware vendors have been revealed to be unsatisfactory, to apoint where many leading construction organizations, withan advanced IT department, have undertaken the develop-ment of their own tools and solutions to support theproduction and maintenance of project documents. Eventhough such proprietary tools provide many helpful facili-ties, including support for document storage, retrieval,versioning and approval, they don’t handle any semanticsof the information being processed and therefore remainlimited in their support of the end-user. In fact, constructionproject data and documentation (including full specificationdocuments) constitute two fragmented information sectorswhere compatibility and interoperability are mostly needed.Moving these pseudo-sectors closer together to supportconstruction project documentation as part of the life-cycleof the building product is becoming an actual and urgenttopic for standard bodies and industry alike.

In order to pioneer a solution, the European ESPRITCondor project, which involves a consortium driven by

*Correspondence to: Paul Hayes, Room 24, Venables Building, InformationTechnology Institute, University of Salford, Salford M5 4WT. E-mail:[email protected]

CASE STUDYKnowledge and Process Management

construction end-users, is investigating a new model-based—as opposed to file-based—approach to documentproduction and management, based on recent IT develop-ments. One aim is to demonstrate the genericity of theapproach, and its applicability across industries. The consor-tium is aware of the fact that it is not possible to develop aunique document management solution for all the members,because of their investment in proprietary systems. TheConsortium is promoting the use of the various existingsystems, as described below, by the development of exten-sions which comply with the proposed approach. Theseextensions will enable all systems to communicate, and haveaccess to advanced Condor functionality, through adedicated Application Programming Interface (API) beingdeveloped within the project.

The paper presents a means of bridging the gap betweenthe traditional document-centred and the proposed (model-based) approaches to project information structuring andrepresentation. Robust models supporting this transition arebeing developed, together with a prototype implementationwhich demonstrates a proactive use of document manage-ment and information management techniques in acollaborative multi-actor environment. The paper alsodemonstrates the reengineering efforts which have tobe imposed on the organization (people, processes,technology) to cradle this transition.

THE EUROPEAN ESPRIT CONDOR PROJECT

The construction industry needs information structureswhich will give construction project participants increasedaccess to consistent project information. This requires aninfrastructure which brings together information processing,information storage and retrieval, information transmissionand the information content itself. In order to address thiswide scope, the Condor project is driven by the needs ofusers and the market, through the expertise of KvaernerConstruction, JM Bygg, Derbi and Cap Gemini, and benefitsfrom the combined expertise of the other project partners(University of Salford, CSTB and KTH). The main project’sobjectives are summarized below:

- Provide opportunities for new processes and new formsof project organizations to be used on constructionprojects.

- Improve document quality and consistency throughoutongoing projects.

- Increase accessibility of project information to all partici-pants in the process, and allow small to medium-sized enterprises to be more closely integrated intoconstruction projects.

- Define the process changes required in order to realizethe benefits of integrated document management.

- Identify organizational and cultural issues impacting onthe adoption of integrated document management andpropose ways of addressing these.

BPR in the Construction Industry

- Integrate document-based (‘black-box’) and model-basedapproaches to project information management.

- Provide a migration path and strategy for moving fromdocument-based to model-based approaches.

- Integrate more closely document types and represen-tation (e.g. text and drawing).

- Investigate the distribution of documents using differentlevels of network capability.

- Demonstrate the integrated use of existing standards formessaging, product modelling, etc.

In order to tackle these objectives effectively, a number ofwell-defined research topics are being addressed:

- Development of a highly generic Condor informationmanagement model which handles various issues includ-ing object versioning, actor’s rights and responsibilities,and change notification.

- Development of techniques to define the semantic linksacross the various forms of document- and model-basedinformation.

- Gaining understanding of the organizational and culturalaspects of introducing the document production andmanagement proposed approach (in terms of people,processes and technology), into small, medium-sized andlarge industries and organizations.

The Condor project objectives are roughly addressedthrough five complementary topics, from which the structureof the technical work breakdown is derived. These topicscomprise: document management, migration strategy to themodel-based approach, business process reengineering withrespect to the changes introduced by the proposed approach,specifications and delivery mechanisms, generalization of theapproach to other industries and results dissemination.

THE IMPERATIVE FOR BPR IN THECONSTRUCTION INDUSTRY

Organizations within the construction industry arerestricted by the technologies and processes thatsupport their infrastructure and have a reluctance toalter their current state, in fright of invoking undue organi-zational change(s). Moreover, current practices depend toomuch on legacy systems that do not exploit the capacity tobetter represent, structure and integrate information. Theneed for improved information structuring, representationand integration is becoming critical to survive thistechnological era.

As a consequence of this need, construction actors,the technology they use and the processes that they operatewithin, must also be changed to complement theCondor approach, as described in the Introduction. Thiscan only be achieved through some form of BusinessProcess Re-engineering (BPR) effort on existing (electronic)document management systems (EDM).

173

Knowledge and Process ManagementCASE STUDY

BPR is a way of transforming the business, to free it fromthe restrictions of the traditional approach by cutting acrossfunctional divisions (Butler Fox Foundation, 1993). It is aninnovative approach to achieve breakthrough improve-ments in performance measures (Teng, 1992), through thefundamental rethink of business processes (Davenport,1992).

Processes

As the name suggests, business process re-engineeringplaces much emphasis on existing processes within anorganization, so as to redesign or change their existingstate. A process is ‘a structured, measured set of activitiesdesigned to produce a specified output for a particularcustomer or market. It implies a strong emphasis on howwork is done within an organisation’ (Davenport, 1993).Davenport and Short (1990) define a business process as ‘aset of logically related tasks performed to achieve a definedbusiness outcome’. To redesign the processes that make upelectronic data management systems, we must understandthe type and composition of such processes. This sectionexamines current construction processes that encompasscurrent EDM systems and provides a detailed example ofone such process.

Processes that encompass current EDM systemsExisting EDMs that are in place within a number ofEuropean companies operate under different regimes, codesof practice, and computer platforms and adhere to variousformulate standards. However, unique processes and ser-vices that constitute these EDMs offer similarities acrossorganizational boundaries. An example of this existsin document categorization, archiving, request and approvalfor information procedures. The genericity of theseprocedures and services are modelled in this section(Figure 1).

The document management services that are providedare a conglomerate of processes, made up of a collection offunctions; each tailored towards clients needs. Nonetheless,such management services link contracts, businesses anddocuments. Below is a generic model of services that areprovided by existing (electronic) document managementsystem(s).

Figure 1 depicts the generic make-up of such systems—astandalone or integrated ‘Binder’ catalogue system, coupledwith an integrated or isolated collection of automated ormanual document management procedures, complementedby a set of supplementary (though not secondary) searchingand ‘housekeeping’ functions.

The storage & archive document process is as the namesuggests. The classification process is a means of registeringthe document with the EDM system and placing thedocument into a predefined category, i.e. Financial, Admin-istrative, etc. The change request process involves the

174

request and approval of amendments to be made todocuments and drawings, currently stored in the EDMsystem. Approval of sub(contractor) documentation anddrawing control process involves the acceptance of aliendocuments and drawing files into proprietary systems.Correspondence control manages all incoming and out-going electronic mail to and from the EDM system. Thefunctions are specific procedures which are aided by andsome of which are carried out within the processes alreadydefined.

Current EDM processes: An exampleTo show the differences (and/or similarities) between thecurrent and re-engineered state of an existing process, oneof the above processes is taken for illustration, i.e. Informa-tion Request Process, in regard to how this is initiated, dealtwith and answered. A generic layout of this process hasbeen provided, as shown in Figure 2.

The request for information is passed through anumber of hands, across a number of tasks in a serialfashion. Each task in this process is self-explanatory anduses a certain amount of resources within a particular timeframe. A detailed description of this process is providedbelow.

From the Information Request Process several conclu-sions can be drawn. Division of labour is apparent here asseveral actors carry out several different tasks, i.e. the resultsof one task are fed as input into another task, operated onby a different actor. Trade-offs of responsibility and infor-mation are evident—the tasks are visibly segmented. Forinstance, the actor responsible for initiating the requestrelinquishes the responsibility to another actor, who com-piles and sends the request. The passing on of responsibilityreflects the isolated tasks in which this occurs. Actors’activities are restricted by the performance of another, e.g.an administrative officer cannot compile and send a requestuntil the structural engineer has fully completed a requestform.

The Information Request Process is one among many, themake-up and characteristics of which are mirrored in otherprocesses, i.e. several segmented tasks operated upon byvarious actors.

(Inter) organizational impact

Below is an analysis of the possible problems and advan-tages of a BPR endeavour, as a consequence of imposing theCondor systems architecture on existing (electronic) docu-ment management systems and hence the resulting pro-cesses. The main area of focus is the processes andconstruction actors, since change (if any) will have a majorimpact on these companies’ most powerful constituents.Construction actors possess a psychological/cognitive mapof their activities and they apply physical means to performtheir task, within a given construction project. This section

P. Hayes et al.


Figure 1 Genericity of current document management services

aims to address the re-tuning of actors’ thoughts andworking style, to coincide with the redesign of existingmethods of working with current EDM systems.

Construction processesTo manage change effectively, organizations should andmust alter more than just a single component of theiroperations and processes, technology and people (actors)should be given equal consideration (Towers, 1990). Thissection addresses how and the extent to which currentconstruction processes will be redesigned as a result ofincorporating the Condor systems architecture. The pro-cesses most affected will be those that involve cross-company communication of information exchange, e.g.information requests. However, the ethos of Condor is themigration from document- to model-based approach and


other processes that operate within the internal use of theEDM system would also see change. This section providesan example that will illustrate the process transformation(s)that will take place and the resulting impact.

Figure 3 illustrates the existing way an actor requests andreceives documents across companies (the InformationRequest Process) in relation to the new way which will beoffered by the Condor Integrated Services. The currentmethod shown in Figure 3 is a generic outline of theInformation Request Process in Figure 2. It provides ascenario whereby a structural engineer in company Arequests supplementary document information about anarchitectural design, held by company B. Current methodsthat deal with such a request begin with the compilation ofthe request, which is usually in the form of a completedrequest form. The request is sent electronically or by post

175


Figure 2 Tasks in an Information Request Process

and this requisition may (not) be registered by company A’sdocument management system.

Company B receives the request and uses whatevermeans necessary to deal with the request (interaction withinternal EDM system), in terms of finding and retrieving theappropriate document from their database or other filingmechanism. The requested document is then sent to com-pany A (whether by e-mail or other means) and this may(not) be logged as an event in their proprietary system.There exists a bureaucracy layer between both companiesthat is fed by different company identities, cultures andtraditions. This incurs time delays and consequent processdeficiencies, as well as being prone to confrontations,misunderstandings and errors. This layer is in fact a barrieror firewall which is established to isolate organizationalinternal operations and workings from outsiders. TheCondor will attempt to fuse the sharing, structuringand representation of such information across companies,

176

through a standard constructed in agreement with theconsortium end-users.

Using the new re-engineered method will cause thecurrent method to disappear. This process of requestingfurther information is now reconfigured in the new method,as a result of the Condor API (as an interface to the CondorIntegrated Services). The bureaucracy layer is removed ascompanies A and B adopt the Condor approach to integratedocuments, providing easier and faster access to relevantinformation. As a result, the request for informationbecomes an automatic and instant transaction (as shown inFigure 3), compared to a slow and bureaucratic process, asseen in the current method. In the new method, thestructural engineer can begin the request process by simplyand quickly using one of the Condor service functions toaccess the proprietary systems in company B and acquirethe appropriate document(s). The search and retrievalservices will actually be performed by proprietary EDM

P. Hayes et al.


Figure 3 Changes in inter-organizational information exchange

systems. To the user, however, these functions will seem tobe executed by the Condor API.

Current and redesigned Information Request Process: acomparisonCompared with the traditional approach (current method),the Condor approach will try to reduce this bureaucracy.The Condor Integrated Services will contain a number ofautomatic service functions, i.e. FindDocument, RetrieveDocument (through the Condor API) to perform and succeedin achieving the same outcome (as shown in Figure 3) as the‘division of labour’ approach which currently exists (Figure2). For example, administration tasks are removed, author-ization may be replaced by knowledge-based reasoning andthe sequential flow of manual tasks are eradicated. Table 1outlines the major differences between the current process(current method) and redesigned process (new method).

Process redesign problems, risks and benefitsThe example of the Information Request Process is not justan illustration to show change due to the automation oftasks. The adoption of a model-based approach for betterinformation structuring and representation will disrupt thebehaviour and pattern of how processes carry the flow


of information. This will become more apparent asin-depth research into these processes will reveal disruptionpossibilities.

In terms of construction processes, the benefits of theCondor approach are numerous. Time delays and informa-tion discrepancies are dramatically reduced. Informationbecomes transparent and its distribution and effective use isnot restricted by its structure and organizational red tape.Scheduling of activities are improved as the redundancyin resources (people and tasks, etc.) are removed (refer toTable 1). Time to market (through the use of an effectivemodel-based EDM system) is increased as a result ofimproved project management within organizations,achieved through better communication and informationintegration.

The risks involved are real and may invoke the totalupheaval of conventional ways of working, to accommo-date new technologies and a new collaborating environ-ment. The real impact of new technologies in theconstruction is still in its infancy. Construction companiesmust make available appropriate resources to managechange to their processes, in terms of expertise, so as toprevent the migration to the Condor approach havingadverse effects.

177


Figure 4 An actor’s pattern of work

Construction actors

- An actor’s pattern of work. Construction actors have acertain way of thinking about project tasks, a way ofworking to perform tasks and a way of controllinginformation flows and activities within a defined process(see Figure 4). For example, a way of thinking about atask is an actor’s mental map/model or a predefinedpicture of the duties to be performed and the real-worldobjects that support them (in terms of resources, such aspeople, technology and information). This map is shapedthrough their education and social background or tradi-tions and experience gained over time. A constructionactor’s way of working is a method, i.e. codes ofpractice, or personnel guidelines and custom, which areapplied through this image to a given duty (or set ofduties), regardless of whether it is structured or ad hoc. A

178

way of controlling is the management of this methodthat directly affects the outcome of the task (the extentto which the method is applied to influence a givenactivity). The following provides an example of how anactor’s pattern of work could change as a result of theCondor approach.

- Changes to an actor’s pattern of work: an example in construc-tion. In the use of current CAD packages, buildingdesigns drawn by architects or other actors are made upof lines and other symbols that have no semanticmeaning. Actors work on this basis and perceive thesedesign elements as nothing more than an aggregation ofcomponents that just represent some part/all of a build-ing outline. To build these designs, an actor conforms toa set of predefined rules and practices that are dictatedby the make-up of a particular CAD package. Thesuccess or outcome of the design is dependent upon theeffective use of these rules to produce a desired outcome(control of the rules). A scenario can be provided,whereby an architect makes competent/comprehensiveuse of these rules and other guidelines rather thanelementary use, to construct a better design.

In a semantic CAD package* every time a new line isused (to represent part of a design) a wall object is

Table 1 Current versus new method in the Information Request Process

Current method New method

Number of actors involved More than one One

Number of tasks involved Several One (compile request through the Condor API)—the othertasks in the Information Request Process are automated andhuman intervention becomes redundant

Locate document time Hours/day(s) Minutes

Access document time Day(s) Instantaneous—once the document has been located. This,however, is dependent upon the efficiency of the transmis-sion link, from the appropriate proprietary system to thelocal user

Checking and approvalof document

Tedious process. The document has tobe manually checked and then subjectedto an approval process for release

Accuracy in checking and obtaining the requested docu-ment(s) is dramatically increased; since the Condor serviceswill provide adequate facilities for registering and searchingfor documents. The approval of documents to be released forother company use could disappear with the closer sharingof integrated information

Resource overheads Bureaucratic, division of labour, costs intime delays and manpower overheads

Minimized: one actor—one task approach

Scheduling Prone to errors. Trade-offs and taskscauses delays and discrepancies

Task boundaries are removed, scheduling the request processaround others becomes redundant. Thus, scheduling of thisprocess around other is improved

*A semantic CAD package treats every element in a construction design asa real object (wall, door) which has dimension and meaning. Additionally,it treats documents as a ‘white box’, whereby a document has structure(paragraphs, headings) and that any such object can be linked within anyfragment of that document.

P. Hayes et al.


Figure 5 Semantic versus traditional CAD packages

instantiated and this may be semantically linked to anysegment of a text document that describes that wall.Thus, an actor does not just draw a line on a CADpackage but creates a new object, which is automaticallylinked to information describing this wall, in a section orparagraph, etc. within a document (Figure 5). Hence, anactor’s pattern of work will have to change to reassoci-ate their thoughts and behaviour in how they view thestructure of information and how it is represented; themethods they apply to work with the information andthe control of these methods to deliver a desiredoutcome.

- Changes to the treatment and handling of information. In-formation that is handled in a process, whether it is aCAD drawing or text document, is viewed and treatedin a predefined fashion, according to organizationalrules, experience and individual judgement. For instance,in current construction projects, building designs aregenerated according to very particular rules and guide-lines, controlled through an actor’s behaviour, as well asthe limitations and exploitation of a particular CADpackage. It is through the daily iteration of behaviouralpatterns that a mental map of how information ishandled and treated, materializes. Text documents aretreated and viewed in the same way. Documents arecurrently ‘black box’, which means that the structure andmeaning of information which resides within a documentmanagement system(s) is disregarded. With the Condorapproach, information representation and structuring


will see a revolutionary transition; the structure andmeaning of the information will be paramount. Forexample, the use of design elements (lines and symbols)within a CAD package will instantiate real objects (wall,door, etc.) that have a semantic meaning; documents willbecome ‘white box’, such that they will have a definedstructure (i.e. aggregation of sections, paragraphs, etc.).

In summary, the way information is represented andadministered at present will see a revolutionary change.This change will affect not only information but con-struction actors as well. The migration path from adocument-based to a model-based approach will causean actor’s pattern of work to be re-engineered, i.e. he orshe will have to view the representation of informationdifferently. The way actors interact with the informationand how this interaction is controlled must also bereformed (refer to example above). The new model-based approach will cause actors to adjust to the use ofinformation using new rules and codes of practice, thus,invoking a large shift in how they perform tasks thatoperate on the information, within a defined process.

- Possible induced benefits and hindrances to the Condor archi-tecture implementation. It is unlikely that an actor’s jobtitle will be altered or a new job created in there-engineering processes; even though the method ofsharing information is changed, an actor’s underlyingobjective will remain unchanged. Only if an actor isemployed specifically to request and receive documents(the manual administration of outgoing and incoming

179


correspondence) that alteration or removal of an actor’srole will be witnessed. This can be the case for otherroles of a similar nature. Nevertheless, it is more likelythat specific tasks that constitute an actor’s role willalter (removed or amended) than the whole role itself.However, depending upon the personnel hierarchicalstructure of the organization that interacts with docu-ment management systems, regrouping of actors may benecessary to complement new or adjusted processes thatmay be implemented. It must be considered that differ-ent organizations may have different structuring of theirpersonnel and it is important to consider a possiblediffusion of this structure as a consequence to changes toan actor’s role. On-going research with the consortiumwill recognize in detail the groups at risk.

Accommodating the Condor systems architecturemay bring many benefits to construction actors and,consequently, organizations. With the adoption of newtechnologies such as this, the workforce will becomemore skilled and IT aware, as a result of the Condor APIand the training that will be provided. Additionally, theywould become less frustrated by the burden of bureauc-racy that exists within current operations of informationexchange (refer to Figure 3). Inter-organizational rela-tionships will improve as the sharing of integratedinformation will support the foundation for better com-munication cohesion. This may also be witnessed at anactor level across companies. As a result, workingpartnerships and actors’ moral may be effected andbetter buildings being constructed as a result of coherentcooperation.

Training and communicationsThe implementation of the Condor systems architecture willlead to the retraining and reskilling of construction actors.Reskilling will entail adapting to new technologies and tonew ways of working. The greater the level of change theorganizations sustain, the greater the impact of training willbe (PA Consulting, 1992). In the manufacturing industry forexample, the installation of a completely automated materialhandling process will affect front-line production workersand have a knock-on effect on maintenance staff, productionmanagement and production engineers. Organizations mustbe wary and address their type of training culture (as part ofa larger, corporate culture) before investing in a trainingeffort. PA Consulting claims that companies feel retrainingis like a light that can be switched off and on and that afterthe (successful) implementation of a major programme (i.e.Condor systems architecture) there is no need to sustain alarger training effort. Such attitudes may not thrive if thereis a prominent training culture and organizations will haveto define some form of ongoing training initiative for theCondor approach.

Towers (1990) prescribes that ‘to change the technologywithout retraining will not result in benefit . . .’. Indeed, thisis a price organizations will have to pay to comply with this

180

new technology. New additional features which will need tobe added to proprietary systems will cause actors to relateto new interfaces and devices, i.e. Condor API, newcomputer software and hardware. Traditional methods ofgathering and sending information across companies (Figure3) will become obsolete because of the new services offeredthrough the Condor systems architecture. This will result ina shift in inter-organizational communications as traditionalmethods of communication become legacy. Additionally, itwill result in actors not only performing something differ-ent, but doing it differently, i.e. work will be performed in adissimilar fashion using alternative tools.

Though proprietary systems will see minimal change, theway information requests will be dealt with across organi-zational boundaries will completely change and this changewill be dependent upon the make-up and services offered byCondor. For example, a GetDocument function could existwithin the Condor API. This will make a call through theEDM adapter (Figure 1) to the proprietary documentmanagement system (from the same or another company)which will automatically locate and retrieve the appropriatedocument from the database(s) to an actor. This can becompared to existing methods of locating and requesting adocument, as shown in Figure 3.

The following factors will determine the extent to whichan actor’s pattern of work will change and associatedprocesses:

- The amount of alterations made to existing proprietarydocument management systems. Actors will have toembrace new technologies and become dependent uponthem.

- The implementation approach to use and integrate theCondor systems architecture into existing system(s)(implementation approaches are described in the nextsection). The magnitude of change will depend upon theamount of reskilling and retraining needed to relateexisting patterns of work to one which is required.

Implementation methods to the Condor approach

In the construction industry the issue is to identify thepossible impact of the Condor architecture on existingdocument management systems and the BPR efforts thatwill need to be imposed on the organizational set-up (interms of people, technology and existing EDM businessprocesses) to accommodate this. The nature of the impact isvery much dependent upon the method of implementationas well as the nature and scope of change. The implemen-tation of the proposed architecture would cause lessorganizational upheaval (processes, tasks, activities, etc.) ifthe existing processes are incrementally changed than if a‘clean sheet’ approach or obliteration of current processes isadopted. Peppard and Rowland (1993) assert that ‘fewcompanies actually succeed in implementing totallynew processes in existing operations’. However, Hammer

P. Hayes et al.


(1990) indicates that an all or nothing exhaustive approachshould be taken. Nevertheless, many practitioners andacademics alike would argue that the differences betweenincremental and radical change are rather blurred in practice.

There are different kinds of approaches to implementa-tion and these are described below. Two main approachesdetailed there are systematic redesign, as illustrated byPeppard and Rowland (1993) and Towers (1990) and aradical (clean sheet) approach. The aim here is to estab-lish and conclude which type of approach would suitthe migration path from document-based to model-based approaches for representation and structuring ofinformation in the construction sector.

Systematic redesignPeppard and Rowland (1993) advocate that this approachwill identify and help understand existing processes andthus enable their systematic redesign and creation of newprocesses. The approach can be seen as starting with thecurrent live processes that constitute the (electronic) docu-ment management system and work through them eliminat-ing waste, while simplifying and integrating tasks and,where appropriate, automating activities. Systematic rede-sign allows for change to be made incrementally. Changecarried out in small chunks reduces disorder and risksinvolved (Peppard and Rowland, 1993). Davenport (1992)and Fried (1994) follow the same school of thought, whoseek high-impact results, by tackling a ‘chunk’ at a time.This can be compared with Harrington (1991), who advo-cates undertaking a manageable number of projects. Underthis ‘chunk-at-a-time’ scenario, identifying the opportunitiesand selecting what to attack, are key issues. Robin (1991)offers some broad guidelines for selecting what to attack:

- Select clearly dysfunctional processes- Attack simple problems first- Pursue quick-to-implement changes- Identify easy-to-measure results

There are mixed attitudes about this approach in theconstruction industry. Systematic redesign is an evolution-ary as opposed to revolutionary approach. The Condorproject aims to revolutionize the way information is struc-tured and represented and calls for closer integration ofinformation. Many construction managers may feel that theneed to implement this ideal is required sooner rather thanlater. Others would prefer to implement these aims over along time period, than use the Condor systems architectureas a ‘tool kit’ for a quick fix. The problem is that companieslike to see the benefits for their investment at an early stage.A slow migration from a document-based to a model-basedapproach to better represent and structure information willreduce risks, but it is argued here that this will yieldmoderate benefits, as opposed to quantum leaps in arevolutionary approach (clean sheet). The intricate nature ofthe construction industry would best support and suit asystematic incremental approach in the implementation of


the Condor revolutionary concepts (the Condor systemsarchitecture).

Clean sheet approachAccording to Peppard and Rowland (1993) the clean sheetor revolutionary method brushes away the implicit tradi-tional concepts embedded within current existing processesand allows for a ‘fundamental rethink in the way businessesare conducted’. This notion is mirrored in Hammer’s (1990)theory, ‘don’t automate, obliterate’. This suggests thatinstead of embedding outdated processes in silicon andsoftware, we should start over, by obliterating them. Theclean sheet approach urges that new processes should bedesigned from scratch, aiming at desired outcomes of theprocesses and working back from these.

There are several ways of implementing a clean sheetapproach in practice and these are described below:

- Greenfield site (Towers, 1990; Davenport, 1993, 1994)The greenfield site is one approach to clean sheetimplementation and refers to the implementation of newdesigns by opening a new location. This is the mostconvenient and easiest way, but such new sites (creatingan entirely new business unit) can be expensive. It is alsoseen as BPR at its finest, i.e. the deliverance of a neworganization without inheriting the complications of thepast. Organizations of this kind can run in parallel toexisting ones. There are many problems with adoptingthis approach for the implementation of the Condorsystems architecture. The construction industry is unlikeany other, since it consists of a number of multi-disciplinary teams across a number of construction sites,collaborating within a multi-organizational environment.Setting up a parallel site would not be economical.Construction companies would find it hard to justify theexpenditure and the amount of effort that this wouldentail as well as the coordination and management ofresources (people, technology) to facilitate a new site.

- Pilot approach (Davenport, 1993) An alternative to thegreenfield site approach is the technique of the creationof pilot and phased introduction. Based on a certain setof customers, product or geography, the pilot approachis an entirely operational implementation of a newprocess in a comparatively small unit of the organiza-tion; but performed on a smaller scale. The pilotapproach may be followed by a phased introduction.This will allow for the implementation of up-to-datetechnology, skills and new systems capabilities to beimplemented as soon as they are available. Constructioncompanies may see this phased approach as financiallyviable and more practical, so that they can deriveeconomic benefit from the process change earlier thanmight otherwise be possible. The migration to themodel-based approach can be set up instantaneously,without affecting real on-line processes. This small-scaleclean sheet approach will identify the possible problems

181


with the implementation of the Condor architecture. Itwould be like rebuilding the engine while the car isrunning (Towers, 1990 as opposed to Scrupski, 1994,who claims that management information systems (MIS)cannot implement BPR while simultaneously offering theBPR services of their company). However, constructionactors may feel a sense of instability and variable changewithin the company, causing difficulty for some actors toaccept this pilot approach. Considerable overheads andstringent use of resources may be visible at first whenembarking on redesign process, but the anticipatedbenefits of this approach will overshadow the illusionthat this is a costly endeavour.

Systematic versus clean sheetTable 2 provides an overview of the major differencesbetween the redesign and clean sheet approach in theimplementation of the Condor systems architecture.

If construction companies have the right vision, attitudeand commitment to break away from the status quo thenthe pilot clean sheet approach is recommended. It is arevolutionary but cautious approach, since it abandonscontinuous thinking in the systematic approach but accom-modates the precaution of current processes not beingaffected until much later in a redesign activity.

Nevertheless, whichever approach is chosen for theimplementation of the Condor systems architecture, it isessential to ensure that the analysis of current processes thatmake up and encompass (electronic) document managementsystems are not overdiagnosed; though the risk of this isgreater in the systematic redesign approach. Greater con-sideration should therefore be paid to new processes thanthe old, which are merely a starting point.

182

Traditions and culturesThe implications of implementing the Condor architectureusing one of the above approaches are not restricted toconstruction actors and processes. Some companies mayexperience many of their traditions and traditional customsbeing tampered with. A tradition can be seen as an actionthat has always been performed in one particular unique anddefined way, since the creation of that action. For example,a company may have always responded to an informationrequest with scrutiny and in a very formal, structured andmeticulous fashion. The Condor architecture may provoke adilution of such traditions, and remove and instantiatenew ones. Generally, traditions are very hard to modify.Companies should assess these and be wary of how thearchitecture may (not) affect them, to prevent undue agita-tion among actors. Resistance to cultural and businesstradition changes is a major challenge at succeeding at BPRand this is what two thirds of respondents cited, in a 1993study of BPR that Delphi Consulting reported (Radosevich,1993).

There is also a risk in changing organizational culture. Acompany’s culture is in the thoughts and minds of companyactors through a self-reinforced network of beliefs andshared values (Rouse and Watson, 1994), which take theform of rules and behaviour (Peppard and Rowland, 1993).It is a mix of approaches, attitudes and behaviours whichcontribute towards reaching a common objective. Accord-ing to Orgbonna (1993), company culture is the values,beliefs and customs that an individual holds in commonwith members of a social or unit group. Organizationalculture is shaped by experience gained over time based onwhat does and does not work. Such a culture may see adisturbance, as closer sharing of integrated information

Table 2 Systematic redesign versus clean sheet (Hayes, 1995)

Dimension Systematic redesign Clean Sheet

Time scale Organizations implement performance improve-ments in the short term

Organizations develop new ways to competein medium to long term

Philosophy Tends to adopt incremental change overtime—moving to continuous improvement

Radical thinking, with radical changes—bearingno regard to existing conditions

Risk factor Moderately low (yields smaller and smaller benefitsover time)

Significantly high (significant and substantialbenefits in long run)

Improvements in performance Significant step changes Quantum leaps

Target success Continuous incremental improvements can makeconsiderable gains

Large-scale projects fail to achieve all targetsset for them at the start point

Understanding existingprocesses

High danger of ‘overdone’ analysis There exists a threat of in-depth examination ofcurrent processes

Preference in approach Japanese manufacturers tend to be more incremen-tal and continuous because of the relative stabilityof their economy

US and European companies tend to adopt thistechnique—the message of radical change ismore appealing. Violent economic swings bringforth the urgency for radical improvements

P. Hayes et al.


forces a shift of organizational boundaries within a construc-tion project. For example, in the past, companies may haveadopted a very secretive belief and competitive behaviourof how information was handled for a given purpose. Closerinformation integration will see changes in this belief andbehaviour.

As culture influences the behaviour of constructionactors, changes such as this will see a difference in attitudesbetween companies within a construction project, asinter-organizational communication methods are greatlyimproved for handling the management of documents.Culture operates at every level within an organization andcan be a cause of friction when two different cultures comeinto contact with one another. Kotter and Heskett (1992)propose two levels in which cultures exist and differ interms of their visibility and resistance to change. Thus, aswe migrate from the status quo (separate independent EDMsystems) to cohesive inter-organizational integrated infor-mation sharing, organizational cultures and traditions mayalso migrate and propagate within other company environ-ments. Companies should be vigilant of the possible risks ofculture migration and its penetration through organizationalfrontiers. The success of culture penetration could bedependent upon the following:

- Make-up of the migrating culture (A) and the targetculture (B) within another company

- Culture B’s characteristics and the extent to which it willchange as a result of this migration

- Will culture B partially or fully embrace culture A toform a hybrid culture C? Will culture B die, co-exist withculture A or will it become unstable?

- Culture A is rejected, as a result of a complete cultureclash.

As we see a change in the way information is shared, theapproach and attitude (culture) towards the use of theinformation will change also. Actors may experience ashock reaction to new culture and according to De Cieri andDowling (1994), this may cause psychological disorienta-tion because an actor does not recognize the new environ-mental cues. Towers (1990) indicates that ‘to change theculture without providing better tools to do the work willnot be successful’. Services offered by the Condor approachmust allow a company’s culture and tradition to adapt andchange in a positive way. Like processes, culture must bealigned to the strategy of an organization and managedwhen changed is required (Peppard and Rowland, 1993).Proficient tools and culture are just two ingredients inhelping deliver closer integration of EDM systems andinformation.

CONCLUSION

This paper has presented the European ESPRIT Condorproject. The Condor project is specifically concerned with


defining the working practices, processes, techniques, toolsand technical infrastructure to allow the construction indus-try to progress from its current position towards a large-scale,computer-integrated approach. All partners in the projectare well aware that moving from processes based on thecurrent document-based approach to those based on aproactive model-based approach is the key issue in facingthe ever-growing complexity of construction projects. Theyall acknowledge that most of today’s commercially availablesolutions are considered to be unsuitable for the particularrequirements of their industry.

The integrated project database will take many years todevelop, but one of the first problems to be overcome is thechange of culture. The document model-based approach,supported by information technology, can provide a pow-erful lever for change. It cannot, however, produce thebenefits alone. The organization and processes of construc-tion projects must change in order to deliver the benefits.Therefore, the construction project lifecycle, from conceptdevelopment to demolition and recycling, need to beexamined and re-engineered. In that respect, the Condorconsortium is analysing and modelling the business pro-cesses within the project end-users. Managing technicallylinked change calls for the total integration of the human,organizational and technical elements of the changethroughout the project. The Condor project will alsoprovide metrics to evaluate business systems responsive-ness towards meeting business objectives, and willanalyse the technological and socio-economic impact of theproposed approach.

This project is on-going and supported by a user interestgroup, which involves representatives from a variety ofnon-construction industry companies. It is hoped that thelatter will help to ensure that the results of the project aresufficiently generic to be transferred to industries other thanconstruction, and to assist in the wider dissemination ofresults. It is expected that some of these companies will beinterested in exploiting the Condor project results withintheir own organizations.

ACKNOWLEDGEMENTS

The authors would like to thank all the members of theCondor consortium and wish to acknowledge the financialsupport of the European Community under the ESPRITprogramme.

REFERENCES

Bjoerk, B.C., Huovila, P. and Hult, S. (1993) Integrated constructionproject document management (ICPDM). In: Beshesti, M. andZreik, K. (eds), Advanced Technologies—architecture—planning—civil engineering, Proceedings of the EuropIA’93 conference,21–24 June, Elsevier, Delft, pp. 135–146.

Butler Fox Foundation (1993) The role of information technology intransforming the business, Research Report 79, January.

183


Davenport, T. (1992) Process Innovation, Harvard Business SchoolPress, Cambridge, MA.

Davenport, T.H. and Short, J.E. (1990) The new industrial engin-eering: information technology and business process redesign.Sloan Management Review, Sammer, pp. 11–27./ 20

De Cieri, H. and Dowling, P.J. (1994) Cross-cultural issues inorganisational behaviour. Paper presented at the InformationSystems International Working Conference, Australia.

Fried, L. (1991) A blueprint for change. Computerworld, 2December, pp. 94–95.

Hammer, M. (1990) Don’t automate, obliterate. Harvard BusinessReview, July–August.

Harrington, J. (1991) Business Process Improvement: The breakthroughin strategy for total quality, productivity and competitiveness,McGraw-Hill, New York.

Hayes, P. (1995) BPR: A manifesto for critical analysis and comparisonof methodologies, BSc thesis, University of Salford.

Kotter, J.P. and Heskett, J.L. (1992) Corporate Culture and Perform-ance, The Free Press, New York.

OMG (1996) Common Facilities RFP-4: Common Business Objectsand Business Object Facility, OMG TC Document Number 96-01-04. http:// www.omg.org/public-doclist.html.

Orfali, R., Harkey, D. and Edwards, J. (1996) The Essential Distrib-uted Objects Survival Guide, John Wiley, New York.

184

Orgbonna, E. (1993) Managing organisational culture: Fantasy orreality. Human Resource Management Journal, Vol 3, No 2, 42–54.

PA Consulting (1992) Information Technology: The Catalyst forChange, Mercury Books, London.

Peppard, J. and Rowland, P. (1993) The Essence of Business ProcessRe-engineering.

Radosevich, L. (1993) Evasive action. Computer World, 4 October,pp. 83–84.

Rezgui, Y. and Debras, P. (1995) An integrated approach for amodel-based document production and management. ElectronicJournal of Information Technology in Construction, Vol 1,November.

Robin, R. (1991) Organisational simplicity. Reaching BeyondBusiness.

Rouse, A. and Watson, D. (1994) Some classic theories onorganisational change, and their implications for business pro-cess innovation and re-engineering. Paper presented at theInformation Systems International Working Conference, GoldCoast, Australia.

Teng, . (1992) Business process redesign and information architec-ture: establishing the missing links. Proceedings of the 13th Inter-national Conference on Information Systems, pp. 81–89.

Towers, S. (1990) Business Process Re-engineering: A practical hand-book for executives, Stanley Thornes, Cheltenham.

P. Hayes et al.