Feature

posted 23 Dec 2004 in Volume 1 Issue 6

The 7Cs of intranets

Intranets are all around us, but how many genuinely deliver sustainable value to their host organisations? The 7Cs is a consulting and change framework that focuses on delivering value through sustainable change. Applying this framework to the development or redevelopment of intranets will help ensure that your intranet doesn’t become a nightmare for users and the business.

The most common project in today’s enterprise that has the potential to become a major headache is the corporate intranet. A few years ago, intranets were seen as a step towards creating the perfect knowledge culture. An internal website, browsed from the comfort of the desktop, enabling quick and easy access to all the information an employee needs to do his job, combined with streamlined internal communications. But in reality, most corporate intranets are out of date, under-utilised and lack any real cohesive design.

The 7Cs is not rocket science, nor is it a magic bullet, but it will help you get things right more often.

1. Client

Understand the person, understand the problem

First, who exactly are you doing this for? Yes, of course the organisation, but who specifically?

A specific, identified client or sponsor is essential for any intranet project. How else can you agree business purpose, goals, scope and budget? This is not simple. Traditional project management methods see this as the person or committee that you agree the project brief with. Unfortunately, the reality is almost always more complex. Luckily, most enterprises have moved on from the ‘me too’ driver for intranets, but there are still clients who will spend their companies’ budget on internal marketing and promotion that is of doubtful value.

First, you have to be sure you have identified who the real client is – who is the key decision maker on behalf of the organisation? Having established this, and gained access to them, you need to view the situation through their eyes. Test their intent and seriousness. Keep asking ‘Why?’ What do they want to get out of this? How will it create value for the organisation?

You will have to build a relationship of trust with the client to be able to do this effectively. Some executives will react badly to having their judgement tested or questioned. There are no short cuts here and spending time with them is essential.

You need to challenge and educate – challenge the client to establish whether they have a clear understanding of what they want to achieve, and educate them as to why you are asking these questions and what might go wrong further down the line if you don’t.

If your client is unwilling or unable to work through these issues with you, perhaps you should consider whether you are prepared to risk your personal reputation on a project that is starting badly?

The 7Cs framework includes several simple but powerful tools that can help you during this initial phase of the project – here’s a brief summary of two of them.

The OUTCOME model

The OUTCOME model provides the basis for a set of questions to ask clients right at the outset of a project:

Ownership – who owns this project and is ultimately accountable for its success?
Unease – why this project, and why now?
Trade offs – what will have to be given up to make this project possible?
Changed – how will life be different when the project is complete?
Others – who will be affected by the project and what do they think?
Measure – how will value be measured and what defines a successful result?
Engage – what value can this project add and how can you contribute?

Using these questions clarifies what is known and not known, raising points for the next stage.

The change ladder

All projects are about change – after all, if nothing changes, then what is the project about?

It’s useful to think about what kind of change a project is trying to achieve, and compare this with the interventions the project will make. The 7Cs change ladder is a way of classifying what kind of change is being made (see figure one).

Asset changes are about physical things, from a PC to a factory or warehouse;
Blueprint changes focus on how things are done – rules and procedures;
Capability changes concern the underlying capabilities of the organisation and, therefore, the people in it;
Desire changes are about individual motivation – what drives people to particular courses of action;
Ethos changes are about core values – why an organisation exists or the deep beliefs of an individual.

As we move up the ladder, the nature of the change becomes less tangible and more personal, requiring different kinds of interventions to be effective and sustainable.

Use the change ladder as an input/output model – what kinds of outputs are expected from this project? What kind of inputs will be required to achieve them? What kind of measures will we need to test the success of the project?

Intranets are usually planned as asset and blueprint inputs, but the client often describes the output in terms of desire and ethos – ‘we’re going to change the way we do things around here’. Is it likely that a new intranet will change peoples’ desires and behaviour? Consider what extra things you’ll need to do to really engage with users.

It is important to remember that this variance between planned input and expected output is the primary reason for failure in many projects.

Key questions

What is the issue, and why is it an issue?
What has caused this?
How will the intranet (help) solve the problem?
Why now?
How will life be different with the new intranet in place? And for whom?

2. Clarify

What’s really going on?

Now that you have established a solid relationship with your client, it’s time to start digging. This is where you have to (diplomatically) look around the client to establish the reality of the organisation’s working environment. In essence, this stage is about understanding the target environment. If you don’t take time to do this, problems will only resurface as expensive redesign work later.

Major stakeholders in intranet projects include: users – both end users and administrative users; business sponsors; and technology providers. You should explore the project with representatives from all of these groups, understanding how they see the project. But remember, clients can feel uncomfortable with this, especially those who believe that they understand their users well.

Notwithstanding this, to help negotiate this difficult stage of the project, it’s worth exploring whether there have been previous attempts at building intranets and how successful these were. Also, what else is going on in the organisation that might affect the project? What do the potential users think? Has anyone asked them (after all, somebody somewhere is going to have to change the way they work)? It is also important to consider what kind of resistance to these changes might be met and from where?

Asking these questions and exploring these areas will help you understand where the real drivers for this project lie, and how bumpy the road is likely to be. You also need to spend some time identifying any ‘shadows’ that may be hovering around the project. Shadows are underlying issues that are rarely discussed, such as:

What’s the real driver for the intranet? Do all stakeholders really believe in the project or is the client just trying to meet a target?
What are the organisational politics that might impact the project? Does the organisation as a whole believe in your client’s vision?
You may well find yourself iterating back to the ‘client’ phase as you find out more – things will come up that you need to ‘clarify’ with them.

By now you should understand and believe in the business case for the intranet, who is accountable for success, what that success will look like and broadly how you will test whether you have been successful.

At this stage, it’s easy to feel that this is a lot of work for little output – but this is the critical stuff. How many projects can you think of that would have been more successful, or perhaps not even started, if these areas had been properly understood at the outset?

Key questions

Who are the intended users?
Has anyone talked to them about the project?
Can you draw me a picture?
Who else should I talk to?
What else do I need to know to understand all of the issues surrounding this project?
Do you foresee any side effects?
What has worked or failed before?
What will happen if this project fails?
How will we know that the project has succeeded?

3. Create

Build the right solution

Now that you have a fuller understanding of the environment for the intranet project, you can focus on designing the solution. The information gathered previously in the client and clarify stages will let you establish what ‘right’ means during this next phase. You need to establish and rank the criteria by which you will judge the myriad options that the technology provides, but there is one over-riding principle – if your intranet doesn’t deliver what your users actually value, you might as well burn your money.

What does ‘right’ mean?

At the highest level, this means ‘whatever delivers value for your organisation’. Of course, life is not always this simple and what’s right means different things to different people. If you have worked through previous client and clarify stages, you should have a pretty good idea of what’s important to the major stakeholders.

The next step is to develop a clear list of benefits for users – what will they be able to do (functionality) and how will this help them (value). Define the value to the user and the organisational value will follow.

If you are supporting existing tasks, you need to understand how users perform such tasks and how the intranet implementation will improve this. If the intranet is to support new functionality, you need to consider how this will be sold to the end user. For example, if you are delivering collaboration functionality, think about how people collaborate in your organisation at present and what you need to do to convince them that using the intranet is better than what they do now.

Your objective should be to make the intranet indispensable for users, and that means delivering functionality that they really value. Just delivering the capability is rarely enough – people have to have the desire to use it.

Some sponsors will firmly believe that they know what users will value, so there’s no need to ask them – in practice, they rarely do. A content-design workshop, which matches user groups to tasks, and then intranet functionality and services to those tasks, will help ensure proper alignment.

Out of this should emerge a clear picture of the functionality that your intranet needs to deliver to create value. Add all the usual project evaluation criteria (cost, speed of implementation, fit with existing technology infrastructure and so forth), and you have the basis for comparing solution options.

Solution options

Selecting a corporate portal or content management product is a serious undertaking. Here’s an approach to evaluating some of the options that you will face:

Functionality – how well does this solution fit with the things that you need? How many other things that you don’t (yet) need does it do? Are any of these potential distractions that you would be better off without?
Implementation – what would it take to implement this in your organisation? Consider organisational fit – does this solution require a very different way of working? Do you have the necessary technology skills available? What about integration costs? What’s it going to cost over five years?
Sustainability – what resources will be required to maintain the information and services delivered by the intranet as well as the technology infrastructure? Will it continue to create value?

A popular approach is to start with a small-scale pilot. Benefits include close contact with the users and the ability to rapidly iterate through evolving designs – the rapid-application-development (RAD) approach. You need to be sure that the pilot is able to provide the important answers you need before rollout. Are the pilot users truly representative of the wider audience? Have you reached a stable design? Will the technology scale up in a manner that is sustainable?

As with any project, robust change management is vital to control scope. There are many formal project-management tools (PRINCE II, SSADM, etc) that focus on this. Underlying the formal procedures and steering committees is a single key test – how will this change add value?

Involving the right people

The project team needs to include representatives of all the key stakeholders. Their importance and roles will change over time.

In the early stages, when the focus is on defining the functionality required, user involvement is vital. Their role is to say what the intranet should do to deliver value for them. The sponsor makes the judgement as to whether this will create value for the business.

As you move to solution options, the technology providers start to play their part. The extreme programming (XP) approach can be helpful, in that it links users and developers in a rapidly iterating cycle. XP is actually two things: a value system and a set of practices that can be applied iteratively to build software. Both aspects hold promise for the design and development of intranets and can result in a robust, highly usable design that is tightly focussed on users’ real needs.

Key questions

What will users be able to do? How will that help them?
What are the constraints? Is there anything we cannot or must not do?
What have you thought of already?
How radical do you want to be?
How much risk are you prepared to take?
Where will the content come from?

4. Change

Making it happen

You’ve defined the functionality, chosen the technology, done the prototyping and you have a great solution that will add enormous value to the organisation.

Now you just need to get it implemented. What kind of execution approach will you choose?

A top-down, corporate mandate (push)?Or bottom-up user adoption (pull)?

Both of these poles have benefits and risks, and of course successful strategies will use a mixture of both appropriate to the organisational culture and situation.

Push from above delivers resources and speed of implementation, but risks alienating users, particularly in creative environments. This can lead to initial success, but without user commitment usage and value will decline over time.

Pulling implementation from user adoption requires that you have a convincing offer for them to adopt, and can take some time. The resources required may in fact be higher than for a push approach, which requires internal marketing and education.

Whichever approach is selected, you’re bound to end up iterating back to the create stage – pretty much every intranet needs re-inventing once in a while as business priorities move on.

You’ll also need great leadership – as you roll out, you will almost certainly run through something similar to Gartner’s hype cycle (see figure two). It’s clear-sighted leadership that will damp down the peak of inflated expectation and drive through the trough of disillusionment.

Key questions:

Is everyone involved keen to go?
Have we got all the power and authority we need to make this happen?
What else is going on in the organisation that might blow us off track?
How will we help people adapt to the new intranet?

Confirm

Checking that it worked

Did that value get delivered? Ascertaining this can be the hardest part of project. Sponsors often don’t want to do this, in case their pet project hasn’t actually delivered. Project teams don’t want to do this – it’s hard, potentially challenges the value of their work, and compared to the excitement of a new project, boring.

And users don’t see much benefit for them in providing feedback.

Measuring intranet activity is easy – there are lots of tools that will provide complex reports on number of users, page impressions and the like – but it’s hard to convert these into value created for the organisation. Somehow you need to get to the money.

Quantitative measures

The most common conversion is to multiply ‘minutes saved’ on some common task – typically searching for information – by the number of users and their average salary. The assumption is that the time saved will be used to do something ‘more productive’. Unfortunately, there is rarely any evidence to support this. Think back to the change ladder – what has been done to help people change their desire?

To be hard-nosed about it, the only reliable way of converting these time-based savings into money is to use the increased efficiency to reduce headcount and therefore staff costs.

Qualitative measures

What’s the value of better collaboration enabled via your intranet?

You may be able to find evidence of new business won, costs avoided or saved through knowledge sharing and so forth – but you will have to look for it. Ask the users, and make it as easy as possible for them to share their success stories with you.

A robust, confirm step will include a mix of quantitative and qualitative measures that will build up into hard evidence for the value of your intranet.

By the way – you did discuss and agree what these would be back in the client and clarify phases, didn’t you?

Key questions

How will we measure user buy-in?
How will we measure value?

6. Continue

Your rollout is complete and you’ve checked that the project is delivering value – time to move on?

The continue stage is about making sure that success continues once the intense focus and resources of the project team have moved on. There’s no value in creating a wonderful intranet that rapidly falls into disuse because there aren’t proper processes and resources to back it up.

The project must define and put in place the processes required to keep the intranet alive – and this means more than the usual content management issues of quality control and lifecycle management. You need to ensure that the intranet remains relevant to users. How much content creation and contribution is seen as a one-off, ‘project’ exercise? And if this is the case, how likely is it that intranet content and services will be kept up to date?

By definition, a project comes to an end. However, an intranet is never finished. You must put in place people and processes to:

Support the infrastructure that the project has delivered;
Maintain and develop content and services;
Monitor user adoption and value delivery, and decide when it is time for the next project.

All of this costs money, and unless the value of the intranet is understood and appreciated, this will be hard to come by.

Key questions:

Are the necessary resources in place to sustain the new intranet?
Are all the roles identified and operational?
How often should we review?
Is the continuous improvement programme in place?

7. Close

Finally, you really are done. Time for you and the client to reflect on how it went:

Did you create value?
Is it sustainable?
What have you learnt and what would you do differently next time?
What’s next?

The moral of the story is to take your intranet project as a serious business decision and afford it the attention it deserves. By carefully considering all of the potential stumbling blocks, you can avoid the pitfalls of uneducated intranet implementation. With a clearly defined business strategy and careful planning, your intranet can become the cornerstone of your organisation.

Resources

1. ‘The 7Cs of Consulting’ by Mick Cope.
See http://www.wizoz.co.uk

2. See http://intranetjournal.com /articles/200109/gb_09_12_01a.html for an introduction to extreme programming and intranets
Chris Fox, Cadno Consulting