Managing the Systems Development Life Cycle:Assess Strategic Information Needs

Assess Strategic Information Needs

Strategic systems planning involves the allocation of systems resources at the macro level, which usually deals with a time frame of 3 to 5 years. This process is very similar to budgeting resources for other strategic activities, such as product development, plant expansions, market research, and manufacturing technology. For most companies, key inputs in developing a sound systems strategy include the strategic business needs of the organization, the legacy system situation, and user feedback.

STRATEGIC BUSINESS NEEDS

All functional areas should support the business strategy of the organization. Because this is most certainly true for the information systems function, we begin with an overview of business strategy. We will briefly review some common aspects of business strategy that bear directly on developing a sound systems strategy.

Vision and Mission

Developing a systems strategy requires an understanding of top management’s vision, which has shaped the organization’s business strategy. Many CEOs communicate their strategic vision through a formal mission statement. In some cases, however, top management’s strategic view for the company is not fully articulated or formulated. Organizations without a well-considered mission statement might have individuals who lack a clear vision for the future managing and directing them. Not surprisingly, companies in this situation often lack a viable systems strategy. Consequently, their management is prone to making knee-jerk responses to information systems needs that emerge out of crisis rather than planning.

Industry and Competency Analysis

In addition to needing a durable vision component, the strategic planning process has many dynamic business factors that drive it, including consolidations, competition, rapidly evolving technology, changes in the regulatory landscape, and increasing demands from stakeholders. Industry analysis and competency analysis are two strategic planning methodologies used to capture information on these factors.

Industry analysis provides management with an analysis of the driving forces that affect its industry and its organization’s performance. Such analysis offers a fact-based perspective on the industry’s important trends, significant risks, and potential opportunities that may impact the business’s performance.

Competency analysis provides a complete picture of the organization’s effectiveness as seen via four strategic filters: resources, infrastructure, products/services, and customers. By assessing these factors, an organization can develop an accurate view of its relative strengths, weaknesses, and core competencies. The analysis helps in developing strategic options, which are based on an understanding of the future environment and the firm’s core competencies. Strategic opportunities may include market-entry options or new product development options.

In developing a business strategy many organizations perform competency analyses on their key competitors as well as potential business partners. By knowing the strengths and weaknesses of competitors, management can identify imminent threats and spot new business opportunities for growth. Similarly, by examining the competencies of potential trading partners, strategic gaps and/or synergies from the partnership may materialize.

LEGACY SYSTEMS

Applications, databases, and business processes that are currently in full operation constitute a firm’s leg- acy systems. Often, these are complicated systems to maintain and enhance. Even in modern companies, the information system is usually a mixture of old and modern technologies, which are critical to the organization’s business success.

Legacy components need to be mapped to current business processes to determine the extent to which they support the mission of the company. This evaluation, together with an assessment of future strategic business needs, will enable management to develop the migration strategy needed to move from legacy systems to future systems with minimum disruption to business operations.

Developing an Architecture Description

System architecture is the structure of components, their interrelationships, and the principles and guide- lines governing their design and evolution over time. An architecture description is a formal description of an information system, organized in a way that identifies the structural properties of the system and defines the components or building blocks that make up the overall information system. This description provides the elements for a plan from which new systems can be developed and commercial packages procured that will work together as harmonious components of the overall system. It also provides the technical foundation for a legacy migration strategy. Finally, the technical advantages that result from an architecture description translate into important business benefits, which are presented in Table 13-1.

USER FEEDBACK

Assessing user feedback involves identifying areas of user needs, preparing written proposals, evaluating each proposal’s feasibility and contribution to the business plan, and prioritizing individual projects. User feedback at this point pertains to substantial, perceived problems rather than minor systems modifications, which are dealt with at a later point in the SDLC. Next, we examine the following key phases of this activity.

1. Recognizing the problem.

2. Defining the problem.

3. Specifying system objectives.

4. Determining project feasibility.

5. Preparing a formal project proposal.

Recognizing the Problem

The need for a new, improved information system may be manifested through various symptoms. In the early stages of a problem, these symptoms may seem vague and innocuous or may go unrecognized.

However, as the underlying source of the problem grows in severity, so do its symptoms, until they are alarmingly apparent. At this point, operations may have reached a state of crisis. Therefore, the point at which the problem is recognized is important. This is often a function of the philosophy of a firm’s management. The reactive management philosophy characterizes an extreme position; in contrast with this is the philosophy of proactive management.

Reactive management responds to problems only when they reach a crisis state and can no longer be ignored. This approach creates a great deal of pressure to solve the problem quickly once it has been recognized. Too often, this results in hurried analysis, incomplete problem identification, shortcuts in design, poor user participation, and the final product of a generally suboptimal solution.

Proactive management stays alert to the subtle signs of problems and aggressively looks for ways to improve the organization’s systems. This management style is more likely to recognize symptoms early and, therefore, implement better solutions. Early problem detection avoids the crisis stage and provides the necessary time for a complete and thorough study.

Who reports problem symptoms? Typically, lower-level managers and operations personnel first report symptoms. Being in continuous contact with day-to-day operations, these individuals are quick to notice operational difficulties with customers, suppliers, and the financial community. As a result, most systems requests originate with lower-level management.

Defining the Problem

The manager must avoid the temptation to take a leap in logic from symptom recognition to problem definition. One must keep an open mind and avoid drawing conclusions about the nature of the problem that may channel attention and resources in the wrong direction. For example, increased product returns, excessive delays in product shipments to customers, excessive overtime for operations personnel, and slow inventory turnover rates are all problem symptoms. These are evidence of underlying problems, but they do not, in themselves, define the problems. The manager must learn enough about the problem to pursue a solution intelligently. The manager cannot, however, collect all the information needed to define the problem accurately and specify a solution. This would require a detailed system evaluation. The manager must specify the nature of the problem as he or she sees it based on the nature of the difficulties identified.

The manager reports this problem definition to the computer systems professionals within the firm. This begins an interactive process between the systems professionals and the user, which results in a formal project proposal that will go before the steering committee for approval. The following three stages in the planning phase—specifying system objectives, determining project feasibility, and preparing a formal project proposal—represent the cooperative efforts of the manager and the systems professional.

Specifying System Objectives

User information requirements need to be specified in terms of operational objectives for the new information system. For example, the user may need an order entry system that can handle 5,000 transactions per hour, maintain up-to-the-minute inventory status, and allow all orders received by 2 pm to be shipped to the customer by the end of the day. At this point, we need only define the objectives in general terms. More precise system requirements will be developed later in the SDLC.

Preliminary Project Feasibility

A preliminary project feasibility study is conducted at this early stage to determine how best to proceed with the project. By assessing the major constraints on the proposed system, management can evaluate the project’s feasibility, or likelihood for success, before committing large amounts of financial and human resources. The acronym TELOS provides guidance for assessing project feasibility. The term stands for technical, economic, legal, operational, and schedule feasibility.

Technical feasibility is concerned with whether the system can be developed under existing technology or if new technology is needed. As a general proposition, the technology in the marketplace is far ahead of most firms’ ability to apply it. Therefore, from an availability viewpoint, technical feasibility is not usually an issue. For most firms, the real issue is their desire and ability to apply available technology. Given that technology is the physical basis for most of the system’s design features, this aspect bears heavily on the overall feasibility of the proposed system.

Economic feasibility pertains to the availability of funds to complete the project. At this point, we are concerned with management’s financial commitment to this project in view of other competing capital projects under consideration. The level of available economic support directly impacts the operational nature and scope of the proposed system. Later, in the system justification and selection step, cost-benefit analysis is used to identify the best system design for the cost.

Legal feasibility involves ensuring that the proposed system is not in conflict with the company’s ability to discharge its legal responsibilities. In previous chapters, we have studied the need to comply with the control requirement laid down in the Foreign Corrupt Practices Act of 1977, Statement on Auditing Standards No. 78, and Sarbanes-Oxley legislation. In addition, many regulations and statutes deal with invasion of privacy and the confidentiality of stored information. We must be certain the proposed system does not breach any legal boundaries.

Operational feasibility pertains to the degree of compatibility between the firm’s existing procedures and personnel skills and the operational requirements of the new system. Implementing the new system may require adopting new procedures and retraining operations personnel. The question that must be answered is: can enough procedural changes be made, personnel retrained, and new skills obtained to make the system operationally feasible?

Schedule feasibility relates to the firm’s ability to implement the project within an acceptable time.

This feasibility factor impacts both the scope of the project and whether it will be developed in-house or purchased from a software vendor. If the project, as originally envisioned, cannot be produced internally by the target date, then its design, its acquisition method, or the target date must be changed.

Preparing a Formal Project Proposal

The systems project proposal provides management with a basis for deciding whether to proceed with the project. The formal proposal serves two purposes. First, it summarizes the findings of the study con- ducted to this point into a general recommendation for a new or modified system. This enables management to evaluate the perceived problem along with the proposed system as a feasible solution. Second, the proposal outlines the linkage between the objectives of the proposed system and the business objectives of the firm. It shows that the proposed new system complements the strategic direction of the firm. Figure 13-2 shows an example of a project proposal.