Contented Management laughing buddha logo

Contented Management

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

What should be in a WCM SWOT?

The first step in any brownfield implementation is to assess what you have already. Indeed, you should be assessing your web content management on a regular basis, particularly if your online business is seasonal. But what are the ground rules for that assessment and what should it cover? I’d recommend a rapid SWOT-check.

SWOT analysis is a long-standing if relatively simple technique used across many types of business to provide the executive with a summary of the current situation. It should be easy to read and quick to determine, rather than involve weeks of assessment and long reports. It should be a couple of pages document or four slides that highlight the most salient issues. You can find some templates on Business Balls.

The contents of your SWOT should cover all the facets of WCM: commercials, technical, design, operational.

Strengths and Weaknesses

  • Does your WCM meet performance and availability expectations?
  • Is the site W3C compliant and accessible?
  • Does it meet usability criteria for both consumers and contributors?
  • Does the content meet quality expectations for target audiences?
  • Are you able to track key performance indicators? What are they telling you?
  • Are the business objectives for the WCM in tandem with organisational objectives and strategy?
  • If so, are these objectives represented in the site’s look, feel and functionality?
  • What extra functionality are your competitors offering? What advantages does this give them?

Opportunities and Threats

Porter’s five forces for competitive advantage provide us with a good baseline for assessing opportunities and threats. In WCM terms, these translate as follows:

  • Potential entrants: Are you considering all the delivery channels: syndication, mobile, widgets, etc.
  • Buyers: Which markets could you expand into? What are your audience expectations as they begin to consume other web technologies (Facebook, Youtube, iGoogle)?
  • Substitutes: Do collaborative tools like blogs and wikis threaten your content management processes? If you have a large Enterprise Content Management platform, is this challenged by Software As A Service, or by Basic Content Services?
  • Suppliers: How dependent is the system on a single supplier, whether internal or external? What contingencies do you have in place should you lose this resource? If you’re going to make enhancements, what sort of training or procurement implications would this have?
  • How do I exploit all the content which might be relevant to my audiences? How do I make the information I’m presenting be cohesive and comprehensive?

Who should make the assessment?

Lots of questions, but who should answer them? You need someone sufficiently distanced from the site as it stands that they won’t simply rubber-stamp the current situation or rubbish it completely. But the person (or people) undertaking the SWOT also needs to be engaged with the site and its users.

So you need to engage an independent expert who then runs a brainstorm with stakeholders around the bullet points listed above, but who you give sufficient licence to that they can be completely honest about your implementation. You’re asking someone to take a sword to the site not to themselves, so expect to hear things that you’d really rather not have known.
Why is this approach useful

Too many times, project teams are given a brief that’s just an abstract assortment of ideas. A SWOT analysis provides a structured way of getting to the root of the problem. As I said at the start, this is just the first step. Steps two and three are about identifying requirements that tackle the issues the SWOT raises and prioritising those requirements so that you can figure out what’s worth changing. I’ll tackle these two steps in subsequent postings.

Philippe Parker on 15 November 2007