Initiating and Planning Systems Development projects

1
Chapter 6

• Initiating and Planning Systems Development
  projects

2
Initiating planning systems development project

• Input Output phase 1
• Output
• Statement Of Work (SOW)
• Baseline Project Plan (BPP)
• Purpose (objective) develop a business case, i.e.
  the justification for IS in term of tangible
  intangible benefits, costs, technical and
  organisational feasibility of the proposed
  system.
• Who is responsible to perform phase 2?
• Experienced systems analysts
• Team of analyst who work close to managers,
• Users
• Other technical development staff
• Process of PIP
• Project initiation
• Project planning

3
Project initiation elements

• Establishing the project initiation team
• Establishing relationship with the customer
• Establishing the project initiation plan (scope
  and objectives)
• Establishing management procedure (communication
  and reporting procedures, conflict management,
  funding billing)
• Establishing project management environment
  project workbook

4
Project planning elements

• Describing project scope, alternatives and
  feasibility
• Dividing the project into manageable tasks and
  logical order
• Estimating resources and creating a resources
  plan
• Developing a preliminary schedule
• Developing a communication plan
• Establishing work standards and procedures
  (alternatives to SDLC, case tools)
• Identifying and assessing risks (potential
  problems)
• Creating a preliminary budget
• Developing a Statement Of Work
• Setting a Baseline Project Plan (specify detailed
  project for next phase of SDLC)

5
Output of PIP

• Baseline Project Plan (BPP)
• It is a major output from the PIP phase which
  contains the best estimate of the projects
  scope, benefits, costs, risks, and resource
  requirements
• Statement Of Work (SOW)
• It is document prepared for the customer during
  project initiation and planning that describes
  what the project will deliver (objectives), when
  it will be completed, resources it may consume
  and outline is generally at a high level all work
  required to complete the project including
  constraints of the project

6
Business CaseTangible and Intangible cost

• Business case
• the justification for an information system,
  presented in terms of the tangible and intangible
  economic benefits and costs and the technical and
  organization feasibility of the proposed system.
• Tangible costs A cost associated with an IS that
  can be measured in dollars and with certainty.
• E.g. hardware cost, internet services setup fee,
  data entry
• Intangible costs A cost associated with an IS
  that can NOT be easily measured in dollars and
  with certainty.
• E.g. Loss of customer goodwill
• One time cost A cost associate with project
  start-up and development, or system start-up
• User training, site preparation, new hardware
• Recurring cost A cost resulting from the ongoing
  evolution and use of a system.
• Software maintenance

7
Assessing project feasibility

• There many factors that should be taken into
  consideration when assessing a potential project
• Economic feasibility
• Technical feasibility
• Operational feasibility
• Schedule feasibility
• Legal and contractual feasibility
• Political feasibility
• Analyses of all the above factors constitute the
  business case

8
Definitions

• Economic feasibility
• A process of identifying the financial benefits
  and cost associated with development process
• Technical feasibility
• A process of assessing the development
  organisations ability to construct a proposed
  system
• Operational feasibility
• It is process of assessing the degree to which a
  proposed system solves business problem or take
  advantages of business opportunities
• 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
  organisational deadlines and constraints for
  affecting change
• 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 deadline and constraint for
  affecting change.
• Legal contractual feasibility
• It is the process of assessing potential legal
  and contractual ramifications due the
  construction of a system
• Political feasibility
• The process of evaluating how key stakeholders
  withing the organization view the proposed
  system.

9
Project risk assessment factors

• Project size
• Project structure
• Development group
• User group

10
Project risk assessment factors
Project Size and Project Structure

• Project size
• Small projects are less riskier than large
  projects
• Factors that increase risks
• Number of members on the project team
• Number of organisational departments involve
• Understanding the targets of the projects
• Size of programming efforts
• Project structure
• Projects with clear requirements (well
  structured) will have less risks than project
  with messy (or ill-structured) requirements
• Factors that increase risks
• User perception to participate in effort
• Organisational, procedural personal change
  resulting from the system
• Management commitment to the system

11
Project risk assessment factors
Development group and User group

• Development group
• Group with more experience with similar systems
  (technology), and employing commonly used or
  standard technology will be less risky than one
  employing novel or non-standard technology
• Factors that affect development group
• Familiarity with target-hardware software
  development environment (operating environments
  to be used )
• Familiarity with similar technology
• Familiarity with proposed application area
• User group
• A project is less risky when the user group is
  familiar with the system development process and
  application area than unfamiliar

12
Building the baseline project plan (BPP)

• All the information collected during PIP is
  collected and organised into a document called
  baseline project plan (BPP)
• Two objectives of BPP. It helps
• customer and development group share a common
  understanding of the project
• sponsoring organisation with a clear idea of the
  scope, benefits, and duration of the project
• Once the BPP is completed, a milestone take take
  place, i.e. a review meeting between all
  concerned parties.
• The result of the review meeting is called
  walkthrough action list