Step 2: Design the Solution to the Request

Having clarified what the user wants, you then ponder the general way to approach the task, using whatever standards the information technology department has set. You then consider how you can get the job done most productively (most quickly and professionally, and with the highest possible quality) in order to improve your companys bottom line.

You can look at similar programs that could be copied . Start with the outputsthe required functionsthe inputs, disk files, user data, and any other inputs are then defined and documented. Then the logic of the reports is made final to make sure that thats what the user wants.

This is a good time to go back to the user again, to make sure your preliminary understanding of what the user wants is correct. If you are working with a new concept, a new application like online order entry, or something that affects many users, you would actually do a skeleton (prototype) program. Your skeleton program shows the user the screens in the anticipated flow of end user processing that he will see when the project is in production (without all the logic, validity checking, and all the other things that are going to be needed in production). Then the user can determine whether youre on the right track. A project prototype is like a movie preview in that it illustrates only the important concepts and functions without the cluttering details required for full implementation.

Lets look at an example: A very, very large company in the apparel field was going from a manual order entry to a real-time online system. In the system to be replaced , the customer service agents were using paper (nine forms!) to record orders, and thirty copies of an inventory availability report that was valid only at 8 oclock in the morning. Under the new system, they would be relying totally on what they saw in the computer to give information and record orders.

There were some thirty customer service agents involved, dealing with customers around the country and around the world. Making this change would have a huge impact on the owners system. He knew he needed it; he wanted it; he demanded it (after all, his agents were so bogged down in paperwork that sometimes they had to let the phone ring for twenty minutes before answering it). That meant that every day, customers who were ready to order became impatient and offended, hung up, and probably went elsewhere. But the senior vice-president in charge of order-entry customer service was very apprehensive about the changeover to a real-time online system. If the new system had glitches, he told the owner, it could actually destroy the company. At the very least, if it didnt work, it would create an enormous problem.

Under the owners direction, I designed the system. We made a skeleton demonstration for the senior vice-president. He came in, looked at it, and went through the typical order-booking scenarios, doing all the variations that the agents would have to do. After a fifteen-minute presentation, he said, Great job. It will absolutely work, and Im satisfied. The rest of the job was simply filling in the production details, like checking product availability dates and getting input on specific needs and desires from the customer-service manager, the vice-president, and the company president. Proceeding so cautiously, and keeping the users part of the process, guaranteed that the installation would be a huge success. And it was. Every agent was able to answer the phone on the first ring , and the inventory they were promising was actually still available when they promised it.

That illustrates the way to turn a skepticindeed, someone whose job depends on the success of an applicationinto an active proponent of your efforts. Once you get the person in charge behind you, all the other people in that department will fall into line.

It is important to note here that the user for whom you are designing a system can be your best advocate or your worst nightmare. Even difficult or reluctant users can be brought around if the programmer is courteous and respectful. Ask questions and then listen to their requests and suggestions. If users are telling everyone in their department (and perhaps the IT department) how helpful you were and how happy they are with your work, you can imagine the impact on your manager. On the other hand, if they tell your manager they never want to see you in their department again