All the world’s a stage,
And all the men and women merely players:
They have their exits and their entrances;
And one man in his time plays many parts.

— Shakespeare
As You Like It, II, vii

IN THIS CHAPTER, YOU WILL LEARN:

As a systems analyst, you will work on systems development projects with a variety of other people. The cast of characters will change from project to project; the personalities will differ dramatically; and the number of people that you interact with will range from as few as one to as many as several dozen. However, the roles are fairly consistent, and you will see them over and over again.

To be a successful systems analyst requires more than an understanding of the technology of computers. Among other things, it requires interpersonal skills: you will be spending a great deal of your time working with other people, many of whom speak a very different “language” than you do, and many of whom will find your language of computer technology alien and frightening. Thus, it is important to know what expectations such people will have of you and what expectations you should have of them.

This chapter concentrates on the characteristics of the following major categories of “players” that you are likely to encounter in a typical systems development project:

Each of these categories is described next.

3.1 USERS

The first, and by far the most important, player in the systems game is someone known to systems analysts as a user. The user is the person (or group of people) for whom the system is being built. He or she is the person whom you will interview, often in great detail, to learn what features the new system must have to be successful. It should be emphasized that most users don’t refer to themselves as “users”; after all, the word is often used in a different context to describe people addicted to drugs. In some organizations, the data processing organization avoids the problem by using the term customer or owner to identify the user. The user is the “owner” in the sense that he or she receives, or inherits — and thus owns — the system when it is finally built. And the user is the “customer” in at least two important respects: (1) as in so many other professions, “the customer is always right,” regardless of how demanding, unpleasant, or irrational he or she may seem; and (2) the customer is ultimately the person paying for the system and usually has the right or ability to refuse to pay if he or she is unhappy with the product received.

In most cases, it is fairly easy to identify the user (or users): the user is typically the person who makes a formal request for a system. In a small organization, this is usually a very informal process; it may consist of the user picking up the phone and calling the Official Systems Analyst to say, “Hey, Joan! I need a new system to keep track of our new Widget marketing campaign!” In a large organization, the initiation of a systems development project is usually much more formalized. The “request for system survey and study,” as it is sometimes called, usually goes through several levels of approval before the systems analyst gets involved. More on this in Chapter 5.

There are a number of situations where the identity of the real user is not known, or where the systems analyst has little or no opportunity to interact directly with the user. One common example is that of a system being developed by a consulting firm or software company: the interaction between the client organization and the consulting firm may take place between contract officers or other administrative agencies, sometimes with explicit provisos that the systems analyst may not talk directly to the user. Another common example is the development of a software product, where the features and functionality are defined by the marketing department, even though they will not be the people who actually use the system. Even if the system is being developed entirely within a single organization, the “real” user may nominate a spokesperson to work with the systems analyst because he or she is too busy with other work. [1] Obviously, in situations like this there is a distinct possibility of miscommunication: whatever it is that the real user wants the system to do may not be communicated properly to the systems analyst, and whatever it is that the systems analyst thinks he or she is creating for the user may not be properly communicated — not until the entire system has been built, at which point it may be too late! There are two conclusions we can draw from this:

3.1.1 The Heterogeneity of Users

One of the mistakes frequently made by people in the computer field — especially by computer programmers, and sometimes by systems analysts, too — is to assume that all users are the same. “User” as a singular noun implies that the systems analyst will only have to interact with one person; even when it is obvious that more than one user is involved, there is a tendency to think of them as a formless, shapeless, homogeneous group of humans.To say that one user is different from another is, of course, a trite statement: yes, they all have different personalities, different backgrounds, different interests, and so on. But there are some important differences that you must keep in mind in your work as a systems analyst. Here are two ways of categorizing users:

3.1.2 Categorizing Users by Jon Category

On a typical systems analysis project, you will spend a considerable amount of time interviewing users to determine system requirements. But which users? At which level? Naturally, this depends on the project and on the politics within your organization — but you can usually count on interacting with three main job categories: operational users, supervisory users, and executive users. [2] Operational users are the clerical, operational, and administrative people most likely to have the most day-to-day contact with the new system (unless you are building a decision-support system, in which case you may have little or no contact with this group). Thus, in a typical large organization, you may find yourself interviewing secretaries, insurance agents, bookkeepers, shipping clerks, order entry personnel, and “assistants” of all sizes, shapes and colors. For a real-time system, you may be talking with operational users whose titles are engineer, physicist, factory worker, pilot, telephone operator, and so on. You should keep three things in mind when you work with operational-level users:

The analyst who understands basic motivation, why people resist change, and how they resist change, may be able to overcome some of the resistance. Most management books make reference to psychologist A.H. Maslows’ hierarchy of needs. The five categories, from lowest priority to highest, are:

Figure 3.1: The three types of user

Thus, if you find some of the users resisting the idea of a new system, you should think about the possibility of one or more of these needs not being met. It is rare, of course, that a user would worry about the physiological level of need, but it is not at all surprising to find that a user is worried about the loss of his or her job. And it is also common for users (especially the operational users) to worry that a new system will lead to their not being able to identify with their familiar social groups; they fear that they will be confined to a CRT terminal all day and spend all of their time interacting with a computer rather than other humans. The operational user who has become an expert in performing an information-processing task on a manual basis may also feel that a new system will leave his or her “egotistic” needs unfulfilled; and the user who feels that the system will take away the creative aspects of his or her current work may also resist.

Table 3.1: Characteristics of different users

3.1.3 Categorizing Users by Level of Experience

It should be obvious that different users will have different levels of experience; unfortunately, it is common for systems analysts to assume that all users are blithering idiots when it comes to the subject of computers. Perhaps this was a safe assumption ten years ago, but it is likely to get you into a lot of trouble in most organizations today [6]: today, one can distinguish between rank amateurs, cocky novices, and a small (but rapidly growing) number of true computer experts. The amateur user is the one who has never seen a computer and who exclaims loudly and frequently that he or she “doesn’t understand all this computer stuff.” Often, such a user is a middle-aged worker or business person who happily survived 16 years of education and another 10 or 20 years in a job before computers were introduced; however, it is also common to find younger users (those still in their twenties) who find computers boring, intimidating, or irrelevant to their lives.

This presents a challenge to the systems analyst who loves to talk about “on-line access” and “menu-driven human-machine dialogues” or other such terminology —but if the systems analyst does his or her job properly, there is no reason why the user should be interested in or knowledgeable about computers .Indeed, the real problem with the amateur user is somewhat more subtle: he or she may find it difficult to understand the “language” that the systems analyst uses to describe the features, functions and characteristics of the system to be built, even though that language avoids obvious computer-related terminology. As we will see in Parts II and III, the job of systems analysis involves the creation of a number of models of the system to be built.

These models are formal and rigorous representations of a computer system, and at the same time they are abstract representations of the system. Most of the models involve graphics (pictures) supported by detailed text, and the overall representation (which is needed to ensure a formal, rigorous description) strikes some users as overwhelmingly mathematical and thus unreadable. These may be users who remember the difficulty of reading the complex graphical notation used in organic chemistry or the equally complex notation used in differential calculus and algebra. Whatever the reason, the result is the same: quite apart from understanding computer technology, if the user cannot understand the model of the system, there is little chance that he or she will be satisfied with the system when it is finally built. [7]

A second type of user is the one I like to call the “cocky novice,” the person who has been involved in one or two systems development projects, or (even worse) the user who has a personal computer and who has written one or two (ugh) BASIC programs. This user often claims to know exactly what he or she wants the system to do and is prone to point out all the mistakes that the systems analyst made on the last project. This is all fine, except for one thing: the user often becomes far too involved in discussions about the specific technology that will be used to implement the system. Thus, the user may say to the systems analyst, “I need a new order processing system, and I’d like it to be built with a Web front-end connected to our Intranet, and I think we should either use Microsoft Access or Oracle.” These may eventually turn out to be the right technical choices, but it is premature to even consider the hardware, programming language, and database packages before the true requirements of the system have been documented. Indeed, in the extreme case, the user’s “suggestion” about the appropriate hardware and software may turn out to be a “solution looking for a problem,” that is, the discovery that there are underutilized hardware and software resources that can be put to some other use.

There are, of course, some users who really understand systems analysis, as well as the underlying technology of computers (as well as their own business area, too!). It is a pleasure working with these people; indeed, the only problem may be that the user and the systems analyst derive so much pleasure talking about the tools and techniques of systems analysis that they forget that their true objective is to build a functioning system! [8]

3.2 MANAGEMENT

Management is a rather loose term; indeed, the systems analyst is likely to come into contact with several different kinds of managers:

The primary interaction between the systems analyst and all these managers has to do with the resources that will be assigned to the project. It is the systems analyst’s job to identify and document the user’s requirements and the constraints within which the system must be built. These constraints usually consist of resources: people, time, and money. Thus, the systems analyst will eventually produce a document that says, “The new system must carry out functions X, Y, and Z, and it must be developed within six months, with no more than three programmers from the IT department, at a cost of no more than $100,000.” Obviously, management will want an ongoing assurance that the systems development project is staying within these constraints — it is not falling behind schedule or exceeding its budget. But these are issues of project management, not systems analysis. [9] And managers from several different functional areas often form a steering committee that helps prioritize potential development projects so that the most cost-effective projects get done first.There are several points you should keep in mind about managers:

The relationship between management and your systems development project may depend quite a lot on the overall management structure of your organization, especially the relationship of the systems development activities to the rest of the organization. The classical organizational structure is shown in Figure 3.2(a); note that the entire data processing organization reports to the head of finance and accounting. The reason for this is that most large organizations originally introduced computers to help automate their accounting activities (e.g., payroll, general ledger, and accounts receivable). Beginning in the 1970s, some organizations began to realize that this was a rather lopsided organizational structure: it virtually guaranteed that the data processing function would be biased toward accounting applications and would have little interest or expertise in other parts of the organization. And as automated information processing began to permeate the organization (e.g., in manufacturing, marketing, and engineering), some organizations changed to the organization chart shown in Figure 3.2(b). By having the data processing (or IS/IT, as it is sometimes called) group report directly to the president of the organization, it becomes clear to everyone that data processing is just as critical to the organization’s survival as manufacturing, engineering, sales, and so on. However, by the 1980s, some organizations had begun to find that the MIS department had become an “empire,” with its own priorities and politics; user organizations, meanwhile, were finding that they had an ever-growing backlog of new systems waiting to be developed by the MIS department. [10] This coincided with the introduction and rapid proliferation of cheap, powerful personal computers; thus, some user departments began to feel that they could develop their own systems, without relying on a centralized MIS function. As a result, some organizations now have a structure like that shown in Figure 3.2(c); while there is still a central MIS department for such “classic” applications as payroll and general ledger, much of the departmental processing is done by system development groups within the departments.

Figure 3.2(a): A classical organization chart

If you work in an organization characterized by Figure 3.2(a), you may find that the systems analysts and the users in various other departments are not as good as they could be; indeed, you are likely to find that much of the systems development projects are the “transaction processing” type that one would find in an accounting department. If your organization looks more like the one shown in Figure 3.2(b), then there is a good chance that your systems development group has a reasonable amount of political “visibility” high in the organization; however, you may find that there is growing frustration about the backlog of new systems waiting to be developed. And if you are working in an organization characterized by Figure 3.2(c), you are likely to have much more direct contact with the users of your system; indeed, you may be reporting directly to them. And you are more likely to find yourself working on personal computers and other small networks of computer systems purchased directly by the user department.

3.3 AUDITORS, QUALITY ASSURANCE, AND STANDARDS BEARERS

Depending on the size of your project and the nature of the organization you work in, you may or may not have auditors, quality assurance personnel, and/or members of the standards department participating in your project. I have grouped these people into a single category, because their objective and perspective are generally similar, if not the same. The general objective of this group is to ensure that your system is developed in accordance with various external standards (external, that is, to your project): accounting standards developed by your organization’s accounting firm; standards developed by other departments in your organization or by the customer/user who will inherit your system; and possibly standards imposed by various governmental regulatory agencies. In addition, such a group may be concerned with “process management” — i.e., they may want to ensure that your project team has carefully followed the organization’s “official” software development process. [11]  There are three problems that you should anticipate when working with auditors, quality assurance people, or members of the standards department:

Figure 3.2(b): A more current organization chart

3.4 SYSTEMS ANALYST

This is you! The systems analyst is a key member of any systems development project, and the previous sections of this chapter have already given you several examples of how the systems analyst interacts with other players in the project. In a broader sense, the systems analyst plays several roles:

Figure 3.2(c): Systems development within user organizations

This means that, as a systems analyst, you need more than just the ability to draw flowcharts and other technical diagrams! You need people skills to interview users, mediate disagreements, and survive the inevitable political battles that surround all but the most trivial project. You need application knowledge to understand and appreciate the user’s business. You need computer skills to understand the potential uses of computer hardware and software in the user’s business. And (obviously!) you need a logical, organized mind: you must be able to view a system from many different perspectives; you must be able to partition it into levels of subsystems; and you must be able to think of a system in abstract terms as well as physical terms. [13] Nobody ever said the job was easy!

3.5 SYSTEMS DESIGNERS

As we have implied in earlier discussions, the systems designer is the person (or group of people) who will receive the output of your systems analysis work: his or her job is to transform a technology-free statement of user requirements into a high-level architectural design that will provide the framework within which the programmers can work. The nature of this work is discussed in Chapter 22. In many cases, the systems analyst and the systems designer are the same person, or members of the same unified group of people. Even if they are different people, it’s important for the systems analyst and systems designer to stay in close touch throughout the project. The reason for this is the feedback that occurs between systems analysis and systems design: the systems analyst has to provide sufficiently detailed information for the systems designer to concoct a technologically superior design; and the systems designer has to provide sufficiently accurate information so that the systems analyst can tell whether the user requirements he or she is documenting are technologically feasible. Based on information received from the systems designer, the systems analyst may have to negotiate with the user to modify user requirements.

3.6 PROGRAMMERS

One could argue that in the best of all worlds there would be no contact between a systems analyst and a programmer. Particularly on large systems development projects, the systems designers are likely to be a “buffer” between the systems analysts and the programmers; that is, the systems analysts deliver their product (a technology-independent statement of the requirements of the system) to the system designers, and the system designers deliver their product (an architectural description of the hardware and software components that will be used to implement the system) to the programmer. There is another reason why the systems analyst and the programmer may have little or no contact with each other: work is often performed in a strictly serial sequence in many systems development projects. [14] Thus, the work of systems analysis takes place first and is completely finished before the work of programming begins. This means that the systems analyst has finished his or her work and has perhaps been reassigned to a new project before the programmer is even brought into the project. However, there is likely to be some contact between programmers and systems analysts for the following reasons:

3.7 WEB DESIGNERS

While traditional computer systems are typically implemented in such programming languages as COBOL or C++, many of the new systems today are designed to interact with end-users via the World Wide Web. Thus, while there may still be a great deal of “back-end” processing and database activity, there is a “front-end” user-interface that end-users access via browsers such as Netscape Communicator or Microsoft’s Internet Explorer.This means that the development project is likely to include specialists who not only understand such languages as Java and PERL, but also the appropriate graphics and multi-media tools for creating a user interface that will be effective, enticing, user-friendly, and also efficient.

Some aspects of this technology — e.g., the HTML codes for constructing simple Web pages — are widely understood, and can be implemented by both veteran programmers and relatively non-technical individuals. Thus, while the programmers, designers, and other technical members of the team may be assigned the task of implementing the Web front-end, it’s also possible that members of the user community — e.g., marketing personnel, individuals from the graphics art department, etc. — will get involved.

Other aspects of the Web-related portion of the project are much more technical, and require very skilled personnel. In some cases, most or all of the application processing will take place on the “server” hardware that also handles HTML requests for page displays. This may require the application developers to be familiar with development tools (e.g., ColdFusion) and database technologies (e.g., object-oriented databases such as Computer Associates’ Jasmine) that are radically different than the older technologies that run on the back-end mainframes and client-server architectures. And because the Web is intimately connected to the Internet, there’s a good chance that the project team will require specialists who are familiar with networking, security, and other technical aspects of the Internet.

3.8 OPERATIONS PERSONNEL

Just as one could argue that the systems analyst would never encounter a programmer, it could be argued that the systems analyst need never have any interactions with the operations personnel who are responsible for the computer center, telecommunications network, security of the computer hardware and data, as well as the actual running of computer programs, mounting of disk packs, and handling of output from computer printers. All this happens after a new system has not only been analyzed and designed, but has also been programmed and tested.

However, there is more to this than meets the eye: the systems analyst must have some understanding of the constraints imposed on a new system by the operations personnel, for this becomes part of the detailed specification produced by the systems analyst. That is, the systems analyst may produce a document that says, “The new order system must be capable of carrying out functions X, Y, and Z — and, in order to conform to the requirements of the Operations Department, it must occupy no more than 16 megabytes of memory on the mainframe computer. The system must be implemented using PC-compatible workstations running Microsoft Windows operating systems, connected to the company’s XYZ telecommunications network.”

In some cases, the operational details of the system may be a matter of negotiation between the user and the central computer operations group. This is especially common today, since users are often in a position to acquire their own personal computers or department-sized minicomputers. While many of these computers can be operated by clerical or administrative people in the user organization (thus not requiring the specialized talents of the operations personnel), and while many of the computers can operate in a normal office environment (thus not requiring the special wiring and air-conditioning equipment typical of large mainframe computers), it is still generally true that these small machines will have to communicate with the mainframe computer (e.g., to download part of a corporate database, or to upload the results of departmental computing), and it is often true that the small PCs and/or minicomputers have a need to communicate with one another through a local area network or some other telecommunications facility. All this usually involves interaction with the operations personnel; only a truly independent stand-alone system can be built without their assistance and approval. These operational issues are documented in a part of the systems analysis effort known as the user implementation model. This is covered in detail in Chapter 21.

3.8 SUMMARY

As we have seen in this chapter, the systems analyst is an orchestrator, a communicator, and a facilitator. It will become evident in Parts II and III that the systems analyst does a great deal of work on his or her own, but even more work is done in harmony with the other players in the systems game. As a systems analyst, the more you know about the people you will be working with, the better off you will be. All the players are people; and they have different goals, different priorities, and different perspectives. Though they may be publicly committed to its success, they may have hidden agendas that are opposed to one or more aspects of the project.The questions and exercises at the end of this chapter are intended to make you think more about these issues. For additional information, consult Block’s excellent book on project politics (Block, 1982) or even Sun Tzu’s classic book on the art of war (Tzu, 1983).

REFERENCES

QUESTIONS AND EXERCISES