|
INFORMATICS
SITE SPONSORS
|
Home > Informatics > Data Management
> Not All Who Wander are Lost
Not All Who Wander are Lost
The treachery of poor user requirements
Randy C. Hice
Whether you pity (likely) or envy (highly unlikely) this dark and dubious statement, I have probably sat through more LIMS demos from the widest variety of vendors than anyone in the world. Also, I have probably read more user requirements documents written by customers or third parties than anyone not committed to a mental hospital. Before you start a groundswell of fund raising to pay for my psychiatric care, let's look into this whole requirements business in a way that makes sense.
I have been using GPS units since AVIS first started to put them rental cars, and I quickly succumbed to the narcotic attraction of not having to fumble with maps at the high speeds I normally drive. Since the early days of AVIS, most car manufacturers now offer GPS as an option, and they are a requirement for all my cars.
Heavy GPS use has triggered an interesting phenomenon among consumers; I like to call it Cartesian Amnesia and Recall Prevention (CARP). This is what happens when you become wholly dependent upon GPS to guide you everywhere, and you simply don't pay attention to the route. Thus, you cannot possibly find that same spot again — or even direct someone to it — because some disembodied voice talked you through every turn and it was, in fact, your brain that went on autopilot.
GPS designs are not all created equal, however and, as elegant and rich in functionality as the unit in my Lexus is, the unit we had in my wife's BMW was equally reprehensible, crude and seemingly engineered by a roving troop of orangutans. Rather than the touch-screen technology prevalent in many of the Japanese-manufactured cars, the BMW units demanded moronic and arcane navigation through menus by twisting a knob, selecting a screen, then twirling that same knob through a keyboard to spell out a street name. What was the alcohol content of that dark beer they were serving in the BMW engineering shop?
I decided that a portable GPS for my road trips made even more sense than having one in my hometown, so I began to research them. Now, all of those LIMS demos and all of those requirements documents have caused me to focus on useful requirements as opposed to sexy interfaces, or bells and whistles that I'll never use. I quickly narrowed the vendor to Garmin, and then proceeded to sort out the basic classes of Garmin GPS units. I started to redline features that I'd never use. Bluetooth dialing for my cell phone? Nah, what's so hard about using my voice dial? MP3 player? I have an iPod. Real time traffic information? Look, if I'm marooned on the Ventura Freeway at 5:00 PM, I don't care if they route me by way of Saturn, it's still gonna have me reaching for that 44 magnum under the driver's seat to discourage those morons who cut in when five angstroms of space opens between me and the next car up.
Who needs a book player, currency converter, FM transmitter and configurable vehicle icons? Bah, bah, bah and bah. Who needs to drop a grand on these features when the unit I really needed was the Garmin Nuvi 350? Although there are many models below the top-of-the-line Nuvi 680, the Nuvi 350 still had many more features than I needed.
Turning to LIMS, as part of a recent RFP, I had to read through workflows and a user requirements specification (URS) that had been prepared by a third party for the customer. My first impression on the URS was that it was a shame that it couldn't have been written on a soft tissue wrapped around a cylindrical cardboard tube. The requirements were so high-level and general that no LIMS vendor from the middle tier of players on up could have missed any of the requirements. As for the workflows, these “harmonized” abominations described the laboratory operations on a single page for an entire work group. At that level of attenuation, the workflows were a colossal waste of the 50 grand or so it took to produce them.
User requirements specifications are becoming the bastard stepchild of the series of required validation documents, and are simply ignored in many non-regulated sites. In some cases, customers have a vague idea of what they want to do with the system, and they start hammering on the keyboards before any requirements are documented. Some URS documents are developed after the fact, and that's not a good thing. I can maybe (at gunpoint) see bending on developing the functional requirements specification (FRS) up front, and I certainly will let the design requirements slide until after prototyping, as few people outside of vendor or specific application experts could wield the prognostication powers required to predict how a specific commercial off-the-shelf (COTS) LIMS would be functionally configured to address URS and thus FRS items, but it is the URS that needs to serve as the scope-limiting document that sets the table for the development effort.
But, in the spirit of that sage adage: garbage-in, garbage-out, cirrus-nimbus level URS documents are a waste of pine pulp or any electronic storage medium. I'm not sure why people latch onto these things as some sort of Rosetta Stone for a project when they are as abstract as David Byrne after six gin gimlets.
User requirements can in fact describe generalities, but must be accompanied by specific details that will eventually be woven into the tapestry of the validation package for regulated environments, or serve as the lighthouse to guide developers from the jagged rocks of LIMS screw-ups and scope explosions that plague a great many projects.
And, while I'm picking on methodology, why not attack use cases that are developed solely because they are mandated by a number of cockamamie tools that cost companies a wad of bucks but end up reflecting a current-state environment rather than a specific future-state environment? Indeed, I don't care how rational (wink, wink) a methodology seems, when COTS LIMS are involved, you can elect to pave cowpaths by parroting a current state (AKA: we've always done it that way) environment that brings no process improvements. If the current state was perfect — and I haven't seen one in 23 years — maybe this could be pulled off, but process improvements are the bedrock of effective and productive environments. Extracting process improvements from a user community involves a certain facilitation skill to be sure, but all you have to do is find out what the chief gripes are about the current state (best done with senior managers out of the room), and then incite a local requirements riot with carefully placed barbs.
So, once process improvements are documented and signed off in blood by management and users alike, then and only then should the URS documents be drummed into shape, with a sharp eye cast to the upcoming functional and design specification (or application configuration) documents.
Unless you've been catching a Caribbean vacation at Gitmo, you've probably heard of the iPhone. Apple has had a long history of pushing the visionary aspect of system design by way of process improvements. They are possibly the most visible design anarchists in the world, and they refuse to be bound by convention. I like that. I don't agree with everything they come up with, but I understand. The iPod thumbwheel was pure genius, and still separates the iPod from wannabies.
With the iPhone, you wonder why the hell someone else didn't think of visual voicemail, the sweeping through menus and lists by dragging a finger across the screen, and the accelerometer that knows when you've tilted the phone on its side and adjusts the display accordingly.
Sure, there are issues, particularly for the business user. I'm sure the Apple visionaries toyed with the faster UMTS/HSDPA network that ATT is rolling out, but the business wonks quashed that idea, favoring the pokey EDGE network because UMTS/HSDPA is limited in its availability in the U.S., and sucks juice like a thirsty ape, and don't get me started on the send-to-dealer battery replacement. With a faster network, the iPhone could be used as a high-speed modem for conventional laptops via Bluetooth or a PCMCIA adapter. Alas, it's not going to be there for a while.
Let's look at the other side of the coin, Microsoft's Vista operating system. The Microsoft marketing machine spent a fantastic amount of money hyping how Vista was going to change everyone's life. They were hoping to obfuscate the fact that people really don't need Vista. What do the vast majority of people use computers for? E-mail, MS Word, maybe MS Excel, maybe PowerPoint, a lot of games, playing with digital photos, and instant messaging. To take it a step further, why even do we need to upgrade MS Office to the new versions of Word, Excel and PowerPoint? For a miniscule percentage of the users, maybe the upgrades make sense, for most, not a chance. Most users who have been burned by Microsoft upgrades in the past…device driver errors, bizarre application crap-outs, video card catastrophes, have learned the lesson…just upgrade when you buy a new machine, and buy a Noah's Ark load of memory. Want to get punched in the mouth? Go to your company's IT director or CIO and demand to upgrade to Vista when they just completed moving the clients to XP.
But these are just a few abstractions of the notion that user wants are not always user requirements, and it's important that when you're developing Shangri-La in your future state design, that The Business is involved to contain the truly insane wish list items that cause purchasing agents to throw back oxycontin like M&Ms.
But I'll take innovative ideas from the users over the status quo any day and any time. The river of great ideas starts from the ice melt of the line workers who really know how things work, and it's a crime not to reward creativity when it is the essential first step of an arduous project journey that is sure to end in shattered expectations if the user requirements are only an afterthought.
Randy Hice is the president of the Laboratory Expertise Center. He may be reached at editor@ScientificComputing.com.
|
|