Category Archives: Requirements

When should technology lead requirements?

How do you develop your content management requirements?

Typically, organisations will identify a business strategy, develop requirements based on that strategy to improve revenue or reduce costs, and then develop a software architecture based on those requirements. But when should the technology drive business change?

The simplest answer is “never”: don’t let the technology tail wag the business dog. But the simplest answer is rarely right. New technologies can lead to competitive advantage as well as stimulate innovation culture, so there should be room for a technology-led approach. You do need to establish some criteria for initiating these kinds of projects, however.

Emergent benefits but a defined problem
You may not know precisely what benefits the new technology will bring — this is particularly true of very new technologies that have little case history of ROI — but that shouldn’t in itself preclude assigning the project a budget. What should prevent you starting the project is not having a problem. This might be an operational issue such as ineffective project communications, or the opportunity to target a new market segment. But the problem needs to be there even if it’s not clear how the new technology will resolve it.

For example, online retailers have long had an issue with customer trust. People don’t buy products just because the website says it’s worth buying. But if you add the facility to comment on or rate a product, this gives some reassurance to the buyer. It improves sales markedly for some items, but risks reducing them for products that receive poor reviews. While it’s not 100% clear what effect customer ratings will have on your revenue stream, they do address the perceived trustworthiness of the product description.

If you want an example where this hasn’t worked, consider Second Life. Eighteen months ago, virtual worlds were the bandwagon to be on. It wasn’t clear what the benefits would be but it was technologically cool. The problem was that there was no problem. Second Life didn’t offer any real communication improvements while tapping a relatively small market that could be reached through other channels anyway. There may well be scope for virtual worlds in future, but they need to address a real business issue before they’ll take off.

Ability to deploy quickly
Since the rate of obsolescence outpaces the rate at which companies change , you’d better be quick about your work. If it takes you a year to roll out a new technology, this should be business-driven, not led by a technology which will be old hat by the time it’s deployed. Software as a service gives companies a real advantage to deploy quickly, as do flexible server environments. You should certainly be looking at these kind of tools if yours is an organisation that likes to be at the leading edge.

Acceptable cost
How much money are you willing to risk if the technology doesn’t bring any benefit? This is a difficult assessment to make as you’re less likely to have a watertight figures than if you went down the more traditional business case route. Normally your assessment would be: my problem costs me £X, so if I spend £Y then I’ll get a return within Z months, so £Y can be my project budget. When you’re technology-led, you’re unlikely to know how long it will take to get a return. So you need to treat your budget as a sunk cost that you’re comfortable writing off.

This doesn’t necessarily mean that your budget must be small: the car industry spends a fortune on innovation because the risks of losing competitive advantage are so huge. Of course, you can limit your risk of failure by running a pilot, which will help you to satisfy the need to deploy quickly as well as constrain costs. Your project budget should be based on the scale of the problem you’re trying to solve, rather than on the scale of anticipated benefits.

Exit strategy
If the technology isn’t as successful as you’d hoped, or it’s viable but creates other problems you hadn’t forseen, you need a cost effective way to abandon it. This is particularly relevant for information management projects. If you put business critical information into a new wiki that has poor adoption, you absolutely need a way of getting that information back in a format that can be migrated to another system. Your project needs to include a decommissioning approach.

Ride the wave
Technology should inform your business strategy, but being at the crest of the hype cycle isn’t enough. If you apply these criteria to technology-driven projects however, you should go some way to avoiding the trough of disillusionment, both emotionally and financially.

Questions to ask before selecting a web content management system

This is a brain dump of open questions that I’ve asked previously when speaking to clients about their websites and their requirements for a content management system. This assumes that the technical prerequisites are being addressed elsewhere.

You can pix and mix these questions as you feel are appropriate to your context, but generally it takes about an hour to get through these with one or two people at a time. If you need to run larger workshops, I don’t think this approach would work.

Vision and Objectives

Is there a content strategy?
What goals are currently being met?
How do you want to interact with your customers?
How much integration is required with other systems?
Which services should be provided through the website?
What is “the Vision” from your team’s perspective?

Suppliers

Who is creating / editing content? With what frequency?
Who plans content?
Where / what is the content you are responsible for and how is it used?
Who do you work with during the content creation process? How effective are these relationships?
How do you collect information to write your content?
Do you usually know about other initiatives in the organisation and how they affect what you’re working on?
Do other departments see the documents you produce? Do you see theirs?
How do you handle authors working on content that may be published simultaneously to different parts of the site? (i.e. ensure content is the same when it needs to be and different when it needs to be).

Inputs

What are your current content creation processes? Which are effective / ineffective? Why?
What are the problems / frustrations you face in creating content?
What features would you like to see in an authoring, CMS or publishing tool?
How are documents created? Do you use or templates or style sheets?
What tools do you use in authoring? How effective are they?
What is the format of the content you create? What sources is it dependent on?
How do you add metadata?
Do you re-use content from elsewhere on the site?
How do you manage demand for content from customers?

Process

What do you do to control documents? Version / access controls?
How do you handle sign-off / review?
Who edits / transforms content?
How is it classified?
Who relates content across the site?
What workflow review is involved?
How will the content be reused / archived / reviewed?
What works well with the current process?
What are we trying to improve?
What sort of reporting is required?

Outputs

What format does the content need to be in? (Accessibility levels, email, print / DTP, mobile, .CSV)
Where is it stored / distributed / aggregated?
What templates are required?
How much content should be reusable?
What extra site functionality are you interested in seeing?
How much Interaction or interoperability is required with other sites (e.g. client extranets)?
What requirements do you have for searching?

Customers

Who do you consider your target audience?
How much interaction do you have with customers (feedback, surveys, consultations)?
Is there a need for personalised / targeted outputs?
What are your customers’ key areas of interest?
Do you have access to website statistics? How do you respond to these?
What attracts customers to the store?
What information on the site helps your customers get their job done?
What types of information do they look for in a document?
How much information do they find useful?
When do they use the content (on one-off projects or on a recurring basis?)
What do they like best about the content? What do you like least?
How do your customers prefer to receive information?

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?

Building up to great websites

I’ve been reading Jim Collins‘ Good to Great and it’s a thought-provoking study, based on mountains of empirical research. It discusses what Collins calls the physics of how good companies become great companies, significantly out-performing their competitors. But it’s striking that a number of the key attributes of companies that make the leap from good to great can also be applied to websites and to WCM in particular. In this post I’ll focus on what Collins calls buildup, before moving onto breakthrough.

Level 5 leadership

Collins found that all the top-performing companies he analysed were led by people who combined personal humility with professional willpower. It’s easy to extend these characteristics to websites, where a major barrier to success is vanity. If the website is your “baby” or reflects the parochial concerns of your departmental or organisational structures, it will never be a great website.

While sponsors and stakeholders empire build, or focus too much on the website and not enough on the web as Gerry McGovern points out, you cannot achieve your potential. The message should not be “when I was in my last job, I did it this way”. The message should be “we need to improve, we need to stop doing things badly”. This is a matter of professional integrity and resolve, not a way to boost egos.

First who… then what

If you recognise that you don’t have the skills or time to do everything yourself, you’ll also see the need to be supported by a good team of editorial, information design, creative, technical and project management people. You just need to get them on the bus. If they’re any good and have encountered similar problems before, you won’t need to set directions for them. They’ll see the need to improve and will be able to start advising you where the problems are.

For example, when Contented Management staff go into a project, we don’t expect to be told the big vision or what a project should look like. If you know that already, you don’t need us. You just need a bunch of body-shopping coders to implement the changes. You bring us on board because we sign up to helping you the best way we know how.

So don’t decide where the bus is going before the right people are on board. A strong team can set a common vision; whoever came up with the idea in the first place is immaterial. If the idea is right, everyone should buy into it and pursue it relentlessly, just wanting to be a part of a website they can be proud of having helped to develop.

Confront the brutal facts

Above all, the common vision needs above all to be well-informed. There’s absolutely no point in speculation. Collins talks about the importance of a climate where the truth is heard.

Many people just want to know what’s convenient: that your WCM is a great platform for managing content, that it’s robust and performs well, that the users love it, that the websites it generates are standards compliant, that your projects follow best practice methodologies, and so forth. The reality may be quite different, but how do you find out?

Collins proposes four ways to get to the truth:

Lead with questions, not answers.
Hopefully previous posts on requirements will give you some indication of what you should be asking, but I think an important point here is that people won’t simply accept the truth just because you tell them it’s staring them in the face. Site owners may tell you that they have high bounce rates, where visitors come to a single page and then leave again, because they’ve found all the information they need on that one page. But is that really what’s required? What about cross-selling opportunities, or more complete views of the information, or suggested further reading? Do none of your visitors want those things?
Engage in dialogue and debate, not coercion.
Just because there are standards out there, doesn’t mean you have to use them. A CMS can compel editors to display their content in certain formats, but there’s not much point if the editorial team doesn’t buy into it. Discuss how your audiences consume your content now and how you want them to consume it in future. If you choose to standardise, do so because your stakeholders agree with the obvious benefits. But give yourselves some leeway, so that stakeholders can have a non-standard feature if they can prove its business case.
Conduct autopsies, without blame.
Undoubtedly one of the toughest things to do is to figure out why something went wrong. I’ve had assessments carried out on the projects I’ve run, and I’ve had to run many reviews of failed projects that someone else has been responsible for. But how many projects ever run smoothly?
You need to accept that things are going to go wrong and that a collective effort is required to put them right again. We prosper and suffer together. If a person makes a mistake, someone else should be there to support them.
This brings us back to leadership style. Fixing problems is a matter of professional integrity, not of ego-bashing. And if the right people are on the bus, they should be looking out for each other.
Build “red flag” mechanisms.
Being able to confront the brutal facts depends on having the facts in the first place. I’m going to talk about Key Performance Indicators at a later date, but you need to know when something is going wrong as soon as possible. This could be lack of site traffic, high drop-off rates, people preferring other information channels (such as print, or even call centres!), difficulties in estimating and planning enhancements, high costs… anything associated with running a website.
One of the first tasks you’re going to have before you embark on real improvements to your web environment is to be able to determine just where things are going wrong, so you can either fix them or abandon that activity entirely.

As Collins repeatedly notes, great companies don’t focus principally on what to do, they focus equally on what not to do and what to stop doing. If you get this right, you’ll get the breakthrough, which I’m going to cover in the next post.

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.

Take all your requirements from the end points on your fishbone, and write them all down on post-it notes.
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.
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.
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.

Fishing for requirements

Following on from my post about SWOT, how do you exploit this analysis to come up with the requirements you’ve identified with your web content management system? Here’s a rapid approach:

Distribute your SWOT analysis to your stakeholders and set up workshops involving between three and five participants in each.
You’ll need a large whiteboard. Each workshop shouldn’t need more than 30 minutes: 5 minutes to introduce the activity, 15 minutes to run it and 10 minutes to recap.
Draw a horizontal line in the centre of the whiteboard. To the left of the line write a one or two-word phrase that describes the objective or result you’re trying to achieve: for example, “improved WCM”.
Take the key areas identified as weaknesses, opportunities and threats and draw them as spokes coming off the horizontal line: e.g. content, performance, usability, competitor offerings.
Now work with your participants to identify the subjects you need to tackle in order to address the issues identified in the SWOT. Ideas should follow on from the categories you’re suggesting: e.g. competitors are offering RSS feeds, email subscription, personalised news, etc. What else can you offer that your competitor doesn’t currently provide?
The idea is to get as many ideas as possible around the themes you’ve identified. At this stage, it’s about quantity not quality. Keeping forking new lines off the themes as you go along, so eventually you end up with ideas that are four or five levels off the main horizontal line.

You’ll end up with something like this, although hopefully more detailed. Click on the image to view the full-size diagram.

Since all the ideas have been made with reference to the original weaknesses, opportunities and threats, they should all be in line with real issues that your SWOT has identified.

You’ll get a feel for the level of detail as you go along, but try not to get too bogged down in any one area: keep the ideas moving along.

At the end of the exercise, you should end up with a skeleton of ideas that looks something like a fishbone. Draw a fish around it to make it look like one if that helps!

What the fishbone will help you do is to drive out requirements that you may not have considered previously. The higher-level ideas should stimulate the more granular issues and focus your stakeholders on the central issues identified in the SWOT, rather than simply bringing their own agenda to the table.

What the fish won’t tell you whether those requirements are feasible or valuable, so the next step we’ll look at is prioritisation.

What should be in a WCM SWOT?

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

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

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

Strengths and Weaknesses

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

Opportunities and Threats

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

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

Who should make the assessment?

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

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

Why is this approach useful

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