Getting The Right Project Requirements

By Kevin M. Berry

Every play "Bring Me A Rock" with a boss or customer? Here's how it goes. "Kevin, please go get me a rock." Kevin, being a model employee, salutes and charges off, returning in short order with, of course, a rock. Placing it proudly on the requestors' desk, he stands back, beaming. "Thanks, Kevin," the boss says, scratching the back of his head. "But, I was looking for a bigger rock." Kevin dashes out, promptly fetching a large, fist sized lump.

The game continues, with Kevin fetching bigger, harder, differently colored rocks. Finally, reduced from willing hey-boy to grumbling mal- content, he screams in frustration. "What do you want this rock for, anyway?" "Well, I've got this pointy metal thing I wanted to pound into the wall to hang my Management School diploma on." "You idiot" - Kevin is bellowing now - "you needed a hammer, not a rock!" Kevin, once an aspiring corporate ladder climber, now works down at the hardware store, happily selling hammers.

Sound familiar? In the real world of IT, a more apt label might be "build me a database," or "I need a user friendly system to access enterprise data real time from customer specific terminals." No matter what you call it, the game remains the same. A customer has a real need, but not the language or background to explain, ahead of time, what they want. During the definition and programming cycles, they don't understand the ramifications of decisions the techies ask them to make. "Will you be indexing on phone number or address?" could be a key design parameter, but the term "indexing" means nothing to someone without extensive database design experience.

So, the alpha version is rolled out, and the customer invariably asks for a seemingly innocent change that requires a complete restructure. Along comes beta, and more chaos. When it hits the validation environment and real users enter the picture, things fall apart completely. Pretty soon, everyone, programmers and users alike, are working with Kevin down at Home Depot!

Every model for managing IT projects starts with the mantra: "Get the Requirements Right" and "Get the Right Requirements!" In textbooks, classrooms, and on the popular book circuit, it sounds so easy. Ask the right questions, be patient, give the customer a chance to sign off on the derived requirements, and then lock down the baseline, which must be protected ruthlessly.

In the grimy world of real projects, it's not that easy. Even assuming a boss or customer understands their own ignorance, and is willing to learn, mistakes and misunderstandings will always result from a front-to-back requirements development approach. Experience shows it's far better to follow Steven Covey's approach, "Begin With The End In Mind". IT professionals think in terms of systems, software, queries and data element relationships. Users think in terms of reports, screens, and searches.

Whether building a database, web interface, or process control system, it's best to start with a blank sheet of paper. Literally. Sit down with the customer, key users, a white board and dry erase markers. Sketch out the final product, such as a report printout, input screen, or metric graph. It is amazing how long it takes to work through simple things like "which column should be on the left" or "is going up good or bad on the graph?" Of course, while the users are discussing whether a column should be alphabetical A-Z or Z-A, the database designer is hearing "one big table or related small ones" and "indexed on name or phone number."

This is where that darling of consultants, "facilitative behavior," can actually be useful. Asking the right questions, drawing what is being said, and helping users understand their own process will result in a good final product. Often, the IT pro winds up helping them flow chart their own business process, which is 100% certain to be imperfect and misunderstood.

This process is one of Covey's "Paradigm Shifts" that can be very painful for a designer to sit through. Too many times, though, the keyboard wizards have blown off a user's report format question early in the design process, only to find out after deployment that a numerical field should really have been a text field. Once a veteran designer has sat through these user product development round tables, they are relieved at all the rework that was avoided.

One reef that many IT project go aground on is the "point one percent problem." Users tend to get hung up on process or data glitches that only happen once in a great while. It's up to the "facilitator" to help them analyze whether a weird case happens infrequently or regularly. Something that only happens one transaction in a thousand may be a minor nit to the users, and can be dealt with manually. To program around these oddities can be a costly, complicated nightmare. On the other hand, if a bizarre data point or process issue is going to happen once every 20 transactions, either the system is going to need to accommodate it, or the user process changed.

Only after complete agreement on the final product is reached should "real" system design begin. Backing up from the user's reports or screens, decisions on structures and software can be made. Architectures that don't support the user's needs are quickly identified. Now, when the designers reach one of those "cost-benefit" points, where it's going to be expensive to implement a specific user need, they can go back to a well informed customer and ask for meaningful inputs. "We are finding it will be tough to fit all 17 fields on one screen and still have the font the size you wanted. Can we put the buyer's detailed shipping information on a pop up instead?" "Well, that depends. Will I be able to cut and paste it into our label-making program? That wouldn't be too big a deal, and then you could skip coding the whole interface between the two." Relate this conversation to the one in the opening paragraph.

Bingo. Smart user, happy programmer, successful project. Save the rocks for your garden wall when you retire to your summer home on the beach, or the winter ski lodge you earned as the most successful IT manager in the history the company.

Kevin M. Berry
copyright 2005
Private use welcomed, reproduction in other publications requires permission of the author.



Got something to add? Send me email.





(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Getting The Right Project Requirements


1 comment



Increase ad revenue 50-250% with Ezoic


More Articles by © Kevin M. Berry







Thu Jul 7 20:07:47 2005: 760   BigDumbDinosaur


Good article!

IT professionals think in terms of systems, software, queries and data element relationships. Users think in terms of reports, screens, and searches.

This is why most coders should stay away from most users. The individual(s) talking to the users should have more generalized experience so as to not only ask the correct questions but ask them using words that a non-technical user can comprehend. Users don't like hearing about "tables," "records," "elements," etc. Rows and columns usually make sense (especially to accountants) and readily relate to a type of organization almost anyone can fathom. In other words, don't describe how a timepiece works. Just show the user how to read it.

------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





The activity of "debugging", or removing bugs from a program, ends when people get tired of doing it, not when the bugs are removed. (Datamation)

Java is the most distressing thing to hit computing since MS-DOS. (Alan Kay)








This post tagged: