Cost Estimating Walls

[PaperStreet SoapCO]

Ok - I've been trying to figure out how to do a complete cost estimate of a model inside of Revit. I'm not really trying to determine studs, nails, etc. but just the general volumes, lengths and heights of things. So I am testing out the walls first. (I am assuming I could make a multi-category schedule and incorporate everything in one at some time right?)

I've looked at this link: http://forums.augi.com/showthread.php?t=12452&highlight=cost+estimating

It looks to work alright but for some reason my if I put in a cost in the wall type - it comes out in the schedule multiplied by 4! I have no idea why. And on top of that - the volume isn't calculating in my schedule for all of the walls but one.

Anybody else tried this before?

[PaperStreet SoapCO]

Ok, it appears that the walls are not just multiplying by 4 but some are by 16 and another by 2. I find this very odd.

[dhurtubise]

Can you post the file. I just ran a test and all walls shows with they're volume

[PaperStreet SoapCO]

Sure, but AUGI says that the file is too big. Know of any way I can get the file uploaded?


As a side note - it appears that the number that the number the cost is multiplied by grows larger as the number of instances of that wall in the project grow larger.

[dhurtubise]

Email me at daniel.hurtubise@@lemaymichaud.com

I'll set you up on the FTP

[robert.manna]

So I am testing out the walls first.
Three things...

1.) If you talk to the guys at Autodesk who are into this kinda thing, they'll tell you that walls are one of the hardest things to do estimates on. Its much easier to start with like doors, windows, curtain wall, heck even floors & roofs.

2.) If you're super serious about getting into quantifying and estimating based on the model, you should talk to your re-seller to talk to AutoDesk, or contact your AutoDesk sales rep directly, and tell them you want to get into cost estimating. Autodesk Revit has guys who specialize in this. On top of that, outside of the programs that integrate direclty with Revit for cost estimating the generally accepted form of doing good estimates is to extract scheduled data out of Revit in one of two ways, either with ODBC export (which directly extracts all the data out of a model), or setting up multiple schedules (not a single multi-cat), and exporting the schedules to excel, and plugging the qauntities into pre-set excel sheets that do the actual estimating. There are lots of reasons for this, and the Autodesk guys have developed some customization to all make it easier. Phil Read would probably argue for doing it all in Revit, but this time I have to disagree (at least until they improve Revit some more, :) ).

3.) If you are super serious, as above, find a real cost estimator to work with you. Architects have done an aweful lot to seperate ourselves from cost estimating, so having an expert to help is a good thing.

My .2 cents,
-R

[PaperStreet SoapCO]

Thank you for the reply. I guess the reason I tried walls first is because I came across a post here on AUGI that was explaining it. It would be nice to get the harder part down first and then move on the easier stuff.

I actually would like to try to get it all done inside of Revit. The reason for this being is my boss was actually amazed when the cost / quantification could be updated live as the things were changing in the model. Currently, in Archicad, we export a quantified list of elements to an Excel spreadsheet that a cost estimator had set up for us. That spreadsheet then does all of the calculations for cost. We could do that with Revit too, and that would be no problem, but its easier for me to get them to switch if Revit not only matches Archicad in this department, but exceeds it.

Plus, I like the idea of having as much information in one file as possible. A true building information model.

[robert.manna]

Not knowing a whole lot about ArchiCad, I don't beleive that it supports an ODBC export. Basically you're converting the Revit database into an open standard database that can be "read" and opened by most Database programes, like Access for instance. The logic behind exporting is the same as what you've run into in Archicad, the cost estiamator gives you an excel sheet to "plug the numbers into" this makes sense, give that unit costs are always changing. If you have 5 projects in Revit, and you're doing cost estimating on all of them, would you rather;

A) go through each model's schedules and update cost info.

or

B) update one master set of excel sheets that each project uses to determine units costs, and then spit out estimated costs of a project. Take it to the level of ODBC export, and now you just plug the project database into the cost database, and everything just runs.

In this case I don't know that I would worry about selling Revit as superior, I would just point out that it supports the kind of workflow that makes the most sense from a cost estimating stand point, and managing all the assoicated data, and perhaps does an even better job, considering how easy it is to set-up and maintain schedules (most especially since you can now save out a pre-set schedule from one project and re-load it into another project, course this works for A too) as well as being able to export an ODBC compliant database. A) would work really well if we could have Revit reference an outside source to pull information like unit costs into a project.

-R

[PaperStreet SoapCO]

A) would work really well if we could have Revit reference an outside source to pull information like unit costs into a project.

Yeah, this is the kind of thing we were ultimately looking for but I dont think it exists in any form of BIM software yet. Again, it would be really nice if this could all be contained inside of one file.

The excel spreadsheet idea is fine except I'm not really fond of exporting 10+ different schedules each time I wont the excel spreadsheet to update our costs. I suppose a mutli-category schedule could solve this and export all things quantified at once. Is this possible?

[PaperStreet SoapCO]

Ok, just to wrap this whole thing up. The problem was that the column in the schedule for cost per cubic foot was calculating totals so it therefore gave me the total number of instances of that wall and multiplied it by the cost parameter in the wall family.

Wow, do I feel pretty lame. Oh well, live and learn.

[robert.manna]

Ok, just to wrap this whole thing up. The problem was that the column in the schedule for cost per cubic foot was calculating totals so it therefore gave me the total number of instances of that wall and multiplied it by the cost parameter in the wall family.

Wow, do I feel pretty lame. Oh well, live and learn.
Don't you hate it when software does exactly what it's supposed to :). We've all been there. :)

G'Luck
-R