1. Initiating and Planning Systems Development projects
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) Statement Of Work (SOW)
It is a major output from the PIP phase which contains the best estimate of the project’s 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 Case: Tangible and Intangible cost
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 Technical feasibility
A process of identifying the financial; benefits and cost associated with development process
Technical feasibility
A process of assessing the development organisation’s 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
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