Frequently-Asked Questions about Modelogix
Modelogix is a fantastic tool to add to your estimating department. Not only does it allow you to compare past project estimates with your new estimate and check for scope and variance, but it also allows you to create compelling Owner reports highlighting your project expertise. Plus, it works with every construction estimating program in the market, even Excel!
Read through the questions we've received from other GCs and let us know what questions you have.
Q: Does Modelogix work with Timberline, or does it require an Excel export of a Timberline estimate as an intermediary before import into Modelogix?
A: It would require a Timberline export. In Timberline Talk, you could take any one of your spreadsheet layouts and, instead of physically printing that layout, you would create an Excel file from that layout and then create a Timberline import template in Modelogix to repeatedly bring in the Timberline Excel output. So anytime you have a final estimate that you want to bring in (this would be true of any other estimating system), you would just print that report to Excel.
Q: What can you do if you're working in Revit? How is this data collected?
A: Revit is a BIM modeling application, so you would need to extract the quantities and create an estimate first. A great solution to do that is Vico Office. But just to clarify: when we say, “build a cost model,” we mean to develop an estimate based on past-project costs for material, labor and equipment. We don’t mean to build a BIM model.
Q: When you update a budget structure in Prolog, there is a utility to change all of the existing budget codes to add the new information. Is that something we can do with other estimating systems as well, and then Modelogix can then read that?
A: When you want to bring cost data from outside Modelogix into the Modelogix database, you will need to reorganize the coding structures prior to the import into Modelogix. Any kind of data scrubbing or reassignment of codes would not be something you would do after bringing it into Modelogix; it would be done prior, and then you would map to that reorganized spreadsheet. So you would go ahead and make those reassignments (using Prolog, for example), print your Excel report and then bring it into the Modelogix database.
Q: You mentioned mean, median, minimum and maximum unit-price breakdowns. That is really based on past estimates -- not on actual completed data. Would you have the ability to incorporate completed project actuals?
A: Absolutely. When you import costs, Modelogix is not going to know whether that imported cost (broken down by your user-defined breakdown structure) is an estimated or an actual cost.
You are just importing cost per project. The attributes that you're going to set up are estimated costs or actual costs because, ideally, what a company would do is bring in both.
So if I have a project that I create a final estimate for, I can bring that in to Modelogix and then attribute it with estimated costs and then, two years later, when the project is complete and I have access to actual costs, I would import those actual costs into Modelogix. Most of the attributes would not change; the only one that would most likely change is estimated to actual cost. So I actually have that project in my database twice and, when I go to build the model, I get to choose whether to model off the estimated cost or actual cost. And Modelogix allows you to do both.
Here's a video snippet that explains how to filter the construction estimates by project attributes and then benchmark with pricing variance thresholds.
Caption: Modelogix allows estimating departments to quickly locate past projects based on similar attributes and then normalize the costing data according to an inflationary index or geography-specific pricing. By organizing these past projects, estimators can create new cost models to supply feasibility budgets, benchmark new estimates looking for any pricing variance, and even sanity-check a new budget to make sure that all scope is covered. By better understanding cost variances, estimators can better identify project risk, suggest value engineering, and even present multiple options to the Owner.
Q: It appears that everything is based on unit cost. For example, a single input of square-foot cost. What if my parametric modeling requires multiple input variables and a more complex regression function?
A: When we looked at the exterior shell, the unit of measure was not based on a job unit; it was based on the square footage of contact or surface area of the shell of all the structures that were pulled into that model. Every one of the rows in the model could have a unique unit of measure by which I model. So let's say, for my CSI division for steel, the unit of measure does not need to be some square foot number, it could be tons of steel. Maybe, for Division Three/Concrete, I want to model off of the total cubic yards of concrete on this project. Every one of those rows in the model can have a uniquely different unit of measure that makes the most sense to model from. And those units of measures and quantities do not need to be manually keyed-in. They can all be brought in as a byproduct of your import. So those quantities and those different units of measure can all be imported and, when I go to build the model, all of those unit prices will be driven from their respective units of measure.
Q: Would you have to create multiple models for various stages of estimating and then the actual cost?
A: You don't have to by any means. Some companies will import final estimates into Modelogix and they will import the final actual costs into Modelogix; that's just their workflow, that's what they do. So if you looked at their list of projects, they have the model represented in Modelogix a couple of times -- one estimated cost and one actual cost. We do have customers who bring estimates into Modelogix when it is a level-one estimate, and then maybe when they have 50% complete drawings, they bring those into Modelogix, too, and they might want to build a model when they were all at the same stage. All of that is possible. So there is no limit to the number of times that a project can be brought in. A number of companies may say that estimates move through four or five distinct phases of the estimating process and we're going to import that estimate into Modelogix as it goes through the gate from one phase to the next -- and we're going to categorize it accordingly. So now, when I search the database, I can say, “find me all stage two healthcare projects,” and I want to build a model from projects that were at that stage.
Q: We use WinEst. For an actual cost, what is the best way to capture change orders?
A: If you use actual cost as opposed to estimated cost, then a lot will depend on which tool you use to manage the project to completion. So if I create an original estimate in WinEst and I push that over to my project management software, and then create a change order later, most likely in WinEst I create that change order as a separate estimate. Then I can use that and transfer that budget over to my project-management software, as well. But at the end of the day, if I am capturing actual cost in my project-management software and that's what I want to represent in the Modelogix database, I would take the resulting actual cost out of my project-management software and I would run a report that shows me, plus or minus by a percentage, by cost budget code, how we performed on that project. I would then go back to the WinEst estimate and I would sort my estimate by cost code, then I would adjust those items that are assigned to each cost code by the same percentage plus or minus according to how we actually performed on that project. Then I would bring the result of that in to Modelogix.
The reason I would do that is because, typically, on the estimating side, you have a much richer work-breakdown structure for a project than you do in project management or accounting where it's not uncommon to have thirty items in an estimate feeding a single cost code. So when you bring information just organized by cost code into the backend database, of course that's going to be your limit for modeling; you're going to have to model based on cost code. If you take the cost code information, update the estimate and bring that into Modelogix, now you can model based on CSI, UniFormat, etc. and the work-breakdown structures that were used by the estimating department are now available.
Q: Is the format of the report a Word document? Can you PDF it?
A: Yes, you can PDF the output. It is not a Word document, however; it is a proprietary Report format.
Here's a brief description of how the reporting feature works in Modelogix.
Caption: Reporting in Modelogix is very easy to set-up and design. Report templates consist of project images, charts, graphs, side-by-side comparisons, and even cover sheets and a table of contents. Users can create any layout they want and populate the data from their cost model and comparable projects. Owners appreciate seeing this project experience alongside the estimate in a format that is easy to read.
Q: Would this solution work on an infrastructure set of documents as well?
A: Absolutely. In fact, if you if you think of the work-breakdown structures that we were looking at, you can imagine this working on an infrastructure or even a DOT project where everything is organized by a standard list of bid items. Certainly, bid items could be one of my work breakdown structures, so I could have five or ten years of cost experience for various projects all broken down by DOT code or infrastructure code or whatever you may want to look at. And now I have the ability to model off those codes just the way we looked at here. So I could look for five projects that were infrastructure-related, and analyze those costs across those five projects -- and how I analyze them could be tied to whatever coding structure I've imported. Again, it could be as simple as Washington State DOT code. So it is completely flexible that way.
Q: Have you developed a way to connect this to a BIM model?
A: There is a direct connection to most BIM models through Vico Office. And, of course, if you create an estimate in Vico Office, you can connect it to Modelogix. So you can keep it in the Trimble family and get everything you need there.
Q: Modelogix looks like it proposes UniFormat up to level 3 -- is that correct? I'm using Vico Office and use the UniFormat system up to level six, so would I be able to use Vico in conjunction with Modelogix?
A: Absolutely. Actually, Modelogix will go N levels deep; there is no limit. So if I have a work-breakdown structure that is ten levels deep, it's not a problem.
Q: Can I import SQL data directly from an existing SQL database?
A: Not really. This is not recommended as it would be extremely difficult to adhere to the underlying logic in the database. Modelogix handles all of this through the import feature.
Q: How does this integrate with Vico?
A: You would take your Vico Office project data and drop it out to Excel or XML. We've created a tool to take that output from Vico, and I use the term “flatten it out” – this means we would "educate" the Excel template where things are located.
Q: Will the addition of Modelogix to Trimble Buildings affect the estimating comparison abilities found in Vico's Cost Planner?
A: The tools are somewhat different, in that Modelogix is based on being able to get data from any source and Cost Planner works within the Vico Office environment. From a customer perspective, the goal is to not take any existing functionality away that you enjoy today.
Q: How are databases set up if you are just starting fresh, with new projects?
A: When you initially set up a Modelogix database, you basically have a shell -- essentially an empty database. And you might first -- before you even pull projects in -- have the discussion about what attributes you are going to assign to those projects after they have been imported. So you may want to lay that out and set up those Smart Categories.
But here is an important component we think is a huge time saver. Let's say I have no projects in my Modelogix database right now. I am getting ready to import my first one, and there are 400 CSI major division codes that are associated with the project that I'm getting ready to bring in -- with all the costs behind each of those 400 codes. Through that import process, you can point to that file, bring it in to Modelogix, and Modelogix creates that work-breakdown structure (that tree structure that you see). It creates it as a by-product of the import. You never manually go in and create those work-breakdown structures; they are created as a by-product of the import. And if the second project that you pull-in had an additional thirty cost components that didn't exist on the previous project, those would get added appropriately. In other words, they would slot right in where they were supposed to, based on your numbering scheme. So, from a work-breakdown structure perspective, your database gets created just as a by-product of your import.
Here's a quick overview of set-up in Modelogix.
Caption: As with any database, it is critical that data is entered cleanly with a pre-defined nomenclature. The Modelogix attribute filter allows you to do this. Another key concept is normalizing your project cost database to inflation and location. Again, the Modelogix set-up allows you to do this. This means that importing past projects, searching, and reporting data is available immediately for your new cost models.
Q: Is there any automatic link between the work-breakdown structure tables that exist in WinEst and those that exist in Modelogix?
A: Yes, absolutely, if you are using WinEst as your estimating tool and you click on the Import WinEst button. We are able to look at an estimate and we are presented with all of the work-breakdown structures that are utilized in WinEst and you see that. And you can determine which of (or all of) those work-breakdown structures you want to use in Modelogix. So there's absolutely a relationship! However, you are not forced to use them. A single item in an estimate might be assigned to a whole host of work-breakdown structures, but maybe in Modelogix we choose to model off of five of the ten that are being utilized in WinEst. That is completely under your control, but obviously, we know how to reach-in and analyze what's in that WinEst estimate, so we present you -- even when you're creating the database -- which work breakdown structures you want to use.
Q: The examples you showed used unit-cost per building square foot to compile an estimate. I imagine other types of units are also supported?
A: Every work breakdown structure can have a unique unit of measure. It doesn't have to be based on the square footage of the project. The example that was shown was the square foot of contact area for the shell of a building instead of the interior gross square footage. Cubic yards of concrete, tons of steel -- all are completely user-defined. Whatever unit of measure you think makes the most sense for analyzing cost is all under your control.
Q: Can the parent line items with an overall unit cost incorporate child items with different unit costs?
Q: Is Modelogix client- or network-licensed for users?
A: It is based on concurrent usage. So if you only had three people you would want to give administrative rights to, but would only have two in there at a time, you might buy two concurrent administrative licenses. You may have a department of thirty estimators and you might say we would never have more than fifteen using Modelogix at one time, so you could buy fifteen concurrent uses of the standard license. And those can be utilized by anyone in the organization up to the point that you hit that limit. And, as you know, with concurrent licensing, if you receive that message that says that those licenses are in use, you can just purchase an additional license -- and those additional licenses can be easily added over the phone.
Here are even more resources to help you learn about Modelogix: