Printer Friendly Version

Users are not passengers, they're the biggest driving force in the direction of an intranet — they just don't know it.

Many users end up frustrated with their IT systems because they feel as though they're sitting in some stuffy backseat being lead around by others, that they have to take what they can get and have no say in where they're going. Intranet sub-site owners seem to make decisions for them. Developers seem to make decisions for them. Even the technology industry seems to be making decisions for them. This is only true if they let them.

End-users are not at the mercy of others. They have more say than they think, but perhaps are unaware of the avenues available to them. To these users I offer five pieces of advice.

1) Initiating Upgrades and/or Bug Fixes

The first secret to getting things done: Never approach IT directly. It's not that IT doesn't want to hear from its users; it's more that it doesn't want to hear the same requests over and over from multiple sources. This can become very frustrating for the IT staff. If it has to respond to the same questions and requests everyday, it will never get anything done. Eventually all these requests are going to sound like white noise and IT will need to hire a PR rep to deal with intranet users. If users keep bombarding IT — by phone, by e-mail, when they bump into each other in the in the hallway — it will no longer be responsive regardless of how important and necessary the request may be. Over time, the interaction between IT and end-user will become little more than polite nodding and the canned response, "We'll get back to you on that."

Article Tools

Print this article E-mail this article Discuss this article Related resources

This leads to the second secret to getting things done: Make it official. A formal request sent to IT from an intranet sub-site owner will carry a lot more weight than a handful of verbal WIBNIs (Wouldn't It Be Nice If) from end-users. It's the responsibility of each intranet sub-site owner to act as a sieve, to be a liaison between IT and its immediate users. Rather than flooding IT with duplicate, and possibly unimportant, requests, they should be grouped together, filtered, and prioritized. Users need to work with their sub-site owner to determine what's most important to them and their part of the intranet. Armed with this information, the sub-site owner can then present a formal request to the IT representative of the intranet governing body for action.

Example flow of end-user requests.

2) Voice Opinions Whenever the Opportunity Arises

Just as the success of a government can be measured by the satisfaction of its constituents, the success of an intranet can be measured by the sum of its satisfied users. With this in mind, it's in IT's best interest to take user feedback seriously. When an opportunity comes up for users to voice their opinions — such as with user surveys — they should take it. This is how intranet users cast their vote.

Unfortunately, many don't because they believe that one “vote” won't make a difference. But users shouldn't think of it as one vote; they should think of it as one vote among a larger group of votes comprising a fairly loud voice that intranet owners will have to hear. If a single user has an opinion on something, chances are there's a whole group who share the same opinion.

Another reason users might not bother to voice their opinion is because they think that their feedback won't be taken seriously or that IT is running the survey merely for appearances. The problem with surveys is that with every action, there's no reaction. Users take the time to fill out a questionnaire but never get to see the outcome. For all they know, their responses might just end up in some vacuous database for storage. What users should do is ask their sub-site owner or representative to get IT to publish the results of any major survey so that they can see something was actually done with all that feedback.

Only by voicing an opinion can users affect real change in an intranet. And as with governments, you don't have the right to complain if you don't bother to vote.

3) Make Sure IT Understands

It's amazing how some developers can miss the mark when they try to design something for an audience they know little about. Take, for example, the public transportation in my neck of the woods. Our newest buses are meant to be wheelchair-friendly, providing accessibility for physically handicapped commuters. These buses have the ability to bottom out so that wheelchairs can roll in. It also has a special section where the seats fold up to allow room for the chair. This all sounds good, right? The only problem is that the entrance to the bus is so narrow that it's next to impossible for a wheelchair to corner.

It's a fact of development life that IT will make certain assumptions as to what their users need. This usually happens as a result of overzealous developers who go too far with their use of new technology, a lack of information and/or feedback from users, or a misunderstanding caused by unclear project specs.

Unless IT is intimately familiar with the daily workings of its user-base it is going to rely on the input of the various sub-site owners. Even though users won't be directly involved in the development of an intranet, it's still important for them to participate in the process by letting their sub-site owner know exactly what their needs are, their daily routine and how they work, and the roadblocks and bottlenecks in current business processes.

4) Help IT Set Policies and Procedures

IT usually sets up standard blanket policies and procedures — maintenance schedules, account and security access acquisition, infrastructure integrity measures — for the entire organization to ease system management. But in some cases, a specific group, department, or a remote office won't fit into this model.

Large, geographically dispersed organizations or organizations with an international client base, for example, might have employees who do the majority of their work during hours that the rest of the company considers off-peak. And if IT's maintenance schedule happens to conflict with some workgroups' core operating hours, these workgroups might find themselves with spotty system performance — or worse, none at all. Users who have exceptional requirements that don't conform to IT's standard policies and procedures must make them known so that IT can provide a solution that will suit their needs.

Examples of Exceptional Requirements

Secure access from remote locations Encrypted transmission of secure content Access for clients via an extranet System availability during off-peak hours Special data retention needs High level security requirements for either personnel or data On-site system support for remote offices

5) Suggest Using Community-Driven Tools

Wikis, blogs, and klogs are changing the very shape of the traditional content managed intranet. Prior to the advent of these tools, users' content contributions were limited to discussion boards. The popularity of the discussion board was not only as a mean of communicating with other users, but it gave end-users a higher degree of interaction and involvement beyond simply reading content and performing database searches. Unfortunately, discussion board data is highly unstructured.

Wikis, blogs, and klogs are allowing for even greater end-user participation and have taken it one step further by turning every end-user into a potential content provider. This puts control of an intranet into the hands of those who use it. While tools such as wikis, blogs, and klogs probably won't replace existing content managed intranets that already have a substantial and sizeable content-base, they will certainly be a perfect addition to any system. By giving users the ability to build their own content, they will have more of a stake in the intranet — a kind of "built for us, by us" pride.

However, caution needs to be taken by all parties — IT, sub-site owners, and user — to ensure proper use of these tools. There are issues related to content quality control and credibility that need to be addressed before such tools are used in a production or mission critical environment.

Closing Thoughts

An intranet is borne from its user community but too many of these users believe that they have no part in the development and future of the system. And because of this belief they allow themselves to become mere spectators. But they do have a role to play: To define an intranet's basic foundation and featureset, and to direct the future direction of the system through their sub-site owner. Even though developers and content owners physically build an intranet, it's users who must help raise it.

Paul Chin is an IT consultant and a freelance writer. Previously, Paul worked as an intranet and content management specialist in the aerospace and competitive intelligence industries.

Printer Friendly Version

Other Resources

from Intranet Journal

Intranet Journal Discussion Board Multi-Tier Intranet Ownership Beware the Bleeding Edge and Feature Creep

from JupiterWeb

Cold Case File: Why Projects Fail (Datamation) Not Just a User, a Customer! (Datamation)