CHAPTER ONE

FUNDAMENTAL CONCEPT OF SYSTEM ANALYSIS AND DESIGN

OBJECTIVES

After completing this chapter learners will be able to:

 Understand the fundamental systems development life cycle and its four phases.
 Understand several different categories of system development methodologies
 And how to choose among them.
 Familiar with the different skill1s and roles required on the project team.
Introduction

This chapter introduces the systems development life cycle, the fundamental four phase model
(planning, analysis, design, and implementation) that is common to all information system
development projects. It then examines several commonly used system development
methodologies that differ in their focus and approach to each of these phases. The chapter closes
with a discussion of the skills and roles needed within the project team.

The need for safe, secure, and reliable system solutions is heightened by the increasing
dependence on computer systems and technology to provide services and develop products,
administer daily activities, and perform short- and long-term management function. There is also
a need to ensure privacy and security when developing information systems, to establish uniform
privacy and protection practices, and to develop acceptable implementation strategies for these
practices.

Using Systems Development Life Cycle will ensure that systems developed by the Department
meet IT mission objectives; are compliant with the current and planned Information Technology
Architecture (ITA); and are easy to maintain and cost-effective to enhance. Sound life cycle
management practices include planning and evaluation in each phase of the information system
life cycle. The appropriate level of planning and evaluation is commensurate with the cost of the
system, the stability and maturity of the technology under consideration, how well defined the
user requirements are, the level of stability of program and user requirements and security
considerations. Systems are created to solve problems. One can think of the systems approach as
an organized way of dealing with a problem. In this dynamic world, the subject System Analysis
and Design mainly deals with the software development activities too.

Defining a System
  A System is collection of components that work together to realize some objective forms
a system. Basically there are three major components in every system, namely input,
processing and output. A system is an interrelated set of business procedures used within
one business unit working together for a purpose.

Information system and organizations

The new business strategy required investments in information systems, and changes in
management and organization. The newly merged company provides value to customers by
competing on both price and quality service.

Information systems are built by managers to serve the interests of the business firm. At the
same time, the organization must be aware of and open to the influences of information systems
to benefit from new technologies. The interaction between information technology and
organizations is complex and is influenced by many mediating factors, including the
organization’s structure, business processes, politics, culture, surrounding environment, and
management decisions. You will need to understand how information systems can change social
and work life in your firm. You will not be able to design new systems successfully or
understand existing systems without understanding your own business organization.

Fig. 1.1. The two way relationship between organization and information system

I.2. Types of information system

I. Transaction processing system (TPS):-those are types of information systems that are used
to record day- to-day business transaction of the organization. They are used by the users at
operational management level.
 Examples of transaction processing system includes:-
 Point of sales system: records daily sales
 Payroll systems: processing employee’s salary, loan management etc.
 Stock control systems; keeping track of inventory levels
 Airline booking system: flight booking system

II. Management information system (MIS): - are used by tactical managers to monitor the organization
current performance status. The output from TPS is used as input to MIS.

Examples:

 Sales Management system: they get input from the point sales system.
 Budgeting system: gives an overview of how much money spent within the organization for
short and long terms:
 Human resource management system: controls the overall welfare of the employees,
turnover etc.

III. Decision support system (DSS): are used by top level management to make none routine decisions.
The main objective of decision support system is to provide solutions for the problems that are
unique and change frequently.

Examples:

 Financial planning systems: it enables manages to evaluate alternative way of achieving

goals, the objective is to find the optimal way of achieving the goal.
 Bank loan management system: it used to verify the credit of the applicant and predict the
likelihood of the loan being recovered.

I.3. The Systems Development Life Cycle

The systems development life cycle (SDLC) is the process of understanding how an information
system (IS) can support business needs, designing the system, building it, and delivering it to
users.
The SDLC has a similar set of four fundamental phases: planning, analysis, design, and
implementation. 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. Each phase
is itself composed of a series of steps, which rely on techniques that produce deliverables
(specific documents and files that provide understanding about the project). For example, when
you apply for admission to a university, there are several phases that all students go through:
information gathering, applying, and accepting. Each of these phases has steps: information
gathering includes steps like searching for schools, requesting information, and reading
brochures. Students then use techniques (e.g., Internet searching) that can be applied to steps
(e.g., requesting information) to create deliverables (e.g., evaluations of different aspects of
universities).

In some projects, phases and steps proceed in a logical path from start to finish, but in many
projects, the project teams move through the steps consecutively, incrementally, iteratively, or in
other patterns. In this section, we describe at a very high level the phases, steps, and some of the
techniques that are used to accomplish the steps. We should emphasize that, in practice, an
organization may follow one of many variations on the overall SDLC. 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. 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 the shape
of the new system. 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 will be built. These deliverables in turn are used in the implementation phase to produce
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 information system
should be built and determining how the project team will go about building it.

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. During this phase, the project team investigates any current
system(s), identifies improvement opportunities, and develops a concept for the new system.

Design

The design phase decides how the system will operate, in terms of the hardware, software, and
network infrastructure; 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 were 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.

Implementation

The final phase in the SDLC is the implementation phase, during which the system is actually
built (or purchased, in the case of a packaged software design). 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.
 systems
planing

operations
systems
and
analysis
support

systems
system
impliment designe
ation

Fig. 1.5 Phases of SDLC

I.4. Systems Development Methodologies

A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and
deliverables). There are many different systems development methodologies and each one is
unique because of its emphasis on processes versus data and the order and focus it places on each
SDLC phase. Some methodologies are formal standards used by government agencies, while
others have been developed by consulting firms to sell to clients. Many organizations have their
own internal methodologies that have been refined over the years, and they explain exactly how
each phase of the SDLC is to be performed in that company. All system development
methodologies lead to a representation of the system concept in terms of processes and data;
however, they vary in terms of whether the methodology places primary emphasis on business
processes or on the data that supports the business.

The open-ended rectangles in the process model diagrams represent data storage containers; the
rounded rectangles represent activities performed; and the arrows represent activity inputs and
outputs.

Process-centered methodologies focus first on defining the activities associated with the system,
i.e., the processes. Process-centered methodologies utilize process models as the core of the
system concept. Analysts concentrate initially on representing the system concept as a set of
processes with information flowing into and out of the processes. Data-centered methodologies
focus first on defining the contents of the data storage containers and how the contents are
organized. Data-centered methodologies utilize data models as the core of the system concept.
For example, analysts concentrate initially on identifying the data that must be available to
produce the payroll and organizing that data into well-defined structures. Object-oriented
methodologies attempt to balance the focus between processes and data. Object-oriented
methodologies utilize the Unified Modeling Language (UML) to describe the system concept as a
collection of objects incorporating both data and processes. Another important factor in
categorizing methodologies is the sequencing of the SDLC phases and the amount of time and
effort devoted to each. In the early days of computing, the need for formal and well-planned life
cycle methodologies was not well understood. Programmers tended to move directly from a very
simple planning phase right into the construction step of the implementation phase; in other
words, they moved directly from a very fuzzy, not-well-thought-out system request into writing
code. This is the same approach that you may sometimes use when writing programs for a
programming class. It can work for small programs that require only one programmer, but if the
requirements are complex or unclear, you may miss important aspects of the problem and have to
start all over again, throwing away part of the program (and the time and effort spent writing it).
This approach also makes teamwork difficult because members have little idea about what needs
to be accomplished and how to work together to produce a final product. In the following
sections, we describe three major categories of systems development methodologies that have
evolved over time: Structured Design, Rapid Application Development (RAD), and Agile
Development. Each category represents a collection of methodologies that attempts to improve
on previous practice, and varies in terms of the progression through the SDLC phases and the
emphasis placed on each phase

Structured Design

The first category of systems development methodologies is called structured design. These
methodologies became dominant in the 1980s, replacing the previous ad-hoc and undisciplined
approach. Structured design methodologies adopt a formal step-by-step approach to the SDLC
that moves logically from one phase to the next. Structured design also introduced the use of
formal modeling or diagramming techniques to describe a system’s basic business processes and
the data that support them. Traditional structured design uses one set of diagrams to represent the
processes (process models) and a separate set of diagrams to represent data (data models).
Because two sets of models are used, the systems analyst must decide which set to develop first
and use as the core of the system—process models or data models. Since each type of model is
important to the system, there is much debate over whether to emphasize processes before data
or vice versa. Numerous processes centered and data-centered methodologies follow the basic
approach of the two structured design categories outlined next.

Waterfall Development The original structured design methodology (that is still used today) is
waterfall development. With waterfall development-based methodologies, the analysts and users
proceed sequentially from one phase to the next. The key deliverables for each phase are
typically voluminous (often hundreds of pages in length) and are presented to the project sponsor
for approval as the project moves from phase to phase. Once the sponsor approves the work that
was conducted for a phase, the phase ends and the next one begins. This methodology is called
waterfall development because it moves forward from phase to phase in the same manner as a
waterfall. Although it is possible to go backward in the SDLC (e.g., from design back to
analysis), it is extremely difficult (imagine yourself as a salmon trying to swim upstream in a
waterfall). The two key advantages of waterfall development-based methodologies are that
system requirements are identified long before programming begins and that changes to the
requirements are minimized as the project proceeds. The two key disadvantages are that the
design must be completely specified before programming begins and that a long time elapses
between the completion of the system proposal in the analysis phase and the delivery of the
system (usually many months or years). The deliverables are often a poor communication
mechanism, so important requirements can be overlooked in the documentation. Users rarely are
prepared for their introduction to the new system, which occurs long after the initial idea for the
system was introduced. If the project team misses important requirements, expensive post-
implementation programming may be needed (imagine yourself trying to design a car on paper;
how likely would you be to remember to include interior lights that come on when the doors
open or to specify the right number of valves on the engine?). Today’s dynamic business world
often imposes rapid environmental change on businesses. A system that meets 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.

Fig. 1.6 waterfall development

Parallel Development The parallel development-based methodologies attempt to address the
long time interval between the analysis phase and the delivery of the system. Instead of doing the
design and implementation in sequence, a general design for the whole system is performed, and
then the project is divided into a series of distinct sub projects 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. The primary advantage of these methodologies is
that the schedule time required to deliver a system is shortened; thus, there is less chance of
changes in the business environment causing rework. The approach still suffers from problems
caused by lengthy deliverables. It also adds a new problem: sometimes the subprojects are not
completely independent; design decisions made in one subproject may affect another, and the
end of the project may involve significant integration challenges.

Fig. 1.7 parallel development methodologies

Rapid Application Development (RAD)

The second system development methodology category includes rapid application development
(RAD)-based methodologies. These are a newer class of system development methodologies that
emerged in the 1990s in response to both structured design methodology weaknesses. RAD-
based methodologies adjust the SDLC phases to get some part of the system developed quickly
and into the hands of the users. In this way, the users can better understand the system and
suggest revisions that bring the system close to what is needed. There are process-centered, data
centered, and object-oriented methodologies that follow the basic approaches of the three RAD
categories described in this section. Most RAD-based methodologies recommend that analysts
use special techniques and computer tools to speed up the analysis, design, and implementation
phases, such as CASE (computer-aided software engineering) tools JAD (joint application
design) sessions, fourth-generation/visual programming languages that simplify and speed up
programming and code generators that automatically produce programs from design
specifications. It is the combination of the changed SDLC phases and the use of these tools and
techniques that improves the speed and quality of systems development. One possible subtle
problem with RAD-based methodologies, however, is managing user expectations. As systems
are developed more rapidly and users gain a better understanding of information technology, user
expectations may dramatically increase and system requirements expand during the project. This
was less of a problem with structured design methodologies where the system requirements, once
determined, were allowed only minimal change.

Phased Development:-The phased development-based methodologies break the overall system

into a series of versions that are developed sequentially. The analysis phase identifies the overall
system concept, and the project team, users, and system sponsor then categorize the requirements
into a series of versions. The most important and fundamental requirements are bundled into the
first version of the system. The analysis phase then leads into design and implementation, but
only with the set of requirements identified for version 1.
 A
P D
A Imp
A S
D
Imp
A S
D
Imp
S

Figure 1.8 the phased development methodology.

Once version 1 is implemented, work begins on version 2. Additional analysis is performed on

the basis of the previously identified requirements and combined with new ideas and issues that
arose from users’ experience with version 1. Version 2 then is designed and implemented, and
work immediately begins on the next version. This process continues until the system is
complete or is no longer in use. Phased development-based methodologies have the advantage of
quickly getting a useful system into the hands of the users. Although it does not perform all the
functions the users need at first, it begins to provide business value sooner than if the system
were delivered only after all requirements are completed, as is the case with the waterfall or
parallel methodologies. Likewise, because users begin to work with the system sooner, they are
more likely to identify important additional requirements sooner than with structured design
situations. The major drawback to phased development is that users begin to work with systems
that are intentionally incomplete. It is critical to identify the most important and useful features
and include them in the first version while managing users’ expectations along the way.

Prototyping:-The prototyping-based methodologies perform the analysis, design, and

implementation phases concurrently, and all three phases are performed repeatedly in a cycle
until the system is completed. With these methodologies, a basic analysis and design are
performed, and work immediately begins on a system prototype, a “quick-and-dirty” program
that provides a minimal amount of features. The first prototype is usually the first part of the
system that the user will use. This is shown to the users and the project sponsor, who provide
reaction and comments. This feedback is used to reanalyze, redesign, and reemployment a
second prototype that provides a few more features. This process continues in a cycle until the
analysts, users, and sponsor agree that the prototype provides enough functionality to be installed
and used in the organization. After the prototype (now called the “system”) is installed,
refinement occurs until it is accepted as the new system. The key advantage of a prototyping-
based methodology is that it very quickly provides a system for the users to interact with, even if
it is not initially ready for widespread organizational use. Prototyping reassures the users that the
project team is working on the system (there are no long time intervals in which the users
perceive little progress), and the approach helps to more quickly refine real requirements. Rather
than attempting to understand system specification materials, the users can interact with the
prototype to better understand what it can and cannot do. The major problem with prototyping is
that its fast-paced system releases challenge attempts to conduct careful, methodical analysis.
Often the prototype undergoes such significant changes that many initial design decisions prove
to be poor ones. This can cause problems in the development of complex systems because
fundamental issues and problems are not recognized until well into the development process.
Imagine building a car and discovering late in the prototyping process that you have to take the
whole engine out to change the oil (because no one thought about the need to change the oil until
after the car had been driven 10,000 miles).
 Fig. 1.8 Prototyping

Throwaway Prototyping:- Throwaway prototyping-based methodologies are similar to the

prototyping-based methodologies in that they include the development of prototypes; however,
throwaway prototypes are done at a different point in the SDLC. These prototypes are used for a
very different purpose than ones previously discussed, and they have a very different appearance.
The throwaway prototyping-based methodologies have a relatively thorough analysis phase that
is used to gather information 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 a working system; it is a product that
represents a part of the system that needs additional refinement, and it contains only enough
detail to enable users to understand the issues under consideration. For example, suppose users
are not completely clear on how an order entry system should work. The analyst team might
build a series of HTML pages viewed using 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.
A system that is developed using this type of methodology probably uses 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 prototyping, in which the prototypes evolve into the final
system.

Throwaway prototyping-based methodologies balance the benefits of well thought 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 as compared with prototyping-based
methodologies (because the prototypes do not become the final system), but the approach usually
produces more stable and reliable systems.

Fig. 1.9 throwaway prototyping

 I.5. Selecting the Appropriate Development Methodology
Since there are many methodologies, the first challenge faced by analysts is to select which
methodology to use. Choosing a methodology is not simple, because no one methodology is
always best (if it were, we’d simply use it everywhere!). Many organizations have standards and
policies to guide the choice of methodology. You will find that organizations range from having
one “approved” methodology to having several methodology options to having no formal
policies at all. One important item not discussed in this figure is the degree of experience of the
analyst team. Many of the RAD 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 for learning. Once they are adopted and the team becomes
experienced, the tools and techniques can significantly increase the speed in which the
methodology can deliver a final system.

 Clarity of User Requirements:-When the user requirements for what the system should
do are unclear, it is difficult to understand them by talking about them and explaining
them with written reports. Users normally need to interact with technology to really
understand what the new system can do and how to best apply it to their needs. The RAD
methodologies of prototyping and throwaway prototyping are usually more appropriate
when user requirements are unclear because they provide prototypes for users to interact
with early in the SDLC.
 Familiarity with Technology: When the system will use new technology with which the
analysts and programmers are not familiar (e.g., the first Web development project with
Java), applying the new technology early in the methodology will improve the chance of
success. If the system is designed without some familiarity with the base technology,
risks increase because the tools may not be capable of doing what is needed. Throwaway
prototyping-based methodologies are particularly appropriate for a lack of familiarity
with technology because they explicitly encourage the developers to create design
prototypes for areas with high risks. Phased development-based methodologies are good
as well because they create opportunities to investigate the technology in some depth
before the design is complete. While one might think prototyping-based methodologies
would also be appropriate, they are much less so, because the early prototypes that are
built usually only scratch the surface of the new technology. Usually, 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-based methodologies are particularly well suited to such detailed
analysis and design, but prototyping-based methodologies are not. The traditional
structured design-based 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 the phased development based 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? However, reliability is just one
factor among several. 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). Throwaway prototyping-based methodologies are most
appropriate when system reliability is a high priority, because they combine detailed
analysis and design phases with the ability for the project team to test many different
approaches through design prototypes before completing the design. Prototyping-based
methodologies are generally not a good choice when reliability is critical because they
lack the careful analysis and design phases that are essential for dependable systems.
 Short Time Schedules: - Projects that have short time schedules are well suited for
RAD-based methodologies because those methodologies are designed to increase the
speed of development. Prototyping and phased development-based 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 removing 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 knows
whether a project is on schedule. This is particularly true of the structured design
methodologies because design and implementation occur at the end of the project. The
RAD-based methodologies move many of the critical design decisions earlier in the
project to help project managers recognize and address risk factors and keep expectations
in check

I.6. Project Team Skills and Roles

As it is clear from the various phases and steps performed during the SDLC, the project team
needs a variety of skills. Project members are change agents who identify ways to improve an
organization, build an information system to support them, and train and motivate others to use
the system. Leading a successful organizational change effort is one of the most difficult jobs
that someone can do. Understanding what to change, how to change it and convincing others, of
the need for change requires 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 situations and to ensure that the 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) and with
programmers (who often have more technical expertise than the analyst). They must be able to
give presentations to large and small groups and write reports. Not only do they need to have
strong interpersonal abilities, but also they 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 to maintain confidence
and trust with all people. In addition to these six general skill sets, analysts require many specific
skills that are associated with roles that are performed on a project. In the early days of systems
development, most organizations expected one person, the analyst, to have all of the specific
skills needed to conduct a systems development project. Some small organizations still expect
one person to perform many roles, but because organizations and technology have become more
complex, most large organizations now build project teams that contain several individuals with
clearly defined responsibilities. Different organizations divide the roles differently. Most IS
teams include many other individuals such as the programmers who actually write the system’s
programs, network engineers, who focus on the design of the network, database administrators,
who deal with optimizing the physical design of the database, and technical writers, who prepare
user and system documentation.

Business Analyst

The business analyst focuses on the business issues surrounding the system. These include
identifying the business value that the system will create, developing ideas and suggestions for
how the business processes can be improved, and designing the new processes and policies in
conjunction with the systems analyst. This individual will likely have business experience and
some type of professional training (e.g., the business analyst for accounting systems will likely
be a CPA [certified public accountant in the United States] or a CA [chartered accountant in
Great Britain and Canada]). He or she represents the interests of the project sponsor and the
ultimate users of the system. The business analyst assists in the planning and design phases but is
most active in the analysis phase.

Systems Analyst

The systems analyst focuses on the IS issues surrounding the system. This person develops ideas
and suggestions for how IT can improve business processes, designs the new business processes
with help from the business analyst, designs the new information system, and ensures that all IS
standards are maintained. The systems analyst likely will have significant training and
experience in analysis and design, programming, and even areas of the business. He or she
represents the interests of the IS department and works intensively throughout the project but
perhaps less so during the implementation phase.

Infrastructure Analyst

The infrastructure analyst focuses on the technical issues surrounding how the system will
interact with the organization’s technical infrastructure (e.g., hard ware, soft ware, networks, and
databases). The infrastructure analyst’s tasks include ensuring that the new information system
conforms to organizational standards and identifying infrastructure changes needed to support
the system. This individual will likely have significant training and experience in networking,
database administration, and various hardware and software products. He or she represents the
interests of the organization and IS group that ultimately will have to operate and support the
new system once it has been installed. The infrastructure analyst works throughout the project
but perhaps less so during planning and analysis phases.

Change Management Analyst

The change management analyst focuses on the people and management issues surrounding the
system installation. The roles of this person include ensuring that adequate documentation and
support are available to users, providing user training on the new system, and developing
strategies to overcome resistance to change. This individual likely will have significant training
and experience in organizational behavior in general and change management in particular. He or
she represents the interests of the project sponsor and users for whom the system is being
designed. The change management analyst works most actively during the implementation phase
but begins laying the groundwork for change during the analysis and design phases.

Project Manager

The project manager is responsible for ensuring that the project is completed on time and within
budget and that the system delivers all benefits that were intended by the project sponsor. The
role of the project manager includes managing the team members, developing the project plan,
assigning resources, and being the primary point of contact when people outside the team have
questions about the project. This individual likely will have significant experience in project
management and likely has worked for many years as a systems analyst beforehand. He or she
represents the interests of the IS department and the project sponsor. The project manager works
intensely during all phases of the project.
 CHAPTER TWO

SYSTEMS PLANNING AND PROJECT SELECTION

At the end of this chapter, you are expected to:

 Understand the importance of linking the information system to business objectives

 Be able to create a system request
 Understand how to assess technical, economic and organizational feasibility
 Be able to perform a feasibility analysis

2.1. Introduction
The first step in the development of project is for someone –a manager, staff member, sales
representatives, or system analysts-to see an opportunity to improve the business. New systems
usually originate from some business need or opportunity. Many ideas for new system or
improvement to existing one arise from the application of new technology but understanding of
technology is usually secondary to a solid understanding of the business and its objectives.

Project initiation begins when someone or some group in the organization called the project
sponsor identifies the business value that can be gained from using IT. The proposed project is
described very briefly using a technique called the system request which is submitted to
approving committee for consideration. This approval committee could be IS Steering committee
of senior executives that meets regularly to make IS decision.

The feasibility analysis plays an important role in deciding whether to proceed with IS
development project or not. One the feasibility analysis has been completed; the system request
is revised and submitted, along with the final feasibility study, back to approval committee. The
board then decides whether to approve the project, decline the project or table it until additional
information is available.

2.2. Identifying Business Value

All systems have to address needs or they likely fail; therefore, most organizations have a
process for insuring that business value has been identified before a development project can
begin. Every organization has its own way of initiating a system but most start with a technique
called systems request. A systems request documents the business reason for building the system
and the value that the system is expected to provide. When the project is initiated, business users
complete this form as part of the formal system approval process within the organization.

Systems Request

Most systems request include four elements: project sponsor, business need, functionality and
expected value. The project sponsor is the person who has an interest in seeing the system
succeed, someone who will work through the SDLC to make sure that the project is moving in
the right direction from the perspective of the business. Usually this is the person who initiated
the proposed project and who will serve as the primary point of contact for the system on the
business side.

The business needs describes why the information system should be built and explain to the
approval committee why the organization should fund the project. It should be clear and concise
but at this point it is not likely to be completely defined.

The functionality of the system (what the information system will do) needs to be explained at a
high level so that the approval committee and ultimately the project team understand what the
project team expects from the final product.

Functionality indicates what features and capabilities the information system will have to
include such as the ability to collect customers, orders over the web.

Expected value to be gained from the system should include both tangible and in tangible values.
Tangible values are values that can be quantified; example 2% reduction in operating costs. An
intangible values are values resulted from an intuitive belief that the system provides important
but hard to measure benefits to the organization. Example improved customer’s service.

Special issues or constraints also are included as a catchall for other information that should be
considered in assessing the project. Once the system request is completed, it will be sent to
approval committee, which could be an information system steering committee that meets
regularly for decision making purpose.

2.3. Feasibility Analysis

Once the need for the system and its functionality have been defined, it is time to create a more
detailed business cases to better understand the opportunities and initiations associated with the
proposed project. Feasibility analysis guides the organization in determining whether to proceed
with a project or not.

At this stage we are discussing the feasibility analysis at the context of project initiation but most
project teams will revise their feasibility study throughout the SDLC and revisit its contents at
various check points during the project. If at any point the projects risk and limitations outweigh
its benefit, the project team may decide to cancel the project or make necessary improvement.

Technical feasibility
The first technique 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 IS
staff. It is in essence a technical risk analysis that strives to answer the question can we build it?
There are many risks that can endanger the successful completion of the project. Most important
is;

 Familiarity with application-less familiarity generates more risk

 Familiarity with technology-less familiarity generates more risk
 Project size- large projects have more risks

Economic feasibility

The second element of feasibility analysis is to perform an economic feasibility analysis (a cost
benefit analysis) that identifies the financial costs and benefits associated with the project. This
analysis tries to attempt questions should we build the system? Economic feasibility is
determined by identifying costs and benefits associated with the system, assigning values to
them, and then calculating the cash flow return on investment for the project.

Organizational feasibility

The final technique used for feasibility analysis is to assess the organizational feasibility of the
system, how well the system ultimately will be accepted by its users, and incorporated in to the
ongoing operations of the organizations. 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 organizational
feasibility is to conduct a stakeholder analysis. A stakeholder is a person, group or organization
that can affect (or will be affected by) a new system. In general the most important stakeholders
in the introduction of a new system are project champion(s), a system user and organizational
management. A champion is a high level non-IS executive who is usually but not always the
project sponsoring who initiates the system request. The champion supports the project by
providing time, resource, (e.g. money), and political support within the organization by
communicating the importance of a system with other organizational decision makers. More than
one champion is preferable because if the champion leaves the organization, the support could
leave as well.
 2.4. Project Management
Project management is the process of planning and controlling the development of a system
within a specified time frame at a minimum cost with the right functionality. The project
manager has primary responsibility for managing the hundreds of tasks and roles that need to be
carefully coordinated. A critical success factor for project management is to start a realistic
assessment that needs to be accomplished and then manage the project according to that
assessment. This can be achieved by carefully following the three steps that are presented as
follows;

1. Creating the work plan: the first step to project management is to create a work plan, a
dynamic schedule that records and keeps track of all of the tasks that need to be
accomplished over the life of the project. The work plan lists each task along with
important information about it such as when it needs to be completed, the person
assigned to do the work, and any deliverables that will result. To create a work plan, you
will need to perform two steps as; identify the tasks that need to be accomplished and
estimate the time that it will take to complete them. If the deadline needs to be shortened
after the work plan is completed, a technique called time boxing can be used to deliver
important parts of the system to its user much faster. Especially when using Rapid
Application Development (RAD), time boxing is quite popular. This technique set a fixed
deadline for a project and delivers the system by that deadline no matter what, even if
functionality needs to be conducted. Time boxing ensures that project teams do not get
hung up on the final finished touches that can drag out indefinitely and it satisfies the
business by providing a product with in a relatively a fast time frame.
2. Staffing the project: staffing is much more than determining how many people should
be assigned to the project. It involves matching people skill with the need of the project,
motivating them to meet the projects objective, and minimizing the conflict that will
occur over time. The deliverable for this part of the project management is a staffing
plan, which describes the kind of people who will work on the project and the overall
reporting structure, and the project charter which describes the projects objectives and
rules. There are many structures for project teams. After roles are defined, and the
structure is in place, the project manager needs to think about which people can fill each
role. Often one person fills more than one role in the project team.
3. Controlling and directing the project: the final step of project management, controlling
and directing the project until the final product is delivered to the project sponsor and
users-will continue throughout the entire process. This step includes a variety of activities
including original project estimates, tracking tasks, encouraging efficient development
practices, managing scope and mitigating risks. All these activities occur over the course
of the entire SDLC, but it is at this point in the project when the project manager needs to
put them in place. Ultimately, these activities ensure that the project stays on track and
that the chance of failure is kept at a minimum.