Contented Management laughing buddha logo

Contented Management

Contented Management

Want to improve your project? Change its name

Street sign - Casa di Giulietta - covered in stickers and graffiti

Let me start by saying this is a purely anecdotal post. But what is lacks in statistical evidence it makes up for in my own eyewitness accounts of projects doomed to fail. I’m sure you’ll have seen this too.

Time and time again I’ve seen institutions running projects that will significanly affect their day-to-day business, but they clearly haven’t thought about what to call them. They’ve invested in governance processes, supporting tools, getting the right people involved, but not the name of the project.

What’s in a name? That which we call a rose
By any other name would smell as sweet.

Juliet knew nothing about project management. If she’d been better at planning she wouldn’t have been so star-crossed.

The name of the project is the thing that’s most readily communicated to the project team and stakeholders. It’s the daily reminder of the work that they’re doing and the benefits that they’re expecting. And yet the name we give a project typically detracts from its core values, with these examples as the most typical culprits:

The new technology

Why oh why have you called this project the “Social Media Marketing project”? Or the “CMS upgrade”? Or the “Intranet replacement”? What useful information could that possibly convey?

  1. Does everyone involved in the project – from the people who’ll use the system to those who have to approve its budget – actually understand what that technology’s supposed to do? Does it really give all the stakeholders a good idea of project scope?
  2. Why are you upgrading? Surely it’s not just so that you can say you’ve the latest version running… or is your organisation full of Apple fanbois? You upgrade because you’re missing key functionality, or because the existing system is underperforming, so at the very least call it a content strategy project which has an upgrade component to it.
  3. And if you’re replacing a system, you’re actually compounding those two issues: do people understand what you’re getting rid of and why, and aren’t you replacing it with something that does a lot more? So it’s not a replacement, it’s a new strategic platform which enables the business to function more effectively. You’re not just throwing a wad of cash at a technology supplier in order to end up with exactly what you had before.

Naming a project after the technology is missing the whole point about what technology is. It’s an enabler, not an end solution. If your organisation thinks that by updating its technology it will solve its problems, you know that you’ll never meet your business goals.

The website redesign

I’m at a loss as to know where to begin with website redesign projects. As with new technology projects, the redesign isn’t an end in itself unless it’s some pure vanity project. The redesign is about improving how your audience achieves its tasks and that usually necessitates people who create content finding new ways to manage it, as well as identification of business objectives, target markets, persona, user experience testing, information architecture and so forth.

But calling a project a website redesign masks an endemic issue. It sets the expectation that once the project is complete, they’ll be no more work to do. Website redesign isn’t a project. It doesn’t have a start and an end. It’s a process of continuous improvement where your web team analyses audience interactions, responds to them and adjusts the website to improve how your organisation communicates with its customers online. If you turn it into a project, you’re effectively saying that you’re not going to fix what you know to be wrong until the project goes live, and that when it goes live you just need to sit back and measure the benefits. That approach is anathema to everything the web stands for: innovation, engagement, simplicity.

Clearly there will always be website projects that need to be run as projects, not least because corporate governance requires it. But they’re not redesigns. They’re projects to improve user experience, or to update a corporate brand, or to plan out a content strategy. Redesigns are fails before you even pass Go.

The acronym or buzzword

Some project management offices think they’re cool. That’s the only explanation that I can find for organisations that give their projects codenames or buzzwords or acronyms.

And guess what: project management offices aren’t cool.

I’ve worked with at least three organisations that called a project Prism. What for? None of them were about optics. It’s just someone thought it was a good idea to call them something cryptic. I’m pretty sure one was an intranet, another was a finance system but I really can’t remember what the third was… document management, perhaps?

The only thing that I can commend about those projects is that they didn’t fally into one of the first two traps. But they didn’t address the issues either. What on earth is project Prism, or project Orange or project Stan all about? Is it something that’s deliberately meant to exclude the majority of employees? Because that’s what it looks like, and it’s hardly going to get stakeholder buy-in if that’s the case.

Buzzword projects are doomed because they isolate the people working on them from the rest of the organisation and – worse still – they give the impression that actually the people working on them don’t really know what the project is about. I’ve seen many a buzzword project (though not the prism ones) being strategic projects where the organisation felt it had to do something, but it wasn’t exactly clear what that something was, and didn’t want other people to know about it until they’d figured that out so they could deliver the right message.

But they’d already delivered the wrong message. That no matter how competent the project team, they simply didn’t have a clue.

Choosing the right name

So if you can’t name the project after its core technology and you can’t call it a redesign and you can’t call it something you thought was cool, what can you call it?

Call it something relevant.

I realise that’s a boring answer, but you know what, every project you ever work should have a business objective. Call it the project content strategy improvement or expenses streamlining or improving our brand reach.

The name of your project should make transparent to all the stakeholders why you’re doing the project in the first place and keep the team focussed on what it is that they’re meant to achieve. Just because developers have done their bit doesn’t mean that the project will be a success.

So if your project is failing and you’re looking for a quick turnaround that might improve it, try renaming it according to where the team needs to focus. You might just avoid tragedy and a plague o’ both your houses.

Philippe Parker on , | 17 February 2012 | 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

Crystal balls are there to be broken

Guy Westlake, a senior product marketing manager at Vignette, has gazed into his crystal ball for trends and technologies in 2009. This is certainly worth a read, as Vignette continue to have some excellent product features and are one of the driving forces in both WCM and portal software development.
Of course there’s an element here of Vignette promoting its own product set — a case of gazing at navels rather than crystal balls? — but I hope Guy won’t mind if that I contradict some of his predictions. I do agree with quite a few!

1. Enterprise 2.0 takes off

The use of web 2.0-style tools (micro-blogging, RSS, tagging, etc.) as part of daily communication within a business should be a no-brainer, but many organisational cultures are way behind the curve. Early adopters are reaping the rewards of improved knowledge sharing, but the ethos of control, hierarchy and compliance hamper efforts to implement Enterprise 2.0. How do you convince people who send email attachments to half a dozen people for approval that there’s a better way of communicating if they can’t see beyond their clogged up inboxes?
One compelling case for web 2.0 tools is their use in project management: posting on project status with comments for feedback, using shared calendars and discussion boards for meetings, building networks of friends across departmental and organisational boundaries. But if you’re used to out-of-the-box services, be prepared! Implementing these kind of tools within the firewall is often considerably more complex: LDAP integration is just the first hurdle you’re likely to face.

2. Life in the cloud

So many cloud-based applications offer real benefits at seemingly ever-falling costs that the cloud appears to be the saviour of the web, particularly when recession hangs over IT budgets. But security questions remain: how sure can you be that information you want to keep in your organisation remains there? Businesses will have to become a lot more savvy about encryption methods before they start to really take advantage of what the cloud has to offer.
Nevertheless, those applications that are external to the firewall — including email — are ripe for cloud computing and I expect we’ll see many organisations taking “a punt” on these services just from a cost perspective.

3. Web 2.0 in the financial services sector

This is a banking compliance officer’s worst nightmare: anyone posting all kinds of comments to a bank’s public website. However, financial services have been the trail-blazers for web 2.0 on internal applications and I think we’ll see them pushing these applications to the public too.
The question is: what is the killer app? Social comparison sites for mortgages, savings and the like similar to Trip Advisor in the holiday industry are bound to become more prominent. But retaill banking is going to have to think long and hard about applications that they can find for online social media to gain market penetration.

4. Personalisation and the rise of ‘My Web’

Personalisation has not been the trend for web content and I see no evidence that it will become one. Personalisation has proven many times to be both costly and ineffective. The trend has been and will continue to be “our web” rather than “mine”.

Even the oft-cited Amazon example isn’t enclosing the individual in their own world: it’s making recommendations based on what other people bought who bought the same product and there’s a heavy use of communal rating functionality. I expect we’ll see more in the way of sites suggesting links other people followed (even Google is moving this way) rather than offering visitors options to configure the kind of content they want to see.

5. The future of online media is video

This is a marketeer’s dream. Unfortunately, the market is willing but not yet ready. There are significant challenges in engaging users with video based on current browsing habits. If you’re online at work, watching video is still viewed as at best anti-social and at worst as skiving. Watching at home still isn’t the experience that it should be, sat a few inches away from a small monitor displaying an even smaller video. Video on mobile devices is improving significantly however, so if mobile bandwidth prices start to fall, expect to see a rise in video clips for handheld devices. What’s more, these devices are likely to be far less effective at blocking out this content than most PC browsers.

6. The integrated brand experience

There’s is a slightly chicken and egg situation going on with multi-channel delivery. Sites won’t develop for small audience shares and those audiences won’t visit sites that don’t cater for them. I expect that we’ll see a few niche players here — probably around news and software sites for mobile devices — before we see any real obvious example (in Europe, at least) of business catering for multiple channels.

7. Social media – what next?

Social media has been about individual sites allowing lots of people to comment and contribute. The next step (we’re already seeing on many sites including BBC news) is for the site themselves to be social and provide links to resources they don’t control. I think this is a really good thing. For too long, organisations have focussed on enclosing themselves in their own “enterprise” models rather than seeing themselves as part of the web. Now they’ll begin sharing content and resources with each other more freely in order to become the “hub” that visitors come to on a regular basis. It’s best to be the daily starting point for browsing rather than the infrequent end point.

8. Semantic Web

Has the semantic web lost all meaning? It’s pushed so heavily by vendors, but how many compelling examples are there of it? Some of the technology is exciting, but let’s see a compelling business proposition for it.

Tidying up your content, organising it better and making it more search-friendly are still more effective ways of improving your website or intranet than the implementation of a semantic engine.

If the crystal ball isn’t right, what is?

I’m not disagreeing out of hand with Guy (apart from on personalisation and possibly the semantic web), but if I disbelieve his predictions, what do my own tarot cards propose?

  1. There will be more opportunities to reach new audiences across multiple channels, but a correspondingly increased need to justify the costs of these new channels.
  2. Intranet projects will struggle for attention. Challenges and costs associated with application integration in comparison to a cloud-based model will cause many internal implementations to be delayed. The focus will turn instead to communication beyond the firewall for market penetration and retention.
  3. Websites will become social, sharing content not just from their own resources but from off-brand and off-message sites too, through the increased use of RSS.

Let’s review next year and see whether tarot is more effective than a crystal ball.

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

Contented Management

Mencius, on collaboration technology

Mencius asserted human nature is naturally good, but that it needs to be nurtured in order to flourish. Your organisation may well have naturally talented staff who are predisposed to helping it succeed, but if they’re not given the tools to do so then you will never make the most of their talent.

Wikis, forums and other collaboration technologies provide the tools for organisations to get the most out of their staff. For public websites, ratings features, comments and social bookmarking enable authors to see which aspects of their content attract positive interest.

If your website ignores its public’s needs, or your systems deny their users the opportunity to add their feedback, they’ll just go somewhere else. If you’re lucky. Mencius also advocated the just overthrow of despots and one of my favourite Chinese stories, Outlaws of the Marsh, also known as the Water Margin very much follows this code.

So the message is clear. You can learn from your audiences and stakeholders, inside or outside your organisation. Provide them with the tools that will enable them to enhance your systems, and you will flourish with them.

Philippe Parker on , | 22 August 2008 | Tweet this |

Contented Management

Devolution, or the origin of pages

You have the software, you have the infrastructure, you have the business process… now where’s the content?

All Creative Commons on flickr: monkey by babasteve, donkey by wollombi, beaver by laszlo-photo, bee by fotodawgThe knowledge chain
Content management depends on a technical knowledge chain rather like the food chain you see in the animal kingdom. The first link in the chain are your drones, doing the bulk of the content harvesting and compiling in your CMS. You then get the eager beavers in your editorial team who control the flow of the content by slowing its course and discarding anything that doesn’t serve the common purpose. There’s also a need for a great deal of donkey work: general tasks like administering users and braying at the drones and beavers who try to buck the system. Finally, you have the code monkeys, the tech geeks who seem to spend their entire time fooling about and gawping, but who still consider themselves primates because they can use a mouse with an opposable thumb.

The problem with this technical knowledge chain is that in many organisations, each layer is of an equal size. This means that there aren’t enough people contributing content and but too many people performing administrative functions, while the technology layer spends time fixing things rather than making enhancements. If you could delegate the simpler daily tasks further down the chain, reserving the few meaty tasks for the more technically skilled species higher up, you could ensure that only the fittest content survives to be published on your website. These CMS animals need to devolve.

The case for devolution
Devolution isn’t just a theory: it’s founded on solid evidence. Many organisations have thought in the past that by spending half a dozen days creating a CMS training programme they can then rest and everything will take care of itself. But the reality of your CMS world is a little different. Over time, the technical team will have adopted a position as alpha male. They dominate the environment to suit them, which means that it may be over-engineered and difficult to change. The authors and editors will have had comparatively little impact on the CMS world around them: they tend to be more dependent on the resources that their environment affords them.

Environmental impact
But if your CMS ecosystem is going to succeed, it needs these authors to break their symbiotic relationship with their super-users so that they can cross-pollinate content and allow the world to flourish. To achieve this, your CMS environment must evolve to meet its inhabitants’ requirements.

People with fewer technical skills outnumber each layer above: contributors, editors, administrators, technical.

The end result is a skills pyramid, where you invest the least effort in the people who contribute the most, because the resources are there for them to prosper. When your contributors are comfortable with the system, this makes it easier for the editorial team to assess content quality. They don’t need to focus on administrative tasks, but can refer these to a dedicated team of first-line support as required. And the technologists aren’t bugged by the mundane concerns of lesser species, but can get on with doing more important things instead.

Intelligent Design
Devolution is supported by intelligent design. Your CMS environment should be technically simple with transparent publishing models and familiar editorial interfaces. If you can focus on adapting the environment to help your users rather than training your users to fit with your software, then the technically meek but editorially able shall inherit the earth.

Philippe Parker on , | 17 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 |