Bob Lewis – Page 86 – IS Survivor Publishing

Escaping the org chart: Why CoEs and CoPs matter

When we delegate responsibility, we’re frequently told, we must also delegate commensurate authority. Otherwise, we can’t hold delegates accountable.

As with so many other what-we’re-frequently-told statements, it’s more plausible than accurate.

Start with the organizational chart. What it does is document operational delegation — how the CEO has delegated responsibility (and, in theory, authority) for everything that has to happen for the organization to succeed.

Imagine you’re Director of Sales for a company that sells a variety of widgets, gadgets, and doohickeys. The company’s strategic plan calls for a 20% year-over-year increase in Gadget sales. You’re responsible, so you ask your top Gadget sales reps what they need to hit the target.

“Fix the product,” they tell you. “Our gadgets are the worst in the industry.”

So you convene a Gadget Redesign Committee, which dutifully creates new-and-improved Gadget specifications. You bestow them to the Director of Gadget Engineering.

Who bestows them right back, because he, not you, is responsible for and has authority over gadget specifications.

His strategic target is a 10% increase in gadget manufacturing efficiency. Your designs would reduce it. And you’re invading his delegated-authority turf.

Oops.

No matter how you draw the boxes and connecting lines, anything important that has to happen crosses organizational boundaries. Successful products, for example, require research-and-development, design, engineering, supply chain management, manufacturing, distribution, sales, marketing, and advertising, and I’m sure I missed a few others.

Which illustrates why, as pointed out last week, there’s no such thing as a perfect org chart.

One solution is to create cross-functional teams to address boundary-crossing responsibilities. These work well when pointed at problems that require collaboration among those competent at the different disciplines required for success at whatever it is that needs to be successful.

But cross-functional teams are less well suited to when the company needs to be competent at something, with “something” encompassing organizational capabilities like: Project management, architecture, process design and management, organizational change, and quality assurance, to name a few.

That’s where Centers of Excellence (CoE) and Communities of Practice (CoP) come into play. Both are boundary-spanning entities whose goal is to improve organizational competence at a specified discipline.

Where they differ: CoEs are official entities with assigned leadership, budgets, and goals. CoPs, in contrast, are, as the name implies, true communities — self-organized, with goals defined informally and by consensus, and with the time and effort required for their success donated by community members on top of their official responsibilities.

Compare a CoE to, say, a Project Management Office (PMO).

With a PMO, the CEO has delegated both responsibility and authority for improved project success. Having authority, the head of the PMO is in a position to define and enforce the use of the company-standard project management methodology.

But as the head of every other organization has the equally delegated authority to run their operation as they see fit, including how they manage projects, conflict is built into this arrangement, right down to its core.

The head of the Project Management CoE, in contrast, is responsible for improving project management practices with no enforcement authority. Lacking authority, the CoE has to make use of a more subtle toolkit, one that includes internal marketing, persuasion and influence, a curriculum with certifications along the way, and one-on-one selling to managers throughout the enterprise.

When you can’t dictate you have to communicate and deliver benefit.

How about CoPs? As self-organizing entities they have a lot in common with volunteer organizations outside a business setting: They depend on the enthusiasm, commitment, and evangelism of people deeply committed to the practice in question. Usually, they’re even more dependent on a highly skilled, even-more-committed, charismatic leader to hold everything together, especially as many volunteers, in the absence of financial compensation, expect payment in the form of ego gratification.

CoPs can and do provide a lot of value. But they’re an unreliable organizational solution, because expecting a CoP to happen on its own is just trusting to luck. If a useful one does form, encourage it. Just don’t rely on it.

Can’t execs drive the process? No, for a simple reason: The act of encouraging a handful of experts to form a CoP instantly transforms it into a CoE, by definition.

By all means support CoPs whenever they form. But as a reliable way to increase organizational competence, CoEs are the way to go.

One last thought: Imagine the company has chartered several CoEs. Some work better than others. Should you charter a Centers of Excellence Center of Excellence?

Repress the thought. That way lies madness. Or at a minimum, uncontrolled recursion.

The org chart alternative

There’s no such thing as … not “an IT project,” although there isn’t. Something else there isn’t is a perfect organizational chart.

You’d think that after centuries of structuring organizations for optimal performance, someone would have figured out a “best-practice” — another thing there isn’t, as it happens, but also not this week’s topic, which is, in an oblique way, something you can do to mitigate your org chart’s limitations once you’ve given up on designing a perfect one. What it is: establishing so-called Centers of Excellence (CoEs) or their grassroots cousins, Communities of Practice (CoPs).

Start with the org chart itself and why there’s no such thing as a perfect one — important because if we don’t understand the problem we’re solving we’ll only solve it by accident. And so …

Org charts are taxonomies. As a general rule, taxonomies partition each level based on the same logic as higher levels, so if the company’s top level is functional — Operations, Finance and Accounting, Human Resources, Information Technology, and so on — it usually makes sense to organize the next level by function as well, so that the CIO breaks IT down into Application Support, IT Operations, IT Business Office …

Then the CEO gets word that some multi-million-dollar project is in trouble, and realizes it isn’t the first, nor is it the second project management disaster in the making. In fact, expecting big projects to crater has become baked into the company culture.

Crater is the default expectation. Late being better than never the CEO recognizes the root cause of project management failure: There’s no “one throat to choke” — no one organization whose head ends up on the chopping block (if you’ll forgive my mixing of executional metaphors).

The topic goes on next the ELT (executive leadership team) meeting agenda, where the CIO recommends the “best practice” solution, namely, to establish a PMO (project management office), to be given responsibility and authority for defining, establishing, and overseeing project management best practices throughout the enterprise … and here’s the punchline … crossing all organizational boundaries.

The ELT, that is, has just recognized the fundamental limitations of taxonomy design: No matter how you break things down from trees to branches, to leaves, to veins in the leaves, some responsibilities will never fit neatly into just one box.

Which is too bad, because whether it’s something seemingly simple like adding a PMO or some other box, or something more complicated like a full-bore organizational restructuring, when you’re done drawing boxes and connecting them with lines, some responsibilities just don’t fit.

The point of reorganizations is to fix problems by removing barriers, but every barrier removed is really a barrier that’s just moved.

Reorganizations, that is, fix what’s broken by breaking what’s fixed.

Which is why, a year after our mythical ELT establishes the PMO and commissions an independent review of its outcomes, they discover that, when compared to pre-PMO times:

Projects fail at the same rate.
Actual project management practices are still scattered and inconsistent.
Project managers face twice the administrative burden … they have, that is, twice the paperwork.
Everyone involved complains that the PMO has turned into little more than a stifling, choking bureaucracy whose main purpose seems to be establishing a bunch of flaming hoops everyone else has to jump through.

It isn’t the PMO’s fault, either. It was chartered to prevent failure, not to foster success. Of course it became a bureaucracy. Try to prevent failure and you’ll do what it did: List every reason projects fail, and establish reviews and checklists to make sure none of those reasons happen here.

Sadly, what they miss is that, taken together, their reviews and checklists become new causes of project failure.

Which is why CoEs and CoPs often work better than attempts to solve problems through more oversight groups.

CoEs’ and CoPs’ purpose is to foster techniques that work well, and to find ways to improve them further, in domains that cross organizational boundaries.

Crucially, they’re chartered to have little (CoE) or no (CoP) authority, so they have to achieve their goals through persuasion and influence — they can’t compel compliance, only encourage participation.

The difference between them: CoEs are official bodies. A project management Center of Excellence has someone or a small team, part of whose official responsibility is to improve project management practices throughout the enterprise.

A CoP does not. It’s a grassroots organization composed of enthusiasts who participate because they want to.

And gee … what a shame. That’s all the time we have this week. Next week we’ll pick up where we’re leaving off.