WO2012162736A1

WO2012162736A1 - Construction management system and method

Info

Publication number: WO2012162736A1
Application number: PCT/AU2012/000602
Authority: WO
Inventors: Craig Stuart MCKINNON
Original assignee: Yarris Pty Ltd
Priority date: 2011-06-03
Filing date: 2012-05-31
Publication date: 2012-12-06
Also published as: AU2012262658A1

Abstract

A construction management method and system for extrapolating a plurality of work ticket items from an input design automatically and generating a plurality of work orders, each work order specifying a task of work for execution which are transmitted via a communication network to third parties responsible for execution of the work order. Work order execution progress data for the one or more work orders is received via the communication network and a progressive as-built automatically updated based on the received work order execution progress data.

Description

CONSTRUCTION MANAGEMENT SYSTEM AND METHOD

Field of the invention

The field of the present invention is management of construction projects, for example for building or installation of buildings or other infrastructure. Embodiments of the invention are particularly useful in projects where a design for a construction project is broken down into components for completion by different subcontractors.

Background to the invention

The construction industry has for a long time used a fairly standard approach to construction projects. There is an initial design phase followed by construction of the approved design and finally the constructor will report back what was actually built in a range of formats which are generally known in the industry as "as-builts". There are several areas in this process which are an ongoing cause of inefficiency and inaccuracy in the construction industry.

Currently construction projects are based on designs generally produced as CAD (computer aided design) drawings and associated documents which define an end product, also known as an asset, for the construction project. Examples of designs include architectural and structural drawings for buildings, drawings defining infrastructure such as roads or telecommunication network infrastructure. Such designs must be manually broken down and adapted to define work orders for distribution to work crews, such as contractors and subcontractors, for execution of the work. The initial conversion of a design, which may cover a large geographical area, in to a set of work orders suitable for issuing to work crews is generally a highly manual process. This introduces delays and potential for errors as designs are manually transcribed into work orders (Bills of materials, Bills of quantities, Labour codes, Certification requirements to perform work etc). This process of converting designs to work orders is slow, inefficient and error-prone, also heavily dependent on paper heavy folders passed to work crews.

The construction process now commences. Construction is often performed in a semi "black hole" environment and updates received back from the field on progress can be fairly ad- hoc or non-existent.

Post construction the various constructor companies will now produce "as-built" documents describing the construction that was performed. These are produced in a range of formats, levels of correctness and levels of quality. Typically a manual paperwork heavy process is required to be executed by the constructor company on completion of the work order to prepare the as-built to report the actual completed work and specify any variations from the original work order. Such As-Builts are typically prepared only once the work order is completed. As-builts ore often prepared using a CAD package but manual paperwork reporting is also used. Thus there is no visibility of work in progress during execution of the work order. Further, there is no standard as-built reporting standard, so as-builts received from multiple construct contractors typically lack consistency.

There are many reasons why there a lack of consistency in As-Builts, some of which are:

Construction volumes - contractors don't have the time to sit down at a cad package after work.

Pricing - slim margins discourage contractors from spending too much time at generally non-chargeable tasks, such as As-Built preparation.

Remote build locations mean it's difficult to produce and deliver As-Builts in a timely fashion.

Education and skills - computer skills vary widely and not all contractors are able to use cad packages at a reasonable standard.

The prime contractor or asset owner has to combine all of the individual as-builts received from various constructor companies to produce a single as-built document. As the as- builts are returned in a range of formats and qualities, enormous manual effort is required to combine these to a common view of the asset. Thus it is a time consuming, difficult and laborious manual task to construct a final as-built for a construction project from the as-builts completed by each contractor for each work order.

Summary of the invention

According to one aspect of the present invention there is provided a construction management method comprising the steps of:

extrapolating a plurality of work ticket items from an input design automatically by a work order generator using a work ticket extrapolation algorithm;

generating a plurality of work orders by the work order generator applying a work break down algorithm to the plurality of work ticket items, each work order specifying a task of work for execution;

transmitting one or more work orders of the plurality of work orders of via a communication network to a third party to be responsible for execution of the work order;

receiving work order execution progress data for the one or more work orders; and updating automatically a progressive as-built based on the received work order execution progress data.

The third party for execution of a work order can receive the more work order transmitted via a communication network via an application executing on a processor device, the application enabling the third party to input data relating to progress of execution of the work order. The method can further comprise the steps of:

receiving via a communication network work order execution progress data for a third party reported via the application;

transforming the received work order execution progress data automatically by an as- built mapper module into progressive as-built data; and

updating a progressive as-built design using the progressive as-built data.

In an embodiment the work order generator applies one or more defined business rules to generate work orders.

In an alternative embodiment the work order generator applies historical work order data obtained from past construction projects and stored in a database accessible by the work order generator to generate work orders.

Each work ticket item can include any one or more of: work item specification, materials estimate, and work hour estimate.

Each work order can include scheduling data. The scheduling data can include start and end dates for the work order determined automatically by the work order generator based on dependencies between work orders and optionally external construction time line limitations for the design.

The construction management method can further comprise the steps of:

inputting one or more additional work orders not automatically generated from the design; and

transmitting the additional work orders via a communication network to a third party to be responsible for execution of the additional work order.

The method can further comprise the step of automatically selecting third parties to execute work orders by a work order management module.

In an embodiment the as-built mapper updates a progressive as-built design by: identifying the work order to which received progress data relates;

identifying any discrepancies between the work order specification and received progress data, and where a discrepancy is identified adjusting as-built actual design data in accordance with the received progress data; and

updating completion data associated with the work order in the progressive as-built design.

The method can further comprise the step of identifying automatically one or more discrepancies from the input design in the progressive as-built.

According to another aspect of the present invention there is provided a construction management system comprising:

a input interface configured to receive input design data; a work order generator configured to analyse the design data, automatically extrapolate a plurality of work tickets items from the design data using a work ticket extrapolation algorithm, and generate a plurality of work orders by applying a work break down algorithm to the plurality of work ticket items, each work order specifying a task of work for execution;

a work order management module having a communication network transceiver, the work order management module being configured to transmit one or more work orders of the plurality of work orders of via a communication network to a third party to be responsible for execution of the work order, and receive work order execution progress data for the one or more work orders; and

an as built mapper module configured to automatically update a progressive as-built based on the received work order execution progress data.

The construction management system can further comprise an application for execution on a processor device to be provided to third parties whereby a third party for execution of a work order receives the work order transmitted via a communication network via the application executing on a processor device, the application being configured to enable the third party to input data relating to progress of execution of the work order.

The work order management module can be further configured to receive via a communication network work order execution progress data for a third party reported via the application, and the as-built mapper module can be configured to transform the received work order execution progress data automatically into progressive as-built data and update a progressive as-build design using the progressive as-built data.

The application can be configured for execution on any one or more processor devices selected from the list of: mobile telephones, smart phones, desktop computers, servers, laptop computers, tablet computers, and personal digital assistants.

In some embodiments the application can also be accessed by the third parties via an internet web page interface.

Brief definition of the drawings

Figure 1 is a block diagram of an example of a system according to an embodiment of the invention,

Figure 2 is a further example of a system according to an embodiment of the invention,

Figure 3 shows a flowchart of a method according to an embodiment of the invention, Figure 4 is an illustrative block diagram of breaking down a design into work orders, Figure 5 is an example of a progress report input screen displayed on a mobile phone, and

Figure 6 is a illustrative block diagram of processing progress report data to update a progressive as-built. Detailed Description

The invention provides a system and method for managing a construction process. Embodiments of the method provide a process for managing a design and construct process from the design through construction and as-built reporting. Embodiments of the system provide specific tools to support the design and construction process. More specifically an automated process is provided for turning designs in to work orders and returning details of actual work completed as as-builts progressively throughout the construction project.

A system for an embodiment of the invention is shown in Figure 1. The construction management system 100 comprises an input/output (I/O) interface 120, a work order generator 130, a work order manager 140 and an as built mapper 160. Each of these modules may be implemented using any suitable combination of software, firmware and hardware. For example, the work order generator, work order manager and as-built mapper may all be implemented as software modules executable on a network connected computer system or server.

At the outset of a construction project the system provides tools and processes to automatically convert a construction design 1 10 obtained from a design tool into a set of work orders suitable for delivery to work crews in the field. A further example of a system according to an embodiment of the invention is shown in Figure 2. A flowchart of a method according to an embodiment of the invention is shown in Figure 3.

The design 1 10 is created for the intended construction activity and are typically created through the use of some sort of computer aided design (CAD) package. Designs 1 10 are commonly stored as a particular file format or as tables in a database.

The input interface 120 is configured to receive input design data. The I/O interface 120 can include tools which enable designs 1 10 created in different formats to be converted into a single format or relevant data extracted from the designs to be used by the system. For example the I/O interface 120 can include a design tool abstraction layer 220 providing access to design and as-built formats from different CAD tool vendors. This design tool abstraction layer can provide a common view of designs and as-builts to the system. For example by transformation or format conversion of design data provided in different CAD or other formats. The design tool abstraction layer can receive design or as-built information in a first format which may be any one of a plurality of different formats, and convert the design or as-built information into a second format, different from the first format. The second format can be a format chosen for use within the system for analysis of designs and as-builts. Any suitable format may be chosen and the format used within the system may be a format used by CAD tools. For example, first formats for design or as built data may be comma separated value (CSV), an Autodesk AutoCad format, I Spatial Internal Feature Format (IFF), Aeronautical information Exchange Model (AIXM), Australian Design as constructed (ADAC), a geodatabase format, an Autodesk format, Geographic Data Files (GDF), Google SketchUp, JPEG, etc, and the data obtained converted to a second format such as Spatial Archive and Interchange Format (SAIF) for use within the system. It should be appreciated that these are just some examples of data formats that may be used and all possible data formats are envisaged within the scope of the present invention.

Once a design 1 10 is input to the system the system converts the design into a number of projects and work orders in an automated fashion. An example of this process is illustrated in the flow chart of Figure 3 and diagram of Figure 4. The design is input to the system 310 and optionally processed via a design tool abstraction layer as described above.

A work ticket extrapolation algorithm is then applied 320. This produces a list of work items, materials, estimated labour hours and other ticket of work items as required based on the input design, these can also be referred to as master work orders. The work order generator 130 is configured to analyse the design data, and automatically extrapolate a plurality of work tickets items from the design data using a work ticket extrapolation algorithm.

For example, with reference to figure 4, a design can have three components 410, 412, 415 each produced using a different tool. Processing in the adaptation layer 420 can translate the data from each design component and apply an extrapolation algorithm 430 to extract and extrapolate from the design data a master work order 440. The master work order 440 can then be broken down 450 into a plurality of individual work orders 460a, 460b, 460c for distribution to work crews.

For example, from a design individual construction components can be identified and task required for construction of each component identified. For example, for a

telecommunication infrastructure design, components such as cabling installation, substation construction and equipment installation, residential interconnection etc components can be identified. Each of these components can require several tasks to complete, for example cabling installation can require the digging of trenches, laying of cable ducts and cable rollout and connection. The work ticket extrapolation algorithm is adapted to perform these extrapolation steps.

The work order generator then generates a plurality of work orders by applying a work break down algorithm to the plurality of work ticket items 330. This produces a suggested break up of work orders. Each work order specifies a task of work for execution. For example, the work order generator 130 can break down a work item such as cabling installation into a plurality of individual work orders divided based on geography, for example street by street. Thus, each work item can be broken down into work orders suitable for distribution to individual constructors for execution 340.

The method and system provide a business process new to the construction industry - namely the automatic creation of work orders directly from a CAD design, design database or other design tool with an appropriate API (application programming interface) or method of interfacing. The process further breaks down the master work orders to a collection of sub work orders at a granularity suitable for scheduling out to work crews or sub-contractor companies. The work ticket items or master work orders specify the work that is required to complete the construction design, these work ticket items or master work orders are then broken down into works orders suitable for distribution to work crews or subcontractors, referred to collectively here as constructors. The level to which master work orders are broken down into work orders for distribution can vary depending on the nature of the design and the skills of the target constructors for executing the work orders. Work orders broken down to different levels can also be used within the same construction project.

Both the master work order and the sub work-orders are created automatically in the system. Two approaches are provided to transform a design to a master work order, each of these will now be discussed with reference to Figure 2.

In the first approach a pre-configured set of business rules 232 is maintained. These business rules 232 are applied by a master work order generator 230 to map design items into the various items required to complete a work order, and by a work order break down module 235 to further break down the work orders down ready for distribution to constructors.

A set of business rules is hosted in a rules engine 232. The business rules will be used both to assist in the breakdown of master work orders to sub work orders and also in the extrapolation of a design into a master work order. The use of a rules engine allows dynamic changes to suit the needs of particular industries, contracts, work types and other unforseen needs. For example, business rules can be used to define execution parameters and requirements for a task that has not previously been executed, for example, installation of a new piece of equipment.

In the second approach, historical work order management data 238 is used by the master work order generator 230 to determine the quantities appropriate to a particular design item. Note that this is generally a one to many mapping. Combinations of these two approaches, where both business rules and historical data are applied can also be used.

The historical work order management data 238 can be a structured repository, i.e. a database, of actual data acquired from the work order management system. The repository can contain past history of work orders in a format suitable for projection of future work order breakdowns. As a simplified example, it should be possible to find the average number of labour hours required to dig a trench based on average work orders in the past and use this as an initial value. The master work order generator 230 is adapted to source data from the repository for past execution of tasks based on the task definition and other defined criteria. For example, the master work order generator 230 can look up historical data in a database for tasks having the same task definition and identify relevant similar historical tasks based on other defined criteria, the execution data for these similar tasks can be analysed for generating work orders. For example a task definition may refer to trench digging and the associated defined criteria may include any one or more of the purpose for the trench, required dimensions, anticipated soil and terrain conditions, council restrictions etc which may all impact on the execution of the task. The work order generator can process the historical data for similar tasks during generation of a work order for a new design. For example, the historical data may be used to adjust scheduled execution time for the task, determine required equipment and enable any additional information such as required permits to be included in the work order.

The master work order generator 230 converts a design 110 to a master work order. The master work order generator 230 can use as inputs a combination of p re-configured business rules 232 and past experience from the work order management system history 238. This module combines these internal inputs with the detailed modelling of the construction project taken from the design 1 10 to produce a master list of materials, labour types, labour rates, plant and equipment, required certifications to complete the work, checklists and documents. This is considered a master order which covers all the details required for the construction aspect.

The master work order is generally too large to be efficiently scheduled and worked upon as a single entity so some sort of breakdown must be applied. This will generally depend on such constraints as geography, contractor skills and available resources. This break down is performed by the work order breakdown module 235. The breakdown is a dynamic process based on configurable business rules hosted in the rules engine 232. An example approach may be to break down a master design for an estate to a single work order per street. The work orders created are in a state ready to be sent to contractors to begin work.

A first indicative example for generating work orders follows:

A design may include an item indicating that a trench is to be dug measuring a length of

100m with a width of 30cm and a depth of 1 m. In the corresponding work order this could translate into multiple items - an item indicating the need for 2 hours construction labour at a particular labour rate, a material item indicating the need for 100kg concrete to line the trench, a plant item indicating the need to use a trenching machine for 2 hours and a labour item indicating the need for a traffic management contractor for 2 hours.

The process designed allows a set of business rules to be applied to the master work order to break it down to sub work orders suitable for scheduling out to work teams or subcontractors.

A second indicative example of generating work orders follows:

A design for an optic fibre loop covering five streets in a new estate is developed. The master work order extracted from this includes codes for the digging and trenching work (often collectively referred to as civils), the distribution of the optic fibre through the trenches (often collectively referred to as hauling), the connection of the optic fibre to homes, other fibres and multiplexer equipment (often collectively referred to as splicing) and finally codes for the traffic management teams required to protect the construction teams and the public. These are all work types often performed by different contractors with different skills and this would be one candidate for a work breakdown. Geography is another, with the possibility of work orders being broken up one per street. I n this example with four work types and five streets the master work order could be broken down in to 20 distinct work orders. The process developed allows the specification of flexible business rules allowing this sort of flexible breakdown.

The work order generator 130 can also be configured to determine scheduling for work orders. For example, the scheduling data can include scheduled start and end dates which are determined based on dependencies between tasks and overall project scheduling constraints. Historical data can also be used for determining scheduling data, for example by analysing time taken previously to execute similar tasks in similar conditions or by the same constructor.

The work order generator 130 can also be adapted to perform allocation of work orders to constructors. For example rules based selection, ranking according to quality / kpi performance or rota based selection.

The system can also enable work orders to be manually input to the system. For example, where required work orders cannot be extracted directly from the design. Examples of such work orders include survey orders to assist in the design process, traffic management work orders to TM contractors, and work orders to internal Land Access Clearance (LAC) teams to arrange access for the construction crew. Once these work orders are entered in to the system they can be automatically distributed and monitored similarly to automatically generated work orders.

The work orders created are in a state ready to be sent to contractors to begin work. The work order management module 140 is configured to communicate with a work order handling application 150 via a communication network. In an embodiment the work order management module 140 has a communication network transceiver 145 to enable communication via wired or wireless communication networks. For example, the transceiver may be a modem for connecting to the internet via a telecommunication network. Alternatively the management module may be implemented in a network connected server. The work order management module 140, 240 is configured to transmit one or more work orders of the plurality of work orders of via a communication network to a third party to be responsible for execution of the work order 340. Embodiments of the system provide a web interface 255 and an application 250 executable on a processor device, such as a PC/laptop/tablet computer, mobile phone, smart phone or personal digital assistant (PDA) for enabling constructors to receive work orders and provide feedback on work progress to a work order management engine 240. For example, the web interface 255 may provide a portal via which constructors can log on to download their work orders or input work progress data. The web interface 255 may be adapted to operate easily from mobile devices such as smart phones or tablet computers. Alternatively an application 250 for smart phones or tablet computers may be provided enabling downloaded work orders to be viewed and work progress feedback to be entered while either online or offline, any offline feedback entered being uploaded to the work order management engine 240 once online.

Embodiments of the system provide a work order management system web interface which can also provide an optimised mobile experience. Specific functionality made available through this portal includes:

1. Accept, reject and manage the lifecycle of work orders.

2. Vary the quantities, times, materials, locations and construction details associated with a work order.

3. Use the GPS hardware associated with the mobile device where available to provide updated coordinates against physical inventory.

4. Use local storage on the device to allow updates to proceed while away from network coverage.

5. Allow synchronizing of local data back to the system when coverage is available again.

6. Use the camera hardware associated with the device to attach evidentiary photos/videos directly to the work order.

7. Mark items as constructed, triggering a progressive update to the as-built.

8. Update milestone information - eg. flag when contractor is on/off site. Triggers update to the data mart.

9. Capture other arbitrary data in user defined fields, triggering updates to the data mart.

During construction the system enables work crews to provide real time updates of work progress from the field 350. These updates can be provided via a mobile device. This can have advantages in accessibility and convenience for progress reporting. The updates are received by the work order manager 140 via the communication network.

The updates from the field are transformed as they are received and stored back to a design repository and/or asset management system. This enables progressive updating of as- built information 360.

For example as shown in Figure 2, work progress can be reported via a mobile device application 250 or web page interface 255 to the work order management workflow engine 240. A Field Update Router 262 can be provided which routes updates received from the field back to an as-built mapper module 260 to provide a progressive update or to the data mart 265 for real time reporting or both. The Data Mart 265 is a data repository for storing work order data. The data mart 265 can include data structures to hold the data captured from the field. This allows end users to use this data in powerful analysis cubes, adhoc reports or dashboards.

The As-Built Mapper module 260 performs any necessary reverse mapping required to an update before applying it to the as-built, for example applying item codes, changing coordinate systems.

The as-built is the counterpart of the design. Whereas the design captures details of the PLANNED construction the As-Built contains details of the ACTUAL construction. As- builts provided by different constructors are commonly stored as a particular file format or as tables in a database. Past practice is that these are created through the use of some sort of computer aided design (CAD) package. The system devised herein creates the as-built in a progressive, automated fashion. I n embodiments of the present invention the as-built construction is no longer an artefact produced at the end of construction but rather is iteratively built through an ongoing process of progress updates during the build phase. This is achieved by use of mobile devices in the hands of the construction crews. Updates transmitted from the field crew are filtered and where relevant used to update a design model - in effect producing a progressive as-built. An adaptation layer can be included to allow the plugging in of different design formats as output.

Whereas a design is a well formatted description of what is intended to be built, an as- built is a well formatted description of what was actually built. In terms of the representation these are usually one and the same - i.e. information in a design tool or a CAD file. Whilst a design is usually a single unified document, the resulting as-builts relating to part of the construction project can be numerous as multiple sub-contractors and work teams provide back their own versions.

Embodiments of the present invention allow each work team and contractor company to collaboratively provide updates in real time progressively during execution of work, for example, via the mobile application 250 or web page interface 255. This can provide three important advantages over the usual process:

1. Visibility is achieved through the life of the project. Asset owners and project managers can view the evolving as-built document / design progressively during the course of the project.

2. There is no need for a team with design skills to combine the as-built data from the multiple sub-contractors. Updates are entered directly in the work order management system, transformed to a suitable format and applied to the evolving as-built design.

3. As-Builts are updated by completing simple forms in a work order management system. This removes the need for contractors to have skill in a design tool and ensures consistency of approach across the project. Progressive updates may be applied either through the standard web forms or through the mobile optimised web forms available in the work order management system. This process is depicted in Figure 6. Work crews 601 , 602 input progress information to an application executing on a suitable mobile device 650, 655, for example a mobile/smart phone, laptop or tablet computer. This data relates to a work order 640a, 640c being worked on by the work crew 601 , 602. The application can provide a template, based on the work order, to facilitate entry of progress information. This progress data is transmitted to the work order management system 400 to trigger an update 670 of the as-built. The progress data for the work order is automatically filtered based on design items 660 and the as-built for the design item updated accordingly 680. For example, where the design item may be cable installation and the progress information relates to the status of trench digging for the cables such that the as-built can be updated with the actual dimensions and locations of trenches dug so far.

The updated as-built data can also be processed through an adaptation layer 690 to convert the as-built data into a format consistent with the original design documents and compatible with a design tool 610, 620, 630 used for generation of the original design, for example, for verification, reporting and project audit purposes.

The web and mobile application interfaces can be used to facilitate feedback of progress data. As-Built update information may be provided by the following methods:

1. By marking an item as being complete "As Designed". This is used when everything has been built according to the design and nothing additional is required.

2. By marking an item as being complete "Varied From Design". This is the case where construction could not be completed exactly as designed for some reason - for example the location for a pit specified in the design has a fire hydrant. In this case new location information must be supplied for the item.

3. By marking the item as being complete "Un Designed". This is the case where an item is required which was left out of the original design. Again, location information is required.

Location information can be entered in the following ways (Note that some items will have multiple coordinates - eg a cable may have a location for each end point):

1. By entering GPS co-ordinates directly against the item before marking it complete. This could be the case where high accuracy survey / navigation equipment is available on site.

2. By entering a street address. This will then be converted to a co-ordinate through an addressing service.

3. When using a mobile browser with GPS capabilities the system can populate the location from the device. An example of a progress report screen of the mobile application is shown in Figure 5. The application identifies the relevant work order 510 and prompts the user to enter as built geographic coordinates 520. The latitude 530 and longitude 540 can be entered manually by the user or the user may press a button 550 to cause the application to automatically enter coordinates based on the location of the mobile device 500 as determined by the device GPS functionality. Thus the actual geographic location of an items, such as a start of a trench can be input to the application and sent via the communication network to the system for updating of the as built for the design.

In embodiments of the construction management system of the present invention progressive work order progress data is fed back to enable a progressive as-built to be maintained for the entire design. Work order progress data can be requested or prompted via the mobile application or web interface using specific work order data. Thus making is easy for the work crew or constructor to provide the information required. This can also alleviate the need for a constructor to produce a complete as-built for a work order, which may include more information that what is essential to feed back for generation of an as-built for the entire design.

The progress data is then applied automatically by the system to a progressively updated as-built for the design. The progress data can be transformed by the as-built mapper and fed into a spatial database to allow a progressive update of as-built information.

For example - a contractor could stand on a pit and mark it complete. This would result in an update being delivered back in to the spatial database marking the asset as constructed. Other measures such as on site time, completion measures (% complete, number of houses passed etc) or important milestone dates can also be reported via the mobile application or web interface.

The As-Built Mapper combines reported progress data to produce a single progressive as-built. The data that is supplied from the field can be reported as progress events, thus a file degenerated as-built for a work order is not required. As each event comes in from the field (eg pit complete) the system updates the single progressive as-built with this information. The role of the As-Built mapper in this is to add back any information required to correctly write to the as- built.

Three functions of the as-built mapper include:

(1 ) Co-Ordinate transformations. The work order management system will use lattitude / longitude but the as-built format may require grid co-ordinates for example. The As-Built mapper can transform co-ordinate data to the correct co-ordinate system.

(2) I nformation stripping / restoration. The design tool may store a greater amount of detail about an item than is required in a work order management system. It is important that this information is also added to the as-built. The as-built mapper is adapted to add this information from the design or generating this information for newly created items. (3) Processing field events. Field events will need to be cached and recombined. When a design item is transformed into a work order item it is possible that more than one work order item will result. For example a design code for fibre may result in a work code for hauling the fibre and another for connecting the fibre. We cannot update the as-built saying this is complete until both work order items are complete. The As-Built mapper would store these dependencies and only apply to the as-built when all are complete.

The as-built mapper may also enable map integration. Map integration with the spatial database can allow display of the network design as a map overlay, for example using a map tool such as Google maps. Overlaying the design and as-built data with maps can also enable features such as:

Display of work crews locations on the same map as a telecommunication network design is shown.

As work is completed in the field it can be flagged as constructed - allowing an overlay of constructed assets in a different colour. For example, displays can be made available showing the telecommunication network being created in real time, as well as the planned design.

The system also enables simple redline requirements to be avoided - for example if a pit was constructed in a different location the contractor could mark it complete and incorporate the new GPS co-ordinates from their mobile device to update the asset location. Alternatively, they could enter a street address and use a geocoding service to retrieve the longitude and latitude co-ordinates. Fibre segments could be treated in a similar fashion by treating them as two end points.

The progressive as-built is created automatically by the as-built mapper based on the original design and progress data fed back from the work crews. The as-built mapper applies business rules for transforming progress data and creation/updating of the progressive as-built. The use of an application for assisting in progress reporting and automatic generation of the progressive as built from reported data can alleviate problems caused by transcription errors and improve timeliness of reporting. Further the availability of progress data stored in the data mart 265 can enable generation of other reports on construction progress at varying levels, i.e. work order or aggregate level. This can improve the ability to provide visibility to the project owner and facilitate early identification and mitigation of potential problems.

It should be appreciated that generation of the progressive as-built based on data fed back from the field enables discrepancies between the planned design and actual construction to be identified automatically. Any such discrepancies can also be flagged to bring these to the attention of a project overseer or designer. For example, if approval is required or if a discrepancy may cause further design deviations to be required. This can facilitate timely identification of potential problems and updating of work orders, if necessary. For example, the as-built mapper 260 may generate warnings for any discrepancies between the design and actual work completed and, using business rules, warnings may have a hierarchy based on the potential impact of the discrepancy. For example, the as-built mapper 260 may be adapted to identify where a discrepancy may cause alteration to the design and flag such discrepancies as high priority.

Embodiments of the construction management system can also include modules adapted to manage all aspects of the construction process from supplier selection, KPI measurement, contract and rate management, variation and dispute management, claiming, invoicing.

It should be appreciated that the modules of the construction management system can be implemented using any suitable combination of software, hardware and firmware.

Embodiments of the system may be implemented as a distributed system having modules executing across a variety of networked hardware resources or using distributed processing resources such as cloud computing resources. All possible variations for system

implementation are contemplated within the scope of the present invention.

In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

It is to be understood that, if any prior art publication is referred to herein, such reference does not constitute an admission that the publication forms a part of the common general knowledge in the art, in any other country.

Claims

CLAIMS:

1. A construction management method comprising the steps of:

receiving work order execution progress data for the one or more work orders; and

updating automatically a progressive as-built based on the received work order execution progress data.

2. A construction management method as claimed in claim 1 wherein the third party for execution of a work order receives the more work order transmitted via a

communication network via an application executing on a processor device, the application enabling the third party to input data relating to progress of execution of the work order.

3. A construction management method as claimed in claim 2 further comprising the steps of:

transforming the received work order execution progress data automatically by an as-built mapper module into progressive as-built data; and

updating a progressive as-built design by the as built mapper using the progressive as-built data.

4. A construction management method as claimed in claim 1 wherein the work order generator applies one or more defined business rules to generate work orders.

5. A construction management method as claimed in claim 1 wherein the work order generator applies historical work order data obtained from past construction projects and stored in a database accessible by the work order generator to generate work orders.

6. A construction management method as claimed in claim 1 wherein each work ticket item includes any one or more of: work item specification, materials estimate, and work hour estimate.

7. A construction management method as claimed in claim 1 wherein each work order includes scheduling data.

8. A construction management method as claimed in claim 7 wherein scheduling data includes start and end dates for the work order determined automatically by the work order generator based on dependencies between work orders and optionally external construction time line limitations for the design.

9. A construction management method as claimed in claim 1 further comprising the steps of:

10. A construction management method as claimed in claim 1 further comprising the step of:

automatically selecting third parties to execute work orders by a work order management module.

1 1 . A construction management method as claimed in claim 3 wherein the as-built mapper updates a progressive as-built design by:

identifying the work order to which received progress data relates; identifying any discrepancies between the work order specification and received progress data, and where a discrepancy is identified adjusting as-built actual design data in accordance with the received progress data; and

updating completion data associated with the work order in the progressive as- built design.

12. A construction management method as claimed in claim 1 further comprising the step of identifying automatically one or more discrepancies from the input design in the progressive as-built.

13. A construction management system comprising:

a input interface configured to receive input design data;

a work order generator configured to analyse the design data, automatically extrapolate a plurality of work tickets items from the design data using a work ticket extrapolation algorithm, and generate a plurality of work orders by applying a work break down algorithm to the plurality of work ticket items, each work order specifying a task of work for execution;

an as built mapper module configured to automatically update a progressive as- built based on the received work order execution progress data.

A construction management system as claimed in claim 13 further comprising an application for execution on a processor device to be provided to third parties whereby a third party for execution of a work order receives the work order transmitted via a communication network via the application executing on a processor device, the application being configured to enable the third party to input data relating to progress of execution of the work order.

A construction management system as claimed in claim 14 wherein the work order management module is further configured to receive via a communication network work order execution progress data for a third party reported via the application, and the as- built mapper module is configured to transform the received work order execution progress data automatically into progressive as-built data and update a progressive as- build design using the progressive as built data.

A construction management system as claimed in claim 14 wherein the application is configured for execution on any one or more processor devices selected from the list of: mobile telephones, smart phones, desktop computers, servers, laptop computers, tablet computers, and personal digital assistants.

A construction management system as claimed as claim 14 wherein the application is accessed by the third parties via an internet web page interface.