|
|
CIS 251 -
System Development Methods
Chapter 2: Analyzing the Business Case
Objectives:
This lesson discusses material from chapter 2. Objectives important to
this lesson:
- Business cases
- SWOT analysis
- SDLC framework
- Systems requests and systems review
- Feasibility
- Assignments for the week
Concepts:
A business case is a formal statement of why something
is needed in an enterprise. This is a basic concept that you need to understand
if you are going to work in any large organization. On page 45, 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 begins the chapter with a discussion of a SWOT
analysis, which is discussed 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 44, 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 begins the discussion of a business case, presenting questions
on page 45 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?
(This may trigger a go or a no-go decision.)
- How will we measure success? How are we doing on that measurement now, without the project?
- What are our alternatives?
On pages 45 and 46, 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 47-50, 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 51, 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?
- economic - What will the system cost to build, implement,
and use? What associated costs, such as training and personnel, are
needed for it?
- 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?
- 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.
- The fishbone chart (page 59) can be used to find
causes of problems.
- The organization chart (page 61) is useful to anyone
working for an organization, and for analysts planning work flows and
program designs.
- The Pareto chart (page 62) is better explained in
this text than in previous versions. 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 text also shows us an example of a scatter chart, also called
an XY chart. (page 63) 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 62. 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 63, 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.
|
