Building Intranets that Matter

In: Articles

By Shiv Singh

Published on January 15, 2003

Introduction

2002 was declared “the year of the intranet¹,” the year organizations recognized that the increased efficiencies intranets bring—time saved, knowledge shared, and communication standardized—are crucial for meeting business objectives. Designing, developing, and deploying an intranet, however, can be expensive, time-consuming, and organizationally tricky. Complicating factors include coordinating budgets across regional boundaries; prioritizing features; addressing user requests; collaborating with other departments to produce and deploy content; and leading interdisciplinary teams of site administrators, information architects, content writers, visual designers, technical architects, and interface developers.

Despite best intentions, intranets often fail to deliver on the value they promise. Why? Companies take an “if we build it they will come” approach. Too often, intended users don’t come. And if people don’t use the intranet, it will never deliver value.

To drive user intranet adoption, Razorfish employs a user-centered approach to Web design and development. Razorfish’s best practices are drawn from seven years of experience deploying effective intranets that drive user adoption and value for the technology investment. In particular, four best practices set the stage for intranet user adoption:

• Make it matter—to both the business and individual users
• Solve someone’s problem well
• Engage users wisely
• Cultivate multi-disciplinary collaboration

Best Practice #1: Make it matter—to both the business and individual users

Ensure clear benefit to the business

The first question to ask is, “What is the relative efficiency of building an intranet in the first place?” Will the cost savings generated by the intranet’s use be significant enough to justify its development and maintenance? Or can the same business tasks be accomplished more cost-effectively using current processes? Just because the technology exists doesn’t always mean it’s prudent to use it.

Working with your project sponsor, determine up front what your intranet effort needs to accomplish. Sample goals might include:

• Reducing costs by making common forms and tasks available centrally and online (where appropriate)
• Providing a central repository for communication from the corporate office to all employees
• Encouraging better information-sharing across the organization

Establish success metrics for each goal. For example, how will cost reduction be measured to calculate intranet ROI? Will corporate information on the intranet replace existing information channels, such as paper newsletters or company-wide memoranda? How will information-sharing be quantified? Sitting down with the project’s sponsor will help set realistic expectations, identifying which problems the intranet can—and cannot—solve.

Now that you’ve decided on the goals of your intranet, how do you form a plan for getting there?

Too often, an intranet’s design is shaped by questions like, “Will the users like it?” Remember that an intranet is a business productivity tool. The hallmark of an effective intranet is the increased efficiency of the employees who use it, and not individual user satisfaction. In the planning stages, users sometimes report strong likes or dislikes for design or features. Careful requirements gathering can make sure the intranet will bring the increased efficiency that strongly correlates with user satisfaction. Balance is essential. If individual users don’t find the intranet easy to use, they won’t use it—and the benefits won’t be realized.

Ensure clear benefit to the individuals, and justify the expense

In order to be adopted, the intranet has to meet the demonstrated needs of targeted individual users. Identify who those target users are and the functionality they require by taking the following steps:

• Segment your user community into groups, defined by their similar needs.
• List the business objectives for each user group.
• Outline the actual tasks that each user group performs in order to achieve those objectives.
• Identify tasks that can potentially be completed using an intranet.
• Compare the amount of time the tasks would take using the intranet, versus other current business processes.
• Measure intranet versus current process task-completion efficiencies, by giving greater emphasis to user groups responsible for more important business objectives. For example, when we completed this exercise at a large biotechnology company, we discovered that their senior managers had such distinct needs that it was best to develop a dedicated intranet for them alone.
• Consider also in your final analysis the ancillary benefits of using the intranet. Examples might include simplifying the content distribution process, or eliminating redundancy in human resources documentation.

Try a real-life example of a common user task: filing expense reports. Steps involved in filing expense reports offline might include:

• Entering each expense item into a spreadsheet.
• Delivering, in person or via office mail, the spreadsheet to a manager for approval.
• Delivering, in person or via office mail, the approved copy to a controller.
• A week later, verifying that the finance department has approved the expense report.

Estimate how much time it would take for a user to perform this task using the current process. Now imagine how this task could be accomplished via an intranet:

• Expenses are automatically imported from a corporate credit card account into an intranet-based reporting program.
• User verifies report details and adds non-credit card expenses via a web interface.
• The report is automatically sent to the manager’s workspace for approval.
• The manager views and approves the expense report on her screen.
• Upon approval, the expense report is electronically sent to the finance department.
• The user checks his expense report’s approval status, via his workspace, at any given time.

On the surface, automating expense reports seems extremely efficient. But, by digging deeper, you may discover that only a few dozen expense reports are being filed each week. You may also discover that salespeople file most of the expense reports; senior managers travel less frequently and have their assistants file their reports for them.

Thus, you might conclude that the benefits of automating the expense report process do not cover its development cost. Too few expense reports are being filed each month, and the extra time to file them is not great enough to warrant automation.

Automating other, more universal processes might show clear benefit. A similar analysis around a process required for all employees, such as filling in mandatory W4 forms, might yield favorable results for intranet delivery.

In other words, think about which user groups would save the most time by using an intranet, and how much time that would actually be. Would those users work more efficiently because of an intranet? Would they make better business decisions? Simple user satisfaction is less meaningful than tangible, measurable economic benefits to the organization.

Best Practice #2: Solve someone’s problem well

When you deploy an intranet, it’s easy to misjudge which features and functionality to phase in first. Easy-to-implement, quick-hit features (e.g., announcements and local weather modules) are often rolled out first, while the home-run features (e.g., centralized access to crucial marketing materials or a worldwide employee directory) are put off until later. To drive adoption, your intranet should start by solving at least one constituency’s problem well.

Your intranet deployment is more than just a series of easy-to-implement quick hits. If that’s all you strive for, then you run the risk of losing your users or garnering contempt for your sweat-ridden intranet initiatives. Nothing is wrong with quick-hit features, but there is much wrong with phasing in features and functionality based on their ease of implementation alone. Instead, release intranet features and functionality determined by user needs, as balanced against technical, operational, and functional complexity. Think about which features your users require the most and whether your intranet’s feature set will meet their needs. Otherwise, you could alienate user groups that have no quick-hit needs.

Phase in support for different user groups at different times. For instance, before introducing a user group to the intranet, determine the minimum number of their business tasks that need to be supported online. Supporting these tasks via the intranet will generate immediate user satisfaction and efficiency gains. After all, no user is interested in an intranet with 200 quick hits and five deep features, when only two features in total are relevant.

Imagine that one of your primary user groups (e.g., field sales force) has five key business tasks that can be accomplished via the intranet. These tasks could include:

• Viewing up-to-date pricing and discount information
• Researching competitor products
• Reviewing client purchases by studying archived sales data
• Sending daily sales totals to a corporate office
• Reviewing quarterly targets and bonus plans

Imagine that you must choose among building functionality to support some of these tasks and only for the sales force; building features that deliver industry and company news to the whole organization; publishing business-unit profitability numbers to senior managers; or upgrading a company events calendar.

We have already discussed why the wrong decision is to implement the easiest features first, and roll out the more expensive, time-consuming functionality later. A better strategy would be to deploy the easiest-to-implement features that benefit the greatest number of users—in this case, the calendar, industry and company news, and possibly researching competitor products.

Making the best choice might involve some radically different thinking. What about rolling out the intranet to the field sales force only, and only after at least three of their key tasks can be supported online?

How will you know when to make an out-of-the-box decision? Keep your eyes open and your mind working! Suppose you find out that automating the sales force’s business tasks dramatically affects the company’s bottom line, in terms of time saved. Then, after factoring in the cost of intranet promotion and training for the entire organization, you also determine that implementing other intranet features will not result in significant organizational savings. A good understanding of your users, their needs, and your limitations can yield dramatic results.

Choose a group of users you can please well early in the rollout, and target those users with features that correspond to their requirements. Use feedback and learning from early users when rolling out the intranet to other constituencies.

Best Practice #3: Engage users wisely

As an intranet manager, you have one key advantage over your public Web site counterparts—your users are your co-workers. You can observe them, talk with them, and understand their needs first-hand. Use this opportunity to your advantage and get users involved in the process.

For example, consider integrating your users into your design process via interviews, observations, paper or low-fidelity prototype evaluations, or other participatory tools. In cases where your users are geographically dispersed, use local help desk and IT support staff to solicit user participation and feedback. The help desk and IT support staff will act as ambassadors for your intranet initiative, so the sooner you garner their support the better. Moreover, they often also have existing relationships with users that can be leveraged.

In general, involving users in the design process is a productive experience for all involved. Yet inadvertent risks and challenges may crop up when your users begin to have a say in their intranet’s creation. Here are some suggestions for overcoming common obstacles.

Guard against powerful business stakeholders dictating the intranet’s architecture or design.

It’s vital that you establish roles and decision-making criteria up front. Otherwise, users who are also business stakeholders may be particularly tough to work with, because they might feel directly responsible for the project’s success. For example, your primary business stakeholder might demand that aggregate sales data for all products appear on every senior manager’s home page.

This might sound like a good idea; but in some instances, senior managers might prefer to get this data pushed to them via email in Microsoft Excel format. On the intranet home page, these same senior managers might prefer to see industry news. Where possible, research intranet users’ actual needs and usage patterns, and provide these to the business stakeholders. Furthermore, avoid letting a few individual users—particularly powerful business stakeholders who are not part of your user base—dictate intranet architecture and design. Remind these stakeholders that the success of the company intranet is dependent upon meeting the needs of a large user population, one with many diverse and specific needs.

Engage users constructively, in order to make the most of their limited time.

An organization that needs an intranet is a busy one. Your co-workers simply may not have the time to sit down with you and offer input. If you do reach them, use their time judiciously; come to the meetings with users having done some prior analysis roles and, where possible, give them something to react to. Be sure to highlight the benefits of their involvement. Show your users how good user-centric intranet design can translate into increased productivity. Listen carefully to their input and be flexible enough to meet their requests, when appropriate. Caveat: Don’t solicit user feedback if it is too late in the design process to accommodate it. You’ll just be wasting their time and yours.

Watch for users feeling disenfranchised or adversarial because they believe their requirements are not being met.

Treat your user community with care. More users involved in the design process means having more complainers among them. Keep your users apprised of the intranet’s development state. Make them aware of trade-offs or design limitations, and (as appropriate) different constituents’ needs. Always let users know how their feedback might be used, and suggest its end-result.

Certainly, user participation can affect your timeline and budget, but the benefits outweigh the costs. User involvement results in an intranet that is more relevant and cost effective in the long term. In fact, the rule of thumb in some usability-conscious organizations is that the cost-benefit ratio for usability is $1: $10-$100. This means that for every dollar spent implementing usability techniques, the organization will realize a benefit between $10 and $100 down the road.

Best Practice #4: Cultivate multi-disciplinary collaboration

Developing and deploying an intranet requires several different disciplines and skill sets. Multi-disciplinary teams often have a hard time collaborating successfully. Good information architects, visual designers, functional analysts, and technologists are all trained to think in certain ways, and often are in conflict with one another. For example, implementing strong information architecture may require compromising certain technology best practices, or vice versa. Will the technologist or information architect want to do this? Can they ever compromise?

Foster collaboration in your team to find immediate and efficient solutions to these issues. Otherwise, the closer you get to your intranet’s launch, the harder it will be for the different skill sets on your team to work together—lowering productivity and perhaps resulting in missed launch dates. Below are some pointers to help your teams collaborate better.

Define clear roles and responsibilities early on in the project.

Understand where roles overlap. Map out who should lead in the overlapping areas. Critically assess your team’s skill sets at the start of the project. If you believe that your existing team is not strong enough, bring in new members early rather than later. In other words, don’t wait for team members to drop the ball before bringing in extra help.

Align milestones and deliverables.

Assign joint deliverables to cross-functional teams in order to foster greater collaboration. For example, pair up designers and developers to jointly deliver a functional specification or wireframes. The project will flounder if it’s based on technology no one wants to use; conversely, it does no good to design experiences that are complex and costly to build and maintain. Assigning joint deliverables can help team members from different disciplines recognize the importance of each other’s requirements.

Make sure team members are sharing enough knowledge.

Don’t allow your team members to use information as a source of power. Be in tune with your project’s inner workings and watch the flow of information between different team members. Where possible, create a Web-based central repository for project assets to reside. Every team member should be a source of knowledge for you, not just a few people. Figure out which information each team member needs, where to get it, and whether each member is getting it at all. Building in time for communication—including a brief daily “scrum” to make sure all participants are operating from the same set of assumptions—can avoid knowledge roadblocks.

Encourage team members to educate one another on their skill sets and deliverables.

Make sure that team members are always communicating their own expectations, and managing one another’s. For example, if you are implementing a software package, each team member—regardless of his or her skill set—should understand its capabilities. Help the team set up processes for sharing their documentation. Schedule regular, short meetings for contributors to present and summarize deliverables. Emphasize that expertise is defined by the educated perspective that a person brings to a discussion, and not simply by owning information.

Conclusion

Designing and managing an intranet is not easy. Most intranets usually require months of planning and development, as well as large, fluid, multi-disciplinary teams. But by staying close to your users, focusing on creating measurable, precise solutions, building harmonious relationships with your vendors, determining how best to serve which user needs, and creating strong collaborative bonds, you will be building the foundations for a successful intranet launch.

Footnotes

[1] Internet Design Annual 2002: The Ten Best Intranets of the Year. Kara Pernice Coyne, Candice Goodwin, and Jakob Nielsen. September 2002.
Back to content

Related Topics: Intranets, Knowledge Management