Problems in the organization

ADS

Managers do not like to conceive of their organization as having problems, let alone talk about them or share them with someone from outside. Good managers, however, realize that recognizing symptoms of problems or, at a later stage, diagnosing the problems themselves and then confronting them are imperative if the business is to keep functioning at its highest potential. Problems surface in many different ways. One way of conceptualizing what problems are and how they arise is to think of them as situations in which goals have never been met or are no longer being met. Useful feedback gives information about the gap between actual and intended performance. In this way feedback spotlights problems.
 

Some instances problems that require the services of systems analysts are uncovered because performance measures are not being met. Problems (or symptoms of problems) with processes that are visible in output and that could require the help of a systems analyst include excessive errors and work performed too slowly, incompletely, incorrectly, or not at all. Other symptoms of problems become evident when people do not meet baseline performance goals. Changes in employee behavior such as unusually high absenteeism, high job dissatisfaction, or high worker turnover should alert managers to potential problems. Any of these changes, alone  or in combination, might be sufficient reason to request the help of a systems analyst.

Although difficulties such as those just described occur in the organization, feedback on how well the organization is meeting intended goals may come from outside, in the form of complaints or suggestions from customers, vendors, or suppliers, and lost or unexpectedly lower sales. This feedback from the external environment is extremely important and should not be ignored. A summary of symptoms of problems and approaches useful in problem detection is provided in Figure 3.1. Notice that checking output, observing or researching employee behavior, and listening to feedback from external sources are all valuable in problem finding.

Defining the Problem

Whether using the classical SDLC or an object-oriented approach, the analyst first defines the problems and objectives of the system. These form the foundation of determining what needs to be accomplished by the system. Methods like Six Sigma  start with a problem definition.

problem definition usually contains some sort of problem statement, summarized in a paragraph or two. This is followed by a series of issues, or major, independent pieces of the problem. The issues are followed by a series of objectives, or goals that match the issues point by point. Issues are the current situation; objectives are the desired situation. The objectives may be very specific or worded using a general statement. Here are some examples of business questions relating to business objectives:

What are the purposes of the business?
Is the business profit or nonprofit?
Does the company plan to grow or expand?
What is the business’s attitude (culture) about technology?
What is the business’s budget for IT?
Does the business’s staff have the expertise?

Needless to say, the systems analyst needs to understand how a business works.
The last part of the problem definition contains requirements, the things that must be accomplished,
along with the possible solutions and the constraints that limit the development of the
system. The requirements section may include security, usability, government requirements, and
so on. Constraints often include the word not, indicating a limitation, and may contain budget restrictions
or time limitations.
The problem definition is produced after completing interviews, observations, and document analysis with the users. The result of gathering this information is a wealth of facts and important opinions in need of summary. The first step in producing the problem definition is to find a num-  ber of points that may be included in one issue. Major points can be identified in the interview in a number of ways:

1.  Users may identify an issue, topic, or theme that is repeated several times, sometimes by different people in several interviews.
2.  Users may communicate the same metaphors, such as saying the business is a journey, war, game, organism, machine, and so on.
3. Users may speak at length on a topic.
4. Users may tell you outright that “This is a major problem.”
5. Users may communicate importance by body language or may speak emphatically on an issue.
6. The problem may be the first thing mentioned by the user.

Once the issues have been created, the objectives must be stated. At times the analyst may have to do a follow-up interview to obtain more precise information about the objectives. After the objectives are stated, the relative importance of the issues or objectives must be determined. If there are not enough funds to develop the complete system, the most critical objectives must be completed first. The identification of the most critical objectives is best done by users (with the support of analysts), because users are domain experts in their business area and in how they work best with technologies in the organization.

One technique is to ask the users to assign a weight for each issue or objective of the first draft of the problem definition. This is a subjective judgment by the user, but, if a number of users all assign weights and they are averaged together, the result might reflect the bigger picture. After the weights have been determined, the problem definition issues and objectives are resequenced in order of decreasing importance, the most important issues listed first. There is software such as Expert Choice (www.expertchoice.com) and other decision support software that can assist with the weighting and prioritizing of objectives. Besides looking through data and interviewing people, try to witness the problem firsthand. When looking at the same situation, an employee may view a problem very differently than a systems analyst does. This also gives analysts the opportunity to confirm their findings. In this way they use multiple methods, thereby strengthening the case for taking appropriate action.

Selection of Projects
Projects come from many different sources and for many reasons. Not all should be selected for further study. You must be clear in your own mind about the reasons for recommending a systems study on a project that seems to address a problem or could bring about improvement. Consider the motivation that prompts a proposal on the project. You need to be sure that the project under consideration is not being proposed simply to enhance your own political reputation or power, or that of the person or group proposing it, because there is a high probability that such a project will be ill-conceived and eventually ill-accepted.

Recall that the various subsystems of the organization are interrelated and interdependent, so a change to one subsystem might affect all the others. Even though the decision makers directly involved ultimately set the boundaries for the systems project, a systems project cannot be contemplated or selected in isolation from the rest of the organization. Beyond these general considerations are five specific criteria for project selection:
1. Backing from management.
2. Appropriate timing of project commitment.
3. Possibility of improving attainment of organizational goals.
4. Practical in terms of resources for the systems analyst and organization.
5. Worthwhile project compared with other ways the organization could invest resources. 

First and foremost is backing from management. Absolutely nothing can be accomplished without the endorsement of the people who eventually will foot the bill. This statement does not mean that you lack influence in directing the project or that people other than management can’t be included, but management backing is essential.

ADS