Chapter 6
Initiating and Planning Systems
Development projects
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
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
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)
Output of PIP
• Baseline Project Plan (BPP)
• 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
Business Case:
Tangible 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
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”
Definitions
•
Economic 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.
Project risk assessment factors
1.
2.
3.
4.
Project size
Project structure
Development group
User group
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
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
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