Creating Preliminary Budget Models with FF&EZ

A common approach to preliminary budgeting uses a spreadsheet grid of FF&E items, room types and budgets to create a "ballpark" FF&E budget for a proposed building.  This post discusses how you can accomplish the same objective with FF&EZ but with a live link to the underlying data, so that the same budget tool automatically responds to changes in item budgets and can then be compared to vendor prices as actual product selection takes place.

One of the first exercises an architect or designer may go through in feasibility planning or budgeting is to estimate the cost of FF&E in a building, especially if the building is one that typically has a common set of repeating room types in it.  Although the "roughest" version of a budget may be based on a simple "cost per area" target (e.g., $50.00/sq ft or €120.00/m²), the next step might be to determine room types and room counts and "populate" those rooms with the expected quantity of generic "objects" that fulfill a specific function ("dining chair") at a desired budget amount.

One common approach for this is to create a basic "schedule" type spreadsheet with a list of common FF&E objects on the left side and columns representing different types of rooms, with a quantity entered at the intersections of the appropriate rows and columns to indicate how much of that object is used in a particular room.  A quantity total column and an object budget column on the right can then be added to create an extended total that can then be itself totaled to get a preliminary budget.

With some planning, a spreadsheet like this can be saved as a prototype at a certain point in its development, so that it is easier to start a new project budget by opening the spreadsheet and using "Save as..." to create a new instance.  This approach is useful, but it also suffers from three problems:

1. The number of all possible objects and room types can quickly turn into an unwieldy expanse that must be viewed and printed in sections. With a reasonably large project, you may have a section where a particular room has most of its contents visible on one page, but some types of FF&E in it occur much further down and/or on a separate page.  As this happens, you start to lose the advantage of this approach in comparing one room to another and in seeing the "whole" room.
2. For more unique projects, the rows and columns of a prebuilt template may need to be deleted, replaced or expanded, which introduces the possibility of fomula errors in making the adjustments.  This is particularly true if someone who is less familiar with how formulas work uses the template.
3. A spreadsheet constructed like this is "dead" as soon as actual product selection and pricing begins, as design decisions are made, room contents and counts are adjusted and prices determined — unless you return to the spreadsheet and update its contents with prices you have also entered elsewhere.

What if you could instead create a budgeting template that allowed a project budget to be estimated from pre-built data like the spreadsheet above, but allowed you to easily see all of each room more easily, automatically did all the math for you and always showed the budget in relation to the current state of the specifications because it was still a "live" part of the data? All this is possible with FF&EZ:

• FF&EZ allows you to create a prototype project containing rooms (organized by major areas) and the standard FF&E content of those rooms as "objects" which are in  themselves prototypes.
• Each FF&E object can be assigned a budget (estimated cost) in its "Budget" field.
• Each room can have a "Room Quantity" which is the number driving the "room mix" or "room count." The rooms also have a "Budget" field for the target cost per room, and if you have a room area (size) to enter, the target budget can be calculated based on a target cost/per unit area (e.g., $/sq ft or €/m²).
• Since FF&EZ projects can be cloned, you set up the project once, then clone it, similar to the way you would open a spreadsheet template and use "Save as..." to create a copy for a new project.

This matches the amount of data needed for a spreadsheet used to create a budget for a hotel (except FF&EZ forces you to enter a "unit of measure" to avoid any confusion).  To create a building model in FF&EZ means to simply add the necessary objects to each room with the quantity needed (or zero if not known).  But because FF&EZ has the flexibility of a database, much more is possible:

• When you create prototype objects for the budget template, you can automatically attach one or two skeleton specifications (e.g., a chair and anticipated fabric spec). These can be detailed later or replaced with existing specifications from elsewhere in the system. If you take advantage of FF&EZ's "prototype" feature for specs stored in the Library, these skeleton specs can be automatically pre-filled with any desired boilerplate text for that product type.
• Both the spreadsheet model and the equivalent FF&EZ model can be used "as is." However, any changes that might be needed to adapt a spreadsheet model to a new project (such as adjusting the room mix or specific budgets) can be done just as easily on the FF&EZ project's source screens. So the FF&EZ project presents no more of a challenge to get a budget estimate for standard building types. Just like a spreadsheet model, using the template for a new project would be simply a matter of copying it. However, FF&EZ also allows the user to add or delete room types (and add or delete room objects) from the copied template without danger of corrupting the template itself or any formulas — or any need to create new ones.
• You can create prototype rooms and import them into the model if a particular room type is needed and exists in another model project.
• Building on the last point, you can create an estimate for a smaller project (or any project) by starting with an empty project and importing only the model rooms that you need for the current project (note that you can just as easily import a completely finished room from any other project).  With this technique in mind, a prototype model can be "overloaded" with many room variations. You only need to import those you need into your current project model.
• The spreadsheet's ability to show you all the rooms where an object is used is duplicated in FF&EZ by simply sorting its FF&E Worksheet by the object column. Unlike the spreadsheet, FF&EZ's screens do not show a lot of wasted column space for items that are only used in one or two rooms.
• Where the spreadsheet template only prints a single format, a simple FF&EZ project template can still generate a budget detail report, a budget summary report, a room content report, an object location report and a quantity take-off of everything in the project. For people who are creating proposals based on their own knowledge of typical prices, there is also a "Quote/Contract" format that uses the number you enter into the object budgets instead of product prices to produce a proposal.
• Since FF&EZ's query tool is available, any report from the preliminary budget model can be limited to any subset of the data you wish to define.  This allows reports based on specific building areas or rooms coded to a phase or even proposals that eliminate a certain product type that the client decides to purchase elsewhere.

So, FF&EZ is able to accomplish much more than what a simple spreadsheet can do with basically the same amount of effort (and with no need to create spreadsheet formulas at all).  Yet, because the template would already link to skeleton specs, the original estimate of the cost would be automatically comparable to actual costs as product specifications were later detailed or imported from previous projects. The reports printed during the budget estimation phase would simply become more and more accurate (the latest version of the "Budget/Price Comparison Report" allows you to substitute a budget amount for unpriced products, so the report can still show evolving budget status when pricing is not complete).  On the contrary, the spreadsheet, because it was a standalone document with no links to the developing data, would never reflect anything but the original estimate without doubling data entry to update it. It should be clear which approach yields more results from your effort.