To see the importance of determining the needs and requirements of the customer, let me digress for a moment. Up until now I have had some strange and seemingly worthless jobs. Two of these were telemarketing and clerking in a local grocery store. During 6 years of telemarketing I got to not only get on the phone and "pitch like hell" but also to see the salespeople in action. I noticed that the scripts and techniques we used were largely geared to "persuading" the prospects to come around to our way of thinking, without much regard to the actual needs of the prospect. At the grocery store I was constantly told that the customer was always right yet I waited on customers that (a) didn't know how to how to act in public and (b) had little idea how to listen to reason. These people didn't deserve the respect they so desperately craved. So I learned that you have to figure out what the customer really needs, whether you can help them, and whether they know how to ask politely! (I threw that last one in for my own pleasure.)

This may sound a bit contradictory, especially since many salespeople and infomercial gurus would have you believe that all you have to do to succeed in life is to do a little work, convince the customer that you know what is best for them, and make the sale! There is a term coined some year's ago by authors Robert B. Miller and Stephen E. Heiman, that serves both as a title for their book, Conceptual Selling2, and is a good description of their basic theory. They tell you to ask questions, do research, and come to the bidding table with as much knowledge of the prospect's situation as you can muster so as to be knowledgeable in what you can and cannot do for the prospect. Wow, what a revolutionary concept!

The creation of a common agreement between the customer and the software project team follows the determination of the customer's requirements. Of course to do this you need to note the customer's needs, both stated and inferred, and come to a mutual understanding of the results that the project will produce. To better realize the implications of this part of the RM process, consider the following scenario. The customer has provided you with specs for the project, which stipulate that all users of the new inventory management software, which runs on the legacy system, will be accessing the necessary data for their work via web browsers. The customer has signed the contracts detailing the work to be done. The software engineering teams are hard at work bringing the solution to light. The design of the new software draws to a close as all aspects of the project are completed when a misplaced memo suddenly materializes and whole departments on both sides of the transition scurry to find cover. Sparks and words fly back and forth as each camp tries to sort through the confusion. But there is no mention of the fact that most of the users rely on the Lynx browser. The initial listing of requirements for this project was not communicated well enough so as to avoid confusion and delays. It is evident that good communication early on in the agreement phase can lead to happier times ahead in a development project.

Of course good communication between all parties involved should be in effect throughout the development process. How can progress be determined without a method or methods for tracking results? Monitoring the development process on an ongoing basis, according to the wishes of both parties, ensures successful completion of the project. Consider young William's concerns that he has about his departmental accounting report that has to be on the supervisor's desk by 7:30 am in the morning. If William's software helps him through this tense time he will be most appreciative, just as if he had fixed his cabinets at home with his new hammer. The tool that gets the job done is the winner in the eyes of the user and quality software can be an excellent tool for the future of business and individuals. To make software that can be counted on to do the job at hand and handle future tasks it is necessary to evaluate the development process from beginning to end. Compare the requirements of the whole process with the current RM system that is in use, no matter how informal it may be. This gives an idea of how to better monitor the RM process in the future and what stages in the development process may need more attention next time around. Getting users, managers, and leaders involved will stimulate the RM process to achieve greater heights of reliability, efficiency, and dependability than before.

Every person who is a consumer of products and services desires one basic thing from their purchases. They want the damn thing to work and alleviate any and all problems and concerns they may have had before buying the product or service. Quality software should be able to do the job that needs to done. It needs to relieve the user's stress, deploy quickly and efficiently, and be a joy to use! Almost everyone who has used a computer for any length of time has experienced frustrations such as frozen screens, lost files, dropped Internet connections, etc. It really sucks when it happens yet we just go on and make the best of it. RM can alleviate some of that tension and make the world a little bit better place in which to work and play.

So, considering all that has been said here, can projects really thrive without RM? The Japanese learned some time ago that to make a better automobile or stereo, you need to regulate the whole process rather strictly. Practice quality control and you have a better chance of delivering an excellent product. Requirements for each project should be reviewed since each development situation can be vary quite a bit from the last one. If RM is made to be an integral part of the software cycle, and coordinated well with the other parts, then every project can come closer to becoming the next "killer app".