Preliminary Investigation

1

• Chapter 3
• Preliminary Investigation

2
Learning Objectives

• Identify Selecting System Development Project
  (SDP)
• Initiating Planning System Development Project
  (SDP)
• System Requirement Modeling

3
Identifying and Selecting Systems Development
Projects
4
The Process of Identifying and Selecting IS
Development Projects

• Identifying potential development projects.
• Identification from a stakeholder group.
• Each stakeholder group brings their own
  perspective and motivation to the IS decision.

5
The Process of Identifying and Selecting IS
Development Projects

• Top-down source are projects identified by top
  management or by a diverse steering committee.
• Bottom-up source are project initiatives stemming
  from managers, business units, or the development
  group.
• The process varies substantially across
  organizations.

6
The Process of Identifying and Selecting IS
Development Projects (Cont.)
7
The Process of Identifying and Selecting IS
Development Projects (Cont.)

• Classifying and ranking IS development projects.
• Using value chain analysis or other evaluation
  criteria
• Value chain analysis the process of analyzing an
  organizations activities for making products
  and/or services to determine where value is added
  and costs are incurred.

8
The Process of Identifying and Selecting IS
Development Projects (Cont.)
9
The Process of Identifying and Selecting IS
Development Projects (Cont.)

• Selecting IS development projects.
• Based on various factors.
• Consider both short- and long-term projects.
• Select those most likely to achieve business
  objectives.
• Is a very important and ongoing activity.

10
The Process of Identifying and Selecting IS
Development Projects (Cont.)
11
Deliverables and Outcomes

• Primary deliverable from the first part of the
  planning phase is a schedule of specific IS
  development projects.
• Outcome of the next part of the planning phase
  project initiation and planning is the
  assurance that careful consideration was given to
  project selection and each project can help the
  organization reach its goals.

12
Deliverables and Outcomes

• Incremental commitment a strategy in systems
  analysis and design in which the project is
  reviewed after each phase and continuation of the
  project is rejustified.

13
Corporate and Information Systems Planning

• To benefit from a planning-based approach for
  identifying and selecting projects
• An organization must analyze its information
  needs thoroughly.
• Plan its projects carefully.

14
Corporate Strategic Planning

• Ongoing process that defines mission, objectives,
  and strategies of an organization.

15
Corporate Strategic Planning

• Corporate strategy involves
• Mission statement
• Objective statements
• Description of competitive strategy

16
Corporate Strategic Planning (Cont.)

• Mission statement A statement that makes it
  clear what business a company is in.

17
Corporate Strategic Planning (Cont.)
18
Corporate Strategic Planning (Cont.)

• Objective statement a series of statements that
  express an organizations qualitative and
  quantitative goals for reaching a desired future
  position.

19
Corporate Strategic Planning (Cont.)
20
Corporate Strategic Planning (Cont.)

• Competitive strategy the method by which an
  organization attempts to achieve its mission and
  objectives.
• Main types
• Low-cost producer
• Product differentiation
• Product focus or niche

21
Information Systems Planning (ISP)

• An orderly means of assessing the information
  needs of an organization and defining systems,
  databases, and technologies that will best meet
  those needs
• ISP must be done in accordance with the
  organization's mission, objectives, and
  competitive strategy.

22
Information Systems Planning (Cont.)
23
Information Systems Planning (Cont.)

• IS planning must be kept in line with corporate
  strategic planning.

24
Information Systems Planning (Cont.)

• Top-down planning attempts to gain a broad
  understanding of information system needs of the
  entire organization and offers
• Broader perspective
• Improved integration
• Improved management support
• Better understanding

25
Information Systems Planning (Cont.)

• Bottom-up planning identifies IS development
  projects based on solving specific operational
  business problems or taking advantage of specific
  opportunities.
• Can be faster and less costly, so may be
  beneficial in certain circumstances.

26
Example

• Refer to Pine Valley Furniture for ISP (text book)

27
Information Systems (IS) Plan
28
Electronic Commerce Applications and Internet
Basics

• Electronic Commerce (EC) Internet-based
  communication to support day-to-day business
  activities.
• Internet a large worldwide network of networks
  that use a common protocol to communicate with
  each other.
• Intranet Internet-based communication to support
  business activities within a single organization.

29
Electronic Commerce Applications and Internet
Basics (Cont.)

• Extranet Internet-based communication to support
  business-to-business activities.
• Electronic data interchange (EDI) the use of
  telecommunications technologies to directly
  transfer business documents between organizations.

30
Electronic Commerce Applications and Internet
Basics (Cont.)
31
Initiating and Planning Systems Development
Projects

• What must be considered when making the decision
  on the division between project initiation and
  planning (PIP) and analysis.
• How much effort should be expended on the PIP
  process?
• Who is responsible for performing the PIP
  process?
• Why is PIP such a challenging activity?

32
The Process of Initiating and Planning IS
Development Projects
33
The Process of Initiating and Planning IS
Development Projects (Cont.)

• Project initiation focuses on activities designed
  to assist in organizing a team to conduct project
  planning.
• Establishing the Project Initiation Team.
• Establishing a Relationship with the Customer.

34
The Process of Initiating and Planning IS
Development Projects (Cont.)

• Establishing the Project Initiation Plan.
• Establishing Management Procedures.
• Establishing the Project Management Environment
  and Project Workbook.
• Developing the Project Charter.

35
The Process of Initiating and Planning IS
Development Projects (Cont.)

• The key activity of project initiation is the
  development of the project charter.
• A short document that is prepared for both
  internal and external stakeholders.
• Provides a high-level overview of the project.
• Useful communication tool that helps to assure
  that the organizations and other stakeholders
  understand the initiation of a project.

36
The Process of Initiating and Planning IS
Development Projects (Cont.)

• A project charter typically contains
• Project title and date of authorization
• Project manager name and contact information
• Customer name and contact information
• Projected start and completion dates

37
The Process of Initiating and Planning IS
Development Projects (Cont.)

• Key stakeholders, project role, and
  responsibilities
• Project objectives and description
• Key assumptions or approach
• Signature section for key stakeholders

38
The Process of Initiating and Planning IS
Development Projects (Cont.)

• The key activity of project planning is the
  process of defining clear, discrete activities
  and the work needed to complete each activity
  within a single project.
• The objective of the project planning process is
  the development of a Baseline Project Plan (BPP)
  and the Project Scope Statement (PSS)

39
Elements of Project Planning

• Describe project scope, alternatives,
  feasibility.
• Divide project into tasks.
• Estimate resource requirements and create
  resource plan.
• Develop preliminary schedule.
• Develop communication plan.

40
Elements of Project Planning (Cont.)

• Determine standards and procedures.
• Identify and assess risk.
• Create preliminary budget.
• Develop a statement of work.
• Set baseline project plan.

41
Deliverables and Outcomes

• Business Case
• Justification for an information system.
• Presented in terms of the tangible and intangible
  economic benefits and costs.
• The technical and organizational feasibility of
  the proposed system.

42
Deliverables and Outcomes (Cont.)

• Baseline Project Plan (BPP)
• A major outcome and deliverable from the PIP
  phase.
• Contains the best estimate of a projects scope,
  benefits, costs, risks, and resource requirements.

43
Deliverables and Outcomes (Cont.)

• Project Scope Statement (PSS)
• A document prepared for the customer.
• Describes what the project will deliver.
• Outlines at a high level all work required to
  complete the project.

44
Assessing Project Feasibility

• Economic
• Technical
• Operational
• Scheduling
• Legal and contractual
• Political

45
Assessing Project Feasibility (Cont.)
46
Assessing Project Feasibility (Cont.)

• Economic feasibility a process of identifying
  the financial benefits and costs associated with
  a development project.
• Often referred to as cost-benefit analysis.
• Project is reviewed after each SDLC phase in
  order to decide whether to continue, redirect, or
  kill a project.

47
Determining Project Benefits

• Tangible benefits refer to items that can be
  measured in dollars and with certainty.
• Examples include
• reduced personnel expenses,
• lower transaction costs, or
• higher profit margins.

48
Determining Project Benefits (Cont.)

• Most tangible benefits will fit within the
  following categories
• Cost reduction and avoidance
• Error reduction
• Increased flexibility
• Increased speed of activity
• Improvement of management planning and control
• Opening new markets and increasing sales
  opportunities

49
Determining Project Benefits (Cont.)

• Intangible benefits are benefits derived from the
  creation of an information system that cannot be
  easily measured in dollars or with certainty.
• May have direct organizational benefits, such as
  the improvement of employee morale.
• May have broader societal implications, such as
  the reduction of waste creation or resource
  consumption.

50
Determining Project Costs

• Tangible costs a cost associated with an
  information system that can be measured in
  dollars and with certainty.
• IS development tangible costs include
• Hardware costs,
• Labor costs, or
• Operational costs including employee training and
  building renovations.

51
Determining Project Costs (Cont.)

• Intangible costs a cost associated with an
  information system that cannot be easily measured
  in terms of dollars or with certainty.
• Intangible costs can include
• Loss of customer goodwill,
• Employee morale, or
• Operational inefficiency.

52
Determining Project Costs (Cont.)

• One-time cost a cost associated with project
  start-up and development or system start-up.
• These costs encompass activities such as
• Systems development,
• New hardware and software purchases,
• User training,
• Site preparation, and
• Data or system conversion.

53
Determining Project Costs (Cont.)

• Recurring cost a cost resulting from the ongoing
  evolution and use of a system.
• Examples of these costs include
• Application software maintenance,
• Incremental data storage expenses,
• Incremental communications,
• New software and hardware leases, and
• Supplies and other expenses (i.e. paper, forms,
  data center personnel).

54
Determining Project Costs (Cont.)

• Both one-time and recurring costs can consist of
  items that are fixed or variable in nature.
• Fixed costs are billed or incurred at a regular
  interval and usually at a fixed rate.
• Variable costs are items that vary in relation to
  usage.

55
Determining Project Costs (Cont.)

• Procurement
• Consulting, equipment, site preparation, capital,
  management time
• Start-up
• Operating systems, communications installation,
  personnel hiring, organizational disruption
• Project-related
• Application software, software modification,
  personnel overhead, training, data analysis,
  documentation
• Operating
• System maintenance, rental, asset depreciation,
  operation and planning

56
Economic Cost- Benefit Analysis Technique

• Net Present Value (NPV)
• Use discount rate to determine present value of
  cash outlays and receipts
• Return on Investment (ROI)
• Ratio of cash receipts to cash outlays
• Break-Even Analysis (BEA)
• Amount of time required for cumulative cash flow
  to equal initial and ongoing investment

57
The Time Value of Money

• Time value of money (TVM) the concept that money
  available today is worth more than the same
  amount tomorrow.
• Discount rate the rate of return used to compute
  the present value of future cash flows (the cost
  of capital).
• Present value the current value of a future cash
  flow

58
The Time Value of Money (Cont.)

• Net Present Value pg 142
• PVn present value of Y dollars n years from now
  based on a discount rate of i.
• NPV sum of PVs across years.
• Calculates time value of money.

59
NPV Summary

• Benefit
• PV Benefit (yearly)
• NPV Benefit Cumulative of PV Benefit
• Costs
• PV Cost (yearly)
• NPV Cost One Time Cost Cumulative PV Cost
• Overall NPV Subtract NPV Benefit from NPV Cost

60
ROI

• Overall ROI (Overall NPV / NPV Cost)

61
The Time Value of Money (Cont.)

• Break-even analysis a type of cost-benefit
  analysis to identify at what point (if ever)
  benefits equal costs.

62
Break Even Analysis

• Yearly cash flow subtract of one time cost and
  PV Cost (yearly) from PV Benefit (yearly)
• Overall NPV cash flow total cash flows for all
  preceding years

63
Assessing Technical Feasibility

• Technical feasibility a process of assessing the
  development organizations ability to construct a
  proposed system.

64
Assessing Technical Feasibility

• The potential consequences of not assessing and
  managing risks can include the following
• Failure to attain expected benefits from the
  project,
• Inaccurate project cost estimates,
• Inaccurate project duration estimates,
• Failure to achieve adequate system performance
  levels, and
• Failure to adequately integrate the new system
  with existing hardware, software, or
  organizational procedures.

65
Project Risk Factors

• Project size
• Team size, organizational departments, project
  duration, programming effort
• Project structure
• New vs. renovated system, resulting
  organizational changes, management commitment,
  user perceptions
• Development group
• Familiarity with platform, software, development
  method, application area, development of similar
  systems
• User group
• Familiarity with IS development process,
  application area, use of similar systems

66
Assessing Technical Feasibility (Cont.)

• Risk can be managed on a project by
• Changing the project plan to avoid risky factors,
• Assigning project team members to carefully
  manage the risky aspects,
• Setting up monitoring methods to determine
  whether or not potential risk is, in fact,
  materializing.

67
Assessing Technical Feasibility (Cont.)

• The four primary factors associated with the
  amount of technical risk on a given project are
• Project size,
• Project structure,
• The development groups experience with the
  application and technology area, and
• The user groups experience with systems
  development projects and the application area
  (see also Kirsch, 2000).

68
Assessing Technical Feasibility (Cont.)

• Four general rules emerged as technical risk
  assessments
• Larger projects are riskier than smaller
  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, ill defined, or subject to the
  judgment of an individual.

69
Assessing Technical Feasibility (Cont.)

• The development of a system employing commonly
  used or standard technology will be less risky
  than one employing novel or nonstandard
  technology.
• A project is less risky when the user group is
  familiar with the familiar with the systems
  development process and application area than if
  unfamiliar.

70
Assessing Technical Feasibility (Cont.)
71
Assessing Other Feasibility Concerns

• Operational
• Does the proposed system solve problems or take
  advantage of opportunities?
• Scheduling
• Can the project time frame and completion dates
  meet organizational deadlines?
• Legal and Contractual
• What are legal and contractual ramifications of
  the proposed system development project?
• Political
• How do key stakeholders view the proposed system?

72
Building the Baseline Project Plan

• Baseline Project Plan (BPP) is a document
  intended primarily to guide the development team.
• Sections
• Introduction
• System description
• Feasibility assessment
• Management issues

73
Building the Baseline Project Plan (Cont.)

• Project Scope statement is part of the BPP
  introduction.
• Sections
• Problem statement
• Project objectives
• Project description
• Business benefits
• Deliverables
• Expected duration

74
Factors in Determining Scope

• Organizational units affected by new system
• Current systems that will interact with or change
  because of new system
• People who are affected by new system
• Range of potential system capabilities

75
Diagram Depiction of Project Scope
76
Building the Baseline Project Plan (Cont.)

• System description section outlines possible
  alternative solutions.
• Feasibility assessment section outlines issues
  related to project costs and benefits, technical
  difficulties, and other such concerns.
• Management issues section outlines a number of
  managerial concerns related to the project.

77
Reviewing the Baseline Project Plan

• Structured Walkthroughs a peer-group review of
  any product created during the system development
  process
• Roles coordinator, presenter, user, secretary,
  standard-bearer, maintenance oracle
• Can be applied to BPP, system specifications,
  logical and physical designs, program code, test
  procedures, manuals and documentation

78
Performing Requirements Determination
79
The Process of Determining Requirements

• Systems Analyst Characteristics for Successful
  Requirements Determination
• Impertinence
• Impartiality
• Relaxing constraints
• Attention to details
• Reframing

80
Deliverables and Outcomes

• Deliverables for Requirements Determination
• From interviews and observations - interview
  transcripts, observation notes, meeting minutes
• From existing written documents - mission and
  strategy statements, business forms, procedure
  manuals, job descriptions, training manuals,
  system documentation, flowcharts

81
Deliverables and Outcomes (Cont.)

• From computerized sources Joint Application
  Design session results, CASE repositories,
  reports from existing systems, displays and
  reports from system prototype.

82
Traditional Methods for Determining Requirements

• Interviewing individuals
• Interviewing groups
• Observing workers
• Studying business documents

83
Interviewing and Listening

• One of the primary ways analysts gather
  information about an information systems project.
• Interview Guide is a document for developing,
  planning and conducting an interview.

84
Guidelines for Effective Interviewing

• Plan the interview.
• Prepare interviewee appointment, priming
  questions.
• Prepare agenda, checklist, questions.
• Listen carefully and take notes (tape record if
  permitted).
• Review notes within 48 hours.
• Be neutral.
• Seek diverse views.

85
Interviewing and Listening (Cont.)
86
Choosing Interview Questions

• Each question in an interview guide can include
  both verbal and non-verbal information.
• Open-ended questions questions that have no
  prespecified answers.
• Closed-ended questions questions that ask those
  responding to choose from among a set of
  specified responses.

87
Interviewing Groups

• Drawbacks to individual interviews
• Contradictions and inconsistencies between
  interviewees.
• Follow-up discussions are time consuming.
• New interviews may reveal new questions that
  require additional interviews with those
  interviewed earlier.

88
Interviewing Groups (Cont.)

• Interview several key people together
• Advantages
• More effective use of time.
• Can hear agreements and disagreements at once.
• Opportunity for synergies.
• Disadvantages
• More difficult to schedule than individual
  interviews.

89
Nominal Group Technique (NGT)

• A facilitated process that supports idea
  generation by groups.
• Process
• Members come together as a group, but initially
  work separately.
• Each person writes ideas.
• Facilitator reads ideas out loud, and they are
  written on a blackboard or flipchart.

90
Nominal Group Technique (NGT)

• Group openly discusses the ideas for
  clarification.
• Ideas are prioritized, combined, selected,
  reduced.
• NGT exercise used to complement group meetings or
  as part of JAD effort.

91
Directly Observing Users

• Direct Observation
• Watching users do their jobs
• Obtaining more firsthand and objective measures
  of employee interaction with information systems.
• Can cause people to change their normal operating
  behavior.
• Time-consuming and limited time to observe.

92
Analyzing Procedures and Other Documents

• Document Analysis
• Review of existing business documents
• Can give a historical and formal view of system
  requirements
• Types of information to be discovered
• Problems with existing system
• Opportunity to meet new need
• Organizational direction

93
Analyzing Procedures and Other Documents (Cont.)

• Names of key individuals
• Values of organization
• Special information processing circumstances
• Reasons for current system design
• Rules for processing data

7.93
94
Analyzing Procedures and Other Documents (Cont.)

• Useful document Written work procedure
• For an individual or work group.
• Describes how a particular job or task is
  performed.
• Includes data and information used and created in
  the process.

7.94
95
Analyzing Procedures and Other Documents (Cont.)
96
Analyzing Procedures and Other Documents (Cont.)

• Potential Problems with Procedure Documents
• May involve duplication of effort.
• May have missing procedures.
• May be out of date.
• May contradict information obtained through
  interviews.

97
Analyzing Procedures and Other Documents (Cont.)

• Formal Systems the official way a system works
  as described in organizational documentation
  (i.e. work procedure).
• Informal Systems the way a system actually works
  (i.e. interviews, observations).

98
Analyzing Procedures and Other Documents (Cont.)

• Useful document Business form
• Used for all types of business functions.
• Explicitly indicate what data flow in and out of
  a system and data necessary for the system to
  function.
• Gives crucial information about the nature of the
  organization.

99
Analyzing Procedures and Other Documents (Cont.)
100
Analyzing Procedures and Other Documents (Cont.)

• Useful document Report
• Primary output of current system.
• Enables you to work backwards from the report to
  the data needed to generate it.
• Useful document Description of current
  information system

101
Analyzing Procedures and Other Documents (Cont.)
102
Contemporary Methods for Determining System
Requirements

• Joint Application Design (JAD)
• Brings together key users, managers, and systems
  analysts.
• Purpose collect system requirements
  simultaneously from key people.
• Conducted off-site.
• Group Support Systems
• Facilitate sharing of ideas and voicing of
  opinions about system requirements.

103
Contemporary Methods for Determining System
Requirements (Cont.)

• CASE tools
• Used to analyze existing systems.
• Help discover requirements to meet changing
  business conditions.
• System prototypes
• Iterative development process.
• Rudimentary working version of system is built.
• Refine understanding of system requirements in
  concrete terms.

104
Joint Application Design (JAD)

• Intensive group-oriented requirements
  determination technique.
• Team members meet in isolation for an extended
  period of time.
• Highly focused.
• Resource intensive.
• Started by IBM in 1970s.

105
JAD (Cont.)
106
JAD (Cont.)

• JAD Participants
• Session Leader facilitates group process.
• Users active, speaking participants
• Managers active, speaking participants
• Sponsor high-level champion, limited
  participation.

107
JAD (Cont.)

• Systems Analysts should mostly listen.
• Scribe record session activities.
• IS Staff should mostly listen.
• End Result
• Documentation detailing existing system.
• Features of proposed system.

108
CASE Tools During JAD

• Upper CASE tools are used.
• Enables analysts to enter system models directly
  into CASE during the JAD session.
• Screen designs and prototyping can be done during
  JAD and shown to users.

109
Using Prototyping During Requirements
Determination

• Quickly converts requirements to working version
  of system.
• Once the user sees requirements converted to
  system, will ask for modifications or will
  generate additional requests.

110
Using Prototyping During Requirements
Determination (Cont.)

• Most useful when
• User requests are not clear.
• Few users are involved in the system.
• Designs are complex and require concrete form.
• History of communication problems between
  analysts and users.
• Tools are readily available to build prototype.

111
Using Prototyping During Requirements
Determination (Cont.)

• Drawbacks
• Tendency to avoid formal documentation.
• Difficult to adapt to more general user audience.
• Sharing data with other systems is often not
  considered.
• Systems Development Life Cycle (SDLC) checks are
  often bypassed.

112
Radical Methods for Determining System
Requirements

• Business Process Reengineering (BPR) search for,
  and implementation of radical change in business
  processes to achieve breakthrough improvements in
  products and services.

113
Radical Methods for Determining System
Requirements (Cont.)

• Goals
• Reorganize complete flow of data in major
  sections of an organization.
• Eliminate unnecessary steps.
• Combine steps.
• Become more responsive to future change.

114
Identifying Processes to Reengineer

• Identification of processes to reengineer
• Key business processes
• Structured, measured set of activities designed
  to produce specific output for a particular
  customer or market.
• Focused on customers and outcome.
• Same techniques are used as were used for
  requirements determination.

115
Disruptive Technologies

• Information technologies must be applied to
  radically improve business processes.
• Disruptive technologies are technologies that
  enable the breaking of long-held business rules
  that inhibit organizations from making radical
  business changes.

116
Disruptive Technologies (Cont.)
117
Requirements Determination using Agile
Methodologies

• Continual user involvement
• Replace traditional SDLC waterfall with iterative
  analyze design code test cycle
• Agile usage-centered design
• Focuses on user goals, roles, and tasks
• The Planning Game
• Based on eXtreme programming
• Exploration, steering, commitment

118
Continual User Involvement
119
Agile Usage-Centered Design Steps

• Gather group of programmers, analysts, users,
  testers, facilitator.
• Document complaints of current system.
• Determine important user roles.
• Determine, prioritize, and describe tasks for
  each user role.
• Group similar tasks into interaction contexts.
• Associate each interaction context with a user
  interface for the system, and prototype the
  interaction context.
• Step through and modify the prototype.

120
The Planning Game from eXtreme Programming
121
Summary

• In this chapter you learned how to
• Describe the project identification and selection
  process.
• Describe corporate strategic planning and
  information systems planning.
• Explain the relationship between corporate
  strategic planning and IS planning.

122
Summary (Cont.)

• Describe how IS planning can assist in system
  development project identification and selection.
• Analyze IS planning matrices.
• Describe three classes of E-Commerce applications.

123
Summary

• Describe steps involved in project initiation and
  planning.
• Explain the need for and contents of Statement of
  Work and Baseline Project Plan.
• List and describe methods for assessing project
  feasibility.
• Describe tangible vs. intangible costs and
  benefits, and one-time vs. recurring costs and
  benefits.

124
Summary (Cont.)

• Perform cost-benefit analysis, and understand
  time value of money, present value, discount
  rate, return on investment, and break-even
  analysis.
• Describe rules for evaluating technical risk of
  systems development projects.
• Describe activities and roles of structured
  walkthroughs.

125
Summary

• Describe interviewing options and develop
  interview plan.
• Explain advantages and pitfalls of worker
  observation and document analysis.
• Explain how computing can support requirements
  determination.

126
Summary (Cont.)

• Participate in and help plan Joint Application
  Design sessions.
• Use prototyping during requirements
  determination.
• Describe contemporary approaches to requirements
  determination.