This piece originally appeared in the March 2023 edition of DS News magazine, online now [1].
In a recent Five Star and OrangeGrid webinar entitled “Getting Servicing Technology Approved: From Concept to Completion in 90 Days [2],” Todd Mobraten, CEO of OrangeGrid; James Campbell, EVP and Head of Servicing for Flagstar’s residential mortgage business; Jarrad Lewis, who leads the delivery management capability of OrangeGrid’s product team; and 28-year industry veteran James Vinci, CTO, Selene Finance, discussed defining project objectives, selecting the right vendor, handling complexities, and getting project and budget approvals.
“For mortgage servicing, the big topic is technology,” said Mobraten, who moderated the webinar. “We need more of it, or we need to change it out. So, we’re either looking to add, replace, or connect things in your technology world. It’s the only way we’re going to become more efficient and increase margins.”
However, that’s no easy task for mortgage servicing and associated businesses, Morbraten said. The business side and IT side of the organization need to work together, which can be challenging.
In addition, servicing is changing faster than ever, Campbell noted. “As we look at technology initiatives, they need to be quick to [both development and deployment.] You can’t have projects take a year or two years anymore. I’m looking for technology solutions that I can scope out, develop, and integrate in a short period of time.”
With that in mind, a 90-day window provides an agile timeframe so a servicer can implement some changes but not spend too much time in development, Campbell added.
“IT is here to help enable and facilitate the business. We all win by getting things done, and getting them done timely is important,” Vinci said. “A large project is almost destined to fail just because of the rapid changes in our environment.”
Today, servicing professionals need information more quickly. So, the quicker analysts can have the necessary information, the better, Vinci added.
A 90-day timeframe, versus a longer scope, lowers complexity, so it lends itself to a higher chance of success, fewer defects, and better time to market, Vinci said. “It also helps on ‘scope creep.’ Both the business side and the IT side feel more of a sense of accomplishment by iterating through these things and getting them done.”
“Time is a killer of all things,” Mobraten agreed.
How to Define Project Objectives
If a servicer fails to discuss the objectives at the beginning, there may be a myriad of issues, including scope creep, lack of alignment with internal teams, and other problems, Lewis suggested.
Scope creep “is death by a thousand cuts,” Campbell said. “You never want scope creep. What you want to do is take the time to develop your business requirements, be very specific and exact about it, know what your end objective is, and take the time to make certain that the vendor partner that you’re going to work with understands exactly what those business requirements are.”
To provide the most benefit, the technology needs to be in a functional state as quickly as possible, Campbell said. “I want to be able to take something and quickly implement it in the line of business. We can refine it later.”
“We’re building business cases and ROIs based on that defined scope and those requirements,” Vinci added. “As scope creep comes in, that business model breaks down.”
Selecting the Right Vendor, Managing the Complexity
The vendor’s specialty must align with what you’re trying to achieve or you’re setting yourself up for failure, Lewis warned.
“I think we could all attest to being in this industry for so long as sometimes we work with a piece of technology that was designed for a specific thing and we either convince ourselves or someone else convinces us, we can tweak and morph this to do this other thing and just make it happen that way,” Morbraten said. “Pretty soon it becomes a [Frankenstein’s monster]. Over the next decade, we’re still asking, ‘how did we get here?’ So, it’s critical to understand what the true offering of that solution is.”
“You can’t have technologies that compete with each other,” Campbell cautioned. “You need a single source of truth for your data. The wraparound systems have to be able to tie into that single source of truth.”
The single source of truth can be your proprietary platform, your data, or your enterprise data warehouse, Campbell added. “Regardless, that single source of truth needs to be aligned with the wraparound technologies, and the wraparound technologies have to be aligned with your single source of truth.”
“Ultimately, these wraparound systems can become the de facto single source of truth for their function,” Vinci added. “So, it’s important to make sure that you’re syncing it back into your true single source.”
Another problem is that technology is often not documented the way it should be, Vinci said.
So, figuring out those interdependencies and doing that work upfront is critical. Changes may still need to be made, so any technology solution needs to be flexible, Vinci said. “Gone are the days when everything was hard-coded. We need technologies out there that are flexible and allow you to rapidly make any needed changes.”
Vinci recommended addressing the need for a single source of truth with your architecture team and your data team. “They know what the interdependencies are.”
Managing complexity is another area where it’s essential to have a vendor that is aligned with your strategy, Vinci noted. “If you’re looking for small iterative development projects, make sure your vendors align with that—not all vendors [do].”
The Benefits of a Strong Technology Foundation
“Most of what business is trying to automate is decades of ‘muscle memory’—things that people have been doing at their desk for a very long time.” Lewis said. “It’s difficult to get to the finite details of truly what you do in your role and how to automate that.” Lewis advised the audience to focus on the organization’s key objectives. The “muscle memory” can be uncovered during the automation process.
To align the different technology stakeholders, Campbell recommended making sure everyone understands the end objective of the technology project.
Clean architecture is important, Vinci added.
“Technologists love shiny objects. We love new things. We love trying to essentially overbuild. It’s important to realize what the goal of the project is.”
While it’s tempting to add new capabilities as they become available, doing so has to be balanced with the need to get the technology up and running, Vinci said. Adding too many bells and whistles will slow down the implementation and benefits the organization will receive from the technology.
“Isolation and separation of applications is critical,” Vinci added. “The integration tool needs to be isolated, not embedded, and configurable.”
“You have to look at the entire solution when you’re integrating with your vendor partners.”
Campbell added. “You want to make certain that you have a cost-effective solution for exchanging data. We want to make certain that we’re coming up with the best solution to utilize the data that we have available and that we’re updating the data from that third-party vendor’s platform back to the primary system record.”
In addition, it must be done in the most cost-effective manner, added Campbell, who pointed out that web service calls or API integrations can be more expensive.
Getting Project Approval
Solving the above issues means nothing if the project isn’t approved, Mobraten noted. To get stakeholder buy-in, Campbell recommended starting with a vision for the fiscal year, then scoping out the different technology initiatives. Trying to get approval in mid-year, rather than at the beginning, can be difficult.
“You need to be prepared to sell the benefit of those technology initiatives to the executive leadership team,” Campbell added. “You need to be able to show that this is going to create a more profitable enterprise for you and the executive team by compressing the cost or expanding the revenue or both. You need to be able to show that it’s accretive to the financials.”
If it’s not, you need to be able to demonstrate that the technology will reduce expenses or cut risk, Campbell said.
However, Vinci cautioned not to just then spend those savings on another IT project. It helps if a proposed technology project is aligned with one the organization was already planning, Vinci added, cautioning that compliance and risk need to be considered with all technology projects.
While IT sometimes says “no” to technology that the business side wants, objections can often be overcome by getting IT excited about how the solution will impact the top and bottom lines, Vinci says. “We’re an enabler. When you think about it that way, you can start getting excited about how you are going to impact the top and bottom lines with your projects.”
Though IT may want to build internally rather than bring in a third-party vendor, sometimes external vendors can implement technology more cost-effectively. Having access to internal and external IT enables you to make a side-by-side comparison and choose the best solution.
“For example, if we were to build something that required a heavy focus on regulatory compliance, we’d need to make certain that we were bringing in all the updates to compliance on a real-time basis, potentially leveraging external attorneys to give us up-to-the-minute updates on compliance,” Campbell explained. “Instead of having to buy those updates as a servicer, I could go to the technology partner. They would be responsible for doing that and integrating it into their technology, so they could spread that cost with the attorneys that they work with across all their partners that they sell their product to, instead of me having to absorb it all internally in my proprietary build.”
Getting Budget Approval
“You’re always going to look to request a bigger budget than you’re going to get approved,” Campbell acknowledged. “The reality is I only have so many IT resources, and I only have so much capital capacity to do development. So, we risk-rank and prioritize everything based on first looking at the regulatory and compliance environment. We focus on those first.”
The service business is heavily regulated, so regulatory- and compliance-related technology must be prioritized, Campbell explained. Next is the maintenance of existing applications, then comes new technology projects.
New projects will be prioritized by whatever provides the best return or the most help with customer experience (CX), though that is difficult to measure.
Campbell added that budget approval is much easier if different departments communicate with one another to find and request approval for technology that can be implemented across the organization.
“It’s important to build those good business relationships,” Vinci agreed.