Contented Management laughing buddha logo

Contented Management

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

Contented Management

Is my project management useful?

Delivery has been uppermost in my mind recently. My wife is expecting a second child but this one decided he doesn’t want to head in the right direction. Next week he’ll be “from his mother’s womb untimely ripp’d”. Consequently I’ve been thinking heavily both about caesarean delivery and about a number of projects which now share a common delivery date. If I were project managing this birth, I’d just be cajoling the baby to get into position but quite frankly wouldn’t be offering much value. Is this the same for web projects? Do project managers actually help and how can you get more out of them?

According to Douglas Adams’ Hitchhikers Guide to the Galaxy, the population of planet Earth was formed by a spaceship full of middle managers, hairdressers, marketeers and account executives. It’s easy to lump project managers into this mix. When Ford Prefect complains about this group’s inability to get stuff done — “This is futile! 573 committee meetings, and you haven’t even discovered fire yet!” — you can be sure that a project manager was there, maintaining the rolling action item log.

This is often exacerbated by project methodologies that foster a generic culture of project management, where all project management problems are essentially the same and if you can fix the issues around business case, stakeholders, executive sponsorship and resources you’re well on the way to project failure prevention. I’ve no doubt that these rules do apply for all projects, but I wonder that if you have a culture of just focussing on these issues you simply encourage project management by numbers where you get unthinking, standardised responses. As usual, Scot Adams got there first:

Case 1: Dogbert the generic manager: Ted - We need more people on the project. Case 2: Dogbert - Figure it out. Work smarter not harder. Make a plan. Move some things around. Adjust priorities. Just get it done. Give me a status report. Case 3: Ted - That did nothing but make me hate you. Dogbert - I can replace you with someone who will pretend to be inspired.

Even where you have a good project manger trying to help, it’s usually soft skills. Plant any management consultant in there and there’ll come up with the same answers without really having to get to grips with the fundamental issues. Why is the project struggling? Let’s not call lack of sponsorship a root cause when it’s just a symptom.

Sponsors are reluctant when they don’t understand project goals. You can see this for nearly any social media project. The business case is difficult to prove, the executive don’t buy into social media as reducing costs or increasing revenue, and the rigid formulae of business case definition help no one. This isn’t a sponsorship failure where the project manager can go in and mitigate against lack of funding. It’s fundamentally about whether an organisation is culturally ready to adopt social media and understand how they might use it. The project manager can facilitate this debate, but really you need a subject matter expert rather than a journalist who has read a couple of reports from the big analyst firms.

Jerry Manas recently wrote an article in which he suggests that project managers who run agile projects bring a completely different style to the table that’s much more concrete than traditional approaches. While I don’t agree with the entirety of his article, I think the main hypothesis is right. If you can get project managers who are close to the stakeholders, intimate with the issues and prove that they’re not just some glorified secretary, they can bring real value. Specialist projects require specialist experience and expertise and the world (of IT in particular) is littered with projects that have been delivered to industry best practice, but to abject failure.

The better generic project managers will continue to mitigate against failure and they’ll deliver their projects. But it the end, you’ll be judged on what you’ve delivered, not how you delivered it, and that’s where domain knowledge is essential.

My son will be just as precious to me whether he comes via forceps or scalpel. But it’s the people with the hard skills, not the soft skills, whom I’ll to put my faith in to ensure that he gets delivered safely.

Further reading

A recent presentation I made to the J. Boye community of practice on speeding up project delivery using techniques from Scrum and Prince2.

Philippe Parker on | 8 March 2010

Contented Management

Does rationlalisation reduce cost?

It’s a fair assumption to make that some organisations haven’t procured their content management systems as effectively as they might have done. Poor procurement is particularly frustrating when it’s done with our money, i.e. by government. But government in the UK is steeling itself for a major cost-cutting exercise. The Transformational Government agenda is already well underway, seeking to reduce the number of government websites and streamline online services. Meanwhile the political parties have competing missions to rethink procurement, particularly of technology. You can’t argue with the idea, and as Ian Truscott points out, there are good reasons for reducing the number of websites from a user experience perspective as well as just costs. However, you can certainly question the approach.

Let’s say you try to consolidate to a single content management system. The smaller the user base for that CMS, the more likely you are to meet its requirements. As soon as you extend the CMS to multiple teams with different ways of working, different audiences and different kinds of content, you have a change management programme on your hands. The focus has shifted from where it should be, online engagement, to training existing users in new ways of working.

Over-rationalisation tends to lead to over-generalisation, and that in turn leads to a poor fit to requirements. If you generalise too much, you’ll necessarily have to introduce customisation to your system, which was precisely what you were trying to avoid in the first place.

This isn’t the only area where too much rationalisation fails to reduce costs. While preferred supplier lists brings down the cost of procurement, they’re unlikely to reduce the cost of implementation. Qualification to be a preferred supplier is strenuous, but once you’re on the list there’s very little incentive to control your prices. Preferred supplier lists can make procurement inflexible and frustrating for the business users too. New entrants to the market are seldom present, so it’s nearly impossible for government departments to be early adopters. This makes government look like it’s off-message, when in reality many civil servants are swimming against the tide to provide a good service.

What government and many other large procuring organisations end up with is a possibly cheaper but probably riskier solution: over-ambitious projects that take too long to implement and that can’t meet emerging requirements. The larger the project, the more changes to requirements will emerge and the less rational it will become. These kind of strategic rationalisations are doomed to failure. To paraphrase John Maynard Keynes, your project’s business case can stay irrational longer than your project can stay solvent.

Rationalising your web presence is a great aspiration to have, but your have to rein in your ambitions. Rationalise a feature, not the whole system, then you’re more likely to see some cost savings.

Philippe Parker on | 19 October 2009

Contented Management

Theatrical ways to improve project performance

I wish I could remember who wrote that in tragic theatre events start quickly but slow down as they draw to their inevitable conclusion, while in comedy the action start slowly then build up pace. There are definitely parallels with projects.

It’s tragic when you have one of those projects which seemed like a great idea at the time, but the longer the it goes on, the less enthused people become and everyone despairs of achieving success. Managing these is not a cathartic experience: it’s a time to pity the stakeholders and fear for the project benefits.

On the other hand there are laughable projects where you took so long to define requirements that your implementation and testing are squeezed into an impossibly short period. These would be funnier if wasn’t for the fact that as a stakeholder, you’re the one being mocked.

So how do you avoid plunging into despair or feeling ridiculous? Here are three theatrical tips:

1. Get adequate direction
Your governance structures are there for a reason. Use them. If you think the project is going off track, then engage with the project board and escalate issues for them to make a decision on. Stick to the script and resist the temptation to ad lib.

2. Engage with the whole audience
If only some of your stakeholders know what’s going on, your project will be in big trouble. Project reporting needs to be broadcast, not sent to individuals. Set up a project repository where anyone can read reports and documentation, ideally with RSS feeds, and let any stakeholder subscribe. That way everyone can engage with the project and show appreciation, or displeasure.

3. Use actions, not just words
The performance of your project won’t be measured by how much you talked it up. Take on the role assigned to you, step up to the front of the stage and perform as best you can.

Finally, remember that acting and project management are both about empathising with people’s emotions without succumbing to them yourself. If your project’s going badly, you should be able to understand why your stakeholders are upset without getting upset yourself.

Philippe Parker on 27 August 2009

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

Contented Management

Three little tips to reduce huff and puff

My two-year-old son is pleased to live in a house made of bricks. It affords him protection from the Big Bad Wolf.

But what the books don’t tell you is that while piglets 1 and 2 were sheltered by their less than robust housing, piglet 3 faced rocketing costs, toil, tears and the emergent threat of swine flu.

In the seldom-told sequel, pigs 1 and 2 are forced to vacate the house that was designed for one small piglet rather than three growing hogs. They lack the skill and resources to build their own brick houses and end up destitute and living in fear of Tom the piper’s son.

As an architect, piglet 3’s end vision is certainly the right one — or would be if he foresees having to accommodate his two brothers. But in order to fulfil that vision you need the skills, resources and time.

If you’ve an immediate problem finding the right shelter for your content, then long-term strategic planning for a robust future vision is likely to be the wrong approach. You need to find a quick way to protect your resources, assess the situation then plan your next step. You’re unlikely to face a fatal threat – it’ll just be lupine bluster – and even less likely to have enough time and money to mitigate against the problem anyway. Start building, see if it works and, if it doesn’t, tear it down again. Being able to manage even a small amount of your content in a robust way is better than just having a visionary strategy.

Those three tips:

  1. Choose two high-value objectives; one that should be simple to achieve and the other likely to be complicated.
  2. Select a technology to deliver these objectives that is in your existing skill set and technology stack. Only buy licences required to meet the project objectives.
  3. Implement the project as quickly as possible and evaluate the success or otherwise six months later.

ECM doesn’t have to be a swine to implement. As long as you don’t try to go the whole hog from the start you’ll avoid making a pig’s ear of the project and be sure to bring home the bacon. It’s a ham-fisted analogy, but it’s no fairy tale.

Further reading on the failings of web strategy:

  1. Anthony Bradley – Your Web Site Strategy is Destined to Fail
  2. Dennis D. McDonald – How to avoid common strategic planning mistakes
  3. Maish Nichani – Mapping your website redesign strategy
  4. Gerry McGovern – Web redesign is bad strategy
Philippe Parker on | 15 May 2009

Contented Management

Basics of organising web content

There are a bewildering array of resources available on information architecture, user experience and interface design, so I just wanted to make a very quick post on how to approach the organisation of your web content.

  1. Identify key user types (personas)
  2. Identify key tasks they need to undertake (user journeys)
  3. Develop navigation to enable journeys (site maps)
  4. Develop user interface that will enable users to complete journeys (wire-frames)

Main advantages of doing things this way:

  • You’re not trying to fit in existing content unless it’s actually useful to your users.
  • You can identify content that’s missing easily.

There are more useful IA definitions at iaonesheeters.com

Philippe Parker on , , | 11 December 2008

Contented Management

Lao Tzu, on agile development

Taoism tells us that it is practically impossible to understand the world fully. Everything we describe falls short of what it actually is, since our language is limited. We naturally want to see things as complete, but everything is part of a wider whole that we are incapable of relating accurately and completely.

The way to understand the world is through continual contemplation. We actually begin to understand by comprehending what we have not yet understood.
A waterfall approach to gathering requirements would therefore be anathema to a Taoist. How can you say a requirement is complete without understanding how it will be met, or indeed what it will look like once its complete, or if the requirement was correct to start off with?

Requirements, design and implementation are part of the same whole: what the project will deliver. Instead of engaging in a futile activity to capture every requirement before you move on to designing how you’ll meet them, you need to engage the whole team in assessing what a requirement really looks like tangibly in the target system. That means discovering the requirement, prototyping and reviewing through a series of iterations, until the feature meets its objectives. These are the principles of agile development.

The subtlety of individual requirements is almost impossible to capture in a strict, documented fashion. If you want to see your requirements met, rather than your project brief adhered too, a more contemplative and iterative approach is necessary.

More on China and WCM to follow.

Philippe Parker on | 21 August 2008

Contented Management

Content management lessons from China: Sun Tzu

China is in fashion. The Olympics, with its spectacular opening ceremony, has brought the Middle Kingdom and its culture to the fore. So we’re going to hop on the bandwagon by looking at some of the better-known examples of Chinese thought and consider how they might influence on web content management (WCM).

Sun Tzu, on effective management

The Art of War was a favourite text for the Reagan-ite wannabe executive who viewed business as a perpetual battle. Yet effective management is rarely about deceiving others and taking control over their realm, despite what some departmental managers may think. Indeed, Sun Tzu stresses the need for delegation as a means to enjoying more control. Management is about delivering an end product.

There are five main obstacles to success:

  1. recklessness: consider what impact your decisions will have before you enforce them;
  2. cowardice: don’t be afraid to implement what you know is right;
  3. hasty temper: don’t be provoked into arguments with stakeholders or suppliers;
  4. delicacy of honor: you don’t need to appear all-knowing; recognise your weaknesses, be open about them and engage people to help;
  5. over-solicitude for the team: people will be unhappy during the project, but if they see that what you’re doing is right, they’ll buy into the cause.

Successful implementations are about pursuing a common objective without having to appease people along the way. So delegate responsibility to your implementation team and ensure that they enforce your decisions for you.

More on China and WCM to follow.

Philippe Parker on | 18 August 2008

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
Older Posts »