Get Complete eBook Download by Email at discountsmtb@hotmail.com
Systems Analysis and Design
Alan Dennis
Indiana University
Barbara Haley Wixom
Massachusetts Institute of Technology
Roberta M. Roth
University of Northern Iowa
EIGHTH
EDITION
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Get Complete eBook Download link Below for Instant Download:
https://browsegrades.net/documents/286751/ebook-payment-link-forinstant-download-after-payment
Get Complete eBook Download by Email at discountsmtb@hotmail.com
The Systems Analyst
and Information Systems
Development
1
PLANNING
TASK
CHECKLIST
Identify project.
Develop systems request.
Analyze technical feasibility.
Analyze economic feasibility.
Analyze organizational feasibility.
Perform project selection review.
Manage scope.
Staff project.
Create project charter.
Set up CASE repository.
Develop standards.
Begin documentation.
Assess and manage risk.
This chapter introduces the role of the systems analyst in information systems development
projects. First, the fundamental four-­stage systems development life cycle (planning, analysis,
design, and implementation) is established as the basic framework for the information system
(IS) development process. Next, ways in which organizations identify and initiate potential projects are discussed. The first steps in the process are to identify a project that will deliver value to
the business and to create a system request that provides the basic information about the proposed
system. Next, the analysts perform a feasibility analysis to determine the technical, economic,
and organizational feasibility of the system.
3
Get Complete eBook Download by Email at discountsmtb@hotmail.com
4
The Systems Analyst and Information Systems Development
OBJECTIVES
• Explain the role played in IS development by the systems analyst.
• Describe the fundamental systems development life cycle and its four phases.
• Explain how organizations identify IS development projects.
• Explain the importance of linking the IS to business needs.
• Be able to create a system request.
• Describe technical, economic, and organizational feasibility assessment.
• Be able to perform a feasibility analysis.
Introduction
The systems development life cycle (SDLC) is the process of determining how an information
system (IS) can support business needs, designing the system, building it, and delivering it to users.
If you have taken a programming class or have programmed on your own, you have probably
experienced some success in developing small software applications. Creating high-­quality IS
that meet expectations and provide meaningful value to organizations is a much more complex
endeavor, however.
Numerous studies over the years report that projects involving information technology experience failure rates from 30 to 70%.1 The definition of failure in these studies is often quite different, so the meaning of these statistics is hard to pin down. It is clear, though, that bringing an IS
development project to a successful conclusion is difficult and many things need to be done right
if we hope to achieve a positive outcome.
Although we would like to promote this book as a “silver bullet” that will keep you from experiencing failed IS projects, we must admit that such a silver bullet guaranteeing IS development
success does not exist.2 Instead, this book will provide you with many fundamental concepts and
practical techniques that you can use to improve the likelihood of success. We also discuss how
the approach to systems development projects has evolved to improve the odds of project success.
The systems analyst plays a key role in the SDLC, analyzing the business situation, identifying opportunities for improvements, and designing an IS to implement the improvements.
Many systems analysts view their profession as one of the most interesting, exciting, and challenging jobs around. As a systems analyst, you will work as a team with a variety of people,
including business and technical experts. You will feel the satisfaction of seeing systems that you
designed and developed make a significant positive business impact, while knowing that your
unique skills helped make that happen.
It is important to remember that the primary objective of the systems analyst is not to create a
wonderful system. The primary goal is to create value for the organization, which for most companies means increasing profits. (Government agencies and not-­for-­profit organizations measure
value differently.) Many failed projects were abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would support the organization’s
goals, improve business processes, and integrate with other IS to provide value. An investment in
an IS is like any other investment, such as a new machine tool. The goal is not to acquire the tool,
because the tool is simply a means to an end; the goal is to enable the organization to perform
work better so that it can earn greater profits or serve its constituents more effectively.
Michael Krigsman, “CIO Analysis: Why 37 Percent of Project Fail,” zdnet.com, accessed February 2014.
1
The idea of using the silver bullet metaphor was first described in a paper by Frederick Brooks. See Frederick P. Brooks, Jr.,
“No Silver Bullet—­Essence and Accident in Software Engineering,” Information Processing 1986, the Proceedings of the IFIP
Tenth World Computing Conference, H.-­J. Kugler (ed.), 1986: 1069–76.
2
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Introduction
5
This book introduces you to the fundamental skills needed by a systems analyst. This is a
pragmatic book that discusses best practices in systems development; it does not present a general survey of systems development that exposes you to everything about the topic. Systems analysts do things and challenge the current way that an organization works. To get the most out of
this book, you will need to actively apply the ideas and concepts in the examples and in the “Your
Turn” exercises that are presented throughout to your own systems development project. This
book will guide you through all the steps for delivering a successful IS. In the text, we illustrate
how one organization, called DrōnTeq, applies the steps in one project, developing a Web-­based
intermediary e-­commerce system. By the time you finish the book, you will not be an expert systems analyst, but you will be ready to start building systems for real.
Concepts in Action 1-­A
An Array of IT Failures
A significant proportion of IT projects fail to fulfill their
original objectives, resulting in wasted resources and a damaged reputation for the responsible IT department. In many
cases, the causes of the failure are organizational issues, not
technical issues.
Qantas, the Australian national airline, has endured two
high-­profile IT failures in recent years. In 1995, Project eQ, a
10-­year technology services contract with IBM, was canceled
after four years, at a cost of $200 million. Poor planning contributed to the failure to upgrade a complex and unwieldy IT
infrastructure saddled with over 700 applications written in
older programming languages.
In 2008, Qantas canceled Jetsmart, a $40 million parts-­
management system implementation, due in part to a dispute
with the unionized users (aircraft mechanics) of the system.
The union advised its members not to assist with the implementation, claiming the software unnecessarily increased the
members’ workload.
An analysis of these IT failures reveals several contributing factors. First, Qantas faced the challenges of a complicated
technical infrastructure and outdated legacy applications. More
significantly, however, was the failure of company leadership to understand basic IT issues. In public statements, the
company CFO seemed not to care about the user perspectives
on new software, preferring instead to put in what management
thought was appropriate. This attitude, in part, led to union
problems and claims of poorly designed, hard-­to-­use software
and inadequate training.
Aging applications and an unwieldy technical infrastructure are challenges faced by many organizations today. But
the senior-­management attitude that seemingly disregards the
views of software users casts serious questions about Qantas’
prospects for IT project success in the future.
Large systems development projects are particularly susceptible to failure. An example was a $110 million unemployment
compensation system upgrade project conducted by IBM for
the state of Pennsylvania that was never completed and ended
in a lawsuit. When the project was ended in 2013, the project
was 45 months behind schedule and $60 million over budget.
An analysis of very large development projects conducted by the Standish Group found that for projects that exceed
$100 million in labor costs, only 2% are successful (defined
as on time and under budget). Although many factors contributed to this specific project’s flaws, several major factors were
delays in decision making and a high workforce turnover during the project.
An 18-­month long project to implement a SaaS customer
relationship management system ultimately was declared a
bust and scrapped. This project had top management support
and was on time and on budget. So why was it considered
a failure?
Although the project team believed it understood the project goals and the outcome that was expected, at the end of the
project, the end users did not want the system. Users were
distrustful of the new system and resistance to change was
extremely high.
In this instance, technical issues did not contribute to p­ roject
failure. The lack of collaboration between the system developers
and the business users ultimately derailed this implementation
project. The development team focused on project execution
rather than building engagement and buy-­in from the users of
the system.
Adapted from: Michael Krigsman, “Quantas Airways: A Perfect Storm for
IT Failures?”, February 29, 2008, zdnet.com, accessed March 2014.
Adapted from: Patrick Thibodeau, “Pennsylvania Sues IBM Over
Troubled $110M IT Upgrade,” Computerworld.com, March 13, 2017,
https://www.computerworld.com/article/3180325/pennsylvania-­sues-­ibm-­
over-­troubled-­110m-­it-­upgrade.html, accessed February 2021.
Adapted from: Mary K. Pratt, “Why IT Projects Still Fail,” CIO.com,
August 1, 2017, https://www.cio.com/article/3211485/why-­it-­projects-­
still-­fail.html?nsdr=true, accessed August 2020.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
6
The Systems Analyst and Information Systems Development
In this chapter, we first describe the role of the systems analyst in IS development projects.
We discuss the wide range of skills needed to be successful in this role, and we explain various specialties that systems analysts may develop. We then introduce the basic SDLC that IS
projects follow. This life cycle is common to all projects and serves as a framework for understanding how IS projects are accomplished. We discuss how projects are identified and initiated
within an organization and how they are initially described in a system request. Finally, we
describe the feasibility analysis that is performed, which drives the decision whether to proceed with the project.
The Systems Analyst
The systems analyst plays a key role in IS development projects. The systems analyst works
closely with all project team members so that the team develops the right system in an effective
way. Systems analysts must understand how to apply technology to solve business problems. In
addition, systems analysts may serve as change agents who identify the organizational improvements needed, design systems to implement those changes, and train and motivate others to use
the systems.
Systems Analyst Skills
New IS introduce change to the organization and its people. Leading a successful organizational
change effort is one of the most difficult jobs that someone can do. Understanding what to change,
knowing how to change it, and convincing others of the need for change require a wide range of
skills. These skills can be broken down into six major categories: technical, business, analytical,
interpersonal, management, and ethical.
Analysts must have the technical skills to understand the organization’s existing technical
environment, the new system’s technology foundation, and the way in which both can be fit into
an integrated technical solution. Business skills are required to understand how IT can be applied
to business processes and to ensure that IT delivers real business value. Analysts are continuous
problem solvers at both the project and the organizational level, and they put their analytical
skills to the test regularly.
Often, analysts need to communicate effectively, one-­on-­one with users and business managers (who often have little experience with technology), with programmers and other technical
SPOTLIGHT ON ETHICS - 1
James is a systems analyst on a new account management
system for Hometown National Bank. At a recent meeting with the project sponsor, James learned about some
new ideas for the system that were not a part of the
original project scope. Specifically, the bank’s marketing
director has asked that some of the data that will be collected by the new system from customers who open new
checking and savings accounts also be used as the basis
of a marketing campaign for various loan products the
bank offers.
James is uncomfortable with the request. He is not
sure the bank has the right to use a person’s data for purposes other than the original intent. Who “owns” this data,
the bank that collected it as a part of a customer opening an account, or the customer who the data describes?
Should James insist that the customers give authorization
to use “their” data in this way? Or should he say nothing
and ignore the issue? Is it necessary (or appropriate) for
a systems analyst to be an ethical watchdog in a systems
development project? Why or why not?
Get Complete eBook Download by Email at discountsmtb@hotmail.com
The Systems Analyst
7
specialists (who often have more technical expertise than the analyst does), and with people from
outsourcing firms and vendor organizations. They must be able to give presentations to large and
small groups and to write reports. Not only do they need to have strong interpersonal abilities,
but they also need to manage people with whom they work, and they must manage the pressure
and risks associated with unclear situations.
Finally, analysts must deal fairly, honestly, and ethically with other project team members,
managers, and system users. Analysts often deal with confidential information or information
that, if shared with others, could cause harm (e.g., dissent among employees); it is important for
analysts to maintain confidence and trust with all people.
Systems Analyst Roles
As organizations and technology have become more complex, most large organizations now
build project teams that incorporate several analysts with different, but complementary roles. In
smaller organizations, one person may play several of these roles. Here we briefly describe these
roles and how they contribute to a systems development project.
The systems analyst role focuses on the IS issues surrounding the system. This person
develops ideas and suggestions for ways that IT can support and improve business processes,
helps design new business processes supported by IT, designs the new IS, and ensures that all IS
standards are maintained. The systems analyst will have significant training and experience in
analysis and design and in programming.
The business analyst role focuses on the business issues surrounding the system. This person
helps to identify the business value that the system will create, develops ideas for improving the
business processes, and helps design new business processes and policies. The business analyst
will have business training and experience, plus knowledge of analysis and design.
The requirements analyst role focuses on eliciting the requirements from the stakeholders associated with the new system. As more organizations recognize the critical role that
complete and accurate requirements play in the ultimate success of the system, this specialty
has gradually evolved. Requirements analysts understand the business well, are excellent
communicators, and are highly skilled in an array of requirements elicitation techniques (discussed in Chapter 3).
The infrastructure analyst role focuses on technical issues surrounding the ways the system
will interact with the organization’s technical infrastructure (hardware, software, networks, and
databases). This person ensures that the new IS conforms to organizational standards and helps
to identify infrastructure changes that will be needed to support the system. The infrastructure
analyst will have significant training and experience in networking, database administration, and
various hardware and software products. Over time, an experienced infrastructure analyst may
assume the role of software architect, who takes a holistic view of the organization’s entire IT
environment and guides application design decisions within that context.
YOUR TURN 1-­1
Being an Analyst
Suppose you set a goal to become an analyst after you graduate. What type of analyst would you most prefer to be? Why
does this particular analyst role appeal to you? What type of
courses should you take before you graduate? What type of
summer job or internship should you seek?
Question
Develop a short plan that describes how you will prepare for
your career as an analyst.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
8
The Systems Analyst and Information Systems Development
Requirements
analyst
Entry-level
business function
specialist
Change
management
analyst
Business
analyst
Project
manager
Systems
analyst
Entry-level
programmer/
analyst
Infrastructure
analyst
Software
architect
More common path
FIGURE 1-­1 Career
paths for system
developers.
Less common path
The change management analyst role focuses on the people and management issues surrounding the system installation. This person ensures that adequate documentation and support
are available to users, provides user training on the new system, and develops strategies to overcome resistance to change. The change management analyst will have significant training and
experience in organizational behavior and specific expertise in change management.
The project manager role ensures that the project is completed on time and within budget
and that the system delivers the expected value to the organization. The project manager is often a
seasoned systems analyst who, through training and experience, has acquired specialized project
management knowledge and skills.
The roles and the names used to describe them may vary from organization to organization.
In addition, there is no single typical career path through these professional roles. Some people
may enter the field as a more technically oriented programmer/analyst. Others may enter as a
business-­oriented functional specialist with an interest in applying IT to solve business problems.
As shown in Figure 1-­1, those who are interested in the broad field of IS development may follow
a variety of paths during their career.
The Systems Development Life Cycle
In some ways, building an IS is like building a house. First, the owner describes the vision for the
house to the developer. Second, this idea is transformed into sketches and drawings that are
shown to the owner and refined (often, through several drawings, each improving on the other)
until the owner agrees that the pictures depict what he or she wants. Third, a set of detailed blueprints is developed that present much more detailed information about the house (e.g., the layout
of rooms, placement of plumbing fixtures and electrical outlets). Finally, the house is built
­following the blueprints—­and often with some changes and decisions made by the owner as the
house is erected.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
9
The Systems Development Life Cycle
Planning
Analysis
Design
Implementation
Idea
System
success
FIGURE 1-­2 The systems development life cycle.
Building an IS using the SDLC follows a similar set of four fundamental phases: planning,
analysis, design, and implementation (Figure 1-­2). Each phase is itself composed of a series of
steps, which rely on techniques that produce deliverables (specific documents and files that
explain various elements of the system). Figure 1-­3 provides more details on the steps, techniques, and deliverables that are included in each phase of the SDLC and outlines how these
topics are covered in this textbook.
Figures 1-­2 and 1-­3 suggest that the SDLC phases proceed in a logical path from start to
finish. In some projects, this is true. In many projects, however, the project team moves through
Phase
Chapter
Step
Planning
Focus: Why build this system?
1
1
Identify opportunity
Analyze feasibility
How to structure the project?
Primary outputs:
—­System request with
feasibility study
—­Project plan
2
Develop project plan
2
Staff project
2
Control and direct project
3
3
Develop analysis strategy
Determine business
requirements
4
4
5
Create use cases
Model processes
Model data
Design
6
Focus: How will this
system work?
7
Analysis
Focus: Who, what, where,
and when for this system?
Technique
Deliverable
Project identification
Technical feasibility
Economic feasibility
Organizational feasibility
Scope management
System request
Feasibility study
Project staffing
Project charter
CASE repository
Standards
Documentation
Timeboxing
Risk management
—­Staffing plan
Business process automation
Business process improvement
Business process reengineering
Interview
JAD session
Questionnaire
Document analysis
Observation
Use case analysis
Data flow diagramming
Entity relationship modeling
Normalization
System proposal
—­Requirements definition
Design physical system
Design strategy
Design architecture
Architecture design
Hardware and software
selection
Alternative matrix
System specification
—­Architecture report
—­Hardware and software
specification
Primary output
—­System proposal
FIGURE 1-­3 Systems development life cycle phases.
Project plan
—­Standards list
—­Risk assessment
—­Use cases
—­Process models
—­Data model
Get Complete eBook Download by Email at discountsmtb@hotmail.com
10
The Systems Analyst and Information Systems Development
Phase
Chapter
Primary output:
—­System specification
Implementation
Focus: Delivery and support
of completed system
Primary output:
—­Installed system
Step
8
Design interface
9
Design programs
10
Design databases and
files
11
12
Construct system
Software testing
Performance testing
Install system
12
Maintain system
12
Postimplementation
Technique
Deliverable
Use scenario
Interface structure
Interface standards
Interface prototype
Interface evaluation
Data flow diagramming
Program structure chart
Program specification
Data format selection
Entity relationship modeling
Denormalization
Performance tuning
Size estimation
—­Interface design
Programming
Programs
Documentation
Conversion strategy selection
Test plan
Training
Support selection
System maintenance
Project assessment
Postimplementation audit
—­Physical process model
—­Program design
—­Database and file
specification
—­Physical data model
Migration plan
—­Conversion plan
—­Business
contingency plan
—­Training plan
Support plan
Problem report
Change request
Postimplementation
audit report
FIGURE 1-­3 (Continued)
the steps consecutively, incrementally, iteratively, or in other patterns. Different projects may
emphasize different parts of the SDLC or approach the SDLC phases in different ways, but all
projects have elements of these four phases.
For now, there are two important points to understand about the SDLC. First, you should get
a general sense of the phases and steps that IS projects move through and some of the techniques
that produce certain deliverables. In this section, we provide an overview of the phases, steps, and
some of the techniques that are used to accomplish the steps. Second, it is important to understand that the SDLC is a process of gradual refinement. The deliverables produced in the analysis phase provide a general idea of what the new system will do. These deliverables are used as
input to the design phase, which then refines them to produce a set of deliverables that describes
in much more detailed terms exactly how the system should be built. These deliverables in turn
are used in the implementation phase to guide the creation of the actual system. Each phase
refines and elaborates on the work done previously.
Planning
The planning phase is the fundamental process of understanding why an IS should be built and
determining how the project team will go about building it. It has two steps:
1. During project initiation, the system’s business value to the organization is
identified—­how will it contribute to the organization’s future success? Most ideas for
new systems come from outside the IS area and are recorded on a system request.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
The Systems Development Life Cycle
A system request presents a brief summary of a business need and explains how a
system that addresses the need will create business value. The IS department works
together with the person or department generating the request (called the project
sponsor) to conduct a feasibility analysis. The feasibility analysis examines key
aspects of the proposed project:
• The technical feasibility (Can we build it?)
• The economic feasibility (Will it provide business value?)
• The organizational feasibility (If we build it, will it be used?)
2. The system request and feasibility analysis are presented to an IS approval committee
(sometimes called a steering committee), which decides whether the project should be
undertaken.
Once the project is approved, it enters project management. During project management,
the project manager creates a plan, staffs the project, and puts techniques in place to
help control and direct the project through the entire SDLC. The deliverable for project
management is a plan that describes how the project team will go about developing
the system.
Analysis
The analysis phase answers the questions of who will use the system, what the system will do,
and where and when it will be used (Figure 1-­3). During this phase, the project team investigates
any current system(s), identifies improvement opportunities, and develops a concept for the new
system. This phase has three steps:
1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy usually includes studying the current system (called the as-­is system) and its problems, and
envisioning ways to design a new system (called the to-­be system).
2. The next step is requirements gathering (e.g., through techniques such as interviews,
group workshops, or questionnaires). The analysis of this information—­in conjunction
with input from the project sponsor and many other people—­leads to the development
of a concept for a new system. The system concept is explained through a set of
requirement statements and a set of business analysis models that describe how the
business will operate if the new system is developed. The analysis models represent
user/system interactions and the data and processes needed to support the underlying
business process.
3. The analyses, system concept, requirements, and models are combined into a document
called the system proposal, which is presented to the project sponsor and other key
decision makers (e.g., members of the approval committee) who will decide whether the
project should continue to move forward.
The system proposal is the initial deliverable describing the requirements the new system
should satisfy. Some experts suggest this phase would be better named analysis and initial
design, rather than analysis, since it really provides the first step in the new system design. Since
most organizations continue to use the name analysis for this phase, we will use it in this book as
well. It is important to remember, however, that the deliverable from the analysis phase is both an
analysis and a high-­level initial design for the new system.
11
Get Complete eBook Download by Email at discountsmtb@hotmail.com
12
The Systems Analyst and Information Systems Development
Design
The design phase decides how the system will operate in terms of the hardware, software, and
network infrastructure that will be in place; the user interface, forms, and reports that will be
used; and the specific programs, databases, and files that will be needed. Although most of the
strategic decisions about the system are made in the development of the system concept during
the analysis phase, the steps in the design phase determine exactly how the system will operate.
The design phase has four steps:
1. The design strategy must be determined. This clarifies whether the system will be developed by the company’s own programmers, whether its development will be outsourced
to another firm (usually a consulting firm), or whether the company will buy and install a
prewritten software package.
2. This leads to the development of the basic architecture design for the system that
describes the hardware, software, and network infrastructure that will be used. In most
cases, the system will add to or change the infrastructure that already exists in the organization. The interface design specifies how the users will move through the system (e.g.,
by navigation methods such as menus and on-­screen buttons) and the forms and reports
that the system will use.
3. The database and file specifications are developed. These define exactly what data will
be stored and where they will be stored.
4. The analyst team develops the program design, which defines the programs that need to
be written and exactly what each program will do.
This collection of deliverables (architecture design, interface design, database and file specifications, and program design) is the system specification that is used by the programming
team for implementation. At the end of the design phase, the feasibility analysis and project plan
are reexamined and revised, and another decision is made by the project sponsor and approval
committee about whether to terminate the project or continue (Figure 1-­3).
Implementation
The final phase in the SDLC is the implementation phase, during which the system is actually
built (or purchased and installed if the design calls for a prewritten software package). This is the
phase that usually gets the most attention, because for most systems it is the longest and most
expensive single part of the development process. This phase has three steps:
1. System construction is the first step. The system is built and tested to ensure that it performs as designed. Since the cost of fixing bugs can be immense, testing is one of the most
critical steps in implementation. Most organizations should spend more time and attention
on testing than on writing the programs in the first place.
2. The system is installed. Installation is the process by which the old system is turned off
and the new one is turned on. There are several approaches that may be used to convert from the old to the new system. One of the most important aspects of conversion is
training, during which users are taught to use the new system and help manage the resulting organizational changes.
3. The analyst team establishes a support plan for the system. This plan usually includes a
formal or informal postimplementation review, as well as a systematic way for identifying
major and minor changes needed for the system.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Project Identification and Initiation
Project Identification and Initiation
Where do project ideas come from? A project is identified when someone in the organization
identifies a business need to build a system. Examples of business needs include supporting
a new marketing campaign, reaching out to a new type of customer, or improving interactions with suppliers. Sometimes, needs arise from some kind of “pain” within the organization, such as a drop in market share, poor customer service levels, unacceptable product
defect rates, or increased competition. New business initiatives and strategies may be created
and a system to support them is required, or a merger or acquisition may require systems to
be integrated.
Business needs also can surface when the organization identifies unique and competitive ways
of using IT. Many organizations keep an eye on emerging technology, which is technology that
is in the early stages of widespread business use. For example, if companies stay abreast of technological advances such as cloud computing, Big Data, or machine learning, they can develop
business strategies that leverage the capabilities of these technologies and introduce them into the
marketplace as a first mover. Ideally, companies can take advantage of this first mover position
by making money and continuing to innovate while competitors trail behind.
Today, many new IS projects grow out of business process management (BPM) initiatives.
BPM is a methodology used by organizations to continuously improve end-­to-­end business
processes. BPM can be applied to internal organizational processes and to processes spanning
multiple business partners. By studying and improving their underlying business processes, organizations can achieve several important benefits, including
• enhanced process agility, giving the organization the ability to adapt more rapidly and effectively to a changing business environment;
• improved process alignment with industry “best practices”; and
• increased process efficiencies as costs are identified and eliminated from process workflows.
BPM generally follows a continuous cycle of systematically creating, assessing, and altering
business processes. Business analysts, with their in-­depth business knowledge, play a particularly
important role in BPM by
1. defining and mapping the steps in a business process;
2. creating ways to improve on steps in the process that add value;
3. finding ways to eliminate or consolidate steps in the process that do not add value;
4. creating or adjusting electronic workflows to match the improved process maps.
The last step is particularly relevant to our discussion since the need for IS projects is frequently identified here. In fact, the automation of business processes [termed business process
automation (BPA)] is the foundation of many information technology systems. In these situations, technology components are used to complement or substitute for manual information
management processes with the goal of gaining cost efficiencies.
BPM practitioners recognize, however, that it is not always advisable to just “pave the cow
paths” by simply adding automation to speed up existing processes (step 4 above). In many situations, business process improvement (BPI) results from studying the business processes,
creating new, redesigned processes to improve the process workflows, and/or utilizing new technologies enabling new process structures (steps 2, 3, and 4 above). For example, could a retail
store’s checkout process be redesigned along the lines of the EZPass toll collection system on
highways? Could customers check out and pay with their mobile devices while clerks simply
review the contents of the customer’s shopping bag?
13
Get Complete eBook Download by Email at discountsmtb@hotmail.com
14
The Systems Analyst and Information Systems Development
Projects with a goal of BPI make moderate changes to the organization’s operations and
can improve efficiency (i.e., doing things right) and improve effectiveness (i.e., doing the right
things). These types of projects involve more risk than business process automation projects
since more significant changes are made to the organization’s operations.
BPM may also reveal the need for the complete revamping of the organization’s business
processes, termed business process reengineering (BPR). BPR means changing the fundamental
way in which the organization operates—­“obliterating” the current way of doing business and
making major changes to take advantage of new ideas and new technology. As you might expect,
BPR projects involve substantial risk due to the significant organizational and operational
changes that result. Top management support and careful management are critical in these fairly
rare types of projects.
Both IT people (i.e., the IS experts) and business people (i.e., the subject matter experts)
should work closely together to find ways for technology to support business needs. In this way,
organizations can leverage the exciting technologies available while ensuring that projects are
based upon real business objectives such as increasing sales, improving customer service, and
decreasing operating expenses. Ultimately, IS need to affect the organization’s bottom line (in a
positive way!).
When a strong business need for an IS is recognized, often as a result of BPM, a person (or
group) who has an interest in the system’s success typically steps forward. We call this person
(or group) the project sponsor. Often, the project sponsor develops the initial vision of the new
system. The project sponsor works throughout the SDLC to make sure that the project is moving
in the right direction from the perspective of the business and serves as the primary point of
contact for the project team. Usually, the sponsor of the project is from a business function
such as marketing, accounting, or finance; however, members of the IT area also can sponsor or
cosponsor a project.
The size or scope of the project often determines the kind of sponsor who is involved.
A small departmental system might be sponsored by a single manager; however, a large,
organizational initiative might be sponsored by the entire senior management team and
even the CEO. If a project is primarily technical in nature (e.g., improvements to the existing IT infrastructure or research into the viability of an emerging technology), then sponsorship from IT is appropriate. When projects have great importance to the business, yet
are technically complex, joint sponsorship by both the business and IT functions may be
necessary.
The business need drives the high-­level business requirements for the system. Business
requirements describe the capabilities the system will provide the organization so that the
Concepts in Action 1-­B
BPI on the Farm
In the farming industry, grain is commonly loaded into large
grain-­hauling trucks by the driver parking under the grain bin,
jumping out of the truck cab, signaling the grain bin operator to
start filling, monitoring the fill level, signaling the bin operator
to stop filling, jumping back into the truck cab, driving 3 feet
forward, and repeating the cycle numerous times until the truck
bed is full. This laborious process can be simplified by digitizing the process. Cameras and secure Wi-­Fi can be installed
on the grain bin. When a truck arrives, the driver can open an
app on his smartphone from the truck cab. Through the app,
the driver can initiate, monitor, and control the filling process
without a grain bin operator and without leaving the truck. This
real-­world example illustrates BPI, the redesign of a business
process with the right application of information technology,
providing significant efficiency gains.
Adapted from: Nicole Laskowski, “Crowdsourcing is the new cloud
computing—­Get with it, CIOs,” searchcio.techtarget.com, accessed
February 2014.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Project Identification and Initiation
YOUR TURN 1-­2
15
Implementing a Satellite Data Network
A major retail store spent $24 million dollars on a large,
private satellite communication system that provides state-­of-­
the-­art voice, data, and video transmission between stores and
regional headquarters. When an item gets sold, the scanner
software updates the inventory system in real time. As a result,
store transactions are passed on to regional and national headquarters instantly, which keeps inventory records up to date.
One of the store’s major competitors has an older system in
which transactions are uploaded at the end of a business day.
The first company feels that its method of instant communication and feedback allows it to react more quickly to changes
in the market, giving the company a competitive advantage.
For example, if an early winter snowstorm causes stores across
the upper Midwest to start selling high-­end (and high-­profit)
snow throwers quite quickly, the company’s nearest warehouse
can prepare next-­day shipments to maintain a good inventory
balance, while the competitor may not move quite as quickly
and thus lose out on such quick inventory turnover.
Questions
1. Do you think a $24 million investment in a private satellite
communication system could be justified by a cost–benefit
analysis? Could this be done with a standard communication line (with encryption)?
2. How might the competitor attempt to close the “information
gap” in this example?
business needs are met. These requirements need to be explained at a high level so that the
approval committee and, ultimately, the project team understand what the business expects from
the final product. Business requirements summarize the features the IS must include, such as the
ability to collect customer orders online or the ability for suppliers to receive inventory status
information as sales occur.
The project sponsor has the insights needed to determine the business value that will be
gained from the system, in both tangible and intangible ways. Tangible value can be quantified
and measured easily (e.g., 2% reduction in operating costs). Intangible value results from an
intuitive belief that the system provides important, but hard-­to-­measure, benefits to the organization (e.g., improved customer service, a better competitive position).
Once the project sponsor identifies a project that meets an important business need and he or
she can identify the business requirements and business value of the system, it is time to formally
initiate the project. In most organizations, project initiation begins by preparing a system request.
System Request
A system request is a document that describes the business reasons for building a system and the
value that the system is expected to provide. The project sponsor usually completes this form as
part of a formal system project selection process within the organization. Most system requests
include five elements: project sponsor, business need, business requirements, business value, and
special issues (Figure 1-­4). The sponsor describes the person who will serve as the primary
contact for the project, and the business need presents the reasons prompting the project. The
business requirements of the project refer to the business capabilities that the system must have,
and the business value describes the benefits that the organization should expect from the system.
Special issues are included on the document as a catchall category for other information that
should be considered in assessing the project. For example, the project may need to be completed
by a specific deadline. Any special circumstances that could affect the outcome of the project
must be clearly identified.
The completed system request is submitted to the approval committee for consideration. This
approval committee could be a company steering committee that meets regularly to make IS
decisions, a senior executive who has control of organizational resources, or any other decision-­
making body that governs the use of business resources. The committee reviews the system request
Get Complete eBook Download by Email at discountsmtb@hotmail.com
16
The Systems Analyst and Information Systems Development
Element
FIGURE 1-­4 Elements of the system
request form.
Description
Examples
Project Sponsor
The person who initiates the project
and who serves as the primary
point of contact for the project
on the business side
Several members of the finance department
Vice president of marketing
CIO
CEO
Business Need
The business-­related reason(s) for
initiating the system
Reach a new market segment
Offer a capability to keep up with competitors
Improve access to information
Decrease product defects
Streamline supply acquisition processes
Business
Requirements
The new or enhanced business
capabilities that the system
will provide
Provide onIine access to information
Capture customer demographic information
Include product search capabilities
Produce performance reports
Enhance online user support
Business Value
The benefits that the system will
create for the organization
3% increase in sales 1% increase in market share
Reduction in headcount by 5 FTEs
$200,000 cost savings from decreased supply costs
$150,000 savings from removal of outdated
technology
Special Issues or
Constraints
Issues that pertain to the approval
committee’s decision
Government-­mandated deadline for May 30
System needed in time for the Christmas
holiday season
Top-­level security clearance needed by project
team to work with data
FTE, full-­time
equivalent.
and makes an initial determination, based on the information provided, of whether to investigate the
proposed project or not. If approved, the next step is to conduct a feasibility analysis.
Applying the Concepts at DrōnTeq
Throughout the book, we will apply the concepts in each chapter to a fictitious company called
DrōnTeq. In this section, we illustrate the creation of a system request.
Concepts in Action 1-­C
Interview with Don Hallacy, President, Technology Services, Sprint
Corporation
At Sprint, network projects originate from two vantage
points—­IT and the business units. IT projects usually address
infrastructure and support needs. The business-­unit projects
typically begin after a business need is identified locally, and a
business group informally collaborates with IT regarding how
a solution can be delivered to meet customer expectations.
Once an idea is developed, a more formal request process
begins, and an analysis team is assigned to investigate and validate the opportunity. This team includes members from the user
community and IT, and they scope out at a high level what the
project will do; create estimates for technology, training, and
development costs; and create a business case. This business
case contains the economic value added and the net present
value of the project.
Of course, not all projects undergo this rigorous process.
The larger projects require more time to be allocated to the
analysis team. It is important to remain flexible and not let
the process consume the organization. At the beginning of
each budgetary year, specific capital expenditures are allocated for operational improvements and maintenance. Moreover, this money is set aside to fund quick projects that deliver
immediate value without going through the traditional approval
process. Get Complete eBook Download by Email at discountsmtb@hotmail.com
Project Identification and Initiation
YOUR TURN 1-­3
17
Too Much Paper, Part 1
The South Dakota Department of Labor, Workers’
Compensation division was sinking under a load of paper files.
This state agency ascertains that employees are treated fairly
when they are injured on the job. If a person (or company)
called to see the status of an injury claim, the clerk would have
to take a message, get the paper file, review the status, and call
the person back. Files were stored in huge filing cabinets and
were entered by year and case number (i.e., the 415th person
injured in 2008 would be in a file numbered 08-­415). Few
callers knew the file number and would give their name and
address and the date of injury. The clerk would look in a spiral
notebook for the last name around the date that was given—­and
then find the file number to retrieve the folder. Some folders
were small—­possibly documenting a minor injury requiring
only a brief treatment period. Other folders could be very large,
with numerous medical reports from several doctors verifying
the extent of a serious injury and treatment (such as an arm
amputation). A digital solution was suggested—­reports could
be submitted online via a secure website. Medical reports could
be submitted electronically, either as a pdf file or as a faxed
digital file. This solution would also mean that the clerk taking
the phone call could query the database by the person’s name
and access the information in a matter of seconds.
Question
Begin a system request for this project. Focus on stating the
business need and the business requirements for this project.
What is the value of this system?
DrōnTeq is a fictitious technology company that develops numerous unmanned aerial vehicles, called drones, and drone technology for many purposes. DrōnTeq was established by two
technology entrepreneurs, Eric Chen and Peter Lyons. The field of drone technology was evolving rapidly, and Eric and Peter quickly established DrōnTeq as a leading maker of commercial-­
grade drones with advanced sensors and imaging capabilities.
As a technology company, DrōnTeq invests heavily in research and development of its drone
products. It also developed proprietary software capable of providing unique analyses of the
data collected by the drone’s onboard sensors. The Sales department focuses primarily on drone
sales and marketing to government and commercial entities. A new Client Services business unit
has been formed within DrōnTeq, focusing on outsourced drone services. Carmella Herrera was
named director of the Client Services business unit.
Project Background
DrōnTeq is a technology company and utilizes IS in a variety of ways. The new Client Services
unit requires specialized IS support, however, to allow clients to request and receive drone services. In the business model of new business unit, licensed drone pilots contract with DrōnTeq to
fly a DrōnTeq drone when requested by a client that is near the drone pilot. The drone pilot uses
a current model DrōnTeq drone, provided at a favorable lease rate, in return for providing prompt
flight service when requested by a client. All client drone flight requests will be processed through
DrōnTeq’s website. Once a request is received, the request will be posted for all contracted drone
pilots to see. Pilots will have a specific window of time in which to submit a bid to conduct the
flight. An assignment algorithm will determine the “winning” bid after the bidding window closes and automatically notifies the pilots and the client of the results.
Many aspects of the Client Services business unit will require IS support, but the current
focus is on the customer-­facing aspects of receiving a client request for service and assigning the
request to a contracted drone pilot. A project to create the required support for the new business
unit has been proposed by Carmella Herrera.
System Request
At DrōnTeq, new IS projects are reviewed and approved by an IS project steering committee that
meets quarterly. The committee has representatives from IS as well as from other major areas of
Get Complete eBook Download by Email at discountsmtb@hotmail.com
18
The Systems Analyst and Information Systems Development
System Request—­Client Services Project
Project Sponsor: Carmella Herrera, General Manager, Client Services Business Unit
Business Need: This project has been initiated to create the capability of clients requesting drone flight
service and data analysis through the company website. The capability is an essential element in the
business model of the newly formed Client Services business unit.
Business Requirements: Using this system from our company website, clients will be able to request
specific drone flight services and data analysis. A request will be offered to any contracted DrōnTeq
drone pilots in the vicinity, who can submit bids during the bidding window. Once the bidding window
closes, the pilot with the “winning” bid will be assigned the request.
Business Value: The Client Services business unit has been formed to enable clients who do not have a
need for actual drone ownership to receive drone flight service and data analysis promptly and cost
effectively. As a new business unit, we must estimate additional revenue from two streams: additional
drone pilots who contract with DrōnTeq and lease a drone; and clients who contract for specific drone
flight service and data analysis.
Conservative estimates of tangible value to the business unit include:
• $357,500 in revenue from new pilot contracts and drone leases
• $565,000 in revenue from drone flight service and data analysis
FIGURE 1-­5 System
request for DrōnTeq.
Special Issues or Constraints: The capabilities described in the Business Requirements are essential to
the business model for the Client Services Business Unit. This project is necessary for the new business
unit’s operations.
the business. Carmella’s first step was to prepare a system request for the committee. Figure 1-­5
shows the system request she prepared. The project sponsor is Carmella, and the business needs
are to enable clients to request drone flight service and data analysis through the company website. Notice that the need does not focus on the technology associated with the project. The
emphasis is on the business aspects: providing the means for clients to request drone flight service and data analysis and determining a drone pilot who will perform the service.
In the system request, the project sponsor focuses on describing his or her vision of the
business requirements at a high level. Carmella has expressed a clear vision of how this system
will affect the new unit at DrōnTeq: producing revenues from new drone pilot contracts and drone
leases and enabling sales from clients requesting drone flight service and data analysis. Carmella
recognized that this system will be essential in supporting the proposed business model of the
new business unit.
The estimates of tangible value were difficult to develop since this venture is completely new
to DrōnTeq. To prepare for this, Carmella had several of her staff members conduct surveys
of commercial drone operators and several agribusiness interest groups (agricultural uses are a
prime target for the Client Services business unit). The surveys also attempted to gauge the drone
pilots’ and potential clients’ price sensitivity for these offerings.
From the survey results, Carmella and her staff developed a range of sales projections
for the various revenue streams: a high-­level estimate, a medium-­level estimate, and low-­
level estimate. They also developed probability assessments for each of these outcomes, settling on a 25% likelihood for the high-­level estimate, a 60% likelihood for the medium-­level
estimate, and a 15% likelihood for the low-­level estimate. Based on the sales projections and
the probability estimates, a weighted average estimated sales figure was computed for each
revenue stream.
For example, for revenue from new pilot contracts and drone leases,
Expected sales
500, 000 .25
350, 000 .60
125, 000 210, 000 22, 500
357, 500
150, 000 .15
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Feasibility Analysis
19
These projections are summarized in Figure 1-­6.
After analyzing the survey results, Carmella and her staff were confident that the sales
projections and probability estimates were as accurate as they could make them for this new
business venture. The completed system request is shown in Figure 1-­5.
Revenue Projections
Pilot Contracts and
Drone Leases
Client Requests for Drone Flight
Service and Data Analysis
High-­level estimate (prob. = 25%)
$500,000
$700,000
Medium-­level estimate (prob. = 60%)
$350,000
$550,000
Low-­level estimate (prob. = 15%)
$150,000
$400,000
Weighted average expected revenue
$357,500
$565,000
FIGURE 1-­6 Revenue
projections for DrōnTeq
Client Services project.
Steering Committee Approval
Carmella presented the system request for the Client Services project to the DrōnTeq IS project
steering committee at its next meeting. Response to the request was uniformly positive. The
strong support for the project by Eric and Peter, the company’s top executives, helped to spur the
committee’s rapid approval of the project. Following approval of the system request, Jiang Tsiao,
a senior systems analyst in the IS department, was assigned to work with Carmella to develop a
preliminary feasibility analysis for the project.
Feasibility Analysis
Once the need for the system and its business requirements have been defined, the approval
committee authorizes the systems analyst to prepare a more detailed business case to better
understand the proposed IS project. Feasibility analysis guides the organization in determining
whether to proceed with the project. Feasibility analysis also identifies the important risks associated with the project that must be managed if the project is approved. As with the system
request, each organization has its own process and format for the feasibility analysis, but most
include techniques to assess three areas: technical feasibility, economic feasibility, and organizational feasibility (Figure 1-­7). The results of evaluating these three feasibility factors are combined
into a feasibility study deliverable that is submitted to the approval committee.
Technical Feasibility: Can We Build It?
• Familiarity with application: Less familiarity generates more risk.
• Familiarity with technology: Less familiarity generates more risk.
• Project size: Large projects have more risk.
• Compatibility: The harder it is to integrate the system with the company’s existing technology, the
higher the risk will be.
Economic Feasibility: Should We Build It?
• Development costs
• Annual operating costs
• Annual benefits (cost savings and/or increased revenues)
• Intangible benefits and costs
Organizational Feasibility: If We Build It, Will They Come?
• Is the project strategically aligned with the business?
• Project champion(s)
• Senior management
• Users
• Other stakeholders
FIGURE 1-­7
Feasibility analysis
assessment factors.
A template for this
figure is available on the
student website.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
20
The Systems Analyst and Information Systems Development
You might wonder at the omission of the element of time as a risk factor for the project.
While the time available for a project can certainly be a concern, we consider time to be a project
management issue. We will discuss project management strategies that can be used when time is
tight in Chapter 2.
Although we will discuss feasibility analysis now within the context of project initiation, most
project teams revise the feasibility study throughout the SDLC and revisit its contents at various
checkpoints during the project. If at any point the project’s risks and limitations outweigh its benefits, the project team may decide to cancel the project or make substantial revisions.
Technical Feasibility
The first issue in the feasibility analysis is to assess the technical feasibility of the project, the
extent to which the system can be successfully designed, developed, and installed by the IT
group. Technical feasibility analysis is, in essence, a technical risk analysis that strives to answer
the question: “Can we build it?”3
Many risks can endanger the successful completion of the project. First and foremost is the
users’ and analysts’ familiarity with the application. When analysts are unfamiliar with the
business application area, they have a greater chance of misunderstanding the users or missing
opportunities for improvement. The risks increase dramatically when the users themselves have
limited knowledge of the application. If the project involves a new business innovation, neither
the users nor the analysts may have any direct knowledge or experience of the proposed new
application. In general, the development of new systems is riskier than extensions to an existing
system, because existing systems tend to be better understood.
Familiarity with the technology is another important source of technical risk. When a system
uses technology that has not been used before within the organization, there is a greater chance
that problems and delays will occur because of the need to learn how to use the technology. Risk
increases dramatically when the technology itself is new (e.g., a Big Data project using Hadoop).
When the technology is not new but the organization lacks experience with it, technical risk is
reduced somewhat, since outside expertise should be available from vendors and consultants.
Project size is an important consideration, whether measured as the number of people on the
development team, the length of time it will take to complete the project, or the number of distinct features in the system. Larger projects present more risk, because they are more complicated
to manage and because there is a greater chance that some important system requirements will be
overlooked or misunderstood. Large systems are typically highly integrated with other systems,
increasing project complexity.
Finally, project teams need to consider the compatibility of the new system with the technology that already exists in the organization. Systems are rarely built in a vacuum—­they are
built in organizations that have numerous systems already in place. New technology and applications need to be able to integrate with the existing environment for many reasons. They may
rely on data from existing systems, they may produce data that feed other applications, and they
may have to use the company’s existing communications infrastructure. A new CRM system, for
example, has little value if it does not use customer data found across the organization in existing
sales systems, marketing applications, and customer service systems.
The assessment of a project’s technical feasibility is not cut and dried, because in many cases,
some interpretation of the underlying conditions is needed (e.g., how large does a project need to
grow before it is considered “big”?). One approach is to compare the project with prior projects
undertaken by the organization. Another option is to consult with experienced IT professionals
in the organization or with external IT consultants; often, they will be able to judge whether a
project is feasible from a technical perspective.
We use the words “build it” in the broadest sense. Organizations can also choose to buy a commercial software package and
install it, in which case the question might be “Can we select the right package and successfully install it?”
3
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Feasibility Analysis
21
Economic Feasibility
The second element of a feasibility analysis is to perform an economic feasibility analysis (also
called a cost–benefit analysis). This attempts to answer the question “Should we build the system?” Economic feasibility is determined by identifying costs and benefits associated with the
system, assigning values to them, calculating future cash flows, and measuring the financial
worthiness of the project. As a result of this analysis, the financial opportunities and risks of the
project can be understood. Keep in mind that organizations have limited capital resources and
multiple projects will be competing for funding. The more expensive the project, the more rigorous and detailed the analysis should be. Before illustrating this process with a detailed example,
we first introduce the framework we will apply to evaluate project investments and the common
assessment measures that are used.
Cash Flow Analysis and Measures
IT projects commonly involve an initial investment that produces a stream of benefits over time,
along with some ongoing support costs. Therefore, the value of the project must be measured
over time. Cash flows, both inflows and outflows, are estimated over some future period. Then,
these cash flows are evaluated using several techniques to judge whether the projected benefits
justify incurring the costs.
A very basic cash flow projection is shown in Figure 1-­8 to demonstrate these evaluation
techniques. In this simple example, a system is developed in Year 0 (the current year) costing
$100,000. Once the system is operational, benefits and on-­going costs are projected over 3 years.
In row 3 of this figure, net benefits are computed by subtracting each year’s total costs from its
total benefits. Finally, in row 4, we have computed a cumulative total of the net cash flows.
Year 0
Total Benefits
Year 1
Year 2
Year 3
Total
45,000
50,000
57,000
152,000
Total Costs
100,000
10,000
12,000
16,000
138,000
3
Net Benefits
(Total Benefits –Total Costs)
(100,000)
35,000
38,000
41,000
14,000
4
Cumulative Net Cash Flow
(100,000)
(65,000)
(27,000)
14,000
Two of the common methods for evaluating a project’s worth can now be determined. Each of
these calculations will be explained here:
Return on Investment The return on investment (ROI) is a calculation that measures the
average rate of return earned on the money invested in the project. ROI is a simple calculation
that divides the project’s net benefits (total benefits total costs) by the total costs. The ROI
formula is
ROI
ROI
Total Benefits Total Costs
Total Costs
152, 000 138, 000 14, 000
138, 000
138, 000
10.14%
A high ROI suggests that the project’s benefits far outweigh the project’s cost, although exactly
what constitutes a “high” ROI is unclear. ROI is commonly used in practice; however, it is hard to
interpret and should not be used as the only measure of a project’s worth.
FIGURE 1-­8 Simple
cash flow projection.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
22
The Systems Analyst and Information Systems Development
Break-­Even Point Another common approach to measuring a project’s worth is the break-­even
point. The break-­even point (also called the payback method) is defined as the number of years
it takes a firm to recover its original investment in the project from net cash flows. As shown in
row 4 of Figure 1-­8, the project’s cumulative cash flow figure becomes positive during Year 3, so
the initial investment is “paid back” over 2 years plus some fraction of the third year.
(In the year in which Cumulative Cash Flow turns positive:)
BEP
Number of years of
negative cash flow
That year’s Net Cash Flow That year’s Cumulative Cash Flow
That year’s Net Cash Flow
Using the values in Figure 1-­8, the BEP calculation is
BEP
2
41, 000 14, 000
41, 000
2
28, 000
41, 000
2.68 years
The break-­even point is intuitively easy to understand and does give an indication of a project’s liquidity, or the speed at which the project generates cash returns. Also, projects that produce higher returns early in the project’s life are thought to be less risky, since we can anticipate
near-­term events with more accuracy than long-­term events. The break-­even point ignores cash
flows that occur after the break-­even point has been reached; therefore, it is biased against longer-­
term projects.
Discounted Cash Flow Technique The simple cash flow projection shown in Figure 1-­8,
and the return on investment and break-­even point calculations all share the weakness of not
recognizing the time value of money. In these analyses, the timing of cash flows is ignored.
A dollar in Year 3 of the project is considered to be exactly equivalent to a dollar received
in Year 1.
Discounted cash flows are used to compare the present value of all cash inflows and outflows
for the project in today’s dollar terms. The key to understanding present values is to recognize that
if you had a dollar today, you could invest it and receive some rate of return on your investment.
Therefore, a dollar received in the future is worth less than a dollar received today, since you
forgo that potential return. If you have a friend who owes you $100 today, but instead gives you
that $100 in 3 years—­you’ve been had! Assuming you could have invested those dollars at a 10%
rate of return, you will be receiving the equivalent of $75 in today’s terms.
The basic formula to convert a future cash flow to its present value is
PV
Cash flow amount
(1 Rate of return)n
, where n is the year in which the cash flow occurs.
The rate of return used in the present value calculation is sometimes called the required rate
of return, or the cost of obtaining the capital needed to fund the project. Many organizations will
have determined the appropriate rate of return to use when analyzing IT investments. The systems analyst should consult with the organization’s finance department.
Using our previous illustration, $100 received in 3 years with a required rate of return of 10%
has a PV of $75.13.
PV
100
1 0.1
3
100
1.331
75.13
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Feasibility Analysis
23
In Figure 1-­9, the present value of the projected benefits and costs shown in Figure 1-­8 have
been calculated using a 10% required rate of return.
Year 0
Total Benefits
PV of Total Benefits
Year 1
Year 2
Year 3
45,000
50,000
57,000
40,909
41,322
42,825
Total Costs
100,000
10,000
12,000
16,000
PV of Total Costs
100,000
9,091
9,917
12,021
Total
125,056
131,029
FIGURE 1-­9
Discounted cash flow
projection.
Net Present Value (NPV) The NPV is simply the difference between the total present value
of the benefits and the total present value of the costs.
NPV
PV of Total Benefits
PV of Total Costs
$125, 056 $131, 029 $5, 973
As long as the NPV is greater than zero, the project is considered economically acceptable.
Unfortunately for this project, the NPV is less than zero, indicating that for a required rate of
return of 10%, this project should not be accepted. The required rate of return would have to be
something less than 6.65% before this project returns a positive NPV. This example illustrates
the fact that sometimes the “naïve” techniques of ROI and BEP find that the project appears
acceptable, but the more rigorous and financially correct NPV technique finds the project is
unacceptable.
Figure 1-­10 reviews the steps involved in performing an economic feasibility analysis. Each
step will be illustrated by an example in the upcoming sections.
Identify Costs and Benefits
The systems analyst’s first task when developing an economic feasibility analysis is to identify
the kinds of costs and benefits the system will have and list them along the left-­hand column of a
spreadsheet. Figure 1-­11 lists examples of costs and benefits that may be included. The costs and
1. Identify Costs and Benefits List the tangible costs and benefits for the project. Include both one-­time
and recurring costs.
2. Assign Values to Costs
and Benefits
Work with business users and IT professionals to create numbers for each
of the costs and benefits. Even intangibles should be valued if possible.
3. Determine Cash Flow
Forecast what the costs and benefits will be over a certain period, usually,
3–5 years. Apply a growth rate to the values, if necessary.
4. Assess Project’s
Economic Value
Evaluate the project’s expected returns in comparison to its costs. Use
one or more of the following evaluation techniques:
• Return on
Investment (ROI)
Calculate the rate of return earned on the money invested in the project,
using the ROI formula.
• Break-­Even Point (BEP)
Find the year in which the cumulative project benefits exceed cumulative
project costs. Apply the break-­even formula, using figures for that year.
This calculation measures how long it will take for the system to
produce benefits that cover its costs.
• Net Present Value (NPV) Restate all costs and benefits in today’s dollar terms (present value), using
an appropriate discount rate. Determine whether the total present value
of benefits is greater than or less than the total present value of costs.
FIGURE 1-­10 Steps
to conduct an economic
feasibility analysis.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
24
The Systems Analyst and Information Systems Development
Development Costs
Development team salaries
Consultant fees
Development training
Hardware and software
Vendor installation
Office space and equipment
Data conversion costs
Tangible Benefits
FIGURE 1-­11
Example of costs
and benefits for
economic feasibility.
Increased sales
Reductions in staff
Reductions in inventory
Reductions in IT costs
Better supplier prices
Operational Costs
Software upgrades
Software licensing fees
Hardware repair and upgrades
Cloud storage fees
Operational team salaries
Communications charges
User training
Intangible Benefits
Increased market share
Increased brand recognition
Higher-­quality products
Improved customer service
Better supplier relations
benefits can be broken down into four categories: (1) development costs, (2) operational costs, (3)
tangible benefits, and (4) intangibles. Development costs are those tangible expenses that are
incurred during the creation of the system, such as salaries for the project team, hardware and
software expenses, consultant fees, training, and office space and equipment. Development costs
are usually thought of as one-­time costs. Operational costs are those tangible costs that are
required to operate the system, such as the salaries for operations staff, software licensing fees,
equipment upgrades, and cloud vendor fees. Operational costs are usually thought of as ongoing
costs. As you can see from the list of Operational Costs in Figure 1-­11, it is important to include
every relevant cost factor over the life of the system, so that we estimate the Total Cost of Ownership (TCO).
Tangible benefits include revenue that the system enables the organization to collect, such
as increased sales. In addition, the system may enable the organization to avoid certain costs,
leading to another type of tangible benefit: cost savings. For example, if the system produces a
reduction in needed staff, lower salary costs result. Similarly, a reduction in required inventory
levels due to the new system produces lower inventory costs. In these examples, the reduction in
costs is a tangible benefit of the new system.
Of course, a project also can affect the organization’s bottom line by reaping intangible benefits
or incurring intangible costs. Intangible costs and benefits are more difficult to incorporate into the
economic feasibility analysis because they are based on intuition and belief rather than on “hard
numbers.” Nonetheless, they should be listed in the spreadsheet along with the tangible items.
Assign Values to Costs and Benefits
Once the types of costs and benefits have been identified, the analyst needs to assign specific
dollar values to them. This may seem impossible—­How can someone quantify costs and benefits
that have not happened yet? And how can those predictions be realistic? Although this task is
exceedingly difficult, you must do the best you can to come up with reasonable numbers for all
of the costs and benefits. Only then can the approval committee make an informed decision about
whether to move ahead with the project.
The most effective strategy for estimating costs and benefits is to rely on the people who
have the best understanding of them. For example, costs and benefits that are related to the
technology or the project itself can be provided by the company’s IT group or external consultants, and business users can develop the numbers associated with the business (e.g., sales
projections, order levels). The company also can consider past projects, industry reports, and
vendor information, although these sources probably will be a bit less accurate. Likely, all the
estimates will be revised as the project proceeds.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
25
Feasibility Analysis
If predicting a specific value for a cost or benefit is proving difficult, it may be useful to estimate
a range of values for the cost or benefit and then assign a likelihood (probability) estimate to each
value. With this information, an expected value for the cost or benefit can be calculated. Recall
the calculations shown in Figure 1-­6 in which the DrōnTeq staff developed expected values for
projected revenue. As more information is learned during the project, the value estimates and the
probability estimates can be revised, resulting in a revised expected value for the cost or benefit.
What about the intangible benefits and costs? Sometimes, it is acceptable to list intangible
benefits, such as improved customer service, without assigning a dollar value. Other times, estimates have to be made regarding how much an intangible benefit is “worth.” We suggest that you
quantify intangible costs or benefits if possible. If you do not, how will you know if they have
been realized? Suppose that a system claims to improve customer service. This benefit is intangible but let us assume that the improvement in customer service will decrease the number of customer complaints by 10% each year over 3 years and that $200,000 is currently spent on phone
charges and phone operators who handle complaint calls. Suddenly, we have some very tangible
numbers with which to set goals and measure the originally intangible benefit.
A detailed cost–benefit analysis is shown in Figure 1-­12. In this example, benefits accrue
because the project is expected to increase sales, reduce customer complaint calls, and lower
2022
2023
2024
2025
2026
Total
Benefits
Increased sales
500,000
530,000
561,800
595,508
2,187,308
Reduction in customer complaint callsa
70,000
70,000
70,000
70,000
280,000
Reduced inventory costs
68,000
68,000
68,000
68,000
272,000
638,000
668,000
699,800
733,508
2,739,308
Total Benefits
b
Development Costs
2 servers @ $125,000
250,000
0
0
0
0
250,000
Printer
100,000
0
0
0
0
100,000
Software licenses
34,825
0
0
0
0
34,825
Server software
10,945
0
0
0
0
10,945
Development labor
Total Development Costs
1,236,525
0
0
0
0
1,236,525
1,632,295
0
0
0
0
1,632,295
50,000
50,000
50,000
50,000
200,000
Operational Costs
Hardware
Software
Operational labor
Total Operational Costs
Total Costs
1,632,295
20,000
20,000
20,000
20,000
80,000
115,000
119,600
124,384
129,359
488,343
185,000
189,600
194,384
199,359
768,343
185,000
189,600
194,384
199,359
2,400,638
338,670
Total Benefits − Total Costs
(1,632,295)
453,000
478,400
505,416
534,149
Cumulative Net Cash Flow
(1,632,295)
(1,179,295)
(700,895)
(195,479)
338,670
Return on Investment (ROI)
14.1% (338,670/2,400,638)
Break-­Even Point
3.37 years (3 years of negative cumulative
cash flow + [534,149 −
338,670]/534,149 = 0.37)
Customer service values are based on reduced costs of handling customer complaint phone calls.
a
An important yet intangible benefit will be the ability to offer services that our competitors currently offer.
b
FIGURE 1-­12 Cost–benefit analysis—­simple cash flow method.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Get Complete eBook Download link Below for Instant Download:
https://browsegrades.net/documents/286751/ebook-payment-link-forinstant-download-after-payment
Get Complete eBook Download by Email at discountsmtb@hotmail.com
26
The Systems Analyst and Information Systems Development
inventory costs. For simplicity, all development costs are assumed to occur in the current year
2022, and all benefits and operational costs are assumed to begin when the system is implemented at the start of 2023 and continue through 2026. Notice that the customer service intangible benefit has been quantified, based on a decrease in customer complaint phone calls. The
intangible benefit of being able to offer services that competitors currently offer was not quantified, but it was listed so that the approval committee will consider the benefit when assessing the
system’s economic feasibility.
Determine Cash Flow
A formal cost–benefit analysis usually contains costs and benefits over a selected number of
years (usually, 3–5 years) to show cash flow over time (Figures 1-­8 and 1-­12). For example,
Figure 1-­12 lists the same amount for customer complaint calls, inventory costs, hardware, and
software for all 4 years. Often, amounts are augmented by some rate of growth to adjust for inflation or business improvements, as shown by the 6% increase that is added to the sales numbers
in the sample spreadsheet. Similarly, labor costs are assumed to increase at a 4% rate each year.
Finally, totals are added to determine the overall benefits and costs.
Determine ROI
Figure 1-­12 includes the ROI calculation for our example project. This project’s ROI is calculated
to be 14.1%.
Determine BEP
Figure 1-­12 also includes the BEP calculation for our example project. This project’s BEP is calculated to be 3.37 years.
Determine NPV
In Figure 1-­13, the present value of the costs and benefits has been calculated and added to our
example spreadsheet, using a 6% rate of return. The NPV is simply the difference between the
total present value of the benefits and the total present value of the costs. If the NPV is greater
than zero, the project is considered economically viable. In this example, since NPV is $68,292,
the project should be accepted from an economic feasibility perspective.
Concepts in Action 1-­D
Intangible Value at Carlson Hospitality
I conducted a case study at Carlson Hospitality, a global leader
in hospitality services, encompassing more than 1,300 hotel,
resort, restaurant, and cruise ship operations in 79 countries.
One of its brands, Radisson Hotels & Resorts, researched guest
stay information and guest satisfaction surveys. The company
was able to quantify how much of a guest’s lifetime value
can be attributed to his or her perception of the stay experience. As a result, Radisson knows how much of the collective
future value of the enterprise is at stake, given the perceived
quality of the stay experience. Using this model, Radisson can
confidently show that a 10% increase in customer satisfaction among the 10% of highest-­quality customers will capture
a one-­point market share for the brand. Each point in market
share for the Radisson brand is worth $20 million in additional
revenue. Question
How can a project team use this information to help determine
the economic feasibility of a system?
Get Complete eBook Download by Email at discountsmtb@hotmail.com
27
Feasibility Analysis
2022
2023
2024
2025
2026
Total
Benefits
500,000
530,000
561,800
595,508
Reduction in customer
complaint callsa
Increased sales
70,000
70,000
70,000
70,000
Reduced inventory costs
68,000
68,000
68,000
68,000
Total Benefits
b
638,000
668,000
699,800
733,508
Present Value Total Benefits
601,887
594,518
587,566
581,007
0
0
0
0
2,364,978
Development Costs
2 Servers @ $125,000
250,000
Printer
100,000
0
0
0
0
34,825
0
0
0
0
Software licenses
Server software
Development labor
Total Development Costs
10,945
0
0
0
0
1,236,525
0
0
0
0
1,632,295
0
0
0
0
Operational Costs
Hardware
50,000
50,000
50,000
50,000
Software
20,000
20,000
20,000
20,000
Operational labor
Total Operational Costs
115,000
119,600
124,384
129,359
185,000
189,600
194,384
199,359
Total Costs
1,632,295
185,000
189,600
194,384
199,359
Present Value Total Costs
1,632,295
174,528
168,743
163,209
157,911
NPV (PV Total Benefits – PV
Total Costs)
Customer service values are based on reduced costs of handling customer complaint phone calls.
a
An important yet intangible benefit will be the ability to offer services that our competitors currently offer.
b
FIGURE 1-­13 Cost–benefit analysis—­discounted cash flow method.
Organizational Feasibility
The organizational feasibility of the system concerns how well the system ultimately will be
accepted by its users and incorporated into the ongoing operations of the organization. There are
many organizational factors that can have an impact on the project, and seasoned developers
know that organizational feasibility can be the most difficult feasibility dimension to assess. In
essence, an organizational feasibility analysis attempts to answer the question “If we build it, will
they come?”
One way to assess the organizational feasibility of the project is to understand how well
the goals of the project align with business objectives. Strategic alignment is the fit between
the project and business strategy—­the greater the alignment, the less risky the project will be,
from an organizational feasibility perspective. For example, if the marketing department has
decided to become more customer focused, then a CRM project that produces integrated customer information would have strong strategic alignment with marketing’s goal. Many projects
fail if the IT department alone initiates them and there is little or no alignment with business-­unit
or organizational strategies.
2,296,686
68,292
Get Complete eBook Download by Email at discountsmtb@hotmail.com
28
The Systems Analyst and Information Systems Development
A second way to assess organizational feasibility is to conduct a stakeholder analysis.4 A
stakeholder is a person, group, or organization that can affect (or can be affected by) a new
system. In general, the most important stakeholders in the introduction of a new system are
the project champion, organizational management, and system users (Figure 1-­14), but systems
sometimes affect other stakeholders as well. For example, a change to a purchasing system will
probably affect the firm’s supply chain partners.
The champion is a high-­level executive and is usually, but not always, the project sponsor who created the system request. The champion supports the project by providing time and
resources (e.g., money) and by giving political support to the project by conveying its importance
to other decision makers. More than one champion is preferable because if the champion leaves
the organization, the support could leave as well.
While champions provide day-­to-­day support for the system, organizational management
also needs to support the project. Such management support conveys to the rest of the organization the belief that the system will make a valuable contribution and that necessary resources will
be made available. Ideally, the management should encourage people in the organization to use
the system and to accept the many changes that the system will likely create.
A third important set of stakeholders is the system users who ultimately will use the system
once it has been installed in the organization. Too often, the project team meets with users at the
beginning of a project and then disappears until after the system is created. In this situation, the
final product rarely meets the expectations and needs of those who are supposed to use it, because
needs change and users become savvier as the project progresses. User participation should be
promoted throughout the development process to make sure that the final system will be accepted
and used, by getting users actively involved in the development of the system (e.g., performing
tasks, providing feedback, and making decisions).
The third column in Figure 1-­14 suggests that actions can be taken that influence organizational feasibility. When the organizational feasibility assessment reveals high risks, the team
members should employ actions like these to overcome the organizational feasibility concerns.
Role
Champion
A champion:
•
•
•
•
Initiates the project
Promotes the project
Allocates his or her time to the project
Provides resources
Organizational
Management
Organizational managers:
System Users
Users:
FIGURE 1-­14
Important
stakeholders for
organizational
feasibility.
• Know about the project
• Budget enough money for the project
• Encourage users to accept and use
the system
To Enhance Organizational Feasibility
• Make a presentation about the objectives of the project and the proposed
benefits to those executives who will
benefit directly from the system.
• Create a prototype of the system to
demonstrate its potential value.
• Make a presentation to the
management about the objectives of
the project and the proposed benefits.
• Market the benefits of the system, using
memos and organizational newsletters.
• Encourage the champion to talk about
the project with his organizational
newsletters or her peers.
• Assign users official roles on the
project team.
• Make decisions that influence the project
• Assign users specific tasks to perform,
• Perform hands-­on activities for the project
with clear deadlines.
• Ultimately determine whether the
• Ask for feedback from users regularly
project is successful using or not using
(e.g., at weekly meetings).
the system
A good book on stakeholder analysis that presents a series of stakeholder analysis techniques is R. O. Mason and I. I. Mittroff,
Challenging Strategic Planning Assumptions: Theory, Cases, and Techniques, New York: John Wiley & Sons, 1981.
4
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Feasibility Analysis
Concepts in Action 1-­E
Return on Investment
Many companies are undergoing server virtualization. This
is the concept of putting multiple “virtual” servers onto one
physical device. The payoffs can be significant: fewer servers,
less electricity, less generated heat, less air conditioning, less
infrastructure and administration costs, increased flexibility,
less physical presence (i.e., smaller server rooms), faster maintenance of servers, and more. There are costs, of course, such
as licensing the virtualization software, labor costs in establishing the virtual servers onto a physical device, labor costs
in updating tables, and access. But determining the return on
YOUR TURN 1-­4
29
investment can be a challenge. Some companies have lost
money on server virtualization, while most would say that they
have gained a positive return on investment but have not really
quantified the results.
Questions
1. How might a company really determine the return on
investment for server virtualization?
2. Is this a project that a systems analyst might be involved in?
Why or why not?
Too Much Paper, Part 2
Review the description of the South Dakota workers’
compensation project in Your Turn 1-­3. There were legal hurdles to implementing a digital solution to handle workers’
compensation claims. One hurdle was that the previous paper
method had physical signatures from employees signing off
that they had received treatment or that the doctor had signed
off on medical treatment performed. How could such permissions be preserved and duplicated digitally?
In addition, some clerks were afraid that the digital solution might not work. What if they could not find an electronic
file on the computer? What if a hard drive crashed or the files
were accidentally deleted? What if they could not retrieve the
electronic file?
Questions
1. What legal issues might arise from having only “digital
signatures” or only electronic/paper copies of documents
instead of physical documents? How do these issues affect
the project’s feasibility?
2. In terms of organizational feasibility and adoption, what
might an analyst do to convince these clerks to adopt and
use the new technology?
The final feasibility study helps organizations make wiser investments regarding IS because
it forces project teams to consider technical, economic, and organizational factors that can
affect their projects. It protects IT professionals from criticism by keeping the business
units educated about decisions and positioned as the leaders in the decision-­making process.
Remember—­the feasibility study should be revised throughout the project at points where the
project team makes critical decisions about the system (e.g., before the design begins). The
final feasibility study can be used to support and explain the critical choices that are made
throughout the SDLC.
Applying the Concepts at DrōnTeq
The steering committee met and placed the Client Services project high on its list of projects.
The next step was for Carmella and Jiang to develop the feasibility analysis. Figure 1-­15 presents the executive summary page of the feasibility study. The report itself was about 10 pages
long and provided additional detail and supporting documentation.
As shown in Figure 1-­15, the project is somewhat risky from a technical perspective. DrōnTeq
has experience with the technology that will be used, but the proposed application has some unfamiliar elements. User involvement will be important. Project size is moderate, and the system
should be very compatible with the existing infrastructure.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
30
The Systems Analyst and Information Systems Development
Client Services Project Executive Summary
Carmella Herrera and Jiang Tsaio created the following feasibility analysis for the DrōnTeq Client Services Project. The System Request
is attached, along with the detailed feasibility study. The highlights of the feasibility analysis are as follows:
Technical Feasibility
The Client Services project is feasible technically, although there is some risk.
DrōnTeq’s risk regarding familiarity with a customer-­facing drone service request system is moderate.
• The Sales Department uses a customer-­facing system to allow customers to configure and place orders for commercial drone purchases. This system was developed by the DrōnTeq IS department.
• The Client Service business model contains an unfamiliar element—­the use of a bidding approach to obtain offers from pilots and
determine the winning bid based on multiple factors.
• Business user involvement will be essential.
DrōnTeq’s risk regarding familiarity with the technology is low.
• The IT department has extensive knowledge of the current Web-­based customer order system and the databases and Internet
technology it uses.
• The technology used in the proposed Client Services Project will be very similar to existing systems.
The project size is considered moderately low.
• Project scope has been deliberately limited to the front-­end of this overall system: customer request, pilot notification, pilot bidding, and flight assignment.
• The project team will likely consist of five or fewer people.
The compatibility with DrōnTeq’s existing technical infrastructure should be good.
• An Internet infrastructure is already in place at corporate headquarters.
• The system will be based on existing technology infrastructure currently supporting the Sales Department.
Economic Feasibility
A cost–benefit analysis was performed; see the attached spreadsheet for details (provided in Appendix 1A). Conservative estimates
show that the Client Services project has a good chance of enhancing the company’s bottom line.
ROI over 3 years: 43%
NPV over 3 years: $675,818
Break-­even occurs after 1.62 years
Intangible Costs and Benefits
Enhanced competitive position through expansion of our drone brand into the drone flight service market. Clients who don’t wish to
own and operate their own drones will still have a convenient and cost–effective way to receive the benefits provided from our drone
flights and data analysis services.
Organizational Feasibility
From an organizational perspective, this project has moderately high risk.
• Top management support: The top executives of the company strongly support the project.
• Project champion: Carmella Hererra is a respected and knowledgeable business executive.
• Organizational management: Overall, managers throughout DrōnTeq support the creation of the new business unit. The Sales
department, however, may experience some drone sales loss as some prospective customers choose to purchase drone flight services rather than purchase and operate drones themselves.
• Customers: Customers will expect a user interface that is clear and simple to use. Customers will want to enter basic facts one
time and have those facts stored securely. This will enable them to request repeat flight services quickly and easily. Customers will
expect prompt response and accurate status information on all flight service requests. Without these features, customers may be
unwilling to use this service.
• Pilots: Pilots will depend on this system to provide notification of potential drone flights, bid on flights, and receive flight assignments; therefore, pilots will demand a system that is quick and easy to use and that embodies a fair and consistent bidding and
flight assignment mechanism. Otherwise, pilots will reject the business model of the Client Services business unit and the venture’s
success is doubtful.
Additional Comments
• The top executives view this as a strategic system. This system will allow us to extend our drone services to a new audience. Our
marketing research tells us this market is strong and we believe the services will be well accepted.
• To enhance acceptance of the new service, the introduction of the system should coincide with the agricultural growing season
since agricultural users are a primary audience.
FIGURE 1-­15 Feasibility analysis executive summary for DrōnTeq.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Key Terms
31
The economic feasibility analysis includes the assumptions that Carmella made in the system
request. The summary spreadsheet that led to the values in the feasibility analysis has been
included in Appendix 1A. Development costs are expected to be about $558,000. This is a very
rough estimate, as Jiang has had to make some assumptions about the amount of time it will take
to design and program the system. Nonetheless, the Client Services project appears to be very
strong economically.
The organizational feasibility is presented in Figure 1-­15. There is a strong champion, well
placed in the organization, to support the project. The project originated in the business or
functional side of the company, not the IS department, and support for the project among the
senior management team is strong.
Additional stakeholders in the project are the managers throughout the organization, customers, and drone pilots. Organizational managers are supportive of the new Client Services
business unit. The Sales department may lose some drone sales if prospective drone purchasers
choose to use the drone flight services rather than buy and operate a drone themselves. Customer
acceptance of the drone flight service product will depend, in part, on the quality, simplicity, and
speed of the user interface of the system that enables quick and easy flight requests. Pilot recruitment and retention will require the system to be quick and easy to use and provide a fair and
consistent bidding and flight assignment mechanism.
CHAPTER REVIEW
After reading and studying this chapter, you should be able to:
• Explain the role of the systems analyst in the process of developing IS.
• Discuss the skills needed to be a successful systems analyst.
• List and explain the four primary phases of the SDLC.
• Explain the ways that projects are identified and initiated.
• Explain why it is important to ensure that a proposed IS will
add value to the organization.
• Describe the purpose of the system request and explain the
contents of its four main sections.
• Be able to create a system request for a proposed project.
• Discuss the purpose of the feasibility study.
• Describe the issues that are considered when evaluating a project’s technical feasibility.
• Be able to develop an economic feasibility assessment for a
project.
• Understand and evaluate the organizational feasibility of a
project.
KEY TERMS
Analysis models
Analysis phase
Analysis strategy
Approval committee
Architecture design
As-­is system
Break-­even point
Business analyst
Business need
Business process
automation (BPA)
Business process
improvement (BPI)
Business process
management (BPM)
Business process
reengineering
(BPR)
Business requirements
Business value
Champion
Change management analyst
Compatibility
Construction
Cost–benefit analysis
Database and file
specifications
Deliverables
Design phase
Design strategy
Development costs
Economic feasibility
Emerging technology
Familiarity with the
application
Familiarity with the
technology
Feasibility analysis
Feasibility study
First mover
Gradual refinement
Implementation phase
Infrastructure analyst
Installation
Intangible benefits
Intangible costs
Intangible value
Interface design
Net present
value (NPV)
Operational costs
Organizational
feasibility
Organizational
management
Payback method
Phases
Planning phase
Program design
Project initiation
Project management
Project manager
Project size
Project sponsor
Requirements analyst
Software architect
Special issues
Stakeholder
Stakeholder analysis
Steering committee
Step
Strategic alignment
Support plan
System proposal
System request
System specification
System users
Systems analyst
Systems development
life cycle (SDLC)
Tangible benefits
Tangible value
Technical feasibility
Technical risk analysis
Technique
To-be system
Training
Total cost of ownership
(TCO)
Get Complete eBook Download by Email at discountsmtb@hotmail.com
32
The Systems Analyst and Information Systems Development
QUESTIONS
1. List and describe the six general skills all project team members should have.
17. Why should the system request be created by a businessperson as opposed to an IS professional?
2. What are the major roles on a project team?
18. What is the difference between intangible value and tangible
value? Give three examples of each.
3. Compare and contrast the role of a systems analyst, business
analyst, and infrastructure analyst.
4. Compare and contrast the role of requirements analyst, change
management analyst, and project manager.
5. Describe the major phases in the systems development life
cycle (SDLC).
6. Describe the principal steps in the planning phase. What are
the major deliverables?
7. Describe the principal steps in the analysis phase. What are
the major deliverables?
8. Describe the principal steps in the design phase. What are the
major deliverables?
9. Describe the principal steps in the implementation phase.
What are the major deliverables?
19. What are the purposes of the system request and the feasibility
analysis? How are they used in the project selection process?
20. Describe two special issues that may be important to list on a
system request.
21. Describe the three dimensions of feasibility analysis.
22. What factors are used to determine project size?
23. Describe a “risky” project in terms of technical feasibility.
Describe a project that would not be considered risky.
24. What are the steps for assessing economic feasibility?
Describe each step.
25. List two intangible benefits. Describe how these benefits can
be quantified.
11. What does gradual refinement mean in the context of SDLC?
26. List two tangible benefits and two operational costs for a system. How would you determine the values that should be
assigned to each item?
12. Describe the four steps of BPM. Why do companies adopt
BPM as a management strategy?
27. Explain how an expected value can be calculated for a cost or
benefit. When would this be done?
13. Compare and contrast BPA, BPI, and BPR. Which is most
risky? Which has the greatest potential value?
28. Explain the net present value and return on investment for a
cost–benefit analysis. Why would these calculations be used?
14. Give three examples of business needs for a system.
even point for the project? How is it
29. What is the break-­
calculated?
10. Which phase in the SDLC is the most important?
15. Describe the roles of the project sponsor and the approval
committee.
16. What is the purpose of an approval committee? Who is usually on this committee?
30. What is stakeholder analysis? Discuss three stakeholders that
would be relevant for most projects.
EXERCISES
A.
Go to www.bls.gov and perform a search for “systems
analyst.” What is the employment outlook for this career?
Compare and contrast the skills listed with the skills that were
presented in this chapter.
B.
Think about your ideal analyst position. Write a job posting
to hire someone for that position. What requirements would
the job have? What skills and experience would be required?
How would applicants demonstrate that they have the appropriate skills and experience?
C.
Locate a news article in an IT trade website (e.g., Computerworld.com, InformationWeek.com) about an organization
that is implementing a new computer system. Describe the
tangible and intangible values that the organization seeks
from the new system.
D.
Car dealers have realized how profitable it can be to sell automobiles by using the Web. Pretend that you work for a local
car dealership that is part of a large chain such as CarMax.
Create a system request that you might use to develop a Web-­
based sales system. Remember to list special issues that are
relevant to the project.
E.
Think about your own university or college and choose an
idea that could improve student satisfaction with the course
enrollment process. Currently, can students enroll for classes from anywhere? How long does it take? Are directions
simple to follow? Is online help available? Next, think
about how technology can help support your idea. Would
you need completely new technology? Can the current system be changed?
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Minicases
F.
For exercise E, create a system request that you could give to
the administration that explains the sponsor, business need,
business requirements, and potential value of the project.
Include any constraints or issues that should be considered.
G. Think about the idea that you developed in Exercise E to
improve your university or college course enrollment process. List three things that influence the technical feasibility
of the system, the economic feasibility of the system, and the
organizational feasibility of the system. How can you learn
more about the issues that affect the three kinds of feasibility?
H. Amazon.com was successful when it decided to extend its
offerings beyond books to many other products. Amazon.
33
com was unable to compete successfully with eBay.com’s
auction site, however, and eventually abandoned its own
auction site. What feasibility factors probably had the most
significance in this failure? Explain.
I.
Interview someone who works in a large organization and ask
him or her to describe the approval process that exists for proposed new development projects. What do they think about
the process? What are the problems? What are the benefits?
J.
Reread the “Your Turn 1-­2” (Implementing a Satellite Data
Network). Create a list of the stakeholders that should be considered in a stakeholder analysis of this project.
MINICASES
1.
Megan Simpson, manager of western regional sales at the
Whitefield Company, requested that the IS department
develop a sales force communication and tracking system
that would enable her to better keep up with her sales staff.
Megan wanted to be able to post messages to her team on
many topics, including sales tips and strategies, update them
on the firm’s products, and point out changes in the competitive environment. She also wanted her team to be able to
post responses to her posts plus their own ideas, update their
schedules, and share their sales success stories.
Unfortunately, due to the massive backlog of work facing the Whitefield Company’s IS department, her request
was given a low priority. After 6 months of inaction by the IS
department, Megan decided to take matters into her own hands.
Following the advice of friends, Megan set up a Word Press
site to use as a sales force communication and tracking system.
Although it took longer than expected, Megan’s site has
been “completed” for about 6 weeks. It still has many features
that do not work very well, and some functions lead to dead
ends. Members of the sales force initially were quite interested in the system. They quickly discovered, however, that
the system was confusing and did not seem to provide many
benefits, so their interest quickly waned. Megan’s assistant
is so mistrustful of the scheduling information posted on the
site that she has secretly gone back to using her old paper-­
based system of tracking the sales staff’s activities, since it is
much more reliable.
Over dinner one evening, Megan complained to a systems analyst friend, “I don’t know what went wrong with this
project. It seemed pretty simple to me. The IS guys gave me
some suggestions for how I should approach this project, but
it seemed like such an elaborate set of steps and tasks. I didn’t
think all that really applied to this small system. I just thought
I’d set up the basics for the system and then tweak it around
until I got what I wanted without all the fuss and bother of the
approach the IS guys were pushing. I mean, doesn’t that just
apply to their big, expensive system projects?”
To understand where Megan went wrong, apply what you
know about the SDLC to answer the following questions:
A. Planning:
i. What is the purpose of the Planning Phase for a project
such as this?
ii. What are the typical outcomes of the Planning Phase?
iii. How did not doing this step affect Megan’s
project outcome?
B. Analysis:
i. What is the purpose of the Analysis Phase?
ii. What is the key outcome produced during the Analysis Phase?
iii. In what ways do you think this project was hurt by not
going through a typical Analysis Phase?
C. Design:
i. What is the purpose of the Design Phase?
ii. How do you think this project could have been
improved by going through a typical Design Phase?
iii. Do you think Megan’s assistant and sales force members could have helped at all during the design phase?
If so, how?
D. Implementation:
i. What type of work is done in the Implementation
Phase for a project like this?
ii. What is usually done during the Implementation
Phase to ensure that the users of the system are satisfied with it?
iii. Megan’s approach to “construction” was to throw
something together and “tweak it around.” How do
you think that approach contributed to the problems
she is now experiencing with her project?
Get Complete eBook Download by Email at discountsmtb@hotmail.com
34
The Systems Analyst and Information Systems Development
Note: If using the flipped classroom model, students
should study the SDLC material before class. Divide the class
into four teams, assign each team one of the SDLC phases,
and have each team present the question’s answers to the rest
of the class.
2.
The Amberssen Specialty Company is a chain of 12 retail
stores that sell a variety of imported gift items, gourmet chocolates, cheeses, and wines in the Toronto area. Amberssen has an
IS staff of three people who have created a simple, but effective, IS of networked point-­of-­sale registers at the stores, and a
centralized accounting system at the company headquarters.
Harry Hilman, the head of Amberssen’s IS group, has just received the following memo from Bill Amberssen, Sales Director (and son of Amberssen’s founder):
Harry—­It’s time Amberssen Specialty launched itself on the
Internet. Many of our competitors are already there, selling
to customers without the expense of a retail storefront, and
we should be there too. I project that we could double or triple our annual revenues by selling our products on the
Internet. I’d like to have this ready by Thanksgiving, in time
for the prime holiday gift-­shopping season. Bill
After pondering this memo for several days, Harry scheduled a meeting with Bill so that he could clarify Bill’s vision
of this venture. Using the standard content of a system request
as your guide, prepare a list of questions that Harry needs to
have answered about this project.
Note: If using the flipped classroom model, students should
study the System Request material before class. Divide the
class into small groups. Each group should prepare a list of key
questions. Then, compile a comprehensive list from all groups
and have the class rank the questions in order of importance.
3.
The Decker Company maintains a fleet of 10 service trucks
and crew which provides a variety of plumbing, heating, and
cooling repair services to residential customers. Currently, it
takes on average about 6 hours before a service team responds
to a service request. Each truck and crew averages 12 service
calls per week, and the average revenue earned per service
call is $150. Each truck is in service 50 weeks per year. Due
to the difficulty in scheduling and routing, there is considerable slack time for each truck and crew during a typical week.
Decker management is evaluating the purchase of a prewritten routing and scheduling software package. The benefits
of the system will include reduced response time to service
requests and more productive service teams, but management
is having trouble quantifying these benefits.
One approach is to make an estimate of how much service response time will decrease with the new system, which
then can be used to project the increase in the number of service calls made each week. For example, if the system permits the average service response time to fall to 4 hours, the
management believes that each truck will be able to make 16
service calls per week on average—­an increase of 4 calls per
week. With each truck making 4 additional calls per week
and the average revenue per call at $150, the revenue increase
per truck per week is $600(4 $150). With 10 trucks in service 50 weeks per year, the average annual revenue increase
will be $300, 000($600 10 50) .
The Decker Company management is unsure whether
the new system will enable response time to fall to 4
hours on average or will be some other number. Therefore,
management has developed the following range of outcomes
that may be possible outcomes of the new system, along with
probability estimates of each outcome occurring:
New Response Time
# Calls/Truck/Week
Likelihood
2 hours
20
20%
3 hours
18
30%
4 hours
16
50%
Given these figures, prepare a spreadsheet model that
computes the expected value of the annual revenues to be
produced by this new system.
Martin is working to develop a preliminary cost–benefit
analysis for a new client-­server system. He has identified several cost factors and values for the new system, summarized
in the following tables:
Development Costs—­Personnel
2 Systems Analysts
400 hours/ea @ $50/hour
4 Programmer Analysts
250 hours/ea @ $35/hour
1 GUI Designer
200 hours/ea @ $40/hour
1 Telecommunications Specialist
50 hours/ea @ $50/hour
1 System Architect
100 hours/ea @ $50/hour
1 Database Specialist
15 hours/ea @ $45/hour
1 System Librarian
250 hours/ea @ $15/hour
Development Costs—­Training
4 Oracle training registration
$3,500/student
Development Costs—­New
Hardware and Software
1 Development server
$18,700
1 Server software (OS, misc.)
$1,500
1 DBMS server software
$7,500
7 DBMS client software
$950/client
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Appendix 1A: Detailed Economic Feasibility Analysis for DrōnTeq
Annual Operating Costs—­
Personnel
2 Programmer Analysts
125 hours/ea @ $35/hour
1 System Librarian
20 hours/ea @ $15/hour
Annual Operating Costs—­
Hardware, Software, and Misc.
1 Maintenance agreement
for server
$995
1 Maintenance agreement
for server
$525
DBMS software
Preprinted forms
APPENDIX 1A
15,000/year @ $.22/form
35
The benefits of the new system are expected to come from
two sources: increased sales and lower inventory levels. Sales
are expected to increase by $30,000 in the first year of the
system’s operation and will grow at a rate of 10% each year
thereafter. Savings from lower inventory levels are expected
to be $15,000 per year for each year of the project’s life.
Using a format like the spreadsheets in this chapter,
develop a spreadsheet that summarizes this project’s cash
flow, assuming a 4-­year useful life after the project is developed. Compute the present value of the cash flows, using an
interest rate of 9%.
What is the NPV for this project? What is the ROI for this
project? What is the break-­even point? Should this project be
accepted by the approval committee?
DETAILED ECONOMIC FEASIBILITY ANALYSIS FOR DRŌNTEQ
Figure 1A-­
1 contains the summary spreadsheet for the
DrōnTeq Client Services project. As shown, Carmella’s
initial sales projections are used for the first year’s revenues.
Revenues are projected to grow 10% in the second year and
8% in the third year.
Cost projections are based on Jiang’s assumptions about
the time it will take to develop the system and the resources
that will be required. Operating costs have a considerable
new labor component because a new business unit is being
created, requiring additional staff.5
Figure 1A-­1 incorporates several of the financial analysis
techniques we have discussed. The rows marked A and C
summarize the annual benefits and costs, respectively. The
row marked D shows the yearly net benefits (total benefits –
total costs). The ROI calculation shows that this project is
expected to return 43% on the investment, calculated by
dividing the difference between total benefits in row A and
total costs in row C by the total costs in row C.
Row E shows the cumulative cash flow for the project,
and this is used to determine the breakeven point. As seen
in Figure 1A-­1, the project fully recovers its costs in the
second year, since the cumulative net cash flow becomes
positive in the second year. It takes about 0.27 of the second
year before the costs are recovered.
The row marked B computes the present value of each
year’s total benefits, and the row marked F computes the
present value of each year’s total costs. A 9% required rate
of return was used in these calculations. These values are
used in the NPV calculation. The total present value of costs
is subtracted from the total present value of benefits, and the
result is $675,818, indicating the strong financial viability
of this investment.
This spreadsheet shows that this project can add
significant business value even if the underlying assumptions prove to be overly optimistic.
Some of the salary information may seem high to you. Keep in mind that most companies use a “full cost” model for estimating salary cost in which all benefits
(e.g., health insurance, retirement, payroll taxes) are included in salaries when estimating costs.
5
Get Complete eBook Download by Email at discountsmtb@hotmail.com
36
The Systems Analyst and Information Systems Development
2022
2023
2024
2025
Total
Revenue from new pilot contracts and drone leases
357,500
393,250
424,710
1,175,460
Sales from drone flight service and data analysis
565,000
621,500
671,220
1,857,720
Ⓐ Total Benefits
922,500
1,014,750
1,095,930
3,033,180
Ⓑ Present Value Total Benefits
846,330
854,095
846,259
2,546,684
Benefits
Development Costs
Labor -­Analysis and Design
300,000
300,000
Labor -­ Implementation
175,000
175,000
Office space and equipment
Software
Hardware
Total Development Costs
8,000
8,000
25,000
25,000
50,000
50,000
558,000
558,000
Operational Costs
Labor -­ Webmaster
85,000
89,250
93,713
267,963
Labor -­Network technician
60,000
63,000
66,150
189,150
Labor -­Computer operations
50,000
52,500
55,125
157,625
Labor -­Business manager
60,000
63,000
66,150
189,150
Labor -­Assistant manager
45,000
47,250
49,613
141,863
120,000
126,000
132,300
378,300
Software upgrades
5,000
5,000
5,000
15,000
Software licenses
8,000
8,000
8,000
24,000
10,000
10,000
10,000
30,000
Labor -­IS maintenance developers (3)
Hardware upgrades
User training and support
Additional ISP charges
8,000
8,400
8,820
25,220
15,000
15,750
16,538
47,288
Marketing expenses
30,000
31,500
33,075
94,575
Total Operational Costs
496,000
519,650
544,483
1,560,133
558,000
496,000
519,650
544,483
2,118,133
Ⓓ Total Benefits –­Total Costs
–­558,000
350,330
334,445
301,777
428,552
Ⓔ Cumulative New Cash Flow
–­558,000
–­207,670
126,775
428,552
558,000
455,046
437,379
420,440
Ⓒ Total Costs
Ⓕ Present Value Total Costs
Return on Investment (ROI)
Break-Even Point
NPV (PV Total Benefits – PV Total Costs)
Intangible Costs and Benefits
143%
1,870,865
(3,033,180 / 2,118,133)
1.62 years (Costs are fully recovered in the second year;
[334,445 – 126,775] / 334.445)
675,819
Intangible Cost: Effective drone flight service option may reduce the
demand for actual drone sales
Intangible Benefit: Enhanced competitive position through expansion of
our drone brand into the drone flight service market
FIGURE 1A-­1 Economic feasibility analysis for DrōnTeq.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Project Selection and Management
2
PLANNING
TASK
CHECKLIST
✔
✔
✔
✔
✔
Identify project.
Develop systems request.
Analyze technical feasibility.
Analyze economic feasibility.
Analyze organizational feasibility.
Perform project selection review.
Manage scope.
Staff project.
Create project charter.
Set up CASE repository.
Develop standards.
Begin documentation.
Assess and manage risk.
This chapter discusses how organizations evaluate and select projects to undertake from the
many available projects. Once a project has been selected, the project manager plans the project.
Project management involves many tasks. Here, we focus on selecting a project methodology,
identifying project staffing requirements, and preparing to manage and control the project. These
steps produce important project management deliverables, including the staffing plan, standards
list, project charter, and risk assessment.
37
Get Complete eBook Download by Email at discountsmtb@hotmail.com
38
Project Selection and Management
OBJECTIVES
• Explain how projects are selected in some organizations.
• Describe various approaches to the systems development life cycle (SDLC) that can
be used to structure a development project.
• Explain how to select a project methodology based on project characteristics.
• Describe project staffing issues and concerns.
• Describe and apply techniques to coordinate and manage the project.
• Explain how to manage risk on the project.
Introduction
Most IT departments face a demand for IT projects that far exceeds the department’s ability to
supply them. In the past 10 years, business application growth has exploded, and chief
information officers (CIOs) are challenged to select projects that will provide the highest possible return on IT investments while managing project risk. In a recent analysis, AMR Research,
Inc., found that 2–15% of projects taken on by IT departments are not strategic to the business.1
In today’s globally competitive business environment, the corporate IT department needs to carefully prioritize, select, and manage its portfolio of development projects.
Historically, IT departments have tended to select projects by ad hoc methods: first-­in, first-­
out; political clout; or the squeaky wheel getting the grease. In recent years, IT departments have
collected project information and mapped the projects’ contributions to business goals, using a
project portfolio perspective.2
Project portfolio management, a process of selecting, prioritizing, and monitoring project
results, has become a critical success factor for IT departments facing too many potential projects
with too few resources.3 Software for project portfolio management, such as Hewlett Packard’s
Project and Portfolio Management, Primavera Systems’ ProSight, and open-­source Project.net,
has become a valuable tool for IT organizations.
Once selected, a systems development project undergoes a thorough process of project
management, the process of planning and controlling the project within a specified time frame,
at minimum cost, with the desired outcomes.4 A project manager has the primary responsibility for managing the hundreds of tasks and roles that need to be carefully coordinated. Project
management has evolved into an actual profession with many training options and professional
certification (e.g., project management professional [PMP]) available through the Project
Management Institute (www.pmi.org). Dozens of software products are available to support
project management activities.
Although training and software are available to help project managers, unreasonable demands
set by project sponsors and business managers can make project management exceedingly difficult. Too often, the approach of the holiday season, the chance at winning a proposal with a low
bid, or a funding opportunity pressures project managers to promise systems long before they are
1
Tucci, Linda, “PPM Strategy a CIO’s Must-­Have in Hard Times,” SearchCIO.com, March 5, 2008.
2
Ibid.
3
Tucci, Linda, “Project Portfolio Management Takes Flight at Sabre,” SearchCIO.com, November 28, 2007.
A good book on project management is by Robert K. Wysocki, Effective Project Management: Traditional, Adaptive, Extreme,
7th Ed., New York: John Wiley & Sons, 2013. Also, the Project Management Institute (www.pmi.org) and the Information
Systems Special Interest Group of the Project Management Institute (www.pmi-­issig.org) have valuable resources on project
management in information systems.
4
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Project Selection
Concepts in Action 2-­A
39
Project Portfolio Management: An Essential Tool for IT Departments
Information systems are at the core of Sabre Holdings Corporation. The Sabre reservation system is the booking system of
choice for travel agencies worldwide. Sabre is also the parent
company of Travelocity.com, the second largest online travel
agency in the United States.
Like many companies, Sabre’s IT department struggles
with many more project requests than it has resources to
accomplish—­as many as 1,500 proposals for 600 funded projects annually. Because of the volatile, competitive nature of
the travel industry, Sabre is especially challenged to be certain
that IT is doing the right projects under constantly changing
conditions. While traditional project management techniques
focus on getting individual projects done, Sabre needs to be
able to rapidly change the entire set of projects it is working on
as market conditions shift.
Project portfolio management software collects and manages information about all projects—­those that are underway
and those that are awaiting approval. The software helps prioritize projects, allocate employees, monitor projects in real time,
flag cost and time variances, measure the ROI, and help the IT
department objectively measure the efficiency and efficacy of
IT investments.
Primavera Systems’ PPM software has enabled Sabre Holdings to update its queue of projects regularly, and projects are
now prioritized quarterly instead of annually. A study of users
of Hewlett Packard’s PPM Center software found that in all
cases, the investment in the software paid for itself in a year.
Other findings were an average 30% increase in on-­time projects, a 12% reduction in budget variance, and a 30% reduction
in the amount of time IT spent on project reporting.
Sources: Tucci, Linda, “Project portfolio management takes flight at
Sabre,” SearchCIO.com, November 28, 2007.
Tucci, Linda, “PPM strategy a CIO’s must-­have in hard times,”
SearchCIO.com, March 5, 2008.
realistically able to deliver them. These overly optimistic timetables are thought to be one of the
biggest problems that projects face; instead of pushing a project forward faster, they result in delays.
Thus, a critical success factor for project management is to start with a realistic assessment of
the work that needs to be accomplished and then manage the project according to the plan. This
can be accomplished by carefully following the basic steps of project management. This textbook does not focus on the details of project management. If you are interested in that topic, we
encourage you to seek out a project management course.
We focus instead on project management issues that matter to a systems analyst. First, the
system development methodology that fits the characteristics of the project is selected. Staffing
needs are determined, and the project coordination methods are established. Finally, the project
risks are monitored and managed as the project proceeds.
Project Selection
Many IT organizations tackle several important initiatives simultaneously. For example, new
software applications may be under development; new business models may be under
consideration; organizational structures may be revised; new technical infrastructures may be
evaluated. Collectively, these endeavors are managed as a program by the IT steering committee.
The steering committee must provide oversight and governance to the entire set of projects that
are undertaken by the IT organization. The individual projects that are accepted by the steering
committee are temporary endeavors undertaken to create a unique product or service.
Investments in information systems projects today are evaluated in the context of an entire
portfolio of projects. Decision makers look beyond project cost and consider a project’s anticipated risks and returns in relation to other projects. Companies prioritize their business strategies
and then assemble and assess project portfolios based on how they meet those strategic needs.
The focus on a project’s contribution to an entire portfolio of projects reinforces the need for
the feasibility study as described in Chapter 1. The approval committee has the responsibility
Get Complete eBook Download by Email at discountsmtb@hotmail.com
40
Project Selection and Management
to evaluate not only the project’s costs and expected benefits, but also the technical and organizational risks associated with the project. The feasibility analysis is submitted back to the
approval committee, along with an updated system request. Using this information, the approval
committee can examine the business need (found in the system request) and the project risks
(described in the feasibility analysis).
Portfolio management takes into consideration the different kinds of projects that exist in an
organization—­large and small, high risk and low risk, strategic and tactical. (See Figure 2-­1 for
different ways of classifying projects.) A good project portfolio will have the most appropriate
mix of projects for the organization’s needs. The committee acts as a portfolio manager, with the
goal of maximizing benefits versus costs and balancing other important factors of the portfolio.
For example, an organization may want to keep high-­risk projects to a level less than 20% of its
total project portfolio.
The approval committee must be selective about where to allocate resources because the
organization has limited funds. This involves trade-­offs in which the organization must give up
something in return for something else to keep its portfolio well balanced. If there are three
potentially high-­payoff projects, yet all have extremely high risk, then maybe only one of the
projects will be selected. Also, there are times when a system at the project level makes good
business sense, but it does not at the organization level. Thus, a project may show a strong
economic feasibility and support important business needs for a part of the company; however, it
is not selected. This could happen for many reasons—­because there is no money in the budget for
another system, the organization is about to go through change (e.g., a merger or the implementation of a company-­wide system such as ERP), projects that meet the same business requirements
already are underway, or the system does not align well with current or future corporate strategy.
Applying the Concepts at DrōnTeq
The IS project steering committee met and reviewed the Client Services project along with two
other projects—­one that called for a new supply-­chain portal and another that involved the
enhancement of DrōnTeq’s data warehouse. Unfortunately, the budget would allow for only one
project to be approved, so the committee carefully examined the costs, expected benefits, risks,
and strategic alignment of all three projects. Currently, top executives are anxious to bring the
client service capability to market to expand drone and data analysis usage to new customers and
to provide more value to existing and potential drone pilots. The Client Services project is an
essential element of that goal. Therefore, the committee decided to immediately initiate the
Client Services project.
FIGURE 2-­1 Ways
to classify projects.
Size
What is the size? How many people are needed to work on the project?
Cost
How much will the project cost the organization?
Purpose
What is the purpose of the project? Is it meant to improve the technical infrastructure? Support a current business strategy? Improve operations? Demonstrate a new
innovation?
Length
How long will the project take before completion? How much time will go by before
value is delivered to the business?
Risk
How likely is it that the project will succeed or fail?
Scope
How much of the organization is affected by the system? A department? A division?
The entire corporation?
Economic Value
How much money does the organization expect to receive in return for the amount
the project costs?
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Creating the Project Plan
YOUR TURN 2-­1
41
To Select or Not to Select
It seems hard to believe that an approval committee would
not select a project that meets real business needs, has a high
potential ROI, and has a positive feasibility analysis. Think of
Concepts in Action 2-­B
Interview with Lyn McDermid, CIO, Dominion Virginia Power
A CIO needs to have a global view when identifying and selecting projects for her organization. I would get lost in the
trees if I were to manage on a project-­by-­project basis. Given
this, I categorize my projects according to my three roles as a
CIO, and the mix of my project portfolio changes depending on
the current business environment.
My primary role is to keep the business running. That
means every day when each person comes to work, they can
perform his or her job efficiently. I measure this using various service levels, cost, and productivity measures. Projects
that keep the business running could have a high priority if the
business were in the middle of a merger, or a low priority if
things were running smoothly, and it were “business as usual.”
Concepts in Action 2-­C
a company that you have worked for or know about. Describe a
scenario in which a project may be very attractive at the project
level, but not at the organization level.
My second role is to push innovation that creates value
for the business. I manage this by looking at our lines of
business and asking which lines of business create the most
value for the company. These are the areas for which I should
be providing the most value. For example, if we had a highly
innovative marketing strategy, I would push for innovation
there. If operations were running smoothly, I would push less
for innovation in that area.
My third role is strategic, to look beyond today and find
new opportunities for both IT and the business of providing
energy. This may include investigating process systems, such
as automated meter reading or looking into the possibilities of
wireless technologies. Interview with Carl Wilson, CIO, Marriott Corporation
At Marriott, we do not have IT projects—­we have business initiatives and strategies that are enabled by IT. As a result, the
only time a traditional “IT project” occurs is when we have an
infrastructure upgrade that will lower costs or leverage better
functioning technology. In this case, IT has to make a business
case for the upgrade and prove its value to the company.
The way IT is involved in business projects in the organization is twofold. First, senior IT positions are filled by people
with good business understanding. Second, these people are
placed on key business committees and forums where the
real business happens, such as finding ways to satisfy guests.
Because IT has a seat at the table, we are able to spot opportunities to support business strategy. We look for ways in which
IT can enable or better support business initiatives as they arise.
Therefore, business projects are proposed, and IT is one
component of them. These projects are then evaluated the same
as any other business proposal, such as a new resort—­by examining the return on investment and other financial measures.
At the organizational level, I think of projects as must-­do’s,
should-­do’s, and nice-­to-­do’s. The “must-­do’s” are required to
achieve core business strategy, such as guest preference. The
“should-­do’s” help grow the business and enhance the functionality of the enterprise. These can be somewhat untested,
but good drivers of growth. The “nice-­to-­do’s” are more experimental and look further out into the future.
The organization’s project portfolio should have a mix of all
three kinds of projects, with a much greater proportion devoted
to the “must-­do’s.” Creating the Project Plan
Projects are launched after being selected by the approval committee. The project manager then
follows a set of project management guidelines, sometimes referred to as the project management
life cycle, as he or she organizes, guides, and directs the project from inception to completion.
The project management phases consist of initiation, planning, execution, control, and closure.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
42
Project Selection and Management
The project manager must make myriad decisions regarding the project, including determining the best project methodology, determining a staffing plan, and establishing mechanisms
to coordinate and control the project. Here, we discuss these issues from the perspective of systems analysts who will be part of the project.
Project Methodology Options
As we discussed in Chapter 1, the SDLC provides the foundation for the processes used to
develop an information system. A methodology is a formalized approach to implementing the
SDLC (i.e., it is a list of tasks, steps, and deliverables). There are many different systems
development methodologies, and they vary in terms of the progression that is followed through
the phases of the SDLC. Many organizations have their own in-­house developed methodologies
that explain exactly how each phase of the SDLC is to be performed in that company. In other
cases, methodologies are obtained from consulting firms for their clients to follow; provided by
the vendor of the software to be installed; or mandated as a part of projects involving government
agencies. Before reviewing several of the predominant methodologies that have evolved over
time, we provide a list of project characteristics that will affect the methodology selection decision.
• Clarity of User Requirements How well do the users and analysts understand the functions
and capabilities needed from the new system?
• Familiarity with Technology How much experience does the project team have with the
technology that will be used?
• System Complexity How much complexity is anticipated in the new system? Does the new
system include a wide array of features? Will the system have to integrate with many existing
systems? Does it span multiple organizational units, or even multiple organizations?
• System Reliability Will this system need to be highly reliable or is some downtime tolerable?
• Short Time Schedules Is the project time frame tight?
• Schedule Visibility Are the project sponsors, users, or organizational managers anxious to
see progress?
Keep these factors in mind as you study the methodologies described here.
Waterfall Development
With waterfall development methodologies, the project team proceeds sequentially from one
phase to the next (Figure 2-­2). The key deliverables for each phase are typically voluminous
(often, hundreds of pages) and are presented to the approval committee and project sponsor for
approval as the project moves from phase to phase. Once the work produced in one phase is
approved, the phase ends and the next phase begins. As the project progresses from phase to
phase, it moves forward in the same manner as a waterfall. While it is possible to go backward
through the phases (e.g., from design back to analysis), it is quite difficult. (Imagine yourself as
a salmon trying to swim upstream in a waterfall.)
Waterfall development methodologies have several advantages: requirements are identified
long before programming begins, and requirement changes are limited as the project progresses.
The key disadvantages are that the design must be completely specified before programming
begins, significant time elapses between the completion of the system proposal in the analysis
phase and the delivery of system, and testing may be treated almost as an afterthought in the
implementation phase. In addition, the deliverables are often a poor communication mechanism,
so important requirements may be overlooked in the volumes of documentation. If the project
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Creating the Project Plan
43
Planning
Analysis
Design
Implementation
System
team misses an important requirement, expensive post-­implementation programming may be
needed. Users may forget the original purpose of the system, since so much time has elapsed
between the original idea and actual implementation. Also, in today’s dynamic business environment, a system that met the existing environmental conditions during the analysis phase may
need considerable rework to match the environment when it is implemented. This rework requires
going back to the initial phase and making needed changes through each of the subsequent
phases in turn.
There are several important variants of waterfall development. The parallel development
methodologies evolved to address the lengthy time frame of waterfall development. As shown in
Figure 2-­3, after the analysis phase, a general design for the whole system is created. Then the
project is divided into a series of subprojects that can be designed and implemented in parallel.
Once all subprojects are complete, there is a final integration of the separate pieces, and the
system is delivered.
Parallel development reduces the time required to deliver a system, so changes in the business
environment are less likely to produce the need for rework. The approach still suffers from problems caused by voluminous deliverables. It also adds a new problem: if the subprojects are not
completely independent, design decisions in one subproject may affect another, and at the end of
the project, integrating the subprojects may be quite challenging.
The V-­model is another variation of waterfall development that pays more explicit attention
to testing. As shown in Figure 2-­4, the development process proceeds down the left-­hand slope of
the V, defining requirements and designing system components. At the base of the V, the code is
written. On the upward-­sloping right side of the model, testing of components, integration testing, and, finally, acceptance testing are performed. A key concept of this model is that as requirements are specified and components designed, testing for those elements is also defined. In this
manner, each level of testing is clearly linked to a part of the analysis or design phase, helping to
ensure high quality and relevant testing and maximize test effectiveness.
The V-­model is simple and straightforward and improves the overall quality of systems
through its emphasis on early development of test plans. Projects benefit from an earlier focus
on testing, plus the quality assurance personnel’s expertise increases the overall quality of the
system design. It still suffers from the rigidity of the waterfall development process, however, and
is not always appropriate for the dynamic nature of the business environment.
FIGURE 2-­2 Waterfall development.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
44
Project Selection and Management
Planning
Analysis
Design
Design
Implementation
Subproject 1
Design
Subproject 2
Implementation
Design
Implementation
Implementation
Subproject 3
System
FIGURE 2-­3
Parallel development.
Acceptance
test design
Analysis
Acceptance
testing
System
test design
Design
Integration
test design
Unit
test design
Implementation
(coding)
FIGURE 2-­4
V-­Model.
System
testing
Integration
testing
Unit
testing
Get Complete eBook Download by Email at discountsmtb@hotmail.com
45
Creating the Project Plan
Rapid Application Development (RAD)5
Rapid application development (RAD) is a collection of methodologies that emerged in
response to the weaknesses of waterfall development and its variations. RAD incorporates special techniques and computer tools to speed up the analysis, design, and implementation phases
in order to get some portion of the system developed quickly and into the hands of the users for
evaluation and feedback. Computer-­aided software engineering (CASE) tools, joint application development (JAD) sessions, fourth generation/visual programming languages (e.g., Visual
Basic.NET), and code generators may all play a role in RAD. While RAD can improve the speed
and quality of systems development, it may also introduce a problem in managing user expectations. As systems are developed more quickly and users gain a better understanding of information
technology, user expectations may dramatically increase, and system requirements may expand
during the project (sometimes known as scope creep or feature creep).
RAD may be conducted in a variety of ways. Iterative development breaks the overall project
into a series of versions that are developed sequentially. The most important and fundamental
requirements are bundled into the first version of the system. This version is developed quickly
by a mini-­waterfall process, and once implemented, the users can provide valuable feedback to
be incorporated into the next version of the system (Figure 2-­5). Iterative development gets a
Analysis
Planning
Design
Analysis
Implementation
Analysis
Design
System
version 1
Implementation
Analysis
Design
System
version 2
Implementation
System
version 3
5
One of the best RAD books is by Steve McConnell, Rapid Development, Redmond, WA: Microsoft Press, 1996.
FIGURE 2-­5 Iterative
development.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
46
Project Selection and Management
preliminary version of the system to the users quickly so that business value is provided. Since
users are working with the system, important additional requirements may be identified and
incorporated into subsequent versions. The chief disadvantage of iterative development is that
users begin to work with a system that is intentionally incomplete. Users must accept that only
the most critical requirements of the system will be available in the early versions and must be
patient with the repeated introduction of new system versions.
System prototyping performs the analysis, design, and implementation phases concurrently
to quickly develop a simplified version of the proposed system and give it to the users for evaluation and feedback (Figure 2-­6). The system prototype is a “quick and dirty” version of the
system and provides minimal features. Following reaction and comments from the users, the
developers reanalyze, redesign, and reimplement a second prototype that corrects deficiencies
and adds more features. This cycle continues until the analysts, users, and sponsors agree that
the prototype provides enough functionality to be installed and used in the organization. System
prototyping very quickly provides a system for users to evaluate and reassures users that progress
is being made. The approach is especially useful when users have difficulty in expressing requirements for the system. A disadvantage, however, is the lack of careful, methodical analysis before
making designs and implementation decisions. System prototypes may have some fundamental
design limitations that are a direct result of an inadequate understanding of the system’s true
requirements early in the project.
Throwaway prototyping6 includes the development of prototypes but uses the prototypes
primarily to explore design alternatives rather than as the actual new system (as in system prototyping). As shown in Figure 2-­7, throwaway prototyping has a thorough analysis phase that is
used to gather requirements and to develop ideas for the system concept. Many of the features
suggested by the users may not be well understood, however, and there may be challenging
technical issues to be solved. Each of these issues is examined by analyzing, designing, and
building a design prototype. A design prototype is not intended to be a working system. It contains only enough details to enable users to understand the issues under consideration.
For example, suppose that users are not completely clear on how an order entry system should
work. The analyst team might build a series of HTML pages to be viewed on a Web browser to
help the users visualize such a system. In this case, a series of mock-­up screens appear to be a
system, but they really do nothing. Or suppose that the project team needs to develop a sophisticated graphics program in Java. The team could write a portion of the program with artificial data
to ensure that they could create a full-­blown program successfully.
Planning
Analysis
Design
System
prototype
Implementation
Implementation
FIGURE 2-­6 System
prototyping.
System
Our description of the throwaway prototyping is a modified version of the Spiral Development Model developed by Barry
Boehm, “A Spiral Model of Software Development and Enhancement,” Computer, May, 1988, 21(5):61–72.
6
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Creating the Project Plan
Planning
Analysis
Design
Analysis
Design
Design
prototype
Implementation
Implementation
System
FIGURE 2-­7 Throwaway prototyping.
A system that is developed by this type of methodology probably requires several design prototypes during the analysis and design phases. Each of the prototypes is used to minimize the risk
associated with the system by confirming that important issues are understood before the real
system is built. Once the issues are resolved, the project moves into design and implementation.
At this point, the design prototypes are thrown away, which is an important difference between
this approach and system prototyping, in which the prototypes evolve into the final system.
Throwaway prototyping balances the benefits of well-­thought-­out analysis and design phases
with the advantages of using prototypes to refine key issues before a system is built. It may take
longer to deliver the final system compared with system prototyping (because the prototypes do
not become the final system), but the approach usually produces more stable and reliable systems.
Agile Development
Agile development7 is a group of programming-­centric methodologies that focus on streamlining the SDLC. Much of the modeling and documentation overhead is eliminated; instead,
face-­to-­face communication is preferred. A project emphasizes simple, iterative application
development in which every iteration is a complete software project, including planning, requirements analysis, design, coding, testing, and documentation (Figure 2-­8). Cycles are kept short
(1–4 weeks), and the development team focuses on adapting to the current business environment.
There are several popular approaches to agile development, including extreme programming
(XP),8 Scrum,9 and dynamic systems development method (DSDM).10 Here, we briefly describe
XP. We expand our discussion of Agile development in Chapter 13.
XP11 emphasizes customer satisfaction and teamwork. Communication, simplicity, feedback,
and courage are core values. Developers communicate with customers and fellow programmers.
Designs are kept simple and clean. Early and frequent testing provides feedback, and developers
can courageously respond to changing requirements and technology. Project teams are kept small.
7
For more information, see www.AgileAlliance.org.
8
For more information, see www.extremeprogramming.org.
9
For more information, see www.scrum.org.
10
For more information, see www.dsdm.com.
11
For more information, see A. Lander, Agile Methodologies, New York: John Wiley & Sons, 2014.
47
Get Complete eBook Download by Email at discountsmtb@hotmail.com
48
Project Selection and Management
Planning
Analysis
Design
System
Implementation
FIGURE 2-­8 Extreme
programming.
An XP project begins with user stories that describe what the system needs to do. Then, programmers code in small, simple modules and test to meet those needs. Users are required to be
available to clear up questions and issues as they arise. Standards are particularly important to
minimize confusion, so XP teams use a common set of names, descriptions, and coding practices.
XP projects deliver results sooner than even the RAD approaches, and they rarely get bogged
down in gathering requirements for the system.
XP works well in projects with highly motivated, cohesive, stable, and experienced teams.
If the project is not small or the teams are not jelled,12 however, then the likelihood of success
for the XP project is reduced. XP requires a great deal of discipline to prevent projects from
becoming unfocused and chaotic. Furthermore, it is recommended only for small groups of
developers (not more than 10), and it is not advised for mission-­critical applications. Since
little analysis and design documentation is produced with XP, there is only code documentation; therefore, maintenance of large systems developed using XP may be impossible. Also,
since mission-­critical business information systems tend to exist for a long time, the utility of
XP as a business information system development methodology is in doubt. Finally, the methodology requires considerable on-­site user involvement, something that is frequently difficult
to obtain.13
Agile Versus Waterfall-­Based Methodologies
Agile development approaches have existed for several decades. Agile development practices
were created in part because of dissatisfaction with the sequential, inflexible structure of waterfall-­
based approaches. Presently, agile development has made inroads into software development
organizations, and studies show an even split between agile and waterfall users.14 Many organizations are experimenting with agile even while continuing to employ more traditional approaches
(see Concepts in Action 2-­E). In fact, suggesting that an organization must be “all agile” or “all
waterfall” is a false choice. Many software developers actively seek to integrate the best elements
of both waterfall and agile into their software development practices. Hybrid agile–waterfall
A “jelled team” is one that has low turnover, a strong sense of identity, a sense of eliteness, a feeling that they jointly own the
product being developed, and enjoyment in working together. For more information regarding jelled teams, see T. DeMarco and
T. Lister, Peopleware: Productive Projects and Teams, New York: Dorsett House, 1987.
12
Many of the observations described here on the utility of XP as a development approach are based on conversations with
Brian Henderson-­Sellers.
13
Jan Stafford, “Agile and Waterfall Neck and Neck as Business Side Fails to Engage.” SearchSoftwareQuality.com,
March 16, 2009.
14
Get Complete eBook Download by Email at discountsmtb@hotmail.com
49
Creating the Project Plan
Concepts in Action 2-­D
Agile Development at Travelers
Travelers Insurance Company of Hartford, Connecticut has
adopted agile development methodologies. The insurance field
can be competitive, and Travelers wanted to have the shortest
“time to implement” in the field. Travelers set up development
teams of six people—­two systems analysts, two representatives from the user group (such as claim services), a project
manager, and a clerical support person. In the agile approach,
the users are physically assigned to the development team for
the project. While at first it might seem that the users are just
sitting around drinking coffee and not doing their regular jobs,
that is not the case. The rapport that is developed within the
team allows for instant communication. The interaction is very
deep and profound. The resulting software product is delivered
quickly—­and, generally, with all the features and nuances that
the users wanted.
Questions
1. Could this be done differently, such as through JAD sessions
or having the users review the program on a weekly basis,
rather than taking the users away from their real jobs to
work on development?
2. What mindset does an analyst need to work on such
an approach?
approaches are evolving. The process of developing information systems is never static. Most IS
departments and system developers recognize that the choice of the “best” development methodology depends on project characteristics, as we discuss in the next section.
Selecting the Appropriate Development Methodology
As the previous section shows, there are many methodologies. The first challenge faced by project managers is to select which methodology to use. Choosing a methodology is not simple,
because no one methodology is always best. (If it were, we would simply use it everywhere!)
Many organizations have standards and policies to guide the choice of methodology. You will
find that organizations may have one “approved” methodology, several methodology options, or
have no formal policies at all. In the following paragraphs, we describe the various methodologies’ strengths and weaknesses using the project characteristics we introduced earlier. Figure 2-­9
provides a concise summary.
Usefulness in
Developing
Systems
Waterfall
Parallel
V-­Model
Iterative
System
Prototyping
Throwaway
Prototyping
Agile
Development
With unclear user
requirements
Poor
Poor
Poor
Good
Excellent
Excellent
Excellent
With unfamiliar
technology
Poor
Poor
Poor
Good
Poor
Excellent
Poor
That are complex
Good
Good
Good
Good
Poor
Excellent
Poor
That are reliable
Good
Good
Excellent
Good
Poor
Excellent
Good
With short time
schedule
Poor
Good
Poor
Excellent
Excellent
Good
Excellent
With schedule visibility
Poor
Poor
Poor
Excellent
Excellent
Good
Good
FIGURE 2-­9 Criteria for selecting a methodology.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
50
Project Selection and Management
Clarity of User Requirements
When it is difficult to state the user requirements clearly, users may need to interact with technology to really understand what a new system can do and how to best apply it to their needs. System
prototyping and throwaway prototyping are most appropriate when user requirements are unclear
because they provide prototypes for users to interact with early in the SDLC. Agile development
is suitable if on-­site user involvement is available.
Familiarity with Technology
When the system will use new, unfamiliar technology, applying the new technology early in the
methodology will improve the chance of success. Without some familiarity with the base technology, design risks increase. Throwaway prototyping is particularly appropriate for situations
with limited familiarity with technology because it explicitly encourages the developers to create
design prototypes for areas with high uncertainty. Iterative development is good as well, because
opportunities are created to investigate the technology in some depth before the design is
complete. While one might think that system prototyping would also be appropriate, it is much
less so because the early prototypes that are built usually only scratch the surface of the new technology. Typically, it is only after several prototypes and several months that the developers discover weaknesses or problems in the new technology.
System Complexity
Complex systems require careful and detailed analysis and design. Throwaway prototyping is
particularly well suited to such detailed analysis and design, but system prototyping is not. The
waterfall methodologies can handle complex systems, but without the ability to get the system
or prototypes into users’ hands early on, some key issues may be overlooked. Although iterative development methodologies enable users to interact with the system early in the process,
we have observed that project teams who follow these methodologies tend to devote less
attention to the analysis of the complete problem domain than they might if they were using
other methodologies.
System Reliability
System reliability is usually an important factor in system development. After all, who wants an
unreliable system? For some applications, reliability is truly critical (e.g., medical equipment,
missile control systems), while for other applications, it is merely important (e.g., games, Internet
video). The V-­model is useful when reliability is important, due to its emphasis on testing. Throwaway prototyping excels when system reliability is a high priority because detailed analysis and
design phases are combined with the ability for the project team to test many different approaches
through design prototypes before completing the design. System prototyping is generally not a
good choice when reliability is critical, due to the lack of careful analysis and design phases that
are essential to dependable systems.
Short Time Schedules
Projects that have short time schedules are well suited for RAD methodologies because those
methodologies are designed to increase the speed of development. Iterative development, system prototyping, and agile methodologies are excellent choices when timelines are short
because they best enable the project team to adjust the functionality in the system on the basis
of a specific delivery date. If the project schedule starts to slip, it can be readjusted by removal
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Creating the Project Plan
YOUR TURN 2-­2
51
Selecting a Methodology
Suppose that you are an analyst for the ABC Company, a large
consulting firm with offices around the world. The company
wants to build a new knowledge management system that can
identify and track the expertise of individual consultants anywhere in the world based on their education and the various consulting projects on which they have worked. Assume that this is
a new idea that has never been attempted in ABC or elsewhere.
Concepts in Action 2-­E
ABC has an international network, but the offices in each country
may use somewhat different hardware and software. ABC
management wants the system up and running within a year.
Question
1. What methodology would you recommend that ABC
Company use? Why?
Where Agile Works and Does Not Work
British Airways (BA) experienced problems in software
development despite a willing and capable development team.
Mike Croucher, brought in as chief software engineer, recommended a move to agile development after studying BA’s
development process. The movement to agile was carefully
conducted, recognizing that agile represents a huge cultural
shift for the developers. BA development team members who
were amenable to and suitable for agile methods were trained
as agile mentors and coaches to help ease the transition.
Converting to agile methods enabled BA to substantially
shorten the time requirements of certain projects. In some
cases, a project that might have taken 9 months following a
traditional methodology was completed in 8 weeks. Only
about 25% of the organization has changed to agile, however.
BA recognized a continuing role for the waterfall methodology in certain areas of the organization and does not intend to
force-­fit agile everywhere. At BA, agile is used when the user
base demands speed, flexibility, and customer-­oriented design.
Agile is ideal when an area requiring small functionality can be
developed and deployed earlier, according to Croucher.
Adapted from: Mondelo, Daniel J. “Where agile development works and
where it doesn’t: A user story.” SearchSoftwareQuality.com. February 24,
2010.
of the functionality from the version or prototype under development. Waterfall-­based methodologies are the worst choice when time is at a premium because they do not allow for easy
schedule changes.
Schedule Visibility
One of the greatest challenges in systems development is knowing whether a project is on schedule. This is particularly true of the waterfall-­based methodologies because design and implementation occur at the end of the project. The RAD methodologies move many of the critical design
decisions to a position earlier in the project to help project managers recognize and address risk
factors and keep expectations in check. Close user involvement in agile methodologies ensures
that progress is well known.
One important item not discussed in Figure 2-­9 is the development team’s degree of experience. Many of the RAD and agile development methodologies require the use of new tools and
techniques that have a significant learning curve. Often, these tools and techniques increase the
complexity of the project and require extra time to learn and apply. Once they are adopted and the
team becomes experienced, the tools and techniques can significantly decrease the time needed
to deliver a final system.
Get Complete eBook Download by Email at discountsmtb@hotmail.com
Get Complete eBook Download link Below for Instant Download:
https://browsegrades.net/documents/286751/ebook-payment-link-forinstant-download-after-payment