Contented Management laughing buddha logo

Contented Management

Contented Management

When should technology lead requirements?

How do you develop your content management requirements?

Typically, organisations will identify a business strategy, develop requirements based on that strategy to improve revenue or reduce costs, and then develop a software architecture based on those requirements. But when should the technology drive business change?

The simplest answer is “never”: don’t let the technology tail wag the business dog. But the simplest answer is rarely right. New technologies can lead to competitive advantage as well as stimulate innovation culture, so there should be room for a technology-led approach. You do need to establish some criteria for initiating these kinds of projects, however.

Emergent benefits but a defined problem
You may not know precisely what benefits the new technology will bring — this is particularly true of very new technologies that have little case history of ROI — but that shouldn’t in itself preclude assigning the project a budget. What should prevent you starting the project is not having a problem. This might be an operational issue such as ineffective project communications, or the opportunity to target a new market segment. But the problem needs to be there even if it’s not clear how the new technology will resolve it.

For example, online retailers have long had an issue with customer trust. People don’t buy products just because the website says it’s worth buying. But if you add the facility to comment on or rate a product, this gives some reassurance to the buyer. It improves sales markedly for some items, but risks reducing them for products that receive poor reviews. While it’s not 100% clear what effect customer ratings will have on your revenue stream, they do address the perceived trustworthiness of the product description.

If you want an example where this hasn’t worked, consider Second Life. Eighteen months ago, virtual worlds were the bandwagon to be on. It wasn’t clear what the benefits would be but it was technologically cool. The problem was that there was no problem. Second Life didn’t offer any real communication improvements while tapping a relatively small market that could be reached through other channels anyway. There may well be scope for virtual worlds in future, but they need to address a real business issue before they’ll take off.

Ability to deploy quickly
Since the rate of obsolescence outpaces the rate at which companies change [slideshare], you’d better be quick about your work. If it takes you a year to roll out a new technology, this should be business-driven, not led by a technology which will be old hat by the time it’s deployed. Software as a service gives companies a real advantage to deploy quickly, as do flexible server environments. You should certainly be looking at these kind of tools if yours is an organisation that likes to be at the leading edge.

Acceptable cost
How much money are you willing to risk if the technology doesn’t bring any benefit? This is a difficult assessment to make as you’re less likely to have a watertight figures than if you went down the more traditional business case route. Normally your assessment would be: my problem costs me £X, so if I spend £Y then I’ll get a return within Z months, so £Y can be my project budget. When you’re technology-led, you’re unlikely to know how long it will take to get a return. So you need to treat your budget as a sunk cost that you’re comfortable writing off.

This doesn’t necessarily mean that your budget must be small: the car industry spends a fortune on innovation because the risks of losing competitive advantage are so huge. Of course, you can limit your risk of failure by running a pilot, which will help you to satisfy the need to deploy quickly as well as constrain costs. Your project budget should be based on the scale of the problem you’re trying to solve, rather than on the scale of anticipated benefits.

Exit strategy
If the technology isn’t as successful as you’d hoped, or it’s viable but creates other problems you hadn’t forseen, you need a cost effective way to abandon it. This is particularly relevant for information management projects. If you put business critical information into a new wiki that has poor adoption, you absolutely need a way of getting that information back in a format that can be migrated to another system. Your project needs to include a decommissioning approach.

Ride the wave
Technology should inform your business strategy, but being at the crest of the hype cycle isn’t enough. If you apply these criteria to technology-driven projects however, you should go some way to avoiding the trough of disillusionment, both emotionally and financially.

Philippe Parker on 29 September 2009

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

Contented Management

How to get better CMS support

Janus Boye recently proposed that you cancel your maintenance contracts in order to save money. But before you think of this as a great money-spinner, there are a number of key issues you must consider.

  • Many maintenance contracts are tied into the licence agreement; cancel your maintenance and you lose the right to use the software. In this case, the vendor may not sue you, but how honest would you be in denying the company its cash?
  • If something goes seriously wrong with the core product — you discover a security flaw or an issue with the schema — then how do you fix it? Third parties will be extremely reluctant to fix this and any changes to the core product are likely to make re-entering support (when upgrading, for example) extremely complex. We’re talking low likelihood, high impact risks. The question is, do you want to tolerate these or transfer them to someone else?
  • A good relationship with the vendor is still preferable to a poor one. If you take all money and services away, what incentive do they have to provide you with a good service? The analogy shouldn’t be about not paying your insurance premium; it should be about having to return to work with the person you had a regretful fling with at the office Christmas party…

So what can you do to improve your CMS support?

  1. Educate yourself: have procedures to handle common issues (restarting the servers, clearing the cache, etc.). Train internal staff to deal with these and provide procedures to out-of-hours support teams, be they internal or at your hosting company. This will cater for the vast majority of issues that don’t need any further investigation.
  2. Get to the root of the problem. Are you unhappy with your software (or implementation), or simply with your supplier’s responsiveness. If there’s something fundamentally wrong with the product, you should be selecting a new one. If the issue is service or cost then renegotiate the SLA, don’t throw it out.
  3. Find someone who’ll support you better. If the software vendor cannot demonstrate their ability to meet your service level requirements, then ask them to recommend someone who will.
  4. Negotiate your licences so that you get what you pay for. The help desk should be like any additional module that you’d have to purchase with the product. Why should you pay for something you don’t use?

Yes, there’s a downturn and you’re under pressure to save money. But you’re probably under more pressure to ensure that projects and services continue to be delivered. Why would you jeopardize these for the sake of a line item already in next year’s budget?

Focus on developing a good relationship with your supplier and you should find the quality of their service improves too.

Philippe Parker on 15 January 2009

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

Contented Management

Fear and loathing in requirements

We’ve previously mentioned that the fear of being left behind often motivates web strategy, even though this just leads to mediocre web presence. Why does this happen? It’s because our heads are ruled by fear, as this Newsweek article points out. As a consequence we make poor choices, trying to come up with functionality-driven requirements rather than finding the problem we’re trying to solve.

A typical example is to implement folksonomies for relatively small websites. Folksonomy (or social tagging) works for large sites with an engaged readership. The sheer volume of tags and people tagging supports rather than counteracts other classification systems. But this simply won’t work if your editors are adding more content than your audience is actively classifying.

Similarly, you may look at other websites with rich media and think that’s what’s driving visitors to their site, when the opposite may be true. Just look at what happened when The Register introduced video reviews for an audience that browses the site while at work.

These kinds of implementations are often driven by the fear of being left behind, losing audience and revenue. Many organisations feel they should be on Web “version 2.0″ by now, irrespective of whether they can articulate what that functionality is or what purpose it will solve. So how do you fight the fear? You need to set out some clear business-driven objectives for the web.

These objectives are common across practically every organisation: increase market share, reduce costs, reinforce brand, improve communication with customers and so forth. Every system requirement that you specify will need to meet one of these objectives. If a requirement is completely off the wall, then it’s either not relevant for the organisation or the organisation needs to reassess its objectives. When you record your requirements, these should be mapped to an objective and validated by the body responsible for meeting the objective: the marketing team, customer relations, IT, etc.

Once you’ve recorded all your requirements, you can develop functional solutions for each one. Again, the relationships between requirement and functionality should be tracked, so when you come to decide about functionality that will be in project scope, you have a clear idea why you’re implementing any given feature. You’ll then be able to ensure that requirements are driving functionality, rather than the other way around.

Diagram showing the relationship between strategy, objectives, requirements and functionality.

Just as your organisational objectives will corroborate your organisational strategy, so the requirements you document will inform the technical strategy you adopt. Do your requirements suggest the need for a web content management system, or an enterprise version to manage documents, or federated search, or wiki tools? You should be able to design a technical strategy once you have an overview of the requirements. This strategy will also inform the functionality you specify to meet the requirements. If your strategy dictates project teams should collaborate using blogs, this should be consistent across your web presence; you shouldn’t end up with a mix of blogs, Word documents and forums. If you can achieve this level of consistency, your technical and organisational strategies will be appropriately aligned.

So stave off your fear of being left behind technologically. Being at the technological bleeding edge will bring you little reward, as Get Strategic points out. Focus instead about meeting your business goals and ensuring that your technology is being designed with these in mind. Didn’t you want business 2.0 rather than web 2.0?

Philippe Parker on 18 January 2008

Contented Management

Building up to great websites

I’ve been reading Jim CollinsGood to Great and it’s a thought-provoking study, based on mountains of empirical research. It discusses what Collins calls the physics of how good companies become great companies, significantly out-performing their competitors. But it’s striking that a number of the key attributes of companies that make the leap from good to great can also be applied to websites and to WCM in particular. In this post I’ll focus on what Collins calls buildup, before moving onto breakthrough.

Level 5 leadership
Collins found that all the top-performing companies he analysed were led by people who combined personal humility with professional willpower. It’s easy to extend these characteristics to websites, where a major barrier to success is vanity. If the website is your “baby” or reflects the parochial concerns of your departmental or organisational structures, it will never be a great website.

While sponsors and stakeholders empire build, or focus too much on the website and not enough on the web as Gerry McGovern points out, you cannot achieve your potential. The message should not be “when I was in my last job, I did it this way”. The message should be “we need to improve, we need to stop doing things badly”. This is a matter of professional integrity and resolve, not a way to boost egos.

First who… then what
If you recognise that you don’t have the skills or time to do everything yourself, you’ll also see the need to be supported by a good team of editorial, information design, creative, technical and project management people. You just need to get them on the bus. If they’re any good and have encountered similar problems before, you won’t need to set directions for them. They’ll see the need to improve and will be able to start advising you where the problems are.

For example, when Contented Management staff go into a project, we don’t expect to be told the big vision or what a project should look like. If you know that already, you don’t need us. You just need a bunch of body-shopping coders to implement the changes. You bring us on board because we sign up to helping you the best way we know how.

So don’t decide where the bus is going before the right people are on board. A strong team can set a common vision; whoever came up with the idea in the first place is immaterial. If the idea is right, everyone should buy into it and pursue it relentlessly, just wanting to be a part of a website they can be proud of having helped to develop.

Confront the brutal facts
Above all, the common vision needs above all to be well-informed. There’s absolutely no point in speculation. Collins talks about the importance of a climate where the truth is heard.

Many people just want to know what’s convenient: that your WCM is a great platform for managing content, that it’s robust and performs well, that the users love it, that the websites it generates are standards compliant, that your projects follow best practice methodologies, and so forth. The reality may be quite different, but how do you find out?

Collins proposes four ways to get to the truth:

  1. Lead with questions, not answers.
    Hopefully previous posts on requirements will give you some indication of what you should be asking, but I think an important point here is that people won’t simply accept the truth just because you tell them it’s staring them in the face. Site owners may tell you that they have high bounce rates, where visitors come to a single page and then leave again, because they’ve found all the information they need on that one page. But is that really what’s required? What about cross-selling opportunities, or more complete views of the information, or suggested further reading? Do none of your visitors want those things?
  2. Engage in dialogue and debate, not coercion.
    Just because there are standards out there, doesn’t mean you have to use them. A CMS can compel editors to display their content in certain formats, but there’s not much point if the editorial team doesn’t buy into it. Discuss how your audiences consume your content now and how you want them to consume it in future. If you choose to standardise, do so because your stakeholders agree with the obvious benefits. But give yourselves some leeway, so that stakeholders can have a non-standard feature if they can prove its business case.
  3. Conduct autopsies, without blame.
    Undoubtedly one of the toughest things to do is to figure out why something went wrong. I’ve had assessments carried out on the projects I’ve run, and I’ve had to run many reviews of failed projects that someone else has been responsible for. But how many projects ever run smoothly?
    You need to accept that things are going to go wrong and that a collective effort is required to put them right again. We prosper and suffer together. If a person makes a mistake, someone else should be there to support them.
    This brings us back to leadership style. Fixing problems is a matter of professional integrity, not of ego-bashing. And if the right people are on the bus, they should be looking out for each other.
  4. Build “red flag” mechanisms.
    Being able to confront the brutal facts depends on having the facts in the first place. I’m going to talk about Key Performance Indicators at a later date, but you need to know when something is going wrong as soon as possible. This could be lack of site traffic, high drop-off rates, people preferring other information channels (such as print, or even call centres!), difficulties in estimating and planning enhancements, high costs… anything associated with running a website.
    One of the first tasks you’re going to have before you embark on real improvements to your web environment is to be able to determine just where things are going wrong, so you can either fix them or abandon that activity entirely.

As Collins repeatedly notes, great companies don’t focus principally on what to do, they focus equally on what not to do and what to stop doing. If you get this right, you’ll get the breakthrough, which I’m going to cover in the next post.

Philippe Parker on 30 November 2007

Contented Management

PICKing the fishbone

So, you have your SWOT and your fishbone, now you need to prioritise your requirements.

There are lots of ways of doing this, but I think you’ll have gathered from my previous posts that I’m always keen to do things the simplest way possible and refine things from there.

  1. Take all your requirements from the end points on your fishbone, and write them all down on post-it notes.
  2. Hold a couple of rapid, 15-minute sessions with business stakeholders and ask them to stick the requirements to a flipchart sheet, with the most important at the top and the least important at the bottom, so you end up with a kind of requirements priority ladder.
  3. Hold a follow-up session with the technical stakeholders who will need to deliver the project: designers, developers, project manager. Don’t tell them that the requirements are prioritised by importance (although they’ll probably guess). Just ask them to review the requirements and move them further to the right of your sheet depending on how time-consuming or difficult they are to achieve.
  4. Draw a 2 x 2 grid around the post-it notes. The 2 x 2 grid is a business analyst’s cliché, but also a friend. The vertical axis is benefit and the horizontal axis is difficulty. You’ll end up with a PICK chart, shown below.

Requirements charted against benefits and costs
You should just implement the requirements in the top left of the grid. They’ll bring value and are relatively easy to do, so they should be in your project scope right away. Conversely, those in the bottom right should be scrapped as their value is questionable and they’re hard to do, so the business case will never be proven.

Requirements in the bottom left grid should be challenged. Just because we can do them, doesn’t mean that we should. What real benefit will there be for the organisation if we implement them? Won’t they just divert our focus from our main project objectives?

We may well implement requirements in the top right of the grid, however. We know from the outset that their implementation will be difficult and costly, but if we can prove their benefit then we shouldn’t rule them out. These requirements may involve some prototyping and benchmarking, but shouldn’t be excluded just because they’re hard to do.
If there are lots of requirements in the Possible group, you can always repeat the exercise just for those requirements and include only those in the top left. You should also retain a record of those requirements that were in the Kill group, as in future there may be more value in doing them and they may be easier to implement with changes to work practices or evolving technologies.

The advantage of the approach articulated in this and the previous two posts is that it’s relatively quick and simple, while retaining a focus on real problems and how likely you are to be able to solve them. Obviously, there are more refined approaches than this, but if you just need to get things done, this approach is worth trying.

Philippe Parker on 22 November 2007

Contented Management

Fishing for requirements

Following on from my post about SWOT, how do you exploit this analysis to come up with the requirements you’ve identified with your web content management system? Here’s a rapid approach:

  1. Distribute your SWOT analysis to your stakeholders and set up workshops involving between three and five participants in each.
  2. You’ll need a large whiteboard. Each workshop shouldn’t need more than 30 minutes: 5 minutes to introduce the activity, 15 minutes to run it and 10 minutes to recap.
  3. Draw a horizontal line in the centre of the whiteboard. To the left of the line write a one or two-word phrase that describes the objective or result you’re trying to achieve: for example, “improved WCM”.
  4. Take the key areas identified as weaknesses, opportunities and threats and draw them as spokes coming off the horizontal line: e.g. content, performance, usability, competitor offerings.
  5. Now work with your participants to identify the subjects you need to tackle in order to address the issues identified in the SWOT. Ideas should follow on from the categories you’re suggesting: e.g. competitors are offering RSS feeds, email subscription, personalised news, etc. What else can you offer that your competitor doesn’t currently provide?
  6. The idea is to get as many ideas as possible around the themes you’ve identified. At this stage, it’s about quantity not quality. Keeping forking new lines off the themes as you go along, so eventually you end up with ideas that are four or five levels off the main horizontal line.

You’ll end up with something like this, although hopefully more detailed. Click on the image to view the full-size diagram.

Fishbone diagram showing idea stream
Since all the ideas have been made with reference to the original weaknesses, opportunities and threats, they should all be in line with real issues that your SWOT has identified.

You’ll get a feel for the level of detail as you go along, but try not to get too bogged down in any one area: keep the ideas moving along.

At the end of the exercise, you should end up with a skeleton of ideas that looks something like a fishbone. Draw a fish around it to make it look like one if that helps!

What the fishbone will help you do is to drive out requirements that you may not have considered previously. The higher-level ideas should stimulate the more granular issues and focus your stakeholders on the central issues identified in the SWOT, rather than simply bringing their own agenda to the table.

What the fish won’t tell you whether those requirements are feasible or valuable, so the next step we’ll look at is prioritisation.

Philippe Parker on 19 November 2007

Contented Management

Suitable content for a CMS

One of the biggest challenges for organisations with complex web architectures, particularly those trying to implement SOA, is deciding just what is appropriate for a content management system and what goes into AN Other application. Oscar Berg has had a stab, but I thought I’d try to give a few guidelines.

An indication that a project may be a good fit is if it meets any of these criteria:

  • Written (as opposed to numerical) content to be published within or outside the organisation and administered through a web browser.
  • Documents to be published internally or externally.
  • Digital assets used in conjunction with web or document publishing.
  • Information aggregated from other sources that subsequently needs to be edited by staff before it is published to an internal or external website.

An indication of a poor fit would be a project with the following requirements:

  • Structured numerical databases: this is more appropriate to a bespoke database application.
  • Draft, unpublished information that belongs to an individual, rather than to the organisation: this can be achieved with a file server.
  • Loose, collaboratively-created content, such as blogs, discussion forums and wikis, that don’t require peer review. This content is usually best managed through dedicated collaboration technologies.
  • Aggregated content that can be presented “live” on websites without editorial intervention. This can be achieved through a portal or an application server.
  • Integration of back-end applications to be presented through a common, browser-based interface. This can be achieved through a portal.
  • Archiving records to less expensive data allocations based on frequency of access or age of assets. This is a feature of a more advanced records management system.
  • eCommerce sites requiring automated cross-sell functionality.

There are some grey areas which might combine a CMS with another technology:

  • “Advanced” personalisation, where a website has to remember who you are while you’re on the website and deliver different content to you based on your profile. This is pretty straightforward in a CMS when applied to the homepage using cookies, but anything beyond this requirement is going to be complex to implement, particularly if your CMS is stateless.
  • Streaming media will require an additional dedicated server.
  • Single sign-on functionality would benefit from an identity management tool.
  • Web-based applications such as polls that need to be included on a website but are unlikely to be managed through the CMS.
Philippe Parker on 29 October 2007