An example of what not to do...

The first chapter in our book discussed different information gathering techniques a systems analysts may use when developing a system. I found this topic interesting because it reminded me of an experience my wife had at work in dealing with the development of a system and her lack of interaction with the system analysts that were involved in the project. My wife works for Dillard’s at their corporate offices in their private label division which oversees Dillard’s in-house brands that are sold in their stores. The system they were using for transferring clothing specifications and details to factories was partly developed in-house while another component they used was purchased from a vendor. The IT department decided to build this other component in-house so that they would no longer need to pay for the vendor software. When gathering the requirements and learning how the existing system worked the IT department relied only on information from my wife’s manager who does not even use the system. She said they did not interview her or others on her team to see how they actually interacted with the system or to determine what functionality they needed from the system. When they released the program it did not have the features the users needed which resulted in my wife’s team being frustrated and less productive. The users were then required to report their issues and complaints to their manager who then relayed the issues to the programmers. I do not know if this process for handling issues was a mandate from the IT department or my wife’s manager but it made the process of getting the system correct even more tedious. The programmers were able to eventually get the program to where it was useable but still had multiple issues. A year after the program was launched the IT management decided to meet with the users and see how they use the program on a daily basis and discuss the issues they have with the software. During the meeting the IT department became aware of software features that were not needed while discovering features that the users wanted but were left out. This meeting with the users yielded the greatest amount of progress in getting the system to meet its intended purpose but it should have been held prior to the development of the system.

I thought this real life situation provided a good example of how important it is to truly understand the business processes of a department or company before developing a system. This example also demonstrates the need for working closely with the individuals who will be using the system and getting feedback from them throughout the development process. The lack of collecting information on the front end resulted in a loss of productivity and an increase of work after the software was initially released. I do not know the entire preparation process the IT department did prior to developing the software but I do know that they did not do an adequate job of gathering information from the users or understanding the business needs of the department.