Explaining BouwData - part 4

When I left my fancy office in 2006, I didn't stop estimating. Quite on the contrary. Where estimating was previously merely a necessity to get the contract signed, it is now the end product of my business. And because of this shift in focus, I realised how sloppy me and fellow estimators sometimes worked.

Let me give you an exemple.

Masons are hard to find. And good masons often start their own specialised company. Therefore, general contractors often depend on them to get the job done. So, when estimating a project, you ask their price. Way too often this price is put into the estimation as a subcontractor. But most of the time these people only bring their own trowel. Bricks and mortar are to be bought by the general contractor; vertical and horizontal transport is to be done for them with the centrally placed tower crane.

Important question: how do you know whether this one tower crane is sufficient to get the job done in the most efficient way ? Well, out of the estimation you derive all the labor hours. Devide them by 8 hours per day and you get the number of "labor days". You  think you will hire the tower crane during e.g. 10 months. In one month you have, on average, 17 to 18 days that people work on the site. Multiply the 10 months by 17 or 18 and you have the "crane days". Divide now the "labor days" by the "crane days". When the result is 8 to 10 this means that, on average, 8 to 10 people are working on site at the same time. In this case you will be doing just fine with this one tower crane. With a higher result the men will have to wait to get their material to work with. With a lower result, the tower crane is not used at its full capacity.

Now, suppose we put the masons we hire as a subcontractor in the estimation. When deriving the labor hours, their hours will not be taken into account. But these people expect that you get the material to the spot where they work in time. If not, they will not be able to work at the estimated efficiency and they will lose money. And people who lose money while working, are usually not the people who deliver the best job. So, in the end the general contractor himself is the victim.

Another issue: all kinds of labor are put in the estimation by the same code because it is usually the same price. Suppose that, at the moment of estimation, it looks like it that there will be enough masons in your own company available for the job. When deriving the labor hours from the estimation, the check of the centrally placed tower crane will be done correctly. But suppose that there is a delay and when the project eventually starts, there are no masons available anymore. Now you have to go through the whole estimation and add up manually how many hours were ment for masonry in order to create a separate budget for these hired masons. In our digital age, a real stupid thing to do.

What can we do about it ?

Apply the set of agreements of BouwData on cost types :o) 

Which cost types do we have ?

  • the classic MAMO, used when the design is finished and when the budget is made to do the purchases. But there are costs which can't be considered as a MAMO e.g. costs for assurances, taxes, etc. In BouwData the code 00 is used to summarise all general funds in the estimation

    - A of "arbeid" which is Dutch for all kinds of labor: the wages of the workers on site as well as the wage of the projectmanager, as well for own staff as for hired people.
    Further distinction is to be made by the material code (will be threated in part 5 of this blog). In BouwData the code 10 is used to summarise all labor in the estimation

    - M of "materiaal" which is Dutch for deliveries, costs for materials used in the building or which can't be used afterwards (e.g. the notice board with all the building partners). In BouwData the code 20 is used to summarise all deliveries in the estimation

    - M of "materieel" which is Dutch for equipment, costs for all the things which don't remain on site and can be used in a following project. In BouwData the code 30 is used to summarise all equipment in the estimation

    - O of "onderaannemer" which is Dutch for subcontractor: people who come on site with their own materials and/or equipment to realise a component of the building.  In BouwData the code 40 is used to summarise all subcontracts in the estimation

  • As I stated in my previous blogs, there are also other costs to be considered while estimating:

    - AK of "Algemene Kosten" which is Dutch for general costs not related to any particular project. Usually this is a percentage added to the cost types mentioned above between 5% and 10%

    - W of "Winst" which is Dutch for profit: the estimated selling price minus the estimated costs. Usually this is also a percentage added to the cost types mentioned above.

    - R of "Risico" which is Dutch for risk: this is an amount of money for unexspected events.  Usually this is considered together with the profit and can go from 0% up to 10%.

    - S of "Stelpost" which is Dutch for a fixed sum. This is used when there are no details available for a component which certainly will needed to be build. E.g. a kitchen in an apartment block.

  • But before purchasing, while designing there is also a need for estimations. In this phase it is too soon to go to the market to ask for prices, though. Usually you search in a database with cost ratio's. There are three levels of cost ratio's, all related to the object code and phasing of projects (will be threated in one of my next blogs as well).

    - cost ratio related to the "elementcluster", which is used when defining the programm requirements

    - cost ratio related to the "element", which is used when making the structural design

    - cost ratio related to the "component", which is used when finetuning the design

All eight sets of agreements are related to each other. Don't expect to understand and see all relationships at the first glance. But believe me, once you get the hang of it, it is a very usefull tool to keep your budget under control. And if you have any questions, just ask !
 
Kind regards,
Peggy