Practical Strategies for Creating a Successful Intranet

“As an intranet designer, you have one key advantage over your web design counterparts: your users are your coworkers.”Designing, developing, and deploying an intranet can be expensive, time-consuming and organizationally tricky. Complicating factors include: supervising the budget; 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 developers. Nevertheless, certain strategies, when carefully executed, can simplify designing and managing your intranet.

The strategies discussed in this article are drawn from Razorfish’s seven years of experience leading intranet projects. Please note, however, that this article’s primary focus is on practical strategies for the design and development of an intranet. The article does not cover related organizational issues that are essential “pre-work” for intranet development, such as executive sponsorship, budget allocation and management, vendor selection, and department-level buy-in. This article instead outlines user-centric strategies designed to build an intranet site that becomes a “living breathing application,” something people really use.

Strategy #1: Your users sit next to you; use that to your advantage, but be careful
As an intranet designer, you have one key advantage over your web design counterparts: your users are your coworkers. You can observe them, talk to them, and understand their needs first-hand. Use this opportunity to your advantage. For example, consider integrating your users into your design process via interviews, card-sorting exercises, paper 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 be happy to serve as ambassadors for your intranet initiative, and the sooner you garner their support the better. They often also have existing relationships with users that can be leveraged.

In most cases, involving users in the design process is a productive experience for all involved. But inadvertent risks and challenges do crop up when your users begin to have a say in their intranet’s creation. These challenges may include the following:

Users want to dictate the intranet’s architecture or content. 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 homepage. This might sound like a good idea. But most senior managers may prefer to get this data in Microsoft Excel format via email. Instead of sales data, these senior managers may prefer to receive industry news on their homepages. Where possible, research intranet users’ actual needs and usage patterns and provide these to the business stakeholders.

In other words, never let a few individual users—particularly powerful business stakeholders 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 larger user population, one with many diverse and specific needs.

Users can’t find time for you. An organization that needs an intranet is a busy one. Your coworkers simply may not have the time to sit down with you and offer input. If you do reach them, use their time carefully, and demonstrate the benefits of their involvement to them. Show your users how good user-centric intranet design can increase their productivity. Listen carefully to their input and be flexible enough to meet their requests when appropriate. 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.

Users feel 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 mean having more complainers or “defectors” among them. Thus, it’s all the more critical that you keep your users apprised on the state of intranet’s development. Make them aware of trade-offs or design limitations, and, where appropriate, of different constituents’ needs. Always let users know how their feedback might be used, and its end result.

User participation can affect your timeline and budget. But the benefits far 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 (Donahue, 1999). This means that for every dollar spent implementing usability techniques, the organization will realize a benefit between $10 and $100 down the road.

Strategy #2: Measure quantifiable results, not just user satisfaction
How do you balance intranet efficiency with user satisfaction, particularly when those two goals may be mutually exclusive? Too often, an intranet’s design is shaped by questions such as, “Do the users like it?” or “Which feature has the highest number of click-throughs?” Remember that an intranet is designed to be a business productivity tool. An intranet’s success should be measured by the increased efficiency of the employees who use it, not solely by individual user satisfaction.

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 offline? Just because the technology exists, doesn’t always mean it’s smart to use it.

These are difficult issues to consider, especially if the intranet project is near and dear to you. But to save yourself trouble later, you must determine whether your intranet will create value in measurable terms. Follow the steps below to more accurately assess your intranet’s potential efficiency.

1. Segment your user community into groups, defined by similar needs.
2. List the business objectives for each user group.
3. Outline the actual tasks that each user group performs in order to achieve those objectives.
4. Identify tasks that can potentially be completed using an intranet.
5. Compare the amount of time the tasks would take using the intranet, versus completing them offline.
6. Tally the scores of online versus offline task completion efficiencies, by giving greater emphasis to user groups responsible for more important business objectives. For example, when we completed this exercise at 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.
7. Account for the behind-the-scenes benefits of using the intranet (e.g., simplifying the content distribution process) in your final analysis.

Now, let’s try a “real-life” example: 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 offline. 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 costs: not enough expense reports are being filed each month, and the extra time to file them is not great enough to warrant automation.

“…for every dollar spent implementing usability techniques, the organization will realize a benefit between $10 and $100 down the road.”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 important than tangible, measurable, economic benefits to the organization.

Strategy #3: Use fewer vendors and take them more seriously
Some large organizations make the mistake of pitting vendors against one another, thinking that healthy competition among consultants results in better service and higher ROI. However, this may be true only if you have a very large budget and lots of time to roll out your intranet—two very unusual situations these days.

The reality is that you lose too much time and money when you use several vendors. Having multiple vendors carries risk; potentially, they could fight over your department budget or could complete redundant or incompatible work.

Vendors put on the defensive will spend their time protecting their business with you, not focusing on delivering solutions. They are also less inclined to take risks with you or their products. Multiple vendors sometimes disagree with each other over responsibilities and recommendations, blame each other for mistakes, and slow down the development process. Watertight roles and responsibilities between vendors will reduce this friction, but will not eliminate it entirely.

A much better tactic is to bring in just one or two strong vendors. Then, hire a full-time employee who has either worked for a vendor in the same field, or has strong experience with similar vendors. This one employee will keep vendors on their toes—saving you money and stress. He or she will also be able to alert you to potential complications.

Keep in mind, though, that this plan will work only if you choose a strong vendor, and hire a highly experienced employee who is given latitude to run the vendor relationship. If you choose well, your vendors will be more delivery-focused, and will appreciate a client stakeholder who understands their work and specific challenges.

Strategy #4: Deploy your features with your users in mind… but you can’t please everyone
When you develop and deploy an intranet, it’s easy to misjudge which features and functionality to deliver first. Easy-to-implement “quick hit” features such as announcements and local weather modules are often rolled out first, while the “home run” features are put off until later.

Your intranet deployment is more than just a series of easy-to-implement quick hits. You run the risk of losing your users this way, or garnering contempt for your sweat-ridden intranet initiatives. Nothing is wrong with quick-hit features, but there is a lot wrong with phasing in features and functionality based on their ease of implementation alone. Instead, release intranet features and functionality determined by user needs. 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 who have no quick-hit needs.

An alternate process is to 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 create immediate user satisfaction and efficiency gains. After all, no user is interested in an intranet with two hundred quick hits and five deep features, when only two features in total are relevant.

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

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

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

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

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

How will you know when to make an unconventional 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.

Trying to please everyone will lead to the deployment of easily rolled-out but unimportant features. Instead, choose a group of users you can please well in the short term, and target those users with features that correspond to their requirements.

Strategy #5: Cultivate multidisciplinary collaboration
Multidisciplinary teams 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?

If possible, 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:

1. Define strict roles and responsibilities early on in the project. Understand where the 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 earlier, rather than later. In other words, don’t wait for team members to drop the ball before bringing in extra help.
2. 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 the inner workings of your project and watch the flow of information between different team members. Every team member should be a source of knowledge for you, not just a few people. Figure out what information each will team member needs, where to get it, and whether they are getting it at all.
3. 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 the workings of the entire package. All should share their documentation. Emphasize that expertise is defined by the educated perspective that a person brings to a discussion, and not simply by owning information.

Multidisciplinary collaboration can contribute in large part to a project’s success. Ensuring good collaboration can be a full-time job in and of itself. As you encourage collaboration, remind your team members that a well-defined team can never collaborate too much.

Conclusion
Designing and managing an intranet is not easy. Most intranets usually require months of planning and development, and large, fluid, multidisciplinary 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.

Donahue, G., Weinschenk, S., Nowicki, J. (1999) “Usability is Good Business,” Compuware Corporation.Shiv Singh is an Experience Lead & Information Architect in the Boston office of Razorfish Inc. He spent the last ten months working on a large multidisciplinary Razorfish team that developed a decision support intranet for a Fortune 1000 company. In the last seven years, Razorfish has built intranets for clients including Avaya, Cisco, Microsoft, Western Union, a large biotechnology company, and a leading professional services firm.