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:
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.
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:
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.
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.