Case Study: Intranets, Usability, and Value, by Jeffrey Veen

Case Study: Intranets, Usability, and Value

I've long been a fan of the case studies in the Harvard Business Review. Typically, the publication sets out a scenario, then asks other to comment on how they would approach the fictional problem. And I've also always wondered why nobody has applied that model to the problems we face day to day on the Web.
To remedy that, I wrote up the fairly typical business case below. Then, I asked Scott Hirsch to react to the scenario. He's an MBA from the Haas School of Business and co-author of the Adaptive Path report "Leveraging Business Value: How ROI Changes User Experience." His comments follow, and be sure to add yours in the comments.

Tracy Jens is the Product Manager for intranet applications at GMS Corporation, a financial services company with 85,000 employees in dozens of geographically disperse offices. The company's intranet is maintained and developed largely by the human resources department, to whom Tracy reports.

Recently, she was asked to a meeting by René Phillips, the Director of corporate HR for GMS. "I can't believe how much I'm spending on that call center," René told Tracy. "Our employees call up for the simplest stuff -- finding a form to download, resetting their password, enrolling in the new online payroll system. If you could do something to reduce the volume of calls by even 15 percent, it would save us a million bucks next year."

Tracy's first stop is Bruce Margo, the director of IT. She tells him about the conversation with René, and asks for his opinion. "Well," he responds, "we've got that license to Interwoven that we're not using, and I could free up four guys to help you build something. I'll give you eight weeks of their time, but we'll need a really detailed functional specification of what you'll need before they can start."

Next, Tracy visits a few departments within the company. Over and over, she sees employees coping with the existing intranet by routing around the problem entirely. Most departments have their own server running a variety of software packages to help them get their work done. Some have installed wikis, others use Front Page to update their department home page, and still others simply rely on emailing documents back and forth.

"Oh sure," says Bruce back at headquarters, "We sent a spider around once and uncovered something like 1600 servers inside the firewall. What a mess."

As Tracy sits down to write a project plan, she considers the problems the company is facing: Almost all the information employees are looking for exists somewhere, but nobody can find anything. She could try to solve this problem with a content management system, but will employees adopt the new tools? And will departments want to give up the control they have over the local servers they have? And how will she show measurable change if she does implement new systems? After all, she wants credit for saving HR all that money at the call center.

Scott responds:

Operation GMS Freedom

Tracy is in a good position. Although she faces a wicked problem that touches most of the GMS organization, the business value of effectively solving this problem is considerable and would quickly elevate her to superstar status. However, there are risks of failure, particularly from internal sabotage and resistance against any proposed solution that is not as flexible or useful as the many workarounds that departments have built themselves. Her plan of attack in the "war on error" should be three-pronged, focusing on coalition building, intelligence gathering, and scenario planning (sound familiar? -- this metaphor has really gotten away from me).

First, she needs to do some coalition-building. Most of the problems she describes are organizational, not technological, and she should avoid the alluring but simplistic view that finding the "right" CMS solution will make all her problems go away. This stratregy is as problemmatic as finding so many weapons of mass destruction. Building a coalition of stakeholders from HR, IT, busniess units, and a few geos will go a long way to avoiding a post-project insurgency -- she can't declare "mission accomplished" after the technical problems are solved. There is a lot of organizational work that will need to be done as well..

Second, Tracy should use her coalition to gather intelligence from the field. In particular, stakeholders should identify common ground: pieces of the intranet that need to work well for everyone. Her call center can be a great source of intelligence to identify common ground. Ask them: what are the most common questions, information needs, and technical problems? Agreement on common ground is the beginning of defining the business requirements for what the CMS can solve. However, she also needs to examine the specific knowledge management solutions that some departments have built for themsleves -- the key questions here will be: in what situations does local control offer a more effective way to solve problems? what are some lessons that GMS can learn globally from these local experiments?

Finally, Tracy's challenge is to scope out a plan for not only winning the war, but also winning the peace. All too often an intranet redesign fails because users don't adopt the new mechanisms for creating and distributing content -- this can be mitigated by choosing early projects that focus on commonly recognized quick wins. Her plan should have a long-term vision, but it should be implemented in small increments that instill a sense of confidence and value among users throughout the redesign. Small increments allow for course corrections toward the long-term vision.

On the question of measuring value, the case answers its own question. Intranets are supposed to foster efficiency and improve productivity -- the highest level metric to demonstrate productive user behavior is call center utilization. However, there is a stickier value question: the determination of whether or not Interwoven is the right tool to achieve the long-term vision. Since the license has already been purchased, there will be pressure to stay the course and use Interwoven as the platform for the redesign. However, it is important to recognize that this investment is a sunk cost. Throughout this process, Tracy and her coalition need to be willing to abandon out-dated models of thinking that are not working. If she's willing to take on these challenges, Tracy can kerry GMS to victory.

This entry was written by Jeffrey Veen and posted 13 November 2004 at 3:53 PM. It was filed under Technology.

Comments

1. On 13 November 2004 at 4:10 PM Jeffrey Veen wrote:

There are a number of common assumptions in this case study and Scott's response -- things I see all the time when consulting. For example, the manager of IT immediately assumed the problem was a technological one. It was so clear to him that he flat out offered resources to help "build something" for Tracy.

Second -- and all too frequent -- is that Tracy even knows what the problem is. Too often, when approaching large organizational quagmires like this, those responsible jump in with the assumption that they even know what the problem is. In this case, the call center expenses can be mitigated with Interwoven. But that's a clear case of the tail wagging the dog. Do we know why people are calling for help? Is that really so expensive? Do the statistics match Tracy's findings from field observations and stakeholder research? These are all assumptions that must be verified before she can get started.

Since I'm of such a short attention span, I'd like look for the rapid consensus-building mini-projects Scott mentioned. I'd get a report of the top ten most frequent issues at the call center, match it with a report from a year ago (if available), and note any interesting differences. Then I'd see which of those top ten issues could be solved the easiest, and prioritize my way down.

Those quick wins could be tackled along with some company-wide projects. Instead of forcing everyone into Interwoven, maybe a vocabulary of metadata values would be more helpful, especially if value was associated with it. That is, keep using Movable Type or PMWiki, but try these keywords when you post something. That way you'll show up in the corporate internal search engine and get more exposure for your work. Slowly, consistency will emerge from the multitude of systems, avoiding switching costs and any apparent power grab.

That's the way I like to work, anyway...

2. On 15 November 2004 at 2:06 PM Mike wrote:

In bringing together her coalition, Tracy should pay particular attention to the people who maintain those 1,600 loose servers. The odds are that many of them have an emotional stake in their little patch of weeds, and will seek to derail any changes they perceive as threatening their domain. Much better to head them off and make them feel like part of the solution.

3. On 15 November 2004 at 5:32 PM Stephan H. Wissel wrote:

The call center costs look very much like symptoms of a much bigger problem below. Also the fact, that IT needed to scan for servers instead of looking them up in their asset database would make me suspicious.
Besides mini-projects and alliance building I would suggest to get to the bottom why services became so fragmented.
One first thesis (that MUST be a thesis that can be falsified, not a conclusion) would be: users/departments flow the path of least resistance. Was it easier running your own server, than to use IT department's services?
This would be my starting point: revamp IT department's service offerings and attitute. If users/departments find wikis and blogs useful, make them part of the intranet strategy (but that eventually would be a technological fix to an organisational problem ).
Since the Intranet makeover has consequences through the whole enterprise it would be advisable to get a board level sponsor for this exercise. To get there a closer look in the potential might help: Call center costs are probably only the tip of the iceberg.
At the end of the exercise GMS should end up with a Intranet where technology is owned by IT, look & feel by corporate communications and content by the users. However caveat: if it ends up in a power struggle and users feel rather bullied than empowered it's not worth the effort, so the service attitute of IT might be critical. To get there: investigate - improve, communicate - understand , motivate - execute!
My 2c
:-) stw

4. On 29 November 2004 at 5:58 PM Mitch Pirtle wrote:

I agree with the abovementioned points, especially regarding the need for real facts that backup the initial request. What exactly is the target again?

But before any of this happens, it is time to discover how there could be so many rogue webservers running within the company -- not enough control, too few IT resources available at a local level, poor security standards, many language complications -- this should not be a problem for a large enterprise, whom also happens to be the only type of organization with the resources (and needs) to deploy some type of asset/systems management environment.

These issues will keep anything Tracy provides from being used as a defacto standard, regardless of politics, budgets and so on.

In my experience organizations of this size with similar problems suffer from a lack of infrastructure and cannot adequately control their internal systems. Couple that with business units that need tools NOW, and you end up with thousands of rogue webservers at your organization.

Once this issue is addressed, you can talk about providing a central application that provides the features that everyone is needing to get their jobs done. If you take everyone's pet applications away, you better be prepared to deploy something that does much, much more.

Remember that for the individual business units, this needs to appear to be a win! Make absolutely sure that you are aware of their individual requirements, and can provide something that delivers - or this will be a political disaster for the company.

Finally, if this application will be supported by IT, you have to get them to own that responsibility. You also will need to verify that they have the resources available to get things rolling in the turbulent beginning. Although this is usually the cause for locally deployed rogue applications (not enough IT support), it can be turned into an advantage (plenty of centralized IT support, no more administration headaches).

There is a way to turn this around, but you have to remove the opportunity for such a chaotic structure first.

5. On 2 December 2004 at 7:08 PM Merolyn wrote:

As a 'information' consultant I often get contracts to redesign intranets. Many are in their first stages and are easy to build up with a robust information architecture - which, along with senior management support, is more important than the technology selections. However, one intranet I am working on at the moment is very like the scenario above but with a smaller global company.

The first thing I looked for in the solutions in the above comments was some kind of systematic or 'scientific' way of proceeding. (Tracey wants to show she has made a difference and have some evidence for the decisions she is making?) There is none as far as I can see, so here is mine.

With the support of the CEO and senior management, who all agreed the present intranet was a mess, inefficient, inaccessable, incomplete etc, I first did a complete expert review using known principles of intranet/internet design.

Then I did a series of reviews with the key stakeholders, including those who had 'renegade' sites. I asked what they wanted to achieve with the intranet (their vision, if you like), what information they produced, what of that information did they need published for their staff or others, what information did their staff need to work efficiently, what form was the information in now, who owned it etc etc.

Then I met a set of representative user focus groups and asked them the same questions:
what did they want from the intranet?

what information did they use?

what form/format did they need it in?

how did they search for it?

where did they expect to find it? and many more questions.

Then I built (on paper) an information architecture that I thought answered all these concerns and tested it (on paper) with other typical user groups.

Then I wrote a report to justify the proposed information architecture, the IT solutions, the proposed graphic 'look and feel', and a schedule for systematic building and testing of a prototype.

I listened carefully to what the company wanted/needed - both providers and users, overt and between the lines needs.

It took three weeks to do this in detail and the report was accepted unanimously by the committee and business sponsor. I am now going in to do the actual pulling apart and rebuilding. I expect to consult with and 'keep sweet' the providers of information and persuade them that with my design their information will be kept safe and they still have some input as they will be trained on how to present and publish it for the new version intranet.

A CMS was reviewed and rejected as too time consuming - even though it is the buzz word here in Australia right now. We are taking a far simpler approach with most information.

There are many 'Controlled documents' that are being separately stored and handled in a Windchill Technology system but accessed through the intranet. (It is an engineering/biotech based company.)

Taking a systematic user-centred approach not only gives the users what they need, pleasing both the users (they have been listened to) and the management (because of increased efficiency), but it provides a lot of ammunition for unpopular decisions. For example, my HR manager (also a Senior VP) wanted her ESS and jobs/careers section on the front page. Not only did the users show no interest in this solution, but they wanted a 'global' solution for everyone, and HR is regional (Europe, US, Aust etc), not global. So the ESS and jobs sections went two levels down in a regionally segmented menu.
So, my advice to Tracey - invest in systematic, user centred research before you do anything else.

You need lots of evidence for your decisions. Your attitude is that you are going in to help - not to destroy. Then with some luck and expertise in communicating, most people are happy.