Last night on the airplane, the fellow sitting next to me spoke candidly on the condition that I'd mention his son's name in print. Hi, Brian!

He also demanded anonymity. We're not talking about a national political intrigue here, but the facts are disturbing.

Wallace (not his real name) is an ERP consultant. On his last two projects -- major implementation programs in two different huge corporations -- he conservatively estimated that one-third of the costs of the project were wasted in the name of Sarbaines-Oxley (SOx) compliance.

That's a 50 percent increase in project costs over what they otherwise would have been!

I was skeptical. Sure, there are costs of compliance with all regulations. But "wasted"? Corporate accountability isn't a waste.

No, he protested. He insisted he wasn't talking about the costs of complying with SOx. Rather, he was saying that these companies could have complied to the same degree for far less money.

Now he had my interest. As I probed, I learned that the real issue was not SOx, but instead was micro-management.

Let's look at how SOx and other regulatory requirements are sometimes implemented in a a way that's disempowering and expensive.

Two Dimensions of SOx Compliance

As with many regulations, SOx generates two distinct requirements.

On one hand, it causes clients to buy applications from IT that help them report data in a truthful, transparent, and timely manner. From the IT perspective, this is nothing more than a driver of systems requirements. The regulation generates "sales" for IT internal service providers, at a cost to the company. But one would expect that clear data should be useful to leaders and shareholders as well as regulators, so the cost of these systems isn't a total waste.

On the other hand, SOx (and other regulations like validation in the pharmaceuticals industry) requires that IT produce documentation of its development and testing processes, among other internal controls. These are additional work products -- "artifacts" if you like buzzwords -- that become another deliverable inherent in any development project affected by the regulations. And of course, they have a cost too.

But again, documenting processes isn't a total waste. Doing so should help IT improve its processes and produce better and more maintainable systems.

The waste that Wallace was talking about is more subtle.

The End Does Not Justify the Means

Wallace gave me an example. In the name of SOx compliance, one of the companies that Wallace had worked with mandated the use of a specific documentation method, UML (Unified Modeling Language), for all systems built by IT. UML, incidentally, is an excellent way to describe an object-oriented system's specifications.

But the problem was this: The ERP systems (widely used, world-class products) are modularized and well-documented. However, they don't fit neatly into the UML paradigm. To develop the documentation required by SOx would have been standard fare, especially since much of it can be based on information supplied by the vendors. But to develop it in UML was extremely time consuming.

Regulations dictated internal controls, and IT leaders interpreted this as requiring documentation. So far, no problem. But IT leadership drove the costs sky-high when they issued an across-the-board edict that the required documentation was to be done in UML.

There may be some value in consistency in the form of documentation, but did anybody consider the cost versus the benefit? I doubt it.

Let me be more precise in defining the root cause of the problem: IT leaders mandated the "how" as well as the "what."

The Meaning of Empowerment

The word "empowerment" means two things.

First and foremost, it means matching authority and accountability. If anyone ever has more accountability than authority, there will be trouble. They may not be able to do their jobs the best way, or even do their jobs at all. Whenever you ask anything of your staff (or anybody else), you've got to be sure they have all the information, resources, and authorities they need to get the job done.

Second, empowerment means managing people by the "what," not the "how" -- by the bottom line, not the top line. It means making clear exactly what's expected, and then leaving staff free to figure out the best way to deliver it.

There's no problem in requiring clear, understandable documentation of development and testing processes as a work product. That is a "what."

The excessive costs were the result of the across-the-board mandate to do so using a specific method, in this case, UML -- a "how."

Principles of Empowerment

Consider, as an alternative, the following principles and corollaries, drawn from our vast best-practices database, that especially apply to leaders.

When we ask things of others:

• We ask people for and measure (results), not tasks, processes, and effort.
  • We base the magnitude and complexity of the deliverable on the degree of confidence people have earned. I.e., if we lack confidence in people's ability to do big projects, we empower them in smaller chunks rather than micro-manage them.

  • We define the results we measure broadly, to include not only the intended outcomes but also unintended consequences (i.e., "leaving dead bodies in your path" is another form of result).

  • We clearly define in advance any constraints that limit how the work is to be done.

• We provide the resources, authorities, and information needed to deliver the agreed results before expecting others to accept accountability.

• We offer support and coaching (mentoring) without dictating tasks or overriding decisions (which would imply reassuming accountability). When we do so, we make it absolutely clear that our advice is not a command.

And hand-in-hand with these fundamental principles of empowerment, consider this entrepreneurial principle for those doing the work:

• We follow processes established by our own group as tools when they add value, not as bureaucratic rules which are followed without question.

It doesn't matter that UML (or whatever standard you pick) is a very good tool. Indeed, it may be the best tool in many cases. But remember, it's just one way to produce clear documentation, and may not be the best in every circumstance.

As we'll no doubt see in the blog below, there are those who will defend rigorous standardization at all costs. But remember, "where you stand depends on where you sit." So called "process owners," internal quality "control" staff, and external consultants who sell process designs are paid to dictate how others do their jobs. Empowering those actually doing the work, and turning these process experts into advisors (rather than controllers), threatens their power and job security.

The people doing the work are in the best position to know how to get the job done, once they understand what outputs are expected of them. If they're not, then fire them.

But presuming you hired your staff because they're competent at their jobs, free them to be creative. Give them standard tools and methods, training, and process advisors to help them, but empower them to deliver their work products in the most efficient way.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....