By Gerard Heinz

For most lenders, the technology buying process begins with a Request for Proposal. Unfortunately, the resulting documents rarely provide enough information to accurately determine which purchase decisions are most likely to benefit the company and have a true effect on the bottom line. In Part I of this article, we addressed the importance of taking time to develop and refine an RFP for distribution to vendors and why it is the gateway document to building a solid lender-vendor relationship. Part II will discuss the typical sections of an RFP, examination of the responses, what conclusions you can draw from it, and what information will help you make a more educated buying decision.

When a response to an RFP is received by the lender, the real work of evaluating potential candidates for a long-term partnership begins. Prepared in accordance with the instructions of Part I, the proposal should relate directly to the lender's needs and provide specific examples of the functionality required in the new technology.

Only by carefully considering all of the vendor responses can the lender make a good decision about the next step in the process. By looking at some of the core sections of the typical RFP, lenders can uncover important information about competing vendors. The key is to understand exactly what is being asked and paying attention to how it's being answered. Is the vendor telling you the truth, or are they daring you to believe their answers? Let's examine some of the common sections of a well constructed RFP.

Vendor Company Information
When it comes to large-scale technology implementations, the lender is not merely purchasing a product, but rather entering into a long-term relationship with the vendor company. Therefore, it is especially important to evaluate the infrastructure of the company itself.

The lender must determine whether the vendor is a true product company or a custom development shop, whether the firm is set up to deliver a core product that meets the basic needs of the lender out of the box, or if the product is a tool kit with significant custom development needed to implement even the basic functionality. There is a very big difference between having to configure a system and having to customize a system. The mortgage professional needs to determine where they want to spend the majority of their time and base the decision on budget, resources and the desired implementation time frame.

There are many other questions that you need to ask in this area. Does the vendor have a product vision or is the product direction dictated solely by customers and regulatory changes? How does the vendor handle upgrades in technology? When enhancements occur is the current version able to implement these changes or do you have to re-implement a new product that includes the new technology? Does the vendor have a dedicated product management staff? Does the vendor do performance testing on the application and are these results published? What is the nature of the firm's ongoing product support? Does the company maintain a fully staffed and qualified help desk? Are the maintenance fees invested back into the product or into the company's pockets? Do they have references to indicate how effective this team has been in the past?

Customer references are invaluable, but even these must be scrutinized. It's not enough to just learn who a vendor's customers may be without learning exactly what the vendor is doing for them. Are these referenced clients using the same system the lender is evaluating? Are they using it in the same manner that you plan on utilizing it?

Vision For The Future
A company's vision is incredibly important. However, with most companies the vision is either nonexistent or simply a showpiece that is not truly followed. First you must determine if the company has a vision and what it contains. Second, look deeper and see how they are incorporating that vision into their company/product direction. What does their product roadmap look like in one year, two years ... five years? The company should be proactive to industry changes not reactive. The vision should be the framework in which their product is evolving technologically. Is the vision validated by their customers? What is the vendor history of major releases?

It is critical to evaluate the direction of the vendor company against your company to ensure you are on the same path. Better yet, if you can find a vendor that will partner with you and help lead your technological progress you are one more step ahead of the game, giving you one less thing to worry about.

Technology Architecture
Today, it is very important to know what architecture a system is built upon, as it is the foundation of the product. Here it is crucial to ask specific technical questions. The lender must request an overall description of the architecture, as well as a visual representation. The lender should have access to a professional with enough technical expertise to analyze this information. If the buyer lacks qualified internal staff, a third-party consultant can assist in evaluating the architecture.

Many vendors utilize buzzwords to describe their application - SOA, MISMO compliance, etc. What do these mean? Is there a truly n-tiered architecture in place and are the tiers actually separated? Is there direct access to the data tier from the presentation layer? What is there security between the various tiers?

If the application is SOA, what does this mean to the lender? How many API or Web services are exposed? Are the APIs consumed by the vendor's application? This will help the lender determine if the APIs are working and appropriately integrated.

What is the vendor's track record for upgrading the technology platform? Does the vendor historically introduce a major technology change as another offering which requires a significant capital expenditure for migration or purchase or does the company migrate technology changes within its existing product offering.

The lender should pay little attention to common technology buzzwords and focus instead on the benefits realized by the architecture. Finding out exactly how the system interacts with existing internal services, and of equal importance, with external partners. Additionally, the RFP response should include detailed information about how the system is designed to interact with other new and/or legacy systems.

The technology should also be constantly advancing. Many product offering architectures do not have the ability to incorporate new technology within their current application. Instead they create what I refer to as a wrapper which is the true definition of putting lipstick on a pig. This is a key area that you need to concentrate on when evaluating the company's architecture. Can it truly evolve and have advances absorbed into the existing product offering without forcing you to move to a new platform. There are a lot of good looking pigs in this marketplace, don't be fooled by their exterior.

Performance and Scalability
The RFP should request specific, verifiable information regarding the systems' proven performance, as well as demonstrated and expected scalability. The vendor should be able to provide descriptive testing results and statistics. Do not accept an answer that simply indicates that the system in question will scale.

Third-party testing is an obvious plus, but lenders should also determine what type of, and at what frequency, testing is being done in-house by the vendor. The best technology providers are continually enhancing functionality, and as such should be employing ongoing stress and scalability testing using industry recognized tools. Lenders should know to what extent this is occurring inside the vendor's shop and how they can continually monitor and test the system once it is implemented.

Integration and Extensibility Capabilities
Most vendors will tell a lender that they can integrate their system(s) with any and all other systems and applications. Given the necessary resources, this is true for any system. However, this is a misleading answer for the lender that desires rapid and seamless integration with no compatibility issues with future releases of the software. The key is for the lender to ask targeted, precise questions regarding elements essential to successful integration.

First, does the system's architecture lend itself easily to integration and extensibility? Does the vendor follow industry recognized data standards? Does the vendor have a clearly documented mechanism/tool, for example, a software development kit? How easy is it to customize the application - add new screens, fields, etc.?

If there is an SDK, it should be fully documented, with import, export and interface frameworks, as well as definitions of exposed components that are understandable. The kit should contain checklists and samples to guide the lender's IT team in developing the code should they desire to extend the system on their own. A fully documented SDK validates that the architecture itself will support integration and that there are tools allowing the software itself to facilitate those integrations while retaining backward compatibility.

In addition, the vendor should clearly establish the process involved in system integration and extensibility. How is this achieved? Often, a vendor can respond truthfully to the question of integration but still neglect to explain in detail the complexity, length of time, resources or expense involved in the process. This will cost the lender time now and in the future during the implementation phase.

Knowing who can perform these functions is also important. Will vendor resources be required, or is it something the lender, given the training and tools, can do themselves? Is there enough documented information provided to accomplish that or is it something that must be undertaken by the vendor?

Software and Hardware Requirements
It's important for the lender to have a good understanding, upfront, of what the additional hardware and software requirements of the new platform will be. Often, platforms require additional resources to fully deliver promised benefits. To calculate total cost of ownership, these elements must be taken into account.

Too many times, lenders have bought into new platforms only to learn that they were faced with the additional cost of upgrading an entire office to a new version of another software package or additional hardware before they could access the full functionality of the system. The capital expenditure related to this facet alone - one often simply left out of pricing projections at the RFP stage of the process - can sometimes be as significant as that of the system itself. Having a clear idea of what sort of capital expenditure will be involved in preparing for the new system will allow the lender to make fully informed cost-benefit ratio projections.

Support Structure & Training
A good RFP will also ask for copies of the vendor's usual service level agreements. It's important to understand what will and will not be provided during the period of the agreement, and what sort of vendor resources will be put toward the project. Does the vendor employ a dedicated, well-trained support staff or does it rely on outside contractors? Is that expense included in the projections?

If possible, lenders should speak with the vendor's current customers to assess their satisfaction level with the vendor's support services. Visiting the actual support call center as part of the due diligence process is also important.

Lenders should use the RFP to determine what product training the vendor provides and to what extent it is included in the standard service level agreement. Is it a one-time instruction course or is it an ongoing process? Is training performed onsite or online? What kinds of reference materials are provided as part of the training? How often are those materials updated?

What about when a new employee enters the lender's shop. Does the vendor employ a train the trainer program?

Implementation
While the best technology vendors now realize that they must provide a version of their software platforms configured to operate out of the box, every actual implementation will include some lender-specific elements. Lenders should use the RFP to get as much information as possible about the real costs and timeframes of these implementations.

While no vendor can anticipate everything that will actually occur during this phase, the detail provided in the answers will help the lender determine the vendor's desire and ability to be an effective partner. Lenders beware as expected, vendors will often offer only the most optimistic scenarios for both time and cost.

Ultimately, the system implemented is only as good as the team that installed it. Finding out who will be performing the implementation and asking other questions along those lines is just as critical during the RFP process. Is it a product company handling their own implementation or is the rollout performed by consultants whose main profit is derived from the hours involved in the implementation process itself?

Whenever a lender is presented with a technology option that is significantly less expensive to license than others, care should be taken to ensure that the additional vendor revenue is not made up on the consulting side of the equation. Asking for a sample implementation project plan will give the lender some insight into timeframes.

Ultimately, the lender should come away from the RFP response with a good picture of the vendor's implementation approach. It should be a structured approach that focuses on good project management. What is the skill level of the implementation team? Will the lender's internal staff be leveraged? What kind of controls does the vendor have in place?

Pricing
When it comes to pricing, the RFP should make it clear that the lender is seeking all-inclusive pricing, a total cost to acquire the system. Questions should specifically ask for details on any additional fees of any kind. For example, a company may offer the lender an entire fleet of possible functionality, but in order to have access to all of it the lender must purchase 10 different modules above and beyond the core system. This information could determine whether the lender will submit to a product demonstration.

Ideally, the pricing information provided by the vendor should represent a good estimate of everything required for the expected life of the product, including maintenance, training and support.

When there are significant differences in prices for maintenance between competing vendors, lenders must determine exactly what is included in each vendor's package. If there is a charge each time a call is placed to the help desk, the lender should expect a significantly lower cost for general maintenance, for instance.

Beyond the RFP
Success in any technological endeavor depends upon the quality of the lender's partners. The RFP is the first step toward establishing what will be a long and hopefully fruitful relationship. Through its format and the ability to draw answers that enable beneficial analysis on the lender's part, the RFP increases the likelihood and precision of qualified vendor proposals, and those not qualified become easily distinguishable.

An understanding of vendor responses ensures that by the time on-site due diligence begins the vendors in question will have already established themselves as suitable partners. In a future article, we will go beyond the RFP and discuss due diligence - one of the last phases in the selection process, and where the lender should be armed and ready to uncover all of the pros and cons of the system in question.

Gerard Heinz is COO at Mortgage Cadence. The Denver-based vendor can be found on the Web at http://www.mortgagecadence.com.