The Art of Planning an LOS Implementation Budget
Pulling from our considerable experience with the unique aspects of implementing a mortgage loan origination system (LOS), CC Pace has recently published a new white paper on the topic, “The Art of Planning an LOS Implementation Budget.” The information covered in the white paper, while essentially specific to LOS implementations, is broadly applicable for any product implementation project.
Best practices indicate that thorough project planning is the most critical step for a successful system implementation, and we concur wholeheartedly. One of the key activities that should be performed during the planning phase is the development of a detailed implementation budget. The budget is particularly important when establishing expectations with Senior Management and gaining support for the effort. Too often, planners fail to consider the costs beyond those of the software, vendor configuration and any vendor-provided customizations when in fact the all-in cost of an implementation includes much more.
We hope that readers see the importance of taking a more comprehensive perspective when planning their next project and we welcome your feedback. What other line items do you include in your budget preparation process?
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.