Information Systems Management Information Systems Assignment

giggles.desmoin

Ch8ManagementInformationSystems.pdf

Home >Information Systems homework help >Information Systems Management Information Systems Assignment

CHapter

8 Initiating systems development

LEARNING OUTCOMES

After reading this chapter, you will be able to:

■ explain the importance of conducting a structured initiation phase for a BIS project;

■ identify typical tangible and intangible costs and benefits associated with the introduction of an information system;

■ apply different techniques to select the most appropriate options from different software, hardware and supplier alternatives;

■ describe the importance of contracts to a successful outcome to information systems projects.

MANAGEMENT ISSUES

The senior management team sponsoring a new BIS must ensure that the project is (a) necessary, i.e. will contribute to business performance, and (b) that it is managed effectively. The initiation and feasibility phase of the systems development lifecycle is directed at achieving these two aims. From a managerial perspective, this chapter addresses the following questions:

■ How should we assess the feasibility of a project?

■ What are the stages and techniques that can be applied to assess feasibility?

■ How can the return on investment of a BIS project be assessed?

■ How can we manage the risks associated with IS projects?

CHAPTER AT A GLANCE

MAIN TOPICS

■ Reasons for project initiation 294

■ The feasibility study 297

■ Risk management 302

■ Acquisition choices and methods 305

FOCUS ON . . .

■ Techniques for comparing systems 306

CASE STUDIES

8.1 Recession reveals the dark side of advanced IT 304

8.2 Sedgemoor District Council 312

M08_BOCI6455_05_SE_C08.indd 293 10/13/14 2:41 PM

Part 2 business information systems development294

Successful completion of information systems is challenging – many information systems projects fail. Often these projects overrun in time or budget, or they do not deliver the benefits expected (see section ‘Why do projects fail?’ in Chapter 9 for more details on information systems project failure).

Failure to achieve success often occurs if the very first initiation or startup phase of the project is poorly managed. This chapter describes all the activities that need to occur at the start of a project to minimise the risk of failure later.

The initiation phase is the first phase in an information systems development project. An information systems project is typically initiated as a response to internal and/or external demands in an organisation’s environment.

A feasibility study will typically follow the initiation phase. 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. It is often also referred to as defining the ‘terms of reference’ for the project.

This chapter will consider the two stages separately. First, we will look at the reasons why an information systems project might be initiated, and then we will analyse those elements that make up a typical feasibility study. Provided that a proposed development project can demonstrate that the various feasibility elements can be satisfied, further work on software acquisition can then proceed.

INTRODUCTION

REASONS FOR PROJECT INITIATION

Figure 8.1 summarises the context for the initiation phase of a systems development project. The stimulus for such a project may come internally from within the organisation or externally from outwith it, or from a combination of the two.

From an internal perspective, the initiation point may lie within one or more individual functional area within the organisation (such as accounting or marketing). The initiation point may also be as a consequence of a need to integrate different functional parts of the organisation more effectively.

From an external perspective, the project initiation may be in response to one or more external entities that lie outside the organisation. Sometimes, an organisation has no choice but to meet the requirements as set out by an external body (such as a government agency). An organisation may also place itself at a competitive disadvantage if it does not meet the requirements of a customer or supplier (for example by not trading electronically).

An information systems project, therefore, may either be in response to a problem or opportunity that arises in the internal and/or external organisational environment or simply as a result of necessity in order to meet legal or other obligations.

When a company is considering the benefits that can arise through implementing an information system, there are a number of possible reasons why an information systems project might be initiated:

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. Information systems can also be enhanced to improve an existing capability where capacity has become limited. For example, business expansion may produce workloads with which current systems cannot cope – a growing company may find that its existing systems can no longer handle the quantity of orders received. 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.

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.

Feasibility study

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.

M08_BOCI6455_05_SE_C08.indd 294 10/13/14 2:41 PM

295ChaPter 8 initiating systems development

Figure 8.1 Sequence of main activities involved with project initiation

Identification of problem or opportunity

Set up feasibility

study

Define objectives and scope

Evaluate alternatives

(make or buy)

Detailed project plan and quality

plan

Recommend proceed?

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. Different aspects of quantifying cost are given in the section on cost–benefit analysis. For a new banking system cost reduction can be measured by modelling the cost savings per transaction – each transaction between a customer and staff over the phone or in a branch can cost several euros, but for an online system these staff costs are zero.

3. Improved internal information flows. Well-established organisations with a long history of using computer-based information systems may have developed their software portfolio in a piecemeal manner over many years. As a result, the installed legacy systems may not have the linkages necessary to facilitate efficient and effective communication within and between different functional areas of the organisation. This is one of the reasons, therefore, why many organisations turn to enterprise systems of the type discussed in Chapter 6.

4. Improved external information flows. In addition to an organisation’s internal value chain, there is also the external value chain to consider and, in particular, the relationship between the organisation and its customers, suppliers and channel partners. For example, a company wishing to purchase computer hardware may be more likely to use a supplier that gives accurate stock levels and delivery information on their web site so that there is an increased level of certainty that the right products

M08_BOCI6455_05_SE_C08.indd 295 10/13/14 2:41 PM

Part 2 business information systems development296

will be delivered on time. 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. Customers are also more likely to respond favourably to an organisation when they have confidence in the accuracy of the information held about them and their business transactions.

6. Legislation changes. These are a fact of life for all organisations and provide one of those ‘must-do’ situations where legislative requirements must be complied with. For example, many countries have introduced data protection laws that may trigger changes to software needed to conform to the legislation’s requirements.

7. Responsiveness. Organisations are increasingly competing on the basis of the speed with which they can respond to the changing internal and external business environment. This means that an organisation’s portfolio of computer-based information systems must not only be capable of providing appropriate information from both internal and external sources (such as accurate market intelligence), but must also enjoy a sufficiently flexible hardware and software infrastructure so that enhancements and improvements can easily be incorporated into the organisation’s information systems portfolio.

8. Reach. While this overlaps with some of the points above, this factor recognises that potential customers and suppliers can exist anywhere in the world. Therefore, by using Internet and extranet technologies, it is possible to extend an organisation’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. Similarly, an internal budget holder will have much better control over their income and expenditure if they have access to real-time financial accounting information.

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. For example, supermarket Tesco (www.tesco.com) was one of the first in its sector to introduce a home shopping service – it has a far greater market share in the online world than for its physical stores. First-mover advantage means, therefore, that rivals will find it difficult to win back customers already using these services who are partially locked-in to the system and they may take several years to catch up. However, some such as Nicholas Carr of the Harvard Business School argue that competitive advantage is transitory as competitors copy innovation (Carr, 2003).

An alternative indication of the need for a new system is to ask: What would be the consequence of not having the proposed information system?

Select a company or organisation with which you are familiar. Rank in order of importance the benefits that developing a new BIS, such as an e-commerce system, could deliver to the business or a particular department. You should give an explanation of why you have placed each benefit factor where you have. If you are completing a class activity you can compare the different systems by placing the benefits side-by-side on a whiteboard.

Benefits of BISActivity 8.1

M08_BOCI6455_05_SE_C08.indd 296 10/13/14 2:41 PM

297ChaPter 8 initiating systems development

THE FEASIBILITY STUDY

The different parts of a feasibility study are commonly categorised as organisational feasibility, economic feasibility, technical feasibility and operational feasibility. These factors will usually be reviewed for each of the possible solutions that have been proposed. The alternative solutions may be from different hardware or software vendors, or they may be different technical solutions that have been proposed by systems integrators or internal development teams.

In this section we will review each type of feasibility in turn. They are summarised in Table 8.1. The main focus will be on organisational and economic feasibility since these are most important as regards whether the IS project proceeds. Technical and operational feasibility usually address risks with the project which can be managed and as such these stages will not usually determine whether the project goes ahead or not.

Organisational feasibility considers how closely the solution will match the needs of the organisation and identifies problems that may arise in this area. The most important aspect of organisational 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.

Alignment of information systems with the business strategy

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. This is the top-down approach to IS strategy described later (in Chapter 13), where the mission and objectives of the company are translated into a portfolio of information systems required by the company.

Organisational feasibility

reviews how well the solution meets the needs of the business and anticipates problems such as hostility to the system if insufficient training occurs. (Considers the effect of change, given a company’s culture and politics.)

Feasibility type Scope Question answered technique used to control

Organisational Alignment of the system with organisational needs. Impact of system on organisational practice.

Will the system meet the business’s needs and help improve its performance?

Critical success factors and key performance indicators. Change management.

Economic Evaluation of the relative costs and benefits of the new system.

Will the costs outweigh the benefits?

Cost–benefit analysis. Return-on-investment and payback calculations.

Technical Evaluation of possible technical problems and their solutions.

Will the system work efficiently?

Risk analysis. Capacity planning. Performance and availability modelling.

Operational Evaluation of likely response to system by its users and management.

Will the system be accepted by end-users into their day-to-day work?

Risk analysis. Change man agement. Usability analysis.

Table 8.1 A summary of the different aspects of a feasibility study

M08_BOCI6455_05_SE_C08.indd 297 10/13/14 2:41 PM

Part 2 business information systems development298

An IT governance model for alignment of benefits with business needs

An example of an IT industry initiative to help deliver better alignment of IS with business needs is COBIT. COBIT is the widely adopted IT governance model for Control Objectives for Information and related Technology. More information on IT governance and COBIT is provided later (in Chapter 14).

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. Key performance indicators (KPIs) are then used to set targets for CSFs and assess whether these have been achieved. COBIT defines KPIs as ‘the lead indicators that define measures of how well the IT process is performing in enabling the goal to be reached’. COBIT uses a three-level method of integrating CSFs and KPIs. An example of this approach is illustrated by Reicheld and Schefter (2000). They reported that Dell Computer has created a customer experience council that has researched key loyalty drivers or CSFs which determine whether customers will be retained by Dell as repeat customers. The business objectives and corresponding CSFs and KPIs are shown in Table 8.2.

BIS play a significant role in achieving CSFs since:

1. BIS are required indirectly to collect KPI data and report them throughout the organisation, so corrective action can be taken when targets are not achieved.

2. BIS may be used to directly achieve the CSFs.

Critical success factors (CSFs)

a performance measure which must be achieved in order for business objectives to be met.

Suggest how Dell Computer may use BIS to:

(a) collect and report the CSFs and KPIs in Table 8.2;

(b) achieve the business objectives and KPIs in Table 8.2.

Critical success factorsActivity 8.2

Business objective Critical success factor KPI

1 Improve order fulfilment Ship to target Percentage of systems that ship on time exactly as the customer specified

2 Increase product performance

Initial field incident rate Frequency of problems experienced by customers

3 Enhance post-sale service On-time, first-time fix Percentage of problems fixed on the first visit by a service representative who arrives at the time promised

Table 8.2 Relationship between loyalty drivers and measures to assess their success at Dell Computer

After identification of CSFs during initiation, development of a system should be targeted specifically at meeting KPIs at all SDLC phases. For example, the analysis stage will question which functionality, data inputs and outputs the system requires to meet these objectives. The testing stage will involve benefits-based testing to check that the system has the features to deliver the intended benefits.

The impact of the system on the organisation

Organisational feasibility will also involve a review of how the potential users’ skill sets and attitudes will affect the system. Problems may include resistance to change from end-users,

IT governance

management of the processes to direct and control the enterprise use of it in order to achieve the enterprise’s goals by adding value while balancing risk versus return over it and its processes.

M08_BOCI6455_05_SE_C08.indd 298 10/13/14 2:41 PM

299ChaPter 8 initiating systems development

particularly those who don’t have experience of using computer systems. If resistance to change from staff is anticipated, then steps should be taken to ensure that this does not happen. Such measures include training and educating staff by explaining why the system is being introduced (Chapter 12). If potential users are not familiar with using computers, then training must occur.

Organisational feasibility is a particularly important consideration for large-scale systems that will be deployed across an organisation. Examples are e-business and enterprise resource planning systems that substantially change working practices through re-engineering business processes. In these cases, the new system may affect the balance of power of different functional parts of the organisation. These implications should also be included as part of the organisational feasibility assessment. A new system may well also affect the communication channels and control mechanisms within an organisation and any detrimental effects on these should be established. Approaches to managing change associated with large systems is discussed further later in the chapter.

Economic feasibility

an assessment of the costs and benefits of different solutions to select that which gives the best value. (Will the new system cost more than the expected benefits?)

Economic feasibility

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 (see coverage of portfolio analysis in Chapter 13 for further details). We will start by looking at different methods for assessing costs and benefits and then go on to look at how critical success factors and KPIs are devised during initiation as part of benefit identification to help align the outcomes of the project with business needs.

Assessing costs and benefits

Assessing costs and benefits of IS is not an exact science. A fundamental problem is that it is not easy to measure each benefit and cost accurately. Even where the benefits and costs are quantifiable, the figures used are only based on an estimate predicting several years into the future. This section outlines how cost–benefit analysis occurs at the start of a project to implement a new BIS.

All feasibility assessments for information systems development should include a cost– benefit analysis. Although this may seem obvious, some companies miss out this stage because other factors are driving the development such as the need to counter a competitor threat or respond to customer demand. The creation of e-commerce systems by banks is an example of this – here the cost of setup and maintenance may be greater than the revenue achieved through increased sales. The marketing manager may, however, want to proceed with such a strategic initiative to gain first-mover advantage as explained above and to gain experience aimed at ensuring success in the future when this form of channel becomes more widely used.

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. It is not possible to place a numeric value on intangible costs and benefits. Note that for some factors it may be difficult to establish whether the benefit is tangible or intangible. For example, although it is difficult to measure the benefit of general improvements in data quality, it would be possible to measure specific aspects of quality such as the time the new system takes to deliver information to the users.

Tangible costs are a measure of cost that can be calculated for each item of expenditure on BIS. For example, the purchase price of new hardware needed to run new software is a tangible cost. A monetary value cannot be placed on an intangible cost: 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.

Tangible costs

a measure of cost can be calculated for each tangible cost. Intangible costs

a monetary value cannot be placed on an intangible cost.

Tangible benefits

a definite measure of improvement can be calculated for each tangible benefit.

Intangible benefits

it is not possible to measure intangible benefits.

M08_BOCI6455_05_SE_C08.indd 299 10/13/14 2:41 PM

Part 2 business information systems development300

A definite measure of improvement can be calculated for each tangible benefit. A reduction in cost per transaction system is an example of a tangible benefit for an online bank. It is not possible to measure an intangible benefit. For example, the improved decision-making capability provided by a decision support system would be difficult to cost.

Assessing costs

A range of costs must be included in the feasibility study. These include:

■ hardware and software purchase costs; ■ systems development staff costs if a bespoke or tailored solution is chosen; ■ installation costs including cabling, physically moving equipment and bringing in new

furniture to house the computers; ■ migration costs such as transferring data from an existing system to the new system or

running the new and original systems in parallel until the reliability of the new system is established;

■ operating costs including maintenance costs of hardware such as replacing parts or upgrading to new versions of software. Staff costs in maintaining the hardware and software and trouble-shooting any problems must also be factored in. Operating costs may also include an environmental audit of the amount of energy and consumables used;

■ training costs; ■ wider organisational costs, for example redundancy payments, may need to be made if

computerisation leads to loss of jobs.

Note that these costs include not only the initial cost of purchase, but also the ongoing maintenance costs. These are considerable for information systems and will often exceed the initial cost of purchase.

It is worth noting that there is a growing realisation that the cost of ownership of a software or hardware product is potentially much higher than the purchase cost. This is mainly due to the cost of trouble-shooting software bugs and hardware faults, phone support, installing upgrades and paying for support and/or upgrades from the vendor. The cost of ownership of the selected software and hardware combination should obviously also be factored into your cost–benefit analysis. The cost of training and education and documentation of staff should also be included with standard development costs of paying analysts and programmers.

The following are examples of costs and benefits:

Typical BIS costs and benefitsActivity 8.3

■ software purchase cost; ■ user resistance; ■ reduction in working hours; ■ improved decision making; ■ hardware purchase cost; ■ new working practices; ■ sales increase; ■ broader planning horizons; ■ implementation costs; ■ disruption during implementation;

■ training costs; ■ reduction in customer complaints; ■ better data integration; ■ reduction in maintenance costs; ■ better data quality; ■ hardware and software maintenance and

consumable costs; ■ reduction in inventory levels; ■ better cashflow.

M08_BOCI6455_05_SE_C08.indd 300 10/13/14 2:41 PM

301ChaPter 8 initiating systems development

Assess where they should be in the grid below:

Costs Benefits

tangible Intangible tangible Intangible

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. Benefits from a new system can be considered in terms of improvements to business processes and the quality of information used to support these processes. Common benefits include reduced costs of operating processes and greater efficiency leading to faster completion of tasks such as serving a customer.

Parker and Benson (1988) recommend a structured approach to identifying tangible benefits. This involves considering the cost of performing a business process before introduction of a new system and comparing this to the cost after implementation. Costs may include staff time, materials and equipment. This result will indicate either a tangible benefit through cost reduction or an added cost of using the new system.

Intangible benefits will include improvements to the quality of information, as described earlier (in Chapter 1). A new information system should enable information quality to be improved in some of the following ways:

■ improved accuracy; ■ improved availability and timeliness; ■ improved usability (easier to understand and then act on information); ■ improved utilisation; ■ improved security of information.

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. Some tasks may only be conducted using a human operator. The types of questions asked are:

■ Can the system deliver the performance required? For example, an online banking solution may be required to deliver thousands of transactions a second.

■ 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? Service-level agreements (SLAs) with the hosting provider are usually used to control this.

Technical feasibility

evaluates to what degree the proposed solutions will work as required and whether the right people and tools are available to implement the solution. (Will it work?)

M08_BOCI6455_05_SE_C08.indd 301 10/13/14 2:41 PM

Part 2 business information systems development302

■ Does the system deliver the necessary level of security? ■ Will there be data integration or data quality problems? Complex systems can fail due

to the difficult of transferring data between different systems. Data quality needs to be managed in order for a system to deliver satisfactory outputs to end-users. This problem is best illustrated by the IT industry expression: ‘garbage in, garbage out’.

■ Can the system support the type of decision making required (particularly support for semi-structured or unstructured decisions)?

A technical feasibility assessment will aim to determine whether the proposed solution will work at all. In some cases, such as for an accounting system, there will be an obvious product that will fulfil the outline requirements. In others, such as for a specialised manufacturing facility, a fairly detailed analysis of requirements and a high-level design of the system may be necessary to assess alternatives before it is possible to decide on the feasibility. If this is the case then the initiation stage will be protracted and costly.

For simple applications, most problems will be technically feasible, the important question is ‘How much will the solution cost?’ Some solutions may be possible, but will require expensive hardware, software or development staff. So technical feasibility needs to be conducted before economic feasibility to assess these costs. Furthermore, to achieve technical feasibility is dependent on a sound approach to risk management which is described in more detail later in this chapter.

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, detailed estimates will be made of whether the system usability and response times are sufficient for the expected volume of customer transactions. With a customer-facing system such as the online banking solution, operational feasibility is very important since a difficult-to-use system will lead to customer use of the system lapsing after the first trial. For this reason, banks employ usability companies such as the Usability Company (www.theusabilitycompany.com) 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 organisational feasibility, and they are sometimes considered together.

Operational feasibility

an assessment of how the new system will affect the daily working practices within the organisation. (is the system workable on a day-to-day basis?)

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 organisational feasibility.

Baccarini, Salm and Love (2004) have produced an excellent analysis of the management of risks in information technology projects. They point out that existing literature identifies 27 common IT risks, grouped into seven broad categories. The impacts of these risk factors will differ, depending on the nature of the system being developed.

1. Commercial and legal relationships. These can include 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 at the start of the project that may result in competitors taking advantage through copying, resulting in high litigation cost and loss of market potential; friction between clients and contractors where misunderstandings, unanticipated changes in the scope of the contract, missed or delayed delivery, or some other item of dispute may split clients and contractors into opposing camps.

Risk management

aims to anticipate the future risks of an information systems project and to put in place measures to counter or eliminate these risks.

M08_BOCI6455_05_SE_C08.indd 302 10/13/14 2:41 PM

303ChaPter 8 initiating systems development

2. Economic circumstances. Factors here can include changing market conditions where the business return on investment in IT can be eroded owing to changing consumer market conditions or advancements in software engineering (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 behaviour. Here, personnel shortfalls where work cannot be completed owing to insufficient staff and poor quality staff through lack of ability, training, motivation and experience of staff can be significant factors which can also have implications that extend to hardware, operating systems and database management systems selection as well as to other software.

4. Political circumstances. Unfortunately, political factors in the software acquisition process can play a significant role in the decision-making process. Aspects of this that are relevant here include situations where the corporate culture is not supportive of the project owing to hidden agendas, factions within the organisation, organisational 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 – this can also lead to users not supporting the project if they perceive that there is a lack of top-level management sponsorship; politically motivated collection of unrelated requirements where a number of unrelated requirements are grouped in an all-encompassing project which becomes difficult to manage and make it meet its objectives.

5. Technology and technical issues. Again there are a number of risks that can occur from problems and errors within the software acquisition process. These can include: inadequate user documentation, meaning that users are unable to fully utilise the new information system as intended; application software perceived as not being fit for purpose because users believe that the software provided does not directly help them with completing day-to-day tasks, thus leading to low user satisfaction; poor production system performance due to the selected software architecture/platform not meeting the purpose for which it was intended, resulting in a system being released into production which is excessively slow or has major operational problems; technical limitations of the software solution are reached or exceeded during the development process resulting in time delays to the project while a work-around solution (if available) is determined – if a solution cannot be found the project will either be cancelled or restarted with a more viable technical solution; incomplete requirements where insufficient information has been obtained in the analysis phase, resulting in construction of a solution that does not meet project objectives; inappropriate user interface which fails to meet user requirements and expectations.

6. Management activities and controls. Over and above the political factors indicated above, there is a range of management factors that can significantly increase the risk of project failure. These include: an unreasonable project schedule and budget where the project is unable to realise its objectives owing to unrealistic restrictions placed on the project’s budget, schedule, quality or level of performance; continuous changes to the requirements by a client can result in project delays unless a software development methodology such as DSDM or RUP is used where the change process is explicitly built in to the method; lack of agreed-to user acceptance testing and sign-off criteria where the project sign-off can be delayed owing to an unclear understanding of what constitutes final sign-off and solution delivery; failure to review daily progress, resulting in project slippage; lack of a single point of responsibility for project deliverables, resulting in the project’s failing to meet its objectives; poor leadership where the project manager and/ or steering committee is not committed to solving problems and providing direction to

M08_BOCI6455_05_SE_C08.indd 303 10/13/14 2:41 PM

Part 2 business information systems development304

the project team; developing the wrong software functionality as a consequence of poor analysis, design or construction; lack of a formal change management process meaning that project progress is hindered owing to ad hoc changes to system specification without a formal review of technical and project impact.

7. Individual activities. There are two factors here of note: over-specification where the project team is focused on analysing 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.

In summary, risk assessment will involve balancing the risks and costs likely to be incurred against the anticipated business benefits. As mentioned in Chapter 7, some approaches to software development such as DSDM or RUP are better at addressing some of the problems identified here. However, even the best methodology cannot compensate for poor management decisions and inadequate project control.

The role of computers in facilitating and compounding current economic turmoil has gone largely unmentioned (with one notable exception being a Digital Business article, ‘The dog that bit its master’, in March 2008).

Without computers, the extraordinary speed and volume of highly complex financial instruments and transactions would have been impossible. The combination of supercomputer-class hardware, complex software and mathematics led to mission-critical strategic trading systems that hardly anyone could understand.

The irony is that until everything fell apart, these systems and experts were seen as the crown jewels of investment banking and trading operations.

Financial institutions accepted unprecedented degrees of leverage in part because their computer models said it was OK. As these models initially seemed to work as advertised, too many executives eagerly bought into the absurd idea that, through the clever use of technology, one could all but eliminate investment risk, ignoring whatever warnings their internal experts may have raised.

When this wishful thinking inevitably imploded, these same systems also proved to be very difficult to turn off and unravel.

Are there lessons here for the rest of us? The financial services industry is not the only sector where system complexity is beginning to boggle or even overwhelm the human mind.

Think how many businesses today rely on complex, computer-based pricing, scoring, logistics, routing, occupancy, and simulation algorithms. Or how many sectors, such as nanotechnology, biotechnology, and robotics are being driven by scientists whose models

say that everything is OK (or, in the case of climate change, not OK). Or how many critical infrastructure systems such as the electrical grid, the internet, and much of the telecommunications system lack clear mechanisms of human governance and control.

We are now well into the early years of a phase that science fiction writers have imagined for decades, where more and more essential societal systems are controlled by machines whose complex workings no one person can fully understand, and which can be very difficult to repair, replace or even terminate should an unexpected crisis occur.

Where all this will lead is impossible to say, but we aren’t far from a world where we will struggle to fly an aero- plane, conduct a transaction, design a product, or defend our countries without complex computer mediation.

While this sort of automation has many potential, even essential, advantages, it also creates new kinds of risks.

Our CIO clients typically say that, while all of this seems true and interesting, it isn’t really their problem to solve. The traditional view of information technol- ogy risk has been a relatively narrow one: to make sure that systems are secure, available, and running as designed – challenges that are plenty tough already.

The actual purpose of a given system has, understandably, been seen mostly as a business issue. This attitude results in the curious fact that, from a traditional information systems perspective, the very computer systems that helped bring down the world economy were essentially operating as planned.

This begs the question as to who should be responsible. Most senior business executives lack the specialised

Recession reveals the dark side of advanced IT By David Moschella

CASE STUDY 8.1

M08_BOCI6455_05_SE_C08.indd 304 10/13/14 2:41 PM

305ChaPter 8 initiating systems development

knowledge needed fully to understand advanced business/IT applications.

But as we have seen, scientists and mathematicians often struggle to find the balance between the upside and downside of their work, especially in the middle of powerful political, career and financial pressures.

The result is today’s unstable situation where much of our economy’s most valuable intellectual property and most important infrastructure tends to lie outside the bounds of traditional business and IT risk assessment.

What to do? Barring radical societal changes, computer dependency will only rise over time.

Our research focuses on the implications of business/ IT co-evolution, the idea that business and IT change are becoming inseparable and will increasingly require integrated management processes.

Looking ahead, we will need to think of risk management within a co-evolutionary framework that

encompasses both the still serious risks of traditional IT, and the new risks that come with complex business automation and control.

We need to come to grips with the fact that deterministic computer systems tend to generate surprising feedback loops, ‘irrational’ human behaviour, and all sorts of important, but unintended consequences.

This more expansive, co-evolving view of business/IT risk management is emerging as an exciting new field, with leadership opportunities for academics, business people and IT professionals alike.

The integration of business and IT will surely create fantastic opportunities for many years, but it will also create many new challenges and even dangers. For the IT industry, the lesson of the global financial crisis is clear: we need to control complex computer systems, lest they increasingly control us.

David Moschella is global research director for CSC’s Leading Edge Forum

This activity is based on Case Study 7.3 where acquisition alternatives were considered for this company.

Produce a feasibility analysis of the alternative methods of acquiring application software as they relate to LFFL. You should pay particular attention to the operational, organisational, economic and technical feasibility of each one. You should conclude with a recommendation on how LFFL should best proceed to the next phase of the information systems acquisition process.

1. Identify risks, including their probabilities and impacts.

2. Identify possible solutions to these risks.

3. Implement the solutions, targeting the highest-impact, most-likely risks.

A feasibility analysis for Lascelles Fine FoodsActivity 8.4

ACQUISITION CHOICES AND METHODS

Part of the feasibility stage is to decide on the method of acquisition. This will usually occur after the need and requirements for the system have been established. The make-or-buy decision will occur, and different suppliers of either off-the-shelf or bespoke solutions will be evaluated (as has been described in Chapter 7). 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 (Chapter 14). This is usually a strategic initiative which involves the outsourcing company in developing more than one system.

QUESTION

What lessons does the case study have for the initiation of an IT project in the organisation?

M08_BOCI6455_05_SE_C08.indd 305 10/13/14 2:41 PM

Part 2 business information systems development306

Example request for proposals for a BIS Executive summary (two pages) – includes company description, acquisition mission statement, ROI requirement, preferred technology strategy, acquisition timing.

Administrative information (three pages) – includes procurement timeline, short- list requirements, proposal submission preparation guidelines, evaluation criteria checklist.

Business case (six pages) – includes business benefit, description of current operations, expectations, critical success factors.

Technical case (fifteen pages) – this section acts as an acceptance list for the buyer. Includes overview of current IS operations, expectations for the new IS operations, system functional specs, expected system response time, document management requirements, integration requirements, exception handling, hardware requirements, software requirements, mass storage specifications.

Management (three pages) – can be reserved for short-list vendors to complete. Includes system acceptance criteria, project management plan, site preparation plan, training plan and schedule, delivery and installation plan and schedule, systems maintenance plan, documentation (description and pricing), qualification and experience (number of installations etc.), customer references, financial report.

Agreement (one page) – asks for vendor’s pricing breakdown, itemised by definitions, so you can easily compare vendor to vendor.

Request for proposals (RFP)

a specification drawn up to assist in selecting the supplier and software.

TECHNIQUES FOR COMPARING SYSTEMSFOCUS ON…

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.

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 and useful tool. The case study shows a typical checklist, which might be available in a magazine such as PC Magazine (www.zdnet.com), comparing three off-the-shelf software products.

If we decide to go ahead after the initial feasibility study, the next stage for a major implementation for a large organisation 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. An example structure of an RFP is shown in the box. The purchaser will fill in the first four sections and different vendors will fill in the last two sections. For a smaller company or system, alternative suppliers will also need to be assessed, but the effort spent on selection will be scaled down.

Summarising system requirements

M08_BOCI6455_05_SE_C08.indd 306 10/13/14 2:41 PM

307ChaPter 8 initiating systems development

Feature checklist – detailed ranking

The main deficiency of simple checklists is that they do not attach relative importance to features. To extend them, give each feature a weighting of, say, between 0 and 100 points for each factor and then add up the scores for the different products. Activity 8.6 shows a detailed analysis using a range of factors to decide on which supplier to use.

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. These can be quite costly for both purchaser and supplier. First, it is possible to benchmark against other organisations 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. Table 8.3 gives such scenarios for using a business intelligence product such as Cognos (www.cognos.com) introduced in Chapter 4. Often a comparison will not be meaningful unless a company’s own data or processes are used as a basis for this scenario.

Function to test Scenario

1 Administration: add new user How readily can a new user be added to the system or their personal details changed? How easy is it to set up the client (end-user) PC?

2 Compare actual against forecast sales

How easily can a user review the variance between actual and forecast sales and their trend through time?

3 Drill-down on a problem If sales are down for one product line, how easy is it to identify the cause of that problem?

4 Export data How easy is it to export part of the data for further analysis into a spreadsheet?

5 Configure data views How easily can charts be customised to show a new KPI?

Table 8.3 Five example scenarios for selecting a business intelligence system

Three products are compared according to:

■ features provided; ■ operating systems supported for the server platform; ■ operating systems supported for the client (end) user.

These systems are compared using Table 8.4. Price for different options could also be shown in a table such as this, together with more detailed features, such as, does the e-mail have an address book for the whole company and does it support file attachments?

Feature checklist for comparing three different groupware productsMini case study

➨

M08_BOCI6455_05_SE_C08.indd 307 10/13/14 2:41 PM

Part 2 business information systems development308

Table 8.4 Feature comparison for three groupware products

Criteria Product a Product B Product C

Server platforms

Windows XP Professional Yes Yes Yes

Novell Netware Yes No Yes

Linux Yes No No

Client platforms

Windows XP Yes Yes Yes

MacOS X Yes No Yes

Features

E-mail Yes Yes Yes

Scheduling Yes No Yes

Document management Yes No Yes

Internet access Yes No Yes

From inspection of the table, it can be seen that Product A and Product C fulfil most of the criteria. Product B would be unsuitable for a company that had a range of existing com- puters running different operating systems. Since Products A and B are similar and cannot be distinguished using this table, a more detailed evaluation of these two could then occur after excluding Product B. A different example of a more detailed evaluation for a business system is described below.

Table 8.5 shows an analysis for three products from different suppliers that were compared across many factors to establish which was most suitable. This type of detailed analysis is usually conducted when a new system costs tens or hundreds of thousands of pounds. The grand total shows that Supplier 3 is the clear winner.

Table 8.5 Detailed weighted analysis for ERP software

Decision criteria Weighting factor

Supplier 1 score

Supplier 2 score

Supplier 3 score

a. General functionality

Receive information 70 60 60 60

Verify cut quantity 70 30 40 80

Schedule operations 80 56 56 56

Monitor schedule execution 80 40 40 68

Verify shop data input 80 64 64 64

Verify parts loss reporting 70 28 56 56

Detect labour variances? 60 30 36 42

Provide real-time status 60 24 19 43

Provide capacity planning? 70 56 40 50

Calculate incentive pay 70 30 25 35

Provide needed flexibility 80 65 50 55

Detailed weighted analysis of an ERP software decisionActivity 8.5

M08_BOCI6455_05_SE_C08.indd 308 10/13/14 2:41 PM

309ChaPter 8 initiating systems development

Decision criteria Weighting factor

Supplier 1 score

Supplier 2 score

Supplier 3 score

Verify inventory data entry 60 42 42 42

Provide operation history 60 32 40 42

Provide security 90 30 36 36

a. Subtotal 1000 587 604 729

B. technical considerations

System reliability 100 56 56 56

Compatibility with other systems 100 56 56 56

Cross-module integration 100 45 70 65

Implementation time 100 45 70 65

Ease of customisation 100 60 48 56

B. Subtotal 500 262 300 298

C. Other considerations

Cost 60 36 48 54

Service and support 90 45 50 57

Vendor vision 25 25 40

Confidence in supplier 80 35 45 65

C. Subtotal 300 141 168 216

Grand total 1800 990 1072 1243

QUESTION

1. Review the different categories and the criteria within them. Do you think that the weighting factors are valid? Are there other factors that might apply for ERP software?

2. Look in detail at the values for each product. Comment on the basis for deciding on individual scores.

3. Given possible deficiencies in 1 and 2 above, comment on the suitability of this technique for making a decision. Would you use it and why? What would you do differently?

Which factors should be used when selecting systems?

When comparing software, cost is an obvious constraint on any purchase, but since this is often a fixed constraint, it is often best to evaluate software on other factors to narrow the choice and then decide finally on cost where contenders are similar in other respects. Eight important factors in deciding on systems are shown in the box. Note though, that from an internal perspective, an organisation needs to consider the skills base within the organisation to manage the application – this may exclude some functionally superior solutions for example. Complete Activity 8.6 to see how these factors can be applied in practice.

Eight 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.

Functionality

a term used to describe whether software has the features necessary to support the business requirements. ➨

M08_BOCI6455_05_SE_C08.indd 309 10/13/14 2:41 PM

Part 2 business information systems development310

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. 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.

6. 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).

7. Prospects for long-term support of product. If the vendor company is small or likely to be taken over by a predator, will the product exist in three years’ time? Is the company responsive in issuing patches and new features for the product? Is the company forming strategic alliances with other key vendors which will improve the product’s features and interoperability?

8. Extensibility. Will the product grow? Are the features available to accommodate your future needs? Are the features available in the initial purchase or will you have to integrate with software from another vendor? As a rule of thumb, it is best if you can single-source software, or use as few vendors as possible: the system will have greater reliability than making different modules interoperate.

Compatibility

software compatibility defines whether one type of software will work with another. for example, will a word processor run Windows 3.1 or Windows 95? data compatibility defines whether data can be exported from one package and imported for use into another. for example, can a word- processor file from one package be used in another?

Interoperability

a general term used to describe how easily different components of a system can be integrated.

Referring to the eight key factors for selecting software, discuss in a group, the order of importance of these factors for each of these different types of business information system:

■ an accounting system; ■ a system controlling a production line; ■ a system for booking customers on to coach trips; ■ a system to support investment in company shares; ■ an HR management system.

Create a table comparing the different factors for each system. Explain similarities and differences.

Comparing selection factors for different systemsActivity 8.6

Some businesses make the mistake of limiting an assessment of new software to its technical merits or features. This is unwise, since software purchase is a long-term commitment and a company is reliant on the support provided by the vendor. 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.

Assessing products from different suppliers

Contract negotiation

An appropriate contract is vital when outsourcing to a third-party systems development or any information systems function. This may include custom or bespoke software, amendments to off-the-shelf software and outsourcing or facilities management (FM). In

M08_BOCI6455_05_SE_C08.indd 310 10/13/14 2:41 PM

311ChaPter 8 initiating systems development

essence, contracts define which activities should happen and when, and who is responsible for them. For example, the supplier should deliver Prototype 1 by 1 October, and review should be completed by 28 November. Both the customer and the suppliers benefit from a reduced risk of failure.

The value of having a well-defined contract is illustrated by failures that have occurred when they are not in place. For example, in the mid-1990s, the UK police terminated a fingerprint system development after two years in development, claiming £10 million in costs. The supplier, IBM, then counter-claimed £19 million on the basis of the client not having made their requirements clear. A protracted legal battle followed before agreement was reached.

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.

Contracts are particularly difficult to establish for information systems projects for the following reasons:

■ It is difficult to specify the requirements in detail at the outset of the project when the contract is signed. Varying functional requirements can lead to project overruns.

■ 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 and a support contract is required to ensure that they are remedied rapidly.

■ If a supplier’s business fails, the system may be unmaintainable without the software program, which may need to be put into safe keeping with a third party in a source code escrow agreement.

Contents of a typical IS product contract

A typical contract will be made up of the following sections or schedules, as well as general clauses on confidentiality, intellectual property (who owns the rights to the software), indemnity, law and jurisdiction.

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

M08_BOCI6455_05_SE_C08.indd 311 10/13/14 2:41 PM

Part 2 business information systems development312

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 incentives if it delivers early.

Sedgemoor District Council is improving the availability of information online to enhance customer service, increase the efficiency of accessing information and reduce data management costs. The council is now in a position to remove its planning department’s legacy data management system (DMS), as it has completed migrating information to its electronic document and records management (EDRM) system, Trim Context from Tower Software.

Craig Wilkins, information systems manager at Sedgemoor District Council, says archived material for planning stretches from 1974 to 1995. ‘It was in a proprietary DMS but it has been migrated to our EDRM system and been made available to the public online’, he says.

‘Dropping the DMS means we can improve efficiency and save about £7,000 annually on maintenance and server hardware. Making planning documents available online has also reduced the number of phone calls to the council.’

The aim is to replace paper-based systems and integrate all systems with the EDRM software to centralise the storage and management of all documents, and to remove legacy DMS applications. ‘We now have a million records in the EDRM system out of 7.5 million documents. We have a variety of systems covering 14 different business areas and EDRM will underpin them all to attain availability of information accurately’, says Wilkins.

Sedgemoor District Council Quick availability of information increases efficiency and reduces costs

CASE STUDY 8.2

M08_BOCI6455_05_SE_C08.indd 312 10/13/14 2:41 PM

313ChaPter 8 initiating systems development

local and central government. Other benefits include making council reports, agendas and minutes available online – and using Goss software in conjunction with EDRM to ensure the correct document versions are published online in each service area. The ultimate goal is for the EDRM system to make information readily available to support customer services through all access channels – the internet, face to face and by telephone, says Wilkins.

Source: Lisa Kelly, Computing, 11 October 2007, www.computing.co.uk/ computing/analysis/2200923/case-study-sedgemoor-district

‘New documents go into the repository as well as archived data being migrated. We can scan documents into EDRM and recycle paper documents, reducing storage costs. We also aim to specify retention policies for data to improve information lifecycle management.’

The council has started to fully integrate its Goss iCM content management system with its EDRM software to assist in making data available via its web site.

As volumes of data multiply, the council has also installed a storage area network to support EDRM. ‘We are scanning documents into the EDRM system and populating the back-office systems with metadata. We are having to key in metadata manually but the aim is to automate this process, perhaps through a barcode system, although there is a question over how much metadata a barcode can contain’, says Wilkins.

Recently the council received confirmation that it is likely to be one of the first local authorities to comply with the Code of Connection requirements for connecting onto GCSx, part of the Government Connect programme to provide a common infrastructure for secure electronic transactions between

QUESTIONS

1. Given the intangible nature of some of the benefits from the new information systems, how might the council have gone about making the investment decision?

2. Analyse the initiation part of the project in terms of the internal and external factors driving the systems acquisition process.

Stage summary: initiation

Purpose: Determine viability of systems and technique used to acquire it

Key activities: Feasibility study

Input: Idea for new system or problem with existing system

Output: Feasibility study, recommendation to proceed

The key characteristics and success factors for the initiation stage of systems development are as follows:

1. The initiation phase is the first stage of the system development lifecycle.

2. The initiation phase is generally considered to consist of two main activities: the generation of the idea for a new system and assessing the feasibility of introducing a new system. Feasibility assessment should occur for all projects, whatever the acquisition method.

3. Feasibility assessment will involve comparing different alternatives in terms of their:

■ economic feasibility – the cost–benefit analysis; ■ technical feasibility – evaluation of the merits of different alternatives in terms of practicality; ■ operational feasibility – will the system meet the needs of the business and end-users? ■ organisational feasibility – do the staff have the skills to use the system and how will their attitudes

affect the acceptance of the system?

4. There is a range of financial measures for assessing the financial viability of a new system. These should take into account the time-varying nature of costs and benefits by using discounted cashflow techniques. Non-financial measures should not be neglected.

5. A contract for the supply of the system should be negotiated at the outset; this minimises the risk of project failure and provides adequate support for when the system becomes operational.

SUMMARY

M08_BOCI6455_05_SE_C08.indd 313 10/13/14 2:41 PM

314 Part 2 business information systems development

1. What is the purpose of the initiation phase of a project?

2. What is meant by the terms ‘intangible’ and ‘tangible benefit’?

3. Identify each of the following as tangible or intangible benefits or costs:

(a) purchase of a server for data storage with a new information system; (b) reduced waiting time for customers when querying the progress of an order; (c) disruption caused by installation of a new company network; (d) reduced inventory holding period resulting from a new stock management system.

4. Summarise the differences between economic, operational, technical and organisational feasibility.

5. What do you understand by the term ‘risk assessment’ and how can it be applied to assist an information systems development project?

6. What is the purpose and outline contents of a ‘request for proposal’ or ‘invitation to tender’ document?

7. What are the key factors that a company will consider when choosing software from different suppliers?

8. What are the main items that should be specified in an information systems contract?

EXERCISES

Self-assessment exercises

Discussion questions

1. To what extent is the failure of many information system projects a consequence of too little time being spent on the initiation stage?

2. ‘The techniques that are available for comparing different software packages or systems from different suppliers must be applied rigorously.’ Discuss.

Essay questions

1. Examine the main consequences for an information systems project if the initiation stage is omitted.

2. A company is intending to purchase accounting software for 100 staff and is considering three different packages. It is currently using a Microsoft Windows 2000-based application, but wants to move to using a Microsoft Windows XP Professional-based application. Give a full account of the factors it should consider when making the comparison. Which do you consider are the most important factors?

3. Risk assessment is a valuable tool for the project manager. What does this technique involve and which future risks might be identified at different stages in a systems development project?

4. Write a short feasibility or initiation report for a new e-commerce site or an enhancement to an existing site incorporating the elements of initiation referred to in this chapter. It can refer to a fictitious company, a small company you are familiar with, or a larger company whose sites you can visit. Your answer should not be limited to exploring economic, operational, organisational and technical feasibility, but should include all the aspects of initiation planning covered in this chapter.

M08_BOCI6455_05_SE_C08.indd 314 10/13/14 2:41 PM

315ChaPter 8 initiating systems development

Examination questions

1. What is the purpose of establishing the following types of feasibility:

(a) operational; (b) organisational; (c) technical; (d) economic.

2. Give three reasons for a company’s initiating an information systems project. Give a brief example of each.

3. Define information systems outsourcing.

4. Give examples of two tangible costs and two intangible costs that may be incurred during an information systems development project.

5. What are the most important factors you would consider when comparing alternative software packages?

References

Baccarini, D., Salm, G. and Love, P.E.D. (2004) ‘management of risks in information technology projects’, Industrial Management and Data Systems, 104, 4, 286–95

Carr, N. (2003) ‘it doesn’t matter’, Harvard Business Review, may, 5–12

Parker, M. and Benson, R. (1988) Information Economics: Linking Business Performance to Information Technology, prentice-Hall, englewood Cliffs, nJ

Reicheld, F. and Schefter, P. (2000) ‘e-loyalty: your secret weapon on the Web’, Harvard Business Review, July–august, 105–13