Chapter Three

Systems Planning and Selection

This first phase of the systems development life cycle deals with the process of identifying,
selecting, initiating, planning projects and assessing project feasibility.

I. Project Identification and Selection

The first step in systems planning and selection is to identify the need for a system, which can be the
result of:
• Problems in existing system or process
• New feature required in an existing system
• A new idea for which in Information System is required
• A requirement to improve efficiency in the organization
• o Compulsory standards or benchmarks (standards) by an external
organization Ex. Government
• The need to keep up with competitors
During this activity, senior manager, a business group, an IS manager, or a steering committee
identifies and assesses all possible systems development projects that a business unit could
undertake.
Requirements for information systems development can come from three key sources, as
depicted in the figure below.

1. Managers who want to make a system more efficient, less costly to operate, or want to
move a system to a new operating environment.
2. Managers and business units who want to replace or extend an existing system in order
to gain
needed information or to provide a new service to customers.
3. Formal planning groups that want to improve an existing system in order to help the
organization meet its corporate objectives, such as providing between customer services.

The Selection Process may vary in different organizations.

Figure – 1: Three key sources for Information Systems Projects

Project identification and selection consists of three primary activities:

1. Identifying potential development projects

Fundamentals of System Analysis and Design Page 27

 This process may be performed by a key member of top management, or a steering committee
composed of cross section managers, or User departments, or the development group.

Projects identified by top management have a strategic organizational focus, by the steering
committees have a cross functional focus, by the individual departments have a narrow, tactical
focus.

The development group identifies projects based on the ease with existing hardware and systems.
Hence, projects may be identified by both top-down and bottom-up initiatives.

The systems analyst should support these groups, to describe their information needs.

2. Classifying and ranking IS development projects

Done by top managers, a steering committee, business units or the IS development

group. The criteria commonly used to evaluate projects are:
▪ Value chain analysis: Extent to which activities add greatest benefits
▪ Strategic alignment: Extent the projects achieves the long-term goals
▪ Potential benefits: Extent to which the project helps to improve profits,
customer service, etc. and the duration of the benefits
▪ Resource availability: Amount and type of resources required for the project
▪ Project size / duration: Number of individuals and duration to complete
▪ Technical difficulty / risk: Level of technical difficulty to complete.
3. Selecting IS development Projects
The short- and long-term projects most likely to achieve the business objectives are considered.
As business conditions change over time, the relative importance of any single project may change.

Figure – 2: Factors to be considered during the project selection

The factors must be considered when selecting a project are:

▪ Perceived needs of the organization
▪ Existing systems and ongoing projects
▪ Resource availability
▪ Evaluation criteria

Fundamentals of System Analysis and Design Page 28

 ▪ Current business conditions
▪ Perspective of the decision makers
Deliverables and outcomes

The primary deliverable or end product form the project identification and selection phase is a
schedule of specific IS development projects.
These projects may come from both top down and bottom up sources.
The selected project moves into the second activity called Project initiation and planning.

Figure-3: Deliverables from Project Identification and selection phase

II. Project Initiation and Planning

The objective of project initiation and planning is to transform vague system

requirements into a tangible project description.
Proper project initiation and planning can reduce the time consumption of further phases.
Activities performed in this phase could also be completed during the next phase, System
analysis.
A rule of thumb is that 10 – 20 % of the entire effort should be expended in this phase. In
other words, you should not be reluctant to spend considerable time and energy early in the
project’s life in order to fully understand the motivation for the requested system.

General Process of Initiating and Planning Systems development Projects

Project Initiation focuses on activities that will help to organize a team to conduct project
planning.
During initiation, one or more analysts are assigned to work with a customer to establish work
standards and communication procedures.
Project Planning focuses on defining clear, discrete tasks and the work needed to complete
each task.
The objective of the project planning is to produce two documents: a Baseline Project Plan
(BPP) and the Statement of Work (SOW).

Fundamentals of System Analysis and Design Page 29

 Figure-4: Statement of Work – an example

The BPP is an internal document used by the development team but not shared with customers.
The BPP contains all information collected and analyzed during the project initiation and
planning activity.
The BPP reflects the best estimate of the project’s scope, benefits, costs, risks and resource
requirements.
The BPP specifies detailed project activities for the next life cycle phase- Systems analysis
and less detail for subsequent phases.
The SOW is a short document prepared for the customers that describe what the project will
deliver
and outlines all work required to complete the project.
The SOW is a useful communication tool that assures that both system analysts and
customers have a common understanding of the project.

A statement of work is a narrative description of the work to be performed as part of a project.

Common synonyms include scope statement, project definition, project overview and document of
understanding.

An outline for a typical statement of work document is shown above. The document will vary in
different organizations. It may be as small as one to two pages or it may run several pages.
Feasibility Study

Most Information System projects have budgets and deadlines; the analysis of factors for feasibility
forms the business case (analysis of the assumptions like resource availability and potential
problems and system cost and benefits) that justifies the expenditure of the resources on the project.
The feasibility factors are in six categories:

Fundamentals of System Analysis and Design Page 30

 Economic Feasibility
✓ Concerned with assessing the financial benefits and costs associated with the project. To do
this, it is necessary to quantify the monetary value of the costs and benefits of the project.
This is also called a cost-benefit analysis.
✓ Benefits and costs can be tangible or intangible.
✓ Tangibles are items which can be quantified in monetary terms and with certainty. Ex.
equipment costs, staff/personnel costs, materials costs, conversion costs, training costs.
✓ Intangibles are items for which a value cannot be precisely determined, and where the value
may be the result of subjective judgment. Ex. Customer goodwill, employee morale,
operational efficiency
✓ The sum value of all costs identified for the project gives the cost of the system.
✓ The sum value of all the benefits identified for the project gives the benefit of the systems.
✓ These sum of costs and benefits are then used to determine if the project is economically
feasible.
✓ These are then used to determine if the project is economically feasible. There are two methods
for doing this are work sheet method and present value method.

Fundamentals of System Analysis and Design Page 31

Fundamentals of System Analysis and Design Page 32
Fundamentals of System Analysis and Design Page 33
 Operational Feasibility
✓ This process examines whether the new project will attain its desired objectives.
✓ The goal of this study is to understand the degree to which the proposed system will likely
solve the business problems or take advantage of the opportunities specified in the Systems
requirement documents.

Technical Feasibility
✓ The goal of this study is to understand the organization’s ability to construct the proposed
system.
✓ This analysis also includes an assessment of the development group’s understanding of the
possible target hardware, software and operating environments as well as the size, complexity
and the group’s experience with similar systems.

Schedule Feasibility
✓ The process of assessing the degree to which the potential time frame and completion dates
for all major activities within a project meet organizational deadlines and constraints for
affecting change.

Legal and Contractual Feasibility

✓ The process of assessing potential legal and contractual consequence (ramification)
due to the construction of a system.
✓ Considerations may include copyright or nondisclosure violation, labor laws, antitrust
legislation, foreign trade regulations and financial reporting standards as well as current
or pending contractual obligations.
Political Feasibility
✓ The process of evaluating how key stakeholders within the organization view the proposed
system.
Risk Feasibility
✓ The probability of successful implementation using the technology and approach.

Fundamentals of System Analysis and Design Page 34

Fundamentals of System Analysis and Design Page 35
 Building the Baseline Project Plan

All the information collected during project initiation and planning is collected and
organized into a document called the Baseline Project Plan.
Once the BPP is completed, a formal review of the project can be conducted with customers.
BPP contains four major sections
1. Introduction
2. System Description
3. Feasibility assessment
4. Management issues

Introduction section provides a brief overview of the entire document and outlines a
recommended course of action for the project.
✓ It provides an executive summary that specifies the project’s scope, feasibility,
justification, resource requirements and schedules. Additionally, a brief statement of
the problem, the environment in which the system is to be implemented and
constraints that affect the project are provided.
✓ Recommendation provides a summary of important findings from the planning
process and recommendations for subsequent activities.
System Description section provides a list of alternatives system configuration.
✓ It provides a description of the selected configuration and a narrative of input
information, tasks performed and resultant information.
✓ This description is at a very high level, mostly narrative in form. Alternatives may be
stated as simply as this:
a) Web-based online system
b) Mainframe with central database
c) Local area network with decentralized
databases
d) Batch data input with online retrieval
e) Purchasing of a prewritten package

Feasibility Assessment outlines project costs and benefits and technical difficulties. High
level project schedules are specified using PERT and Gantt charts. The greatest amount of
project planning effort is typically expended on feasibility assessment activities.

Fundamentals of System Analysis and Design Page 36

 Management Issues: outlines the concerns that management has about the project.
▪ Team Configuration and Management: Provides a description of the team
member roles and reporting relationships.
▪ Communication plan: Provides a description of the communication procedures to be
followed by management, team members and the customer.
▪ Project standards and procedures: Provides a description of how deliverables will be
evaluated and accepted by the customer.
▪ Other project-specific topics: Provides a description of any other relevant issues
related to the project uncovered during planning.

Fundamentals of System Analysis and Design Page 37

 Reviewing the Baseline Project Plan

Before submitting the BPP to some project approval body, it is to be reviewed by the users,
management and development groups.
The objectives of this review are to assure that the proposed system conforms to organizational
standards and to make sure that all relevant parties understand and agree with the information
contained in the BPP.

Fundamentals of System Analysis and Design Page 38

 A common method for performing this review is called a structured walkthrough, a
peer group review of any product created during the systems development process.
The walkthrough may have specific agenda that highlights what is to be covered and
the expected completion time.
Individuals attending the meeting have specific roles
o Coordinator – plans the meeting and facilitates discussions.
o Presenter – describes the work product to the group.
o User – makes sure that the work product meets the needs of the project’s
customers.
o Secretary – takes notes & records decisions or recommendations made by the
group.
o Standard-bearer – ensures that the work product adheres to organizational
technical standards.
o Maintenance oracle – reviews the work product in terms of future maintenance
activities. The goal is to make the system and its documentation easy to maintain.

In addition to reviewing the BPP, the walkthrough can be used for the following
activities
- System specifications
- Logical and physical designs
- Code or program segments
- Test procedures and results
- Manuals and documentation

The key advantage of using a structured review process is to ensure that formal review
points occur during the project. At each phase of the project, a formal review should
be conducted to make sure that all aspects of the projects are satisfactory accomplished
before assigning additional resources to project.

This conservative approach of reviewing each major activity with continuation contingent on
successful completion of the prior phase is called incremental commitment

Fundamentals of System Analysis and Design Page 39