How Do I Get This Up and Running? -- Part II: Should My Program Be Centralized or Decentralized?

05/15/2015 02:11 pm ET | Updated May 15, 2016

I have one of those "a-funny-thing-happened-to-me-on-the-way-to-the-dry-cleaners" stories and it just so happens to be a perfect segue from last month's blog as we now switch focus to targeting alignment and support of your key initiative or action within the organization.

I received a call from a Senior Audit Manager from a major retail company who wanted to discuss with me an implementation strategy proposal to her C-suite for a third party risk program... and get my opinion on who should "own" said program. After asking questions to gain some background into her company's key organizational components (e.g., compliance, audit, procurement, etc.), current departmental staffing levels and risk tolerance, we discussed what I thought would be best for her proposal to target the C-level executive's needs.

So what did I recommend? Let me preface by explaining that each organization is different and there are usually quite a number of variables, such as budgeting, staffing, and subject matter expertise that come into play here. It's also important to have a solid understanding of the benefits and hindrances of both centralized and decentralized program models before selecting the right one for your organization.

Instituting centralized programs

The primary benefits of having a third party risk program in a centralized operation tend to adhere to the following:

  • The program will be known to all stakeholders across the enterprise (i.e., business units, C-level executives, etc.).
  • It offers a one-stop shop for other stakeholders, such as knowing who to contact with questions or concerns.
  • It tends to apply a consistent methodology and execution strategy.
  • Processes and practices have a sound structure.

Though these attributes sound impressive organizations must also be aware of common challenges that come with a centralized program; most notably:

  • In this case, it may become difficult for her team to know all that is or will be going on with larger third party service providers as multiple projects are employed with various scopes and data elements.
  • Her team may learn that smaller vendors managed by large business partners may refuse to cooperate, thus getting "lost in the shuffle" as they try to convince your organization that they are operating under the auspices of all parent-vendor policies and procedures - even when they are not.
  • Additionally, her staff may not truly understand why the business unit has selected or is using a particular vendor.

Managing decentralized programs

In a decentralized environment, organizations primarily maintain control in one business unit while ceding to that business unit's various responsibilities. Notable attributes in a decentralized program in this third party risk management case include:

  • Personnel performing the third party risk management program functions will reside in multiple business units (silos), reporting via a solid-line up to the head of the business unit and via a dotted-line into her.
  • Stakeholders (i.e., the business unit) want control over vendors connected to their department; thereby, handling or overseeing the assessment could take control away from her - the real owner of the program.

Decentralized programs also face common challenges that organizations should be aware of; most notably:

  • A centralized policy is usually missing and assessment methodologies and execution strategies tend to be inconsistently applied including the use of different tools for assessments.
  • Knowledge-sharing outside of the business unit, with respect to vendors or the results of their assessments, is often non-existent. This includes key assessment reports to senior level management in other business units who may be affected by their own projects with a problem vendor.

Which program model is right for your organization?

In the case of the Senior Audit Manager and her company, I recommended a centralized approach. Why? Not only because of the items previously mentioned, but also because she has enough well-trained staff to execute this program successfully, she is willing to take ownership of the program, and she is willing to work with the business units to ensure coverage across the enterprise.

When implementing any program, you should thoroughly study all options and expectations. In this case, there really is no "better" option when choosing between a centralized or decentralized program models; only the one you believe will operate best in your organization's environment.

Be sure to run your plan by your peers, staff and any business units you may need support from for additional feedback to prepare for any questions and answers prior to taking it up to the next rung on the management ladder. In your meeting with senior management, be sure to adequately present the whys and hows up front so you can get to the heart of the matter as well as any additional support that may be required from other business units. Once approval is received, request these senior leaders to assist you in propagating your plan and program across the enterprise. (NOTE: This step is critical in order to ensure there are no surprises within the business units as well as with their existing or potential vendors.)

Also, in reference to last month's column, be sure to begin writing policies and procedures and get them approved quickly as they will be the blueprints paramount to your program. Review policies and procedures at least annually for updates or changes. Programs are dynamic and always subject to change in order to address new challenges.

Remember, what matters most in implementing your program is communicating why it needs to be done and how it will be done. Ensuring that all relevant stakeholders across the enterprise understand the goals and execution plan breeds continued support and compliance for the program, ultimately leading to its success.