Chapter 2 Analyzing the Business Case
Analyzing the
Business Case
Chapter 2 explains how to analyze a business case.This
chapter also explains why it is Important to understand
business operations and requirements, how IT projects
support a company's overall strategic plan, how systems
projects get started, and how systems analysts conduct
a feasibility study and perform preliminary investigations, which concludes with a report to management.
Fact-finding techniques that begin at this point and carry
over into later development phases are also described.
The chapter includes three "Case in Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" asks the
systems analyst to consider the Implications of granting
preferential treatment to a system enhancement
request when the request originates with a friend of the
project's manager.
LEARNING OB ECTIVES
Wl1e11 you fi11isb this d1apter, you s/Jould be able
to:
CONTENTS
I . Describe the strategic planning process.
2. Conduct a SWOT analysis.
3. Explam how cools can support strategic
planning.
4. Explain the concept of a business case.
5. Summarize the ~ix main rea~ons for systems
requests.
6. Describe the two factors affecting systems
projects.
7. Explain how systems requests are processed.
8. Explain how systems request feasibility is
assessed.
2. 1 Strategic Planning
Case in Point 2. 1: Pets for Rent
2.2 Strategic Planning Tools
2 .3 The Business Case
2 .4 Systems Requests
2 .5 Factors Affecting Systems Projects
2 .6 Processing Systems Reque~cs
Case in Point 2.2: Actaway Airlines, Part One
2 .7 Assessing Request Feasibility
2 .8 Setting Priorities
Case in Point 2.3: Arra way Airlines, Parr Two
2 .9 The Preliminary Investigation
A Question of Ethics
2 . 10 Summary
Key Term~
Exercises
9. Explain how systems requests arc prioritized.
I 0. Conduct a preliminary invesrigarion.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,...... 111>_... ........ _ .. ~ ........................._ .... ._
Phase I
Systems Planning
2.1 Strategic Planning
2 I
45
STRATEGIC PLANNING
Strategic planning is the process of identifying long-term organizational goals, strategies, and resources. A strategic plan looks beyond day-to-day activities and focuses on
a horizon that is three, five, ten, or more years in the forure. The IT ream must deliver
IT resources ro support the firm's long-term strategic goals. Therefore, IT managers
and systems analysts must understand and participate in strategic planning acriviries.
IT managers ha\'e ro prepare for long-range needs, such as a new darn warehouse,
even as they handle immediate problems, such as a logic bug in the payroll system. In
mosr companies, the IT ream reviews each IT-rela ted proposal, project, and systems
request ro determine if it presents a strong business case, or justification.
T he following sections provide an overview o f strategic planning, a description of
SWOT analysis, and a look at the role of the IT d epartment.
2. 1. 1 Strate gic Planning Ove rview
Strategic plan ning starts with a missio n ~tatemen t that reflects rhe firm's vision, purpose, and v:ilues. Mission statements usually focus o n lo ng-term cha llenges and goa ls,
the importance of the firm's stakeholders, :rn d a commitment to the fi rm's ro le as a
corporate citizen. For example, Google's mission statement posted on their website is
stated succinctly as," ... to organize the world's information and make it universally
accessible and useful."
\Vi ch the mission statement as a backdrop, a f'irm develops short-ter m goals and
objectives. For example, the company might establish one-year, three-year, and fiveyear goals for expanding market share. To achieve those goals, the company might
develop a list of shorter-term objecrives. lf it wants to increase online orders by
30% next year, a company might sec quarterly objectives with monthly milestones.
High-priority objectives arc called crirical success factors. A critical success facto r is
one that must be achie\'ed to fulfill the company's mission.
Objccti\•cs also might include tactical plans, such as creating a new website and
training a special customer support group to answer email inquiries. Finally, the objectives translate into day-to-day business operations, supported by IT and other corporate
resources. The outcome is a sec of business resulcs thar affect company stakeholders.
Pets for Rent is an innovative company that brings puppies to corporate meetings.
The company's CEO says that having puppies in a room with employees in an informal setting
helps break down communication barriers and fosters. a greater sense of teamwork and comradery. Since this is a new company, the CEO has asked you if a mission statement is necessary.
After you review the chapter material, write a brief memo with your views. Be sure to include
good (and not-so-good) examples of actual mission statements that you find on the web.
2. 1.2 SWOT Analysis
The letters SWOT stand for st rengths, weaknesses, opportunities, and threats. A SWOT a na lysis can focus
on a specific product or project, an operating division, the entire company, or the mission statement itself.
The overall aim is to avoid seeking goals that are unrealistic, unprofitable, or unachievable.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Chapter 2 Analyzing the Business Case
2.1 Strategic Planning
46
An enterprise SWOT analysis us ually begins with these questions:
•
•
•
•
What are our strengths, and how can we use them to achieve our business goals?
What are our weaknesses, and how can we reduce or eliminate chem?
\'Qhac arc our opportunities, aod how do we plan ro rake advanragc of them?
\'Qhat are our threats, and ho\V can we assess, manage, and respond m the possible risks?
STRENGTHS
A SWOT analysis examines a
firm's technical, human, and financial resources. In Figure 2-1, the
butlered lists show samples of rypical
strengths, wca kncsscs, opportu nities,
and threats for an organization considering cxp:tnding their web-based
online operations.
As the SWOT process conrinues, management reviews specific
resources, business operations, and
valm1blc assets. For example, suppose
rhat the company owns an imporranr
patent. A SWOT review for rhe parent
might resemble Figure 2-2.
There is no srandard approach to
WEAKNESSES
• Excellent web design staff
• low systems analyst
• Still using 58\/eral legacy
systems
• Budget Increase was turned
down
• Documentation needs updaUng
turnover
• Recently upgraded notwork
THREATS
OPPORTUNmES
• Well-pos1Uoned for expansion
• Can be first with new
software
• High potenbal tor B2B
growth
• Aggressiv e new web
competition
• Impact ol new FCC rules
strategic planning. Some managers
• Other firms oller bener
benefits
believe that a firm's mi sion sratement !.hould contain an inspirational
message to its stakeholders. Others
feel that unless a firm starts with a
FIGURE 2 - 1 A SWOT analysis might produce l"e$Ults similar to those
realistic SWOT assessment, ic might
shown here.
develop a mission statement that is
unachievable. Most companies view
the strategic planning process as a dynamic iorcraction, where the company's mission
statement reflects a long-term horizon, but sets forch goals that arc achievable and
consistent with real-world conditions.
2. 1.3 The Ro le of the IT De partme nt
A systems analyst should be interested in strategic planning because it reflects a
higher level of involvement in supporring the direcrion of rhe project. For example,
while working on rhe same project, one analyst might say, "I am using a CASE cool,"
while another might say, "I am helping the company succeed in a major new business
venture." Systems ana lysts should focus on the larger, strategic role of the IT department even as they carry out their day-to-da y technical tasks.
Experienced analysts know that planning is essentia l for IT project success, and it
must srarr as early as possible. Ca reful planning can help assure chat:
• The proiect supports overall business strategy and operarional needs.
• The project scope is well defined and clearly stated.
• The project goals are realistic, achievable, and tied ro specific statements,
assumptions, constraints, factors, and other inpucs.
(....,..... J:gi( . . . . .
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
47
2.3 The Business Case
SWOT Analysis of a Corporate Patent
During the planning process, management and IT should be closely linked. In
the past, a typical IT department handled
Strengths
Weaknesses
all aspects of systems development and
• Our patent has a hmrted Me
• Our patent covers valuable
consulted uc;er~ only when, and if, the
Whetl 11 expires. the technology
technology that we can use in
depamnent wanted user input. Today,
will no longer be prot8C1ed
popular products
systems development 1c; much more
team-onenred. New approaches to systems
Patent
development, such as agile methods,
typically involve groups of users, managers,
Opportunities
Threats
and IT staff working together right from
• We can use the technology on
• A compehtor might develop
the start of the project.
more products, license 11 to
similar technology thal does
Although ream-oriented development
others, or seek more patents.
not legally lnfnnge our patent.
is the norm, some companies still sec the
role of the IT department as a gatekeeper,
responsible for screening and evaluating
FIGURE 2-2 This SWOT analysis example focuses on a specific asset: a
systems requests. Should the IT department
company patent.
perform the initial evaluation, or shouJd
a cross-functional team do it? The answer
probably depends on rhc company's size, the nature of the system request, and the
scale of the project. For example, in smaller companies or firms where only one person has IT skills, that person acts as a coordinator and consults closely with users and
managers to evaluate systems requests. Larger firms are more likely to use an cvaluarion team or a srsrems review committee.
22
STqATEGIC PLAl'INING TOOLS
Irrespective of the development strategy used, many organizations still rely on the IT
group to provide guidance when it comes to selecting tools to support strategic planning activities. Some analyses srick to tradicional text-based methods, using tvl icrosofc
\'(lord rabies, to pro,•ide srrucrure and clarity. Ochers prefer a spreadsheet, such as
t..1icrosoft Excel, because it is easy to display prioriries and the relative importance of
planning assumptions.
A more sophisticated approach is co use a CASE tool to define and document the
overall environment. Such tools can integrate various statements, entities, data elemencs, and graphical models into an overall structure. The result is more consistency,
better quality, and much less effort for the system analyst. Figure 2-3 shows a cloudbased road mapping software product from Aha! chat provides inccgraced support for
product scracegy visioning and strategy develop1nent.
There arc other strategic planning "cools" that are not CASE tools, bur more techniques that ore sometimes supported by software programs. For example, mind maps,
balanced scorecards, and gap analysis are all valuable techniques thac can be parr of strategic planning in an organizarion. An imporrant role for the systems ana lyst is to know
when each of these rools and cechniques can best be used in particular project conwxcs.
2.3
THE BUSINESS CASE
During the systems planning phase, the IT ream reviews a request co determine if
it presents a strong businesc; case. The term business case refers co the reasons, or
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
--......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__....
~~·~---- ···---~~-.,.-"~
...........
Chapter 2 Analyzing the Business Case
2.3 The Business Case
48
Ahal - - _, -
_,, .....
- -0
-
Strategy first
-
- -
.. ...,............. .,,... ... .......... I"'
....
· -~--
-
....-.;,~
-=---
·- - .--
••• • •
=
-
-..
--
. ._..,_,
............
_.,.
..........
.,_, ..
,_
...,., -"«.,...
.,............,..........
c.....
~
FIGURE 2-l Aha! provides Integrated support for product strategy visioning.
·~• .&.1\. 1
,_
jusrificarion, for a proposal. To perform rhe review, the analysr muse consider rhe
company's overall mission, objectives, and IT needs.
A business case shouJd be comprehensive yet easy to understand. It should
describe rhe project clearly, provide the juscificarioa to proceed, and estimate the project's financial impact. SpecificaUy, che business case should answer questions such as
the following:
•
Why are we doing this project?
•
What is the project about?
•
How docs this solution address key business issues?
•
•
I low much will it cost and how long will it rake?
Will we suffer a productivity loss during the transition?
•
What is the return
•
What arc the risks of doing rhe project? What are the risks of nor doing the
projccr?
•
How will we measure success?
•
What alternatives exist?
OJl
investment and payback period?
Examples of business cases, borh good and bad, can be found on line. Just search
for "sample business case" and examine the structure and content of some of rhe samples available. It is particularly instructive to compare and contrast business cases for
different areas, such as chose for go\•emmenr contracts versus private enterprises.
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U,
..,...,.......,..~
r..a...w...,..._...., ..
-Woip-M ._..,.. -·~•-fllllie<'f•,...
.................,.t11ru ..
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
49
2.4 Systems Requests
2.4
SYSTEMS REQUESTS
Stronger
The starting point for most information
systems projects is called a systems request,
which is a formal way of asking for IT
support. A srsrems requesr might propose
enhancements for an existing system, the
correction of problems, the replacemenr
of an older sy rem, or rhe developmenr of
an enrirel)• new informarion sysrem char is
needed ro support a company's cur renr and
future busine s need .
As Figure 2-4 shows, rhe six main reasons
for ~ystems request are stronger controls,
reduced cost, more information, bener performance, improved service to customers, and
more support for new produces and services.
STRONGER CONTROLS: A system must
Controls
Reduced
Cos1
More
Suppo<1
Systems
Request
Improved
Service
t/
More
_J
I
lnlormatt~
Better
Performance
J
FIGURE 2-4 Six main reasons for systems requests.
have effective controls to ensure that data
is secure and accurate. This is becoming
increasingly important given the number
of darn breaches that seem to occur on a
daily ba!.i . ome common securiry con-
trols include passwords, various levels
of user acces~, and encryption, or coding
data to keep it safe from unauthorized
users. l lardware-based security conrrols
include biometric devices that can identify
a person by a retina scan or b>• mapping
a fingerprint pattern. The technology uses
infrared scanners that create images with
thousands of measurements of personal
physical characteristics, as shown in
Figure 2-5, which displays Apple's Face ID
security mechanism on the iPhonc.
In addition to being secure, data also
must be accurate. Controls ~hou ld minimize data entry errors whenever possible.
For example, if a user enters an invalid
FIGURE 2-5 Apple Face ID uses advanced machine leamirig co recognize users.
customer number, the order processing
system should reject the entry immediately and prompt the user to enter a valid
number. Darn entry controls must be effective without being excessive. If a !.)'Stem
requires users to confirm every item with an "Are you sure? YIN" message, internal
users and customers might complain that the system is not user-friendly.
REDUCED COST: The current system could be expensive ro operate or maintain
as a result of rechnical problems, design weaknesses, or the changing demands of che
busine s. Ir might be possible to adapr the system co newer technology or upgrade
it. On the other hand, cost-benefit analysis might show that a new system would be
more cost effective and provide bener supporr for long-term objectives.
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
--......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__....
~~·~---- ···---~~-.,.-"~
...........
Chapter 2 Analyzing the Business Case
so
2.5 Factors Affecting Systems Projects
MORE INFORMATION: The syscem mighc produce informacion char is insuf-
ficienc, incomple re, or unable ro supporc the company's changing informarion
needs. For example, a syscem chat tracks customer orders mighr nor be capable of
analy1.1ng and predicring marketing rrends. In the face of intense compericion and
rapid product development cycles, managers need the best po~s1ble informacion
to make major decisions on planning, designing, and marketing new products and
services.
BETTER PERFORMANCE: The current system mjght not meec performance require-
mencs. For example, ic n1ighc respond slowly co data inquiries at certain times, or it
mighc be unable co support company growth. Performance limicarions also result
when a system that was designed for a specific hardware configuration becomes
obsolete when new hardware is introduced.
IMPROVED SERVICE: Systems requests often are aimed ac improving service ro cus-
tomers or users within the company. For instance, allowing mutual fund investors ro
check their acco unt balances on a website, storing data on rental car customer preferences, or creating an online college registration system arc all examples of providing
valuable services and increased cusromer satisfaction.
MORE SUPPORT FOR NEW PRODUCTS AND SERVICES: New products and
services often require new types or levels of IT supporc. For example, a sofrware
vendor might offer an a utomacic upgrade service for subscribers; or a package delivery company might add a special service for RFID-tagged shipment!>. In situations like
rhe!>e, it is most likely that addjtional IT support will be required. At the other end of
the speetrum, product obsolescence can also be an important factor in IT planning. As
new products enter the marketplace, vendors often announce that they will no longer
provide support for older versions. A lack of vendor support would be an important
consideracion in deciding whether or not to upgrade.
2.5 f ACTORS AFFECTING
SYSTEMS PROJECTS
internal and external factors affecc every business decision that a company makes,
and IT projects are no exception. Figure 2-6 shows internal and external factors that
shape corporate IT choices.
2.S. I Internal Factors
Internal focrors include the strategic plan, top managers, user requests, information
technology deparcment, existing systems and data, and company finances.
STRATEGIC PLAN: A company's srrategic plan sets the overall direction for the
firm and has an importa nt impact on IT projects. Company goals and objectives rhat
need IT support will generate sysrems requests and influence IT priorities. A strategic
plan that stresses technology rends to create a favorable climate for IT projects that
extends throughout the organization.
TOP MANAGERS: Because significant resources arc required, top management usu-
ally initiates large-scale projects. Those decisions often result from strategic business
goals that require new IT systems, more information for decision making processes,
or better supporr for mission-critical information systems.
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U,
..,...,.......,..~
r..a...w...,..._...., ..
-
Woip-M ._..,.. - ·~•-fllllie<'f •,...
.................,.t11ru ..
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
51
2.5 Factors Affecting Systems Projects
External Fact ors
Lr------...
Teclinology
l..__ _ _ _~J
Suppliers
Government
The Economy
l.
------
Custome~
Competitors
JL- - - - - -
FIGURE 2·6 Internal and CKternal factors that affect IT projecrs.
As users rely more heavily on information systems to perform
their jobs, they arc likely to request even more IT services and support. For example,
USER REQUESTS:
sales rep might request improvemencs to the company's web ire, a more powerful
sales analysis report, a network ro link all sales locations, or an on line S)'Stem that
allows customers to obrain the status of their orders instantly. Or, users might nor
be satisfied with the current system because it is difficult to learn or lacks flexibtliry.
They might want 111formation S)'Stems support for business requirement!> that did nor
even exist when the S)'Stem was first developed.
Systems project requests come also
&om the IT department itself. TT staff members often make recommendations based
on their knowledge of business operations and cechno1ogy trends. IT proposals might
be strictly technical matters, such as replacement of certain nenvork components, or
suggestions might be more business oriented, such as proposing a new reporting or
data collection srstem.
INFORMATION TECHNOLOGY DEPARTMENT:
Errors or problems in existing systems can trigger
requests for sysrcms projects. When dealing with older systems, analyses sometimes
spend coo much rime reacting ro day-to·day problems without looking at underlying
causes. This approach can curn an iniormarion system into a patchwork of corrections and changes that cannot support the company's overa ll business needs. This
problem typically occurs with legacy systems, which are older systems rhat are less
technologically advanced. When migrating ro a new system, IT pl:inners must plan
the conversion of existing data, which is described in detai l in Chapter I I.
EXISTING SYSTEMS AND DATA:
COMPANY FINANCES:
A company's financial status can affect systems projects.
If rhe company is going through a difficult time, the project may be postponed until
there is more cash available to finance the effort. On the other hand, if the company
is enjoying financ ial success, the decision ro embark on a new project may be easier to
make.
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
--......
"-> - "'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~---- ···---~~ - .,.-" ~
...........
Chapter 2 Analyzing the Business Case
52
2.5 Factors Affecting Systems Projects
2.S.2 External Factors
Exrernal facrors include technology, suppliers, cusromers, comperiror<;, the economy,
and government.
Changing technology is a major force affecting business and society in general. For example, the rapid growth of telecommunications, coupled with
increased computing power and continuous miniaturization of electronic components, has created entire new industries and technologies, including the proliferarion
of smarrphones and the app ecosysrem.
Technology also dramatically reshapes existing business opcrarions .
The success of scanner technology resulted in universal bar coding rhat
now affects vi rtually all products. Some industry experts predict that
bar code technology, which is over 40 years o ld, will be overshadowed
in the furure by electronic product code (EPC) technology that uses
RF ID rags to identify and monitor the movement of each individual
product, from the factory floor to the rernil checkout counter.
Quick Response codes (QR Codes), as shown in Figure 2-7, are like
bar codes bur square in shape. T hey contain more information than
traditional ba r codes, but less than RF ID rags. T hey do ha vc the advantage of being less expensive to use than RFID rags, and they can be
printed o n a lmost an ything-including online advertisements.
The Internet-of-Things (JOT) is a newer development that involves
almost all electronic devices con1municating with one another over a comFIGURE 2·7 QR Code.
puter network. The communication can use radio signal~, as with RFID
cags, digical messages, or other means. loT devices can act as sensors, sending important information to centralized data storage and procetising nodes. IoT devices
also raise new security and privacy concerns that the systems analyst must coru.ider.
TECHNOLOGY:
•
SUPPLIERS: With the growth of clcctroaic data interchange (EDI), relationships with
suppliers arc crirically importanr. For example, an automobile company might require
t hat suppliers code their parts in a certain manner to march rhc auto company's inventor)' conrrol system. EDI also enables just-in-time UIT ) inventory ystems that rely on
computer-to-computer data exchange to minimize unneces ary inventory. The purpose
of a JIT system is to provide the right products at the right place at rhc right rime.
Blockchain technology is a promising mechanism for managing upply chains more
powerfully rhan before. Blockchain provides a distributed ledger ysrem that is efficient, secure, transparent. Large companies such as 181\ll are already using blockchain
to improve operarions for their customers, such as the Food Trust product shown in
Figure 2-8 rhar \'<'almart uses for tracking food safety from grower to consumer.
IBM Blockchaln at work
......
,....~.....nc:rwe,..;
-..............
---·--
__...._,.,._...,..,.
----~-----
_........
,.._..___,.
......._.___..........
._.. ...__
..__ .......
...
._
FIGURE 2·8 IBM 81ockcha1n.
Sourt•
(....,..... J:gi ( . . . . .
_,..._
. ..............
....-......."..__
-
.-
»1(
I_,.. 4111.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
-------..... ......
.....--------.
~- )U,
..,...,...... .,..~
-·~•-fllllie<'f•,...
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
53
2.5 Factors Affecting Systems Projects
Customers are virally important 1to any business. Information S)'Stcm
that interact with customers usually receive top prioriry. Many companies implement
customer relationship management (C RM ) systems char integrate all customer-related
event<; and transactions, including marketing, sales, and customer service acnvines.
Vendor-oriented CRNI systems often interconnect with supply chain management
(SCM) systems, which were discu sed in Chapter 1. CR;\it components can provide
automated responses to sales inquiries, online order processing, and inventory tracking. Some suppliers use robots for order fulfillment, such as the Kiva robots shown in
Figure 2-9 rhar Amazon.com uses in their warehouses.
CUSTOMERS:
FIGURE l -9 Amnon Roboucs' Krva robots.
Another RFID application is called electronic proof of delivery (EPOD). Using
EPOD, a supplier uses RFID tags on each crate, case, or shipping unit ro create a digital shipping list. The customer receives the list and scans rbe incoming shipment. If a
discrepancy is detected, iris reported and adjusted automatically. Because they would
be expensive ro invesrigare manually, small shipping inconsistencies might nor otherwise be traced. This is an example of technolog)r- related cost control.
Competition drives many information systems decisions. For
example, if one cellula r telephone provider offers a new cype of digiral service, orher
firm s musr match rhe plan in order to remai n competitive. New product research and
developmcnr, marketing, sales, and service all require IT support.
COMPETITORS:
Economic activity bas a powerful influence on corporate
information management. In a period of economic expansion, firms need to be rea<ly
with i.calable systems that can handle additional volume and growth. Predicting the
business cycle is not an exact science, and careful research and planning are important.
THE ECONOMY:
Federal, stare, and local government regulations directly affect
the design of corporate information systems. For example, up-to-dare fRS reporting
requiremenrs must be designed into a payroll package.
GOVERNMENT:
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
--......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__....
~~·~---- ···---~~-.,.-"~
...........
Chapter 2 Analyzing the Business Case
2.6 Processing Systems Requests
54
2.6
PROCESSING SYSTEMS REQUESTS
In most organizacions, che IT deparcment receives more systems requests than it can hancUe.
Many organizations assign responsibility for evaluating systems requests to a group of
key managers and users. tvlany companies call this group a systems rC\ iew com mince
or a computer resources committee. RegardJess of che name, che objective 1s to use the
combined judgn1ent and experience of severaJ analysts co evaluate project requests.
2.6. 1 Systems Request Forms
Many organizations use a special form for systems requests, similar to the online sample hown in Figure 2-10. A properly designed form streamlines che request process and
ensures consistency. The form must be easy to understand and include clear instructions. It shou ld include enough space for all required information and )hould indicate
what supporting documents
Tech Support Request Sysleni
1/••r1,.:.. ·"~' ::..·, ~· ,,, "'·'"''· 1
are needed. Most companies
use onJine systems request
Submit Roqueet
forms rh:H users submit electronically because the form can
be processed automatically.
When a systems request
form is received, a systems analyst or IT manager examines it
o-awio . . ~
_ _ ., olllllO Cl•
co determine what IT resources
arc required for the preliminary
investigation. A designated
person or a committee then
decides whether m proceed
wirh a prelimmary inve tigation. omerimes, a situation
o a - .... o ...
requires an immediate response.
For example, if the problem
involves a mission-critical sysFIGURE 2- 10 Example of an onhne systems request form.
tem, an IT maintenance team
must restore normal operacions
immediately. \'Qhen the sysrem is functioning properly, die ream conduce a review and
prepares a systems request to docwnent the work that was perfom1ed.
7
•
)
2.6.2 Systems RequestTools
\Xfhen the number of requests su bmitted throug h automated fo rms becomes significant,
or if the requests can origi nate from intern al sou rces as well as extern a I customers,
special-purpose systems request tools can be used to help manage t he work flow. For
example, Figure 2-'l 1 ill ustrates the service request capa bilities from l'nregrify that captures, manages, a nd routes requests to systems analysts based on definable business
rules. In th is way, req uests are tracked and analyzed for improved performance.
2.6.3 Systems Review Committee
Most large companies use a systems review comminee to evaluate systems requests.
Instead of relying on a single individual, a committee approach provides a variety of
experience and knowledge. \Vith a broader viewpoint, a committee can establish priorities more effectively t ban an individual, and one person's bias is less likely ro affect
the decisions.
(....,..... J:gl( . . . . . I_,.. 41 11.,.. ~- )U,
..,...,.......,..~
r..a...w...,..._...., ..
-Woip-M ._..,.. -·~•-fllllie<'f•,...
.................,.t11ru ..
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
SS
2.6 Processing Systems Requests
A rypical committee consists of
C
.
··• •' "'
.... c
•
•
• •
'·'
the IT director and several managers or representarives from other
Service Request Management
departmencs. The IT dirccror usuall)' serve:. as a technical consultant
co ensure that committee members
are aware of crucial issues, prob~
....
&"!ilil• ~ ---·-----~---- .... · - lems, and opportunities.
- ........ - - -..... ,..._ ...................... ~o..
...,.._,___...,
_..
,...
_...
Although a committee offers
._
many advantages, some disadvan--~
s..1.....-r .. tagei. exist. For example, action
.........
on requescs must wait unri l the
committee meets. Another potential disadva ntage of a committee is
that members might favor projects
req uested by their own departments,
and internal polit ical differences
could delay important decisio ns.
M any sma ller companies re ly
FIGURE 2- 11 A service request management system from lntegrify.
on one person to evaluate sysrem
requests instead of a committee. If
only one person has the necessary IT skills and ex perience, t hat person must consult
closely with users and managers throughout t he company to ensure that bu5iness and
operational needs arc considered carefully.
p
::::.
GM11o.rno
-·----_...................
...........
.... .............. ......
---
.. ............. ........ -.........................
...
~
. . . . . . . . . ;ill . . . . . . . . . _ . . . . . . . . . . . ..,.
_ __
--
-- -
--
\Vherher one person or a commitrec is responsible, the goal is to evaluate the
requests and ser priorities. Suppose four requests must be reviewed:
1. The marketing group wanes to analyze current customer spending habits and
forecast future trends.
2. The technical supporr group wanes a cellular link, so sen•ice representatives can
download rechnical dara instantly.
3. The account ing department wanes ro redesjgn customer starements and allow
Internet access.
4. The producrion sraff wants an inventory control system that can exchange dara
wirh major suppliers.
\'<lhich projects should che firm pursue? What criteria should be applied? I low
should p riorities be determined? To answer chose questions, the individual or the
commirtce m use assess rhc feasibiliry of each request.
__ ,
.
.
.
.CASEJN;.P.OINfl:,.2.2:
..
.
,ATITAWAY AIRLINES, ~ RART:: O;,a·>
~
--
----
'
·.:4
You are the IT director at Attaway Airlines, a small regional air carrier.You chair the
company's systems review committee. and you currently are dealing with strong
disagreements about two key projeets. The marketing manager says it is vital to have a new
computerized reservation system that can provide better customer service and reduce operational costs.The vice president of finance is equally adamant that a new accounting system
is needed immediately because it will be very expensive to adjust the current system to new
federal reporting requirements.The VP outranks the marketing manager. and the VP is your
boss.The next meeting, which promises to be a real showdown, is set for 9:00 a.m. tomorrow. How will you prepare for the meeting! What questions and issues should be discussed!
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
-
Chapter 2 Analyzing the Business Case
56
2. 7 Assessing Request Feasibility
2. 7
ASSESSING REQUEST FEASIBILITY
As described in Chapter 1, a sysrerns request must pass several tests to see whether
it is worthwhile to proceed further. The first step is to identify and weed out systems requests that arc not feasible. For example, a request would not be feasible if it
required hardware or software that the company al ready had rejected.
Even if the request is feasible, it might not be necessary. For example, a request
for multiple versions of a report could require considerable design and programming
effort. A bencr alternarive might be to download the server dara ro a personal compurerbased sofnvare package and show users how to produce their own reports. In this
case, rraming users would be a bener investment than producing reports for them.
Somerimes assessing request feasibility is quite simple and can be done in a few
hours. If rhc request involves a new system or a major change, however, extensive
fact-finding and investigation in rhe form of feasibility studies are reqwred.
2.7. I Feasibility Studies
As shown in Figure 2- 12, a feasibi lity study uses four main yardsticks ro measure a
proposal: operational feasibi lity, eco111omic feasibi lity, technical feasibility, and schedule fcasibil icy.
How much effort should go into a feasibility study depends on nature of the
request. For example, if a deparunent wants an existing report sorted in a different
o rder, the analyst can decide quickly whether the request is feasible. On the other
hand, a proposal by the marketing department for a new market research system to
predict sales trends would require much more effort. Jn either case, the systems analyst should ask these important questions:
•
ls the proposal desirable in an operational sense? Is it a practical approach char will
soh·e a problem or rake advantage of an opporruniry to achieve company goals?
•
Is the proposal technically feasible? Are the necessary technical resources and
people available for the project?
• Is rhe proposal economically desirable?
What are the projected saving~ and costs?
Are ocher intangible factors involved, such
as customer satisfocrion or company image?
ls the problem worrh solving, and will
the request result in a sound business
investment?
0pe1"8tlonal
• WiH If be easy to
team and vse?
Schedule
• Can we do 11in
time?
Fualble?
=:=a •
Economic
Will b enefits
e'Kceed costs?
Technlcel
• Do we have the
tech resources?
FIGURE l -1l A feasibility study examines operational, technical, economic,
and schedule factors.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
• Can the proposal be accomplished
within an acceptable rime frame?
To obtain mo re information about a
systems request, ini tial fact-finding migh t
be accomplished by stud ying o rganization
charts, performing interviews, reviewing
current d ocumentation, observing operations, and surveying users. Sometimes,
developing prototypes can provide additional insight into the feasibility of the
request. If the systems request is approved,
more intensive face-finding will continue
during the systems analysis phase.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
57
2.7 Assessing Request Feasibility
2.7.2 O perational Feasibility
Operational feasibi lity means that a proposed system will be used effectively after ir
has been developed. If users have difficulry with a new sysrem, it will nor produce the
expected benefits. Orgamtarional culture can also affect operational feasibility. For
instance, a system that works well in a highly structured workplace might be very
unpopular in a more relaxed corporate culture. Operational feas ibility is difficult ro
measure wirh precision but must be studied very carefully. The follo·wing questions
would help predict a system's operational feasibility:
•
•
•
•
•
•
Does management support the project? Do users support the pro1ecr? ls rhe current !>yi.cem well liked and effectively used? Do users see the need for change?
\Xfill the new system result in a workforce reduction? lf so, what will happen to
the affected employees?
Will the new system require training for users? lf so, is the company prepared
to provide the necessary resources for training current employees?
Will users be involved in planning rhe new system right from the start?
Will rhc new system place any new demands on users or require any operaring
changes? For example, will any information be less accessible or produced less
frequencly? Will performance decJjne in any way? lf so, will an overall gain co
the organizarion outweigh individual losses?
Will customers experience adverse effects in any way, either temporarily or
permanently?
•
Will any risk co rhe company's image or goodwill resulc?
•
Does the development schedule conflict with other company priorities?
•
Do legal or ethical issues need to be considered?
2.7.l Economic Feasibility
Economic feasibility means thar the projected benefits of the proposed !>ystem outweigh the est11nated coses usually considered the total cost of o wnenhip ( fCO),
whic h includes ongoing support and maintenance cosrs, as well as acquisition co~ts.
To determine TCO, the analyst must estimate coses in each of the folio\\ mg a reas:
•
People, including IT staff and users
•
J lardwarc and equipment
•
Software, including in-house development as well as purchases from vendors
•
Formal :.tnd informal craining, including peer-to-peer support
•
•
Licenses and fees
Consulting expenses
•
Facility costs
•
The e~timatcd cost of not developing the system or postponing the project
Tangible co~ts, such as those listed above, usually can be measured in dollars. But
intangible co~ts also must be considered. For exainple, low employee morale might not
have an immediate dollar impact, bur certainly will affect the company's performance.
In addition to costs, tangible and inrangible benefits to the company must be assessed.
The systems review commirtee will use those figures, along with the cost estimates, to
decide whether ro pursue rhe project beyond the preliminary investigation phase.
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
--......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__....
~~·~---- ···---~~-.,.-"~
...........
Chapter 2 Analyzing the Business Case
2. 7 Assessing Request Feasibility
58
Tangible benefi ts are benefits that can be measured in dollars. Tangible benefits
result from a decrease in expenses, an increase in revenues, or both. Examples of tangible benefits include the following:
•
•
•
A new scheduling l>ysrem that reduces overtime
An online package tracking system that improves service and decreases the
need for clerical staff
A sophisticated inventory control system that curs excess inventory and eliminates production delays
lniangible benefits are advantages tbat are difficult to measure in dollars but are
important to the company. Examples of intangible benefits include rhe following:
•
•
A user-friendly system that improves employee job satisfaction
A sales tracking system that supplies berter information for marketing decisions
•
A new website that enhances the company's image
The development timetable must also be considered, because some benefits mighr
occur as soon as rhe system is operational, but others might not rake place until later.
2.7.4 Technical Feasibility
Technical feasibility refers to the technical resources needed to develop, purchase,
install, or operate the system. When assessing technical feasib ility, an analyst should
consider the following points:
•
Does the company have the necessary hardware, software, and network
resources? If not, can those resources be acquired without difficult)•?
•
Docs the company have the needed technical expertise? If not, can it be acquired?
•
Does rhe proposed platform have sufficient capacit} for future needs? If not,
can it be expanded?
Will a prototype be required?
•
•
\Xfill the hardware and software environment be reliable? \Xfill tt integrate with
ocher company information systems, both now and in the future? Will ir mrerface properl y with external systems operated by customer~ and suppliers?
•
Will the combination of hardware and software supply adequate performance?
Do clear expecta tions and performance specifications exist?
•
Will rhe system be able to handle future transaction volume and company
growth?
Keep in mind that systems requests that are not currently technically feasible cao
be resubmitted as new ha rdware, software, or expertise becomes available. Development costs might decrease, or the val ue of benefits might increase enough that a systems request eventua lly becomes feasible. Conversely, an initially feasible project can
be rejected later.
2. 7 .S Schedule Feasibility
Schedule feasibility means rhar a project can be implemented in an acceptable rime
frame. \'V'hen assessing schedule feasibility, a systems analyst must consider the inter·
action between time and costs. For example, speeding up a project schedule might
make a project feasible, but much more expensive.
(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U,
..,...,.......,..~
r..a...w...,..._...., ..
-Woip-M ._..,.. -·~•-fllllie<'f•,...
.................,.t11ru ..
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
59
2.8 Setting Priorities
Other issues that relate ro schedule feasibiliry include the following:
•
•
•
•
•
•
Can the company or the IT ream control the factors chat affect schedule
feasibiliry?
Has management established a firm cimetable for the project?
\Xlhar condition~ must be satisfied during the development of the system?
\Xlill an accelerated schedule pose any risks? If so, arc the risks acceptable?
\Xl11l project management techniques be available to coordinate and control the
project?
Will a project manager be appointed?
Chapter 3 describes various project management tools and techniques.
2.8
SFTTING PRIORITIES
After rejecting systems requests that are not feasible, the systems review committee
must establish priorities for the remaining items. lf tools are used as part of the review
process, the requests may already be in a partially or fully sorted order. The highest
priority goes to project requests that provide the greatest benefit, at the lowest cost, in
the shortest period of rime. Many faccors, however, influence project evaluation.
2.8.1 Dynamic Priorities
It's important to note that many projects are dynamic in nature. For example, projects
chat have adopted an agile merhodology are prone ro rapid changes rhroughout the system development lifecycle. These changes can cause request priorities to change as well.
For example, acquisition costs mighc increase over time, making the project more
expensive than anticipated. This can affect the economic feasibility of a number of
requests. In addition, managers and users somecimes lose confidence in a project. For
all those reasons, feasibiliry anal)•sis and priority setting are ongoing rask that must
be performed throughout the S)'Stems development process.
2.8.2 FactorsThatAffect Priority
When assessing a project's priority, a systems analyst should consider the following:
•
•
•
•
•
•
•
Will the proposed system reduce costs? Where? When? How? By how much?
Will the system increase revenue for the company? Where? When? How? By
how much?
Will the systems project res ul t in more information or produce better results?
I low? Are the results measurable?
Will rhe system serve customers better?
\'(fill the system serve the organization berrer?
Can the project be implemented in a reasonable time period? How long will
the results last?
Are the necessary financial, human, and technical resources available?
Few projects will score high in all areas. Some proposals might not reduce costs
but will provide important new features. Other systems might reduce operating costs
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
--......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__....
~~·~---- ···---~~-.,.-"~
...........
Chapter 2 Analyzing the Business Case
2.9 The Preliminary Investigation
60
substantially but require che purchase or lease of additional hardware. Some systems
might be very desirable but require several years of development before producing
significant benefits.
\'<lhenever possible, the analyst should use tangible costs and benefits that can be
measured in dollars. However, the proposal might invoh·e intangible benefits, such as
enhancing the organization's image, raising employee morale, or improving customer
service. These examples are harder to measu re but should aJ50 be considered.
2.8.3
Disc~tionary
and Nondiscretionary Projects
Pro1eccs where management has a choice in implementing chem are called
di~crecion ary project!;. Projects where no choice exists are called nondiscretionary
projects. Creating a new report for a user is an example of a discretionary project;
adding a reporc required by a new federal law is an example of a nondiscretionary
project.
If a particular project is not discretionary, the systems analyst should ask if it is
really necessary for the systems review committee to evaluate it. Some people believe
th:i t waiting for com111irtee approval delays critical nondiscrecionary projects unnecessarily. Others believe t bat submitting all requests to the systems review keeps the committee aware of all projects that compete for IT resources. As a resul t, the committee
can review priorities and create realistic schedules.
Many nondiscrerionary projects are predictable. Examples include annual updates
ro payroll, cax percentages, or quarterly changes in reporting requirements for an
insurance processing system. By planning ahead for predictable projects, the IT
department manages its resources berrer and keeps the systems review committee fully
informed without needing prior approval in every case.
Back at Ar.u.way Airlines, the morning meeting ended with no agreement between the VP
of finance and the marketing manager. In fact, a new issue arose.The VP now says that the
new accounting system is entided to the highest priority because the federal government
soon will require the reporting of certain types of company-paid health insurance premiums. Because the current system will not handle this report. the VP insists that the entire
accounting system is a nondiscretionary project. As you might expect. the marketing
manager Is upset. Can pare of a project be nondiscretionary? What issues need co be
discussed/ The committee meets again tomorrow. and the members will look to you. as the
IT director, for guidance.
2. 9
THE PRELIMINARY INVESTIGATION
A systems analyst conducts a prelimina ry investigation to study the systems request
and recommend specific action. After obtain ing an authorization to proceed, the
analyst interacts wirh managers, users, and other stakeholders, as shown in the
model in Figure 2-13. The analyst garhers faces about the problem or opportunity, project scope and constraints, project benefits, and estimated development
rime and coses. T he end produce of the preliminary investigation is a report to
management.
r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
.. ~ ........................._ .... ._
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
Phase I
Systems Planning
61
2.9 The Preliminary Investigation
2.9.1 Planning the Preliminary Investigation
Before starting a preliminary inve rigarion, iris importanr co let
Problem or
people know about chc invcstigarion and explain the role of the
Benefits
Opportunity
system analyst. 1\lleetings with key managers, users, and ocher
stakeholders such as the rT staff should be scheduled, to describe
the proiect, e'<plain roles and responsibilities, answer questions,
and invite comments. Interactive communication with users
starts at this point and continues throughout the development
Projec1 Scope
Costs
and Cons1ra1nts
process.
A systems project often produces significant changes in
company operarions. Employees may be curious, concerned, or
even opposed to those changes. It is not surprising ro encounter some user resistance during a preliminary investigation.
Report to Management J
Employee attitudes and reactions arc important and must be
considered.
FIGURE 2- 13 Model ofa preliminary
When interacting with users, use t he word problem careInvestigation. Note the Importance of fact-finding
fully, because ir has a negative meaning. When users are asked
In each of the four areas.
about problems, some will stress current system limita tions
rather than desirable new features or enha ncements. Instead
of focusing on difficulties, question users about additional capabi lity they would
like to have. This approach highlights ways to improve the user's job, provides a
better understanding of operations, and builds better, more positive relationships
with users.
2.9.2 Pe rforming the Preliminary Investigation
During a preluninary investigation, a systems analyst typically follows a series of
steps, as ~hown in Figure 2-14. The exact procedure depends on the nature of the
request, the size of the project, and the degree of urgency.
Step I: Understand t he Problem or O pportunity
lf the systems request mvolves a new informacion system
or a substantial change 111 an existing syscem, sysre1ns
analysts might need co develop a business profile chat
descnbes current business processes and funcrioos, as
explained in Chapter I. Even where the request involves
relatively minor changes or enhancements, how chose
modifications will affect business operations and ocher
information systems must be understood. Often a change
in one system has an unexpected ripple effect on another
system. When a systems request is analyzed, which
departmen ts, users, and business processes are involved
must be determined.
Jn many cases, the systems request does not reveal
the underlying problem, bur only a symptom. For
example, a request to invest igate centralized processing delays might reveal improper scheduling practices
rather than hardware problems. Similarly, a request
for analysis of customer complaints might disclose a
lack of sales representative training, rather than problems with the product.
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
•
•
•
0
Undersland the problem or opponun11y
_J
Dehne fhe pro1ect sc;ope and consframts
Perform lact-fond1ng
• Analyze organlzauon charts
• Review documentauon
• Observe operaflons
• Conducf a user survey
Study usablhty, cost, benefit. and schedule data
Evaluate feaslbllity
0
• Operational
• Technical
• Economic
• Schedule
FIGURE 2- 1 ~ Five main steps in a typical preliminary
invesug~uon.
--......
"-> - "'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__....
~~·~---- ···---~~ - .,.-" ~
...........
Chapter 2 Analyzing the Business Case
2. 9 The Preliminary Investigation
62
A popular rechnique for investigaring causes and effecrs is called a fi 5hbone
diag ram, a shown in Figure 2-15. A fishbone diagram is an analysis cool rhar
represenrs the possible causes of a problem as a graphical ourline. \Vhen using a
fish bone diagram, an analyse firsr scares rhe problem and draws a main bone wirh
sub-bones chat rcpresenr possible causes of rhe problem. In rhe example shown in
Figure 2-15, rhe problem is Low M orale, and rhe analyst has identified four areas
to investigate: £11vironme11t, People, Management, and Mac/1111es. In each area,
the analyst idenrifies possible causes and draws chem as horizontal sub-bones.
For example, Temp too hot or cold is a possible cause in rhe £11viro11me11t bone.
For each cause, the analyse muse dig deeper and ask rhe quesrion: Whar could be
causing this symprom co occur? For example, why is it too hoc? If the answer is a
Faulty thermostat, rhe analyst indicates this as a sub-bone co rhe Temp too hot or
cold cause. In ch is manner, the anal yst adds addirional sub-bones to the diagram,
until he or she uncovers root causes of a problem, rather than just the symptoms.
fl!
••
~- -
---~--
·-
•• , ••
_....... ·--·-
....
•
-
--
•
:.
-
...
FIGURE l - 1S A fishbone diagram displays the causes of a problem.Typically, you must dig deeper to identify
anual causes rather than just symptoms
Step 2: Define the Project Scope and Constraints
Determining the project scope means defining the specific boundaries, or extent, of
the project. For example, a statemen't that, payroll is not being produced accurate/)'
is very general, compared with the statement, overtime pay is 1101 being calc11/ated
correctly (or production workers on the second shift at the Yorktown pla11t. Similarly,
the statement, the project scope is to modify the accounts receivable system, is not
as specific as the sta tement, the project scope is to allow customers to inquire 011/i11e
about acco1111t balances and recent transactions.
Some analysrs find it helpful ro define project scope by creating a list with sections
called Nfust Do, Should Do, Could Do, and W/011't Do. T his list can be reviewed
later, during the systems analysis phase, when the systems requirements document is
developed.
Projects with very general scope definitions are at risk of expanding gradually,
without specific au thorization, in a process called project creep. To avoid thi~
problem, project scope should be defined as clearly as possible. A graphical model
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U,
..,...,.......,..~
r..a...w...,..._...., ..
-Woip-M ._..,.. -·~•-fllllie<'f•,...
.................,.t11ru ..
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
63
2.9 The Preliminary Investigation
that shows the systems, people, and business processes that will be affected is sometimes useful. The scope of the project also establishes the boundaries of the preliminary investigation itself. A systems analyst should limit the focus to the problem at
hand and avoid unnecessary expendirure of time and money.
Along with defining the scope of the project, any constraincs on the '>)'Stem must
be identified. A con~traint is a requirement or condition that the system must .,arisfy
or an outcome that the system must achieve. A constraint can im·olve hardware,
software, rime, policy, law, or cosr. System constraints also define project cope. For
example, if the system must operate with cxisring hardware, that is a constraint that
affects porential solutions. Other examples of consrraincs are:
•
The order entry sy!.rem must accept input from 15 remote site .
•
The human resources information system must produce statistics on hiring
practices.
The new website must be operational by March 1.
•
When examining constraints, their characteristics should be identified, as follows.
PRESENTVERSUS FUTURE: Is t he constraint something that must be met as soon as
the system is developed or modified, or is the constraint necessary ar some fucure time?
Ls the consrrainr due ro a requirement within the
organization, or docs some external force, such as government regulation, impose it?
INTERNAL VERSUS EXTERNAL:
MANDATORY VERSUS DESIRABLE: Is the coosuaint mandatory? ls it absolutely
essential to meet rhe constraint, or is ir merely desirable?
Figure 2-16 shows five examples of constraints. Notice rhar each constraint has
three characterisrics, which arc indjcarcd by ics position in the figure and by the srmbol thac represents the consrrainr, as follows:
Sample Constrai nts Shown byTlming, Type, and Urgency
("'E;';'mple A: New IRS
I ~must be used 1n
!he payroll system as
I
Example B: Sometime neX1
year our largest cus1omer wdl
require a seounty code for all
onhne transactlOlls
as poSSlble
Future
Present
I • Mandatory constraint
•
£ • Desirable constraint
Internal
Example 0 : Starting next
week, the marketing system
must track all repeat visits
to the webslle.
Example C: Managemen1
prefers that the project be
completed now rather
than next quarter
FIGURE
Example E: To reduce raw material
costs. we should build supply chain
management capabthty Into lhe next
versoo of our purcnasmg system
l - t 6 Examples of v.1nous types of constraints.
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
--......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__....
~~·~---- ···---~~-.,.-"~
...........
Chapter 2 Analyzing the Business Case
2. 9 The Preliminary Investigation
64
•
•
The consrraint in Example A is presenr, external, and mandatory.
The constraint in Example B is future, external, and mandatory.
•
The constraint in Example C is present, internal, and desirable.
•
The constrJint in Example D is present, internal, and mandatory.
•
The con rrainr in Example Eis future, interna~ and desirable.
Regardless of the type, all constraints should be identified as early as possible
to avoid future problems and surprises. A clear definition of project scope and constraints avoids misunderstandings that arise when managers assume that the system
will have a certain feature or support for a project, but later find that the feature is
nor included.
Ste p 3: Pe rform Fact-Finding
The object ive of face- finding is to gather data about project usability, costs, benefits, ;ind schedules. Fact-finding involves various techniques, which arc described
below. Depending on what info rmation is need ed to investigate the systems
request, fact-finding mig ht cons ume several hours, days, or weeks. For example, a
change in a report forma t o r data entry screen might requ ire a single telephone call
or emai l message to a use r, whereas a new inventory system wou ld involve a series
of interviews. During fact- finding, the analyst might analyze organization charts,
conduct interviews, review current d ocumentation, observe operations, and carry
out a user survey.
ANALYZE ORGANIZATIO N CHARTS: An analyst will not alway~ know the organi-
.tational structure of departments involved in the study. Organization charts should be
obtained to understand the functions and identify people to interview.
If organization charts are not available, or are out-of-date, the necessary information should be obtained from department personnel and construct the charts, as
shown in Figure 2-17.
Even when c harts are available, their accuracy should be ve rified. Keep in mind
t hat an organization chart shows formal reporting relationships but nor the informal
alignment of a group, which also is important.
CONDUCT INTERVIEWS: The
Customer Service Department
primary merhod of obraining
informatio n during the preliminary
investigation is the interview. The
interviewing process involves a
series of steps:
1. Determine the people to
interview.
2. Establish objecri vcs for t he
interview.
-
3. Develop interview questions.
~
FIGURE 2- 17 Specialo:z.ed tools such as MlcrosoftVisoo an be used to draw
organizational charu. but general purpose presentation tools such as Microsoft
PowerPoint shown here can also be used.
(....,..... J:gi( . . . . .
I_,.. 41 11.,.. .................,.t11ru
-Woip-M ._..,..
..
r..a...w...,..._...., ..
~- )U,
..,...,.......,..~
-·~•-fllllie<'f•,...
4. Prepare for the interview.
5. Conduct the interview.
6. Document the interview.
7. Evaluate rhe interview.
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
65
2.9 The Preliminary Investigation
These seven steps arc discussed in derail in Chapter 4, which describes fact-finding
techniques that occur during the systems analysis phase of the SDLC.
Rememher that the purpose of the interview, and of che preliminary mvestiganon itself, is co uncover facts, nor ro convince others char che project is justified. The
analyst's primary role in an interview is co ask effective questions and listen carefully.
If several people will be asked about the same topic, a standard set of questions for all
the interviews should be prepared. Also be sure to include open-ended que ttons, such
as " \Xlhat else do you think I should know about the system?" or .. Is there any other
relevant information that we have not discussed?"'
\'(!hen conducting interviews during the preliminary investigation, interview managers and supervisors who have a broad knowledge of the system and can provide an
overview of the business processes involved. Depending on the situation, talking to
operational personnel to learn how the system functions on a day-to-day basis may
also be helpful.
REVIEW DOCUMENTATION: Although interviews are an extremely important
method of obtaining information, investigating the current system documentation is
also useful. The documentation might nor be up ro dare, so check with users co confirm that the informa tion is accurate a nd complete.
Another fact-finding method is to observe the current
system in operation. Observe how workers carry out typical tasks. Trace or follow
the actual paths taken by input source documents or output reports. ln addition to
observing operations, consider sampling the inputs or outputs of the system. Using
sampling techniques described in Chapter 4, valuable information about the nature
and frequency of the problem can be obtained.
OBSERVE OPERATIONS:
Interviews can be rime consuming. Sometimes information from a larger group can be obtained by conducting a user survey. In this
case, design a form that users complete and reru rn for cabularion. A survc}' is nor as
Aexible as a series of interviews, bur ir is
less expensive, generally rakes less time,
and can involve a broad cross-secrion of
Pareto Chart: Inventory System Errors
people.
CONDUCT A USER SURVEY:
ANALYZE THE DATA: Systems analysts
use many techniques to locate the source
of a problem. For example, the Pareto
chart is a widely used tool for visualizing
issues that need attention. Named for a
nineteenth century economist, a Pareto
chart is drawn as a vertical bar graph, as
shown in Figure 2- J 8. The bars, which
represent various causes of a problem, are
arranged in descending order, so the team
can focus on the most important causes.
ln the example shown, a systems analyst
mighr use a Pareto chart to learn more
about the causes of inventory system
problems, so that necessary improvements
can be made.
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
-
--
-
-.....
FIGURE l -18 A Pareto chart displays the causes ofa problem. in priority
order. so an analyst can tackle the most lmpon:ant cases first. In this example.
the part number issue would be the obvious starting point.
...................
--......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__....
~~·~---- ···---~~-.,.-"~
...........
Chapter 2 Analyzing the Business Case
2. 9 The Preliminary Investigation
66
The XY chart, somerimes called a scatter diagnim, is anorher problem-solving root.
Often, an :malysr looks for a correlation becween two variables. For example, suppose complainrs are received about network response time, and rhe cause needs robe
derermined. The analyst would rry to identify variables, such as rhe number of users,
to see whecher there is a correlation, or pan ern. Figure 2- 19 shows rwo XY charts
wirh dara samples. The firsr chart sample would suggest thar rhere is no corrclacion
...
-
__ .. .•
.
~-
•
............... --..._
·-
..
0-. .... _
•
-
.A
.
..
II
'
-
•
-
...........
- ....
• .. •
I
- ·- p
~
•
Network Response Time vs. Number of Users
.. .
..
••
..
••
---
•
n ...... t
n...,...1
•
.,..
---
•
•
•
--
••
• p
•
I
. ...
•
......_
Network Response Time vs. Number of Users
..
..
•.....
-1
...
..
"
•
•
- - ..
... r -
•
•
-~·
•
..
FIGURE 2- 19 An XY chart shows correlation between variables, which is very important in
problem solving. Conversely, a lack of correlation suggests that the vari:lbles are independent.
and that you should look elsewhere for the cause.
(....,..... J:gi ( . . . . . I_,.. 41 11.,.. ~- )U,
..,...,...... .,..~
r..a...w...,..._...., ..
-Woip-M ._..,.. -·~•-fllllie<'f•,...
.................,.t11ru ..
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
__.~~ c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
67
2.9 The Preliminary Investigation
between the delays and the number of users, so the analyst would look elsewhere for
the source of the problem. However, if the data resembles the second XY sample, it
indicates a strong relationship between the number of users and the longer response
rimes. Thar informanon would be extremely valuable in the problem-solving process.
Step 4:Analyze Project Usability, Cost, Be nefit, and Schedule Data
During fact-finding, data is gathered about the project's predicted cosrs, anticipated
benefits, and chedule issues that could affect implementation. Before feasibilit y can
be evaluated, this data must be analyzed carefuUy. If interviews were conducted or
surveys used, the data should be tabulated to make it easier to understand. If current
operations were observed, the results should be reviewed and key facts that will be
useful in the feasibihry analysis highlighted. If cost and benefit data were gathered,
financial analysis and impact statements can be prepared using spreadsheets and
other decision-support tools.
Also, time and cost estimates should be developed for the requirements modeling
tasks for the next SDLC phase, systems analysis. Specifically, the following should be
considered:
•
What informa tion must be obta ined, and how will it be gathered and analyzed?
•
Who will conduct the interviews? How many people will be interviewed, and
how much time will be needed to meet with the people and i.umnrnrize their
responses?
\'(fill a survey be conducted? Who will be involved? How much time will it cake
people to complete it? How much rime will it take to tabulate the results?
•
•
How much will it cost to :rnalyze che information and prepare a report with
findings and recommendations?
Step S: Evaluate Feasibility
At chis point, the problem or opportunity has been analyzed, the proiect scope and
consrraincs have been defined, and fact-finding has been performed ro evaluate
project usab1liry, costs, benefits, and time constraints. The next step is to as ess the
project'!> feasibility, beginning wi th reviewing che answers to the questions listed in
Section 2.7. The following guidelines should also be considered:
OPERATIONAL FEASIBILITY: Fact-finding should have included a review of user
needs, requirements, and expectations. When this data is analyzed, look for areas that
might present problems for system users and how chey might be resolved. Because
operational feasibility mea ns that a system will be used effectively, this is a vital area
of concern.
ECONOMIC FEASIBILITY: Using che fact-findi ng data, financia l ana lysis tools can
be applied to :i~sess feas ihiliry. The cost-benefit da ra will be an important factor fo r
management co consider. Also, a cost estimate for the project development ream wi ll
be built into the project management plan.
TECHN ICAL FEASIBILITY: The fact-finding data should identify the hardware, soft-
ware, and network resources needed co develop, install, and operate the system. \~ith this
data, a checklist can be developed that will highlight technical costs and concerns, if any.
SCHEDULE FEASIBILITY: The fact-finding data should include stakeholder expec-
tations regarding acceptable timing and completion dares. As mentioned previously,
.........""_.. ... .-.................
_..__
("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
--......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__....
~~·~---- ···---~~-.,.-"~
...........
Chapter 2 Analyzing the Business Case
2. 9 The Preliminary Investigation
68
often a trade-off exisrs berween a project's schedule and its cosrs. For example,
compressing a projecr schedule mighr be possible, but only if the budget is increased
accordingly co add ext ra personnel. The schedule data will be incorporated into the
pro1cct plan in che form of task durations and milestones.
At rhis stage of the preliminary investigation, there are several alrernarives. It
might be rhat no action is necessary or thar some other srrateg)', such as addirional
training, is needed. To solve a minor problem, a simple solurion might be chosen
wirhour performing further analysis. In other situations, it will be recommended that
rhe project proceed to the next phase, which is systems analysis.
2.9.3 Summarizing the Preliminary Investigation
The fina l cask in the preliminary investigation is to summarize the results and recommendations, which can be conveying to management in a report and/or in a presentation. The written report and the oral presentation are examples of the need for
systems analysts to develop strong conu11unicacions skills. The report includes an
evaluation of the systems request, ao estimate of costs and benefits, and a case for
actio n, which is a summary of che pi:oject reques t and a specific recommenda tion.
T he spcci fie format of a preliminary investigation report varies. A typical report
might consist of the fo llowing sections:
•
/ntroductio11-tbe fi rst section is an overview of che reporc. The introduction
contains a brief description of the system, the name of the person or group
who performed the investigation, and the name of the person or group who
initiated the investigation.
• Systems Request Summary-the summary describes the basis of the systems
request.
•
•
•
•
•
•
findings-the findings section contains the res ults of che preliminar)' investigation, including a descriptjoa of the project's scope, constraints, and
feasibiliry.
Recommendations-a summary of the project request and a specific recommendation. Management will make the final dec1s1on, but the IT department's
input is an important factor.
Pro1ect Roles-this section lists the people who will participate in the project
and describes each person's role.
Time and Cost Estimates- this section describes the cost of acquiring and
installing the system, and che coral cost of ownership during the system's useful
life. Intangible costs a lso shou ld be noted.
Expected Benefits-this section incl udes anticipated tangible and intangible
benefits and a timetable that shows when they are to occur.
Appendix- an ap pendix is included in the report if supporting information
must be attac hed. For example, the interviews conducted might be listed, the
documencacion reviewed, and other sources for the information obtained.
Detailed interview reporrs do not need to be included, but those documents
that support t he report's findings should be retained for future reference.
(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U,
..,...,.......,..~
r..a...w...,..._...., ..
-Woip-M ._..,.. -·~•-fllllie<'f•,...
.................,.t11ru ..
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
__.~~c.....,..~
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I
Systems Planning
2. 10 Summa ry
As a new systems analyst at Premier Financial Services. you are getting quite an education.
You report to the IT manager, who also chairs the systems review committee. Several
months ago. the committee rejected a request from the finance director for an expensive
new accounts payable system because the benefits did not appear to outweigh the costs.
Yesterday. the IT manager's boss asked the IT manager to reconsider the finance director's request. and to persuade the other members to approve it. The IT manager wanted
to discuss the merits of the request, but the discuss ion was cut off rather abruptly. It turns
out the IT manager's boss and the finance director are longtime friends.
The IT manager is now very uncomfortable meeting with her boss. She believes the
directive to reconsider the finance director's request would undermine the integrity of the
systems review process. She feels it would be unethical to grant preferred treatment just
because a friendship is involved. She is thinking of submitting a request to step down as
review committee chair, even though that might harm her career at the company.
Is this an ethical question, or just a matter of office politics? What would you do if you
were the IT manager!
2. I 0
SUMMARY
Systems plann ing is rhe firsr phase of rhe systems development life cycle. Effective
information systems help an organization support irs business processes, carry out its
mission, and serve its stakeholders. During strategic planning, a company examines
its purpose, vision, and values and develops a mission scacement, which leads to goals,
objecttve!>, day-to-day operauons, and business resulcs that affect compan)' stakeholders. SWOT analysis exammes strengths, weaknesses, opponumries, and threats.
S\XIOT analysis can be u ed at the enterprise level and for mdividual pro1ect~.
During the }'Stems planning phase, an analyse reviews the busines~ case, which is
the basis, or reason, for a proposed system. A business case should de cribe the project clearly, provide the jusrificarion to proceed, and estimate rhe project's financial
impact.
Sy~tem~ projects are initiaced co improve performance, provide more information,
reduce costs, strengthen controls, or provide bener service. Various internal and external factors affect syscems projects, such as user requests, top management directives,
existing sy~tems, the IT depa rtment, software and hardware vendors, technology, cu~­
tomers, competitors, the economy, and government.
Duri ng the preliminary investigation, the analyst evaluates the systems request and
determine~ whether the project is feasible from an o perational, technical, economic,
and schedule standpoi nt. Analysts evaluate systems requests on the basis of their
expected costs and benefits, both tangible and intangible.
The steps in the preliminary in vestigation are to understand the problem or opportunity; define the project scope and constraints; perform fact-finding; analyze project
usability, cost, benefit, and schedule dara; evaluate feasibility; and present results and
recommendations to management. During the preliminary investigation, analysts
often use investigative rools such as fishbone diagrams, Pareto charts, and XY charts.
The last cask in a preliminary invescigarion is to prepare a report to management. The
report must include an estimate of time, staffing requirements, cosrs, benefits, and
expected results for the next phase of the SDLC.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._
69
Chapter 2 Analyzing the Business Case
Key Terms
70
Ke y Te rms
biomclric de' kes A mech3ntSm used co uniquely identify a per~n by J rcuna scan or b> mJpping J
fa"al panern.
blod..-h.un A distributed ledger srstem. The technology underl}1ng B11corn.
bu'"''"'' ""'" Refer' to the rca>On>, or ju.cification, for a propo"11.
ca\c: for a•"l1on A part of the prd1m111ary 1n\'e>t1gat1on report to mdna11c:ment that \ummar11e> pro1c.t
rcque\r. and make> ,pcxific recommendation,.
computer resources commim~e A group oi key managers and users responsible for cvaluanng systems
requests. Inc rcrm "systems review commircee ~ is also used.
constraint A requirement or a condirion rhar rhe sysrem must satisf>' or an ourcomc chat 1he system muse
achieve.
critical \Uccc" focwrs Viral objectives that mu>t be achieved for rhe entcrpri>e m fulfill ir' mi,,,ion.
cu,ttuncr rdatiomhip nurna11ement (CRM) l\fany companie; implement 'Y'len1' to mtci;rotc all
cU\lomer·rdarcd event> and tran,action'> including mnrkcrin11, >ale,, and ""l<>mer wrvicc activitics.
discrc1i0Mry projects Where managemenr has a cboice in implementing a pro1ect, rhey arc c;11ied d1screrionJry. l·or example, cre:iring a new reporr for a user is .111 example of .1 discreuonary pro1ccr.
economic fcas1b1lit)' Achieved if the projecred benefits of rhe proposed system ou1we1gh rhc csrirnarcd
cosrs involved in acquiring, installing, and operating ir.
clcccrnnic darn interchange !EDT) The exchange of busine's document\ hctwccn compute" ll'ing a scan·
Jard clcctronk format.
dcuronic produu ~ode (EPCJ Technology char U!>l"> RFID la);) co idcntit) and monicor chc movement of
each 1nd1ndual product, from rhc factory Aoor ro the retail chc~kolll counter.
dcctron1c proof of dcli''l'f} (U'OO) A supplier uses RHD t.igs 011 e.ich cr.ite. case, or shipping unu ro
crearc J d1giral shipping hsr ro verify receipt oi goods.
cncrypuon A process where data is coded (oonverted into unrc.idable char.1cters) so char only those wnh
the required authorization can access the da1a.
fi,hhonc diagram \n analy-;is rool rhar represenrs rhe pos'>ible cau<e<> of a problem a< a graphical nm·
line. ""'.:ailed an bhikawa <liah'l"am.
intang1hlc hencfih Po\1ll•c ouKomcs that a~ difficult to mea~ure 1n dollars. Howc\'cr, intangible hcne·
fib can he very important m che calculation of economic fca>1b1hry. An c'<amplc of an intan111blc hen·
cfir m1ghr he a new wch<ite rhar improve-; a company'' ima11e.
intangible co-.s lrems that are difficulr ro measure in dollar remlS, such a~ employee d1~sa11~focnon.
ln1emc1 of Thing~ (IOT) Devices connected to one anorhcr over a computer nerwork.
j1M m·rimc (]TT) The exchange or dclh·ery of informanon when and where It i< needed. For c-camplc,
just·m·rimc 11wcntory sysrcms rely on compmer-co-compurer darn exchange rn minimize unncccs"3ry
111ven1ory.
111i,)io11 ~1a1c111cnt 1\ documcnr or >ratcmenr rbar <lc;c1·ibes 1hr.: company for Ill• stakeholder; and bricny
' rare' the company's overall purpose, produces, services, and value,.
nond1scrctionary pro1ccts Where managemem has no choice in 1mplemcnt111g a pro1ccr, they ore called
nond1screrionar)'· For example, adding a report required by a new fedcrJI law.
operational
fca~ib1lit)'
A •y,rcm char that will be used effecth•cly afrcr i1 has hccn developed.
Parero chart \vertical har graph named for a nineceench century economist. The bar<, which rcpre<cm
'arn>u., cau~e~ of a problem, are arranged in descending order, o;o rhe reJm can focu< on rhc mmr
11nport.1nt cau>e>.
prd1minal"} 10\C\llga11on An mmal :malysIS to clearly 1dennfy the namre and scope of the business
opportumry or problem. Al,o called a feasibilicy study.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Phase I
Systems Planning
71
Key Terms
pro1cct cr•-ep !"he procco~ b> which projects with ,.et) general scope definirions exp.ind gradual!)." 11h·
out ~pcc1ftc .1u1horua11on.
proi«t \.:ope A ~pc..1fic dctcrmmanon of a pro1en's boundaries or extent.
\c.ttter diagram A tool u\cd hy 'Y'lem anal)\"' co graphicall) show the corrd;mon between two variabl~. Al'-<> c..1llcd an XY chart.
\cbcdulc fcas1biliry A proiect can be 1mplcmemed in an acceptable rune frame.
str.1t1:111c planomg Inc process o( 1dennfy1ng long-rerm orga nizanonal goals. s1rateg1es, and resource.
'iWOT analy\1' An c~ammarion of a company'• srreni,'ths (S), wcaknc•scs (W ), oppnrruni11c' (0), and
threat• (T).
\}'>tern\ rcquc•t A formal appeal m rhe IT departmem rhar describes problem\ or de\ired chanitc' in an
information •>''lean ur hu\lnes• proces;. Ti mighr propose t.>nham:emenl:!> for an exi;uni; 'Y>tem, the
corrcx:1iun of problem,, 01 the devdvpment vf an entirely new system.
systems renew commiuee A group of key nunagers and users responsible for cvalu.11mg systems
requests. The term computer resources committee is somerimes J!so used.
tangible benefit~ Pomivc o utcomes that can be measured in dollars. The)' can resulr from
expenses. an increase in revenues, or botb.
,1
decrc.1se 1n
tangible cmi. f.xpen•cs that haven ~pecific dollar value. Examples include employee o;al.iric• and hard
ware pun.. ha>c,.
U!thnital fca.,ihilil) \Vhcn an ori:ani1:1ri11n ha~ the resources to develop or purcha_,e, 1mtall, and operate
rhc ~JMcm.
101.il co~1 of o" ocrsh1p (TCO) A number used in assessing costs. which tndudes oogomg suppon .ind
numrenJnct costs, .1s well a~ acqu1sinon cosrs.
XY chart A tool used b> S)Stcm analysts 10 graphie<1lly show rhe corrcla1ion between mo \ar1.1hlcs. Also
called J scancr diagram.
~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:
.........,. _ _ .._ ......... ..,
..
..,,.........,..~_.......,_,_,_._....~~
...
...............
_ .... ~---11rt~
-,..~---~ ~
....._
.......... _ _ _ , _ • .......,.. ....................
C'ftlpll"&.-..,~fw
Chapter 2 Analyzing the Business Case
Exercises
72
Exercises
Questions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Why should a S)'Stems analyst be interested in strategic planmng?
Lisr the four factors invoked in a S\'V'OT analysis.
Describe how CASE rools can support strategic planning.
List five que~tions rhe business case should answer.
What arc the six main reasons for sysrems requests?
Explain the two main factors affecting systems requescs.
Describe the role of rhc sy~rems review committee in processing systems requests.
Define operational, economic, technical, and schedule feasibility.
List seven questions the sysrcms analyst should consider when assessing project priorities.
What are rhe five seeps of :i prel iminary investigation?
Discussion Topics
1. One of your coworkers says, "Mission statements are nice, but rhey really don'r change things down
2.
3.
4.
5.
here where rhc work gets done." How would you reply?
Discuss how a company's financial status can affect systems projects.
The vice prc~idenr of accounting ~ays to you, the IT direcror, "This request procedure takes too long.
My people know what they are doing, and their systems requests are necessary and important." She
~uggcsts char the IT deparrmenr bypass rhe initial seeps and immediately get ro work on her requesrs.
What would you say ro her?
When setting prioriries for system requests, the highest priority goes to projects that provide rhe great·
e~t benefit, at the lowest cost, in rhe shortest period of time. H ow would you reconcile projects thar
can produce good results in che shorr rerm versus projects rbac can produce excellent resulcs in rhe
long term?
The final cask 1n rhe preliminar)' invesngation is to summan1e chc r~ults and recommendations in a
report and/o r 1n a presenrarion. Which form of communicarion, wrirren or oral, do you chink is rhe
most effci.-ri'e for come)·ing your findings co managemenc?
Projects
1. Use rhe lnrcrncr rn find rluec examples of corporare mission stacemcncs.
2. Prepare a SWOT anal)·sis of your school or your employer.
3. A mind map is a diagram used ro visua ll y organize information. ldencify a tool rhat supports the crcacion of mind maps and explain how they can be a valuable part of srraregic planning.
4. Visit che website for an IT magazine and find an article chac discusses business cases. Summarize rhe
article and what you learned from it.
5. Think of a problem you have experienced ar school or at work and draw a sample fishbone diagram
with at lease two levels.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _
.. ~ ........................._ .... ._