Creating Preliminary Budget Models with FF&EZ

Posted by jimcarls on October 24, 2011

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.

0 Comments Read full post »

Previously, we've shown that an "all-in-one" spreadsheet approach to documenting FF&E specifications is cumbersome and hard to keep updated, In the second segment of this series, we looked at how designers naturally turned to a more "data-oriented" two-part approach that was also a step towards a more efficient way to organize data.  That method, called "normalization" by your local Nick Burns types, is fairly strict deconstruction of data into "tables" similar to filing cabinets, each holding either a specific type of unique data (like "rooms" or "vendors") or a type of relationship (like "objects in rooms"). Below, we will finish the deconstruction process and then put it back together, but this time, without having to repeat data.

0 Comments Read full post »

In discussing the limitations of "document-oriented" thinking in the last segment, I discussed one end of the range of ways to organize FF&E specifications data — looking at a sprawling, "all-in-one document" approach that recorded all the information about a project's FF&E specifications and their use in a spreadsheet.  In this one, I will look at how the search for more efficient ways to create documents takes us in the direction of a very specific way of organizing data.

0 Comments Read full post »

Data-orientation vs. Document-orientation 1: Introduction

Posted by jimcarls on September 5, 2011

This series of posts helps you move from being a "document oriented" user of word-processors and spreadsheets to a "data oriented" user of a database like FF&EZ. Databases can make the documentation creation process much easier to manage. You can take advantage of that by understanding how data is organized in a database and losing your document-oriented thinking habits.

0 Comments Read full post »

project_spreadsheet_product_sheet.png

Personal computers became the dominant type of computing device for a simple reason: They handed actual computing power to the business people "in the trenches," allowing them to develop their own solutions to common problems — problems that had been long beneath the interest (and outside the funding) of corporate IT departments.  This group of self-taught power users is known for having two qualities:  1) an informal training in software design where they very literally learn from their own mistakes and 2) an understanding of the problems they want to solve that cannot be matched by the average graduate of a math sciences curriculum. For FF&E specifications, this has produced methods that often use some combination of word-processing and spreadsheets to collect and tabulate the FF&E data in a design project.  This is good (because it's so much better than inching a preformatted sheet through a typewriter — remember those?) and bad, because there is much more efficiency to be gained by using more powerful solutions.  In this entry, I'll compare the use of these approaches to using database software.

0 Comments Read full post »