All Posts in Organizational Effectiveness

|In: Organizational Effectiveness|Last Updated:

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.

Comments

|In: Organizational Effectiveness|Last Updated:

When you move your family, even if it’s into your (and presumably their) dream home, the inconveniences outweigh everything you love about the new place.

At least they do for a while, which is why, if you’re in the change business, you should read and re-read William and Susan Bridges’ Managing Transitions. It clarifies the essential divide separating a change’s immediate annoyances (the transition) from its ongoing joys.

Which is why I had my annual physical before upgrading our household to Microsoft 365.

I wanted my blood pressure to look good.

So while I like my terabyte of cloud storage and 50 more gigs for email, I didn’t at all appreciate the three multi-hour chat support sessions required to make them available (don’t ask).

Not to mention the time spent finding all the features that have been rearranged.

Which brings us to why, if you’re in the change business, you should also ponder how and why it is that plug-in hybrids and pure-play electric vehicles are more likely to dominate future driving than the vastly superior alternative — cars powered by hydrogen fuel cells.

Disagree? Explain why in the Comments. For our purposes today just go with it.

The problem with hydrogen powered vehicles when compared to plug-in hybrids or pure-play electrics is as easy to grasp as it is difficult to solve.

Pure-play electric vehicles need electricity. As a nation we have an electrical grid that delivers it. It might (and does) require upgrading, but it’s there. Plug-in hybrids need the grid, along with gasoline or some other hydrocarbon-based fuel. We have a deep and rich system in place for obtaining, refining, distributing, and selling this stuff in massive quantities.

Hydrogen? Even overcoming the unfair perception, created by the Hindenberg, that hydrogen is too explosive to ever be safe. I’ve read that most of those who died were killed by the fall; the hydrogen itself, being lighter than air, floated up as it burned).

Where was I?

Overcoming the complete absence of a hydrogen distribution network will most likely prevent hydrogen from ever catching on as a fuel.

Now about that software project you’re running.

By now, assembling requirements or their Agile user-story equivalents, is something most IT shops know how to do. Your developers know what outputs the software is supposed to deliver, and the inputs and algorithms it needs to deliver it.

Your testers have the same knowledge and know how to turn it into an organized, and ideally automated test plan and program. Your project might not deliver bug-free code, but its bug count won’t be the sort of embarrassingly huge number generally reserved for astrophysicists trying to describe the age of the universe in months. No worries on that front.

You’ve ticked all of the check boxes put in front of you by the Change Advisory Board (CAB) and Architecture Review Board (ARB). These i’s have been dotted and t’s crossed.

And you’ve involved Organizational Change Management (OCM) throughout. They’ve communicated with everyone to explain why the change is necessary and good, and they’ve put a training plan in place which you’re ready to launch just as soon as you know the official deployment date.

What could go wrong?

Welcome to the problem of hydrogen logistics. Sorta. It’s an analogy. Don’t worry if it’s not a perfect fit.

Anyway, imagine, for the sake of argument, the software your team is preparing to deploy is to consolidate the 17 supply chain management systems that are the legacy of past corporate acquisitions.

You might have designed the new software to be flexible enough that all 17 supply chain managers can use it to manage their supply chains as they like (the car will run on hydrogen, gasoline, diesel fuel, or batteries) at which point you might as well have designed and developed 17 separate supply chain management systems. You’ll deliver all pain and no gain.

Or else, all 17 supply chain managers agree to standardize their processes so they can use the same software the same way. It’s as if enough gas stations start selling hydrogen, fuel delivery trucks are retrofitted to transport it, and so on that anyone driving a hydrogen vehicle anywhere can fill it up before it runs out of fuel.

Let’s hope process standardization is the plan. If it is, make sure your OCM trainers avoid a common mistake: Teaching business users how to operate the software, not how to do their jobs a new way with the software.

That leaves you with one advantage over hydrogen: You don’t have to convert supply chain management all at once.

But you do need to figure out who will go first.

And last.

# # #

Want to be more adroit at making change happen in your organization? Get yourself a copy of There’s No Such Thing as an IT Project. It’s nothing but practical ideas you can put to use tomorrow.

Assuming, of course, you’re a fast reader.

Comments