The human side of intranets Part III

All too often, the user is the guinea pig in today’s fast-paced technological landscape. In the third part of this series, Paul Chin examines the effects of change on user communities.

Ever since the industrial revolution, there’s been an air of humanity against machinery – a sort of John Henry versus the steam hammer mentality. Today, many computer users are still feeling the effects of a technological revolution, trying in vain to reconcile between what technology is supposed to do and what it actually does do.

To some, the promises of bigger, faster and simpler just don’t live up to their expectations. They view technology as both the cancer and the cure. Rather than the utopia celebrated in science fiction movies, many users find themselves solving their technology woes with a skillful karate chop to the keyboard or monitor.

In this third part in my series on the human side of intranets, I’ll take a look at how the fast-paced evolution of technology affects organisational user communities, and the dangers of not adapting to the changes in an organisation’s technological landscape.

Understanding the effects of change

To the average computer user, it may seem as though technology is moving at five times the speed of their ability to adapt to the changes. Developers go to great lengths to come up with new and improved ways of carrying out existing processes. In stark contrast, most users are just happy to get through the day without wanting to throw their computers into the path of an oncoming bus.

This creates an odd, unbalanced relationship between the user community and the technology that’s meant to support them. And herein lies the real irony: while all this effort is expended by developers to make users’ lives simpler, it’s actually had the opposite effect on many. It has created anxiety, reluctance, frustration and fear. And for some, these “advancements” are more disruption than improvement.

But technological change is inevitable. Intranets and other IT applications are built to support business processes during a specific time period. We have come to expect these processes to evolve over time in response to shifts in business requirements; so shouldn’t we also expect the applications to evolve in parallel?

It’s unrealistic to think that we can use the same applications we built five years ago to support the radically changed business processes of today.

Everyone deals with change differently, but some organisational cultures don’t react well to the introduction of new technology. In an ideal world, the release of a new system into the production environment would be seamless; new and pre-existing system components would mesh perfectly without any side effects, and users would embrace it with open arms — but this is rarely the case. Reality and experience have taught us that there’s usually a certain amount of collateral damage left in the wake of any new technology or system. Either the system won’t live up to its potential or users won’t even given it a chance and reject it outright.

Failure to notice, and subsequently address, the effects of technological change will result in long-lasting consequences within the user community and their willingness to accept future implementations.

The dangers of resisting technology

When technology was first introduced into the business realm it was used to enhance existing processes and to simplify repetitive tasks. The core processes, however, remained relatively unchanged. But now technology is so ingrained in our daily business lives that we can no longer separate it from the process. They are merely two halves of a whole, each facilitating the existence of the other.

Every modern organisation relies on technology, in varying degrees, for its operation. It helps employees manage their personal information, collaborate with colleagues and clients regardless of their geographic location, and drive the organisation’s essential business processes. And as these technologies advance, so do the skill-sets of the users. But there are some who are either unable or unwilling to adapt to changes within the organisation’s IT environment.

Regardless of whether this comes in the form of open resistance or a quiet inability to adjust, there’s a danger of falling behind. Some users may be under the impression that the new systems and technologies being introduced are mere frivolities and not to be taken seriously. What they don’t understand is that the new tools being introduced today will be the norm tomorrow. And a failure to adapt to these advancements in corporate technology will result in outdated skills. This will threaten users’ self-sufficiency as they begin to rely more and more heavily on those who are familiar with the new systems to do things for them.

But the solution to this problem isn’t to force technology through like a battering ram with a take-it-or-leave-it ultimatum. The reluctance, or unwillingness, to accept changes in the organisational IT environment needs to be handled at the basic human level.

Taking a more human approach

The reason organisations have such a difficult time getting users to adopt new technologies and systems often lies in their approach. Too much focus is placed on the technology itself and not the people who will be using it. Users are made to adopt new systems without adequate training or understanding of what they’re using. Remember that you’re developing for people, not for the sake of technology.

Those responsible for the introduction of new technologies and systems must acknowledge the viewpoints of their users, and how major technological changes affect their daily work habits.

It’s naive, and even a little pompous, to believe that all users within an organisation will look upon new systems and technology with awe. Most users aren’t in the IT industry and might not have the same eagerness to try new technology as those who are. In fact, some users regard the launching of new systems with the same sense of foreboding that accompanies an impending storm.

Applying new technology to an organisation’s user community must extend beyond the tool, and address the needs of those the tools are meant to support. There are several crucial user-oriented issues to keep in mind before any new system is implemented:

Is it a process driven evolution?

Users exist to run an organisation’s business, and the tools that come out of IT must cater to them and their functions. So when change is required in an organisation’s IT environment, it must be based on actual business process needs, and not done simply for the sake of technology.

IT is a service centre; responsible for outfitting users with the appropriate tools to get their jobs done quickly and efficiently. But when changes are made solely for technology, you’re catering only to IT. For users, issues of performance and efficiency, technological longevity, and conformation to new industry standards mean very little – they just want something that works properly.

Never treat users as guinea pigs

With the speed at which technology moves, developers might be tempted to fast track system changes by applying them directly to existing production applications. But this doesn’t always work out as planned. Even minor changes that are thought to be relatively benign can snowball and corrupt, or even disable, production systems.

Stable production systems must never be used to test new technology. This places the unwanted burden of IT guinea pig squarely on the shoulders of users who are just trying to do their work. The user community doesn’t exist to support IT’s R&D initiatives, so forcing them to accept unproven technologies in a real-world setting can cause a lot of resentment. It will make it seem as though IT can’t be bothered to test their own work, or don’t think enough about the importance of their users to consider the impact of these changes on the user community.

System upgrades and enhancements must be thoroughly tested in a controlled environment that won’t adversely affect users’ production systems or data. Only after the testing phase is completed and the updates proven stable, should they be deployed into the real world environment.

Stagger system upgrades over time

While change is expected, constant and rapid change can be disorienting. Nothing frustrates users more than when they just start getting comfortable with a system and IT changes it on them again. This will make users feel as though they’re at the mercy of IT’s whims, without any control or say as to their own technological fates.

When new applications or updates are introduced, users need to go though an adjustment period before they feel confident enough in their ability to use the system with any efficiency.

By releasing a seemingly endless stream of intranet updates, users are not given the luxury and comfort afforded by this adjustment period.

Unless updates are urgent – meant to fix bugs, patch security holes, or otherwise reinforce system integrity – all non-essential updates should be accumulated with other upgrades and released into the production environment in staggered, well-timed batches rather than piecemeal. This minimises the impact on users since they will only have to adjust to one group of changes at a time instead of a continuous flow of minor alterations over a short period.

In addition to the grouping of updates, intranet teams also need to ensure that a reasonable passage of time occurs before the next substantial set of upgrades. For example, many intranet owners like to perform the occasional cosmetic overhaul, changing the look and feel of their system in order to keep it fresh and maintain user interest. Doing that every couple of years is reasonable; doing so every year is not.

Provide tailored training

Intranet teams should make every effort to develop several user tailored training programmes rather than using a single generalised course. If the audience is diverse, the approach to training should be as well. At the very least, there should be two distinct training programmes: one catered to technical staff, and another to the less technical.

Everyone learns at a different pace and with whatever method they’re most comfortable with. But, I’ve found that those who are more technically inclined tend to be more accustomed to learning through experimentation with a new system, while the less tech-savvy prefer a more formal face-to-face classroom setting. Instructors can use a faster paced course for technical staff, providing an overview of the system and then letting them explore on their own. Another, more detailed programme can be used to teach the less tech-savvy with more time allotted for questions and practical in-class exercises.

Using a single blanket course isn’t very effective because each core user group has different needs and will access the system for different reasons. Lumping engineers and software developers in the same room as HR managers and

accounting personnel isn’t a productive way to learn. Each group will end up asking questions that aren’t applicable to the others, so discussions can easily branch off into a multitude of topics. But when training sessions are composed of peers with similar concerns and responsibilities, the issues covered will be much more focused.

A change in attitude

Some view technological changes within their organisation as a natural progression in business culture; others view it as an unnecessary disruption to their already complicated lives. But this discrepancy exists because there’s too large a gap between those implementing technology and those using it. And it’s a gap that widens when IT tries to forge ahead in a user community that’s already reluctant to adapt to technological changes.

It’s unfair for those in IT to introduce these new technologies and automatically expect users to sort things out for themselves. IT’s job doesn’t begin and end with the development. Perhaps there should be a new revolution; one in which technology extends beyond the code and the equipment to include a better understanding of the human beings at the receiving end of it all.

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