Contented Management laughing buddha logo

Contented Management

Contented Management

WCM season preview

Leon playing football

The new Premier League season is upon us in England and it was with some surprise that I noted Tottenham were being sponsored by Autonomy, purveyors of Bayesian probability and content management systems.
Professional integrity dictates that I shouldn’t exclude Autonomy from shortlists just because of who they sponsor, but this deal may cause those of you with taste to reconsider whether Autonomy are meeting their corporate and social responsibility targets. Yes, I am an Arsenal fan.
I was going to write an article that mapped each Premier League team to a WCM product, but realised I’d be sued by anyone I associated with Blackburn Rovers or Stoke City. Nevertheless, I think their are a number of useful analogies to be drawn

Beautiful doesn’t always mean effective

Some WCM products have editorial interfaces that entice you to play around with them: thoughtfully designed with user-friendly tools like drag and drop, red-lining, or DAM integration. Others practically repulse: ugly web forms with incomprehensible labelling and non-sensical reference data.

But don’t assume that a beautiful GUI makes for more effective content management processes. Just as Bolton Wanderers are restyling their footballing approach under Owen Coyle to be more appealing, this won’t mean they’ll finish higher than they used to under the ugly pragmatism of Sam Allardyce. Give free reign to your editors’ creative spark and you may find your content strategy going down the pan.

A solid financial basis

Virtually no Premier League football club is without debt. WCM vendors are in a less financially perilous situation but hardly paragons of financial stability. This should make you wary in your contractual dealings with them. Always hold proprietary source code in Escrow. It’s not much of a security but it’s better than none at all. Check the financial stability of services partners and weigh this against their ability to deliver: a team that’s doing badly is likely to have disincentivised staff and the best of them may be looking to leave.

Be wary too of cutting deals that actually disincentivise your suppliers: if you cut their profit margin too much they’ll focus on more profitable accounts when the going gets tough. And the last thing you want to do is see your team go into administration like Portsmouth last season.

Living off past glories?

Just as some Premier League clubs look down on new entrants and see themselves as the established top tier, some WCM vendors subscribe to a similarly blinkered view. Don’t choose a team just because they’re an established player and appear in an analyst’s magic quadrant. Take a look at the wider field and figure out what it is you’re really after from your supplier. Having a vendor with a good reputation in the industry won’t improve your website any more than winning the league 49 years ago makes you a better club today.

The long-term view

So if you’re ignoring the past, what abou the future? No need for Paul the octopus: take a look at company history. Has there been a recent big-money acquisition? If so, you can be certain that the vendor is going to be focussing more immediate efforts on proper integration of that product rather than on new features. Assimilating new players takes time, as Manchester City discovered last season.

Or was the last release community-driven? If you don’t have the means to engage actively with that community, how are you planning on getting the enhancement (and fixes) you need the product to deliver? You’re unlikely to hold any sway over the selection despite your investment.

Where’s the support?

A crucial consideration must be who’s going to support your team once you kick off. Is there a loyal and knowledgable fan base? Are they likely to up sticks for another trendier team the minute the going gets tough? And where are they? If all your support is in a different timezone, you’re going to have problems.

In my experience, transatlantic services particularly suffer from this Manchester United syndrome of long-distance support. Many European vendors have struggled to provide north American clients with the same levels of support as clients in Europe and the reverse is certainly true. The problem is is seldom resolved by takeovers, when a larger company may bring a much larger support team, but product experts remain few and far between.

It’s not about loyalty

In the end, remember the crucial difference between implementing a WCM and following a football team: you’re a client, not a fan. I’ll support Arsenal even when the players all inevitably collapse with cruciate ligament injuries before Christmas; I’m a lifelong fan. But if you’re not getting what you need from your team, relegate them and seek your glory elsewhere.

Philippe Parker on | 20 August 2010 | Tweet this |

Contented Management

CMS fail: how not to implement a content management system

Envelope stamped with a fail

The attempts of Johnston Press, a publisher of local news in the UK, to implement a new content management system have spectacularly backfired. How can the selection of a CMS lead to a vote of no confidence in the managing director and a ballot on strike action by employees? That’s a pretty colossal project failure by any measure.

Johnston Press selected the Atex content management system. Atex, whose product is based on the acquisition of the Swedish CMS Polopoly, has carved itself a niche in the newspapers vertical and Johnston Press would no doubt have been reassured by their client list. However, the company imposed the choice of CMS on employees at a number of its titles and more importantly, inextricably linked the CMS to changes in working practice. The Guardian provides more background to the dispute.

So where did it all go wrong?

No stakeholder involvement

It’s truly crass management to push through a project without consulting those people who have to live with its consequences.  Johnston Press wanted to cut costs with an integrated cross-channel publishing environment and employees were right to fear that this would put their jobs at risk. So the CMS became an enemy, rather than a product that would help staff to work better and secure the company’s future. There may have been no way to get around job losses, but if there had been consultation about the reasons for the CMS, how it was going to work and the benefits that it would have, there could have been a more constructive dialogue and a greater chance of a decent outcome.

No content strategy

One reason why Johnston Press thought the CMS would bring cost savings was because they thought they could replace the role of sub-editors, getting the journalists who’d researched the stories to also place the stories and create the headlines. This may well have been possible, but it doesn’t look to have been that well thought through. The journalists were interested in gathering stories and information gathering. The sub-editors were interested in promoting the right messages and maintaining editorial standards. These objectives can conflict.

Again, had the management approached the project by identifying a content strategy issue – positioning the kind of tasks they wanted from their readers and establishing relevant journalistic and copy-writing processes to support these tasks – they would have stood a better chance of selling the benefits to their employees and having a successful project.

Lessons learned?

I would hope that your content management project failures haven’t been as extreme as this one, but I wanted to take two highlights from this project.

Firstly, it demonstrates the importance of an inclusive and transparent selection process. You need to involve the people who’ll receive business benefits from the system, the people who’ll support the system and the people who’ll use the system. And you need to communicate the business case to them transparently so that they understand the purpose of the CMS and don’t feel threatened by it once it’s been implemented.

Secondly, you still need people to assure content quality. The CMS can certainly help you build in those processes that assure quality, but you need real writers to write good content and achieve your business goals.

There’s a lesson for the supplier too. This publicity hasn’t been great for Atex. When a project goes so spectacularly wrong, it’s easy to assume that the software is the root cause. But there’s an onus on the supplier to deliver against a clear brief and ensure that the client isn’t being stupid. You may have got your commission, but at what cost?

If you have a more spectacular case of CMS failure than this, I’d love to hear it.

Philippe Parker on , | 9 April 2010 | Tweet this |

Contented Management

Devolving complexity

Combined harvester

What sort of editorial model do you follow for your web content management? Do you try to get as many as possible hands-on, or do you run everything through a centralised editorial team?

It’s ironic that WCMS which enable you to perform more advanced content management provide tools that you probably won’t want to devolve to part-time editorial teams. Conversely, simpler WCMS are often chosen by by smaller, centralised teams who often feel constrained by the software they use.

Vignette, for example, enables you to assign content to various taxonomies through folders, projects and channels, so that content can be cross-referenced extensively across your site. Put these taxonomies in the hands of people who don’t understand them and you’ll create convoluted user journeys: the exact opposite of your content management objectives.

Alterian’s corporate offering meanwhile — once known as Immediacy — provides pretty basic content management. Most users should be able to get their head around its tools pretty easily. But if you want to create more complex content relationships or have content fragments re-used across your sites, you’re better off with Alterian’s enterprise product, known as Morello. Devolving editorial responsibilities to part-timers who don’t fully understand the consequences of updating content that’s used in lots of places in your websites is decidedly risky, however.

In larger organisations, lots of people will produce content for the web sporadically. These people will change, have variable knowledge of the software and writing style guides, and limited understanding of your website. The last thing they need is a piece of software that allows them to break stuff because they just don’t get it.

So, do you:

  1. select a simple WCM for devolved teams to create pages in predefined templates; or
  2. select a complex WCM that enables you to perform more advanced content management tasks, but centralise the editorial process.

The more you want to cross-reference and re-use content across your sites, the greater your need for an advanced tool and an expert team to manage it. But if you want to devolve authorship, you’ll need to keep content management tasks and software as simple as possible. Don’t try to industrialise content production by providing everyone with more machinery. For broader participation you need to provide hand tools. Leave the combined harvester in the hands of experts.

Philippe Parker on , , , | 8 December 2009 | Tweet this |

Contented Management

‘Bove the contentious waves he kept

Google Wave is a browser-based collaboration tool that combines messaging, document writing and discussions in real time. I participated by proxy in an experiment with the tool last week that involved fellow content management professionals. These are my observations.

Saying is easier than listening.

In many ways the collaboration was too real time. In a spoken conversation, talking across each other isn’t really possible. In the Wave, it’s the norm. Even with half a dozen participants, it seemed everyone was piling in trying to get their thoughts down rather than considering what people were writing elsewhere. There were multiple threads to the document that you couldn’t follow at once It was like being in the middle seat at a party: it seemed like a good place to be but you couldn’t figure out which conversation to jump into. This might say more about the participants than the platform, but it is a serious issue for collaborative working where listening to a conversation, being able to respond to the speaker and draw out more information is crucial to constructive dialogue.

More is easier than less.

Anyone can add to the document, but there are no commenting features and a social reluctance to delete what someone else has written. The effect is that assertions are qualified rather than challenged or deleted, meaning that you end up saying in thirty words what you could have said in ten. The compound effect of this writing style is that you layer meaning on top of meaning to the point that — as Julia Kristeva might have pointed out — as a group you’ve said something different to the individual’s original point. That’s not collaboration.

You get more than you need.

I couldn’t quite figure out what we got from the Wave that we couldn’t get from just a Google document combined with chat or a similar tool. It was less the case of the glass being half full or half empty than the glass being twice as big as we needed. There were too many features. Nearly everyone experienced serious browser issues — except Ian, whose virtual shoulder I was peering over— whose Chrome held out where Firefox faltered. Wave might run in a thin client, but it’s a fat piece of technology.

So was Wave a total washout? No, but I think it will take a lot of adapting to. If only there were some browser-based tool out there that wasn’t reliant on Ajax, that was near real-time but forced you to refresh so that you listened before you spoke and which encouraged you to be as brief as possible when you did speak up.

Where could we find a tool that met those requirements? I’ll have to ask the good people of Twitter.

Read more

Philippe Parker on | 26 October 2009 | Tweet this |

Contented Management

How to read Gartner

Gartner’s Magic Quadrant is stirring up emotions again. This time ZL Technologies have launched a law suit against the analyst firm, essentially claiming that its methods are biased and obscure. We’re not industry analysts, or partners of any of the vendors, so we’re not too bothered about who’s in Gartner’s good books. It makes a big difference to the vendors, however, since Gartner is such a dominant influence in the industry and so many clients assume that if a product’s in the Magic Quadrant, it must be the best.

And yet, this precisely contradicts Gartner’s own advice:

Gartner advises organizations against simply selecting vendors that appear in the Leaders quadrant. All selections should be buyer-specific, and vendors from the Challengers, Niche Players or Visionaries quadrants could be better matches for your business goals and solution requirements.

But what clients and many consultants see is the graph, and this is what they decide on. We’ve worked with many of the WCM products assessed by Gartner and conducted many technology selections for clients. They want the best product, not a niche player.

But what do you want to do with your CMS? Don’t you want to achieve things that other people aren’t doing, within business structures that will be difficult to change, aimed at specific audiences? Isn’t that a niche? Then why wouldn’t you consider a niche product?

Just because a vendor has a more complete vision, doesn’t mean it offers all the features that niche products do. In fact, the completeness of vision is based on many other criteria, including market understanding and strategy, sales strategy, business model and geographic strategy. These are all important, but do they really have a bearing on your business requirements?

We’d rather come and ask you what you’re trying to achieve, point out the things that any CMS will do and some of your issues that only certain products are likely to solve well. We’ll suggest you look at those but warn you about some of their weak points. If you’re then concerned that the vendor’s marketing strategy isn’t up to scratch, go and take a look at their financial viability. But every vendor Gartner assessed had WCM revenues in excess of $8 million in 2008,  so they aren’t small fry.

Nevertheless, you have to question the neutrality of a firm that takes a significant proportion of its revenue from advising the vendors on product development, but doesn’t disclose what that revenue is. As a buyer, you should question whether the criteria are relevant and whether the assessments are fair.

So what benefit can you get from the report?

Firstly, you get a list of products. That’s not a trite observation. In a market with several hundred vendors — and seemingly more each day popping out of the Scandinavian CMS womb — it’s useful to be able to limit the products you’re considering to those that have a considerable industry presence. Gartner will shortly be adding open source WCM to the proprietary software it currently evaluates.

Secondly, you get some ammunition with which to question vendors. If EPiServer is heavily focussed on expanding into the US market, you should be asking how much of their core team is still in Europe and able to deal with your concerns. (This is true of many of the European vendors.) Similarly, if you read between the lines on cautions about Vignette, you’ll need to ask how many of their clients are actually using the latest version of their product which they’re so keen to sell you.

So how should you read Gartner? With interest, and with caution.

Some further reading:

Philippe Parker on , , | 22 October 2009 | Tweet this |

Contented Management

Why do projects cost so much?

Why do Enterprise Content Management systems cost about five times as much as their top-tier web content management equivalents? Do they offer five times as much functionality? Are they five times less likely to fail? Are they significantly more usable? Generally, not.

But the operational savings that can be achieved with ECM are significantly greater than those typically made by rolling out WCM: there are time savings in information retrieval, cost savings in storage and reduced risk of compliance failure. You would expect these savings to be worth a great deal to most large organisations. Consequently, vendors can sell licences and services at a far higher cost than WCM.

Greater web content management costs can be justified in environments where devolved authorship, strong version control and compliance with web publishing standards are all required. This means that vendors can sell product licences at £200,000 knowing that what they offer can’t be achieved simply by installing WordPress. Commercial open source follows the same approach, but with pricing focussed on support and services.

It’s basic economics, but it’s worth recalling when you feel the costs of your implementation are running out of control. Products and services cost so much because clients tell suppliers that’s what they’re worth. It’s not up to your supplier to calculate your ROI; it’s up to the person paying the bill to do that.

The buyer sets a budget based on the benefits the project will bring, or the cost of not doing the project. Suppliers try to provide a solution that will bring about the benefits within the budget constraints. Together, they set up governance to ensure that the project doesn’t overrun or overspend, so that the business case remains viable.

The goal is not to deliver your project as cheaply as possible. It is to deliver the project in line with the specified business case. If you can save money then great, but if you’ve achieved your objectives, don’t worry that you might have been able to do it cheaper. Just bask in the contentment of having completed a successful project, an achievement that eludes so many.

See also Peter Sejersen’s article on whether you should reveal your budget when inviting tenders.

Philippe Parker on 20 August 2009 | Tweet this |

Contented Management

Thoughts on the CMS debate

Last week I attended the Future of Web Content Management Debate hosted by Squiz at Australia House. I met many interesting people and saw a range of presentations from analysts, customers and software vendors. I’m not sure that the future of the WCM was really debated that much, but perhaps the acquisition of enterprise search engine Funnelback by Squiz tells us that content management may well be rendered obsolete by improved information retrieval technologies… The debate instead seemed to focus on the advantages of open source content management software, as you might expect given that Squiz is an open source CMS vendor.

But why should open source even be a consideration when selecting a CMS? Increasingly we see drives by government and other organisations to promote open source, but as Adriaan Bloem points out, the only generalisation you can really make about open source software is legal: the licence. So unless being able to get into the nuts and bolts of the application and feeding back into its source are important to you, then open source shouldn’t really matter.

What should matter, and is often confused with the open source requirement, is:

  • cost: initial licences, project costs and on-going support;
  • who’ll carry out the development and support: an external supplier or an in-house team;
  • relationship with your suppliers and how easy it is to change them if something goes wrong without throwing away your technology;
  • upgrade path: ensuring you don’t over-customise your application so that you can’t move off it once it has outlived its usefulness.

Certainly, open source has a strong case to make with many of these issues, but fundamentally choosing the right CMS is about matching business requirements and budget to a technology and supplier, not about licence models. Hopefully the one-sheet guide we just published will help you in this respect.

Many thanks to Squiz for organising the debate and in particular to Kenton Ward, who was very open about his company and its development approach. Kenton also organises the Last Thursday group who meet in Shoreditch on the last Thursday of each month to discuss content management. Do join us!

Philippe Parker on 7 July 2009 | Tweet this |

Contented Management

A one-sheet guide to picking a CMS

I’ve been trying to consolidate my thoughts on content management technology selection (a large number of which are collated on this site) into something more digestible.

So I’ve come up with this one-sheet guide to picking a CMS (rich text format, 41KB).

The guide is based on reading the many excellent posts on this subject from across the web (you can find a few of these on del.icio.us), discussions with colleagues and my own experiences in tweaking this process on client projects over the years.

Of course, reducing the process to a single page does mean that some of the finer points about how you achieve these tasks can’t be captured fully, but the key purpose is that people who haven’t been through a CMS selection before understand the main tasks involved and the order in which they should be undertaken. The document should also assist those of us who help clients select a CMS to focus on the most significant issues.

It’s not meant to be definitive, so please do let me know your comments: twitter’s the best place to do this. I’ll happily update this page and the document as required.

Philippe Parker on 6 July 2009 | Tweet this |

Contented Management

CMS trade-in deals

Fatwire is waiving licence fees for clients who migrate to its CMS from Vignette or Interwoven. Both these vendors have traditionally had quite expensive licensing models so there are potentially big savings to be made, although FatWire has a feature set that is probably closer to Vignette than to Interwoven.

The catch is that you need to procure migration services through FatWire, but they’ve partnered with content migration specialists who you’d probably use anyway. You just lose some flexibility on negotiating the price, but you’re going to be saving money anyway.

But does that make it a worthwhile exercise? As Irina Guseva points out, the project inevitably costs more than the licence, so the cost of migrating may well be more than your existing Vignette or Interwoven maintenance costs.

More importantly, the reasons for migrating are wrong. You shouldn’t abandon your CMS just because you can get a better deal elsewhere. It’s not like switching an electricity supplier to get a better rate. Just moving from one CMS platform to another is unlikely to resolve the content management issues you’ve been experiencing. You need to think about which problems you’re going to solve then pick the processes and technologies that will address these.

FatWire’s rescue package doesn’t make a business case to move away from Vignette or Interwoven, but it does put the product on the shortlist if you are migrating. For dynamic-driven Java websites, you have to consider FatWire, but it’s not a shorlist of one. Remember, open source products don’t have licence costs either.

So let’s commend FatWire for their marketing effort, and if you’re looking to migrate from a platform other that those mentioned, ask FatWire if they’ll cut you the same deal. But don’t trade in your existing CMS just to get a better price. Address your issues, conduct due diligence and pick a product that meets your requirements.

A couple of useful links:

Philippe Parker on , , | 16 June 2009 | Tweet this |

Contented Management

People or software?

There’s a seemingly never-ending debate as to whether you choose your web content management software first or the team to deliver it. I’ve passed some comment on this myself in the past. It really comes down to Strategy 101. Are you looking to improve productivity or growth?

If you’re trying to improve your website’s revenue streams the software will offer you little. There are of course CMS out there that are sold by integrated marketing campaigners, and there are other CMS that offer strong personalisation capabilities. But fundamentally, it’s the concept and the design that will make your website better, not the underlying technology.

That’s not to say that you won’t make your life more difficult by picking the wrong tool; if you need to deliver personalised content with a CMS that only offers static delivery, for example. But if it takes you 20 minutes longer to produce the right content for your audience and deliver better advocacy and revenue, that’s a hindrance you may well choose to accept.

Nevertheless, CMS are fundamentally about improving editorial processes and governance. So if you’re trying to improve your content classification, link with other systems (like your LDAP directory) or make devolved authorship of your website easier, you must find the right tool to do this. If you pick the wrong product, you will be in for a world of painful customisations that will damage your operations in the longer term.

Of course, projects rarely have a single objective that’s exclusively sales or operations focussed. There is usually a weighting one way or the other, however.

  1. If the operational side is more important, look at the software first.
  2. If the marketing side is more important, go to an agency and ask them to recommend the CMS.
  3. If you’re trying to do both, let the agencies and vendors decide who they want to partner with in order to deliver your requirements.

More on technology selection:

Philippe Parker on 18 May 2009 | Tweet this |

Contented Management

My CMS vendor just got acquired; should I panic?

It’s all the rage for the CMS community; OpenText is acquiring Vignette.

What does this mean for clients of the two companies?

RedDot has been the web content management offering from OpenText for the last few years. It’s a pretty basic tool compared to Vignette, but this has distinct advantages: friendly user interface, quicker to implement, generally cheaper to develop basic functionality. I expect that RedDot will continue to be sold, but that there will be minimal product development. It will probably serve as a cheaper basic WCM in the same way as Alterian market Immediacy as a cheaper alternative to Morello.

The big challenge for the new company will be how to consolidate and exploit LiveLink and Vignette’s core content management offering, VCM. The offering that OpenText should be providing is end-to-end content management from documents and business process to web, but it’s going to be a substantial task to provide this through two pieces of software that are so established. LiveLink does the trick with documents and VCM does it with complex web content. But this certainly doesn’t mean that the two fit together neatly.

A significant benefit for OpenText is the acquisition of Vignette portal (VAP). This will enable OpenText to market web applications rather than just content-driven websites. Again, there will probably have to be some significant work done on the API level to LiveLink to turn this into a fully SOA-enabled platform. Nevertheless, if you’re doing business via the web — and surely everyone is these days — then a portal offering is a necessity for any enterprise content management vendor.

OpenText will be able to offer a product suite to match any of its competitors. But it will be a suite, not an integrated platform. Indeed the company has a poor track record in integrating its product suite: Gauss and ObTree anyone? Even RedDot stands pretty much alone from LiveLink. Oracle, despite its many acquisitions, has a far smoother integration of document and web content management, as does Interwoven.

So what does this mean for you if you’re about to buy? You still need to be wary of LiveLink’s web credentials; this is unlikely to improve for some time as the company attempts to make the various products work together smoothly. And if you’re about to buy RedDot, bargain hard, because I think the prices are likely to come down.

A few other thoughts on the acquisition:

Philippe Parker on , , , | 7 May 2009 | Tweet this |

Contented Management

Setting standards

CMS vendors are under constant pressure to improve their products. They add features their competitors lack (or that are perceived as lacking in their own product), provide what they hope will be prettier and more intuitive administration interfaces and increasingly integrate with other applications.

Increasingly we see vendors trying to make their products meet industry-defined standards. This could be CMIS, ECM maturity, or feature tables that are readily comparable.

But how do these standards help you as a buyer or end-user of the CMS? A multi-lingual installation package or a product rated as highly mature do not guarantee a successful solution to your content management requirements. I applaud the vendors who are trying to improve the technology, but I don’t think the analysts and architects would be doing their clients a good service by telling them that these standards somehow make the products better.

As a client selecting or supporting your content management software, you need to think about the tasks that are most critical (e.g. must run on my infrastructure) and most frequent. If your CMS is easy to install but you can’t tell when content you’ve published will go live, you have a really serious problem. If your workflow requirements can’t be met, it doesn’t matter if the content sits in a JCR-compliant repository.

You need to focus on your own day-to-day needs, not on the industry telling you what a great product it offers. Set your own standards and be sceptical about other people’s.

Philippe Parker on | 31 March 2009 | Tweet this |

Contented Management

Shortlisting your CMS

Having asked yourself what problems your content management system should address, you reach the stage in the selection exercise where you can shortlist some products. This does NOT mean going to Gartner, Butler or Forrester and picking whatever’s in the magic quadrant. That is a recipe for expensive mistakes.

There will be a lot of software on the market that can help to overcome your problems. You can whittle these down by placing other constraints on your selection process.

Due diligence: have you involved the right people?

Your project will need buy-in from various stakeholders. If you haven’t got their buy-in by the time you shortlist products, you’ll be facing all kinds of political issues even if you pick exactly the right tool. But you need input from all the relevant parties. What benefit do you get from excluding people in communications or marketing, hands-on content editors, technical support and development (whether these are in-house or a trusted service provider), the people in charge of your IT strategy, and of course, procurement. Not only do all these parties have a stake in the selection process; they’ll be able to contribute something constructive too.

How long will you keep the technology for?

Clearly your shouldn’t be looking to keep the technology for longer than the duration of your web or content strategy. If you’re planning to keep something for longer than you know what you’re going to do with it, you’ll probably get into a mess. So, if you have a clear strategy, you’ll want a product with a roadmap to match. If you’re just trying to satisfy short-term goals, you’ll probably want something that’s easy to deploy rather than highly extensible. Having an awareness of how long you’ll want to keep the software for will also help to inform your business case.

Do you really need just a single content management system?

Firstly, you need to understand the limitations of a CMS; it won’t do everything you need. You may need an additional search engine, it won’t satisfy eCommerce requirements, it probably won’t allow much in the way of personalisation, forms created in it will be pretty limited, it’s unlikely to stream live audio or video… these are all best served by distinct applications (which can mean a difficult integration project). So manage your stakeholders’ expectations and constrain your project objectives.

Now consider whether a single CMS is right for your organisations. Are different departments contributing to the CMS likely to need to share content or code? Or could they each have their own devolved system with a common interface for delivery, such as a portal? Will there be licencing or training cost benefits from a having a single CMS?

Work out your budget

Figure out what you can afford, then build your business case. As a rule of thumb, in order to get something workable and fully tested, you’ll need to spend upwards of 75% of your budget on services as opposed to software and database licences. This is likely to cross a whole range of software off your long-list right away.

Baseline your technology

Why does your CMS need to be Java or .Net? Is this your existing in-house skill set? If not, do you really want to invest in re-training? If you have no in-house team, do you really care what technology the CMS is built in? Shouldn’t it just be the cheapest available? Java and .Net are useful if you know you’re going to have a number of integration exercises with applications in those technologies. Otherwise your technological prerequisites may be a costly red herring.

Invite both software vendors and integration partners together

Encourage all participants to do pitch together. In my experience, no web CMS vendor has sufficient in-house experience to address all the services issues in a web project: information architecture, interface design, even systems integration. Conversely, the only services companies you’ll find who know a product inside out will be those who have ex-employees from the vendor. And even then, these developers won’t know the product roadmap or the best practice that the software supplier has gleaned from its many clients over the years. Get them together and have a happy menage-à-trois.

You now have your requirements and your constraints. You should be in a better positioni to shortlist suppliers. If you don’t know where to start in drawing up this list, you can contact us.

Philippe Parker on 12 December 2008 | Tweet this |

Contented Management

Questions to ask before selecting a web content management system

This is a brain dump of open questions that I’ve asked previously when speaking to clients about their websites and their requirements for a content management system. This assumes that the technical prerequisites are being addressed elsewhere.

You can pix and mix these questions as you feel are appropriate to your context, but generally it takes about an hour to get through these with one or two people at a time. If you need to run larger workshops, I don’t think this approach would work.

Vision and Objectives

  • Is there a content strategy?
  • What goals are currently being met?
  • How do you want to interact with your customers?
  • How much integration is required with other systems?
  • Which services should be provided through the website?
  • What is “the Vision” from your team’s perspective?

Suppliers

  • Who is creating / editing content? With what frequency?
  • Who plans content?
  • Where / what is the content you are responsible for and how is it used?
  • Who do you work with during the content creation process? How effective are these relationships?
  • How do you collect information to write your content?
  • Do you usually know about other initiatives in the organisation and how they affect what you’re working on?
  • Do other departments see the documents you produce? Do you see theirs?
  • How do you handle authors working on content that may be published simultaneously to different parts of the site? (i.e. ensure content is the same when it needs to be and different when it needs to be).

Inputs

  • What are your current content creation processes? Which are effective / ineffective? Why?
  • What are the problems / frustrations you face in creating content?
  • What features would you like to see in an authoring, CMS or publishing tool?
  • How are documents created? Do you use or templates or style sheets?
  • What tools do you use in authoring? How effective are they?
  • What is the format of the content you create? What sources is it dependent on?
  • How do you add metadata?
  • Do you re-use content from elsewhere on the site?
  • How do you manage demand for content from customers?

Process

  • What do you do to control documents? Version / access controls?
  • How do you handle sign-off / review?
  • Who edits / transforms content?
  • How is it classified?
  • Who relates content across the site?
  • What workflow review is involved?
  • How will the content be reused / archived / reviewed?
  • What works well with the current process?
  • What are we trying to improve?
  • What sort of reporting is required?

Outputs

  • What format does the content need to be in? (Accessibility levels, email, print / DTP, mobile, .CSV)
  • Where is it stored / distributed / aggregated?
  • What templates are required?
  • How much content should be reusable?
  • What extra site functionality are you interested in seeing?
  • How much Interaction or interoperability is required with other sites (e.g. client extranets)?
  • What requirements do you have for searching?

Customers

  • Who do you consider your target audience?
  • How much interaction do you have with customers (feedback, surveys, consultations)?
  • Is there a need for personalised / targeted outputs?
  • What are your customers’ key areas of interest?
  • Do you have access to website statistics? How do you respond to these?
  • What attracts customers to the store?
  • What information on the site helps your customers get their job done?
  • What types of information do they look for in a document?
  • How much information do they find useful?
  • When do they use the content (on one-off projects or on a recurring basis?)
  • What do they like best about the content? What do you like least?
  • How do your customers prefer to receive information?
Philippe Parker on 2 December 2008 | Tweet this |

Contented Management

One hand knowing what the other is doing

I have no idea whether left-brain vs. right-brain theories have any physiological grounding. Nevertheless, the concept that some people are more guided by intuitive feelings and others by rational judgement appears to be commonly-held.

These contradictory temperaments can be seen in departmental cultures when deploying content management software.

On the one hand, IT departments consider CMS to be applications that need to be fully-documented robust applications that conform to all kinds of architectural principles. Since the software will never meet all these standards, they have to be built by internally until some kind of compliant behemoth is unleashed.

On the other hand, the communications team expects the CMS to simply do everything out of the box using basic intuition. After all, Word is used to create and publish content, so why shouldn’t a web CMS do the same?

Of course suppliers are striving for a happy medium, where applications are robust and extendable but have a great deal of functionality off-the-shelf. But I think there are simple and important messages to communicate to both parties:

Even Word doesn’t provide you with the tools you need right away. More experienced users need to create templates that are on brand and conform to your processes. In the case of CMS, this needs a trained developer.

Most CMS are not designed to be heavily customisable applications. They’re meant to perform a simple function: enable the right people to publish the right content to the right places in a timely fashion. If you need to do more than this, then a CMS is one piece in the jigsaw puzzle, rather than being a piece of software that you can extend by yourself.

The message is to keep it simple. Pick the technology that meets a technical basis defined by IT, but only go to the absolute essentials (e.g. Java or .Net or LAMP, XML / web services, static or dynamic, LDAP compliant). This gives you a shortlist of products which the communications team then gets to choose from, focussing on all the features you get out of the box.

And if you’re tempted to tinker with the final product choice, don’t. You’ll be in for a world of pain when it comes to upgrade or roll out to other parts of the business.

The right CMS for your business is one where there are no quibbles over who owns it. If you let just one side of the brain choose, you’ll never satisfy the other.

Philippe Parker on 29 October 2008 | Tweet this |

Contented Management

Missing the SharePoint

Let me firstly qualify this post by saying that I’m not inherently anti-Microsoft. I don’t use a Mac, I do use Microsoft Windows (even the mobile version) and Office and I’m using the beta version of Office Live Workspaces. But I just can’t fathom why people choose to use SharePoint.

As a pure document repository it is mostly harmless. It follows Microsoft security models so will only show users documents from file systems and folders they should have access to. Unless you’ve been unbelievably rigorous and consistent in your file naming and metadata conventions, however, its search will be utterly useless. Just search a MOSS intranet for “agenda” if you don’t believe me. The search is also hampered by some strange behaviour when looking at external systems with case sensitive URLs, so try before you buy. No wonder Microsoft have bought Fast.

There are some nice collaboration features: user homepages, instant messaging; but these are bound up in inaccessible HTML. So are the Web Parts, Microsoft’s equivalent of Java-based portlets. This is also true of many Java portals which are heavily dependent on JavaScript functionality and HTML table layouts.

There is a big difference between SharePoint and other portals, however. Java portal technology is built to the JSR standards, notably JSR168. This means that you can take pre-developed portlets and simply expose them through your portal. You can even send these to other portals through WSRP. But not with SharePoint. It doesn’t comply with Java Content Repository standards, so you’ll struggle to put develop a service oriented architecture around it. If you needed a single point of entry for web services that you can develop in .Net, you’d have to look at BEA’s AquaLogic, not SharePoint.

So what is SharePoint for? It doesn’t fit into a service oriented architecture, uses security models from file servers, doesn’t do federated search well and isn’t built to open standards. Do you really want to put that sort of technology at the hub of your organisation?

You can try out SharePoint through the Microsoft Online Customer Portal, although you’ll need a Windows Live ID.

Philippe Parker on , , | 25 March 2008 | Tweet this |

Contented Management

More enterprise myths

It’s true to say that enterprise is a loaded word: it means a lot more to some than to others. We have enterprise content management (ECM), enterprise search, enterprise portals, enterprise resource planning… People like Nicholas Carr have been railing against these all-encompassing applications for years now, questioning how applications that cost so much to install and configure can deliver tangible business benefit, particularly compared to smaller, more targeted systems. The Gilbane Group on the other hand dislike the term enterprise because they believe it’s pure marketing spiel, particularly in the case of content management where few vendors offer the full range of content management products.

It is of course possible to go to a single supplier and get the full WCM, DM, RM, DAM, JCR and IDM gamut of acronyms. The leaders are IBM and Oracle, but Day, Vignette and Open Text all have products covering the main functionality. You have to take care of course that just because the products are owned by the same company and are labelled as a single product family, this does not mean that they can actually talk to each other. Many is the client persuaded to implement a product portfolio from off the shelf, only to spend months and hundreds of thousands on systems integration.

Leaving aside the truth that vendors relate and the more palpable realities their clients are faced with, ask yourself this: why would you need an enterprise application for content management anyway?

Enterprise means not simply across your whole organisation but unique to your organisation. Your ECM will be different to someone else’s, with different security privileges, workflow, storage and retrieval requirements.

Except it’s not.

What you’re trying to do in your organisation is being attempted in every other organisation of a similar scale or vertical. All your competitors, all your partners, all your suppliers and clients will need to control their information and distribute it to the right people. And they want to do it in similar ways, which is why all these vendors are able to sell their content management technologies to so many clients. The thing is, if your requirements aren’t unique, do you need a system that’s unique?

Of course you don’t.

People like Andrew McAfee and JP Rangaswami have been using and writing about disruptive technologies for years. Technologies like wikis, blogs and tagging are disruptive because they upset standard business models and processes where you procure a single technology and then tell everyone how to use it. Under the disruptive model, you let people use a set of tools the way they find most productive. You can add anything to a wiki without it going through workflow, you use blogs instead of email, you use tags instead of a taxonomy. Depending on where you look, these technologies have been more or less successful.

But for me the issue is that it’s not blogs and wikis that are disruptive, it’s the enterprise technologies themselves. Why do organisations feel the need to procure these tools that few people know how to implement and even fewer know how to use? Why not just pick a few technologies that are out there already? The procurement and implementation of these systems actually disrupts the things your organisation is good at, often having a greater negative impact than the business benefits the system will eventually entail. Yes, an enterprise system gives you one butt to kick, but you still have to do some butt-kicking.
For example, why set up a massive LDAP directory that a bunch of systems administrators need to maintain, when you can use OpenID? If you used this to authenticate people, they can use the same username and password for their social life as their daily business. Isn’t this simpler for everyone? Why set up project team servers? Just let each project team set up a blogger account with a new blog for each project and restrict who can view it. They can use the same email address for their email, calendar, and even documents. And those documents could be shared as a wiki. Some of these technologies will work better than others, and there are of course security implications.

Your organisation does not need to control technology, it needs to exploit it. So before you procure a new CMS ask yourself:

  • Am I trying to do something that is already being done by some of my staff using existing tools?
  • Why can’t I extend those tools to support my business?
  • Do I really want to manage a new supplier, a new project and on-going support?

Isn’t it easier to view web technologies as a facility your enterprise makes use of, like roads or a rail system? Let your employees make their own way to work, don’t go out and buy a bus to round them all up in.

Philippe Parker on , , , , | 20 March 2008 | Tweet this |

Contented Management

4 steps to the right CMS

The main reason for choosing a new technology is to reap its benefits. But the processes that organisations follow can obscure these benefits rather than unearth what’s feasible. So let me add a few points that may help to steer you in a direction where you can get the most from a new CMS selection exercise.

1. Accept that different technologies will make a difference
Your organisation has to understand that different technologies will provide different benefits. There will inevitably be people who tell you that it’s just technology and which one you choose won’t make that much difference; they all perform the same basic function after all.

There is an element of truth in this argument, but there are some very significant differences between WCM software and their suppliers, notably:

  • financial stability, product maturity and the number of service partners in your geography;
  • delivery mechanisms (static or dynamic) and product scalability;
  • integration capabilities and an open API;
  • user management, persistence and personalisation options;
  • classification management;
  • community and marketing features;

2. You will need a spreadsheet
Technology selection is not about scoring matrices, with coefficients for requirements and complex calculations. However, if you are going to satisfy the finance director you will need to prove that the technology you’ve selected does meet the requirements set out in the business case. Moreover, you will certainly need a check-list of technical prerequisites that any software should adhere to in order to make a shortlist. Don’t forget to tell the vendors which email clients your editors will be using and which operating systems and versions of Office their tool should integrate with.

3. You will need scenarios
No matter how command-and-control the culture within your organisation, if you enforce a technology that’s meant to be devolved to lots of users — particularly if they’re in multiple locations— that is difficult to use, you will be in for a lot of trouble. You’ll have to expect increased training and support costs as well as brooding resentment about the new technology. People will find workarounds to the very processes you were looking to instill.

Engage the people who are actually going to use the CMS and get them to help you to articulate the main issues they have with managing publishing content. Then invite the vendors to demonstrate these tasks to this audience. A few key points on these demonstrations:

  • Don’t tell the vendors how you want things to work. Explain the problem and ask them to demonstrate a solution.
  • Create scenarios for the tasks you perform the most frequently. If you only create a new workflow once every six months, the fact that you can do this in Visio is pretty irrelevant. Concentrate on content creation, review and relationships.
  • Think about how the content is managed rather than its delivery. In the end, any product can be made to generate accessible HTML, provide streaming media and publish printer-friendly views. Concentrate on short and long documents, content sharing and classification and take a hard look at the authoring interfaces which your teams will be using every day.

4. Allow the vendors to impress you
Always give the vendors twenty minutes to show them what else their product can do that you haven’t asked for. It’s the opportunity for the sales team to show off why the product inspires them and to show you why you want to work with their product rather than someone else’s. A content management system is not only supposed to enforce your editorial processes; it should inform them too. If you’ve been struggling with a technology for a number of years it may be hard for you to see what’s possible, but some new product feature may resolve a problem that you previously thought intractable.

Take a look at what the product has to offer and see if you have any business problems now that the tool can resolve that may have been out of scope. Don’t get hung up on features for their own sake, but if the product rings a bell and the sales team have done their job, you’ll be well on the way to picking the right piece of software.

Philippe Parker on 2 January 2008 | Tweet this |

Contented Management

You speak the language, we do the grammar

When I was at university, I was one of a somewhat rare group who enjoyed structuralist critical theory. In a nutshell, this states that since all literature is made up of components of grammar (phonemes, adjectives, syntax, etc.) you can describe any text according to this grammar. At its most basic a narrative is state X → event Y → state Z which is different to state X.

Perhaps this is why content management appeals to me. There’s a set of paradigms (content types) that can be described through adjectives (metadata). There are verbs (workflow) and syntax (navigation), and content can be represented in different declensions (templates). But what the content management system is expressing is different each time. The content is the language, while the CMS is the grammar.

So an FAQ has similar composition whether it’s aimed at specialist user communities or the general public; a press release has the same structure whether it’s displayed in English or in French; content can have different “skins” depending on the person viewing the page. When implementing your content, I really don’t care what the content contains, just how people are going to produce and consume it.

A key point to remember about grammar however is that it evolves. Common usage changes the rules. How many supermarkets state “10 items or less” rather than the correct “10 items or fewer”? And how many people know the difference?

So you have to be aware that your requirements will change and the grammatical model for your CMS may need to evolve. If you pick a model with more complex content management processes — component-based systems like Tridion or Percussion say — you may find your users struggling initially. But if you pick simple page-based tools like EpiServer, your contributors may not be able to express themselves in the way they want, such as creating more complex content relationships.

So when picking a CMS technology, you need to think about the complexity of your content management tasks, the processes and structure you’ll want to exploit. Does the system speak your language? Try a few phrases and see. Get the suppliers to show you how you would achieve key tasks around content creation, publication and relationships and pick the language that isn’t double-Dutch.

Philippe Parker on , , | 19 December 2007 | Tweet this |

Contented Management

Is it “what” or “how” that broke it?

A typical question I get asked when assessing failing CMS implementations is whether there’s a fundamental flaw in the product or in the way it’s been implemented. Some products are more difficult to implement than others, but businesses can be hasty in wanting to throw technology away when the implementation has failed to meet expectations.

While you can make any product do anything if you have an endless supply of time, money and ingenuity, it’s useful to have some idea about whether you need to throw your core product away to achieve your goals feasibly. So I thought I’d list a few typical warning signs that might prompt you to initiate a technology selection project:

  • Wrong technology stack — You’d have thought this would be obvious; but if you’re living in a Java world and you have a .Net, ColdFusion or LAMP product, you’re in trouble. This also applies to legacy systems coming out of support.
  • Unfriendly URLs — You could get around this with some clever rewrite rules, but it’s extremely tricky to do this in a really scalable and cost-effective way.
  • Incompatible workflow — If your CMS doesn’t allow you to implement your online publishing processes, you have a serious problem. Integrating a distinct workflow tool could be more trouble than it’s worth.
  • Running Active X components on a Mac — This is a way to alienate your user base. Don’t use anything that relies on Active X. Even if you’ve locked down all your editors’ PCs to use the same version of Windows, these components can be a headache. There’s plenty of tools out there that use cross-platform, browser-based technologies, so why give yourself this burden?
  • Auto-generated non-compliant mark-up — Many portals (including MOSS Sharepoint) provide you with default templates into which your content is published. Trouble is, they rely on HTML table layouts and JavaScript that are a long way off best practice for being well-formed and accessible. If this is important to you, it can take a lot of effort to fix. You have to weigh up this level of effort against the advantages the product gives you, or against simply throwing the tool away.
  • Poor security — A requirement that’s more obvious to some organisations than others. Some CMS (dynamic-delivery products tend to be more susceptible than those using static delivery methods) are prone to brute force attacks, so if you could be vulnerable to DDoS you should get this evaluated. You should also ensure that your product doesn’t suffer from SQL injections.
  • Lack of integration standards — If your CMS doesn’t work with your LDAP directory, you’re in for a world of pain…
  • Poor version comparison — As with workflow, does the CMS provide you with versioning and audit capabilities that match your business processes? If not, there are tools you can integrate with no little effort, but why wouldn’t you just pick a CMS that does all the red-lining and version comparison for you?

This isn’t an exhaustive list. What characterises these issues is that while you could address them with some outside-the-box thinking, the problem is likely to be so ingrained in the product that dumping your current technology is a more viable approach. And at that stage, when you look to select a new technology, all the points listed above should be the technical prerequisites you have when inviting suppliers to tender. During the selection process, you can then concentrate on organisational fit. This is a subject I’ll return to later.

But what if the reason your implementation is struggling isn’t listed above? It could well be down to the implementation. Most common things people blame on the product, but are actually a problem with how the product has been implemented are:

  • Performance — Hardly ever down to the product, in my experience. Can almost always be improved, if not completely solved, by improving infrastructure (not necessarily more licences) and information architecture.
  • Unfriendly WYSIWYG editorial interface — There are lots of free or cheap tools out on the market which provide friendly and standards-based ways for editors to add rich content to your CMS.
  • Poor classification systems — Products have limitations about implementing taxonomies and classification systems, but typically if you’ve trouble managing these in enterprise products, it’s more likely to be because of how you chose to do it rather than a fundamental flaw with the product itself. It may well require some bespoke work, but doesn’t mean abandoning your entire system.
  • Having to publish in multiple places to generate a single piece of content — This problem is more often found with component-based content management systems, such as Tridion and Percussion. Editors have to publish blocks of related content that then go through independent workflow processes only to be assembled on the same page. There’s an advantage that these are re-used elsewhere on the site, or translated into other languages more efficiently, but the big disadvantage is that editors are confused by what needs to be published in order to make one simple update. In my experience, the business blames the technology when it’s just down to how it’s been put together.

Hopefully this will steer you down the right path when you need to decide whose arse to kick: software supplier or systems integrator / design agency. But more than that, it should give you an idea about where to focus your energy for new requirements: do you need to run a technology selection project or can you build on the platform you have currently? We all know that things break, but if you know whether it’s the what or the how that’ll do it, you should be able to put some contingency in place, saving some blushes and some money.

Philippe Parker on , , | 16 October 2007 | Tweet this |

Contented Management

Ajax: hero or zero?

As yet another vendor introduces AJAX to their WCM offering, it’s worth considering what benefits these interfaces bring you. Last year, Jonathan Downes and Joe Walker at CMS Watch provided a great introduction to the subject of Ajax in content management systems, but there are a couple of other points you should consider.

Firstly, in the last year or so, users have become much more familiar with these kinds of interfaces. Most webmail systems make use of the tool and there are countless portal-type sites and map applications that use JavaScript to create smoother browser-based interfaces. This should mean that people will be more comfortable with richer interfaces than with simple web forms.

Secondly, Downes and Walker tell us that Ajax generally equates to better performance. While the interface may give the end-user an impression of efficiency, this isn’t necessarily the case for the server. Remember that with each interaction, you’re sending a request — albeit small — to the server. Given that most CMS licences run on a per CPU basis and many environments have as a consequence been under-specified, introducing these tiny rapid requests could put some serious strain on your hardware and your budget.

These interfaces can be more user-friendly than some client software, but as with any CMS selection process you just need to be wary, size your environment appropriately and test with real editorial users to see if they get the desired usability benefits. It’s pretty safe to say that the smaller the number of users, the more benefit and least risk in deploying these kinds of tools.

A final word of caution: in the Iliad, Ajax was certainly mighty. But he was passed over by his peers for a hero with more guile and ended up destroying himself. Is this the sort of technology you want to unleash in your CMS campaign?

Philippe Parker on , , , | 14 October 2007 | Tweet this |

Contented Management

The mirror stage in content management

If you’re considering whether your organisation needs collaborative software or a CMS to fulfil its content management needs, you’re doubtless being confronted by a bewildering range of products that all seem to provide the tools to meet your requirements. So how do you decide if you need a wiki, a portal, or ECM?

It’s down to psychology, not technology.

Psychologist asks PC: So tell me about your relationship with your father.

Let’s refer to the Mirror Stage, a psychoanalytical concept developed by Jacques Lacan during the 1940s. The concept describes how infants imagine themselves to be at one with a mother who satisfies their every need. When a child cries, its mother will feed it, change it, put it to bed, or comfort it. When a child reaches between six and eighteen months old, it starts to realise that its identity is separate to its mother’s. It recognises itself in a mirror, has to learn to feed itself and will be told off by its father. In short, it enters a symbolic order where it now has to conform to social constraints in order to get what it wants. The early imaginary state provides gratification without context, while the symbolic order provides context but imposes boundaries.

Which psychological order do your contributors belong to? Do you want or provide an environment for them to express themselves freely, or do you need to contextualise them and the content they produce?

Collaborative tools assume a shared identity. Just as an infant considers its mother to be an extension of itself that responds to its every whim, users look to collaborative software as a personal tool that instantly fulfils their need for self-expression. In this imaginary order, contributors “write out their question in their blog and look for their community to respond and help them“. Compare this to a content management system, where you have both context and boundaries: contributors recognise that their content can only be published if it meets predetermined social criteria.

Some examples:

  • Folskonomy vs. Taxonomy: The most obvious difference between imaginary and symbolic orders in content classification. In folksonomy, users enter terms that help them understand their content and they imagine that other users understand these terms. In taxonomy, these terms are given a context and only predefined terms can be used according to a preordained structure.
  • Intranets: Is your intranet an environment for generating knowledge or enshrining it? If your staff use it to discover what’s going on across multiple locations and projects, they assume that content is representative of the work they do. If the intranet holds authoritative information that employees want to refer to (for example, HR policy), you need a tool that confirms their place in the organisation and that reasserts social context.
  • Web 2.0 vs. Web 1.0 sites: People who use social networking sites subconsciously assume that what is valid for them is valid for others: that their tags make sense, that their ratings (of YouTube videos for example) are relevant, that people will follow their myspace page. These assumptions may well be right, but context is limited to these assumptions. If I put a photo of Sophie onto Flickr and tag it accordingly, this tells me that there are other photos of people called Sophie on the site, but doesn’t tell me that it’s Sophie Marceau and I’m interested in pictures of French film actresses. It’s not clear of course that this is the information people are looking for, but a content managed system would presume this in its design. So if you go to a report on a football match on the BBC news website, it will provide links to more news about each club involved, league tables, fixtures, weather forecasts for that area and so on. The contributor doesn’t elect to have all this correlated information: the CMS provides the context automatically and imposes an authoritative order.

Of course, collaborative environments aren’t completely without context: any user who logs into the system has a distinct identity within the organisation. But the mirror stage in content management comes when you start to impose structure and workflow. If you need your contributors to put content in a specific place for easier retrieval, or to have their contributions approved before they’re viewed by a wider audience, then you’re imposing a symbolic order.

So when choosing your approach, ask yourself are you a mother or father to your users? Are you coaxing them, encouraging them to express themselves freely, or are you imposing a paternalistic authority?

If your organisation is essentially the same thing as your contributors, then an unstructured wiki is a viable option. This covers social networking sites, or collaborative research intranets. But if your organisation represents something more than the people it comprises, in line with a Gestalt psychology, then you need a content management system that enforces a shared identity rather than assumes it.

Philippe Parker on | 4 October 2007 | Tweet this |

Contented Management

Enterprise too? ECM’s long tail

Over the years, the content management market has seen a great deal of consolidation through acquisition, creating vendors with more extensive product ranges that they tout as enterprise almost by default. If you have web, document, digital asset and records management then you must be enterprise.

There are a number of problems with this consolidation that are well-documented, notably the maturity of product integration; just because you buy Oracle UCM (Stellent) doesn’t mean it works out of the box with Oracle WebCenter. But there’s another issue too: not all the clients are enterprise. Once you’ve sold your massive projects into big corporate clients, how do you tap into the long tail?

Increasingly we’re seeing the larger vendors buy up smaller companies not just to become more enterprise, but to reach a broader market that can’t afford enterprise licence fees. We see this in SDL’s acquisition of Tridion, very much a mid-tier WCM. It’s also been in evidence with the RedDot / Open Text product offering, with the RedDot WCM being able to offer trendier features aimed a less “enterprise” installations, such as User Generated Content plug-ins.

Perhaps the most obvious example of this non-enterprise approach is Mediasurface. Even though Mediasurface is a WCM rather than ECM offering, it has many clients who would struggle to pay for the core product licence, Morello client, database licence, and Solaris servers. Yet it has many small clients who it does well from, particularly in UK local government. To increase its stake in this market, Mediasurface has acquired both Immediacy and the SilverBullet hosted CMS offering, rebranded as Pepperio. This enables the company to dip more easily into the long tail.

So why is this important for you, the customer?

On the positive side, it means that if you’re a small customer you can still get a product from an established vendor rather than a high-risk niche supplier. If you’re a large customer, it enables the vendor to leverage the features of the products in its portfolio to provide you with a more comprehensive system, potentially in a more agile way.

On the negative side, if you do go for a small product from one of these companies, you have to ensure that you don’t turn yourself into a small fish in a big pond. If you go for a small WCM package and you need something quick, you’re more likely to get it when you represent 10% of the supplier’s revenue than if you represent less than 1%. And if you are the big fish, don’t expect the small pond to be anything other than a set of nearly joined up puddles.

Philippe Parker on , , , | 3 October 2007 | Tweet this |