Skip to content

8 reasons COEs fail (Part 3)

February 24, 2010

In this post, we conclude our consideration off the eight reasons COEs fail with reasons 6-8.

#6. Inappropriate COE model for the process area, business activity, or capability the COE is meant to address

As I touched on in reason #3 in the last post, there is a continuum of authority that any given COE sits on, from purely advisory to authoritative, i.e., from here’s a recommended way to do things to here’s the way they must be done. This is one of the axes that COE design must consider: the other is from strategic to operational activities, i.e., will the COE only be involved in deciding what will be done, or also in deciding how to do it?

For example, consider an organization that has a need for getting its records management (RM) improved because it’s in a heavily regulated industry and has recently come under fire for poor RM practices. An RM COE won’t have the desired impact at this organization if it’s purely an advisory and strategic one rather than an authoritative, operational one. It can publish all the policies it wants, design as many RM processes as it can think of, and hold RM lunch and learns till the cows come home. At the end of the day, the folks on the ground in the lines of business will continue to do whatever is operationally expedient with their records—which is precisely what got the organization in trouble in the first place. And the COE will be seen as ineffective on the basis of the work it did, which may in fact have been excellent, rather than on the failure of the underlying model, which was the real culprit.

But the answer isn’t always to give the COE more authority, as tempting as that is. To take another example I see frequently in my practice, let’s consider a project management COE (often referred to as a project management office, or PMO). Project management (PM) is a capability that varies widely from organization to organization and even within organizations. Process heavy, process adverse, PMI adherent, organization specific, PMO driven, LOB owned—there are a myriad of ways to tackle the problem of running projects at an organization, none of them intrinsically better than the others, but all dependent on lots of factors for their success or failure.

Finding the right model for a PM COE, then, is not simply a matter of giving it the most authority possible, because in the long run this may do more to hurt the cause of good PM practices at an organization than help. Here’s what I mean…

Let’s say that the culture of project management at an organization favors local control and has been generally successful to date, but the organization is interested in leveraging common processes and documentation across the enterprise. A PM COE established as the final word on all things PM may end up encouraging shadow PM activities even as it tries to standardize PM across the organization—except that now, these won’t be as visible as they were before the COE was established. It may try to place its own project managers on all projects, which could result in less successful projects as project team members only marginally cooperate with the outsider PM resource among them. And finally, it may author and institute standard documents on all projects, which, no matter how excellent, may be adopted grudgingly and used incorrectly by reluctant project ream members.

What might have worked better in such an environment is a PM COE that was a purely advisory body, that sought its members widely from across the organization, welcoming anyone who has a stake in the practice of PM at the organization; that started from an analysis of how things are actually done at the organization to find a common ground of best practices rather than from theoretical best practices that it pushes onto the organization.

#7. Culture clash between COE and larger organization

As the two (admittedly simplified) examples in the last section suggested, the COE model must be appropriate for the process area, business activity, or capability its meant to address if it is to succeed. Central to that, however, is making sure that the COE doesn’t clash with the culture of the larger organization.

Culture clashes can be of a couple of different kinds, but the two that I consider most relevant to the success of a COE are process-centric vs. process-adverse and centralized vs. federated decision making. Organizations with an enterprise license for Visio Professional 2007 and a laminated process flow diagram for everything they do versus organizations that have handwritten cheat sheets even for mission-critical activities like journal entries or legal holds; organizations where upper management can mandate the use of a new system or process and expect adoption and compliance versus organizations that have to bargain with and convince their lines of business to comply with even the least burdensome request—we’ve all seen some variety of these tendencies in our working lives, and both of them impact fundamentally how effectively the COE will be able to operate at any given point on the advisory-authority and operations-strategy continuums we discussed in the last section.

I’m not suggesting in all this that the COE “mirror” or “fit exactly” the larger organizational culture, because in many cases the COE is being created precisely to change the prevailing organizational culture for the better. But the COE must do so with eyes wide open and with an operational plan for how it will achieve results despite the delta between it and the larger organization, otherwise it will be more difficult (and quite likely impossible) for it to do so.

#8. Failure to adapt to changing conditions in the larger organization or marketplace

This final reason is a bit different from the others in that it has to do with the ongoing sustainment of the COE rather than its design, planning, and implementation. So much time and effort goes into making sure the COE is aligned with the larger business context while standing up the COE that members can forget that the COE must do ongoing work to remain in alignment.

There are many ways a COE can get out of step with the larger business context, everything from changing priorities at the leadership level of an organization to the introduction of new technologies or capabilities in the marketplace. A collaboration COE built in 2007 will have been organized around an approach to collaboration and the dominant technologies for supporting it that are already shifting, both because of new technology (tablets, widely available open source smart phones) and changes in the way people use social computing technologies in their private lives (Facebook, LinkedIn, Twitter, Flickr). If a collaboration COE failed to take these changes into consideration, it would be hard pressed to continue to deliver value to the organization.

Given this, COEs must make sure they devote a certain amount of their time and energy keeping an ear to the ground for organizational and marketplace changes that may affect them. How much will depend on a range of factors, from the kind of COE and the industry of the larger organization to the technologies involved, and everything in between.

The final word

In the end, these are the eight reasons I’ve found that COEs fail, but I’d be interested to hear about the experiences others have had in trying to stand up and maintain successful COEs, whether as consultants, COE participants, or even passive observers who’ve witnessed the success or failure of COEs from the sidelines in the course of their working lives.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s