paulchinonline.com

The Problem with Jack-Of-All-Trades Intranets

By Paul Chin

Originally published in Intranet Journal (24-Jan-2005)

back back to portfolio


I used to have this Swiss Army knife that I carried around with me everywhere I went. It proved its worth in almost every situation that could befall a hapless adventurer with a tendency to get into trouble—both in my day-to-day job as well as when I headed out for weekend backpacking trips into the mountains. It had every imaginable tool tucked conveniently into its trademark red handle and then some.

During the day, as a young network administrator out on a field call, I used it to splice cable, cut boxes open, unscrew hardware cases, and to protect myself from unruly users. But by night, I was a poor man's MacGyver, using my trusty Swiss Army knife to disarm villainous foes with little more than a pine cone, two feet of mint-flavored dental floss, and the ingenuity of an overactive imagination.

After years of use, I noticed that only three or four out of the 20-plus tools were ever used. The main blade showed signs of multiple re-sharpenings, and the scissors still bore evidence of the time I sheared a sheep and knit an emergency sweater when the temperature dropped drastically in the great outdoors. But the majority of the other tools remained unused, still shining like the day it left the factory.

I'm not making any allusions as to the compactness of this portable utility chest either, since it was more that capable of being used as a boat anchor. It suddenly dawned on me that I was carrying around this behemoth—adding extra weight to an already gear-laden pack—when all I really needed was a simple blade.


Jack of All Trades, Master of None

The majority of corporate IT implementations are developed and focused around a set of core components aimed at a single objective, and any additional features outside these core components are just gravy.

Let's take corporate e-mail as an example—a tool used for communication, collaboration, and personal information management. In addition to the software's basic e-mail management abilities, supporting features—spam filtering, message rules, newsgroup and RSS reader, address book—can be added to enhance the overall value and quality of the application. But after a certain point, an application's required featureset will plateau, and anything added after that is just showing off—usually at the expense of user productivity. I'm sure that few of us would actually trade in the stability of core components for the inclusion of "nice-to-have" features.

An intranet, however, is not as definable as many other IT implementations. It's a blank canvas with few hard-and-set guidelines this is reinforced by the amount of e-mail I still receive from people asking me what goes into an intranet. But an intranet is many things to many people. I can't answer this question unless they have already asked themselves the same question, and at the very least determined the primary purpose of the system. Once this has been decided, then we can talk about what features to include.

This lack of a focused goal may cause intranet developers and content owners to over-develop, making it a Jack-of-all-trades (JOAT) system when a much smaller solution would suffice—and is probably preferred.

JOAT intranets are the Swiss Army knives of IT—they can contain any number of tools, and can be used to solve countless problems. If a particular tool doesn't fit into the handle, you can always make a bigger one. But therein lies the problem: if you keep adding more and more, you may as well wheel a tool chest around with you, which defeats the purpose of having something small and portable.

You need to know when to say enough is enough. Are you putting features into your system because users have a genuine need for them or are you putting them in because you're afraid of leaving something out? You should be developing your intranet to meet a business need, not to wow users with the its extensive list of features.

There's really nothing wrong with JOAT intranets if that's what's called for and, more importantly, if it's done properly. Unfortunately, in many cases, JOAT intranets that try to do too much end up doing many things adequately but no one thing very well. I can honestly say that there are several JOAT-type software applications on my PC where only about 25 percent of its inflated featureset is ever used. They take forever to load and do little more than occupy hard disk space and suck up valuable memory reserves. And without an option to uninstall all these unused tools, I have little choice but to bear with them.

But don't expect your user community to show the same type of resigned indignation; and don't assume that they will automatically be happier with more features. An intranet needs to suit the job it's built to support. Sometimes less is more; and it takes quite a bit of skill to prevent JOAT from becoming bloat.


The Right Tool for the Right Job

Many IT implementations have a pre-defined application template—a list of features identical to all other implementations of the same type. Applications such as anti-virus solutions, office suites, and corporate e-mail all have core components that don't vary much from one vendor to another. Even broader, more complex IT implementations such as enterprise resource planning (ERP) solutions have a core set of components and application templates. ERPs can incorporate multiple modules for standard business operations including human resources, payroll, project planning, customer service, and purchasing—to name a few. It's just a matter of which modules to include, and fine-tuning the applications to meet the needs of the company implementing it.

With intranets there's no such predefined template. Intranet technology can be used to support and facilitate just about any application you can think of. It can be used to support content and knowledge management systems, to drive online collaboration, to build a user support network, or to serve as an enterprise portal tying several corporate database applications together.

You can't simply say, “Build me an intranet” anymore than you can ask a team of mechanics to build you a generic vehicle without ever mentioning the type of vehicle you're looking for. Will it travel on water, land, or air? Is it a single person vehicle or a personnel carrier? The right tool needs to be developed for the job at hand. While you may be thinking of a speedy little compact car to zip around town in, your mechanics may end up delivering you a Hercules transport plane—talk about overkill.

Intranets—whether in the initial stages of development or undergoing a complete re-design—always have to begin with a concrete and clearly defined game plan. It's this game plan that will help intranet developers and content owners from adding impromptu features along the development path.

And because intranet solutions do encompass such a wide field of possible IT applications, you need to ensure that you're building the right tool for the right job. If all that's needed is a svelte content management system, don't try to squeeze in a bunch of online collaboration tools. While it might be nice to have, it's unnecessary and will take focus away for the intranet's core features.

But it's very important to note that building the right tool for the right job doesn't mean backing yourself into a technological corner. Just because your current requirements call for a narrow set of components doesn't mean that's all you'll ever need. Your intranet should still be flexible enough to allow for future expansion; and this flexibility should help you avoid the temptation of including everything into one release.


Avoiding the Pressures of Over-Development

An intranet should always have a mission statement. If not an official one then at least one used by developers and content owners in order to help them maintain perspective on system goals. Otherwise, over time, intranet owners may lose sight on why they built the system to begin with and morph the intranet into a hodgepodge of tools.

Always stay focused on your intranet's mission statement (what is its primary purpose?) and target audience (who are you building it for?). If the job calls for five or six core components, concentrate your effort on building those components. JOAT intranets containing too many unnecessary features may end up projecting a negative image and a lack of focus to the user community. It will be as though you were not quite sure what you were trying to build and thought it safer to include more features for fear of missing something. Ironically, users will appreciate nothing more than a straightforward system that simply does what it's supposed to without all the other bell-and-whistles bogging down the system.

Also, don't be overly swayed or influenced by what you see in other companies' intranets, or what you read in magazines and Web site. Every company's needs are different, and every intranet is different. Your solution has to be a right fit for your specific business processes and user needs. Don't try to build a generic, all-inclusive solution containing every imaginable application just because you think it will better fit someone else's definition of what an intranet should be. The time and effort spent on including unnecessary features may cause you to neglect core components.


Final Thoughts

I've always appreciated software that had a focused purpose. They do exactly what they're supposed to without the unnecessary extravagance of a marketing wow factor. Unfortunately, too many software developers maintain the false impression that more is always better—that they can win users' confidence by hitting them over the head with a long list of features.

It's gotten to the point where you can't even classify some JOAT-type software packages anymore; they try too hard to be everything to everyone. Either that or they're overcompensating for lack of software direction by loading the system up with as many feature as possible.

And I've also learned this same lesson in my own life—to match the right tool with the right job. After countless hours hiking in the backcountry, I've learned that there are some tools in my clunky old Swiss Army knife I'll never use. So I've long since retired "Big Red" in favor of a slimmer Swiss Army knife with only seven essential tools—and somewhere, a sheep with an uneven coat is breathing a very deep sigh of relief.


Copyright © 2005 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.