CHAPTER FOUR

SYSTEMS PLANNING AND

SELECTION

1
Introduction
 The first phase of the systems development life
cycle—systems planning and selection—deals
with:
 Identifying
 selecting,
 initiating, and
 planning projects.
 There are two primary activities in this phase:

general method for identifying and selecting
projects and

project initiation and planning, and present
several techniques for assessing project feasibility.
2
 Identifying and Selecting Projects
 Sources of projects (request)
1. Management and business units: who want to
replace or extend an existing system

2. Info. System Managers who want to make a

system more efficient and less costly.

3. Formal planning groups: want to improve an

existing system in orders to help the organization
meet its corporate objectives,
3
 Identifying and Selecting Projects

 During this activity, a senior manager, a

business group, an IS manager, or a steering
committee identifies and assesses all possible
systems development projects.

 Next, those projects deemed most likely to yield

significant organizational benefits, given available
resources, are selected.

4
The Process of Identifying and Selecting
IS Development Projects

1. Project identification
 Projects are identified by
 Top management
 Steering committee
 User departments

Development group or senior IS staff
 Top-Down Identification
 Senior management or steering committee

Focus is on global/strategic needs of organization

5
 The Process of Identifying and
Selecting IS Development Projects

 Bottom-Up Identification
 Business unit or IS group

Don’t reflect overall goals of the organization

2. Classify and rank development projects

 The criteria used to assign the merit of a given
project are:
 value chain analysis

 Strategic alignment

 Potential benefits
6
 The Process of Identifying and
Selecting IS Development Projects

 Resource availability
 Project size/duration
 Technical difficulty/risk

3. Select development projects

7
The Process of Identifying and
Selecting IS Development Projects

 The decision-making process can lead to

numerous outcomes.
 Accepted:- funding to conduct the next

SDLC activity has been approved.

 Rejected:- the project will no longer be
considered for development.
 Delayed:
 End-user Development:
8
9
 The Process of Identifying and Selecting IS Development
Projects

 Deliverables and outcomes

 Primary deliverable of this phase is a schedule of
specific IS development projects.

 Selected project doesn’t necessarily result in a

working system, due to incremental
commitment
 Incremental commitment
 Continuous reassessment of project after each phase
10
11
Initiating and Planning System Development Projects

 The objective of project initiation and planning is

to transform a vague system request document into
a tangible project description.

 Two activities occur during project initiation and

project planning.
 Project initiation focuses on activities designed to assist
in organizing a team to conduct project planning.

 Project planning is the process of defining clear,

discrete activities and the work needed to complete each
activity within a single project. (BPP)
12
 The process of Initiating and
planning IS Development Projects

 Activities performed during Project

initiation (Elements project Initiation):
 Establishing the Project Initiation Team
 Establishing a Relationship with the Customer
 Establishing the Project Initiation Plan
 Establish Management Procedure
 Generally, Establish the Project Management
Environment and Project Workbook

13
 The process of Initiating and
planning IS Development Projects
 The objective of Project Planning:
 Baseline Project Plan (BPP)

 Internal document

 Statement of Work (SOW)

 Outlines objectives and constraints of the
project to the customer
14
 The process of Initiating and planning IS
Development Projects

 Activity Performed during Project Planning

 Describing the projects scope, Alternative, and
feasibility
 Dividing the project into manageable tasks
 Estimating resources and creating a resource plan
 Developing a preliminary schedule
 Developing a communication plan
 Determining project standards and procedures
 Identifying and assessing risk
 Creating a preliminary budget
 Developing a Statement of work
 Setting a Baseline plan
15
The process of Initiating and planning IS
Development Projects

 Deliverables and Outcomes

 Baseline Project Plan (BPP)

 Scope
 Benefits

 Costs

 Risks

 Resources

 Statement of Work (SOW)

 Describes deliverables
 Outlines work needed to be performed
16
17
Assessing Project Feasibility
 Six Categories
 Economic
 Operational

 Technical

 Schedule

 Legal and contractual

 Political

18
 Assessing Economic Feasibility
 Cost – Benefit Analysis
 Determine Benefits
 Tangible Benefits
 Can be measured easily
 Examples
 Error reduction

 Increased flexibility

 Increased speed of activity

 Increased management planning and control

19
 Assessing Economic Feasibility

 Intangible Benefits
 Cannot be measured easily
 Examples
 Increased employee morale
 More timely information
 Promotion of organizational learning and understanding
 Determine Costs
 Intangible Costs
 Cannot be easily measured in dollars
 Examples:
1. Loss of customer goodwill
2. Loss of employee morale
20
Assessing Economic Feasibility
 Tangible cost
 Can easily be measured in dollars
 Example: Hardware
 It includes one-time (capital) and recurrent
cost
 One-Time Costs
 Associated with project startup, initiation and
development

21
Assessing Economic Feasibility
 One time costs includes
 System Development
 New hardware and software purchases
 User training
 Site preparation
 Data or system conversion
 Recurring Costs

Associated with ongoing use of the system
 Includes:
 Application software maintenance

 Incremental data storage expense

 New software and hardware releases

 Consumable supplies

22
23
 ONE-TIME COST WORKSHEET
Customer Tracking System Project
Year 0
A. Development costs (4*5000) 20,000
B. New hardware (5*3000) 15,000
C. New (purchased) software, if any
1. Packaged application software (5*1000) 5,000
2. Other______________ 0
D. User training (10*250) 2,500
E. Site preparation 0
F. Other_______________________ 0
TOTAL one-time cost 42,500

RUCURRING COSTS WORKSHEET

Customer Tracking System Project
Year 1 through 5
A. Application software maintenance (5*5000) 25,000
B. Incremental data storage required: 20MB x Birr 50. (estimated cost/MB = $50) 1,000
C. Incremental communications (lines, messages, …) 2,000
D. New software or hardware leases 0
Supplies 500
F. Other_______________________ 0
TOTAL recurring costs 28,500.00

24
 Assessing Economic Feasibility

 Commonly used Economic Cost-benefit Analysis

Techniques.
 Net Present Value (NPV): A discount rate is used to
determine the present value of both cash receipts and
outlays.
 Return of Investment (ROI):
 measures the gain or loss generated on an investment relative to
the amount of money invested
 is the ratio of the net cash receipts of the project divided by the cash
outlays the project.
Overall NPV 35,003
  0.24
NPV of all cos ts 145,236
25
Assessing Economic Feasibility
 Break-Even Analysis (BEA): finds the
amount of time required for the cumulative cash
flow from a project to equal its initial and
ongoing investment.
Yearly NPV Cash in Flow  Overall NPV Cash out Flow
Break  Even Ratio 
Yearly NPV Cash in Flow

15,303  9,139
Break  Even Ratio  0.404  2  0.404  2.4
15,303

26
 Assessing Technical Feasibility

 The purpose of assessing technical feasibility is:

 Assessing of the development organization’s ability to
construct a proposed system.
 understanding of the possible target hardware, software,
and operating environments
 All projects have risk and that risk is not necessarily
something to avoid.
 understanding the sources and types of technical risks
proves to be a valuable tool when you assess a project.
27
 Assessing Technical Feasibility

 The amount of technical risk associated with a

given project is contingent on four primary
factors:
1. project size,
2. project structure,
3. The development group’s experience with
the application and technology area, and
4. The user group’s experience with
development projects and application area28
 Assessing Technical Feasibility
 Using these factors for conducting a technical risk
assessment, four general rules emerge:
 Large projects are riskier than small projects.
 A system in which the requirements are easily obtained
and highly structured will be less risky than one in which
requirements are messy, ill-structured or unstructured .
 The development of a system employing commonly used
or standard technology will be less risky than one
employing novel or not standard technology.
 A project is less risky when the user group is familiar with
the systems development process and application area.
29
 Assessing Other Project Feasibility Concerns

 Operational Feasibility
 Assessment of how a proposed system solves
business problems or takes advantage of
opportunities
 Your assessment of operational feasibility should also
include an analysis of how the proposed system will
affect organizational structures and procedures.
 Clear understanding of how an IS will fit into the
current day-to-day operations of the organization. 30
Assessing Other Project Feasibility Concerns

 Schedule Feasibility
 Assessment of timeframe and project completion
dates with respect to organization constraints for
affecting change
 For example, a system may have to be
operational
 by a government imposed deadline,
 by a particular point in the business cycle (such as the
beginning of the season when new products are
introduced),
 by the time a competitor is expected to introduce a
similar system.

31
 Assessing Other Project
Feasibility Concerns
 Legal and Contractual Feasibility
 Assessment of legal and contractual
ramifications/consequence of new system
 Possible legal considerations might include
 copyright or non disclosure
 antitrust legislation (which might limit the reaction of
systems to share data with other organizations),

32
 Assessing Other Project
Feasibility Concerns
 Contractual obligations may involve
 Ownership of software used in joint ventures,
 License agreements for use of hardware or software,

 if your organization has historically used

an outside organization for specific systems
or services that you now are considering
handling yourself, this feasibility is a greater
important.
33
Assessing Other Project
Feasibility Concerns
 Political Feasibility
 Assessment of view of key stakeholders
in organization toward proposed system.
 Since an information system may affect

the distribution of power, the

construction of an IS can have political
ramifications.

34
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.
 This presentation called a walkthrough
 The focus of this review is to verify all
information and assumptions in the baseline plan

35
 Building the Baseline Project Plan
 Four Sections
 Introduction
 System Description
 Feasibility Assessment
 Management Issues
 Introduction
 Brief overview
 Recommended course of action
 Project scope defined
 Units affected

36
 Building the Baseline Project Plan
 Interaction with other systems
 Range of system capabilities
 System Description
 Outline of possible alternative solutions
 The description is at a very high level-narrative format.
 collecting and structuring information in a more detailed and rigorous
manner during the analysis phase
 your objective is only to identify the most obvious alternative
solutions.
 Feasibility Assessment
 Project costs and benefits

37
Building the Baseline Project Plan
 Technical difficulties
 High-level project schedule
 work breakdown for the next one or two life-cycle activities.
 Management Issues
 Outlines concerns that management may have about the project
 Team composition- 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.

38
39
 Reviewing the Baseline Project Plan
 The users, management, and development
group review the Baseline Project Plan, before
the next phase of the SDLC can begin.
 Objectives
 Assure conformity to organizational standards

 All parties agree to continue with project

 A common method for performing this review (as

swell as reviews during subsequent life-cycle
phases) is called a structured walkthrough.

40
Reviewing the Baseline Project Plan
 Walkthrough
 Peer group review of any product created
during the systems development
organizations.
 Participants
 Coordinator
 Presenter

 User

 Secretary

 Standards Bearer

41
 Reviewing the Baseline Project Plan
 Activities
 The coordinator by providing a Walkthrough Review Form can
make sure that a qualified individual is assigned to each
walkthrough role.
 After the presentation completed the coordinator polled each
representative for his or her recommendation concerning the
work product.
 The suggested changes were recorded by the secretary on a
Walkthrough Action List and given to the analyst to
incorporate into a final version of the baseline plan.
 Advantages
 Assures that formal review occurs during project

42
43
44