Intranet Challenges

There's one important lesson that to learn that applies brilliantly to our discussion of intranet marketing, and it's one that we should review before we get too far into things: you can't turn lead into gold.

Put simply, if your intranet is a disaster - for whatever reason - there's only so much that even a masterful marketing plan will be able to achieve. There are a wide array of factors that can undermine your intranet even before it is first presented to your employees, and you'll not necessarily be able to compensate for any of these shortcomings prior to launch, if at all, simply through snazzy tag lines or custom mousepads. You may simply have to put on a brave face, work diligently to market the most appealing intranet elements to your audience, and hope for the best.

Note

Of course, marketing is based as much on hard facts and consumer research as it is on the touchy-feely intuition and gut-feelings that guide some marketing groups. This can come in handy, especially in instances where your intranet's initial reveal was less than well received. Via the traditional tools of marketing - customer surveys, collection of feedback, focus groups, etc. - you can collect solid quantitative and qualitative data that will, over time, allow the marketing and intranet development teams to turn their insights into the wants and needs of the company's employees in order to foment improvements to the intranet. Even if your intranet's early days are plagued by some of these problems, all is not lost. Simply apply some of the techniques and tips provided throughout this chapter and you'll stand a good chance of getting your intranet back on the right track.

The Intranet is a Corporate Afterthought

Intranets, just as with extranets or public web sites, are not inexpensive endeavors. Depending on their scope and complexity, it's possible for intranets to consume significant amounts of time, staff, infrastructure, and financial resources.

If your intranet has been launched on someone's seven-year-old desktop computer that can barely boot up without catching fire, there's a storm on the horizon. The same is true if your lead intranet developer is a 15 year-old kid from the local high school - not necessarily a good sign that your managers really give a hoot one way or another that your intranet launches successfully, thrives, or even survives!

Unfortunately, we're not necessarily dealing with a simple lack of sufficient hardware or hands-on support. An even more difficult hurdle can be when senior management doesn't view the intranet as worthy of attention, let alone support. Once that tone is set by the managers, such an attitude can trickle down through the ranks and convince other employees to disregard the intranet as a serious business resource, undermining attempts to elicit content updates or feedback from coworkers, bog down efforts to integrate new functionality that is dependent on a particular team's input, and so on.

Alas, there's no quick-fix or otherwise universal solution for such a problem. The best strategy for addressing such a scenario is to identify the top 2 or 3 features of the intranet that are the most exciting or useful to your audience and market the heck out of them, almost to the point of over-exposure. Over time - with a good bit of hard work and a little luck - you can hopefully build a grassroots movement of sorts that will integrate those core features that you initially presented into their daily lives. From this point, you can step up your efforts to solicit input from your audience (focus groups, message boards, suggestion boxes, etc.) and start the employees actively considering how the intranet can best enhance their productivity, integrating the employees more closely into the development process, and lending the added weight of their collective opinions to your own when negotiating with management for future intranet enhancements.

The Intranet was Not Designed to Satisfy Employee Needs

It's often the case that an intranet will be designed based on artificial technology constraints or will focus on fulfilling management's pet projects, rather than on providing the core content and functionality needed to facilitate cost savings and increase efficiency among the largest number of employees.

For example, companies will often dictate that a strategic business partner's software be used as the platform for the intranet, while the intranet team's protestations of foreseeable usability problems, technology incompatibilities, or their evaluation of the software as simple garbage, fall on deaf ears. Additionally, managers will often manipulate intranet development efforts in order to streamline the operation of their particular fiefdom (marketing, logistics, etc.) at the expense of others, with little regard for the enterprise as a whole. Of course, if you've already read the earlier chapters, you know that working through the proper development stages can assist with creating a plan that *does* address employee needs, and can help you in justifying them up-front. (If you haven't read the earlier chapter stick a bookmark here and go read them!)

It's important to note that it's not always the case that a software solution recommended by management will be garbage. If you're lucky, your company has a strategic business relationship with an organization that produces an excellent web server, or authentication system, or e-collaboration tools. And if your bosses can obtain preferential pricing, or training, or other freebies, so much the better!

However, we'll frequently find that managers force employees to use platforms for internal computing needs based on arrogance, questionable guesstimates of potential efficiencies, etc. AOL-Time Warner, for example, mandated that the employees of ALL companies with the AOL-TW family would - post-merger - be forced to use AOL's proprietary client software as the backbone of their internal electronic communications. Nice idea, save for the fact that AOL's e-mail system was designed for leisure use and did not meet the needs of big business in terms of scalability, functionality, or reliability. After months of frustrating struggles with this new system, many AOL-TW business units staged an internal "coup" and reverted to Exchange servers and traditional clients to reliably solve their mail needs.

Not only did the migration to a management-mandated platform not enhance productivity or otherwise benefit the enterprise in any significant way, it actually cost them money both for the initial switch from their original solution, then again when they were forced to switch back to their original system from this supposed "upgrade".

"Usability" is a Concept Foreign to Your Intranet Developers.

Even if your intranet has benefited from an enthusiastic and well-meaning sponsor from within the ranks of management and was built specifically to address employee needs through content and functionality, there's still the possibility that the folks designing your intranet's user interface or its information architecture are simply sub-par, hindering users' efforts to utilize the intranet. Not to mention that your developers may have completely disregarded generally-accepted web development standards, leading to other unforeseen problems down the road. (If you think this is the case, perhaps you should leave this copy of Intranet Development on the desk of your lead developer, casually opened to our Usability chapter.)

Some of the usability problems that can plague your intranet can include:

• An intranet that works on only certain computers within your company, perhaps on all the PCs, but only on certain Macs, and not at all on the Linux boxes

• Web pages that cease to function in newer versions of web browsers

• A visual interface that fails to anticipate the need for a flexible interface that can be easily modified without changing the underlying (back-end) technology of the intranet, requiring massive effort to implement even the most modest of changes