Valacich J., George J., Hoffer J.A. Essentials of Systems Analysis and Design
Подождите немного. Документ загружается.
Chapter Preview . . .
The acquisition, development, and maintenance
of information systems consume substantial re-
sources for most organizations. Organizations can
benefit from following a formal process for iden-
tifying, selecting, initiating, and planning projects.
The first phase of the systems development life
cycle—systems planning and selection—deals
with this issue. As you can see in Figure 4-1, this
phase consists of two primary activities. In the
next section, you learn about the first activity, a
general method for identifying and selecting proj-
ects and the deliverables and outcomes from this
process. Next, we review the second activity, proj-
ect initiation and planning, and present several
techniques for assessing project feasibility. The
information uncovered during feasibility analysis
is organized into a document called a baseline
project plan. The process of building this plan is
discussed next. Before the project can evolve to
the next phase of the systems development life
cycle—systems analysis—the project plan must
be reviewed and accepted. In the final major sec-
tion of the chapter, we provide an overview of the
project review process.
83
✓
Project Identification and Selection
✓
Project Initiation and Planning
Systems
Planning and
Selection
Systems
Analysis
Systems
Design
Systems
Implementation
and Operation
SDLC
FIGURE 4-1
Systems development life
cycle phase 1, systems
planning and selection.
Phase 1 activities are project
identification and selection
and project initiation and
planning.
84 Part II Systems Planning and Selection
Information Systems
Managers
Formal Planning Groups
Managers and
Business Units
Project 1
Project 2
Project 3
...
Project N
FIGURE 4-2
Three key sources for information
systems projects.
Identifying and Selecting Projects
The first activity of the systems planning and selection phase of the SDLC is proj-
ect identification and selection. During this activity, a senior manager, a business
group, an IS manager, or a steering committee identifies and assesses all possible
systems development projects that a business unit could undertake. Next, those
projects deemed most likely to yield significant organizational benefits, given
available resources, are selected. Organizations vary in their approach to identi-
fying and selecting projects. In some organizations, project identification and
selection is a formal process in which projects are outcomes of a larger overall
planning process. For example, a large organization may follow a formal project
identification process that involves rigorously comparing all competing projects.
Alternatively, a small organization may use informal project selection processes
that allow the highest-ranking IS manager to select projects independently or
allow individual business units to decide on projects after agreeing on funding.
Requests for information systems development can come from three key
sources, as depicted in Figure 4-2:
1. Managers and business units who want to replace or extend an existing
system in order to gain needed information or to provide a new service to
customers
2. Information systems managers who want to make a system more efficient,
less costly to operate, or want to move a system to a new operating
environment
3. Formal planning groups that want to improve an existing system in order
to help the organization meet its corporate objectives, such as providing
better customer service
Regardless of how an organization executes the project identification and
selection process, a common sequence of activities occurs. In the following
sections, we describe a general process for identifying and selecting projects,
and producing the deliverables and outcomes of this process.
The Process of Identifying and Selecting Information
Systems Development Projects
Project identification and selection consists of three primary activities: identi-
fying potential development projects, classifying and ranking projects, and
selecting projects for development. Each of these activities is described next.
Chapter 4 Systems Planning and Selection 85
1. Identifying potential development projects. Organizations vary as to how
they identify projects. This process can be performed by:
쐍 A key member of top management, either the CEO of a small or
medium-size organization or a senior executive in a larger
organization
쐍 A steering committee, composed of a cross section of managers with
an interest in systems
쐍 User departments, in which either the head of the requesting unit or a
committee from the requesting department decides which projects to
submit (as a systems analyst, you will help users prepare such requests)
쐍 The development group or a senior IS manager
Each identification method has strengths and weaknesses. For example,
projects identified by top management have a strategic organizational
focus. Alternatively, projects identified by steering committees reflect the
diversity of the committee and therefore have a cross-functional focus.
Projects identified by individual departments or business units have a
narrow, tactical focus. The development group identifies projects based
on the ease with which existing hardware and systems will integrate with
the proposed project. Other factors, such as project cost, duration,
complexity, and risk, also influence the people who identify a project.
Table 4-1 summarizes the characteristics of each selection method.
Of all the possible project sources, those identified by top management
and steering committees most often reflect the broader needs of the
organization. These groups have a better understanding of overall business
objectives and constraints. Projects identified by top management or by a
diverse steering committee are therefore referred to as coming from a
top-down source.
Projects identified by a functional manager, a business unit, or the
information systems development group are often designed for a
particular business need within a given business unit and may not reflect
the overall objectives of the organization. It’s not that projects identified
by individual managers, business units, or the IS development group are
deficient, but rather that they may not consider broader organizational
issues. Project initiatives stemming from managers, business units, or the
development group are referred to as coming from a bottom-up source.
As a systems analyst, you provide ongoing support for users of these types
of projects and are involved early in the life cycle. You help managers
describe their information needs and the reasons for doing the project.
These descriptions are evaluated in selecting which projects will be
approved to move into the project initiation and planning activities.
In sum, projects are identified by both top-down and bottom-up
initiatives. The formality of identifying and selecting projects can vary
substantially across organizations. Because limited resources preclude the
TABLE 4-1: Common Characteristics of Alternative Methods for Making Information Systems
Identification and Selection Decisions
Project Source Cost Duration Complexity System Size Focus
Top management Highest Longest Highest Largest Strategic
Steering committee High Long High Large Cross-functional
User department Low Short Low Small Departmental
Development group Low–high Short–long Low–high Small–large Integration with existing systems
86 Part II Systems Planning and Selection
TABLE 4-2: Possible Evaluation Criteria When Classifying and Ranking Projects
Evaluation Criteria Description
Value chain analysis Extent to which activities add value and costs when developing products and/or services; information
systems projects providing the greatest overall benefits will be given priority over those with fewer benefits
Strategic alignment Extent to which the project is viewed as helping the organization achieve its strategic objectives and
long-term goals
Potential benefits Extent to which the project is viewed as improving profits, customer service, etc., and the duration
of these benefits
Resource availability Amount and type of resources the project requires and their availability
Project size/duration Number of individuals and the length of time needed to complete the project
Technical difficulty/risks Level of technical difficulty to complete the project successfully within given time and resource
constraints
development of all proposed systems, most organizations have some
process of classifying and ranking each project’s merit. Those projects
deemed to be inconsistent with overall organizational objectives,
redundant in functionality to some existing system, or unnecessary will
not be considered.
2. Classifying and ranking IS development projects. Assessing the merit of
potential projects is the second major activity in the project identification
and selection phase. As with project identification, classifying and ranking
projects can be performed by top managers, a steering committee,
business units, or the IS development group. The criteria used to assign
the merit of a given project can vary based on the size of the organization.
Table 4-2 summarizes the criteria commonly used to evaluate projects. In
any given organization, one or several criteria might be used during the
classifying and ranking process.
As with project identification, the criteria used to evaluate projects
will vary by organization. If, for example, an organization uses a steering
committee, it may choose to meet monthly or quarterly to review
projects and use a wide variety of evaluation criteria. At these meetings,
new project requests are reviewed relative to projects already identified,
and ongoing projects are monitored. The relative ratings of projects are
used to guide the final activity of this identification process—project
selection.
3. Selecting IS development projects. The selection of projects is the final
activity in the project identification and selection phase. The short- and
long-term projects most likely to achieve business objectives are
considered. As business conditions change over time, the relative
importance of any single project may substantially change. Thus, the
identification and selection of projects is an important and ongoing activity.
Numerous factors must be considered when selecting a project, as illus-
trated in Figure 4-3. These factors include:
쐍 Perceived needs of the organization
쐍 Existing systems and ongoing projects
쐍 Resource availability
쐍 Evaluation criteria
쐍 Current business conditions
쐍 Perspectives of the decision makers
Chapter 4 Systems Planning and Selection 87
Existing and
Available
Resources
Perceived and
Real Needs
List of Potential
and Ongoing
Projects
Current
Business
Conditions
Evaluation
Criteria
Decision Outcome
Project
Selection
Decision
• Accept Project
• Reject Project
• Delay Project
• Refocus Project
• End-User Development
• Purchase System
• Modify and Resubmit
FIGURE 4-3
Numerous factors must be
considered when selecting a
project. Decisions can result in
one of seven outcomes.
Top Down
Bottom Up
Schedule of Projects
1. ...
2. ...
3. ...
Evaluate,
Prioritize, and
Schedule
Projects
Sources of
Potential Projects
Project Identification
and Selection
Project Initiation
and Planning
• Top Management
• Steering Committee
• User Departments
• Development Group
FIGURE 4-4
Information systems development
projects come from both top-down
and bottom-up initiatives.
This decision-making process can lead to numerous outcomes. Of course, proj-
ects can be accepted or rejected. Acceptance of a project usually means that
funding to conduct the next SDLC activity has been approved. Rejection means
that the project will no longer be considered for development. However, projects
may also be conditionally accepted; projects may be accepted pending the ap-
proval or availability of needed resources or the demonstration that a particularly
difficult aspect of the system can be developed. Projects may also be returned to
the original requesters who are told to develop or purchase the requested system
themselves. Finally, the requesters of a project may be asked to modify and
resubmit their request after making suggested changes or clarifications.
Deliverables and Outcomes
The primary deliverable, or end product, from the project identification and se-
lection phase is a schedule of specific IS development projects. These projects
come from both top-down and bottom-up sources, and once selected they
move into the second activity within this SDLC phase—project initiation and
planning. This sequence of events is illustrated in Figure 4-4. An outcome of
this activity is the assurance that people in the organization gave careful
88 Part II Systems Planning and Selection
consideration to project selection and clearly understood how each project
could help the organization reach its objectives. Because of the principle of
incremental commitment, a selected project does not necessarily result in a
working system. Incremental commitment means that after each subsequent
SDLC activity, you, other members of the project team, and organization offi-
cials will reassess your project. This reassessment will determine whether the
business conditions have changed or whether a more detailed understanding
of a system’s costs, benefits, and risks would suggest that the project is not as
worthy as previously thought. In the next section, we discuss several tech-
niques for gaining a thorough understanding of your development project.
Initiating and Planning Systems Development Projects
Many activities performed during initiation and planning could also be com-
pleted during the next phase of the SDLC—systems analysis. Proper and
insightful project initiation and planning, including determining project scope
and identifying project activities, can reduce the time needed to complete later
project phases, including systems analysis. For example, a careful feasibility
analysis conducted during initiation and planning could lead to rejecting a proj-
ect and saving a considerable expenditure of resources. The actual amount of
time expended will be affected by the size and complexity of the project as well
as by the experience of your organization in building similar systems. A rule of
thumb is that between 10 and 20 percent of the entire development effort should
be expended on initiation and planning. In other words, you should not be re-
luctant to spend considerable time and energy early in the project’s life in order
to fully understand the motivation for the requested system.
Most organizations assign an experienced systems analyst, or team of ana-
lysts for large projects, to perform project initiation and planning. The analyst
will work with the proposed customers—managers and users in a business
unit—of the system and other technical development staff in preparing the final
plan. Experienced analysts working with customers who well understand their
information services needs should be able to perform a detailed analysis with
relatively little effort. Less experienced analysts with customers who only
vaguely understand their needs will likely expend more effort in order to be
certain that the project scope and work plan are feasible.
The objective of project initiation and planning is to transform a vague system
request document into a tangible project description, as illustrated in Figure 4-5.
Effective communication among the systems analysts, users, and management
is crucial to the creation of a meaningful project plan. Getting all parties to agree
on the direction of a project may be difficult for cross-department projects when
different parties have different business objectives. Projects at large, complex
organizations require systems analysts to take more time to analyze both the
current and proposed systems.
In the remainder of this chapter, we describe how a systems analyst develops
a clear project description.
The Process of Initiating and Planning Systems
Development Projects
As its name implies, two major activities occur during project initiation and
project planning. Project initiation focuses on activities that will help orga-
nize a team to conduct project planning. During initiation, one or more
analysts are assigned to work with a customer to establish work standards
and communication procedures. Table 4-3 summarizes six activities per-
formed during project initiation.
Incremental commitment
A strategy in systems analysis
and design in which the project
is reviewed after each phase,
and continuation of the project
is rejustified in each of these
reviews.
Business case
A written report that outlines the
justification for an information
system. The report highlights
economic benefits and costs and
the technical and organizational
feasibility of the proposed system.
Chapter 4 Systems Planning and Selection 89
Vague System Request
Tangible Project Description
Technical Staff
Systems Analyst
Customers of the
Proposed System
FIGURE 4-5
The systems analyst transforms
a vague systems request into a
tangible project description during
project initiation and planning.
The second activity, project planning, focuses on defining clear, discrete tasks
and the work needed to complete each task. The objective of the project plan-
ning process is to produce two documents: a baseline project plan (BPP) and
the project scope statement (PSS). The BPP becomes the foundation for the re-
mainder of the development project. It is an internal document used by the
development team but not shared with customers. The PSS, produced by the
project team, clearly outlines the objectives of the project for the customer. As
with the project initiation process, the size, scope, and complexity of a project
dictate the comprehensiveness of the project planning process and the result-
ing documents. Further, numerous assumptions about resource availability and
potential problems will have to be made. Analysis of these assumptions and sys-
tem costs and benefits forms a business case. Table 4-4 lists the activities per-
formed during project planning.
Deliverables and Outcomes
The major outcomes and deliverables from project initiation and planning are
the baseline project plan and the project scope statement. The baseline project
plan (BPP) contains all information collected and analyzed during the project
initiation and planning activity. The plan contains the best estimate of the project’s
TABLE 4-3: Types of Activities Performed during Project Initiation
• Establishing the project initiation team
• Establishing a relationship with the customer
• Establishing the project initiation plan
• Establishing management procedures
• Establishing the project management environment and project workbook
• Developing the project charter
Baseline project
plan (BPP)
One of the major outcomes and
deliverables from the project
initiation and planning phase. It
contains the best estimate of the
project’s scope, benefits, costs,
risks, and resource requirements.
90 Part II Systems Planning and Selection
scope, benefits, costs, risks, and resource requirements given the current under-
standing of the project. The BPP specifies detailed project activities for the next
life cycle phase—systems analysis—and provides less detail for subsequent proj-
ect phases (because these depend on the results of the analysis phase). Similarly,
benefits, costs, risks, and resource requirements will become more specific and
quantifiable as the project progresses. The project selection committee uses the
BPP to help decide whether to continue, redirect, or cancel a project. If selected,
the BPP becomes the foundation document for all subsequent SDLC activities;
however, it is updated as new information is learned during subsequent SDLC
activities. We explain how to construct the BPP later in the chapter.
Assessing Project Feasibility
Most information systems projects have budgets and deadlines. Assessing
project feasibility is a required task that can be a large undertaking because it
requires you, as a systems analyst, to evaluate a wide range of factors. Although
the specifics of a given project will dictate which factors are most important,
most feasibility factors fall into the following six categories:
쐍 Economic
쐍 Operational
쐍 Technical
쐍 Schedule
쐍 Legal and contractual
쐍 Political
The analysis of these six factors forms the business case that justifies the
expenditure of resources on the project. In the remainder of this section, we
examine various feasibility studies, beginning with economic feasibility.
To help you better understand the feasibility assessment process, we examine
a project at Pine Valley Furniture. Jackie Judson, Pine Valley Furniture’s (PVF)
vice president of marketing, prepares a system service request (SSR), illustrated
in Figure 4-6, to develop a customer tracking system. Jackie feels that this system
would allow PVF’s marketing group to better track customer purchase activity
and sales trends. She also feels that, if implemented, the Customer Tracking
System (CTS) would help improve revenue, a tangible benefit, and improve em-
ployee morale, an intangible benefit. PVF’s Systems Priority Board selected this
project for an initiation and planning study. The board assigned senior systems
TABLE 4-4: Activities Performed during Project Planning
• Describing the project scope, alternatives, and feasibility
• Dividing the project into manageable tasks
• Estimating resources and creating a resource plan
• Developing a preliminary schedule
• Developing a communication plan
• Determining project standards and procedures
• Identifying and assessing risk
• Creating a preliminary budget
• Developing a project scope statement
• Setting a baseline project plan
Chapter 4 Systems Planning and Selection 91
Sales growth at PVF has caused a greater volume of work for the marketing department. This volume of
work has greatly increased the volume and complexity of the data we need to deal with and understand.
We are currently using manual methods and a complex PC-based electronic spreadsheet to track and
forecast customer buying patterns. This method of analysis has many problems: (1) We are slow to catch
buying trends as there is often a week or more delay before data can be taken from the point-of-sale
system and manually entered into our spreadsheet; (2) the process of manual data entry is prone to errors
(which makes the results of our subsequent analysis suspect); and (3) the volume of data and the
complexity of analyses conducted in the system seem to be overwhelming our current system—sometimes
the program starts recalculating and never returns anything, or it returns information that we know
cannot be correct.
SERVICE REQUEST
I request a thorough analysis of our current method of tracking and analysis of customer purchasing
activity with the intent to design and build a completely new information system. This system should
handle all customer purchasing activity, support display and reporting of critical sales information, and
assist marketing personnel in understanding the increasingly complex and competitive business
environment. I feel that such a system will improve the competitiveness of PVF, particularly in our ability
to better serve our customers.
IS LIAISON
SPONSOR
Pine Valley Furniture
System Service Request
REQUESTED BY
DEPARTMENT
LOCATION
CONTACT
TYPE OF REQUEST
PROBLEM STATEMENT
URGENCY
DATE:Jackie Judson
Marketing
Headquarters, 570c
Tel: 4-3290 FAX: 4-3270 e-mail: jjudson@pvf.com
September 1, 2012
[
[
[
]
]
]
[
[
[
]
]
]
New System
System Enhancement
System Error Correction
Immediate—Operations are impaired or opportunity lost
Problems exist, but can be worked around
Business losses can be tolerated until new system installed
X
X
Jim Woo (Tel: 4-6207 FAX: 4-6200 e-mail: jwoo@pvf.com)
Jackie Judson, Vice President of Marketing
TO BE COMPLETED BY SYSTEMS PRIORITY BOARD
[
[
[
[
]
]
]
]
Request approved
Recommend revision
Suggest user development
Reject for reason
Assigned to
Start date
FIGURE 4-6
System service request (SSR) for the Customer Tracking System at Pine Valley Furniture. The SSR includes contact information,
a problem statement, service request statement, and liaison contact information.
analyst Jim Woo to work with Jackie to initiate and plan the project. At this point
in the project, all project initiation activities have been completed: Jackie
prepared an SSR, the selection board reviewed the SSR, and Jim Woo was as-
signed to work on the project. Jackie and Jim can now focus on project planning
activities, which will lead to the baseline project plan.
Tangible benefit
A benefit, derived from the
creation of an information
system, that can be measured in
dollars and with certainty.
92 Part II Systems Planning and Selection
TANGIBLE BENEFITS WORKSHEET
Customer Tracking System Project
Year 1 through 5
A. Cost reduction or avoidance $ 4,500
B. Error reduction 2,500
C. Increased flexibility 7,500
D. Increased speed of activity 10,500
E. Improvement in management
planning or control 25,000
F. Other
__________________________________________
0
_______
TOTAL Tangible Benefits $50,000
FIGURE 4-7
Tangible benefits worksheet for the
Customer Tracking System at Pine
Valley Furniture.
Assessing Economic Feasibility
A study of economic feasibility is required for the baseline project plan. The
purpose for assessing economic feasibility is to identify the financial bene-
fits and costs associated with the development project. Economic feasibility is
often referred to as cost-benefit analysis. During project initiation and plan-
ning, it will be impossible for you to define precisely all benefits and costs re-
lated to a particular project. Yet, it is important that you identify and quantify
benefits and costs, or it will be impossible for you to conduct a sound eco-
nomic analysis and determine whether one project is more feasible than an-
other. Next, we review worksheets you can use to record costs and benefits,
and techniques for making cost-benefit calculations. These worksheets and
techniques are used after each SDLC phase to decide whether to continue, redi-
rect, or kill a project.
Determining Project Benefits An information system can provide many
benefits to an organization. For example, a new or renovated IS can automate
monotonous jobs, reduce errors, provide innovative services to customers and
suppliers, and improve organizational efficiency, speed, flexibility, and morale.
These benefits are both tangible and intangible. A tangible benefit is an item
that can be measured in dollars and with certainty. Examples of tangible
benefits include reduced personnel expenses, lower transaction costs, or
higher profit margins. It is important to note that not all tangible benefits can
be easily quantified. For example, a tangible benefit that allows a company to
perform a task 50 percent of the time may be difficult to quantify in terms of
hard dollar savings. Most tangible benefits fit in one or more of the following
categories:
쐍 Cost reduction and avoidance
쐍 Error reduction
쐍 Increased flexibility
쐍 Increased speed of activity
쐍 Improvement of management planning and control
쐍 Opening new markets and increasing sales opportunities
Jim and Jackie identified several tangible benefits of the Customer Tracking
System at PVF and summarized them in a worksheet, shown in Figure 4-7.
Jackie and Jim collected information from users of the current customer track-
ing system in order to create the worksheet. They first interviewed the person
responsible for collecting, entering, and analyzing the correctness of the current
customer tracking data. This person estimated that he spent 10 percent of his
Economic feasibility
A process of identifying the
financial benefits and costs
associated with a development
project.