How to make the consultant’s edge your own

CIOs often make mistakes when working with consultants. I pointed out three of them in my last installment.

There’s a fourth that’s potentially more serious than these three combined: failing to take advantage of the consultant’s edge, either by engaging them or by making their edge your edge.

True story: My consulting team, engaged to assess an IT organization’s overall effectiveness, found that some of its practices violated fundamental financial compliance requirements in ways that could potentially lead to civil and criminal liability.

We presented our concerns to the client’s top executives as part of our preliminary findings review. They, quite testily, disagreed. Their books, they insisted, were squeaky clean, not to be challenged in our final analysis and recommendations.

As consultants our integrity was, of course, negotiable. But not that negotiable. We wrapped up the engagement and left the client’s halls and conference rooms, never to be invited back.

Three years later they restated (unfavorably) their balance sheet by a few billion dollars.

How was it that in just six weeks our four-person team, none with specialized expertise in forensic finance and accounting, spotted a major problem with the company’s finance practices that the CFO, immersed in the subject every day, missed entirely?

A fundamental rule of organizational dynamics is what made the difference, namely, that hidden in every company are people who collectively know about everything that’s broken, and how to fix it.

The consultant’s edge: Breaking the culture of silence

As outside consultants, all we have to do is listen — to lots of people, promising all of them anonymity as part of our process.

In return they unburden, relieved to finally be talking with someone who cares.

It’s the consultant’s secret edge, and it’s harder to re-create this inside the organization than you might think.

Imagine you’re an individual contributor and you spot what you think is a serious problem, such as a steadily accumulating balance-sheet misstatement. What do you do?

You tell your supervisor, of course. Your supervisor, though, lacks the authority, not to mention the budget and staff resources, to fix the problem. That leaves your supervisor with two choices. They can: (1) bury the problem and hope it isn’t excavated until after they’ve departed for less-vulnerable pastures; or (2) escalate the problem to their manager, who then has the same two choices.

Rinse and repeat until the problem reaches a manager who does have the budget and authority, and can reallocate staff priorities to fix it. That should do it, but it doesn’t, because this manager is, by definition, also the manager who will be blamed for the problem if it becomes visible at blamestorming levels.

That’s when things get ugly, because while fixing the root cause might not be all that difficult and could be handled quietly, fixing the accumulated damage — in this case restating a balance sheet whose inaccuracies have gradually accumulated over a period of years — can’t be kept under the management radar.

Blamestorming: Bureaucracy’s big fix

The most common “solution,” such as it is, is the practice known as “bayonetting the wounded” — firing or disciplining everyone in the reporting chain directly below the manager who sits at the top of the problem tree and therefore logically owns it.

By establishing that they “hold people accountable,” the bayonetter creates a political buffer that makes them part of the solution rather than the cause of the problem. This layer of protection lets them fix what needs to be fixed without endangering themselves.

A less popular solution is whistleblowing. It’s unpopular among individual contributors because it isn’t a career-enhancing move for those who whistle and frequently leads to bayonetting the aforementioned wounded among their peers.

It’s also unpopular because its impact is, more often than not, negligible. Employees are, as a result, hesitant to take that path, and management is even less likely to encourage it.

The solution? Culture change

What actually works, should the organization be led by a braver sort of leadership team, is a change in the culture of management at all levels.

The change is that when something bad happens, everyone in the organization, from the board of directors on down, assumes the root cause is systemic, not a person who has screwed up.

In the case of my client’s balance sheet fiasco, the root cause turned out to be everyone doing exactly what the situation they faced Right Now required.

What had happened was that a badly delayed system implementation, coupled with the strategic decision to freeze the legacy system being replaced, led to a cascade of PTFs (Permanent Temporary Fixes to the uninitiated) to get through month-end closes. The PTFs, being temporary, weren’t tested as thoroughly as production code. But being permanent, they accumulated and sometimes conflicted with one another, requiring more PTFs each month to get everything to process.

The result: Month ends did close, nobody had to tell the new system implementation’s executive sponsor about the PTFs and the risks they entailed, and nobody had to acknowledge that freezing the legacy system had turned out to be a bad call.

Everyone involved in the affected financial areas and IT areas that supported them knew about: (1) this house of cards; and (2) that trying to alert management to it would be a career-limiting move.

What CIOs should do about this

Bad news does not improve with age. Assuming problems are caused by bad systems lets employees call attention to — and organizations to acknowledge and fix — problems when they’re small and only mildly embarrassing.

Assuming problems are caused by bad employees, on the other hand, leads to the problems becoming humiliating money pits.

Or else you can bring in consultants every few years to figure this stuff out. Just don’t ask them to reveal their sources.

Even though the sources are on your payroll, they’re still the consultant’s edge.

IT Consulting Services, IT Leadership