The Content Management craze, and why it’s a cautionary tale for today’s IT managers

A few years ago a public sector client asked me to look into the feasibility of implementing an enterprise content management system. Somebody at the upper level in the client’s organization had fallen in love with the whole concept of content management. By itself, that wasn’t the problem—CM is hugely important, and can be a powerful tool for both productivity inside an organization and branding outside of it.

However, my client was worried about her colleague’s infatuation with one CM solution in particular. That solution, marketed by one of the big software vendors, started at around $750,000 per license—plus the vendor’s fees for implementation and maintenance. An allegedly independent IT consultancy had done a prior study into the feasibility and desirability of the above-mentioned vendor offering, and had wholeheartedly recommended that particular package. But was it necessary, my client wondered, to fork over that kind of money? Wasn’t there any other way to introduce CM to the organization? And did the organization need CM in the first place?

In the course of answering these questions, I interviewed many people in the organization. Not surprisingly, the $750k “solution” had its backers and detractors. My job was to figure out which of them had the better argument. Public money—and my client’s own budget, not to mention her reputation—were at stake.

One interviewee gave me all I needed to recommend against the vendor solution. When I asked him about lower-cost alternatives, he stonily looked at me and said “how about no cost alternatives?” He then went on to describe in detail the plethora of free open-source CM tools that were available. I asked him if he had recommended any of these tools to management. He said he had, but that senior managers—especially those who aren’t familiar or comfortable with IT—feel they are getting value simply by spending money.

After researching the open-source tools that were then available (this was 2006) and comparing descriptions and reviews with descriptions and reviews of the proposed vendor’s offering, I recommended against the vendor offering. I told my client that she could test an open source CM solution for free and see if it jibed with her organization’s way of working. That was a low-cost way of at least seeing if the organization was ready for CM (or if CM was ready for the organization). She took my advice.

Other public sector organizations in Canada didn’t show that kind of circumspection. Many plunged into CM, buying from the vendors that were around back in the day: packages like Interwoven, Divine, MS CMS.

And where are those packages today? Not one is available as a commercial package. They were all overwhelmed and simply replaced by free open source systems like WordPress and Blogger (which I am using here), or by free-membership “clubs” like the mighty Facebook, the back-end of which is proprietary but was built using a free, open source programming language (PHP) and database (MySQL).

My client’s decision to listen to her free-open-source adviser was a good one. I’m not saying that that is the way everyone should go. I’m saying that all organizations should seek out the advice of people who know their stuff and are not afraid to think critically. Every feasibility study team should contain people like this.

Designing agile organizations

Every manager has run into bureaucratic inertia. Some have complained that getting a bureaucracy to change direction is like turning around an aircraft carrier in a narrow channel. Even more frustrating are the situations in which no one disagrees that things have to change.

So why is organizational change so slow and so painful?

Often it is because organizational units share power over decisions and actions. Collaboration between such units—or across functional areas, or between government departments and agencies, or between countries—becomes an exercise in what some management theorists have called the “complexity of joint action.” With multiple decision-makers, each decision entails some degree of “friction,” which adds time to the process.

In such circumstances it is easily possible for all players to agree on the precise aim of a joint enterprise, and on a blueprint for action—and for the enterprise to grind to a halt in spite of this agreement. What seems obvious and easy is actually extremely convoluted and complex.

For example, I recently worked on a project whose aim was to centralize certain core administrative functions across a vast bureaucracy. It seemed obvious to everyone concerned, from the designers of the project to the implementers and those whose work would be radically transformed, that these moves were necessary and that they would result in big cost savings and better work experiences.

But once we really got into the work, we discovered the range of interdependencies between these seemingly straightforward administrative functions. We identified over 70 individual administrative actions within four major functional areas. We had not initially appreciated that these interdependencies would grow geometrically over time, as more participants became directly involved in the new processes. Nor did we realize the difficulty of obtaining consensus between the major participants. Once we did, our problem-solving focus shifted from more rational organization design to consensus building.

Problems of joint decision and action have become more common, with the advent of more horizontal structures in government bureaucracies. This is not to say we need to return to rigid hierarchy and all the problems it entailed. But a healthy respect for the difficulties of joint action is a pre-requisite for anyone who proposes, designs, or implements such an initiative.