Contented Management laughing buddha logo

Contented Management

Contented Management

Fear and loathing in requirements

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

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

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

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

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

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

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

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

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

Philippe Parker on 18 January 2008

Contented Management

Are open standards by-passing enterprise implementations?

A significant challenge for medium to large organisations is managing the exchange of information between all the applications. This might mean having a common login for your users across all your websites, or being able to display different content depending on a visitor’s geographic location.Ordinarily, the approach has been to create complex integrations of content management systems with user directories (LDAP), web services and portals to expose information from back-end systems in a standardised way.The single biggest issue with this approach is cost. You need sufficient kit to ensure scalable dynamic delivery of the applications, licences for all the software involved and significant design and implementation time. You always hit hurdles during the project as you discover data models weren’t quite what you expected, or your LDAP directory has been customised to hold data slightly differently, or you can’t get one portlet to communicate with another… It’s time-consuming and often frustrating.

Once you complete integration to all your applications, they appear as a common platform for everyone interacting with your services. Except that people don’t use the internet to interact just with your services. They want to check their email, spend time on their networking sites, shop… why should they have to go to your site just to get hold of information that should be available anywhere?

Who buys a washing machine by going to the Hotpoint site? They go to a price comparison site or a reliable distributor first. You should be able to syndicate your content any partner site. And when I’ve remembered my login to all your services, wouldn’t it be good to have the same username and password across all these partner sites? For example, you login to check your current account balance, and it’s the same login to check your mortgage status with another bank!

All right, you can retain login credentials in your browser, in a particularly insecure way. And why would you expect Barclay’s and Abbey to share login credentials? Because it’s what customers need.

We’re seeing the emergence now of true data portability. Increasingly, large web organisations (Google, Facebook, LinkedIn, Flickr) are subscribing to a model of open standards for information exchange that mean you’ll be able to enter your information once and choose which data you share with which websites. Consider OpenID which already provides single sign-on across many sites on the web. This is exactly what many enterprises are struggling to achieve across applications which they actually own!

So what does this emerging approach mean for enterprise implementations? It means you need to question the value of creating complex data integrations. Service oriented architecture through a portal is no longer the only method for integrating your systems, so you need to conduct some due diligence to satisfy this kind of expenditure.

Data portability is, of course, no panacea. Standards are still emerging. But if you’re going to jump on a web services bandwagon, it’s probably a good idea to be on the same train as Google and other leading web presences.

Philippe Parker on | 16 January 2008

Contented Management

4 steps to the right CMS

The main reason for choosing a new technology is to reap its benefits. But the processes that organisations follow can obscure these benefits rather than unearth what’s feasible. So let me add a few points that may help to steer you in a direction where you can get the most from a new CMS selection exercise.

1. Accept that different technologies will make a difference
Your organisation has to understand that different technologies will provide different benefits. There will inevitably be people who tell you that it’s just technology and which one you choose won’t make that much difference; they all perform the same basic function after all.

There is an element of truth in this argument, but there are some very significant differences between WCM software and their suppliers, notably:

  • financial stability, product maturity and the number of service partners in your geography;
  • delivery mechanisms (static or dynamic) and product scalability;
  • integration capabilities and an open API;
  • user management, persistence and personalisation options;
  • classification management;
  • community and marketing features;

2. You will need a spreadsheet
Technology selection is not about scoring matrices, with coefficients for requirements and complex calculations. However, if you are going to satisfy the finance director you will need to prove that the technology you’ve selected does meet the requirements set out in the business case. Moreover, you will certainly need a check-list of technical prerequisites that any software should adhere to in order to make a shortlist. Don’t forget to tell the vendors which email clients your editors will be using and which operating systems and versions of Office their tool should integrate with.

3. You will need scenarios
No matter how command-and-control the culture within your organisation, if you enforce a technology that’s meant to be devolved to lots of users — particularly if they’re in multiple locations— that is difficult to use, you will be in for a lot of trouble. You’ll have to expect increased training and support costs as well as brooding resentment about the new technology. People will find workarounds to the very processes you were looking to instill.

Engage the people who are actually going to use the CMS and get them to help you to articulate the main issues they have with managing publishing content. Then invite the vendors to demonstrate these tasks to this audience. A few key points on these demonstrations:

  • Don’t tell the vendors how you want things to work. Explain the problem and ask them to demonstrate a solution.
  • Create scenarios for the tasks you perform the most frequently. If you only create a new workflow once every six months, the fact that you can do this in Visio is pretty irrelevant. Concentrate on content creation, review and relationships.
  • Think about how the content is managed rather than its delivery. In the end, any product can be made to generate accessible HTML, provide streaming media and publish printer-friendly views. Concentrate on short and long documents, content sharing and classification and take a hard look at the authoring interfaces which your teams will be using every day.

4. Allow the vendors to impress you
Always give the vendors twenty minutes to show them what else their product can do that you haven’t asked for. It’s the opportunity for the sales team to show off why the product inspires them and to show you why you want to work with their product rather than someone else’s. A content management system is not only supposed to enforce your editorial processes; it should inform them too. If you’ve been struggling with a technology for a number of years it may be hard for you to see what’s possible, but some new product feature may resolve a problem that you previously thought intractable.

Take a look at what the product has to offer and see if you have any business problems now that the tool can resolve that may have been out of scope. Don’t get hung up on features for their own sake, but if the product rings a bell and the sales team have done their job, you’ll be well on the way to picking the right piece of software.

Philippe Parker on 2 January 2008