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:

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.

I’ve recently been working on a number of web content management system selections. My preference is to carry these out in a two-stage process (see the one-sheet guide to selecting a WCM). The first stage pre-qualifies suppliers according to client attitudes to cost, risk and technological preferences. The second stage then gets into the real tasks that you want to perform, discovering how the WCM enforces and informs processes.

Like most other people in this business, I approach this from the point of view that there is no best WCM, just different products that may be viable for different kinds of tasks. It’s about finding a product that will allow you to get started as quickly as possible without precluding later ambitions. I try to show clients what a WCM could do for them, and in turn client aspirations suggest product features. These usually centre around a number of core areas:

Editorial interface

How is content updated? Is it through a browser, a document template, or some other application? If it is through a browser, which browsers does it work in? Does it require a plug-in? How viable are those constraints within the organisation? If the organisation is planning to devolve editing, how appropriate are WYSIWYG and in situ editors? If content entry needs to be more controlled via forms, how will users preview their work? Can the WCM offer different editorial interfaces for different types of users? And hand in hand with the interfaces, if you have lots of devolved editors, how does the WCM assure concurrent contribution and secure access for different kinds of users?

Pages vs. elements

Some WCM only really have the concept of pages and associated assets, making it hard to re-use fragments of content across the site. This simple model is generally appropriate for two scenarios: where there are many devolved, occasional contributors who would be confused by having to perform multiple tasks to get a piece of content to update on one part of the site and wouldn’t immediately understand the implications of a more complex editorial change; and for sites which have quite user journeys with little information appearing in more than one place.
For sites which need to re-use content a lot, where there’s a central editorial team assuring that changes are propagated correctly, more advanced systems that use “fragments” of content in multiple locations across the site in an “edit once, publish many” model can bring significant business benefit. These content management models usually bring more flexible templates but they can also make it more difficult to audit content: what did a given page look like on a specific day and who made the content changes? They are also reliant on robust link cohesion, so that if you move a piece of content, the WCM continues to link to its new location.

Content structures

Absolutely central to most WCM is the concept of a content type. This is the model that allows you to define which fields editors need to complete to publish a page and the constraints on those: e.g. title (no more than 200 characters), summary (plain text), main body text (rich text), location (postal code), category (list of valid values), etc. These structures are important for a number of reasons. They allow you to create business rules for linking content, such as get me the three latest news items about Germany. They allow you to create different presentations for different types of content, so am event looks completely different from an FAQ. And they allow you to contol which information must be completed before content can go live and how it will be presented on different platforms once it’s been published.
There are other metaphors that WCM use to relate complex content: hierarchical metadata structures such as folders, categories or channels enable you to group content together in more complex ways. Flatter metadata structures also allow you to “traverse” across website structures and relate content in differnt part of the information architecture that don’t sit into this hierarchy. It’s often useful to have multiple kinds of metadata, particularly faceted taxonomy, if your content is particularly complicated and needs a lot of content relationships in order to achieved desired user journeys.

Technology

Where the WCM isn’t a standalone application but needs to integrate with other systems in a web platform – user directories, CRM, eCommerce, transactional tools – you need to validate how it will communicate with other systems. Is it through the Application Programming Interface (API), web services, or some other method?
The maintenance and extensibility of the system can also be important requirements. If I need to change a content type, what does that involve? If I need to get data from another application, can I do this in a de-coupled way?

Some other factors may come into play, such as workflow, internationaisation and personalisation. If one product is particularly strong in one of these areas and it’s a key requirement, then it may get into a shortlist even if it’s weaker in some of the other areas identified above.

This all brings me to the recent debate about whether WordPress is a CMS, with numerous contributions on Twitter as well as from:

• Jeff Cram: Is WordPress a CMS?
• Ian Truscott: Is WordPress a CMS? Hardly? Barely?
• CMS Watch: Evaluating WordPress as a web CMS
• Laurence Hart: What makes a CMS a CMS?

My experience of WordPress is that it’s really good at two key features where some established content management systems are relatively poor: search engine optimisation and comments. On SEO, it ties your blog post title to a friendly URL, enables good internal linking (as long as you don’t move any pages), allows tagging and categorisation and offers some great SEO tools. Comments meanwhile can be quite tricky for some WCM that operate separate content contribution and consumption environments, but WordPress does this easily, with useful anti-spamming tools and the ability to follow the comment conversation by RSS or email.

When it comes to the question of whether WordPress is or isn’t a WCM, the best analogy I could come up with was a camera phone. A camera phone does take pictures, it is convenient, some phones even have a flash and autofocus. But would you get a camera phone specifically to use as a camera? I think not if you’re serious about photography, It is a camera, but a very limited one.

WordPress is a blogging tool with some shared characteristics of a WCM. If you apply some of the many available modules to it you can come up with a really nice proposition, up to a point. But you’re effectively hacking the software to get it to behave as many WCM already do. You can get any software to do pretty much anything in the end, but that still doesn’t make it a WCM.

WordPress is widely used by many organisations as a web content management system and there are a lot of photos taken on camera phones. But you need to understand the product’s limitations and if these don’t affect you and you’re achieving what you want, then no one should criticise you for your choice. But let’s be sensible about it and say that even if there’s no such thing as the best WCM, you know that it wouldn’t be WordPress.

Janus Boye recently provoked an indignant response from the Twitterati when he proclaimed that he unfollows anyone with more tweets than followers. You should read the comments to gauge the general feelings about that view. It provoked some reflection on my part — which I guess Janus will say was his aim — and I went back to look at how my use of Twitter has evolved over the last two years. And it went something like this: Bewilderment » Discovery » Catharsis » Promotion » Engagement

Bewilderment

Like most people first dipping their toes into a new service, I came to Twitter slightly perplexed. What do you tweet if you have no followers? The thing that first drew me was trying to find out how micro-blogging might be used in a business collaboration context. I’d already used SharePoint and Ning and I was intrigued by the broadcast nature of theses services. It was so Enterprise 2.0! It reminded me of how J.P. Rangaswami had made his emails public to all employees in the organisations he was working and I wondered what effect that had on an even more public scale.

Discovery

So I kept relatively schtum and decided to follow some people I know: @draml, @izahoor, @mcboof and see what they were saying. And they were talking about web content management and I thought, that’s cool: I can find out some new stuff. It’s quick to scan tweets and I’ll read up on a daily basis.

Then I followed the people they were following — which was easier then because Twitter used to show all replies. And I discovered CMS people well worth following, like @sggottlieb and @piewords, as well as people I knew about already like @irina_guseva and @TonyByrne.

So Twitter effectively became a recommendation engine for blogs, of which I amassed quite a few and continue to add to. That gave me plenty to read to keep me on the bleeding edge of the industry.

Catharsis

But then I realised I was saying nothing myself. Resolutely ignoring the adage that it’s better to stay silent and be thought the fool than to speak and remove all doubt, I started to tweet my frustrations at various projects. It was these tweets that put me in jeopardy of Janus’ Law. I was re-living Joachim du Bellay:

Je me plains à mes vers, si j’ay quelque regret,
Je me ris avec eulx, je leur dy mon secret,
Comme estans de mon coeur les plus seurs secretaires.

That was a mistake. Fortunately I never resorted to telling people I was on public transport or making toast.

Promotion

So I just started retweeting links to useful CMS resources and that got me some followers. And it dawned on me that there was a whole world of business leads out there, so I started searching for key CMS terms and following people who tweeted on the subject, trying to engage with them and see what they were after. It was a bit rough but drew some small successes. So then I just promoting my blogging instead.

Engagement

That was a turning point, because I could engage more with people on Twitter than through my website. And because I was following other people’s blogs, I could engage with them on Twitter more easily and involve other people through broadcast messaging, just like JP Rangaswami! Twitter has become a sounding board for my thoughts: I can test things out on the Twitterati and get feedback before I have to let my ideas loose on clients. I hope that it’s actually improved the quality of my work.

I had one big #unfollowfriday when it all got a bit too much, but I won’t generally unfollow unless you annoy me, and I’ve a pretty passive character. I also find some kind of moral obligation to follow people who’re following me and can’t bring myself to unfollow people I’ve known for a long time in the real world, no matter how much rubbish they spout. Those that I really like to follow are those who know stuff and are funny; although having now met @adriaanbloem I’m convinced he uses some kind of ghost tweeter.

But the best things are seeing people get involved in real conversations. Take a look at @jameshoskins‘ Paxman-esque interrogation of @iantruscott about the Alterian roadmap. Or the discussions around #cmshaiku. Twitter can be fun and informative.

So how do I use Twitter for work? I still haven’t figured out if Twitter has a place in the enterprise, but it does allow me to keep engaged with a continually-evolving industry whose ideas appear online in less than 140 characters.

So, I thought I’d try a sonnet.

Shall I compare thee to CQ5 Day
Complete with JCR? Or to software
Suites from EMC (with FatWire?). Beware!
OpenText Livelink and Vignette make hay

While Sun’s products are now Oracle’s prey.
Alterian markets acronyms. Share
Point and EPiServer are .Net fare.
SDL can’t decide. But should you pay

For a licence? Consider open source
From Joomla, Squiz, Liferay… or Drupal of course.
Just don’t assume that it will cost you less:
Calculate carefully the TCO
Of products that seem free like Alfresco
And if you have no budget use WordPress.

All right, so the pentameter isn’t truly iambic, but it is a sonnet. So I tried this instead:

There was a young man from Nantucket
Who used his CMS like a bucket.
Although his pater
Said “apply metadata”
He just didn’t know where to tuck it.

Some of my haikus were:

Like autumnal mist
Licence costs remain obscure.
What am I paying?

Drupal has Gardens
Cultivated in the cloud.
I share my first thoughts.

Is 5-7-5
A template, a content type
Or metadata?

You can retweet this
Or change it; open source not
Proprietary

Call that CMS?
Where’s workflow and content types?
Just a blogging tool.

Feel free to add limericks as comments.

Last week, Acquia launched Drupal Gardens in beta. Speculation might have been more feverish had this not been on the same day as some company in Cupertino launched a new gadget. Nevertheless, Acquia’s offering is worth a second look.

Gardens is effectively Drupal 7 as a service: WCM hosted on the Amazon content delivery network. It includes a number of modules and is aimed very squarely at microsites and perishable campaign sites. It promises rapid deployment without needing a Drupal superhero to set up your site. You don’t need SQL, you don’t need PHP. You pick your URL, your templates, tools and styles, enter your content and you’re live.

And that represents what many people really understand by WCM.

You can create repeatable information architecture and consistent design elements from a library of themes and templates. You can use the Theme Builder to create custome content types. And it’s way friendlier than WordPress.com. Slicker too. People with very limited web knowledge can create websites even more easily than they used to in the days of Frontpage or Dreamweaver and go live with them, since Acquia take care of the hosting.

But this is very much WCM for websites that have content only. There’s nothing transactional and no sign yet of secure hosting that establishes private networking to your other online applications. It’s a great template editing tool to give to your design team or for small businesses to play around with, but not necessarily the tool that allows you to devolve complex editorial tasks to distributed authors. While the cloud-based aspect should allow you to scale your website delivery, it’s not clear whether it scales on the authoring side for people wanting to contribute content from around the world (which probably isn’t a central use case). It’s also worth noting what’s on the road map, because these are things that Gardens can’t yet do; such as multi-site search, multi-site configuration, and analytics.

Where Garens is a great fit is for clients who want a rapid time to deploy with minimal fuss. Why should clients concern themselves with APIs and hosting SLAs? Why should they have to engage with geeks just to change a template? Gardens resolves those issues by giving you a website builder and at a great price: it’s free throughout 2010 and only $20 to $40 per month per site after that, with flexibility over multi-site licences. But if you’re hoping that your website should be more than just vanity-ware, that it will increase revenues or reduce pressure on other streams by bringing transactions online, you’ll have to look at a content-driven application that has better integration points with other systems, or wait for this to be developed by Acquia.

I think Acquia’s move has implications for the wider WCM industry. Firstly, that the SaaS model has a valid use case which will permeate higher-end WCM; for example, Alterian CME is sort of available as a service through Verizon. Secondly, because many clients still understand (and want) WCM to be a tool for managing look and feel as well as content. Drupal Gardens achieves both those things. Can other vendors say the same?

How many websites these days are purely content-driven?

It’s hard to justify brochureware sites. How many people do business with you just because your website looks pretty? Organisations want websites that either generate an income or reduce pressure on more costly channels, like call centres. That means transactional web applications, not just web content management.

Yet content management is still required. Whether you’re updating marketing material to support your service offering or changing form labelling and layouts to ensure fewer drop-outs on transactions, the web team still needs to be able to make content changes without having to go through a lengthy development release process.

The simplest way to achieve this is to run two web applications separately, one driven by the content management system and the other by the transactional software, like eCommerce. You get your developers to style the two applications to look the same, run from similar URLs and hope that the web app gives you enough control to alter content that it’s responsible for, such as labels on form fields. This way you can keep system integration to a minimum. There are a couple of significant disadvantages, however. Firstly, if your site needs to change globally — a change to brand or navigation, for example — you have to update both systems. Secondly, you need to design your site in such a way that you keep content and transactions separate, which is very unlikely to lead to a successful user experience.

So what are your other options? You could take content managed through the CMS and embed it in the transactional application. This means that when you have a form field to complete which needs some guidance, that guidance can come from the CMS without the user having to abandon their transaction. But this creates problems of its own. You lose some of the key benefits of the CMS: relationships are harder to maintain between pieces of content and preview becomes nearly impossible.

This is why the transactional application is often embedded in the CMS. FatWire, for example, has just launched its Web Experience Management Framework, which should make this process easier, while Terminal Four also touts its integration with external systems. Yet irrespective of the CMS you use, you’re going to face some integration problems. There’s bound to be an element of custom code, issues with assuring decent performance from both the CMS and the transactional application, and above all design difficulties ensuring that the security of the user’s transaction is maintained by the delivery layer.

Another option is portal technology. In theory, portals enable you to deliver all your web applications in an integrated fashion and what’s more, do so incrementally, adding applications without having to change the core configuration. They’re also usually pretty good at managing sessions and user credentials. Portals bring their own problems however, not least cost of delivery, increased time to develop and un-friendly URLs.

So all four approaches have positives and negatives. There’s a niche in that market somewhere for a vendor. Until someone proves they’ve filled that niche however, you’re unlikely to be able to deliver a great business-driven website using just a web content management system.

The future of the web is mobile. And by mobile I don’t mean mobile phones. I mean browsing through devices that people carry around with them. All these devices, irrespective of form factor, have a common problem: they are prone to lose connectivity to the internet.

If you’re on the move and keep losing your 3G signal, or just happen to live in an area with a poor reception, or in a house with brick walls which slow wifi, or suffer from terrible contention rates in your Starbucks or conference venue, you’ll know that cable-less connectivity is fallible. So you’re in the middle of a transaction, just trying to get to the next step when… enter tunnel / lose packet / connection error and you have to start over.

There is a solution to this problem however. As Michael Kowalski tells us, the future of the web is JavaScript. Or perhaps not JavaScript in its current form, but client-side scripting nonetheless. Why? Consider the options.

If you want interaction that will run reliably on a device with poor connectivity, you can’t keep expecting the browser to go back to a server. So you might make your functionality available as a downloadable app. But it had better be a killer app the user wants to rely on, because otherwise they won’t want it taking up real estate on their phone. And it’ll have to run across operating systems if you want to reach a broad market, not just Steve Jobs’ latest toy.

You could use a rich internet application such as Flash or Silverlight. But the client platform has to support these and the user has to install them, although they’re more likely to do so for a generic RIA than for a specific tool. The big issue with these applications however is that the content is embedded in the interface, which makes them both heavy to download and difficult to make accessible to other applications, such as screen readers and content aggregators. So you’d probably have to create two versions of the content: one embedded in the RIA, the other standalone. That’s not great.

JavaScript has the advantage that it can be used to enrich content, but not contain the content itself; for example, to provide better interactivity on maps. There are also libraries of JavaScript functions that can be re-used and downloaded to the client device with the user barely noticing. Take jquery: Google hosts a copy, so if you use these functions on your site, you don’t even need to host the file. Reference Google’s copy and you’ll save bandwidth and, if enough websites follow the same path, there’ll probably be a cached copy on the user’s machine even before they get to your site, which will significantly improve response times.

Google is of course moving beyond jquery to complex client-side scripting which its own browser / operating system will be capable of handling, but some other browsers may struggle with. Chrome is a replacement for off-line scripting using Gears. It should not only enable mini applications such as Wave to run faster in a browser, but will enable online transactions to continue to function better when connections are poor. Opera has been developing similar functionality for its browser too.

So if you want to provide audiences with a better experience irrespective of platform and location, a lightweight client-side tool that separates content and function and runs in a browser seems like a future-proof idea. And for the moment at least, that means JavaScript.

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

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

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

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

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

So, do you:

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

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

Alas, poor clients

How many people could say that they were happy with their implementation? Even those case studies I saw were tinged with regret at missing features or how long the process took. The conference was littered with people who’d wasted budget and wanted to share their hindsight. And these were the enlightened ones.

The industry protests too much, methinks

But while those of us in the industry can easily put errors down to naïvety, I think it’s time we took a long hard look at ourselves. How can we tell users that CMS is like complex machinery which should involve substantial training and even change management? That’s an appalling attitude to user requirements.

Don’t try to make people change… do something that can’t already be done. (Euan Semple)

When every survey shows usability as the top area of dissatisfaction with CMS, what’s preventing vendors from making a friendlier system? As Seth Gottlieb points out, they’re all as bad as each other.

Slings (and boxes) and arrows

Creating and maintaining content should be simple enough for devolved editorial teams to perform with little training. The tricky thing is creating high quality content to suit an audience’s needs. Yet few CMS will ease editors through this process or evaluate their content against style guides. We’re beginning to see a few technologies in this area, but these are just sold as add-ons to an already bloated feature set.

The play’s the thing

It seems the industry has been blind to the truth. Features are specified but never used. Vendors add functionality so that they can score highly in analyst reports and avoid being excluded from shortlists, but all they’re doing is making it more difficult for users to create a compelling web presence.
To be or not to be
WCM was once a breakthrough in enabling less technical users to publish web content relatively quickly. But has it really progressed in the last few years? I don’t think so. We just have more modules piled onto re-skinned interfaces. Can’t we have friendlier tools for delivering a content strategy? Otherwise WCM will see some other application usurp its role and seduces its client base, which would be a tragedy for the industry.

More on #fixwcm

• Jon Marks, including links to other post on the theme.
• #fixwcm tweets

More on #jboye09

• J. Boye participants
• My conference presentation — succeed fast

Saying is easier than listening.

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

More is easier than less.

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

You get more than you need.

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

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

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

Read more

• Things We Hate About Content Management
• A Collaborative Google Wave Blog Post.
• I Predict A (CMS) Riot: 1 hour, 6 People, 1 Wave, 1 Post
• Wave experiment: Things We Hate About Content Management
• The people who contributed to the post were: @irina_guseva, @justincormack, @iantruscott, @andrew_liles @adriaanbloem, @McBoof