Course - DT249/1Course - DT249/1

Subject - Information Systems in Organisations

SELECTION AND ACQUISITION OF INFORMATION SYSTEMS

Semester 2, Week 6

2

Model Content TitleModel Content Title

From the course document, this week’s lecture refers to:

Selection and acquisition of Information Systems

3

Textbooks?Textbooks?The Laudon and Laudon book,

‘Management Information Systems’ (Seventh Edition) – Chapters 5, 6 and 7

Not the whole of each chapter!◦ Ch 5, Battling the Megadealers…

Management Challenges – also, the Summary◦ Ch 6, Renting Software on the Web…

Management Challenges – also, the Summary◦ Ch 7, Famous Footware… Management

Challenges – also, the Summary

4

Selection and AcquisitionSelection and AcquisitionSelection of Information Systems is a

managerial task when (or where) the hardware and software of a new Information System need to be decided upon. The task of ‘acquisition’ follows these decisions – it can be seen as the ‘buying in’ of hardware and software to match the choices made.

(There are other Information Systems features to be considered, such as training, but the hardware and software make up the greater part of the Information System.)

5

Selection and Acquisition Selection and Acquisition (2)(2)Selection of hardware and software can

be made in any order; you might choose hardware for particular reasons and choose software to ‘go with’ the hardware. Alternatively, (and perhaps more frequently,) you will choose the software and follow up by looking for hardware to suit it.

In either case, hardware is more often acquired ahead of software – so that you will have the machinery on which to test/run the software when it turns up!

6

Selection and Acquisition – Where Selection and Acquisition – Where They Fit InThey Fit In

Systems Investigation

Systems Analysis

Systems Design

Systems Implementation

Review & Maintenance

Feasibility Study

Project Selection

Using the Waterfall Life Cycle Model

Selection

Acquisition

7

A Sequence of EventsA Sequence of EventsFollowing a common practice of

defining hardware and software systems, then buying in the hardware on which to try out the software, these lecture notes will take the order of:◦Software selection◦Hardware selection◦Hardware acquisition◦Software acquisition

8

A Sequence of Events (2)A Sequence of Events (2)To keep track of slides, the Software

selection and Software acquisition slides will have headings beginning with (S/W)

Hardware selection, Hardware acquisition will have their slides marked with (H/W)

9

(S/W) Selecting Between (S/W) Selecting Between AlternativesAlternativesWhen choosing software for

applications:◦Select the criteria for making the

choice,◦Associate ‘weights’ with each criteria,◦Score acquisition alternatives in terms

of how they satisfy the criteria,◦Calculate the potential choices’ rating

by multiplying each score by the weight and then sum the total,

◦Select the one with the highest score.

10

(S/W) Selecting Between (S/W) Selecting Between Alternatives (2)Alternatives (2)Criteria for selection of systems or

software:◦List its ‘must-do’ features,◦ ‘should-do’ features◦ ‘nice-to-do’ features

Critical success factors for acquisition:◦Deciding who will manage the purchase,◦Knowing what to do,◦Knowing how to do it,◦Having time to do it.

11

(S/W) Selecting Between (S/W) Selecting Between Alternatives (3)Alternatives (3)Difficulties in the early part of software

selection:◦Developing a criteria list,◦Weighting the criteria list -

Especially in service areas.◦Developing benchmarks -

The methods chosen must be tailored to the actual use of a system.

12

(S/W) Criteria List(S/W) Criteria ListThe criteria define the set of

characteristics that the selection candidate software should have.

They enable the elimination of some alternatives at an early stage.

Examples of criteria;◦The cost consideration of Information

Systems elements (hardware, software…),

◦Maintenance and support (whether worthwhile, whether provided at all),

◦Quality of the supplier(s) (The vendors),◦Quality of their product(s).

13

(S/W) Weighted Selection (S/W) Weighted Selection ProcessProcessBenefits of applying a scoring method of

‘weighting’ software component solutions:◦ It brings objectivity to the selection

process.◦ It breaks down the complexity of

solutions into their constituent parts so that it becomes possible to compare solutions - This eases the comparison of simpler

solutions with those with more complexity.

14

(S/W) General Selection (S/W) General Selection GuidelinesGuidelinesThe desire to gain ‘hardware economy’ –

the idea of having the newest and the most sophisticated hardware - should not motivate selection.

Software, not hardware, should drive almost all Information Systems selection decisions.◦The organisational (business?) need is

generally to have an Information System made up of;System softwareHardwareApplication software

15

(S/W) General Selection (S/W) General Selection Guidelines (2)Guidelines (2)Software generally has a longer life than

the hardware on which it runs. Data has even greater longevity.

The Information System function should not be migrated to a new architecture without a very good reason - so compatibility with the current architecture should score highly.

If using software from more than one vendor, connecting components from one or more vendors is generally difficult. /… continued

16

(S/W) General Selection (S/W) General Selection Guidelines (3)Guidelines (3)Because of the view of hardware being the

first aspect of the new system to ‘wear out’, followed by software and, eventually, the data, the choice of architecture is important.

The architecture should allow for the inclusion of new hardware in 2 – 5 years, software in 2 – 7 years and the reformatting of data in 5, 10, 20… years. (Representing a fairly typical Information System in a medium-size organisation.)

/… continued

17

(S/W) General Selection (S/W) General Selection Guidelines (4)Guidelines (4)Connecting applications from different

vendors is usually technically feasible - whether it is desirable or not depends on a trade-off between benefits and complexity.

Information requirements can never be fully defined in advance, so the selected system or subsystems must be capable of adaptation and growth.

Avoid ‘pioneering’ with untested systems unless there is good business justification.

18

(S/W) General Selection Guidelines (S/W) General Selection Guidelines - Summary- SummaryDo not change without a reason.When change is needed:

◦Keep it simple.◦Go for compatibility with current

architecture, if at all possible.◦Go for flexibility.◦Work from the organisational problem,

through software and hardware options, to a solution.

◦Do not look for ways to choose the most elegant solution, irrespective of the problem.

Two OptionsTwo OptionsThere follows two options for selecting

software – though there are many;Standard packagesOutsourcing

Standard packages are software products that are available to buy immediately, since they are ‘off-the-shelf’.

Outsourcing, in the current context, is the idea of buying software or software services from a ‘third party’.

Issues with Standard Issues with Standard PackagesPackagesIf considering modification of a bought

standard package…◦Ownership could be retained by the vendor.◦Your changes may compromise your current

licence if your software is licenced.◦Changes may not be covered by technical

support.◦They may not be supported in upgrades.

Upgrade trap◦Where vendors only support most recent

versions of software. (A sales strategy on their part.)

21

Issues with Standard Issues with Standard Packages (2)Packages (2)Vendor lock-in

◦New systems may be difficult to replace in the future.

Training costs◦There may be a need to train in-house

staff to support and maintain the bought-in system.

22

(S/W) Outsourcing(S/W) OutsourcingOutsourcing is the term that describes

the purchase of systems development services from outside the organisation.

This often entails buying ‘off-the-shelf’ software – or software written specifically for the organisation (known as ‘bespoke’ software) and may also mean ‘buying in’ system analysis work that is often called ‘consultancy’.

23

(S/W) Outsourcing (2)(S/W) Outsourcing (2)Subcontracting all or parts of the IT

function to an external vendor as an alternative to relying solely on in-house resources or capabilities.

An organisation can create a strategic partnership between itself and the outsourcing vendor.

24

(S/W) Outsourcing (3)(S/W) Outsourcing (3)An organisation may outsource:

◦Data Centre Operations◦Hardware Support◦Systems Software Licensing◦Telecommunications◦Applications Software Maintenance

25

(S/W) Outsourcing (4)(S/W) Outsourcing (4)An organisation is likely to have;

◦limited amounts of capital for new technology investment,

◦ limited in-house capabilities to make a wise investment,

◦scarce or narrow IT expertise and/or◦ insufficient resources to adequately

support or enhance their existing IT activities.

26

(S/W) Outsourcing - (S/W) Outsourcing - ReasonsReasonsThe recruitment and retention of

experienced IT staff,

IT purchasing decisions,◦A need to make choices that will be

appropriate and beneficial both now and in the future.

Deciding to focus on core business activities, which often do not include IT systems or telecommunications.

27

(S/W) Outsourcing – Reasons (S/W) Outsourcing – Reasons (2)(2)When it is more efficient in terms of

cost/benefit to outsource IT for use in gaining competitive advantage.

Where there is a need to acquire new resources

As a reaction to ‘the bandwagon’ (keeping up with competitors)

To reduce uncertainty ‘in the field’To eliminate some troublesome functionTo enhance credibility of the organisation

or its products

28

(S/W) Outsourcing - (S/W) Outsourcing - BenefitsBenefitsReduces costs as a result of economies

of scale.◦Vendor consolidates activities for a

number of clients.◦The client avoids large capital investment.

Enables a strategic business focus.◦The organisation can concentrate efforts

on a manageable number of activities.◦ Improve financial predictability and

reduce uncertainty associated with IT.Facilitates technology ‘leapfrogging’ or

‘catch-up’.

29

(S/W) Outsourcing – Benefits (S/W) Outsourcing – Benefits (2)(2)Enables leveraging of IT expertise.

◦Internal IT staff to focus on higher priority activities.

◦ IT staff can give greater attention to key business issues.

It offers a way for an organisation to receive the benefits of the latest hardware and software - without making all the purchases themselves by, for example, leasing software.

30

(S/W) Outsourcing - (S/W) Outsourcing - ProblemsProblemsSome loss of strategic flexibility.Potential irreversibility if problems occur. Organisations choosing outsourcing without

negotiating a detailed contract may also encounter hidden costs or dramatic increases upon renewal.

The outsourced vendor often fails to support the organisation’s business needs.

Internal improvements could be neglected.Human Resources effects – the new

applications may not suit some employees.It may change the role of internal IT staff to

maintenance staff.

31

Hardware SelectionHardware SelectionHardware – evaluated with a view to

selection will have the following factors examined:◦Performance

Speed, capacity, throughput

◦Cost Lease or purchase price Cost of operations and maintenance

…/ continued

32

(H/W) Hardware Selection (H/W) Hardware Selection (2)(2)

◦Reliability Any risk of malfunction and

maintenance requirements will be identified

Error control and diagnostic features will be specified

◦Compatibility With existing hardware and software? With hardware and software provided

by alternative vendors?

…/ continued

33

(H/W) Hardware Selection (H/W) Hardware Selection (3)(3)

◦ ‘Future proof’? What is the speculated product life cycle? Does it use a new, untested technology? Does it run the risk of obsolescence?

◦Ergonomics Is the equipment “human factors

engineered”? Is the hardware user-friendly? Is the hardware safe, comfortable and

easy to use?…/ continued

34

(H/W) Hardware Selection (H/W) Hardware Selection (4)(4)

◦Connectivity Is the hardware easily connected to Wide

Area Networks and Local Area Networks that use different types of network technology and various bandwidth alternatives?

◦Scalability (Does the hardware fit with application tasks?) Can the hardware handle the processing

demands of end users, transactions, queries and other processing requirements?

…/ continued

35

(H/W) Hardware Selection (H/W) Hardware Selection (5)(5)

◦Software (The big question) Is the selected

system software and application software best suited this hardware?

◦Support Is support available for this hardware,

should equipment go wrong?

36

Hardware AcquisitionHardware AcquisitionWhen the hardware has been selected

there can be a process of hardware acquisition.

This is, on the surface, a straightforward task of buying the equipment specified in any Hardware Selection Report.

37

Hardware Acquisition (2)Hardware Acquisition (2)What makes hardware acquisition difficult

is the ‘policy for procurement’ that many organisations have.

This means that Management representatives meet with hardware vendors and ‘haggle’ over what is, ultimately, to be bought in and whether discounts and concessions might be applied.

The policy is a safeguard against buying unnecessary equipment or overspending when taxes and percentages can be ‘negotiated off’.

38

Hardware Acquisition (3)Hardware Acquisition (3)The hardware vendor will be asked to

enter into a contract of sorts – ensuring that the hardware order is complete and on time.

There may be more than one hardware vendor (supplier) for complex hardware systems or where there are, for example, ‘dedicated’ network systems that require specialised hardware manufacture.

(S/W) Software Acquisition(S/W) Software AcquisitionManagement responsibility for

acquisition:◦Senior management must recognise the

potential for gain in the acquisition of software.

◦Management should review and re-review the relationship between the organisation and Information Systems strategies during the acquisition process.

◦Management should assess the implications of any sensitive applications as part of the procurement process.

40

Acquisition of Software – Possible Acquisition of Software – Possible ProcessProcess

Software House

Interested ?

Package Available ?

Common System

Any Strategic Impact ?

Select a standard package

User Development

In-house IS Team Development

Yes Yes

Yes

Yes

No No

No

41

(S/W) Acquiring…(S/W) Acquiring…While working in Information Systems

with such job titles as IT Manager, Project Manager, Systems Analyst, Network Administrator… (and may more with some level of management) a person may be asked to ‘get’ things.

42

(S/W) Acquiring… (2)(S/W) Acquiring… (2)The ‘things’, in this context, are very

often ‘resources’ of one sort or another and may be sorts of hardware, software, personnel or parts of ‘infrastructure’ to contain these things/people.

43

(S/W) Acquiring… (3)(S/W) Acquiring… (3)Acquisition may have other names:

◦Procurement◦Purchasing◦Buy-in

44

The Software Acquisition The Software Acquisition TaskTaskThe duty of software acquisition is,

briefly, to get the most appropriate software for a particular task for the best possible price.

The price being applied to the organisation for which the (systems analyst) works.

“If only it were that easy!” … a systems analyst might say.

45

Software Acquisition Software Acquisition ConsiderationsConsiderationsBefore a systems analyst starts

acquisition there are a few considerations.

The following list are points of practicality, legality – or both.

This general list gets modified in later slides.

46

Software Acquisition Software Acquisition Considerations (2)Considerations (2)

◦Purpose (of the software)◦Planning (to place and use the

software)◦Cost-benefit analysis◦Quality◦Licensing◦Life span (or Life Cycle)◦Risks

47

(S/W) Managing (S/W) Managing AcquisitionAcquisitionThe software may be being purchased on

a small scale for a small part of the organisation, or it might be a large system of software for a large number of users.

The larger the project, the greater the risks.

The ideas for this lecture envisage a large project – imagining thousands of Euro to be spent, up to a million, say.

48

(S/W) Managing (S/W) Managing Acquisition (2)Acquisition (2)The purchase of software very often

involves the management (or control) of:◦Complex, diverse requirements,◦A large software development team,◦Software that is not completely

commercial off-the-shelf, but may include some (- to cause complex inter-operability problems),

◦Legal issues involving contracts, copyrights, trade secrets, patents, warranties, and product liability,

◦Disparate interests/focuses of the developers, the acquirers (themselves) and, possibly, the users.

49

(S/W) Bidding Vendors(S/W) Bidding VendorsFor the purpose of practicality we can

include the idea of putting the software purchase ‘out to tender’.

This means that more than one (often as many as five) vendors can bid for the job of providing software to the acquirer.

Each vendor is a software supply organisation – a business – that makes a bid to the acquirer by presenting an overview of what they intend to provide with some idea of a price for software (delivered and installed).

50

Software Acquisition Software Acquisition ProcessProcessAn example of the process of software

acquisition might look like this:◦Planning,◦Budgeting,◦Specifying requirements,◦Soliciting bids/responses,◦Evaluating bids/responses,◦Contracting/negotiating,◦Monitoring development progress,◦Evaluating/accepting a new system.

51

Software Development Software Development EnvironmentEnvironmentWhere does ‘Software Acquisition’ fit into

the whole Software Development environment?

Overall you could have a software project◦Within that you could have:◦Software Engineering – where software is

developed ‘in-house’◦Software Acquisition – where software that

cannot be developed in house is bought in.

52

Software Development Software Development Environment (2)Environment (2)

Software Project Management – the process of managing the technical

process. Software Engineering Management

– the process of building the software product.

Software Acquisition Management – the process of assembling the requirements, planning the project, acquiring the resources, and monitoring and controlling the implementation.

53

Back to the Acquisition Back to the Acquisition ProcessProcessThe buyer (acquirer) plans for the

acquisition by: ◦Detailing the requirements◦Allocating the resources◦Arranging for the selection of a vendor◦Contracting with the selected vendor◦Building an in-house team of users and

acquirers◦Addressing the support requirements

54

(S/W) Back to the Acquisition (S/W) Back to the Acquisition Process (2)Process (2)The vendor (seller) prepares for the

acquisition by:◦Deciding whether the resources and

capability to bid on the contract are available

◦Deciding whether to bid◦Developing a team to respond to the

proposal◦Estimating the resources required to

accomplish the work

55

(S/W) Will There Be (S/W) Will There Be Problems?Problems?“Crisis – what crisis?”

You can be sure there will be problems. There always are.

(In my experience, I got the impression that the more money was at stake the more problems there were to address.)

56

(S/W) Will There Be Problems? (S/W) Will There Be Problems? (2)(2)The challenge in most acquisition tasks

is to manage:

Functionally: Organisationally:

- Cost - Acquirer

- Schedule - Developer

- Performance - User

Ideally, the user should specify performance, the vendor (seller, supplier) should bid with a cost and schedule, the acquirer should make the big decisions.

57

(S/W) A Few Problems(S/W) A Few ProblemsProblems occur in the areas of:

◦Communication◦Planning◦Requirements◦Verification and validation◦Maintenance

There follows a few general problems types and one typical problem (of MANY).

58

(S/W) A Few Problems (2)(S/W) A Few Problems (2)Communication problems

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

Hierarchical communications only – the red line showsthe path of communication about a project.

Customer Developer

59

(S/W) A Few Problems (3)(S/W) A Few Problems (3)Communication problems

In the previous slide the ‘Name Titles’ represent people in the organisation who are involved in describing – communicating - the needs for software. The communication paths are different for Customers and Developers so the outcomes from discussions on what is needed are similarly different.

60

(S/W) A Few Problems (4)(S/W) A Few Problems (4)Planning problems

E.g. Unrealistic planning; for example, ignoring changes in requirements, staff, legislative framework, organisation...

Requirements problemsE.g. The vendor (supplier) poorly

prepared to deal with new and changing requirements.

61

(S/W) A Few Problems (5)(S/W) A Few Problems (5)Verification problems

E.g. End-user collaboration causes verification reporting weaknesses.

Validation problemsE.g. Ill-defined tests lead to

compromised validity checks.

62

(S/W) Examining the (S/W) Examining the SituationSituationThe process of analysis for acquisition

will often include considerations of:Objectives, Constraints, Alternatives, Risks, Review and Commitment to proceed

63

(S/W) Examining the Situation (S/W) Examining the Situation (2)(2)Determination of critical stakeholder

objectives and constraints (- stakeholders being the acquirer and the vendor),

Elaboration of project and process alternatives for achieving the objectives, subject to the constraints,

Identification and resolution of risks attendant on choices of alternative solutions,

Stakeholders' review and commitment to proceed based on satisfaction of their critical objectives and constraints.

64

(S/W) Examining the Situation (S/W) Examining the Situation (2)(2)If all of these are not considered the

project may be prematurely committed to alternatives that are either unacceptable to key stakeholders or overly risky.

65

(S/W) Risks(S/W) RisksThere are risks associated with spending a

lot of money on product as variable as software.

Risks associated with cost, schedule, resources and technical aspects are tracked during the acquisition process.

‘Risk review’ may take the form of a meeting or an agenda item of a more general meeting where stakeholders can assesses the ‘Commitment to Proceed’.

66

(S/W) Risks (2)(S/W) Risks (2)The level of effort in the acquisition

project might be driven by risk considerations.

The degree of detail (for documentation) may be driven by risk considerations.

The project team’s defined acquisition process provides for the identification, analysis and mitigation of risks for all project functions.

67

(S/W) Acquisition Risk (S/W) Acquisition Risk ManagementManagementProject-wide participation in the

identification and mitigation of risks is encouraged.

Risk management is conducted as an integral part of the solicitation, user requirements, project performance management and contract performance management processes.

68

(S/W) Acquisition Risk (S/W) Acquisition Risk Management (2)Management (2)Acquisition risks are analysed, tracked

and resolved or controlled until mitigated.

Project reviews include the status of identified risks.

69

(S/W) Requirements (S/W) Requirements CriteriaCriteriaWhen choosing a software product the

analyst must match the task to the software product.

She or he may use criteria to help make the choice.

These may be simple or elaborate – and many of them are obvious: an accounts task? Get a spreadsheet application…

70

(S/W) Requirements (S/W) Requirements Criteria (2)Criteria (2)Typical criteria for software selection

might include:◦Compatibility and industry standards◦Ease of installation and operation◦Support (including technical support

such as training)◦Cost (what is included in the price?)

/… continued

71

(S/W) Requirements (S/W) Requirements Criteria (3)Criteria (3)

◦Reliability and track record of the vendor

◦Compatibility of software with current and future hardware

◦Compatibility with other programs being used

◦History of product updates and/or revisions

◦Are there preview or sample options – alternative software products?

72

(S/W) Product Features(S/W) Product FeaturesThe software product is to be used

with a particular task. There are some things that it must be able to do and other things that would be preferred.

E.g. , a spreadsheet MUST be able to represent tabular data, MUST be able to calculate figures… a graph-generator, though not imperative, would be a good feature and the application SHOULD be able to show graphs.

73

What Next?What Next? That’s it for Selection and

Acquisition.

Week 8:Building Information

Systems