Thursday, February 25, 2016

Benchmarking Series Part I - Data Capture and Quality Control

The Benchmarking Challenge

One of the biggest challenges for organisations when they want to benchmark is finding the relevant information in a way that is comparable across the things they're looking to benchmark. Perhaps user friendly software can help.

UniPhi's focus is on benchmarking everything cost and time related to construction projects. The range of this is almost endless and includes things like:

  • Average cost per m2/SF of floor area
  • Average elemental rates
  • Ratios between floor and wall areas
  • Revenue per net lettable area
  • Average duration of design phases
  • Average time to tender and procure 
  • Average time to achieve final account (We've gotten this down to two weeks for our construction clients)
  • Average percentage of variations to original price
  • Etc
Typically, this information is stored in spreadsheets and an email is sent around requesting people to send files for projects like XYZ. This is then consolidated and analysed by a BI team and hopefully some insights are obtained one to two weeks after the request went out.

Data Capture

The way UniPhi has approached this issue is to make sure we integrate with as many underlying cost planning tools as possible and to streamline the process of importing an estimate into our Costs module. We then link this process to something of benefit to the person importing the plan. This is usually in the shape of assisting them to generate a report to a client (either internal or external). By making their life easier we have created an incentive to actually go to the trouble of importing the data into our application.


Once the data is captured, the next challenge is to make sure it is valid and to provide enough meta data or classifications to it to allow benchmarking end users to be able to obtain a collection of similar projects to benchmark against.

Firstly the meta data. All projects create in UniPhi require the classification of four customisable items to describe them. The out of the box labels for these are:
  1. Sector
  2. Project Type
  3. Service Line
  4. Location
Users of our software can then add an unlimited number of additional classification drop downs. The typical additional classifications are:
  1. Work Type
  2. Floor Area
  3. And some sector specific functional units like number of keys or apartments, theatres, or beds.
As these are mandatory fields when creating the project, you end up having classified a project as being in a Commercial Sector, Office Tower, Sydney, New Build,30,000 Sqm and 30 levels.

Add a project description and you've got a lot of information about the project already. The key with this meta data is that it is keyed in once. Then every piece of content created against that project subsequently inherits this meta data. So when the estimator or cost manager imports a cost plan into a particular project, the sector, project type, work type and floor area is automatically associated to this new piece of content.

Quality Control

At this stage we have a cost for a project and an association for the type of project but how do we quality control the data? This is where UniPhi's documents module comes into play. The documents system aggregates information stored in the rest of the application and workflows it to relevant parties for review and sign off. Only signed off pieces of information are available in the resulting benchmark reports.

Similarly, our new benchmark algorithm (See Part 4 of this series) relies on the certified progress claims of completed projects as the basis for generating phased forecasts.

At risk of stating the obvious, the quality of your information is crucial in generating useful benchmarking results, and with some simple rules and workflows embedded in the software, we believe this is not as difficult a task as it once was.


Once we get lots of projects captured in our database, benchmarking is as simple as the query interface and resulting data set of sample projects ready for comparison.

No comments: