Allison was recently appointed Chief Compliance Officer in the IT department of a huge financial services company, and was set up to fail from day one.

The set-up was pretty obvious to an outsider, but not to her. She enthusiastically told me of the importance of regulatory compliance in their industry and the stature of her position as the one person accountable for the compliance of the entire IT function.

"The regulators require a single point of contact," she explained. "We need to ensure consistent processes and metrics throughout the organization. And our CIO gave me the authority to make it happen."

I was reminded of past discussions with Chief Security Officers, quality managers in the pharmaceuticals industry, and business continuity managers. All these people had been made accountable for other people's compliance, and believed they had the authority to control other people's behaviors.

Sigh. I hated to burst Allison's bubble. But time and again, history has proven that this approach doesn't work. Here's why:

Executives have businesses to run, and they're not going to let a compliance officer tell them how to do it. Sure, they'll comply when it's easy or when they really have to—with the big, visible initiatives. But on a day-to-day basis, Allison has three factors going against her:

1. Others are not being held accountable for their own compliance—she is. Why should they put effort into something that's outside their own personal performance objectives?

2. Executives are held accountable for business results, and they aren't going to let Allison cause them to fail at that. They're not going to change their processes or disrupt their operations to help with her objectives.

3. Allison is the one who's accountable. So if others mess up and bad things happen, she'll take the fall.

Allison may as well have been given the title, "Chief Scapegoat."

The Path of Accountability

The trap of the scapegoat occurs in many situations beyond compliance. It may be that ITIL "process owners" are tasked with implementing changes in the way the rest of the IT organization works. Or perhaps IT is asked to implement ERP and takes responsibility for changing clients' business processes.

The organizational principle that applies in all these situations is straightforward: Accountability and authority must flow down through the solid lines of the reporting hierarchy. It must never flow sideways such that someone is given accountability or authority for peers' behaviors.