Published: November 2009
James says that intranet teams need to look long and hard at how much they get caught up in the details, and consider how they can take a more strategic role.
Gerry Gaffney:
This is Gerry Gaffney with the User Experience podcast. My guest today has a specific interest in intranets and content management systems.
He’s founder and director of Step Two Designs based in Sydney, Australia. He has written the Content Management Requirements Toolkit, a Staff Directories Report, and most recently a nice succinct book entitled What Every Intranet Team Should Know.
James Robertson, welcome to the User Experience Podcast.
James Robertson:
Nice to be here, Gerry.
Gerry:
Now James, I know that Step Two has a broad work range, but I think it’s fair to say that your key focus is intranets. What’s so interesting about intranets?
James:
Well, what I would observe first off is that pretty much everyone has an intranet. Any medium, certainly large organisation, government agency, anywhere across the globe has an intranet. Safe to say, many of them suck.
There’s a lot of work to be done around intranets. And what I think makes it most interesting is how directly they connect with the work that staff do day-to-day. And certainly the work that we get to do. We get to spend a lot of time with the staff who do the actual work, out in the front line, in the call centre, behind the scenes, and you really get a sense of, if we make this thing work better, then it really does make people’s lives easier. And that’s a tremendously satisfying thing.
Gerry:
I enjoyed your recent book “What Every Intranet Team Should Know” very much, and congratulations on getting that out. It’s a lovely book in a nice small size as well, which is always, I think, an achievement.
In the book you begin with a discussion of the six phases of intranet evolution. What are the six stages, and what characterises each stage? I know that’s rather a length question, but perhaps you could give us a brief run-through of the stages and what they are.
James:
The six phases of intranet evolution came from our observation that pretty much every intranet has gone through the same steps of evolution, across the globe, across public sector, private sector, and it’s useful to understand that, to understand where the intranet is at now, where to go next.
So the six stages:
Stage 1, intranet is born. Someone has this great idea, Hey! I think we should have an intranet. And that might be quite small, but it kick-starts interest, and we go into stage 2 – rapid organic growth.
This is where a lot more people get involved, a lot more content gets published, but there’s no overall strategy or direction. Someone described this once as the intranet having grown like coral, which I thought was kind of nice. And I used that for a while, until someone said: No, no, my intranet, it’s grown like a fungus.
And certainly by the end of this organic growth, many of the common problems – unstructured, incomplete information, stuff is hard to find…
Stage 3. The intranet team says, Oh my goodness, what happened here? Right, let’s do a redesign. And in fact this is the era of repeated redesigns, where organisations get trapped in a cycle of every three years changing the intranet. And it’s different, it’s just not necessarily better.
And then phase 4 is where a topic very close to your heart comes in, which is where the intranet team says, Hey, it’s good that it makes sense to us, maybe we should actually involve users. And this is where user experience comes in – user centred design, card sorting, usability testing, all of this good stuff.
And this pushes intranets forward quite a way, but it’s still not enough, because you can have the world’s most usable intranet, but it can still be entirely useless. It’s great you can find a hundred things, but if it doesn’t do what you need, then it doesn’t add any value.
And so in stage 5, intranet teams start to focus on useful. Building on usable, but now going out into the organisation, understanding what staff do in a much more detailed way, starting to deliver new capabilities.
And that leads them on to stage 6, which is the intranet as a business tool. More than just a dumping-ground for second-hand content, a repository for stuff, this is where the intranet is tightly integrated into people’s day-to-day work, and really adds business value.
If we look at where organisations are at, most organisations are in repeated redesigns, or in the user experience side of things. The useful and the business tool are future stages for most organisations, but are definitely where everyone should be aiming for.
Gerry:
I guess it’s very like a capability maturity model, the process that you’re describing there.
James:
Yeah, I think organisations should aim to try and skip some steps. There’s no reason to let the intranet become a mess, and then to try and fix it. And certainly if… the most common piece of work that teams do around intranets is your intranet redesign… and that’s fine, and if you follow user centred principles, then you can deliver a great intranet, but I would say, do a bit more. Take the opportunity to deliver some new capabilities, rather than just shuffling around what you’ve got.
And in that way, you can start to push the intranet forward, and not just keep cycling on the spot. And that’s, I think, a key focus, should be a key focus for every intranet team.
Gerry:
It’s interesting that you talk about “useful”. I often talk to clients in terms of “utility”. It’s often quite a push for people because… to get them doing the whole usability schtick in the first place is kind of a big step for many organisations. And then to say to them: Well, hang on, that’s actually not enough, you have to be providing utility, or usefulness as you call it, is quite a leap I think for many of them, or an extra effort. Do you find that?
James:
Yeah, I agree. I think utility is a great way of looking at it. For us, we say that good intranet improvements are tangible and visible. So tangible says there was a problem and it’s been fixed, or there was a need and it’s been met. Something that people can understand.
And visible says well ideally it touches everyone in the organisation. But there may not be many things that do that. So instead, at least needs to be able to be communicated out.
So then if we look at that we can say Well, great, improving metadata… Well, it’s interesting, but it’s not very tangible and certainly no-one understands it, it’s not visible. So that’s not enough. It’s got to be something that the organisation says: Thank you so much for delivering that. Even if it’s small. That’s okay, it just needs to be tangible.
Gerry:
Your talk about tangible and visible brings me to a question that I had listed for a little bit later down the conversation, but we might as well jump to it now. You talk in the book about the need for teams to focus on results that are, as you say, both tangible and visible.
But one thing that occurred to me is it’s arguable that quality content is neither tangible nor visible, at least to management. Nevertheless most content owners and most intranet teams would probably say it’s very important. Is there a paradox there, and if so, how can you address it?
James:
Well I think that’s a perfect example. Content is clearly important. If the intranet doesn’t deliver accurate information to staff then, well, that’s an issue.
But teams spend a lot of time trying to deliver great content, and to be honest they’ve been trying to do so for the last five or ten years. And I think the way to approach it is to say, let’s re-chunk the piece of work. So instead of trying to go off and pick on all the authors and put in place all these elaborate guidelines and to make life hard, why don’t we tackle it as solving business problems.
So instead of fix all the intranet, why don’t we start with the call centre section? Because then we really can demonstrate that that helps customer service. Or why don’t we just focus on HR, because that’s a major area that people have needs around. And then we can do something really concrete. We can actually bundle together the content, the information architecture, the utility aspect, all into the one project, and still have it a manageable size.
And then at the end of the day, intranet teams need to recognise that not all content needs to be of equal quality. They should care about the important stuff, and manage that well, but a lot of the content on the intranet is used by a small number of people, or infrequently, or it’s more important to be updated frequently than to get the spelling right… So intranet teams need to stop beating themselves up and ultimately burning themselves out trying to solve this content problem in isolation.
Gerry:
I wonder if you have a rule of thumb in regard to how much content is important stuff that needs to be well written and well edited and so on, and how much is the supporting material that has to be there, and it’s used, but it doesn’t need the same care and attention. Do you have any guidelines in that regard, or any feeling for it?
James:
I don’t know that there are any specific guidelines, but it’s not hard to get a sense out of stuff. I mean, if you look at it as levels of importance, at the core of things is your core corporate content – HR, finance, other policies. They need to be right. And ultimately you’d maybe centralise them, or even get them written by professional technical writers to get a really good job. So that’s your core level.
Outside that you’ve then got the information that’s pushed out by business units, that may be used by quite a few people, and that needs to be quite well written. And certainly needs to be findable and well structured.
And then you get out to the stuff that is, I guess, used within smaller areas or updated more frequently, and there I think it’s more important to help staff differentiate between the expected level of quality, rather than trying to get everything right.
So people know… look, let’s say IT project updates. I want to know where the roll-out of an email update is up to. That’s important information, but I know that IT can’t spell, and I don’t care. I just want to know where the project is up to. So maybe it’s more important to give them, say, a blog where they can communicate this stuff, or to give them a little spot on the home page where they can update with some latest key facts than it is to spend two weeks polishing it and not get the information out to people.
Gerry:
You talk in the book about various potential owners of an intranet. And this is… where there’s discussion within an organisation or even outright discord and aggression within an organisation as to who the owners are. Who do you think should own the intranet?
James:
This is probably the single most common question that I get asked at conferences around the globe. And there isn’t one answer, because everyone in the organisation is a stakeholder when it comes to the intranet. And so everyone feels they have something to say about the intranet. Which is great, but tricky.
If you look at it, I think there can be quite a few different owners. Communications teams are common owners, IT, maybe HR or business areas, knowledge management type groups. Each of them has strengths and weaknesses.
Communications will obviously be great at the communication side of things, but may be less experienced around the IT. And maybe less interested in other content.
IT, in your stereotyped IT, great at the platform, great at the tools and the business solutions, but maybe doesn’t want to worry about the content.
At the end of the day, though, I think any of these groups can prosper, and the rule I would say is this: I don’t care who owns the intranet, as long as they have the right skills and focus, and the right support from their management.
And that I think is the tricky thing, but I think it’s up to intranet teams to say: Am I really the owner? Do I own it all, or am I only interested in one little slice? And if it’s only just the one slice, I don’t think that’s owning the intranet.
So I think intranet teams need to look across all of it – not do it all, if you’re a comms team you’re not going to do the IT thing, you’re going to need a relationship with that, but your intranet strategy needs to touch upon all of those elements. And I think that’s possible for any of those groups.
Gerry:
When you talk about intranet teams, you also discuss in the book… you’ve got suggestions for how intranet teams should divide their time. Can you tell us a little bit about that?
James:
Yeah, it’s interesting, talking with intranet teams to say: Where are you spending your time? And after a little bit of chatting it becomes apparent that, say, 80% or 90% of time is spent maintaining the current site. And the lack of time is the single biggest point of pain for intranet teams the world over.
What we would say, and maybe it’s easy for us to say, is that only 30% of time should be spent maintaining the current site. 30% of the time should then be spent on relationships. So that’s relationships with end users but particularly with stakeholders and managers. And what we’ve observed is the most successful intranet teams are people people. They’re great at building relationships, maybe ahead of everything else.
And then 40% of time is devoted to new projects. Whether that’s improving some content, whether that’s adding photos to the staff directory or making search work better, or bigger things. It doesn’t really matter, but it’s about pushing the intranet forward.
And that’s where intranet teams add their value, that’s where they demonstrate their value, that’s where they can get funding, and ultimately that’s where they build momentum.
Now that 30/30/40 split… not easy for teams to get, but again this is where I think intranet teams need to look long and hard at how much they get caught up in the details, and maybe say is that where we’re adding the most value at the end of the day? And hopefully the answer is “not”. Hopefully they’re adding more value, or can add more value, playing a more strategic role, playing more of an enabler role in the organisation, rather than just being a custodian of a huge and sprawling intranet site.
Gerry:
Would that apply in a one-person intranet team or in, God forbid, you know, one-and-a-half full-time equivalents or whatever these strange dividers are that we come across around the place?
James:
Yeah, I think where there is a single-person intranet team or even, as you say part of a person, this becomes even more important. You have to tackle it in different ways. If you’ve got a team of three or five or, God forbid, ten, then it’s easy. You just allocate different people to do different roles.
When you’re a single person, obviously the buck stops there. There I think you need to be incredibly disciplined about how time is spent.
And we’ve seen some great strategies. It might be that, say, every Friday is set aside for project work. Or maybe updates are only done on Tuesdays and Wednesdays. Or other strategies where we’ve seen intranet individuals divide up their day into four chunks, and people can book them. So like:
And this is where I think time management – and project management but certainly time management – is critical for intranet teams of any size, but as an individual as you say, if you’re not disciplined you’re under water from the start of Monday and you never surface by the end of the week, and that’s a hard job.
Gerry:
… Related somewhat to that, you caution about the limitations of workflow, in terms of, I guess, people trying to be efficient in the way they manage the whole content specification, development, editing and so on. But you sort of caution in the book about being a little bit… I guess you flag that workflow is a limited concept, or a limited tool set. Can you tell us a little bit about that?
James:
Yeah, a lot of the work we do alongside intranets is to help people select content management systems. And that’s a really interesting process. And certainly coming into CMS selection projects, organisations have some really high expectations about workflow, the idea about making the publishing process manageable, improving quality and all these sorts of things.
The reality is though, that we see, is that one of the widely known secrets in the content management industry is that workflow doesn’t work. Now, why is that? Every CMS product has it, so surely it must do something.
And if you keep it simple – one, maybe two steps – get a central team to check stuff before it goes up, that’s great. But the problem with workflow is that you have to set it up in advance, and it’s rigid, whereas the reality in organisations is that the current manual processes are incredibly context-specific. Depending on what you’re publishing, you’ll have completely different workflows. It will depend on who you are, where you sit in the organisation, where in the site you’re publishing to, what kind of content, what kind of sensitivities, legal implications, technical aspects, or just the fact that if Bob doesn’t have a look at this stuff before it goes up, he’s going to come and kick your ass afterwards.
Now, as humans, great, we’ve got unlimited flexibility, and we can email around these various people and bring it together. But workflow doesn’t have any of that flexibility. And in the end, it too easily becomes a bottleneck. And if it’s hard to publish to the intranet, and with intranet being a hobby for most people – they’re given the task but no extra time, no extra training – that’s a hurdle that is too much to get over.
And so we, in the aim to get a beautiful perfect intranet, we just don’t get any updates at all. And that’s hardly the outcome we were looking for.
So use it, sparingly, again maybe targeting more important content, but at the end of the day I think it’s more important for the intranet to be updated frequently and maybe as a result most of the intranet maybe shouldn’t have workflow at all.
Gerry:
I was amused in the book, James, to see your list of banned terms. [Laughs.] Tell us few of them.
James:
We’ve touched upon already that intranet teams have a hard job and can very easily burn out, and the way we see is the quickest route to do this is to play or attempt to play gatekeeper role. This is where intranet teams are the people who say No.
The problem is, no-one reports to the intranet team. They actually don’t have any direct power to set these things in place. And that leads to our list of banned words, like “enforcement” and “compliance” and “standards” and “auditing”. All of these sorts of words, because they create a cultural problem between the intranet team, the authors, and the rest of the business. And ultimately it just means that if the intranet team makes it too hard to get stuff up onto the site, people will work around that.
And so this is where the intranet team needs to be very careful about the language it uses, to look to instead engage with the organisation, maybe not say Yes to everything but to say Well, instead of doing that a better solution is this.
Now you’re not going to win every situation, but taking that approach is ultimately going to be much more satisfying for intranet teams, and is going to get better results. And as I’ve said in the past, you get the right content when the right people are doing the right things. And they’re both people issues. Standards are great, but we need to work with the people, and the better informed they are and the better supported they are, then they’ll do a better job, and the less the intranet team has to use some of these banned words.
Gerry:
To shift gears slightly, James, a lot of people are very excited about collaborative tools, and we see some organisations who seem hell-bent on making wikis for everything, and you would have lots of examples, I’m sure, of organisations who have wiki-ised things to the stage that nobody at all can use them. What’s your take on the whole collaboration within the intranet situation?
James:
We talk about intranets having four fundamental purposes. So, content, communication, collaboration, and the last is activity, which is your utility, the intranet as a place for doing things, not just for reading things.
So, content, communication, collaboration and activity – all four of those are useful, and there should be some balance across those. Now historically, intranets were just content and communication. So repositories for stuff, and you know, blah, blah, internal news.
That’s not enough. So we do need to do a lot more about collaboration. The challenge, though, is to fit it in alongside existing tools. Wikis are not going to change the fabric of the universe. Maintaining content and getting good user experience is just as important whether you’ve got a wiki or a content management system-based intranet. So it’s about sitting things alongside. So you have a core intranet with the publishing content, and then collaboration is often an inwards-facing thing. It’s about helping project teams, it’s about helping business units communication and collaborate within their area.
And we find that’s often a useful way for people to think about it. So a business area might have a shopfront where they offer key resources for the rest of the organisation, and then they have a back office where the collaboration tools sit in helping them do the day-to-day work.
And that way we get the benefits, but hopefully we avoid the risks. And certainly what we’ve seen is the unmanaged spread of collaboration tools can be anti knowledge sharing. It can make the capture of information, the sharing of information, dramatically worse. Because now we take one average-quality intranet and we supplement it or even replace it with a thousand little team sites.
And then life gets very hard very quickly. [Laughs.]
Gerry:
We see a lot of organisations who seem blissfully unaware of the existence of mobile phones. I’m not totally up with what the stats are but clearly many, many people are accessing data on mobile devices. Now I know that some organisations embrace that, and embrace even alternative access like IVR access to staff directories for example. What should intranet teams and organisations be thinking about in terms of mobile usage of the intranet? Do you have any pointers?
James:
Yeah, this is a really interesting thing. It’s been an area that we’ve been hoping to see some really solid progress on over the last year or so, but safe to say that this is happening a lot slower than a number of us would like.
As you say, a lot of staff now have mobile devices, and they’re out in the field or they’re going from meeting to meeting. These devices are brilliant. Five years ago mobile phones were an absolute pain to deliver stuff to, but there’s been a sea-change around this, whether it’s your Blackberries or your iPhones or other similar things, these are dramatically better devices, so we should be delivering to these.
Now in this year’s intranet innovation awards we’ve actually had some really good entries around this, and that I think is really encouraging, whether it’s even the simple stuff around providing an intranet-backed mechanism to deliver SMS messages out to staff in the field… this is really cheap, easy stuff to do, and we can go a lot further than that, accessing news on mobile devices, but ultimately to provide staff, particularly in the field, with applications that allow them to seamlessly interact with core corporate systems. Whether this is in hospitals, whether this is in local councils, whether this is in field staff in government agencies, or staff going out to aged care centres, there are a thousand opportunities to do this stuff.
And I’m really hoping to see over the coming year that people realise that the intranet, or whatever you want to call it, is more than just the desktop. It can actually get out past the PC, it can get into the hands of people. And then I think we’ll really start to see usage and value skyrocket, once that starts to happen.
Gerry:
Yes, although I can hear in my mind people saying Oh God, something else to worry about.
James:
[Laughs.] Well, look, this is the UX podcast, so I think it would be remiss not to highlight that user experience is going to be critical around this. And the user experience of mobile devices is a field within itself, and people would be foolish to wade into this without saying that what works on a lovely 17 or 21-inch flat-screen monitor is not going to automatically work on the handheld device. And it’s more than just wrapping your existing intranet or existing website with some new CSS and hoping for the best, ’cause that’s not going to cut it.
Gerry:
Well, my bank, James – I won’t name it – but when I type in its URL on my iPhone it redirects me to an iPhone version of the site which does not contain a link to internet banking.
James:
[Laughs.] Yeah, and certainly in the work that we’re doing around content management systems, this whole idea about mobile delivery is top of people’s list, but it’s interesting how few people are able to articulate what exactly that means, and what exactly they’d want to deliver to it. And I’d agree with you, and highlighted many times, that maybe what people want is not your corporate website or corporate intranet with 500 or 5,000 pages of content. Maybe it’s the key tasks like internet banking that people want. And that’s where they add the value, but that’s maybe a little bit harder again than just CSS and a little bit of browser detection.
Gerry:
Well, the book “What Every Intranet Team Should Know” I thoroughly recommend to anybody involved in intranets. It’s one of those nice little books that can be read by management to get an understanding of, I guess the capabilities and the scope of what they need to think about, and also by practitioners of all sorts involved in actually delivering content on the intranet. It’s a great little book and congratulations. I enjoyed it thoroughly and I don’t often enjoy technical books thoroughly, or books in the field, but I enjoyed this one very much.
James Robertson, thanks for talking with me today on the User Experience podcast.
James:
Thank you very much, Gerry. Always a pleasure.
Published: November 2009
We make verbatim transcripts of the User Experience podcast. We then edit the transcripts to remove speech-specific elements that interfere with meaning in print (primarily space-fillers such as “you know…”, “um…”).