Printer Friendly Version

Drawing the Line: Need Versus Want

It takes a great deal of discipline to consciously distinguish between what's required and what's desired. Users need to be able to search their primary intranet database of client information and have the results sortable by name, location, and project association; it would be nice if these results could be exported into a MS-Access database so that the data can be used to produce cosmetically friendly reports.

It's the same principle behind never going grocery shopping when you have a case of the munchies — because if you do, you will most likely end up with a cart full of beer and Ho-Hos. But this is really a matter of interpretation: one person's necessity is another's extravagance.

This distinction between need and want — sometimes a matter of controversy depending on who you ask — must be made during the requirements gathering stage of an intranet project, and agreed upon by the developers and content owners. Failure to do so will put your intranet at risk of being overtaken by runaway technology and a bloated featureset.

Here are some tips to help prevent your intranet from being a victim of its own technology:

• Follow a formal set of system specs
• Keep in mind you're designing for people
• Separate production from R&D

Follow a Formal Set of System Specs

It's a phenomenon known by many names — creeping featuritis, requirements creep, feature creep, creeping elegance — and occurs when a system's featureset grows beyond what was originally planned. It can be caused by users' growing wish lists or overzealous developers' attempts to "improve" upon a system when they learn of newer technologies and techniques. It's a movie we have all seen at one point or another; the characters and setting may be different, but the plot is always the same. For me, the story plays out as "The Attack of the Killer WIBNI."

WIBNI (Wouldn't It Be Nice If), a term coined at Bell Labs to represent features (some would say superficial and unnecessary features) that are constantly dreamed up and added to a original system specs. Wouldn't it be nice if we could put dynamic Flash-driven menus instead of static ones; wouldn't it be nice if the search results were automatically formatted for printable reports; wouldn't it be nice if the system was able to spit out an espresso while I surf. The list of system WIBNIs can be as infinite as your imagination.

The only way to tame this WIBNI monster is to follow a formal set of project specs and stick to them regardless of any desire to tack on more flashy gadgets.

System specs provide developers with a concrete framework in which to work with. If WIBNIs are constantly added, your project will never get done. Any time progress is made, the finish line would be moved as well — like a rabbit chasing a carrot dangling in front of it from a fishing rod attached to its back. This will not only wreak havoc on scheduled deliverables and milestones, it also creates an incongruous patchwork of system features.

Post-spec WIBNIs — and feature creep, in general — are notorious for delaying project deliverables. Rather than feeding the beast with endless features, consider them something that can be added in future versions of the system.

But if additional features not originally specified in system specs are truly required (i.e., not trivial WIBNIs), make sure:

• all team members agree on the additions and/or changes
• the additions and/or changes are made through a formal request process and not verbally or on-the-fly
• there's a spec change sign-off procedure by someone in authority
• you understand the effects that the additions and/or changes have on scheduling and current deliverables

Keep in Mind You're Designing for People

With all this discussion of technology, what everyone needs to remember is that at the other end of technology are human beings who must use it. You can pack tons of technological ammunition into a system but if it does nothing to make the lives of your users easier, it's useless.

It's sad to see that the advancement of all things high-tech seem to have dehumanized the workplace (P.G. Daly wrote a great article, "People First, Then Technology," dealing with this issue) when we should, in fact, be placing even more emphasis on the people using the products because of such advancements in technology.

We need to always be aware that we're developing for people, not developing for technology. But it's an unfortunate trend in system development where developers feel the need to pack in as many features into a product as possible just because the technology allows them to do so. This is precisely why the market is swamped with so much bloatware — software that's so feature-laden that it not only taxes hardware requirements but also makes it overly complicated and almost unusable for the regular end-user.

Simplicity and user-friendly software is often the key to productivity. Just because technology allows developers to do more doesn't mean they're obligated to do so. And it's unfair to expect users to constantly have to adjust to the frequent changes in technology. Don't, for example, redo or replace a system that was only rolled out onto the production environment several months ago (unless there are serious deficiencies with the original system) because a newer technology arises.

Bottom line: If it doesn't help the users, don't do it.

Separate Production From R&D

Bleeding edge technology is a vicious cycle; those trying to gain control of technology are also the ones feeding the problem. In their attempts to keep pace with new technology, developers are sometimes forced to use production systems as a live experiment for lack of a practical alternative.

Perhaps they find it difficult to justify the expense of a dedicated development environment because there's little to show management in terms of immediate returns. But R&D shouldn't be viewed upon as a luxury; it's essential in keeping the bleeding edge from seeping into live, production systems — an environment not suitable to open experimentation.

Development and production must remain two separate entities because new technology requires a period of testing — or as I like to call it "gestation" — in a controlled environment to ensure stability and technological maturity before being released for company-wide usage. Using a production system to facilitate this need places the unwanted burden of being guinea pigs on users who are just trying to do their jobs with the tools provided to them by IT. And you don't want this relationship to turn into one where users harbor resentment toward IT and everything that comes from them.

Final Thoughts

There are far too many users, both in and out of IT, who feel as though they're slaves to the trends in technology — but they don't have to be. There is such a thing as technological freewill! What we all need to achieve is a balance between keeping pace with technology so that we don't fall behind while maintaining enough caution and good sense not to prematurely adopt bleeding edge technology.

I hope users and developers begin to see technology beyond both ends of the extreme. We have far more options than just standing rigidly still or running full-speed ahead with arms flailing in the air because there's plenty of middle ground for a nice, steady stroll.