“Pitfalls” Old and New

I was crawling around in the dusty library stacks the other day, pursuing a bit of research in old (and I mean old) copies of Practical Accountant.  I’m talking about 1978 through 1981.  I read the tables of contents of every edition and didn’t find what I was looking for, alas. 

However, as often happens when one opens an old volume, there can be interesting surprises lurking in the pages.  The lurking surprise was in an article from 1979 called “Seventeen Pitfalls in Selecting a Computer System.”   Having spent most of my career in Information Technology (despite an early and enduring foundation in the Liberal Arts), I couldn’t resist checking out an article about what went wrong with technology purchases in 1979.  I wondered how pitfalls then compare to pitfalls now. 

I was happy to discover that not all of the 17 they worried about back then are worries today.  For example, we no longer worry about what programming languages can be supported by which platforms.  Concerns about obsolescence (buying technology that can’t be upgraded) have gone away, as have many worries about expansion capability, since many vendors have designed their products to be scalable for future growth.  That’s all good news.

Interesting, though–and rather awful–was the #1 item on the list, which is still very much alive and well, I’m sorry to say.  Pitfall #1:  “Defining objectives and requirements poorly.”  Thirty years later, it’s still coming up as #1 on many project “post mortem” lists, when debriefing about what went well and writing up “lessons learned” (which often become “lessons ignored”). 

Defining requirements is usually a job for a Business Analyst, and in my experience, some of the very best Business Analysts have been people with Liberal Arts backgrounds–people who can write, analyze abstraction, organize information, document findings.  Engineers usually don’t like that sort of thing.  Project Managers are often impatient with this phase of work (even though many of them know how important it is).  Business leaders tend to shortchange its importance. 

But Business Analysts know that organizing and articulating what’s needed is an essential step.  Technology solutions that move ahead to design, for example, without taking into account all the requirements miss things.  Testing without fully documented requirements is haphazard at best.

Even if all that doesn’t sound terribly familiar to you, let me tell you what I think this article from 1979 actually means:  We’ve gotten better about acquiring technology.  Many things that used to go wrong don’t go wrong anymore, and we have engineering to thank for that.  The technology itself is less rickety, less risky.  It’s more adaptable, easier to scale–all good things for businesses that grow and change. 

However, one very important area still comes up as short as it did 30 years ago, and that is the job of Business Analyst–analyzing and documenting requirements.  This is a job for Liberal Arts majors!

Why?  Businesses are often about abstract, intangible things and often require a clear understanding about things you can’t get your hands on.  Money, for one thing.  And data.  And process.  Even ideas, invention.   

Consider how, for example, software is developed to perform a particular job function.

Have you ever been to a restaurant where the waitress took your order on a handheld device?  I don’t mean a notepad with a pen, not that kind of handheld device.  I mean something about the size of an iPhone.  She taps in your order—halibut fish sandwich with a side salad, ranch dressing—and as soon as she does, it appears on a screen in the kitchen—halibut fish sandwich, side salad, ranch—and the food prep guys get to work on it.  They key in when it’s done, which immediately appears on your waitress’s handheld, and she hops back to the pick-up window to get your order.

How do you suppose that comes into being, that little piece of equipment your waitress now can’t live without?  It comes into being because someone who has really good analytical abilities was able to examine and decompose and finally translate the restaurant job processes into material that technology developers could use to design a new product.

That’s what a Business Analyst does, and believe me it’s a highly prized skill that not many people are good at.  People who are good at this don’t mind dealing with the abstract.  They’re comfortable with ambiguity, shades of gray rather than black and white.  They’re willing not only to analyze a situation or event but to write about it, and then to revise what’s written as information improves.

Analysis and writing.  You haven’t studied anything like that in your academic career, have you?

In my experience, the best business analysts have Liberal Arts educations.  If you can examine, analyze, de-compose, organize and write, this might be a great place to start your career in business. 

And perhaps in 30 years, Practical Accountant (or its successor) will be able to produce a list of only two or three “pitfalls in selecting a computer system,” and “defining requirements poorly” won’t be on the list.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s