Make Your System Demo Count!

As a continuation of our blog series on system selection, it’s time to discuss helpful tips to facilitate a successful product demonstration. The organization and management of the entire process requires upfront preparation. If you drive the process, your demo evaluations will be far more effective.

Demonstrations are one of the most critical components of the software selection process. Seeing a system in action can be a great learning experience. But not all demos are created equal. Let’s talk about how you can level the playing field. To make the most of everyone’s time, CC Pace recommends the following best practices for product evaluations.

Tip One – Keep your process manageable by evaluating no more than five systems. If you evaluate too many vendors, it becomes difficult to drill down deep enough into each offering. You will inevitably suffer from memory loss and start asking questions like, “which system was it that had that cool fee functionality that would be really helpful?”

Tip Two – For each software vendor, set a well thought out date and time for the on-site demo. Depending on your team’s travel schedule, try to space out the demos a few days apart so that you have time to prepare and properly analyze between sessions.

Tip Three – Logistics play a big role in understanding how a system looks and functions, so do your part to help your vendors present well. Whenever possible, arrange for a high-quality projector or large HD screen for the attendees in the room. Hard-wired internet connections are always better. There’s nothing worse than being told, “the screen issues are because of a resolution problem” or “it’s running slow because the air card only has one bar.” Providing these two items can easily remove doubts about external factors causing appearance and performance issues.

Tip Four – Involve the right people from your organization. It’s important to have executive sponsorship as well as hands-on managers involved to assess the software modules. This is also the best opportunity to get “buy-in” from all parts of your organization.

Tip Five – Be sure to head into these demonstrations knowing your key requirements. Visualize it as a day in the life of a loan and follow a natural progression from initial lead into funding. Jumping around causes confusion and can be difficult on the vendor.

Build a list of requirements based on the bulk of your business. Asking to see how the software handles the most complicated scenarios can send the demo down needless paths. No one wants to watch a sales person jump through a bunch of unnecessary hoops for a low-volume loan product.

If you highlight which functional capabilities are most important to your organization, the vendors can spend more time demonstrating those capabilities in their software. Communicate how you think their software can help. But be careful not to justify why something is done a certain way today, but rather focus on how it should be done in the future.

Tip Six – The easiest way to take control of the demo process is to draft demo scripts for your vendors. Start by identifying the ‘must-have’ processes that the software should automate. Don’t worry about seeing everything during this demo. Set the expectation that if the demo goes well, the vendor will likely be called back again for a deeper dive. Provide a brief description of each process and send it to the vendor participants so they can show how their software automates each process. The best vendor partners will have innovative ways to automate your processes, so give them a chance to show their approach.

As you watch the demos, keep track of how many screens are navigated to accomplish a specific task. The fewer clicks and screens, the better. Third-party integrations can significantly help with the data collection and approval process. Always have an open mind regarding different ways to accomplish tasks and don’t expect your new software to look or act just like your legacy system.

Simple scorecards should be completed immediately following each demonstration. This will make it easier to remember what you liked and disliked and prove invaluable when comparing all the systems side-by-side when your demos are complete.

One final suggestion: always request copies of the presentations. Not only will this help you remember what each system offers, it’s useful when the time comes to create presentations for senior management.

photo credit: http://www.freepik.com/free-vector/business-presentation_792712.htm Designed by Freepik

Is the RFP dead? As a tool for helping guide the selection of the best possible loan origination software, the traditional Request for Proposal seems to be increasingly viewed as an optional, and not particularly helpful, part of the selection process these days. And for good reason.

We at CC Pace have been questioning the value of a formal RFP for LOS selection, at least as typically applied, for some time now. Traditionally, the RFP is used to serve two primary functions: 1) to provide an apples-to-apples comparison of features and functionality among a group of worthy competing systems and vendors, and 2) to provide helpful documentation to the selection decision. But in today’s origination software market, the functionality included with competitive systems is more alike than ever before. LOSs have matured such that the differentiating factors are most often “how” they do things, not “what” they do. The RFP is simply not well suited to “how” distinctions, as “yes or no” questions are geared more for “what” and seldom shed light on the more nuanced distinctions of the candidate systems. In short, why bother asking detailed functionality questions when what is really needed is a better understanding of how each system handles those features that are “make-or-break” factors in your search?

The big problem for many lenders trying to navigate the software selection process is getting too caught up on debating the merits of a plethora of “bells and whistles,” while largely ignoring the bigger questions of whether the system meets their most important criteria and can they be successful in implementing it? In most situations there are only a relatively small number of things that really define what is absolutely critical, so why not limit the RFP to a short list of things you want the vendors to provide detailed answers on? Beyond that, well-orchestrated, in-depth system demonstrations typically do a better job of telling you whether a given system will meet your functional needs in a way that will fit well with your company’s organizational culture and processes.

Once having used detailed demonstrations to narrow the field to a small number of seemingly suitable candidate systems, the most important things a lender should want to focus on are 1) which of the systems can be successfully deployed in my shop and 2) will we be happy with the results afterwards? As simple as they may seem, these questions are exactly what you should strive to figure out in the process of selecting a system. And surprisingly they are often left out of the selection process entirely.

Too often lenders try to answer the first question (can we successfully deploy the system?) by looking at who the vendor has sold the system to recently. Many attempt to shorten the selection cycle simply by accepting that if Company ABC and XYZ bought the system, it must be good, without regard as to whether ABC or XYZ have successfully deployed it as yet, or if they’ve even begun that process. The truth is that not every LOS implementation goes all that smoothly, with something like a quarter of them failing outright. Rather than asking the vendor about their track record for successful implementation, it is far better to speak to as many customers of that vendor as possible and ask them directly. Probe into how their implementation efforts went, how happy were they with the vendor through that process, what kind of attention they received, and whether everything went as planned. Most of your lending brethren will be remarkably candid about this process when asked, even if the response doesn’t reflect all that well on them or the vendor. Use that candor to your advantage and learn from it.

Then ask how similar ABC and the others are to your company. When it comes to an LOS, one size does not fit all, so success with one company may not mean that much if they aren’t very similar to your company. Do they have the same operational model, offer the same products, and leverage the same channels? Ask them what level of effort was required of their own resources and how well prepared they were to meet those demands. Make sure you are ready to hold up your end of the implementation bargain, so listen carefully to what those that have succeeded tell you. Don’t over-reach by choosing a system that demands in-house analytical, configuration or development skills that you aren’t well-suited to provide, as those are critical factors when assessing suitability of organizational fit and common contributors to implementation struggles.

When it comes to being happy with the resulting system post-deployment, once again we strongly suggest doing your homework by talking to the vendors’ customers. Speak to as many current clients of the system as possible and ask probing questions about their satisfaction. Be honest with them about your expectations and goals and solicit their feedback on whether the system, in their opinion, can deliver. Here again the real trick is to not set yourself up to fail. Take the time to document your expectations up front, then carefully vet whether the system under consideration is truly aligned with those expectations.

The goals you are trying to achieve by replacing an existing LOS should be your north star guiding the process from start to finish. The desired outcomes should be things far more substantial than just successfully implementing a system. Clearly defining those desired outcomes at the outset is critical to guiding the implementation process, and to measuring your success at completion. Focusing the selection process on how to meet your critical needs while increasing the likelihood of successful deployment and roll-out is the right approach and one that relies very little on the traditional RFP.

So, should the RFP be laid to rest? My vote would be “no.” The RFP can provide important value, but skip the lengthy laundry list of functionality check boxes. Keep it short, ask open ended questions and focus on those critical things that are the real “make or break” factors in your search. But more importantly, the RFP should only be the start of your due diligence, used to help narrow the field before launching into asking the really big questions of whether you can succeed and by happy with your choice.

Still a bit overwhelmed with the selection process? Let’s talk.

An important part of any system selection process is when the vendor is asked to demonstrate their products. This is a pivotal time, when the dry responses to the RFP become something that is seen and the staff can begin to visualize themselves using the system in their daily work.  Selection Team members walk out of a demonstration with their preconceptions turned into expectations of what the product can or cannot do, and what benefits it may bring to the organization.  These impressions stick with the audience; it is hard to move someone away from what they’ve seen or heard during a demonstration.

I’ve always considered the demonstration, as well as the set-up and coordination activities around this meeting, as where I earn most of my fee for managing a selection process.  It is important not to view this as a one-off meeting, or standalone activity, but to view it as integral to the overall selection process using information already collected and providing output to the next steps, as well as the final decision.

Steps prior to the demonstration including defining and prioritizing the business requirements, creating a potential product list, developing/distributing an RFP and assessing the vendor responses.  That assessment should narrow down the field to those 2-4 vendors that best meet your baseline requirements and are most worthy of being invited in for a demonstration.

Recommended activities to surround the demonstration, include:

Schedule:  I try to group the demonstrations within a 1-2 week time period, without significant time gaps between sessions.  This is rough on the individual calendars of those attending the meetings, but worth it to keep the purpose, critical requirements and comparisons top of mind throughout.

Agenda: Using the most critical requirements identified previously, the agenda is set to walk through all key aspects of the functionality, with a focus on any particular area where the selection committee is particularly concerned.  The agenda is also set up to allow users to manage their time, so they are only present when the demo is covering their functional areas, without tying them up for the full session. Importantly, a well thought out agenda ensures the vendor spends adequate time on all the aspects of the system the team is interested in, with little opportunity to gloss over areas of weakness.

Scorecard:  Any attendee in the demonstration should complete a scorecard for the parts of the demo they participated in.  The scorecards must be completed before the participant exits the room, as their thoughts quickly get mixed between systems, and other priorities occur that take attention and time away from completing the scorecard.  The scorecard is never overly long, but serves to provide a quantitative view of the participant’s impression of specific functionality in the system, and to capture any comments or questions that may be pending at the end of the demo.  To avoid skewing the quantitative results, participants should only score those sections with which they have expertise.  Entries on the scorecard are aligned with the agenda for easy following, and are weighted based on priority for quantitative comparison across products.

Attendees:  I discourage the selection team members from looking at the systems early in the process, before their requirements are known and prioritized, to avoid any preset leanings in one direction or another.  The size of the group varies on the size of the organization, breadth of functionality for the system being selected and amount of time devoted to the selection.  The preference is to keep the participating audience at a manageable size and consistent across all systems being considered.  All audience members should be prepped beforehand, as to how the meeting will run, the agenda and the scorecard.

Facilitation:  The facilitator role is an active one, ensuring the focus remains on the agenda and covers all the topics in the scorecard.  Questions may be tabled, conversations cut short (particularly those that serve a small part of the audience present at that time), and information prompted out of the audience or the vendor.  Another role is that of translator and interpreter.  It always stuns me how we all say the same things in entirely different ways within and across financial sectors.  It is important that the vendor’s presentation is translated into the audience’s terminology whenever possible for maximum appreciation of what is being presented.  It is equally important to also interpret what the vendor says into how the audience members think.  The facilitator’s knowledge of the industry, the available products, implementation, maintenance, etc. are all leveraged to steer the discussion such that the audience will appreciate not only what they are seeing, but what they will need to contribute for configuration and maintenance and whether the system has the flexibility to meet their needs in different ways.  This leads to a more mutually fulfilling discussion between the vendor and the audience, as everyone speaks from the same page.

Post-Meeting Roundtable:  A facilitated session of key audience members should quickly follow each demonstration (to mitigate crossover confusion with what functionality went where or when a particular comment came up).  A review of the scorecards should be completed prior to this session, so disparities can be addressed.  This meeting is the opportunity to discuss the demo, questions raised, and establish a general consensus about where the product stands and that the functionality represents similar things to everyone.  It is not unknown to find a score of 1 and a score of 5 (using a 1-5 range) for the same functionality line item on the scorecards of two different participants.  There is no expectation that everyone will score things the same, rather that scores should be in a similar ballpark.  Large disparities like this one indicate misunderstandings by one or both team members, and those need to be put on the table for clarification as soon as possible, before perceptions are cemented and expectations set in one’s mind that cannot be met.

I know companies who failed to follow one or more of the steps above during their selection process and the result was typically missed expectations and buyer’s regret.  Allowing the vendors free roam for their demonstrations causes confusion when comparing products, as the vendors may approach the discussion from totally disparate functional areas.  Lack of a schedule requires a larger investment of time, as people with only a small area of functionality to observe are sitting in for much longer time periods (or the meeting is stopping and starting, while new people are called in and others leave). Most importantly, what someone hears versus what was intended may be completely different messages that were not caught prior to a final recommendation.  That “results in not getting what you thought you were getting”.

While key to the overall selection process, the demonstration is not the final task in the process.  A quantitative comparison of RFP responses and demo results can be used to further reduce the short list of potential candidates prior to moving into an in-depth due diligence process.  Targeted system demonstrations, or question/answer sessions with the vendor may occur during this period to collect additional information or clarify any points.

Once the due diligence is completed, the qualitative and quantitative results are assessed to identify the final recommendation from the selection process.

I was recently reminded of a column I wrote back in February 2008 titled “Maintaining a Vendor Relationship”, for Mortgage Banking Magazine (available here).  I’ve been working on multiple system selection efforts of late being driven by proactive customer decisions to look at options available in the marketplace. These efforts have been driven by dissatisfaction with the current vendor but without pressure of a looming deadline or need for immediate change.  In most cases, the dissatisfaction came after the vendor/product was acquired by a larger organization changing the dynamic between client and vendor.

The recommendations I outlined in that well-aged column included:

1. Identify your vendors
2. Know the contractual highlights
3. Maintain open communication
4. Leverage the partnership
5. Maintain documentation
6. Validate escrow
7. Increase internal resources
8. Do market research

And while these recommendations are still valid today, they don’t fully reflect the new landscape of the consolidated marketplace where there are few independent vendors with a single, focused product offering.  Most vendors these days are part of larger conglomerates, with seemingly deeper pockets to support innovation, who have created through acquisition a portfolio of offerings to their financial services clients.  In some cases this includes multiple solutions addressing the exact same (or very similar) functionality, possibly, but not always, targeted at different customer segments.

So what does this mean and how does it change things?

In today’s market, there are additional recommendations needed to manage the vendor relationship.  These address the more complex organizational structure, the focus of those organization (and where those deep pockets may be utilized) and looking further ahead, not only for the product you’re using, but for the overall vendor objective.   Let’s face it, your vendor’s move from a sole product offering to being a small fish in a larger pond is a culture shock not only to your relationship, but to the staff supporting the product, as well.  There is a lot of change to be managed and it’s important to stay on top of it.

• More layers of communication: While open communication is still important, there are more options for who you might communicate with.  Obviously the product support team is key to the upkeep of service levels and current enhancement plans, but there should be connections maintained up the ladder.  This group may not be fully in the know on the long-term strategic plan for the product or the organization.  Do not wait until there is an issue to figure out who the contacts outside the product group are, and do not let the relationship languish in order to avoid reaching out, only to find out that they have left the company or moved to another position.  Within a large organization, much can happen without direct communication, so keeping these lines open increases the likelihood you will begin to hear murmurs and can make plans, prior to announcements being fully communicated or distributed.
• Networking: It is more important than ever to keep your connections alive.  These can include other users of the platform, or people who developed or supported the product.  It is always good to have someone to share stories with, and ensure things are progressing in similar patterns for everyone. Working in concert with other users can help to influence the vendor towards a particular direction or implement needed enhancements.  Knowing the people who really “know” the system, provides a possible back door to address critical issues that the current support organization may be struggling with.
• Awareness of where the organization is making investments:  If the consolidated company claims four LOS’ within their portfolio, it is extremely unlikely that each LOS is receiving similar investments for future improvements.  Identify which product and/or customer segment has the focus, and determine the implications for support of your solution when it is not the focal product.
• Be modular: It is more important than ever to retain your flexibility when it comes to the ability to switch products.  Vendors being acquired and the direction new owners take a product are outside your control.  What is within the control, is the level of effort and ability to switch vendors when needed.  Within the mortgage industry, MISMO for services was lauded as a tool lenders can use to more easily switch between providers.  Similarly, the recommendation is to standardize the requirements for any feeds to your systems via a connector-based process.  Products would feed/receive data to/from the connector, rather than directly into the internal system.  This allows the system on either side to be exchanged, without a direct impact on the other system or the resources supporting it.  This reduces the risk and effort when replacing systems, as they only need to connect to the connector; the programming which directly impacts that system is unaffected.  In addition, should the vendor make a change that could impact your systems without realizing it, the data would be likely stopped at the connector and not impact your internal systems.  Today, much of the integration is directly system to system, requiring a full re-development every time either system changes.   The connector approach reduces the level of effort needed and resulting testing that will need to be completed.  The connectors also offer re-usability for different purposes.  Internal resources to develop and support the connectors are needed, but in most instances the long term peace of mind and time savings will balance that investment.
• Be Diligent:  A vendor with a wide portfolio has a lot to offer, but it is important that additional offerings are approached wisely.  With a lot of growth coming from consolidation and not organic expansion, it is important to complete a thorough due diligence of all offerings.  Do not assume anything!  Do not assume that because the same vendor offers both products, the products are tightly integrated.  Growth through acquisition results in potentially disparate solutions carrying the product name.  Don’t assume because products have same or complementary names, they are connected. Product name changes are marketing ploys to create the feel of a suite of offerings, whether the connectivity between products is in place or not.  Do not assume that because your product is well supported, that any additional platform has similar support.  Each product may have separate support staffs, with different levels of competencies and knowledge.  Do your homework and complete a due diligence exercise extending into the marketplace with competing solutions to determine if the vendor solution represents the best solution for your organization.

There can be significant benefit to you through acquisition of your vendor by a larger organization, or not.  It is a matter of what that organization’s plans are, how they are managed and where their investment is being placed. Stay informed and be proactive is the best advice.