Required Characteristics of the Systems Analyst
In the textbook Modern Systems Analysis & Design, Jeffrey A. Hoffer, Joey E. George and Joseph S. Valacich describe four specific characteristics (skills) required of a systems analyst (Hoffer et al, 1998) . They are analytical skills, management skills, technical skills, and interpersonal skills. They break down each category into finer detail.
Analytical skills include systems thinking, organizational knowledge, problem identification, and problem analyzing and solving. Systems think is the ability to identify something as a system or a related set. Organizational knowledge assumes that there is an understanding of the organization and how it works. Problem identification is the ability to identify where you are verses where you want to be. Problem analyzing and solving is the ability to apply bring your knowledge and research to the problem and from the results of the analysis be able to develop a solution to the problem.
Technical skills provide the analyst with the ability to exploit current technology for the purpose of providing a solution to the problem at hand. Staying current with the technologies used to describe, model and build systems allows the analyst to be ready to solve most technology, systems, and pprocess related issues.
Management skills provide what you need to work effectively in a team and give you the skills to be able to manage other people and things. Even if the analyst is not a project leader, management skills are helpful when managing smaller subsections of projects.
Interpersonal skills provide the ability to work with the different constituencies that are involved with you at any given time. Many agree that interpersonal skills are likely one of the most important skills a systems analyst can have.
A research study I did during the fall of 2003 of fifty job postings for a network administrator rated social skills (i.e. interpersonal skills) second only to technology skills. Thirty-nine of fifty job postings or seventy-eight percent included interpersonal skills as a requirement. For this paper I theorized that because of the similarities in the job of a systems analyst and a network administrator that the systems analyst would likely have similar requirements. To test this theory I looked at ten random job postings on monster.com with the title of systems analyst. Eight of the ten jobs either specifically stated that interpersonal skills were required or had responsibilities (project leader, training, communication with vendors, and etc.) that required strong interpersonal skills.
Shirley C. Payne and Elias M Awad (1990) have a similar list of characteristics that overlap with the Hoffer et al (1998) list. Although the lists are have different component elements they highlight the same characteristics overall.
The following table shows a comparison of the two.
| Payne-Awad | Hoffer et al |
| In-depth knowledge of computer technology | Technical skills |
| Knowledge of general fact finding techniques | Analytical skills |
| Training in prototyping techniques | Technical skills, Analytical skills |
| Experience in buy vs. make decisions | Analytical skills |
| Appreciation for human engineering factors in designing interfaces |
Analytical skills |
| Project planning skills | Management skills |
| Understanding of business functions | Analytical skills |
| Excellent verbal and written communication skills | Interpersonal skills |
| Marketing skills | Analytical skills, Management skills |
| Human relations skills | Management skills, Interpersonal skills |
| Organizational skills | Analytical skills, Management skills |
In my job as the Director of Information Technology for a law school it is clear that each of the skills that Hoffer et al lists are important to my role and to my ability to succeed. Perhaps the most obvious are technical skill requirements. In my job and position technical skills are essential to succeed. It is critical that I keep my skills current so that I am able to provide my employer with the best and most appropriate solutions to problems.
Analytical skills are essential also. I have observed that most people that I work with tend to think in terms of their department rather than in terms of the organization. It is interesting to me that each department head will tell you that their department is the most important. While in some ways this is a true statement for each person, it does show that managers often do not think of their department as being a part of a system. My ability to step back and see the organization as a whole without any particular prejudice for or against any department is not only valuable but essential. This also allows me to see trends, issues, and problems that are affecting the school over all rather than limiting my perspective to only one area.
As a department head, management skills are essential as they relate to managing people. But, because I also get involved in projects that affect the school as a whole, I am often in situations where I am working on teams with many different members of the law school. Management skills are essential to keep projects on track to help teams members to work together.
Far too often interpersonal skills are overlooked. As I stated above, the limited research that I did both last year and for this writing shows that interpersonal skills are extremely important to be successful as a systems analyst.
Potential Difficulties of the Role
The systems analyst encounters many difficulties in their role within the organization. This paper focuses on problems related to communication, ethics, and stress.
In his paper on user-designer conflict Aaron H. Konstam (2004) talks about the problem of communication. He observes that systems analysts and users speak different languages related to systems. Users tend to be concerned with the ‘what and when’ of the system and system analysts tend to be concerned with the how of the system. This difference in communication is clearly evident to me in the user-analyst relationship associated with the implementation of PeopleSoft at the law school where I work. Prior to PeopleSoft we ran our own admissions system on a mini-computer located within the law school. When we converted to the PeopleSoft system the user’s greatest concerns were how they would input data and how they would get their reports. The concerns of the systems analysts and technical staff were how they were going to make the system do what the users wanted. Time and time again the users would say ‘this is how I want to do this or that’ or they would simply hand us reports and say this is what I want. We would ask the how questions. For example, if the user was requesting a report that provided details about matriculated students we would ask how we identify a matriculated student. To them it seemed obvious but to the analyst the answer was not so easy. Is the system to consider a student matriculated upon receipt of a confirmation that the student will be coming to SU, or is it when they register for their first course, or is it when they actually show up for their first day of class. These kinds of what-when vs. how questions led to many heated but often productive discussions.
Konstam describes what he calls “the law of routine ignorance” (Konstam 2004). He discusses the difficulty of automating a routine task for someone who is not actively aware of the subtasks associated with the routine. This was again evident during our conversion to the PeopleSoft HRMS system. In one notable example there was a five to seven page statistical report that provided details about the admissions process at the law school. The user absolutely needed this report to be produced after the conversion and needed it to look identical to the report that was produced out of the current system. This was no simple task. A database consultant was hired to spend three months developing and formatting the report. As the development process continued it became evident to the consultant that the inputs to the system had not been fully described and as a result the data that was being generated on the newly developed report was different each time the report was produced when it should have been the same. This turned into a two year project where the initial implementation was abandoned and the development restarted because the user was not able to identify accurately or was not aware of the subtasks associated with the project.
Another difficulty facing the systems analyst is ethics in the systems analysis process. The difficulty arises when the analyst attempts to “understand whether the good is to be maximized for an individual, some specific group, or human society as a whole” (Wood-Harper et al 1996). Unfortunately, analysts are often placed in situations that raise ethical considerations for both the analyst and the user. I was asked by a previous employer to analyze the email of a former employee by looking for specific content. The problem for me was that this former employee had brought a law suit against my employer. Because of my position in the company I had a good understanding abut the validity of the law suit, as did my employer. The email analysis was an attempt to find anything that the employer could use as a defense. Ethical theory is an area that systems analysts should be familiar. Whether it is adherence to a company’s own published code of ethics or it is a struggle with personal ethics this is a subject that provides problems at times that may surprise the analyst and also the employer.
Stress affects everyone in the workplace. The systems analyst is not exempt from stress. The factors contributing to stress in this area include long work hours, insatiable user demand, deadlines that are not met, newly acquired skills are constantly becoming obsolete, shortage of personnel, high turnover, general management’s lack of understanding of MIS, and user resistance to change (Ivancevich et al 1983). Stress not only affects job performance but also affects health. A study by Ivancevich et al (1983) concluded that information systems personnel as a group generally have moderate to low stress in their jobs. My experience and the experiences of my colleagues seem to contradict this conclusion. I find my job to be highly stressful for many of the reasons listed above.
There have been a number of times that my supervisor(s) told me they didn’t understand what I do. That statement keeps me awake at night. If my supervisor doesn’t understand what I do then it is nearly impossible for them to give me proper feedback and therefore difficult for me to gauge how well what I do is aligned with the goals of the organization. In a service oriented job employee turnover and a shortage of help increase the workload and exacerbate the effects of insatiable user demand. More stress!
One of the greatest frustrations I experience is how quickly acquired skills become obsolete. For a time during my career I tried to keep up with vendor certifications. This is a costly and stress inducing exercise in futility. Not only do vendor requirements change frequently but making sure you have the right certifications for marketplace can be maddening and expensive. Beyond that, and more importantly in my opinion, is the task of keeping abreast of all of the changes that are going on in the field. The task of the systems analyst is to provide expert guidance based on knowledge of the organization and the problems it desires to solve, and knowledge of the technology available to solve those problems.
Likely Impact of the Decisions of the Systems Analyst on Personnel
The decisions of the systems analyst can have a positive or negative affect on an organization. Business intelligence, efficiency, power relationships, and user satisfaction are all affected by the decisions that systems analysts make.
If you only look at the marketing it appears that decisions of systems analysts are always successful. On MicroStrategy’s site (Success Story) we find a great success story about how MicroStrategy solved several problems for Lexmark. Questions answered include ‘what are my weekly sales, who are the top retailers and what my inventory levels are’. On Wherewithall’s site (Healthcare Solutions) an interview with a physician describes the many benefits of their knowledge management system and how it has positively affected their ability to access information.
However, there have been some notable disasters in systems analysis. In the book Dangerous Company, James O’Shea and Charles Madigan (1998) describe several failed consulting projects that were the result of flawed systems analysis . Although the focus of this book is on the consultant’s role is provides clear examples of how systems analysis impacts the personnel of an organization. One episode tells of a director of operations for a manufacturing plant who was surprised by the arrival of a machine described as “half the size of a Denny’s Restaurant” (O’shea & Madigan, 1998). He had no idea it was coming and at first refused to accept delivery. Once he contacted one of the senior managers in the corporation it was confirmed that the machine was to be delivered to his location. It goes on to describe how the machine was not appropriate for the task it was intended for. This occurred primarily because none of the employees who were expected to use the product were consulted before the consultants made the buy decision. Further more management did not want to hear that the machine was not adequate for the job and demanded the users make it work. This is a clear example of how power can be exercised over users and how user satisfaction is affected by the decisions of analysts.
“IS professionals exercise technical power over users when they select system design features to which users explicitly object… (Power Over Users) . When systems analysts recommend a product they are making a decision on behalf of many (sometimes thousands) employees within a company. The employees are the ones who have to live with, work with and make work the systems the analyst recommends. This exerts enormous power over users that often sets up resentment between IS and users. In my own work I find that some users are always resentful of any system IS recommends or “imposes” on them. A clear example came through in a recent implementation of a new email system at the law school. We moved from email system “A” to email system “B”. I was not prepared for the backlash the users had against this system. Even though they recognized the need to move to a more sophisticated system and agreed that IS was best prepared to choose and implement the new system the transition took more that 2 years. Users often blamed “the system” for their negative attitude but in every instance where I had the opportunity to talk one on one with someone it was never demonstrated that the “system” was inadequate. It seemed to me then and now that the primary cause of problems with using the system resulted from resentment that we (IS) implemented a new system.
Once you get past the negative aspects of implementing a new system there are benefits that users can gain from the decisions of the systems analyst. Systems that are better suited to the task can be big wins for everyone. The Dangerous Company book describes how the Boston Consulting Group solved a significant problem for Boehringer Mannheim Group (a pharmaceutical company) and in the process spawned an entire industry in the area of disease management.
Conclusion
There are many obstacles in the path of a systems analyst. Assuming you are able to master technical, analytical, managerial, and interpersonal skills you then have to deal with effective communication, ethics on the job, and all of the items that make for a stressful life. Decisions that the systems analyst makes affect the company’s ability to do business. The point of systems analysis is to improve systems and processes, whatever that means to the company. Sometimes users will see the decisions of the analyst as steps toward improvement but often they will see just the opposite.
References
Hoffer, J. A., George, J. F., & Valacich, J. S. (1998). Modern Systems Analysis and Design, Second Edition, Reading, MA: Addison-Wesley (pp. 40-59)
Healthcare Solutions Profile: Thomas C. Barber, MD,
http://www.wherewithall.com/solutions/tomb_profile.html; Internet, accessed February 29, 2004.
Ivancevich, J. M., Napier, H. A., & Wetherbe, J. C (1983) Stress in the Information Systems Professional, ACM Digital Library, accessed from http://libwww.syr.edu; Internet; accessed on February 28, 2004, 58.
Konstam, A. H. , The User-Designer Conflict and Its Resolution, ACM Digital Library, accessed from http://libwww.syr.edu; Internet; accessed on February 28, 2004.
monster.com, http://jobserrch.monster.com, Retrieved: February 29, 2004.
O’Shea, J, & Madigan, C. (1998). Dangerous Company (New York: Penguin Group)
Payne, S. C., and Awad, E. M. (1990). The Systems Analyst As A Knowledge Engineer: Can The Transition Be Successfully Made?, ACM Digital Library, accessed from http://libwww.syr.edu; Internet; accessed on February 28, 2004.
Power Over Users: Its Exercise by System Professionals, 1987, ACM Digital Library, accessed from http://libwww.syr.edu; Internet; accessed on February 28, 2004, 58.
Wood-Harper, A.T., Corder, S., Wood, J.R.G, & Watson, H. (1996) How We Profess: The Ethical Systems Analyst, ACM Digital Library, accessed from http://libwww.syr.edu; Internet; accessed on February 28, 2004.
Success Story: Lexmark,
http://www.microstrategy.com/Customers/Successes/lexmark.asp?PrinterFriendly=1; Internet, accessed February 29, 2004.
December 2003 © Ronald M. Denby
