Chapter 8

Initiating systems development

LEARNING Objectives
1. Introduction.
2. Reasons for project initiation.
3. The feasibility study.
4. Risk management.
5. Acquisition choices and methods.
Objective1: Introduction

This objective covers the following points:

1.1- Initiation or startup phase
1.2- Feasibility study
 1.1- Initiation or startup phase
- The first phase in an information systems
development project.
- Its aims are to establish whether the project is feasible
and prepare to ensure the project is successful.
- An information systems project is typically initiated as
a response to internal and/or external demands in an
organization's environment.
1.2- Feasibility study
- It is designed as a preliminary investigation intended to
establish whether a business opportunity or problem can
be solved through introducing a new information system.
- The activity that occurs before the requirements
determination stage of a systems development project to
ensure that the project is a viable business proposition.
- The feasibility report analyses the need for and impact
of the system and considers different alternatives for
acquiring software.
Objective 2: Reasons why an information
systems project might be initiated.
The main reasons why an information systems project
might be initiated are:
1- Capability:
- A new information system can provide a new capability to
achieve something that has not previously been possible.
- For example, creating online grocery sales through a web site
gives a new sales channel capability.
- An improved capability can be provided by increasing the
amount of storage of an existing system or upgrading the
software to a version with new features.
2- Cost savings:
- Cost reduction is often the key driver for the introduction of
new systems. This factor is relatively easy to quantify and is
readily understood by the managing director and finance
manager.
3- Improved internal information flows:
- This is one of the reasons why many organizations turn to
enterprise systems.
4- Improved external information flows:
- In addition to an organization's internal value chain, there is also the
external value chain to consider and, in particular, the relationship
between the organization and its customers, suppliers and channel
partners.
- Order tracking through the supplier’s delivery partner will also
enhance the buying process.
5- Improved customer service:
- Customer service can be enhanced indirectly: a company could
purchase an improved sales order processing system that reduces the
time taken to order and deliver a product to the customer or ‘free up’
staff time to deal with more difficult customer service problems.
6- Legislation changes:
- All organizations provide one of those ‘must-do’ situations
where legislative requirements must be complied with.
7- Responsiveness:
- Organization's portfolio of computer-based information systems
must also enjoy a sufficiently flexible hardware and software
infrastructure so that enhancements and improvements can be
installed easily.
8- Reach:
- By using Internet and extranet technologies, it is possible to extend
an organization's value chain such that it can broaden its range of
possible suppliers (thus potentially reducing costs) and also its
customer base (thus in-creasing revenues).
9- Control:
- Control can be improved through better information delivery for
managers.
- A sales manager who has weekly reports on the performance of
his or her salesforce is in a better position to exercise control than
a manager who receives the figures monthly.
10- Competitive advantage:
- If information systems can give a company the edge over its
rivals through the benefits above, a competitive advantage
may be achieved.
- First-mover advantage means that rivals will find it difficult to
win back customers already using these services and they may
take several years to catch up.
Objective 3 - The Feasibility Study
- The different parts of a feasibility study are commonly categorized as
organizational feasibility, economic feasibility, technical feasibility and
operational feasibility
3.1- Organizational feasibility
- Considers how closely the solution will match the needs of the
organization and identifies problems that may arise in this area.
- The most important aspect of organizational feasibility is consideration
of how well the proposed system fits in with the company’s overall
business and IS strategy.
- Often the desirability of a system will be compared to other competing
systems.
- As part of benefits identification during assessment of economic
feasibility, it is important to check that there is a strong alignment
between the benefits that the new information system will provide
and the overall business strategy.
3-1-1 Critical success factors
• The use of critical success factors (CSFs) is valuable in helping
to align new systems with business objectives.
• Critical success factors are those factors that determine whether
business objectives will be achieved.
3-2- Economic feasibility
- Is the analysis of the different costs and benefits of implementing the
new system.
- It also assesses the relative importance of the new system in the
comparison with other proposed systems
3-2-1- Assessing costs and benefits
- A fundamental problem is that it is not easy to measure each
benefit and cost accurately.
- The business analyst undertaking a cost–benefit analysis will
identify both tangible and intangible costs and benefits.
• When a cost or benefit is tangible, it is possible to set a
definite numeric value against an item such as the cost of
installing a new network.
• Tangible costs are a measure of cost that can be calculated
for each item of expenditure on BIS.
• An intangible cost is when it is not possible to place a
numeric value on intangible costs and benefits.
• It is also when a monetary value cannot be placed on the
disruption and possible user resistance that will occur due to
implementing a new system will have an effect on overall
company performance, but they are difficult to measure.
3-2-1-1 Assessing costs
•A range of costs must be included in the feasibility study. These
include:
1. hardware and software purchase costs.
1.systems development staff costs.
2.installation costs including cabling, physically moving equipment.
3.migration costs such as transferring data from an existing system to
the new system.
4.operating costs including maintenance costs of hardware.
5.Staff costs in maintaining the hardware and software.
6.training costs
3-2-1-2- Assessing benefits
•While information systems costs are relatively easy to identify, the
benefits are harder to quantify since they are often intangible and will
occur in the future.
Intangible benefits will include improvements to the quality of
information. A new information system should enable information quality
to be improved in some of the following ways:
1.improved accuracy.
2.improved availability and timeliness.
3.improved usability (easier to understand and then act on information).
4.improved utilization.
5.improved security of information.
3-3- Technical feasibility
• Technical feasibility refers to the analysis of possible
technical problems in the different solutions and
who is appropriate to solve them.
• Technical feasibility can involve asking a series of
questions to determine whether a computer system
is the right tool for solving a problem.
• The types of questions asked are:
1- Can the system deliver the performance required?
2- Will the system meet availability or reliability requirements?
An online banking system should ideally be available 100% of the time,
so what are the risks in terms of hardware, software and network errors
that will prevent this?
3- Does the system deliver the necessary level of security?
4- Will there be data integration or data quality problems?
5- Can the system support the type of decision making required
(particularly support for semi-structured or unstructured decisions)?
6- will the proposed solution will work at all?
7- How much will the solution cost?
3-4- Operational feasibility
• Operational feasibility will review how the introduction
of the new system will affect working practices on a day-
to-day basis.
• For example; banks employ usability companies to reduce
the risks that the system will be difficult to use or will not
meet accessibility guidelines.
• There is close linkage between operational and
organizational feasibility, and they are sometimes
considered together.
Objective 4 - Risk Management
• Risk management can be used at the start of a project to
determine the level of risk and develop plans for reducing
this risk
• It is particularly important as part of assessing operational
and organizational feasibility.
• There are 27 common IT risks, grouped into
seven broad categories.
1. Commercial and legal relationships:
- Inadequate third-party performance where the contractor is
unable to provide a solution that meets time, cost, quality and
performance objectives.
- inadequate protection of software through copying, resulting
in high litigation cost and loss of market potential.
- Friction between clients and contractors where
misunderstandings, missed or delayed delivery.
2. Economic circumstances.
- Changing market conditions (perhaps as a result of lengthy cycle
times for software development).
- Harmful competitive actions where competitors may build software
solutions more quickly, with greater functionality at cheaper cost.
- Software no longer needed because the software that is developed is
prematurely terminated because its value or impact exceeds what
management is prepared to absorb.
3. Human behavior.
- Work cannot be completed owing to insufficient staff and poor-
quality staff through lack of ability, training, motivation and experience
of staff
4. Political circumstances.
- Corporate culture is not supportive of the project
owing to hidden agendas.
- organizational culture under continuous change or
threat of change, and other internal priorities.
- lack of executive support where the project is
disrupted from achieving its objectives owing to
management playing politics within and between
departments or external agents .
- lack of top-level management sponsorship.
5. Technology and technical issues.
• Inadequate user documentation.
• Application software perceived as not being fit for purpose
because users believe that the software provided does not
directly help them.
• Poor production system performance due to the selected
software architecture/platform not meeting the purpose for
which it was intended.
• Time delays to the project.
• If a solution cannot be found the project will either be
cancelled or restarted with a more viable technical solution.
6. Management activities and controls:
- An unreasonable project schedule and budget where the project
is unable to realize its objectives.
- Continuous changes to the requirements by a client.
- Lack of agreed-to user acceptance testing.
- Failure to review daily progress, resulting in project slippage.
- Lack of a single point of responsibility for project deliverables.
- Poor leadership where the project manager and/ or steering
committee is not committed to solving problems and providing
direction to the project team
7. Individual activities:
There are two factors here of note:
- Over-specification where the project team is
focused on analyzing and generating excessive
levels of detail, thus losing sight of the project’s
objectives.
- Unrealistic expectations where the functionality and
benefits of the product are over-sold and the items
promised for delivery to individuals may be
unrealistic.
Objective 5: Acquisition Choices
and Methods
- The make-or-buy decision will occur, and different
suppliers of either off-the-shelf or bespoke solutions will
be evaluated.
- The economic, technical and operational feasibility will
be evaluated for each of the suppliers after a tender or
request for proposals has been sent out to the suppliers.
- If a company decides to use a third party to develop its
information systems or provide other IS services, this is
known as outsourcing
5-1 Summarizing system requirements
• If we decide to go ahead after the initial feasibility
study, the next stage for a major implementation for
a large organization will be to issue an invitation to
tender a document, brief or request for
proposals (RFP).
• The RFP is a specification drawn up to assist in
selecting the supplier and software.
5-2 Techniques for comparing systems
• When purchasing a system, structured decision making is
required to ensure that the best option is selected.
• Three simple methods for making product or supplier decisions
are given below.
5-2-1 Feature checklist – first-cut exclusion:
- This is used initially to exclude products that are perhaps missing
a key function or do not support the operating system you use.
- The humble feature checklist is the most easily applied.
5-2-2 Feature checklist – detailed ranking
•The main deficiency of simple checklists is that they do not attach relative
importance to features.
5-2-3 Final selection using benchmarking
- Once a company has narrowed down its selection of software using feature
checklists to two or three contenders, a number of possibilities are available to make
the final decision.
- First, it is possible to benchmark against other organizations that are performing
similar tasks to you – what are their experiences, what performance is the software
achieving, are they an independent reference site?
- Second, if it is a large order, you can ask the suppliers to provide the software and
test important functions using example process scenarios from a company, often
including example data.
5-3 Which factors should be used when
selecting systems?
important key factors in selecting systems.
1. Functionality: Does the software have the features described to
support the business requirements?
2. Ease of use: for both end-users and initial setup and administration.
3. Performance: for different functions such as data retrieval and screen
display. If used in a customer-facing situation, this will be a critical
factor.
4. Compatibility or interoperability. How well does your solution
integrate with other products? This includes what you are using now and
what you will be using based on your strategic direction.
5. Compatibility: Software compatibility defines whether
one type of software will work with another.
6. Interoperability: A general term used to describe how
easily different components of a system can be integrated.
7. Security: This includes how easy it is to set up access
control for different users and the physical robustness of
methods for restricting access to information.
8. Stability or reliability of product: Early versions of
products often have bugs and you will experience a great
deal of downtime and support calls; hence the saying
‘never buy one dot zero’ (Version 1.0).
9. Prospects for long-term support of product: will
the product exist in three years’ time? Is the company
responsive in issuing patches and new features for the
product?
10. Extensibility: Will the product grow? Are the
features available to accommodate your future needs?
5-4 Assessing products from different suppliers
• A small ‘startup’ company may provide a good
range of features in its products, but it is likely to
have fewer staff responsible for ensuring quality of
the software and providing after-sales support.
• A further risk is that the vendor may fail or be taken
over by a larger company and no support or upgrade
versions will be available.
5-5 Contract negotiation
- Contracts define which activities should happen and when, and
who is responsible for them.
5-5-1 Contracts should define the following main
parameters:
1. business requirements and features of system;
2. deliverables such as hardware, software and documentation;
3. timescales and milestones for different modules;
4. how the project is managed;
5. division of responsibilities between different suppliers and the
customer;
6. costs and method of payment;
7. long-term support of system.
5-5-2 Contracts are particularly difficult to establish for
the following reasons:
■ It is difficult to specify the requirements in detail at the outset of
the project when the contract is signed.
■ Establishing acceptable performance at the outset is difficult
because this depends on the combination of hardware and
software.
■ Many different suppliers are involved, and it is often not clear
where responsibilities for fixing problems may lie.
■ After the project is finished, critical errors can potentially occur.
■ If a supplier’s business fails, the system may be unmaintainable
5-6 Contents of a typical IS product contract
• A typical contract will be made up of the following sections or schedules:
Schedule 1: Product specification and acceptance
• This is usually the most involved section, since it will detail the features of
the software and acceptance criteria.
• These will include the completion of all key features with an acceptable level
of error and ensure that functions such as reporting occur rapidly enough.
Schedule 2: Input to project from client
• This information is sometimes omitted since most activities are conducted by
the provider.
• The activities essential to the completion of the project may include time for
writing and reviewing requirements and prototypes; time for user acceptance
testing (UAT); time for
• training; supply of test data; possibly supply of hardware and systems
software (if purchased by buying department of company); support from
internal IS function and project management.
Schedule 3: Services to be supplied by contractor
• Each deliverable should be linked to a milestone and a specific payment to
help avoid slippage in the project.
• Milestones should include deliverables from both client and supplier.
Frequent monthly milestones should be set.
Schedule 4: Support of system and warranty
• A service-level agreement should state how problems are ‘escalated’ within
sup-pliers (passed up through the hierarchy so as to be resolved) and should
define acceptable times for response according to the severity of the problem.
• The fault-logging system and contact points such as a helpdesk may also be
defined.
Schedule 5: Project plan
• An outline project plan showing key deliverables and milestones
should be part of the contract. Responsibility for project management
will be identified for both parties and regular meetings defined.
Schedule 6: Payment method
• The two main methods of payment are fixed price, which tends to be
favoured by the client since it has better visibility of costs, and time
and materials, which is usually preferred by the supplier. Timing of
payments should be tied into milestones (when they are known as
‘phased payments’). Suppliers may prefer regular monthly payments.
• Penalty clauses or liquidated damages may be stipulated where the
supplier loses part of its payment if it delivers late or risk and reward
clauses which provide financial incentivesif it delivers early.