September 9, 2019
As vendors who specialize in single product solutions, (such as commissions or supervision) are absorbed into larger organizations that offer a wider array of services and inter-product connectivity, there is a hidden cost: the broker dealer.
The vendor subject matter expertise is diminishing, and deployment and development time frames are being elongated. In addition, the broker dealers now need to allocate resources to manage the vendor and the project, while also developing internal business analysts capable of crossing the divide between the operational staff and the vendor’s software development teams.
There are undeniable benefits of these larger organizations. The larger vendor firms are able to scale and support hardened security environments. They can comply with, and successfully pass, the growing number of audits the regulators require; such as SOX and SAS replacement. By the very nature of their own size these vendors require their own disaster recovery sites and can extend those offerings to their clients. These gains are coming at a cost though, and as there is no turning back the tide, the savvy broker dealer must proactively be prepared to address the changes.
The most notable change is apparent to both the longtime client as well as clients amid a new deployment; the diminishing Subject Matter Expertise. As scalability is the name of the game for larger vendors, broker dealers immediately notice increased layers of individuals and new roles that are introduced between your key operational staff and the product subject matter expert. Typically, the B/D is assigned an Account Manager, and if we’re being honest the primary role for the Account Manager is sales; cross selling the newly integrated product sweet. Then comes the Client Service Manger or Representative, who often, has little or no industry experience and whose primarily role is managing the open issue and request queue, not actively providing answers and solutions. Even the role of business analyst is being generalized, and generalized results in less ability to clearly understand the business driver behind new requests or diminishes the ability to diagnose issues. Inconvenient if you have already deployed the software; brutally painful if you’re in the midst of a new deployment.
So, how do you respond? The short answer is to adopt the mindset, “You Own It—You Need to Drive IT.”
We will focus on addressing a new implementation, but keep in mind many of the new roles and responsibilities for your B/D will carry over into your ongoing production relationship.
A successful deployment requires that the B/D have resources capable of managing the vendor and the project. Though most vendors will promote that the deployment fees include project management, that effort is generally focused internally for the vendor; not across your organization. The vendor’s PM isn’t held accountable for delays in the “go-live date”, and most contracts now include a date for when at least partial billing starts, regardless of whether the “go-live” date is pushed. The B/D’s PM needs to be capable of driving deliverables both internally and with the vendor, managing both internal tracking systems and the vendors ticketing systems. The B/D PM needs to own the success of the implementation and for meeting agreed milestone dates. Appoint a vendor manager from day one; this may be the PM or the business unit owner who will own the ongoing relationship. Your vendor manager and PM are a partnership that should live or die together on the success of the deployment.
One of the most difficult changes is the need to ensure that the B/D is represented not only by strong operational owners, but also by individuals who have a solid grasp of software development and data base architecture. Gone are the days when your operations staff could explain to the vendor’s SME the business requirement, and that SME had enough industry knowledge to immediately understand the driver and translate that into accurate business requirements.
Today your business staff explains the requirements to a generalized BA, who documents their understand of the requirements, that the vendor then turns into technical requirements. Sounds logical right? Not so fast, first the BA often doesn’t have the experience to ask about the edge cases, and the negative or unexpected scenarios. Meanwhile your staff misguidedly believes the BA has some expertise or they don’t have experience documenting requirements, so they rely too heavily on the BA’s work. Any misses hear are compounded when the vendor then asks you to sign-off on the technical requirements. The technical requirements are even more of a black box as they refer to data fields and data base structures you are not familiar with, and reasonably your staff makes assumptions based on the field name.
Finally expect to spend more time and dive deeper into user acceptance testing than you’d hope or want to allocate time for. Assign a broad spectrum of users to test and allocate time for each to perform detailed testing. This will include training internal resources on what “user acceptance testing” means and how to test.