Georgetown School of Business

MGMT550 Information Technology and Business Strategy

Organisational Learning

Ewan Sutherland

Business Systems Planning (BSP) is a well-established methodology developed by IBM for both private and public sector organizations. It is a structured approach to planning both short- and long-term information systems requirements, derived from experience within IBM and based on attempts to create an all-encompassing corporate database.

Critical Success Factors (CSFs) were originally intended for use by information systems managers in dealing with senior executives by Rockart. It enabled senior managers to express their needs in terms of the few factors which were absolutely critical to the performance of their job. The IS manager could then use these to propose information systems which would meet the needs of the senior manager. The methodology was subsequently extended to cover planning for all information systems for a company.

Portfolio theory was adopted from financial management—the use of a ‘portfolio’ of projects information systems to balance the risks.

In addition to the more formally planned areas of information systems, there is a wide range of unplanned and sometimes anarchic uses of information systems, such as the adoption and use of personal computers, notebook computers, personal digital assistants, cellular telephones and facsimile machines. These operate under few if any organizational controls, being funded from many different budgets and by many different individual managers.

Beneath the level of information systems planning and resource allocation, there is a need for the detailed work of systems analysis, design, construction, delivery and implementation. Information engineering is the term used increasingly to describe the activities of building information systems, in more formalized ways than in the past. Although information engineering ought to be based on the application of information science, it relies instead on the codification of empirical knowledge, putting it firmly in the craft tradition. Examples of the move towards engineering practices have been the adoption of prototyping and re-working of software already in use.

Information engineering methodologies can be grouped under the following headings:

Structured programming

From the original ‘hand-crafted’ or do-it-yourself style of programming, more systematic approaches have been developed. In order to improve the productivity and the reliability of the ‘code’ generated by programmers, more rigorous approaches were developed for the construction, layout and documentation of computer programs.

Systems analysis and design

Following the success of structured approaches to programming, more rigorous approaches have been developed for systems analysis. The systems development cycle is now well covered by reliable and tested methodologies for investigations, analysis, design, implementation and review. These methodologies address issues such as overall planning, quality management, project management and security, using well-established techniques such as data flow diagrams and entity-relationship models.

Software engineering

A major factor in the drive for improved productivity was the shortage of staff and especially skilled staff. Considerable successes have been achieved through these of software engineering, especially through Computer-aided Software Engineering (CASE).

Human computer interaction

Again ideas for human computer interaction (HCI) started from relatively ad hoc beginnings but have gone on to a more formal basis. Part of the formality has been achieved through market forces which have driven companies towards the use of Graphical User Interfaces (GUIs), such as Microsoft Windows in imitation of the highly successful Apple Macintosh, itself based on work at Xerox PARC.

Formal specifications

There has been a growth in methodologies intended to specify systems in ways which are either provably correct or which can be compiled into runnable code.

Project management

Information systems have come to rival civil engineering projects in terms of their reputed failure to deliver on time and on budget. This is often aggravated by delivering something markedly different from what the customer expected, with the problem of the expectations of the customer changing during the production phase. Therefore, there have been considerable efforts to develop systems and supporting software which will help in managing large software projects. Systems such as Hoskyns’ Project Manager Workbench have been developed to support project management. Project management software has also been integrated into Computer Aided Software Engineering (CASE) tools.

Stages of Growth

The original model comprised four stages:

• cost-reduction accounting
• proliferation in functional areas
• moratorium on new applications
• database applications

• s-shaped curves
• crises in EDP departments
• more stages to come
• three types of growth:
  1. computer applications
  2. specialisation of EDP staff
  3. formal management techniques

Growth of specialisation of personnel

computer efficiency

operators, programmers and systems analysts

development of applications

systems programmers, systems analysts and applications specialists

control and effectiveness

maintenance programmers, functional systems analysts (e.g., finance)

database and on-line

database and telcommunications experts

Management techniques

lax management

no priorities, FIFO, no chargeout

pro-active sales orientation

few priorities or control, informal project control

control-oriented

control by centralisation and a steering group, growth of importance of maintenance, imposition of budgetary controls, chargeout, quality programme

resource-oriented

EDP as a functional area, growing specialisation in EDP department, refinement of cntrols and planning

Sometimes in stage 3, therefore, one can observe a basic shift in orientation from management of the computer to management of the company's data resources. This shift in orientation is a direct result of analyses about how to put more emphasis in expanding DP activities, on the needs of management control and planning as opposed to the needs of consolidation and coordination in the DP activities themselves. [Richard Nolan]

• recognise the fundamental organisational transformation from computer management to data resource management
• recognise the importance of the enabling technologies
• identify the stages of the company's operating units to help keep data processing activities on track
• develop a multi-level strategy and plan
• make the steering committee work

Too many people have fallen into the trap of sophisticated copying of this linear model, including this author. Experience of IS and of the management of IS gives rise to a whole matrix of learning curves, with different technologies and in different parts of the organization. The idea of ‘development’ ceased to be useful when the applications of information systems became too diverse to be mapped onto a single curve; there is no easy way to combine, say, experience in managing mainframe-based on-line transaction processing with end-user experience in electronic publishing. The issue is further confused by the different aims and strategies of subsidiaries and strategic business units which, with different business goals, may require different uses of information systems.

Critical Success Factors

Problems in the late 1970s for determing CEO data needs:

By-product

supply of data as a by-product of OLTP

Null

cannot predict needs (therefore why bother?)

Total study

comprehensive study of informations (e.g., IBM BSP)

Key indicators

infoprmation on 'health' indicators of the business

John Rockart of MIT proposed Critical Success Factors (CSFs):

• intelligible to senior executives
• intelligible to IS managers
• originally for CEOs' personal needs but extended to MIS planning
• can be acted upon

... those few key areas of activity in which favorable results are absolutely necessary for a particular manager to reach his or her goal ...

Sources of CSfs

• industry structure
• competitive strategy
• industry position
• business environment
• contingencies

In summary, CSFs appear valuable as a means ofbuilding a conceptual model of the key facets of an organisation or a of a manager's role in an organisation. Such a model can then be used to drive the requirements analysis process. However, because certain managers may experience some difficulty indealing with conceptual thought processes, the CSF methodology may not be universally appropriate. Because rather concrete thought processes are required to arrive at a detailed specification of information requirements, the CSF method might not, by itself, be a effective requirements analysis tool.

[Boynton and Zmud]

Guidelines for use CSFs

• because of the conceptual nature of CSFs it is best to use prototyping
• project managers need to have a thorough understanding of the business
• find a project champion
• do not make an overt attempt to identify CSFs with information systems
• conduct CSF interviews on several levels in the organisation

A disturbing observation

Second, the CSF exercise provided senior management with important information for strategic planning efforts. The explicit identification of CSFs sharpened management's understanding of those facotrs central to the firm's success. Corporate reorganisation efforts were accelerated by the CSF exercise, and they are likely to be more successful because of it.

Boynton and Zmud

Strengths
• provide effective support to planning processes
• develop insights into information services that can affect a company's competitive position
• are well received by top managers
• serve as the top level of structured analysis

Weaknesses
• middle-level and lower-level managers find it difficult to identify meaningful CSFs
• managers not involved in strategic planning find CSFs too abstract
• some managers cannot express their information needs only in terms of CSFs

CSFs for MIS Managers

• service (user perception)
• communication (between IS managers and users)
• human resources (within larger IS departments)
• repositioning (moving towards information management)

Background: problems and massive growth and spending:

• proliferation
• applications
• systems
• scale
• headaches
• backlog

Portfolio approach

Failure by IS managers to:

• assess individual project risk
• consider the aggregate risk of projects
• recognise that different projects requiredifferent managerial approaches

• failure to obtain forecast benefits
• costs vastly over planned expenditure
• implementation time greatly exceeded
• technical performance significantly below expectation
• incompatibility of the system with existing hardware and software

Dimensions of project risk

• size
• experience
• structure

Assessment

• do the likely benefits outweigh the risks?
• can the affected parts of the organisations survive project failure?
• what are the alternatives?

Portfolio Risk Profile

In addition to determining relative risk for single projects, a company should develop an aggregate risk profile of the portfolio in the abstract, there are appropriate risk profiles for different types of companies and strategies.

F Warren McFarlan

Project management

external integration

communication links between the project team and the user management and community

internal integration

ensuring that the team works as a team

formal planning

to give a structure and sequence to the tasks including allocations of money, time and technical resources

formal control

means to help project managers evaluate progress and failure to progress

External integration

• selection of user as project manager
• creation of user steering committee
• frequent and 'deep' meetings of the committee
• user-managed change processes
• distribution of minutes to key users
• selection of users as team members
• formal approval of specification by users
• progress reports to corporate steering committee
• users responsible for education and installation
• users manage decisions on key action dates

Internal integration

• selection of experienced DP management team
• frequent team meetings
• distribution of minutes within team on key design decisions
• regular technical status reviews
• selection of team members who have worked together
• participation of team in goal and deadline setting
• outside technical assistance when necessary

Formal planning

• PERT, critical path, networks, etc
• selection of milestones and phases
• systems specification standards
• feasibility study specifications
• project approval processes
• post-audit procedures

Formal control

• periodic formal status reports against plan
• change control disciplines
• regular milestone presentation meetings
• detecting deviations from plan

The right approach flows from the project rather than the other way around.

F Warren McFarlan

Readings

Benbasat et al. (1984)

Boynton & Zmud (1984)

Britcher (1990)

Brooks (1975)

Cash et al. (1992)Cohen et al. (1986)

Davis (1979)

Dijkstra (1976)

Earl (1989)

Galliers (1991)

Galliers & Sutherland (1991)

Gibson & Nolan (1974)

Harrison & Thimbleby (1990)

Humphrey & Kellner (1989)

IBM (1984)

McFarlan (1981)

Martin (1984)

Martin (1985)

Munro & Wheeler (1980)

Nolan (1979)

Nolan and Dearden [1973]

Olle et al. (1991)

Rockart (1979)

Rockart (1987)

Rockart & Crescenzi (1984)

Sommerville (1992)

Steinholz et al. (1990)

Sutherland (1991)

Thimbleby (1990)

Yeates (1991)

Zmud & Lind (1985)