Project Management Principles for Compliance

I’m always looking for new ways to think about corporate compliance, to see whether that fresh perspective can help compliance officers do their jobs more effectively. Last week I found a great example courtesy of the Institute of Internal Auditors and its guidance for how to audit projects.

The guidance caught my eye because I’ve been thinking lately about the importance of IT projects to the success of large compliance programs—and the tendency for IT projects to go wrong. At first I wanted to see how internal audit’s principles for risk assessment and management might apply to IT projects. As I read further, however, I saw that many of the concepts here are just as useful to compliance officers trying to roll out your own programs.

After all, in a broad sense “compliance” is a project like any other. It starts as a specific set of actions you want the company to take, to achieve a desired outcome. Sure, in our case the desired outcome is usually something like higher completion rates for training programs, or more accurate due diligence analyses, or better accounting of payments from intermediaries to overseas customers—but those are projects like any other. They can fail like any other, too.

So what nuggets of wisdom can we steal from the IIA’s guidance? Several.

Find the Best Way to Fail

First, projects can fail in two ways: they can fail to be completed on time, or they can fail to achieve the outcome you want. And as the IIA noted, “All too often the completion failures are the ones that grab the headlines but the outcome failures can have the greatest impact.”

This is a hugely important point for compliance officers to grasp. We all know that that compliance projects can be complicated, nuts-and-bolts ordeals; just try integrating two different accounting systems and your third-party screening program if you need a reminder. They can be deadline-driven, with real budget dollars at stake and awkward conversations with the CIO or CFO should they fall behind schedule.

Still, for many compliance projects the paramount goal is to improve behavior—and that’s where failed outcomes can be really dangerous. Your new training program might get higher completion rates, but fewer employees absorb the lessons you want to impart. An internal reporting system might try to be helpful with automated prompts, and not allow employees the chance to report an error or misconduct you haven’t anticipated.

Whatever your specific project is, you need to ask several questions. First, what’s the worst way your project could fail? Second, what’s the “best” way your project could fail? That is, would your rather run 20 percent over budget but still achieve 100 percent of your desired outcome, or stay within budget but achieve only 80 percent of your goal?

Those can be tough questions for compliance officers to answer. Usually it will depend on the specific problem you’re trying to solve. Inevitably some consultant will remind you to “take a risk-based approach”—which is good advice, until you need to start making real decisions about what stays in the project and what stays out. The questions above can help you focus your thinking.

Age Gracefully

Second, remember that projects have a natural lifecycle: inception, development, delivery, and closure. Benchmarking your compliance project to that lifecycle will help you know who involve at various points along the way.

For example, at the inception phase, you want to define why you’re undertaking this compliance project at all and what the desired outcomes are. So this is when you want a robust conversation among yourself, the chief audit executive, perhaps the general counsel (say, if the project is to improve contract management) or the HR director (if the project is to improve employee attitudes).

When you move on to the development phase, you’ll need help from other executives. If the project is technology driven, clearly you’ll need the help of the CIO. You will probably need to bring operations executives into the mix now, as you figure out how to fit the outcomes you articulated above into the practices the operating units already have. And this is where you start to spend money, so the CFO will always be nearby.

The IIA guidance uses this handy chart to demonstrate a project lifecycle visually. It’s a good point of reference so you can ask yourself: What do I want to happen as this project moves from one phase to the next? Who helps me do that?

Review Your Priorities

Third, every project can benefit from a good project review, and internal audit executives are tailor-made for that sort of work—examining something and asking, “Is this the best approach? What are the risks involved? What might go wrong?”

This is where I would recommend compliance officers make a conceptual leap. Don’t ask internal audit to review your project’s technical execution or its progress along the project lifecycle. Instead, ask them to audit the compliance department’s priorities and needs. In the world of project management (yes, there is such a field), this would be called a portfolio review: a look at all the projects you have happening at once.

Compliance officers do have lots of projects happening at once, even if some of them are more “ongoing programs” or “efforts” or whatever—we can get carried away with the nomenclature pretty easily here. Regardless, you get the idea. The compliance department is juggling a lot of concerns all at once, and the internal audit department (perhaps enlisting the help of others) can be a valuable resource to keep all your concerns in perspective and on track.

The IIA guidance on projects has many more ideas, too. Let’s take good insight anywhere we can find it.