CIS 251 - System Development Methods

Chapter 2: Analyzing the Business Case

Objectives:

This lesson discusses material from chapter 2. Objectives important to this lesson:

1. Business cases
2. SWOT analysis
3. SDLC framework
4. Systems requests and systems review
5. Feasibility
6. Assignments for the week

Concepts:

A business case is a formal statement of why something is needed in an enterprise. The text explains the use of a business case as part of a request to build or change an information system. More generally, a business case may be needed for any kind of change in an enterprise, such as an equipment purchase, adding new staff, or changing a product line. You have to explain your reasons for making the request, and what the enterprise will gain from the change being requested. The cost of making the change, the projected gain from it, the risk of making the change, and a backout plan for the change are commonly required elements for a business case.

The text continues with a discussion of a SWOT analysis, which they discuss as part of strategic planning. SWOT describes four areas to examine about an enterprise before making a plan for the future:

• Strengths - This is the easy part: what would we be proud to tell an investor or a prospective employee about our company? What are we good or best at doing? What has been replaced to be state of the art?
• Weaknesses - What is not working? What needs to be fixed? What has upper administration told us we have little, no, or reduced funding for?
• Opportunities - What are the quick wins for our company? What could we do to make a big improvement? What projects could we take on to improve our earnings, our stature, or our customer loyalty?
• Threats - Where do we stand to lose market share to a competitor? What changes in laws or regulations will force us to change our practices? What are the competitors doing better than we do?

The text tells us that the SWOT analysis is an important part of the strategic analysis that should take place when planning IT projects. On page 58, the text discusses the evolution of such evaluations, moving away from a function of the IT department only, to a function that often involves representative users and managers as well as analysts who would work on the projects. Joint Application Development (JAD) and Rapid Application Development (RAD) are two methods that support the newer style of projects.

The text returns to the discussion of a business case, presenting questions on pages 58 and 59 that might be asked during the evaluation of a business case.

• What is the reason for the project?
• What is involved in the project?
• What business needs does the project answer?
• What will the project cost, and how long will it take?
• What will be the effect on productivity during the project? Staff who work on it will not be doing their regular work.
• What will be the ROI of the project, and how long will it take to reach it?
• What are the risks of doing and of not doing the project?
• How will we measure success? How are we doing on that measurement now, without the project?
• What are our alternatives?

On page 59, the text lists several classic reasons for systems projects to be started. These are often the key points in system requests, which are the formal means that any entity in the enterprise might fill out to begin a project evaluation. The reasons given in the text:

• To improve service
• To improve performance
• To support new products and services
• To reduce cost
• To provide stronger controls (stronger security)
• To provide more or better information about company operations

On pages 62-64, the text provides a list of factors that affect systems projects. Some are obvious, such as user requests, management directives, and the needs of existing systems. Less obvious factors are the government and the economy. Laws and regulations are often the cause for systems to be created, changed, or retired. Economic pressure may lead to changes that cost less in bad times, or respond to growth in good times.

On page 66, the text discusses the concept of a systems review committee. In large enterprises, there may be several such committees, each having their say over their areas of authority. Whether these committees consist of one person or several, they must consider project requests, and make decisions on whether to pursue them or not.

The text lists several kinds of feasibility considerations that may be used by review committees. Each may be a factor in deciding whether a project request may move forward.

• operational - In short, will the new system work for us? Can we use it, can the users use it, is there any problem that will prevent it from being of value to us?
• technical - Do we have the hardware or software to use this system? Can we upgrade as needed to use it? Does the system limit our future choices or expand them?
• economic - What will the system cost to build, implement, and use? What associated costs, such as training and personnel, are needed for it?
• schedule - Will the timeline of the project take so long that it will bring no value to the company? Will it cost too much to shorten the timeline?

The text continues to discuss several types of charts that may be used to diagnose problems with your systems. One is a Pareto chart, which the text does not explain in detail. Follow this link to get a quick lesson on how to make such a chart in Excel. A Pareto chart tells you which of several problems presents itself most often, telling you which one will get you the most return by fixing it. This choice, however, must be balanced by considering which fix can done most easily or most rapidly. Does your boss care more about fixing the big problem, or about a quick win to put on this week's performance report?

The second example given in the text is a scatter chart, also called an XY chart. Follow this link for a lesson on making one in Excel. This kind of chart may be used to judge whether there is a correlation between two variables, such as number of users connected to a network and network response time, as shown in the text on page 79. Avoid the trap of assuming that this proves a causal relationship. Correlation does not prove causation, but it may point in that direction. In the two charts on page 79, it is clear that there is nearly a linear relation between the variable charted in the lower example that does not exist in the upper example.