Fear of Content
August 13, 2011
Content can be a little frightening, it’s true. Not to everyone mind you. Some people simply love content, with all its oddities and challenges. More often than not these are the people who spend much of their time designing and creating content. But there are definitely people who look somewhat askance at this thing called “content”. The reasons why some people are less than enamored with content are worth considering and not only to refute them. There may well be good reasons to be afraid – or at least to approach content with due respect.
Now the truth is that the vast majority of people do not fall into either of these categories. These are the people who have never given any thought to what content might be. And if these people are confronted with the question – What is content? – their answer might be something like – It’s the stuff we publish. Actually that’s a pretty good answer. But it’s not an answer that is necessarily based on much reflection. In most cases, what we will find underneath this answer is a base assumption that content is a pretty simple thing.
Now what typically happens when you start into a content management project with the base assumption that content is a simple thing? The answer to this question is simple – disappointment and sometimes even dismay. It turns out that content is anything but simple. And strategies and implementations that assume otherwise quickly encounter problems.
Among the areas where this pattern is seen in action most frequently is within the Information Technology (IT) branches of organizations. To people who are seasoned implementers of databases and business applications, content is merely the stuff that has not yet merited their attention and therefore has not yet benefited from the discipline that comes with proven analytical and design methods. The distinction is made between unstructured content and structured data. A common statement you will hear is “it’s just content – what we need is data”. Seen strictly from the perspective of what most business applications can handle, this sentiment actually does make some sense. Or at least we can understand it in this context.
However, experience has repeatedly shown that several consequences immediately flow from the viewpoint that sees content as raw material that is simple, unstructured and awaiting proper organization. First, the analysis activities that genuinely attempt to model all of the structures evident within content quickly find themselves in a continuous loop of refinement. If they are carefully attending to what they are finding and to what the various stakeholders are saying about the content, it seems that there is virtually no end to the details that come to the surface. Second, the design and implementation of the database environment becomes a far more onerous undertaking that anyone expected. Third, the output products generated by the publishing processes always seem to disappoint someone. Finally, because it was assumed that content is simple both the project budget and the selected solution technology are found to be completely inadequate. The need to continue applying resources to refining the analysis, stabilizing the database environment and adapting the outputs therefore hits the wall of management impatience.
Following this path at least has the benefit of delivering some of the lessons that only implementation experience can provide. It is often at this point that people really begin to wonder about what content might be. And if they reflect back on their experiences they come to see that content is not simple and that it’s best not to think of it as “unstructured”. In fact, it becomes evident that it is much more prudent to classify content as “hyper-structured”. Content brings together a variety of data patterns, often from diverse sources, pedigrees and domains, and then arrays these data patterns within complex rhetorical structures that professional communicators are adept at using to convince people to behave in certain ways – literally to “inform” them. This is one of the key take-aways from Bob Boiko’s book “Laughing at the CIO”. For content to be modelled and managed well and for useful, and usable, information products to be published, it is essential that content initiatives start with this more fulsome understanding of the nature of content.
Now when the true nature of content is encountered, even if it is not fully appreciated, one common reaction will be denial. It won’t necessarily be recognizable as such but it will clearly be visible in shaking heads, dismissive hand gestures, glasses being removed, notebooks being closed, meetings coming to an inconclusive end, managers being called, accusations being made. For those who assumed that content is simple, and that their content projects would be easy, the inevitable disappointment still comes as a rude awaking.
In all too many cases, particularly amongst IT shops where content will almost always remain a peripheral distraction, an initial disappointment does not lead to much in the way of learning or adaptation. More commonly, the next content initiative is simply supplied with additional resources and an emboldened mandate. This time the implementation team will get a firm sign-off from the business stakeholders on the requirements before commencing the design and development effort. With this clarity in hand, the elusive success will come into reach. Sadly, each successive effort along these lines will become a yet bigger failure and still the pattern will tend to repeat. With each repetition, a glimpse is provided into what content is really like but the cycle is sustained by an impulse to turn away ever more resolutely and to re-embrace the base assumption that content is simple and we just need to get the analysis right. This is in fact an anti-pattern that is best labelled “Fear of Content”.
However common this anti-pattern may be, there is still hope in that it is becoming increasingly important that we improve our content management systems and publishing processes and that more and more people are coming to a better appreciation of what content is really like and how it really needs to be handled. And when approached in the right way, the very features of content that can make it challenging to manage and process can also be seen as what makes it valuable, important and even at times fascinating.
Epilogue
As something of an echo of this post, I wrote an article for TechWhirl for Halloween 2013. It was intended to be a Content Management Horror Story. It can be taken as an illustration of themes touched on in this post. See A Tale from the Content Management Crypt. The text has also been included in a comment below.
A Tale from the Content Management Crypt
Halloween Content Management Horror Story for TechWhirl 2013
Like all good horror stories, this one starts with a group of normal people engaging in a convivial discussion—one full of optimism and hope. It began as an online discussion about how all content management investments generate some good. There is no such thing, it was felt, as an absolute content management project failure. Of course, this convergence of positive feeling could not be left to stand. Predictably, such cheerful dreams called forth a virtual Freddie Kruger who could not resist the temptation to intervene.
And thus a post was introduced into the story circle, called “The Perfect CMS Failure.” Perhaps because they assumed that the positive spirit of the campfire discussion would continue, the participants welcomed the contributor into the circle. They were gravely mistaken. To make things worse, the story was a very recent case study and undermining one of this group’s favourite beliefs, this case study saw the very best tools, or at least the most expensive ones, being deployed. It was immediately impossible to relegate this failure to the poor practices of an unenlightened past.
So the story begins harmlessly enough. A senior consultant was contacted by a large government organization that administers the judicial process within a specific jurisdiction. They wanted an independent assessment of their most recent foray into content management. This organization had invested heavily in an enterprise content management system and they disclosed that they had encountered a “few issues.”
This project had started with the usual honeymoon phase. Requirements-gathering sessions were convened and participation was good. This was impressive because many of the users were high-priced, and very busy, lawyers. And a team of high-priced consultants had been flown in from around the world to help with this effort. The requirements snowballed, and before long the team had an impressive matrix of requirements that would be used to select a content management system. Given the nature of the legal environment, many of these requirements revolved around ensuring that sufficient security controls were in place for the content.
This process happily culminated with a CMS selection that coincided with the parallel technical selection process, driven by criteria such as compatibility with the existing infrastructure, team skills, and architecture standards. At this point in their project, things were looking great. The choice of CMS platform would be one of the most expensive available, if not the most expensive, but it covered all the requirements and was especially strong on the security side. As when Icarus flew higher and higher, the project stakeholders started to congratulate themselves even before the roll-out began. In fact, they were so confident that they jettisoned plans for a pilot deployment so they could acquire a full enterprise license and charge straight through to implementation. Like Icarus, they probably didn’t notice the impact of the heat of the sun on the wax on their wings.
The implementation proceeded relatively smoothly, and a surprising number of the organization’s staff, including the high-priced lawyers, participated in workshops convened to refine the implementation details. Usability experts were engaged and worked earnestly to build in support for the users’ needs. External stakeholders were involved to ensure that the implementation was also implemented in a way that would conform to a raft of government standards and edicts on information management. The technology group established processes for performing a mass import of information from legacy systems scattered around the organization and that the new CMS was intended to replace. Training sessions were conducted and reference resources made available to all impacted staff. Although some who had been down this road before might have seen what was coming and given warning, the project stakeholders moved onto their second batch of Champagne as they approached the “go live” date with no indication of the darkness that lurked behind the project dashboard.
True to the horror story motif, it was only on the very day that the new system was to “go live” that problems were noticed. And although these problems had been initially positioned as a “few issues” the magnitude of the problems was in fact, breathtaking.
On the “go live” date, the new system was launched. It contained the master copies of all documents created in the department and that remained of active interest. The new system was the place where all future work within the organization was going to be transacted. It was a “Big Bang” cut over. “Big Bang”, it turns out was an apt choice of words.
On one level, the failure was in the technical implementation. As high-priced lawyers sat down at their desks they realized that their machines were taking an unusually long time to start up. In most cases, their machines never did start up successfully. It turned out that the CMS client, when combined with the security software that it was bundled with, was simply too much for the desktop or laptop computers to load up. On the functional level, those few users who were able to gain access to the system found the combined effect of all the isolated efforts to optimize the environment for various needs, such as records management, in fact made the workspace a virtual train-wreck of complexity. Finding things, sharing things, using things proved to be as unbearably difficult as holding onto an umbrella in a raging thunderstorm.
Within a matter of minutes, the system was abandoned by its victims, the users, as completely unusable who retreated to the relative safety of legacy systems like villagers draping themselves in garlic. Suddenly the stakeholders, like the high-priced lawyers, raised objections that all their time that had been invested in good faith in the project had been wasted. The cost of this time alone ran to a figure that was comparable to the significant licensing cost for this enterprise tool.
Naturally, the horribly scarred project team contacted the vendor of the tool with a desperate plea for assistance. But the vendor, who might have been named Lector or Hyde in another time and place, said that they were about to retire this product and that the only real option was for the organization to migrate to a new, and completely different, offering. And unfortunately there would not be any credits provided for the acquisition of the new tool. In effect, none of the development investments that had been made would be portable to the new environment.
It was about this time that our intrepid, and innocent, senior consultant appeared on the scene to look into the “few issues” that the project had encountered. On the very first day of this engagement, the consultant, like an Egyptologist interpreting the hieroglyphic curse at the entrance of the tomb, had to inform the CIO and the senior business stakeholders that their project was a “perfect failure.” The investments made, on a per user basis, could not have been higher and the system logs proved that not a single user had performed any work in the environment. The stakeholder community who had invested so much effort and so much hope had, in the course of minutes, splintered into recalcitrant pockets of users using tools and processes of their own design. Because the “Big Bang” had coincided with the turning off of several legacy systems, these users were forced to come up with fall-back positions and post-apocalyptic manual workarounds.
As should have been expected, the CIO postured a lot and pretended to be unsurprised that this business-led initiative had fallen afoul. The project could still be seen as a success from the perspective of the technology group, because they had been able to expend their annual budget on schedule and the technology group team members had successful retired many legacy systems, a metric that the CIO was to be evaluated on.
So as the dust settled, the meaning behind this failure began to sink in and it was perhaps the most terrifying thing. On the surface of things, it looked like everything was done correctly. All the right specialists were involved. All the right stakeholders had been engaged. But the result was a massively expensive CMS repository solution with no active users and no active content – even though it technically held everything that was important. The failure had been perfect – even sublime. And, in the deep of the night, there is one thought that still awakens the consultant who found himself performing the autopsy and who grew silent as the terrible truth was laid bare. This perfect failure was a result not so much of doing things wrong but of doing too many things right. Like the tale of the body-snatchers, it was difficult distinguish were the guilty parties and the innocent victims (although it seemed pretty clear that the CIO had blood on his hands).
Our protagonist emerged from the experience with a changed view of the world. He had seen failure before but nothing quite so stark and unrelenting. There was simply no room left for optimism or hope. This consultant would forever after be unable to participate in discussion circles where this optimism and hope were the main currencies. And as expected, the introduction of his story into the original discussion circle led to complete silence. Suddenly cheerleading seemed out of place. And the walking dead moved on in search of new hope and perhaps new victims.
Posted by: Joe Gollner | January 25, 2014 at 04:12 AM