Last night on the airplane, the fellow sitting next to me spoke candidly on the condition that I\u2019d mention his son\u2019s name in print. Hi, Brian!\n\nHe also demanded anonymity. We\u2019re 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\u2014major implementation programs in two different huge corporations\u2014he conservatively estimated that one-third of the costs of the project were wasted in the name of Sarbanes-Oxley (SOX) compliance. That\u2019s 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 \u201cwasted\u201d? Corporate accountability isn\u2019t a waste. No, he protested. He insisted he wasn\u2019t 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 micromanagement. Let\u2019s look at how SOX and other regulatory requirements are sometimes implemented in a way that\u201ds disempowering and expensive. \n\n\n\nTwo Dimensions of SOX ComplianceAs 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 \u201csales\u201d 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\u2019t a total waste. On the other hand, SOX (and other regulations such as 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\u2014\u201cartifacts\u201d if you like buzzwords\u2014that 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\u2019t 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. \n\nThe End Does Not Justify the MeansWallace gave me an example. In the name of SOX compliance, one of the companies that Wallace had 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\u2019s specifications. But the problem was this: The ERP systems (widely used, world-class products) are modularized and well-documented. However, they don\u2019t 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 \u201chow\u201d as well as the \u201cwhat.\u201d\n\nThe Meaning of EmpowermentThe 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\u2019ve 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 \u201cwhat,\u201d not the \u201chow\u201d\u2014by the bottom line, not the top line. It means making clear exactly what\u2019s expected, and then leaving staff free to figure out the best way to deliver it. There\u2019s no problem in requiring clear, understandable documentation of development and testing processes as a work product. That is a \u201cwhat.\u201dThe excessive costs were the result of the across-the-board mandate to do so using a specific method, in this case, UML\u2014a \u201chow.\u201d\n\nPrinciples of EmpowermentConsider, 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: \n\n\n\nWe ask people for and measure (results), not tasks, processes, and effort. \n\n\n\nWe base the magnitude and complexity of the deliverable on the degree of confidence people have earned. I.e., if we lack confidence in people\u2019s ability to do big projects, we empower them in smaller chunks rather than micro-manage them. \n\nWe 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). \n\nWe clearly define in advance any constraints that limit how the work is to be done. \n\nWe provide the resources, authorities and information needed to deliver the agreed results before expecting others to accept accountability. \n\nWe 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: \n\nWe follow processes established by our own group as tools when they add value, not as bureaucratic rules which are followed without question. It doesn\u2019t 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\u2019s just one way to produce clear documentation, and may not be the best in every circumstance. \n\n\n\nAs we\u2019ll no doubt see in the comments below, there are those who will defend rigorous standardization at all costs. But remember, where you stand depends on where you sit. So-called \u201cprocess owners,\u201d internal quality \u201ccontrol\u201d 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\u2019re not, then fire them. But presuming you hired your staff because they\u2019re 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. Dean Meyer coaches CIOs on organizational, political and leadership issues. He listens, and offers perspective with his compelling business-within-a-business paradigm and the common sense built over 35 years in the IT industry. He works with you to plan practical solutions, drawing from a wealth of implementation experiences and proven systemic change processes. For a no-obligation get-to-know-you chat, contact his office at email@example.com or 203-431-0029.