Defining Information Gathering

Defining Information Gathering Christine Willems CMGT 555 February 12, 2012 Michele Gamberutti

Defining Information Gathering

A very important step in determining a project is the information gathered about the project. For the system project, the single sign-on process, the techniques used to gather information for this system will be explained in detail, including the reasoning behind this project. Any assumptions made about this project will be described in detail, and the difficulties involved in gathering the requirements will also be included. There are many techniques used to gather information, especially when there is a change involved in the way a system and the users are doing things. First of all, we would not know there was a problem without user feedback. Information collected from the feedback link on the technical support site is taken into account. The feedback is sorted by topic, then by severity, and then by priority. There have been many complaints made by users about the wait time in getting them access to critical systems, especially when they have locked their user accounts, usually because of a forgotten password. Although forgotten passwords are not a high priority, renewing passwords when they expire is. This is normally an automated process, yet not all users get the message to. Therefore, it is up to the platforms team to send reminders out and to reset user passwords when the users do not in time. When the number of users to techs is 20 to 1, and involves seven different systems, the demand for the platforms team is a bit overwhelming. The wait time can last up to a week, in some instances. That is also an important piece of information to look at. How long are users waiting to be re-authorized to use a system? What impact is it having on getting necessary changes done? How much

Defining Information Gathering

productivity is being lost? At what point does it become mission critical (Valacich, George, & Hoffer, 2009)? These are some of the questions that are being asked of the project management team. Statistical reports showing the percentages of down time and uptime for each user on a system may give us some of those answers. This information would not be complete without asking everyone involved their opinion on what the solution should include, or be. With users submitting feedback on how well platforms performed their job or if the user was satisfied with the service they received, there should be a way for the user to suggest their own thoughts about a solution to the problem. These comments could help the platforms team form ideas as to how to fix a problem and where to start working. Other information sources to include in the information gathering process would be the policies that are involved in the user id and password process of each system being used, how each system is set up, and the security around how each system is communicating with the network. Such documents can include organizational mission statements, business plans, organization charts, business policy manuals, job descriptions, internal and external correspondence and reports from prior organizational studies (Valacich, George, & Hoffer, 2009). Assumptions can be made using all of these information resources. Reviewing user input on a problem can help us to understand the cause. Observing users engaged in using the business process and noting what procedures are being used to complete certain steps can give us an idea of how the system is set up to work. Reading over written documentation of business procedures and comparing

Defining Information Gathering

them to notes that were taken can show us how up-to-date the written documentation is. Using these finding can enable us to identify problems or difficulties when we start implementing changes (Valacich, George, & Hoffer, 2009). Procedures are not always error-free, and can be redundant. For instance, when users are using the same user id for two or three different systems to login, it is a duplicated effort. This issue should be brought to the attention of management to see if this process can be combined as one. What if the written documentation is missing a step when a user is being authorized to use a system (Valacich, George, & Hoffer, 2009)? This could be a problem when programming the single sign-on process, since it involves the step-by-step process of each systems login. These issues should be addressed before using the information gathered for development of the single sign-on system. In conclusion, gathering information for such an involved project can make or break a system. A thorough analysis will evaluate where the information is from, and what it means in deciding which avenue of consequence to take. The gathered information helps shape and model the project and what needs to be done to improve what is being tasked (Valacich, George, & Hoffer, 2009). Information should generate questions as to how and why and for whom. In the proposed single sign-on system, the problem is first identified by user feedback about password resets and their personal experience. We are supplied with opinions as to what they expect and what we could do to improve their experience the next time it happens. This is then carried to the management for discussion where

Defining Information Gathering

system documentation can be reviewed and processes observed. Lastly, problems are listed that will need to be mitigated and gone over to ensure proper installation of the project.

Defining Information Gathering

Works Cited Valacich, J. S., George, J. F., & Hoffer, J. A. (2009). Essentials of Systems Analysis and Design. Pearson Education.