Guest Author: Bert Craytor, SRA
- Software Engineer Certified General Appraiser California Real Estate Broker
Many appraisers have complained about the use of standard forms such as the URAR, especially with regard to complex residential appraisals. The existing categories are often too simplistic and the grid is of a fixed size and format. For example, there are not enough blank rows in the associated sales grid to insert property factors that are important in valuation. Complaints about the use of forms are most common on the AI forum, where several SRAs and MAIs have, over the years, stated that they only do narrative reports for that reason.
The problem is that the design of appraisal forms is still based on outmoded paper forms. The restriction is nowadays artificial and meaningless. Computer software has shown time and again that it can easily handle processing of flexible forms that allow users to insert arbitrary numbers of rows and even columns.
For example, this is a common feature in order processing software– where parts and components can be added to order forms in some fairly complex ways. Peoplesoft, where I worked for a number of years, became successful largely through Microsoft Windows based software that allowed users to modify and design forms back in the early 90’s.
Well over 95% of appraisal forms are handled by Microsoft Windows based computer software provided by vendors such as Bradford Technologies, Alamode and ACI. Because of this, there is really no inherent limitation as to how forms can be designed and modified by end users, other than what is imposed by regulations and guidelines.
What is possible with regard to appraisal forms? For the sake of simplicity, I will restrict this article to a brief discussion of Sales Comparison Grids – noting that the same considerations apply to Cost and Income related grids.
While spreadsheet software such as Excel allows nearly any kind of grid to be created, a robust grid with built-in intelligence has to be written by software developers. The common tools for such software development in our field are based on Microsoft .NET and third party components such as ComponentOne, Infragistics or DevExpress.
To see what is generally possible, just visit the websites for these companies and view their demos.
http://www.devexpress.com http://www.infragistics.com http://www.componentone.com
You will see that grids can be created that allow pictures, graphs and text to be embedded in cells, such that a click brings up the associated attachment in an editor. Pictures can be shown in the grid as thumbnails or easily hidden from view by clicking the associated row, where the usual “+” indicates whether details under the row exist to be expanded and a “-“ indicates that a given row is already fully expanded and can be compressed by a single click. It is possible to copy pictures and text for sales comparable from the MLS and paste them into the grid. Even virtual tours could be copied and pasted to the sales grid.
The entire workfile can be embedded in a grid. In fact, such grids serve as an optimal way to organize the workfile – there is no longer a need to go searching for the picture for Comparable #3, because it is right there in the grid in the column for that comparable. In fact, just about all information for Comparable 3 can be embedded directly or via a link, in the associated grid column. For example, the front street pictures for each of the comparables can be easily placed under the address headers, followed by a row with a copy of the MLS page. In fact, you can create a row for each kind of picture that is available – including aerial. A button click can make all attachment rows disappear, so that you only see the standard grid.
Why don’t we already have such software for dealing with grids? It’s a question of profitability. Software developers need to know whether there is sufficient demand for such a product, to proceed with development.
There has long been a demand from some advanced appraisers who do complex appraisals for something better than the traditional grids, but the major roadblock has been the regulated use of standard forms. If that roadblock were removed, then the question still remains as to whether there would be enough demand for a flexible grid product to make development worthwhile.
Let’s assume for the time being that demand is sufficient and that the only roadblock is regulatory. As a software engineer and appraiser, who has built such software as far back as the early 90’s, I can assure you that all of the following is completely doable:
1. The ability to insert new rows into the grid and give them a name based on a drop down of selected features (e.g. Cottage GLA, Swimming Pool, Tennis Court, ….).
2. The ability to delete optional rows.
3. The ability to inject different adjustment models into the various rows, e.g. non-linear adjustment models for GLA – that pop up graphs. In particular, MARS type models can be created through specification of contribution functions from regression analysis, or manual creation by simply creating and dragging graph points based on slopes that replicate $/unit adjustments that appraisers wish to use for selected ranges of values. Using the models (i.e. functions), the computer can compute value adjustments as the difference between contribution values between each comparable and the subject property.
4. The ability to add or delete types and categories to or from custom dictionaries for different property types.
5. The ability to define hierarchical relationships for such types and categories. For example, the group “Bathrooms” can be created to summarize detail rows represent any number of master, full, half- and quarter bathrooms. Details could include whatever the appraiser considers appropriate. Clicking on the summary will expand or hide the detail rows.
6. Selective compression and expansion of feature groups, to make the grid more readable and allowing the appraiser to focus on working with one or more selected groups at a time. For example, as with #5, we would probably want to summarize the adjustments and total count for all bathrooms in one row.
7. The ability to insert pictures and text (including html, rich text and pdfs) into cells. For example, you could put MLS pictures of the master bathroom for the subject and each of the comps behind/under the adjustment for the master bathroom. You could also grab the MLS description for a property and stick it behind/under the header for each comp. Clicking on a row with attached pictures would dynamically expand the photos into view. If anyone asks you why you made such an adjustment – you have the evidence at the click of a mouse button. Click again to hide them.
8. The ability to check which rows should go into the final report and which remain as part of the workfile supporting documents.
9. The ability to define intermediate calculations based on entering formula into rows and cells, which makes it possible to split an adjustment up into detail rows and only use the intermediate sum in the report grid.
10. Of course, the definition of templates to make any grid design reusable or extensible for other property types or situations.
11. Other …
This kind of software is possible and of course exists in many non-appraisal products. What is needed are new guidelines that would define:
1. Required grid components such as Sale Price, View, GLA, Heating Type, Net & Gross Adjustments.
2. Pre-defined optional components, such as Kitchen Upgrades.
3. Rules on allowing appraisers to define and create new optional components for the grid, such as detail features.
4. Rules related to handling the detailed breakdowns of components. For example, the appraiser may choose to separately treat the master bathrooms from secondary bathrooms in high end homes, by having individual lines for the master and secondary baths and then summarizing the adjustments.
5. Rules related to the digital representation of the sales grid: Does it remain only in the workfile – or would lenders be given access?
In my opinion, it is likely that a simplified version of the digital representation will be provided to the lender – via export to an XML based file and appropriate software drivers for import into the lender software.
Understandably, the above just scratches the requirements for what is possible, what is needed and the work to be done. However, regulators and appraisers should start thinking in this direction – as it opens the doors to more sophisticated and rational handling of complex appraisal assignments.
By the way,if you are wondering whether this kind of software exists, it does - in the research labs of certain software developers. It undoubtedly still has bugs, and certain issues such as cross-referencing of attachments have to be handled. Integration, export, QA testing and other issues have to be dealt with.
Author: Bert Craytor, SRA Software Engineer Certified General Appraiser California Real Estate Broker
Recent Comments