When compliance teams are planning and building out their program, more specifically the compliance software they use, they often encounter certain challenges and obstacles within their organization. Sometimes, the challenges may not surface until late in the decision-making process, meaning compliance teams are getting to a point where the entire team has researched, vetted and bought into a strategy and that somehow unravels at the last minute because of one influence or another. Beyond being frustrating, it’s incredibly inefficient for the team. With foresight and planning, there are ways to understand some of those challenges so that you can better anticipate and overcome them early in the process.
Internal battles around software purchases usually center around three schools of thought: making it work with generic business tools, building a proprietary solution or buying software off the shelf.
How do you know which option is best for your organization and your compliance program, now and in the future? What are the relative advantages, challenges and costs of those options? And how do you effectively communicate this to internal stakeholders in a way that generates their support (best case scenario) or at a minimum avoids their scrutiny and derailing of your project?
This whole exercise starts when you’ve made a decision that whatever you’re doing today is not working. From there, you need to carefully consider your options.
To view the full recording of our recent webinar on this topic, including the presentation slides, visit here.
SET YOUR REQUIREMENTS
Set your requirements first. Before you begin this entire process, start with the “why?” Identifying exactly what outcome you’d like to achieve is a critical, but often overlooked, step in the process—particularly when it comes to engaging with and soliciting feedback from other internal stakeholders. Neglecting decision influencers early in the process can create huge obstacles to getting what you need down the road. Before you start researching vendors and pricing out your options, first gather a team (that may include representatives from legal, HR, audit, risk and/or IT, depending on the solution you’re looking for) and get their feedback and requirements, specifically around the following themes:
- What are the goals you’re trying to achieve?
- What’s stopping you from achieving your goals today?
- What features are required?
- What control do you need in terms of flexibility, scalability or configurability—now and down the road?
- What service and support do you need during implementation and throughout the life of the product?
- What’s your budget?
Getting early and widespread consensus on barriers to success can help the team stay focused on shared, specific requirements. Focusing on the big picture can also help avoid unforeseen project derailments and hangups on feature/function minutiae. Be sure to have all stakeholders break their requirements into minimum, standard and aspirational categories: separating the “need to haves” from the “nice to haves” will help you understand what is most important to whom and potentially anticipate and disarm project show-stoppers down the line.
WHEN TO BUILD…AND WHEN TO BUY
You shouldn’t build anything that’s available off the shelf that’s not the source of competitive advantage.
—Mark Holst-Knudsen, CEO
There are a couple guiding principles that will help you decide early on which route is best for your organization.
- Build if the system will give you an advantage over your competitors. Buy if the system is a fundamental requirement of doing business. Take the example of Delta Airlines, who recently brought their data systems in-house so that they could control, manage, modify and enhance the way they handle reservations. For Delta, offering a better, more cost-effective reservations process would provide the company an advantage over its competitors. For most companies, compliance would be a “fundamental requirement” more often than a “competitive advantage,” making it a no-brainer choice to buy.
- Prioritize adding value wherever and whenever possible. Manual, administrative and project management tasks can be disruptive and hugely time-consuming. While most teams would be required to oversee the setup and implementation of off-the-shelf software, it would likely pale in comparison to the time and effort required to inform the building, implementation, launch and ongoing maintenance of an entirely new and proprietary system.
- Assess your current capabilities and market availability against your requirements. This means taking into account your in-house technical proficiency, the complexity of the project requirements, the availability of off-the-shelf solutions and how often or quickly your requirements might change. As far as compliance goes, there are very few situations where it actually makes sense to internally build a product; it’s a mature and competitive market where a variety of products are widely available at competitive prices.
Most organizations are going to be much better served to buy, rather than build. You only really want to build when your requirements are so unique that you can’t find any solution in the market that’s going to be able to fit or adapt to your process.
—Michael Rasmussen, The GRC Pundit
GRC 20/20 Research
This is all to say nothing of the fact that the stakes in compliance are uniquely high. “There’s so much detail that cannot slip through the cracks,” Rasmussen continued, “because a lot of the regulators are looking for audit trail integrity. What was assessed? What was communicated? On what date and time? If we’re not thinking through of the audit trails, evidence and reporting that we need for defensible compliance, the build-your-own solution might have as many errors and issues as relying on basic documents, spreadsheets and emails.”
OVERCOMING PRESSURE TO “MAKE IT WORK”
We’d be remiss if we didn’t acknowledge that it’s not always as simple as weighing building versus buying a solution. Some companies choose to simply make it work with the basic tools they have available—spreadsheets, email, print files, etc.—or to do nothing, kicking the proverbial can down the road.
While resistance to change can be difficult to overcome, or budgets tough to justify, these two paths of seemingly less resistance can create major problems in the form of:
- Ineffectiveness: Calling this the “inevitability of failure,” Rasmussen points out that “regulators are really picking up on the fact that things are going to slip through the cracks, emails are going to get deleted or filed away, and not followed up on. Documents, spreadsheets and emails can all be manufactured. [Anyone] can paint a rosy picture to get themselves or the organization out of trouble.”
- Lack of agility: In the compliance world, there’s usually more happening than what compliance teams can reasonably keep up with. Regulations, standards, enforcement trends, administrative decisions and best practices are constantly evolving, usually without an uptick in headcount or improvement in technology within the teams that are required to address them. Information architecture, process automation and audit trail capturing increases accountability in such a fluid environment.
- Inefficiency: It’s the simple 80/20 principle. Ideally, compliance teams would be spending 20% of their time on administrative work, and 80% adding value. When a team is forced to rely on antiquated systems, that ratio is usually flipped, with teams spending a vast majority of their time on data entry, aggregation, reconciliation and reporting.
Look for the second blog in our “buy vs. build” series soon, where we’ll explore the “pros” and “cons” of buying and building compliance software, along with the line items that make up the total cost of ownership (TCO) for each option. In the interim, you can view the full recording of our recent webinar on this topic, including the presentation slides, here.