I was reflecting this week on implementation barriers to BIG BIM. Building richness to your BIM data to allow all disciplines, and therefore ultimately the customer, to benefit, is a goal. 'Standardise your data' is a common tip judging by comments at recent conferences. Whilst richness of information is part of its power, it seems to me to be the very providing of a common data standard that allows this data to be mined that is often a barrier in BIM implementation. "Standard data sets are all very well" I have heard from some senior construction managers, but we "build prototypes" and "nothing is ever the same." "We need to see our data in a different format from other disciplines" is another common theme.

"We build prototypes": yes, every construction project is unique. But every construction project also consists of repeatable components that can be described in standardised ways. Boil it down to the bricks, pipes, concrete and the working steps to join them together and you come up with the same components, no matter what the project. So the issue here is surely what is the right list of construction resources and work descriptions? Whilst there may not at the moment in many countries be a list of standard construction resources, most general contractors' estimators will have their own list, all with their own codes and rates. And many national bodies have several measurement methods breaking down how the work shall be described and quantified. So isn't a prototype just a unique combination of resources and scope statements? What's so hard about that? Why do only the most committed organisations start to look at building their cost control data out of unique combinations of standard components?

"We need to see our data in a different format". This one is more tricky, but answering it sheds light on why standardisation can be mind-bendingly difficult unless you have the right IT solution to support it and the right people to manage it. In fact what you need to see here is the lowest common denominator across all disciplines. Normally this will be a combination of estimating resource, scope description item (BoQ item), schedule activity, cost controlling line, and BIM object.

So how do you stitch all these together? And why? Is it worth it?

To borrow a phrase from the BBC's Robert Peston, bear with me, because the next bit gets more complicated, and its your project controls manager who has the pain of this on every bid and every live project.

What you have to do is start with the Building Information Model (let's call it a product breakdown structure - PBS - to use project management terms), and link your scope descriptions to it. So you end up, for each model element, whether it be a base, footing, wall, window, roof, pipe run, embankment section, with a 'mini-BoQ' that describes the work scope in that object. Then estimate the cost of each work scope item in each object using your standard resource list and outputs.

So now you have a quantified resource basis for each scope descriptor linked to each model object. When you aggregate all of these together you have a cost breakdown structure (CBS) for your project, breaking costs into sums and quantities for labour, materials, equipment and so on.

In fact though, what you really need to do before you resource estimate each object is gather together all like scope descriptors into one BoQ item. Then you can estimate the cost of one unit (for example m2 of dry wall) and spread that back across each BIM object. No problem there - that is what estimators do every day. But you need to see the context of all of this estimating in a visual representation so that you can see, for example, when you are pricing drywall whether it is 2m high or 3m high, and make the appropriate allowances. Not every estimator sees that.

Now you find that linking all of this to a schedule is the next problem. Why? Because the scope description (let's call it a scope breakdown structure - SBS - to avoid confusing this with the schedule breakdown), if it is based on standard measurement methods, is not in the same structure as the schedule Work Breakdown Structure - WBS. Not only that, but you normally find you need to make many-to-many links between your SBS and your WBS.

A great example - drainage. An estimator will want to price drains based on diameter, bed type, depth below ground level and probably ground conditions. A scheduler will want to have activities that list drain lengths in particular locations, and will work on an average output of so many metres of drain per day for a gang.

So you need a way of taking part of one SBS item and linking it to one schedule activity. Perhaps even you want to schedule the drain excavation, pipelay and backfill separately, so you may even need to take the estimate detail behind one SBS item and link it to several schedule activities.

Now the good news. If you can achieve this you have linked together your PBS, CBS, SBS and WBS. And the result is that you have information in the format the estimator wants it and the format the scheduler wants it, and you can visually see using the PBS model which elements of your project are represented in either.

Next thing: you want to use this information to resource load the schedule. The resources are already in the estimate, right? So why do we persist so often in doing things twice and getting the scheduler to re-estimate the resource requirements? Fine, if you want to do it as an independent check, but here's what can be a better way.

Your schedule needs to be loaded with requirements for drainage pipe, but only at the level of linear metres for all drain. But your estimate has several types of pipe in it: different diameters, all over the place. So you need to map your schedule resources to your estimating resources or CBS. Then you can pull out the information for resources required for each schedule activity. Because you have SBS items linked to each schedule activity you know the total length of drain (say). So now you can evaluate or check the duration in the schedule for the drainage activities based on the quantity of drain, total resource requirement, and a productivity for the activity.

If this sounds mind-bogglingly complicated to you, then just remember that project controls managers and their teams normally have to do this every day for every project. It is a major industry pain point, and often it is done by spinning masses of data in a spreadsheet, which takes ages and is very error prone. Search and you will find systems that allow you to seamlessly integrate your estimate (in one structure) with your schedule (in another).

All well and good, but now your financial controller gets involved. You've all agreed you will track the progress of the job and check your forecasts to complete using earned value. But you have yet another structure for your cost controlling. Quite typical - and the pain point here is that scheduling software encourages you to capture your actual costs at the level of the activity, which is normally far too detailed. So you devise a less detailed structure, but with the best will in the world, your financial controller can't make it overlap with your schedule WBS. Not only that, but the costs coming out of your financial system for individual cost codes are not in the same structure as your estimating cost codes.

So now you need two more mappings: accounting cost codes to estimating cost codes, and schedule activities to controlling lines.

This is no joke - it happens on every project and normally people spend ages spinning data around in vast spreadsheets to try to make it work. At great effort.

So you need a system which allows these mappings and will allow you to capture your actuals in a format that allows comparison with your allowances. And search hard enough and you will indeed find those systems on the market.

And now, the last thing. And again this should happen every day on every construction project. Capturing the value of the work done. With all this stitched together an engineer can, every day, look at a visual representation of his scope element, and say "I've done that!". For example, visually select in a viewer the piles that were bored today and capture the quantity of each linked SBS item. Do it again for the ones that were concreted, and the ones that were broken down, and so on.

So what you are building up, every day, is a very accurate survey of the value of the work done. No more breaking activities into steps and weighting them, duplicating what has already happened in the estimate. No more guessing percent complete of activities. No more duplication of surveying and scheduling effort. No more lack of traceability of valuation. Which makes your cost forecasts more reliable. Less arguments with your funder over payment release, better cash flow, complete as built records in the event of any dispute.

So is it worth it? And why do it? Well, my experience and customers tell me that the above processes are what they already do, or if they don't they often recognise that they need to but they can't stitch the data together because they don't have an integrated IT solution, or they haven't got a Programme Management Office that can implement the solution. They can save significant effort in controlling, resource scheduling, cost forecasting and valuation if they do have that integrated environment, and the right resource to implement it. So, yes I think it's worth it.

Who in the construction team is best placed to lead the integration of information? Who can save the most in their everyday job if the BIM model is used as the centre of this integration? I give you the new project controller. Not just a scheduler. Not just a resource planner. Not just someone who liaises with finance, engineering, estimating. Now also an even more highly skilled practitioner who needs to understand BIM and its power. Someone who can be the best resource to break down the barriers to integrating BIM to cost management in your organisation. If your organisation has someone who can meld BIM experience with project controls experience then you have a resource well worth rewarding.