63/MITSDE
Chapter VIMIS Design and Development Process
Learning Objectives
Reading this chapter would enable you to understand
• The processes used for designing, developing and implementing MIS
• Techniques used for determining management information needs
• The techniques of systems analysis and design
• Methods of managing MIS development projects
Contents
6.1 Introduction
6.2 Challenges of the MIS Development Process
6.3 Determining Management Information Needs
6.3.1 Business Systems Planning
6.3.2 Critical Success Factor (CSF) Method
6.3.3 End/Means (E/M) Analysis
6.4 Systems Development Methodology
6.4.1 Systems Development Life Cycle (SDLC) Approach
6.4.2 Problem Definition
6.4.3 Feasibility Study
6.4.4 Systems Analysis
6.4.5 System Design
6.4.6 Detailed System Design
6.4.7 Implementation
6.4.8 Maintenance
6.5 Systems Analysis and Design
6.6 Requirements Determination and Structuring
6.6.1 Requirements Determination
6.6.2 Choosing the Right Method
6.7 Requirements Structuring
6.7.1 Data Flow Diagram (DFD)
6.7.2 Logic Modelling
6.7.3 Data Modelling
6.8 Advanced System Analysis
6.8.1 Rapid Application Development (RAD)
6.8.2 Object Oriented Analysis (OOA)
6.9 Managing the MIS Development Project
6.9.1 Who Develops the MIS ?
6.9.2 People Side of MIS Development
6.9.3 Managing User Expectations
6.9.4 Critical Issues for MIS Development and Operation
Summing Up
Self-assessment
References
6.1 Introduction
Although many organisations greatly benefit from their MIS, developing and
implementing such systems successfully is far from certain. The literature on
this subject contains many and sometimes very expensive examples of failures.
Box 6.1 gives one such case relating the London Stock Exchange. Such cases
64/MITSDE
Management Information System
have led to much study of the reasons for failure and the factors that contribute
to success. By adopting systematic approaches for designing and developing
MIS, a great deal of delays and excess costs can be avoided in addition to
getting MIS that is much more effective and efficient. In this chapter we will
discuss ways of designing, developing and implementing MIS.
Box 6.1
Example of failure of a major information system
development project
In the early 1990s, an information system titled Taurus was sold as
a multi-million pound project that would revolutionise the London
Stock Exchange. The London Stock Exchange decided to modernise
its operations by introducing new technologies both, within the
exchange itself and among the organisations associated with it. The
project started with all the optimism of any new venture sold as
revolutionising an industry.
However, in 1993, after years spent in development, the head of the
London Stock Exchange announced that the Taurus system had
failed. It never reached the operational stage; at its demise parts of
it had not been implemented.
In the initial days after the announcement, people searched for
answers: why had Taurus failed? A highly regarded firm of computer
consultants, Ovum Consultancy, suggested that the failure of Taurus
was a direct result of poor configuration management practices.
Configuration management involves identifying the components of
a software system and tracking the changes made to them. It also
involves maintaining information about how to assemble the
components into systems. In practice developers and organisations
find configuration management activities very difficult, because the
software components have technical relationships—called
dependencies—that must be coordinated by the people working on
that code.
Taurus was a highly distributed system; teams of developers worked
together on individual parts of the projects. At the same time Taurus
required that all the organisations linked to the London Stock
Exchange build Taurus-compliant systems. In this highly distributed
environment, the different developers and organisations struggled
to coordinate their ef forts with each other. Technically, it was
difficult to align the distributed development efforts so that all the
systems worked together. Socially, it was hard to maintain
communication among the different developers and organisations
working on the project so that everyone understood what changes
were taking place and why.
Software engineering researchers know that dependencies exist
between pieces of code. However, little is known about how technical
dependencies among modules of code create and reflect social
dependencies among the developers, teams, and organisations
working on them. The story of Taurus clearly illustrates that the
problem of trying to coordinate these technical dependencies is a
managerial problem.Source: Grinter (1996)
65/MITSDE
6.2 Challenges of the MIS Development Process
Frequently managers are faced with a situation where they find that they are
receiving such a lot of information that they just don’t have enough time to
go through all the information received. Yet, at times they find that the MIS
does not generate adequate information on some important issue that they
need to tackle. The information may be incomplete, incorrect, or confusing.
Still worse, they may face a situation that an important report has been sent
to them, but they are unable to locate it when required because it has been
lost somewhere been the piles of reports on their desk or in filing cabinets.
At times it becomes difficult to locate the required information stored on
one’s desktop computer. This problem can be solved by careful study of
management information system requirement of each manager in the
organisation and providing him or her with just that information. The
approach of providing managers with all possible information required by
them is unworkable for several reasons. First is the problem of information
overload. Individuals have limited capacity to absorb and understand the
information reaching them. Too much information can tire the mind of the
recipient, which in turn leads to carelessness, poor understanding, and
mistakes. Then as we have seen in the paragraph above, the presence of
irrelevant, extra, or unimportant information can make it difficult to use the
relevant and information. Finally, extra information means extra costs.
Quantity of information and its content - that is what the information describes
– is just one of the parameters used for identifying management information
requirements. Other parameters include the following factors:
• Nature of Analysis and Presentation: This determines the extent to which
the information is easy or difficult to understand by the manager and
the time needed to spend in doing so (pre-defined versus as requested
or required).
• Time of availability: There are several dimensions to this parameter
including frequency, recency, acquisition lead time, on-demand v/s
routine, periodic versus occasional, repetitive versus one time.
• Accuracy.
• Reliability.
• Security and Authentication.
Thus any good MIS design and development process must address the following
issues effectively -
• Problems of effective communication between users and developers of
MIS. MIS development calls for good understanding of management,
industry, and IT, all of which are usually not available with either the
MIS users or developers.
• Problems in understanding and combining information needs of
managers from dif ferent functions and levels in a common MIS.
Considerations of economy, speed, and data integrity favours a unified
MIS covering the whole organisation. However, because of complexity
of designing and developing a truly unified MIS, it has remained an
ideal rather than reality in practice.
• Usually a management system, of which MIS is a sub-system, is a very
complex system, comprising of a vast array of dif ferent types of
subsystems, interacting with the environment which is even more
66/MITSDE
Management Information System
complex. In a situation like this it is a laborious, costly and time-
consuming task to understand this management system and define its
requirements.
• Need for the organisation to keep pace with changes in environment,
increasingly demanding customer and intensifying competition.
• Using effectively the opportunities fast developing in IT capabilities.
• Keeping in control the capital cost and time of installing advanced IT based
systems. These can be substantial and have a tendency to escalate easily.
• Eliminating the need for frequent and major modifications in the MIS.
This is relative difficulty and costly for advanced IT based MIS.
• Need to manage the human aspect of the MIS user, and other
stakeholders such as employees, customers, suppliers, and other
environmental agencies.
Managers need to decide on the types of information systems that should be
installed in the organisation to support and facilitate their management duties
and responsibilities.
Emergence of sophisticated IT including computers, telecommunication and
automation has created new opportunities for the improvement of operational
and managerial performance. To use these opportunities, managers and MIS
developers need to adopt appropriate methods for designinig, developing and
implementing MIS.
Managers need to take an active role in identifying and clarifying their
information requirements. It is not enough to just limit themselves to the
information they are using currently. Information technology offers many
opportunities for improving business per formance through improving
managerial effectiveness and business process transformation. The total MIS
development project can be broadly divided in two major parts – determining
information needs for managers, and designing and developing information
systems that fulfil these requirements effectively and efficiently. We will first
take up the issue of determining the management information needs, and then
discuss the methodologies for designing and developing information systems.
6.3 Determining Management Information Needs
Three methodologies can be adopted to determine management information
needs:
• Business Systems Planning – To specify problems and decisions.
Developed by IBM
• Critical Success Factor (CSF) – Developed by John Rockart of MIT
• End/Means (E/M) analysis – Developed by Wetherbe and Davis at the
University of Minnesota
6.3.1 Business Systems Planning (BSP)
The business system planning (BSP) method approach was developed by
IBM. It helps to build MIS for both long and short-term information needs of
an organisation. It provides an objective way of identifying information system
priorities for the organisation, and focuses on developing a good overall design
of the way data is maintained in the system so that it can support information
67/MITSDE
system development activities over a period. For example, supplier related
data may be used in 20 different reports and stored in 6 different databases.
Any change in some major information about a supplier may thus need to be
changed in each of the 6 databases separately. The BSP approach tries to
overcome or reduce this problem by using data architecture that supports
multiple applications.
Major activities involved in a BSP study are:
• Top management making a commitment to the MIS development
project.
• Organise a BSP study team consisting of managers from different
functional areas.
• Hold a kick-off meeting of the BSP study team.
• Identify major business processes in the organisation that are needed
to manage the resources of the business.
• Define data classes using different matrices to establish relationships
among the organisation, its processes and data requirements. The
process/ organisation matrix relates the organisational process activities
to people responsible for these activities. Also the classes or types of
data that are used for different processes are identified and charted on
another matrix of data class versus processes showing indicating
processes that use or create the data.
• Determine executive perspective on how effectively the current MIS is
supporting various business processes.
• Identify business problems as perceived by managers, processes
impacted, processes causing the problems, and the impact of the
problem.
• Identify systems development projects based on data classes and business
processes, and based on this define an information architecture.
• Determine priorities for the system development projects based on their
benefit, impact, probabilities of success and demand based on value to
users.
• Review information system management capability to develop proposed
integrated database to environment supporting multiple applications.
• Develop recommendations and action plan to move towards the planned
integrated database environment and develop required applications.
Although the BSP approach is a comprehensive technique for planning
information systems, its application can be time consuming and expensive.
Also it focuses more on more information processing aspects rather than on
managerial effectiveness. It has been criticised also for not paying attention
to identifying opportunities for effective use of new IT. This technique is more
suitable for use by IT professionals trained in the design of database systems
rather than line managers using the MIS.
6.3.2 Critical Success Factor (CSF) Method
CSF was developed by John Rockart of MIT. Critical success factors are
management aspects believed to be crucial to the success of an operation.
They are sometimes described as necessary although not sufficient conditions
for success. The “escape clause” indicates that we do not yet have a complete
understanding of the reasons of success in each situation, but we may draw
68/MITSDE
Management Information System
some general conclusions. The CSF method identifies key business goals and
strategies that must be addressed with business strategy. An effective way of
spotting business problems is to develop key indicators of the health of the
business and to focus on significant deviations from planned performance.
In the first step in the CSF method, the manager identifies his or her goals.
In the next step he looks for the critical success factors underlying these
goals – that “ what has to go right” to achieve a business goal. For example,
for the goal of increasing the market share of a company there could be
different critical success factors. A management consulting firm organising
management development programmes may need to identify seminar topics
that are of interest to the prospective clients, and create a pool of effective
trainers on these topics. An FMCG (fast moving consumer goods) company,
to achieve the same goal may have to focus on advertising effectiveness and
an extensive distribution network. The critical success factors applicable to a
company depend on the nature of the industry and the business strategy
adopted by the company.
Information need of managers is derived from the critical success factors by
finding ways of measuring how well these are being achieved. For example,
advertising effectiveness may be measured by change in market share, and
distribution network may be measured by the number of retail outlets stocking
the goods.
Each of the measure of CSF effectiveness becomes an input for defining
information system requirements. After compiling all the different information
needs, decisions can be taken on the best ways of making these available to
the managers
The CSF method enables managers to identify their own information needs
clearly and correctly. The MIS can then be limited to only such information,
eliminating all other reports, which are often created in traditional MIS more
because of easy availability of input data rather than based on value of
information contained. The main limitation of the CSF method is that it focuses
on information needs of individual managers, rather than the organisation as
a whole. This is not very helpful in building integrated MIS that need to look
at the totality of information required by all the managers in the organisation.
6.3.3 End/Means (E/M) Analysis
E/M analysis technique was developed by Wetherbe and Davis at the University
of Minnesota. Its purpose is to determine effectiveness criteria for outputs
and efficiency criteria for the process generating the outputs.
The first part of the E/M analysis process, related to the “end” aspect, starts
with identifying outputs or services provided by the business process, and
moving on to clarifying what makes these outputs effective for the recipient or
the user. Finally information needed to evaluate the effectiveness of outputs is
selected. For example, the output of a demand forecasting system are forecasts
and market demand. The effectiveness of this will depend on factors like accuracy
of the forecast, and the prompt availability of forecasts. Information required
for measuring the effectiveness may include analysis of variation between forecast
and actual sales, and analysis of delays in providing the forecasts.
69/MITSDE
The other part of E/M analysis, concerned with specifying efficiency criteria
for the processes generating the outputs is based on answers to three
questions:
• What are the key means or processes used to generate or provide the
outputs?
• What constitutes efficiency in providing the outputs?
• What information is needed to evaluate that efficiency?
Continuing the example of demand forecasting process, the key means or
processes used for generating the outputs might include obtaining and
analysing data on past demand and other factors impacting the demand. The
efficiency in this case may be the cost of processing per month, and this cost
may be calculated based on a standard costing system that may be related to
parameters such as computer processing time.
6.4 Systems Development Methodology
A system development methodology establishes a set of procedures that conform
with a life cycle. It helps to keep MIS development project cost and time within
limits, ensures that the results meet business requirements, and that MIS is
properly documented. It gives the users an opportunity to review and confirm
their requirement of the MIS at each phase of MIS development. These constitute
checkpoints for detecting and correcting errors at various points in the
development process. Also it becomes possible to review and modify time and
cost estimates for the project. If required, decisions can be taken on major
modifications in the MIS project approach including cancelling it.
6.4.1 Systems Development Life Cycle (SDLC) Approach
One widely used system development methodology is “Systems Development
Life Cycle (SDLC)” approach. It is a structured technique for developing
systems that cover procedures for controlling information system development
projects. It is a useful tool for producing reliable and maintainable systems.
In SDLC, each stage (subsystem) is defined in terms of activities,
responsibilities, milestones and deliverables (the output from one subsystem
to another subsystem). The SDLC approach helps to control the large and
complex systems that consume large amounts of time and resources.
SDLC may divide the total project from four to 12 phases. One phase is
completed before beginning the next phase. This approach emphasises
documentation and checkpoints, and requires detailed planning and budgeting
at each phase.
SDLC has the following advantages and disadvantages:
Advantages
• Lends itself to good control
• Phase deliverables well defined
• Clear checkpoints makes reviews easy
• Creates detailed documentation which is valuable for maintenance
70/MITSDE
Management Information System
Disadvantages
• Time and cost estimation is difficult
• Can be very slow
• Requires that requirements are defined abstractly, without interaction
with the “system”
• Overall ownership of the process is usually on “systems” people
The key steps of systems development life cycle (SDLC) are listed below:
• Problem Definition
• Feasibility Study
• Systems Analysis
• Systems Design
• Detailed Systems Design
• Implementation
• Maintenance
6.4.2 Problem Definition
Problem definition, the first step of SDLC is intended to clarify the problem
to be solved, improvements to be made, or new opportunities seized by the
proposed MIS. This is really clarifying the objectives for undertaking the MIS
project in the first place. These objectives may be one or more of three general
types. The first of these types of objectives is improving efficiency of the
information system. The focus here is on reducing costs related to the
information system rather than improving the overall performance of the
organisation. When the objective is to reduce the information costs, the MIS
development is focused on automating the process of providing information
to managers, without much stress on improving the nature or quality of
information over the existing levels. The second type of objectives relate to
improving the effectiveness of managers to improve the business performance
by improving the quality of information provided to them. Here the MIS
attempts to provide managers with information not available to them in the
present system or improves the quality of information in terms of features
like timeliness, analysis, presentation and accuracy. The final type of objectives
aim at bringing about major improvements in efficiency and efficiency of the
total business by transforming the way in which the business processes are
undertaken. For example, Wal-mart achieved major improvement in its sales
and at the same time reduced costs of inventories, by introducing a totally
new concept in its procurement practices, where instead of placing purchase
orders on its suppliers for replenishment of stocks in its stores, it introduced
a system of its major suppliers initiating replenishment on their own based
on information on movement of stocks in Wal-Mart stores available to them
with an advanced IT based system using the POS (point-of-sales) information
generated electronically at Wal-Mart checkout counters.
The main methods used for problem definition are - collecting information
from user managers and others through interviews, and questionnaires. This
study may be initiated by sponsoring user managers or an MIS professional.
In any case, the objectives finally developed must be accepted by the sponsor.
The output of this step is a formal document to guide the analyst and the
users with a broad view of the system development project. It specifies the
objectives, scope, any special constraints, material to be used, and resources
71/MITSDE
available (cash limits, time deadlines, persons committed). When an outside
consultant is used, this document provides the inputs for the terms of reference
of a contract. The terms of reference may be provisional pending the findings
of the feasibility study.
6.4.3 Feasibility Study
As the name implies, the feasibility study examines the practical feasibility of
solving the identified problems and achieving the desired objectives within
reasonable time and cost limits. An analyst makes a rapid study of current
practices and systems and of any problems and gaps. Alternative solutions are
examined and may include merely solving specific problems, broad improvements
across the existing system, or moving to a new system. A cross-section of users
is consulted. It results in a feasibility report that advises whether a project for a
new system is worthwhile or whether work should be stopped at this stage.
Whatever the advice, it must be substantiated with facts and explanations. These
should include an indication of resources needed and the costs and benefits,
even though it will be difficult to determine these with accuracy.
This done by doing performing a simple system analysis type exercise without
going into too much depth or details. In this phase, the current system is
studied to identify specific problem areas and possible areas for improvement.
The scope and depth of such study is determined by the objectives set in the
problem identification stage. Based on this study, outlines of alternative MIS
design options are developed and their cost, benefit and time are made. If one
or more of these alternatives are found to be attractive enough, the project
moves to the next stage of systems analysis. When more than one feasible
alternatives are identified, the one most promising may be chosen. When
none of the alternatives is considered by the top management responsible for
sponsoring the project, it may be terminated at this stage itself.
Output of the feasibility study includes the development of a logical model for
the proposed system, specific performance objectives to be achieved by the
proposed system, and time and cost estimates for developing and implementing
the system.
If the advice is to proceed with the project and develop a system, then it
should specify the outline of a solution. It may offer a choice between two or
more options, and it may specify ways in which the original terms of reference
need to be adjusted.
Information on existing methods and organisation for this step is collected
using interviews, questionnaires. If required, some additional analysis based
on organisational records may also be carried out. Logical models of the
existing and proposed systems are constructed using systems diagrams that
graphically depict the main process steps and information flows.
6.4.4 Systems Analysis
Systems analysis involves an in-depth and documented study of current
practices in information management. Based on this study, a proposal for a
revised or new system is developed. The process has three parts: gathering
data, analysing it, and developing from this analysis the system proposal,
which will be the starting point of the next major stage: system design.
72/MITSDE
Management Information System
In consultations with all levels of users, the analysts will seek to identify all
impor tant data entities and information flows, i.e., their origins and
destinations, and record and analyse the information obtained. In a business,
the users include managers from all functional areas at various levels. This
stage uses several sources of information, including the existing reports and
documents in the organisation, questionnaires, interviews and observations.
Questionnaires need to be designed carefully to avoid misinterpretation. An
accompanying letter can explain the purpose and give a return date. Note that
there are limits to the accuracy that respondents can provide, particularly
with numeric data such as hours per week spent on a particular task.
Interviews are often the most productive source of facts and the best way to
tap people’s views and experiences of the current systems and practices.
Observation comprises visits to key offices and operations to view their
processes, check previously recorded facts, and look for new (unrecorded)
facts and for bottlenecks. Good powers of observation are a valuable trait of
the good analyst.
The order in which the methods are listed may also be useful in applying
them. Initial study of appropriate documents can provide the analyst with a
good initial view of the current systems and assist in developing an effective
questionnaire. A well thought out questionnaire is likely to prompt users to
think about their information uses and needs, which can enhance a subsequent
interview.
Data collection is followed by data analysis. At this point, the systems analyst
is not looking for a solution so much as a clear understanding of the current
systems and any problems with them, and for opportunities for greater
effectiveness and efficiency in information management. There are well-
established tools to assist in a methodical systems analysis, such as data
flow charting, data entity modelling, and the function-organisation matrix.
They become important particularly in large and complex systems. This phase
may also encounter resistance from users, who may have legitimate fears
that are best addressed by open and frank discussions between managers,
analysts, and users on plans and prospects.
The system analysis finally leads to a systems proposal specifying a high
level of output (e.g., printed reports, on-screen charts), inputs (e.g., data
collection forms), and the main database tables and their relationships. It
also lists the major tasks of the project to implement the proposed system,
with their duration, and the resources needed. Outputs reflect the perceived
information needs of users. An MIS output only has merit if a management
decision might be made on the basis of an output. Difficulty in identifying any
such decision casts doubt on the value of the output.
A formal report with the analyst’s recommendations is presented to the
management. This report should be accompanied by an oral presentation
attended by all involved parties. Based on a review of the report and the
presentation, management makes a decision whether to continue to the system
design phase (i.e., the proposed system is feasible), revisit the systems analysis
phase to meet areas of concern, or terminate the project.
Management may look at operational, technical, and economic aspects of a
system proposal and at its development schedule:
73/MITSDE
Operational capability ensures that the system can perform its intended
functions within the existing organisational environment with its current (or
planned) personnel and procedures, i.e., that the system will be used once it
has been developed and implemented. If the end users resist a new system,
the system might not be exploited to its full potential. The operational aspect
is largely a human relations problem.
The technical area comprises hardware, software, and personnel to develop
(or purchase), install, and operate the system.
From the economic standpoint, the analyst has to determine and demonstrate
that the benefits to be derived from the system are worth the time, money,
and other resources required to implement it.
Finally, management has to be convinced that the proposed implementation
schedule is realistic and acceptable. The analyst may find Gantt charts and
the Program Evaluation and Review Technique (PERT) helpful to demonstrate
the tasks of a project and their sequence and relationships. If management is
convinced that the project is feasible and should continue, then the project is
taken to the next phase.
6.4.5 System Design
The system design step is intended to decide on detailed features and processes
of the proposed MIS within the framework of overall system identified during
the feasibility phase. In a way systems analysis involves the same tasks as in
feasibility stage, but the range of options considered is narrowed down to the
alternatives selected at the previous stage. Also the level of details and
thoroughness in studying the existing system and for designing and specifying
the proposed systems is much more. The estimates of cost and benefits
produced at this stage are more detailed and reliable. For example, the
feasibility study may talk of developing a system of developing sales persons
evaluation system base on their performance against targets in terms of sales
as well as contribution to profits and overheads. At the systems analysis stage
it will be necessary to give details like what constitutes sales, and how
contribution to profits against these sales are defined, how targets for these
are to be fixed and how the actual performance is to be measured.
The systems analysis stage will also include finalisation of greater details of
IT options to be used for different MIS tasks. For example, the feasibility
study for computerisation of a bank may say that all withdrawal and deposit
transactions by the customers will be computerised, their accounts statements
or passbooks will be printed on computer, and the related accounts of the
banks will also be computerised. The System design stage may then identify
and choose from several alternatives for printing of customer passbooks like,
a running passbook which can be updated after every transaction, a running
passbook updated periodically, and loose statements printed periodically.
Systems analysis will also specify the overall architecture of the computer
hardware, software, and the data structure. This will interest primarily the IT
specialist, but some aspects will also affect the user managers and other
employees. For example, availability of computer terminals for data entry,
transaction processing, and on-line information impacts them substantially.
Similarly they will be very much affected by the ease of and delays in accessing
information available in computer databases.
74/MITSDE
Management Information System
Systems analysis also needs to provide specifications of computer and
communication hardware required for the proposed MIS along with cost
estimates. Similarly time and cost estimates for software development and
other project activities are reviewed and revised as required. Also a time
schedule is prepared giving the break-up, sequence, and schedules for various
detailed design and implementation activities to follow. At times, the system
design may divide the whole MIS project into smaller subprojects to be
implemented in a phased manner.
The developers of MIS need to consult managers widely and need to agree on
their broad information needs for managing the business. This provides an
outline of what the system needs to include. Ideally the cost of management of
an organisation should be kept within acceptable limits. Management of the
MIS has its own cost, which adds to the above cost of management. This is a
further reason to constrain the system within reasonable limits. Having said
that, it is crucial to the value of the information system that sufficient skilled
resources be allocated to its development, implementation, and operation.
6.4.6 Detailed System Design
Detailed system design carries the process of MIS design further and firms
up detailed systems specifications for the proposed MIS, which becomes the
basis for detailed software development and other development activities to
be undertaken by IT professionals. The specifications cover details like report
layouts, computer terminal screen designs, input documents, and the logic
for processes to be used in the system for analysis of information, which need
to be approved by the users and affect their working. There are other details
that affect the efficiency and reliability of the computer processes. This includes
details like data dictionary specifications giving names, definition, format and
size of all data elements in the system. Systems flow charts describing the
subsystems and processes within the MIS are developed to facilitate easy
understanding of the total system and its internal relationships as well as
interface with the environment.
During the process of detailed system design, some of the minor features of
MIS finalised in the earlier stages may be changed in view of the fact that a
clearer picture of the issues involved is available. If the previous steps have
been handled well, a need for major changes should not arise at this stage.
Detailed system design will also provide more reliable data for time and cost
estimates. Therefore, the cost estimates should also be reviewed, revised if
required.
6.4.7 Implementation
Implementation covers the process of coding, testing, and documenting
programmes to capture, store, process and present information to managers
at all levels as envisaged in detailed system design. Also, computer and
communication hardware as required for the planned MIS are procured and
installed at this stage. The process of implementation takes up about two
thirds of the total development effort. Therefore it is necessary to plan,
monitor, and control the implementation activities in much greater detail than
the earlier stages.
75/MITSDE
A poorly tested system is a frequent cause of problems during and after
systems implementation. The system should not become fully operational
until it has been tested for errors. Although testing is tedious, it is essential
that it is carried out thoroughly. It is useful to develop a formal test plan,
which should include for each test: its purpose, definition of test inputs,
detailed specification of test procedure, and definition of outputs expected.
A system’s components are first tested individually, using previously
established test procedures and test data. Then the system is tested in its
entirety to ensure the components are compatible and function as intended.
Testing must include users: this will not only identify further errors but also
provide indispensable feedback on the users’ reaction to the system and the
degree to which they find it meets their requirements. Testers should include
users who are not expert in the system or its software—experts will avoid
user’s errors that more normal users will be prone to make. Testers will need
clear guidance on what they are expected to do. They also need a good medium
in which to record test results, an unhurried environment, and motivation to
test thoroughly.
Another important area of implementation is training of user managers and
other employees to operate and use the system effectively. There are different
training needs for different categories of users. It may be necessary to enlist
external expertise for some of this training. If the company has procured a
readymade system or used an external organisation to develop a local system,
then the source of the system or expertise is likely to be a useful provider of
initial training. It is very important that all those undergoing such training
are in a position to apply it immediately. It is quite different from learning to
ride a bicycle—skills learned in computer training are lost rapidly if not
employed. So the training has to be fitted into the whole MIS implementation
plan in such a way that hardware and software are already in place. If new
equipment is being procured, then it should be used for the training workshops;
trainees can take the new equipment with them back to their station, with
the MIS installed and operational, for immediate use.
Usually a new or revised MIS entails capturing a large volume of master data
into the system before the MIS can become fully operational. When the new
MIS needs to replace the existing ones, there are additional activities involved
for change over from the old to the new system. This task at times can be
quite tricky because a large number of employees in the company have to get
involved in the process, and usually, during the process of changeover they
need to put in extra efforts. Therefore the process of changeover needs to be
planned and executed carefully. We can choose from one of the following four
ways of changing over from an existing system to a new one:
• Parallel conversion
• Direct conversion
• Pilot conversion
• Phased conversion
76/MITSDE
Management Information System
Parallel Conversion
The old and new systems are run side by side for a fixed period of time.
Outputs from each system can be compared to check for errors in the new
system. The causes of errors can be investigated and revisions made in the
final design of the new system. The duration of parallel processing may have
to be extended if an excessive number of errors need to be corrected.
• Advantage: The old system is available to fall back on in case there are
serious difficulties with the new one.
• Disadvantage: The high cost, mainly in staff time, of operating two
systems simultaneously, and in the time and skills needed in running
the cross-system checking.
Direct Conversion
The old system is dismantled immediately after the new system has been put
into place. It might be the preferred choice if the old system has so many
weaknesses that a parallel conversion would serve no useful purpose or if the
new system is very small or simple and does not involve major risks.
• Advantage: It avoids the cost of running two systems simultaneously.
• Disadvantage: Should the new system fail, there is no system currently
operational.
Pilot Conversion
In pilot conversion method, the new system is installed initially in only part
of the organisation, such as one or a branch of a bank, where it can be
thoroughly tested in all its aspects before it is extended to other stations.
• Advantage: The old system is available to fall back on in case there are
serious difficulties with the new one. It is less disruptive and there is
more time for training and for detecting and correcting errors, and it
imposes lower peak demands on users and the system operators.
• Disadvantage: The organisation is left working with different systems
in different parts of the organisation.
Phased Conversion
Throughout the organisation, only part of the new system is implemented
initially. When that part is proven to work efficiently and users are comfortable
with it, another part may be introduced, again for organisation-wide adoption.
• Advantage: The old system is available to fall back on in case there are
serious difficulties with the new one. It is less disruptive and there is
more time for training and for detecting and correcting errors, and it
imposes lower peak demands on users and system operators.
• Disadvantage: The modules have to be able to be implemented and
operated independently and, later, collectively.
77/MITSDE
File Conversion
One important conversion activity is file conversion – that is, changing any
existing paper or electronic files into a form in which they can be used by the
new system. Both paper and electronic forms will often be structured very
differently from the new system. Paper files will need to be keyboarded into
electronic files. It may be worth using an intermediate electronic file that
matches the existing paper format to ease the chore of this keyboarding effort,
and which the systems staff can later process into the new system. Electronic
files from a prior system may be processed into the new system although the
batch process files that are needed for this are difficult and time consuming
to develop. Considerable manual intervention is usually required, especially if
the data is inconsistent and incomplete. Users may have to be asked to update
and correct their data, but as it is a time consuming task, they may need to be
persuaded of its necessity.
Testing
A poorly tested system is a frequent cause of problems during and after
systems implementation. The system should not become fully operational
until it has been tested for errors. Although testing is tedious, it is essential
that it is carried out thoroughly. It is useful to develop a formal test plan,
which should include for each test: its purpose, definition of test inputs,
detailed specification of test procedure, and definition of outputs expected.
A system’s components are first tested individually, using previously
established test procedures and test data. Then the system is tested in its
entirety to ensure the components are compatible and function as intended.
Testing must include users: this will not only identify further errors but also
provide indispensable feedback on the users’ reaction to the system and the
degree to which they find it meets their requirements. Testers should include
users who are not expert in the system or its software—experts will avoid
user’s errors that more normal users will be prone to make. Testers will need
clear guidance on what they are expected to do. They also need a good medium
in which to record test results, an unhurried environment, and motivation to
test thoroughly.
Quality Assurance
Among other things implementation involves, developing procedures designed
to ensure quality of the MIS as a whole in terms of issues like:
• Data security, backup and recovery
• Systems control
• Testing of programme to ensure their ability to be bug free under all
expected business situations
• Ability of hardware and software to deliver the expected processing
capacity and maintain reasonable response times
Attention must be given to usability, stability, documentation and
maintainability of the software system’s quality. Usability should derive from
early and continued user testing and comments from users. Stability,
maintainability will be encouraged if a relational database software is used by
addressing relational principles.
78/MITSDE
Management Information System
Documentation
The MIS project cannot be considered to be complete until all the important
details of the system including hardware, software, computer operational
procedures, and user inter face procedures have been documented.
Documentation is the material that explains what the information system
does and how people interact with it. All documentation must be clearly
identified and dated. Documents must be readily understandable and should
not refer to other documents as far as possible. While a number of documents
were prepared as part of the systems analysis and design processes described
earlier, here we look at those to be released as soon as the system is developed.
The documentation should comprise the following:
• A user guide, which enables an inexperienced user to learn how to use
the system for the major functions for which it is designed
• A user reference or operations manual, which provides more detailed
information for advanced users, including the routine management of
the system
• A systems reference manual, which provides a record of the system
structure and design in sufficient detail in order to enable new staff to
continue the maintenance of the system and make future enhancements
in case the original system developer(s) depart
The first two may be combined in a single document. Increasingly such
assistance is provided by built-in, on-line help facilities within the system
software. The systems reference manual includes a data dictionary, which
lists and defines all tables and their fields.
6.4.8 Maintenance
The MIS system developed, needs to be maintained throughout its working
life to solve any problems faced in operation and to make minor modifications
to the system in response to additional requirements developing after initial
development and implementation is over. Effective design, development, and
implementation of MIS systems can substantially reduce the need for
maintenance efforts. But no amount of planning and design efforts can totally
eliminate the need for maintenance. Good documentation is the only other
way to reduce the maintenance effort required.
It is better to actively seek the area of improvement possible in the MIS and
wherever possible make necessary modifications to improve its utility.
However, not all desired modifications may be that easy or economical to
implement. Even when it is not possible to modify the system to address a
problem or opportunity identified, a record of these should be kept. Sooner
or later a stage may arise when it may become advisable to undertake a major
upgrade of the system. At these stages such records of unattended problems
and opportunities will be a great help in analysis and design of a revised MIS.
6.5 Systems Analysis and Design
We have seen different stages of SDLC use, the Systems Analysis and Design
techniques. These techniques are used even when methods other than SDLC
are used for the MIS project. While information system developers need to be
79/MITSDE
skilled in use systems analysis and design, an overview of these techniques
enables the user managers also to participate more effectively in the MIS
development process.
James A. Senn, in his book “Analysis and Design of Information Systems”
describes systems analysis and design as the process of examining a business
situation with the intent of improving it through better procedures and methods.
It comprises of processes through which the existing practice of information
management is studied. The results are used to redefine the needs for information,
which form the basis for the design of a new system to meet these needs.
Systems development can be generally thought of as having two major
components: systems analysis and systems design. System design is the
process of planning a new business system or one to replace or complement
an existing system. System analysis is the process of gathering and interpreting
facts, diagnosing problems, and using the information to recommend
improvements to the system. This is the job of the systems analyst.
Systems analysts do more than solve current problems. They assess what the
future needs of business will be and what changes should be considered to meet
these needs. Analysts may recommend alternatives for improving a situation.
Working with managers and employees in the organisation, a systems analyst
recommends which alternative to adopt, based on such considerations as the
suitability of the solution to the particular organisation and setting, as well as
employee support the solution is likely to have. Sometimes the time required
to develop an alternative is the most critical issue. Costs and benefits are also
important determinants. In the end management, which will pay for and use
the system, will decide which alternative to accept.
Once this decision is made, a plan is developed to implement the
recommendations. The plan includes all system design features such as new
data capture needs, file specifications, operating procedures, and equipment
and personnel needs. The system design is like the blueprint for a building: it
specifies all the features that are to be in a finished product.
System design will specify ways to capture and store data. It will also designate
work to be performed by people and computers.
Each design describes output to be produced by the system. The systems
analyst decides which output to use, and how to produce.
Analysis specifies what the system should do. Design states how to accomplish
the objective.
Information system consists of subsystems, including hardware, software and
data storage for files and databases. The particular set of subsystems used –
the specific equipment, programmes, files and procedures – constitute an
information system application. Thus the information system can have
purchasing, accounting, or sales application.
Since information systems support other organisation systems, analysts must
first study the organisation system as a whole and then its information systems
details.
80/MITSDE
Management Information System
6.6 Requirements Determination and Structuring
Requirements determination and requirements structuring are two core
components of system analysis. Traditionally, interviewing, questionnaires,
directly observing and analysing documents are four main methods adopted
by system analysts to collect information. JAD and prototyping are two modern
requirements of determination methodologies, which are developed and based
on the previous traditional methods. A well-structured representation of
system requirements can dramatically improve the communication among
analysts, designers, users, and programmers. DFD, structured English,
decision tables, decision trees, and E-R diagrams are traditional primary
requirements structuring tools. Now a days, RAD and OOA are emerging to
help streamline and shorten the total SDLC. While RAD packs traditional
analysis phase and part of design phase into one step, OOA tries to make the
outcomes of analysis phase reusable by the following developing phases, which
can dramatically shorten the total SDLC.
Detailed system analysis involves a substantial amount of effort and cost and
is therefore undertaken only after the management has decided that the
systems development project under consideration has merit and should be
pursued through this phase. Most observers would agree that many of the
errors in a developed system are directly traceable to inadequate efforts in
the analysis and design phases of the life cycle. However, for many reasons, it
is difficult to obtain a correct and complete set of requirements.
As analysis can be divided into three main activities: Requirement
determination, Requirement Structuring, and Alternative generation and
selection. The third one is usually regarded as the automatic result from the
first two processes.
Requirements determination is the beginning sub phase of analysis. In this
sub phase, analysts should gather information on what the system should do
from as many sources as possible. There are some traditional methods to
help collecting system requirements, such as interviewing, survey, directly
observing users, etc. Now a days, some modern requirement collecting
methods, such as JAD and prototyping, have emerged.
Requirements structuring is the process to use some kind of systematic and
standard, well-structured method to model the real world. Traditionally, we
use the data flow diagram for process modelling, decision table or decision
tree for logic modelling, and Entity-relationship diagram for data modelling.
These modelling tools usually separately model only one face of the real world.
So, when we try to show the integral picture of a system, we usually choose
more than one of the above requirements structuring methods.
Rapid Application Development (RAD) is an approach that promises better
and cheaper systems and more rapid deployment by having system developers
and end users work tighter jointly in real-time to develop systems. RAD is not
a single methodology but is more a general strategy of developing information
systems. It brings several system development components together.
Object-oriented analysis and development is a brand new methodology.
Although OOP has become popular in the computer world, whether OOA is
superior to traditional methods is still a question mark. However, from the
81/MITSDE
view of OO world, OOA seems having an important role to play in the future.
In this section, we will discuss some widely adopted basic requirements
determination and requirements structuring methods, compare and contrast
those methods and try to find a best way for system requirements analysis.
6.6.1 Requirements Determination
Collection of information is at the core of systems analysis. Information
requirement determination (IRD) is frequently and convincingly presented as
the most critical phase of information system (IS) development, and many IS
failures have been attributed to incomplete and inaccurate information
requirements. System analysts must collect the information about the current
system and how users would like to improve their performance with new
information systems. Accurately understanding users requirements will help
the system developing team deliver a proper system to the end users in limited
time and limited budget. If the user just wants an ant, definitely, an elephant
is improper. There are many methods to collect information. We will discuss
some basic and widely adopted ones of them.
Interviewing
Interviewing is one of the primary ways to gather information about an
information system. A good system analyst must be good at interviewing and
no project can be conducted without interviewing. There are many ways to
arrange an effective interview and no one is superior to others. However,
experienced analysts commonly accept some of the following best practices
for an effective interview:
• Prepare the interview carefully, including appointment, priming question,
checklist, agenda, and questions.
• Listen carefully and take note during the interview (tape record if
possible)
• Review notes within 48 hours after interview
• Be neutral
• Seek diverse views
Questionnaires
Questionnaires have the advantage of gathering information from many people
in a relatively short time and of being less biased in the interpretation of their
results. Choosing the right questionnaire respondents and designing effective
questionnaires are the critical issues in this information collection method.
People usually only use a part of the functions of a system, so they are always
just familiar with a part of the system functions or processes. In most
situations, one copy of questionnaires obviously cannot fit all the users. To
conduct an effective survey, the analyst should group the users properly and
design different questionnaires for different groups. Moreover, the ability to
build good questionnaires is a skill that improves with practice and experience.
When designing questionnaires, the analyst should concern the following
issues at least:
• The ambiguity of questions.
• Consistence of respondents’ answers.
• What kind of questions should be applied, open-ended or close-ended?
• What is the proper length of the questionnaires?
82/MITSDE
Management Information System
Observation
The third one is directly observing users. People are not always very reliable
informants, even when they try to be reliable and tell what they think is the
truth. People often do not have a completely accurate appreciation of what they
do or how they do it. This is especially true concerning infrequent events, issues
from the past, or issues for which people have considerable passion. Since
people cannot always be trusted to reliably interpret and report their own actions,
analysts can supplement and corroborate what people say by watching what
they do or by obtaining relatively objective measures of how people behave in a
work situation. However, observation can cause people to change their normal
operation behaviour. It will make the gathered information biased.
Analysing Procedures and Documents
The fourth one is analysing procedures and documents. By examining the
existing system and organisational documentation, the systems analyst can
find out details about the current system and the organisation these systems
support. In documents, analysts can find information such as problems with
existing systems, opportunities to meet new needs if only certain information
or information processing were available, organisational direction that can
influence the information system requirements, and the reason why current
systems are designed as they are.
However, when analysing those official documentations, analysts should pay
attention to the difference between the systems described on the official
documentations and the practical systems in the real world. For the reason of
inadequacies of formal procedures, individual work habits and preferences,
resistance to control, and other factors, the difference between the so called
formal system and informal system universally exists.
Joint Application Design (JAD)
The fifth one is Joint Application Design (JAD). It is a facilitated, team-based
approach for defining the requirements for new or modified information
systems. JAD was developed at IBM in the late 1970s. The main idea behind
JAD is to bring together the key users, managers, and systems analysts
involved in the analysis of a current system. The primary purpose of using
JAD in the analysis phase is to collect systems requirements simultaneously
from the key people involved with the system. The result is an intense and
structured, but highly effective, process. Having all the key people together
in one place at one time allows analysts to see where there are areas of
agreement and where there are conflicts.
The typical participants in a JAD are: JAD session leader, end users, business
managers, sponsor, system analysts, IS staff, and scribe. The JAD team is a
group of from six to sixteen individuals who all have a stake in designing a
high quality system. Approximately two thirds of the group members are
functional experts, the other one third are systems professionals. JAD sessions
are usually conducted in a location other than the place where the people
involved normally work, and are usually held in special purpose rooms where
participants sit around horseshoe-shaped tables. Involving so many different
kinds of people in one workshop makes effectively and efficiently organising
the JAD session a big challenge.
83/MITSDE
When a JAD is completed, the final result is a set of documents that detail the
workings of the current system related to the study of a replacement system.
These requirements definition document generally includes business activity
model and definitions, data model and definition, data input and output
requirements. It may also include interface requirements, screen and report
layouts, ad hoc query specifications, menus, and security requirements. When
used at a later point in the system development life cycle, a JAD session can
also be used to refine a system prototype, develop new job profiles for system
users, or develop an implementation plan.
However, to exploit the full potential of the JAD, the groupware tools should
be applied in JAD workshop sessions. The use of groupware tools to support
the joint Application Development technique increases the value of this
technique dramatically. When groupware tools are used in an automated JAD
workshop, they greatly facilitate the generation, analysis, and documentation
of information. This is particularly valuable for JAD workshops conducted to
define and build consensus on the requirements for new systems.
Prototyping
The Sixth one is Prototyping. Prototyping is a means of exploring ideas before
you invest in them. Prototyping is the process of building a model of a system.
In terms of an information system, prototypes are employed to help system
designers build an information system that is intuitive and easy to manipulate
for end users. Most system developers believe that the benefits from early
usability data are at least ten times greater than those from late usability
data. Prototyping allows systems analysts quickly show users the basic
requirements for a working version of the desired information system.
This method recognises the difficulty of prescribing in detail a system’s
requirements on paper prior to its construction, and the value of enabling
users to develop their statement of needs dynamically through repeatedly
commenting on an evolving prototype. Prototyping thus integrates systems
analysis, design, and implementation. Prototyping is particularly useful for
systems where requirements are difficult to specify (e.g., decision support
systems) or for solutions for designing the human interface, such as the
screens for data entry, selection menus, and reports. A valuable aspect of
prototyping is that it encourages users to become interested in the
development of a system. This greatly reduces the risk of implementing a
system that is based on incorrect analysis of users’ real needs, and it avoids
the associated cost of major redevelopment. Prototyping is more useful for
small systems; large ones therefore need to be broken down into small
components. However, it remains important to undertake at least a basic
systems analysis prior to starting. Care should be taken to fully finish the
system and write the documentation.
After viewing and testing the prototype, the users usually adjust existing
requirements to new ones. The goal with using prototyping to support
requirement determination is to develop concrete specifications for the ultimate
system, not to build the ultimate system from prototyping. Prototyping is most
useful for requirements determination when user requirements are not clear or
well understood. One or a few users and other stakeholders are involved with
the system, possible designs are complex and require concrete form to fully
84/MITSDE
Management Information System
evaluate. Communication problems have existed in the past between users and
analysts, and tools and data are readily available to rapidly build working systems.
Prototyping comes in many forms - from low tech sketches or paper screens
(Pictive) from which users and developers can paste controls and objects, to
high tech operational systems using CASE (computer-aided software
engineering) or fourth generation languages and everywhere in between. Many
organisations use multiple prototyping tools. For example, some will use paper
in the initial analysis to facilitate concrete user feedback and then later develop
an operational prototype using fourth generation languages, such as Visual
Basic, during the design stage.
When adopting prototyping, analysts should be concerned about the potential
problems about the requirements determination method, such as informal
documentation, ignored subtle but important requirements.
Advantages of Prototyping:
• Reduces development time
• Reduces development costs
• Requires user involvement
• Developers receive quantifiable user feedback
• Facilitates system implementation since users know what to expect
• Results in higher user satisfaction
• Exposes developers to potential future system enhancements.
Disadvantages of Prototyping
• Can lead to insufficient analysis.
• Users expect the performance of the ultimate system to be the same as
the prototype.
• Developers can become too attached to their prototypes.
• Can cause systems to be left unfinished and/or implemented before
they are ready.
• Sometimes leads to incomplete documentation.
• If sophisticated software prototypes (4th GL or CASE Tools) are
employed, the time saving benefit of prototyping can be lost.
• Prototyping is not necessary if the developer is already familiar with
the language ultimately used for system design.
Instead of software prototyping, several information systems consultants and
researchers recommend using “low tech” prototyping tools (also known as
paper prototypes or Pictive), especially for initial systems analysis and design.
The paper approach allows both designers and users to literally cut and paste
the system interface. Object command and controls can be easily and quickly
moved to suit user needs.
Among its many benefits, this approach lowers the cost and time involved in
prototyping, allows for more iterations, and gives developers the chance to
get immediate user feedback on refinements to the design. It effectively
eliminates many of the disadvantages of prototyping since paper prototypes
are inexpensive to create, developers are less likely to become attached to
their work, users do not develop performance expectations, and best of all,
paper prototypes are usually “bug-free” unlike most software prototypes.
85/MITSDE
6.6.2 Choosing the Right Method
When we choose the requirements determination method for a specific project,
there are seven characteristics we should consider. They are Information
Richness, Time Required, Expense, Chance for Follow-up and Probing,
Confidentiality, Involvement of Subject, Potential Audience. Table 6.1 concludes
these characters of previously discussed six requirements determination
methods.
Comparison of Requirement Determination Methods
Characte- Interviews Questionn- Observa- Document JAD Proto-ristics aires tion analysis typing
Information High Medium to High Low(passive) High Medium
Richness low and old to High
Time Can be Low to Can be Low to Dedicated Moderate
Required extensive moderate extensive moderate period of and can
time of be
all kinds extensive
of involved
people
Expense Can be Moderate Can be Low to High High
high high moderate
Chance for Good Limited Good Limited Good Good
Follow-up
and probing
Confi- Interviewee Respondent Observee Depends on All the Usually
dentiality is known to can be is known to nature of people know
interviewer unknown interviewer document know each each
other other
Involve- Interviewee Respondent Interviewees None, no All kinds Users
ment of is involved is passive, involved and clear of people are
Subject and no clear committed commitment are involved
committed commitment depending involved and
on their and commit-
awareness committed ted
of being
observed
Potential Limited Can be Limited Potentially Potentially Limited
Audience numbers, quite large, numbers biased by biased by numbers;
but but lack of and documents the people’s it is
complete response limited selection and reluctance difficult
responses from some time of original to be frank to involve
from those can bias each purpose of on sensitive all
interviewed results documents issues potential
users
Table 6.1 Comparison of requirement determination methods
6.7 Requirements Structuring
In the last section, we discussed about the methods to determine information
system requirements. In this section, we will focus on the widely adopted
methods used to present the requirements. Traditionally, there are three basic
methods for requirements structuring:
• Data flow diagrams: These are widely used for process modelling
• Logic modelling using structural English, decision tables, and decision
trees
• Data modelling using entity and relationship diagrams
86/MITSDE
Management Information System
6.7.1 Data Flow Diagram (DFD)
First, a data flow diagram (DFD) is a graphical tool that allows analysts (and
users) to depict the flow of data in an information system. DFD graphically
represents the functions, or processes, which capture, manipulate, store and
distribute data between a system and its environment and between components
within a system. The final deliverables and outcomes for DFD are:
• Context data flow diagram, which defines the boundary of the system
• DFDs of the current physical system, which is used to determine how
to convert the current system into its replacement
• DFDs of current logical systems
• DFDs of new logical systems
• Thorough descriptions of each DFD component
In a DFD, there are only four symbols that represent the same things: data
flows, data stores, processes, and source/sinks (or external entities). A data
flow can be best understood as data in motion, moving from one place in a
system to another. A data store is data as rest, which may take the form of
many different physical representations. A process is the work or actions
performed on data so that they are transformed, stored, or distributed. Source/
sink is the origin or destination of data, sometimes referred to as external
entities.
Data flow diagrams should be mechanically correct, but they should also
accurately reflect the information system being modelled. To that end, analysts
should check DFDs for completeness and consistency and draw them as if
the system being modelled were timeless. Complete sets of DFDs should
extend to the primitive level where every component reflects certain irreducible
properties. Following the above guidelines, DFDs can aid the analysis process
by analysing the gaps between existing procedures and desired procedures
and between current and new systems.
6.7.2 Logic Modelling
Secondly, logic modelling involves representing the internal structure and
functionality of the processes represented on data flow diagrams. In the
analysis phase, logic modelling will be complete and reasonably detailed, but
it will also be generic in that it will not reflect the structure or syntax of a
particular programming language. There are three traditional tools for logic
modelling: structure English, decision tables and decision trees. Structured
English is a modified form of the English language used to specify the logic
of information system processes. Although there is no single standard,
structured English typically relies on action verbs and noun phrases and
contains no adjectives or adverbs. The decision table is a matrix representation
of the logic of a decision, which specifies the possible conditions for decisions
and the resulting actions. Usually, there are three parts in a decision table:
the condition stubs, the action stubs, and the rules. A decision tree is a
graphical technique that depicts a decision or choice situation as a connected
series of nodes and branches. Decision trees have two main components:
decision points and actions. Nodes represent decision points, while actions
are represented by branches. The comparison among these three is shown in
following table 6.2.
87/MITSDE
Comparison of Requirement Presentation Methods
Criteria Structured English Decision Table Decision Tree
Determining Second Best Third Best Bestconditions &actions
Transforming Best Third Best Bestconditions &actions intosequence
Checking Third Best Best Bestconsistency &completeness
Table 6.2 Comparison of requirement presentation methods
The comparison of decision table and decision trees is shown in table 6.3.
Comparison of Decision Table and Decision Trees
Criteria Decision Tables Decision Trees
Portraying complex logic Best Worst
Portraying simple problems Worst Best
Making decisions Worst Best
More compact Best Worst
Easier to manipulate Best Worst
Table 6.3 Comparison of decision table and decision trees
6.7.3 Data Modelling
Thirdly, data modelling develops the definition, structure, and relationships
within the data. Many analysts believe that a data model is the most important
part of the statement of information system requirements. This belief is based
on the following reasons:
• The characteristics of data captured during data modelling are crucial in
the design of databases, programmes, computer screens, and print reports.
• Data rather than processes are the most complex aspects of many
modern information systems and hence require a central role in
structuring system requirements.
• The characteristics about data (such as length, format, and relationship
with other data) are reasonably permanent.
The most common format used for data modelling is entity-relationship (E-
R) diagramming. The E-R data model is a detailed, logical representation of
the data for an organisation or for a business area. There are three main
constructs in the E-R diagram: data entities, relationships, and their associated
attributes. An entity is a person, place, object event, or concept in the user
environment about which the organisation wishes to maintain data. Each
entity type has a set of attributes associated with it. An attribute is a property
or characteristic of an entity that is of interest to the organisation. Relationships
are the glue that hold together the various components of an E-R model. A
relationship is an association between the instances of one or more entity
types that is of interest to the organisation.
88/MITSDE
Management Information System
6.8 Advanced System Analysis
Now a days, there are other two very widely adopted methods for system
analysis. They are Rapid Application Development (RAD) and Object-oriented
analysis. These two are always labelled as advanced system analysis or modern
system analysis. The popularity of these two methods owes to the high
pressure of today’s quickly changed business environment. The present end-
users cannot wait for two to three years to have a system. So, streamlining
the SDLC and shortening the total SDLC play a critical role in system
development. To achieve this goal, RAD tries to compact several phases into
one single step while OOA try to make the analysis phase seamlessly pass to
the OO design phase.
6.8.1 Rapid Application Development (RAD)
RAD is an approach to developing information systems that promises better
and cheaper systems and more rapid deployment by having systems developers
and end users work together jointly in real time to develop. RAD grew out of
the convergence of two trends:
• The increased speed and turbulence of doing business. As global
competition increases, processes for detecting and satisfying customers
must be redesigned and continuously improved. To do this, information
technology should be merged into business-process design as early as
possible.
• Ready availability of high-powered computer-based tools to support
systems development and easy maintenance.
Compared with seven phases, standard SDLC, RAD SDLC has only four
phases. They are - planning, design, development, and cutover. RAD pushes
analysis and part of design jobs of standard SDLC into one design step.
Actually, RAD is not a single methodology but is instead a general strategy of
developing information systems, which takes into account human factors and
corporate culture as well as technology. To succeed, RAD relies on bringing
together several system development components, such as JAD, prototyping,
and all kinds of traditional requirements structuring methods. It is impossible
to do so without using the high-powered computer-based tools such as visual
tools and integrated CASE tools, which include code generators for creating
code from the design end users and analysts create during prototyping. There
are four necessary pillars for the RAD approach: tools, people, methodology,
and management.
Advantages of RAD:
· Time saving, money saving, human effort saving
· Tighter fit between user requirements and system specifications
· Best fit for quickly changed business environment
· Concentrates on essential system elements from user viewpoint.
Disadvantages of RAD:
· High costs of commitment on the part of key user personnel
· Easy to ignore some issues, such as missing information on underlying
business processes, inconsistent internal designs with and across
systems, lack of scalability, lack of attention to later systems
administration built into the system, etc.
89/MITSDE
In one sentence, RAD heavily depends on JAD and Prototyping, so it inherits
the advantages of these two approaches while it has to tolerate the
disadvantages of the two. Last but not the least, the RAD approach is not
appropriate to all projects. Project scope, size and circumstances all determine
the success of a RAD approach.
6.8.2 Object Oriented Analysis (OOA)
Object oriented system analysis abstracts concepts from the application
domain and describes what the intended system must do, rather than how it
will be done. Instead of using functional decomposition of the system, the
OOA approach focuses on identifying objects and their activities. Using the
Object oriented approach, system analysts model information systems by
identifying a set of objects, along with their attributes and operations that
manipulate the object data. Objects are grouped into classes that have
common properties. Classes are organised into hierarchies, in which the
subclasses inherit the properties, including the data definitions and operations.
The model specifies the functional behaviour of the system, independent of
concerns relating to the environment in which it is to be finally implemented.
The OO analysts need to devote sufficient time to clearly understand the
requirements of the problem and the analysis model should capture those
requirements completely and accurately. The core of OO is reusability. The
whole OO system is built on inheritance, so a subtle misunderstanding of the
basic requirements of the problem may cause the whole system to seem
ridiculous. OOA is inspired by the now a days very popular object-orient
programming (OOP). The traditional system analysis methods cannot adapt
to OOP to make the whole development process smoother and seamless, so
OOA comes up and tries to solve such problems. The outcomes of OOA usually
are considered reusable for the further OO system development phase, such
as OOD and OOP, and these reusability characters can dramatically shorten
the total SDLC.
OOA has it own whole set of modelling tools to represent the system
requirements. They are:
• Use-case diagram helps to generate a requirements analysis model,
which captures the functionalities of the system as seen by external
actors
• Class diagram helps to analyse the objects in the problem domain and
describe their static structure
• State diagram shows how the object transitions from one state to other
states
• Sequence diagram shows the explicit sequencing of messages
The commonly admitted points about OOA advantages in the OO world are:
• An easier modelling process and the ability to tackle more challenging
problem domains
• Improved communication among users, analysis, designers, and
programmers
• Increased consistency among analysis, design, and programming
activities
• Improved quality of system
• Reusability of analysis, design, and programming results
90/MITSDE
Management Information System
So far, although more and more system analysts adopt OOA, whether it is
superior to traditional system analysis is still in hot argument. Although in
the OO world, the above advantage points about OOA are commonly accepted,
there are still a large number of software communities which don’t agree
with them. People may more naturally think in a procedural way than in an
object way. Moreover, it is commonly accepted in the Object-oriented research
field that the methodology of OOA is far from mature and the identification of
object classes remains an art because it is highly dependent on the problem
domain.
Conclusion: There is no official best way of systems analysis, the methods
applied to a project depend on the project context, such as the analyst’s
expertise, user’s favourites, project’s size and complexity. So, a good systems
analyst should be able to use any of these methods on the fly according to the
specific project context.
Although the new system analysis methods come out one by one, the
traditional ways for requirements determination, like inter viewing,
questionnaires, directly observing, and analysing documents can never be
simply replaced. Furthermore, neither in modern requirements determination
methods, such as JAD and prototyping, nor in the now a days advanced system
analysis, such as RAD and OOA, those four types of information collecting
approaches are always the cornerstones, which can never be touched.
As a result of the high changing pace of the business environment, RAD
shows itself dramatically shortening the SDLC. However, from the view of a
system requirements analysis, RAD intensively combines all kinds of system
analysis methodologies into a one-step process by using the now a days high-
powered computer technology. RAD heavily adopts JAD and prototyping as
the two primary ways to gather the requirements, so the merits and drawbacks
of these two methods also can be found in RAD.
OOA may be the real revolution in the system analysis field. However, such a
revolution just happened at the requirements structuring level. It does not
touch the basic requirements determination method, although better
requirements representation can help the requirements determination process
to be more efficient and effective. In order to adapt to the OOP, a whole set of
OOA requirements structuring tools, such as use-case diagram, class diagram,
etc., were developed, which are thoroughly dif ferent to the traditional
requirements structuring tools, such as DFD, structured English, etc. So far,
whether the OOA is better than the traditional analysis methods or not is
still a question mark. However, traditional requirements analysis techniques
were inspired by, and founded on, structured programming concepts. Now a
days, in a programming world that is increasingly turning to object orientation,
such traditional techniques seemed out of date and had to be replaced.
6.9 Managing the MIS Development Project
Traditionally, a project is required to (1) be completed within time, (2) be
completed within budget, and (3) deliver the right product. To an extent these
are conflicting or competing demands, and part of the task of a project manager
in-charge of developing MIS is maintaining a reasonable balance between them.
There is a range of project management software on the market. The simplest
91/MITSDE
programmes enable the manager to list the project’s several components and
track them through estimates of their start dates and duration as well as
monitor their individual progress to completion. Typically this is done through
Gantt charts and the Programme Evaluation and Review Technique (PERT).
Project components can usually be entered in a hierarchy, such as project,
tasks, and activities. For very large and complex projects, such software
support tools are a valuable management aid. They are less useful for small
projects as they incur a considerable overhead in time initially in learning
how to use them and subsequently in entering data and generating and using
the reports.
A person familiar with database software could construct a basic project
management system that records all tasks and activities, their start date and
estimated duration, and their completion. Such a system may lack the Gantt
and PERT charts of the purchased product but can still ser ve project
management well. An additional module can record the “bugs” and user
comments that start emerging on the release of the first prototype. Such a
project tracking database system would record for each problem or bug an
estimate of the time needed to resolve it and the percentage resolved to date.
This enables the system to report at any time, the outstanding resources still
required to completion. The outstanding resources needed and the number of
items provide a useful indicator of progress: both should show a steady decline
if the project is moving forward satisfactorily to conclusion. The flow of user
comments and reports of system faults will initially increase if this process is
going well, but then in time also decline as the system moves closer to users’
needs and a fault-free state.
6.9.1 Who Develops the MIS ?
While the overall responsibility for developing and operating MIS rests with
the top management of the company, several alternatives may need to be
considered for supplementing the resources available within the company.
Particularly, the MIS development and design process calls for professional
expertise and skills in IT and system analysis. Also, new MIS development
presents the company an opportunity to also review and upgrade its business
processes. Again, for this kind of business process reengineering it is
worthwhile for many companies to seek the best available expertise in
business management, which may not be available in the companies. Thus, a
company which embarks on MIS development project has several alternatives
to choose from. These are:
1. Use in-house resources for all MIS design, development and
implementation activities.
2. Use in-house resources for all MIS design, development and
implementation activities except software development.
3. Use in-house resources to develop the overall framework of the MIS
design including the user specifications. This will roughly correspond
to SDLC activities up to systems analysis and design being done in-
house and the detailed system design and implementation being
outsourced.
4. Use in-house resources to do the feasibility study and on that basis
outsource rest of the activities.
92/MITSDE
Management Information System
5. Appoint a management consultant to do the feasibility study, and with
his consulting support, outsource all the other activities.
6. Outsource the total MIS with minimum in-house work, just enough to
guide the terms of business with the party responsible for total MIS
project.
7. Some combination of the first six alternatives described above.
Irrespective of the option selected, there is always a need to involve the users
and other employees in various development activities as we have discussed
in the sections relating to MIS development and management. Also, any of
the MIS development activities require exper tise in IT and systems
methodologies, which, if not available in-house, must be outsourced. To some
extent, line managers can learn some of the expertise with short training and
by working on the MIS development project, and then become valuable
resources for the project. However a total reliance on line managers, in today’s
world of advanced IT and complex business processes, is not likely to produce
acceptable results.
With these general remarks, we will discuss the issues involved in choosing
from the alternatives listed above. In almost all cases the first alternative is
not preferred by any company. While smaller companies lack the necessary
information systems expertise, the larger companies generally prefer to
outsource the detailed systems development work to avoid hiring too many
people, which may not be needed after the MIS project is over. This alternative,
if used at all, is limited to small modifications to existing MIS in companies
having some permanent IT staff.
The second and third alternatives are feasible mostly for bigger companies
having an in-house IT department. The limiting factor here will be the availability
of adequate staff with the necessary IT skills. Also, companies will need to
examine the availability of necessary business management expertise in case
the MIS project involves some business process reengineering.
The fourth alternative is most suitable in a situation where the company has
experienced managers or internal experts that understand well the business
processes as well as opportunities offered by IT. These internal experts will
need to be senior managers with a good grasp of all functions of management,
and must enjoy top management credibility. This alternative may be used by
all sizes of companies that are fortunate to have the kind of personnel described
above. Companies that have a strong IT department in addition to such
personnel, may decide to undertake some additional development activities
in-house, depending upon the resources available.
The fifth alternative is clearly for companies with neither business process
reengineering or IT resources to spare. The sixth alternative is a high risk
alternative and, unless there are some compelling reasons to make an
exception, must be avoided.
Installation of hardware is almost always done by the vendor, who may also
supply some supporting software. These vendors also provide some training
in operation and maintenance of the hardware and software supplied by them.
Wherever available, such resources should be used.
93/MITSDE
In general a company may use one of the following three approaches for
constitution of the MIS project teams:
• Internal, team-based experts
• Internal IT department
• Outsourcing to external consultants
Internal, Team-Based Experts
Advantages
• Often the internal team based experts are highly motivated and
committed to the company.
• Team members have expertise in both, IT and the business. Also, they
understand the company operations and problems best.
• Easiest to integrate with users and managers they’ll need to interact
with.
• Internal teams dominated by line managers are prone to use off-the-
shelf, easier-to-use software than IT professionals and hence likely to
get systems up and running more quickly.
• Most economical over the long term if their skills are fully utilised.
Disadvantages
• Employees with required skills and knowledge may be difficult to find
and keep.
• May not have the specialised skills needed for every project.
• Excludes the internal IT department, which
(a) Knows best the IT infrastructure;
(b) Is responsible for maintaining corporate IT standards and
(c) May one day be asked to maintain an
Internal IT Department
Advantages
• Product is likely to be compatible with other IT systems in the
organisation.
Disadvantages
• Many systems professionals do not understand the specific needs of
users and have little or no knowledge of users’ work.
• Some users have sufficient IT competence to recognise when they are
being inadequately served, which results in dissatisfaction with the IT
department and a preference to develop their own systems.
• Tends to subordinate users desires to their own views.
Outsourcing to External Consultants
Advantages
• It is more cost-effective than own IT department for small businesses.
• Can take advantage of specialised skills which are inefficient to maintain
in-house.
94/MITSDE
Management Information System
• Larger organisations find this preferable when there is a lack of time or
particular skills in the IT department.
• Can offer a combination of range of expertise and experience not available
in the IT department. Many focus on particular industries and have worked
on many sites in that industry (though not often in agricultural research).
• An outsider can introduce more easily unpopular changes deriving from
system development.
• IT department believed to be too technocratic for user-empowered
systems.
Disadvantages
• Unless carefully managed, runs the risk of large expenditure without a
functional system at the end.
• Possible communication problems.
• Might be less committed to solving problems.
• May not understand your business as well as permanent employees.
• Could be more expensive if you need them more than you originally
estimated.
6.9.2 People Side of MIS Development
People are very important components of any MIS. They are also the most
important factor in the MIS development process. The people that need to be
managed during the MIS development project include:
• Top management
• Middle and lower management
• Employees other than managers who will be involved in operation of MIS
• Other stakeholders impacted by the proposed MIS
Involvement of the top management is essential for the success of any major
or even medium sized MIS project. Change in MIS of a company usually
involves some changes in basic business processes. Unless top management
approval is available, it is difficult to agree on and introduce such changes.
Top management support is also required to ensure that the best of managerial
resources in the company are available for the MIS project. An effective design
of MIS is possible only with active involvement of capable senior managers of
the company who understand the business well and have the capability and
willingness to understand and adopt new innovative practices. Unless the top
management backs the MIS project, such inputs from the user managers will
not be forthcoming. Top management approval and close involvement is
absolutely essential when the MIS project aims at business transformation.
Of course, top management are also likely to be users of the new MIS, and
therefore, must accept the final results of the MIS project.
Middle and lower management are the main users of the MIS. They also have
to make a major contribution in identifying and clarifying the user
requirements. Identification of user requirements has always been a tricky
area and frequently the cause of many a dispute between MIS users and
developers from the IT function. In view of the critical importance of this
aspect of MIS project management, we have discussed it in detail in the section
titled “Managing User Expectations”.
95/MITSDE
Middle management also provide the human resources required involved in
the routine operation of an MIS, as well as during the implementation phase
for activities such as master file creation and parallel operation. At times,
employees at lower levels may need to learn new skills and their job profiles
may change significantly. Middle managers are usually the group which is in
a position to reorganise the workforce as required, and to arrange resources
for extra work involved in the development and implementation process. These
managers also play an important role in ensuring acceptance of proposed
MIS by the employees and other stakeholders
Managers are the main source of data for the system, and the MIS needs data
from every manager each year. These requirements will not be met unless
the managers are, and feel, part of the system and are allowed to benefit from
it. The system needs to be demonstrated to them before it is implemented to
show the benefits relevant to them alongside the cost, i.e., their time to provide
information.
One dilemma for line managers in participating in MIS projects is the conflict
between their original discipline, such as manufacturing or marketing, and
the new IT. Time spent on managing information is time taken from pursuing
their conventional functional discipline, and they may therefore suffer reduced
prospects of advancement in their functional area. Therefore they need to be
reassured that their time spent on MIS development is also an important
part of their line job that will enable them to take a fresh look at their operation
and also improve their effectiveness in their line functions.
The operational level employees are essential for the operation of any MIS
operation. Usually they are responsible for feeding the bulk of the input in the
system. They may also be involved in report generation. At times, MIS may
involve computerising some laborious manual jobs, and thereby releasing
some manpower for alternative duties. People may need to learn some new
skills on using the computerised systems as well as for taking up additional
responsibilities. Computerisation often releases people from routine and simple
tasks, giving them an opportunity to devote more of their time to tasks that
are more demanding in terms of using their mental skills and judgment. In
the long term this leads to better job-profile and prospects for the employee
concerned. But in the short-term they may resist this change. There is a
need to use the appropriate human relations approach to help them accept
the changed situation and the added responsibilities. One important thing is
to consult and keep these employees involved and informed from the beginning
and through the entire project process. Springing surprises, even apparently
happy ones, have a tendency to backfire.
Other groups of people like suppliers, customers and statutory agencies, can
also be affected by the operational changes necessary to implement the MIS.
At times, managers in India underestimate the willingness and abilities of
suppliers, customers, and government agencies in India to adopt new
technology. Starting with a negative attitude like this does not help anyone. A
sincere attempt should be made to have a meaningful dialogue with all
stakeholders early in the project. The attempt should be on understanding
their situation as well as explaining your own.
96/MITSDE
Management Information System
Use of project teams is an effective way of obtaining commitment and developing
understanding. The members of the project team may work on the project
full time or part-time depending on the project need and their other
responsibilities.
Successful IT companies are abandoning the old organisation structures where
a client tracking down some information is shunted from department to
department. Instead, individuals have access to pooled knowledge that can
be harnessed to solve problems. Information technology allows individuals
to link to each other and to information repositories. This is likely to
involve change in the way the organisation operates. The contribution of teams
is seen par ticularly in internal projects, such as the development of
information systems.
A user committee enables the views of all the intended groups of users to be
represented. During the establishment of an MIS, the user committee meets
a number of times to monitor and advise on the system and the establishment
process, ensuring that users’ needs are well addressed.
When the system is operational, the committee needs to meet less frequently.
Its role then shifts to monitoring how the system serves its users and agreeing
on behalf of all on any changes to the system. Any suggestions are passed to
the system administrators for implementation. External users may best be
served by occasionally sending them a questionnaire followed up by
consultation by one or two interviewers in their own office.
6.9.3 Managing User Expectations
MIS development projects have a high failure rate because the users of a
system are dissatisfied with it as it does not meet their expectations.
What is the cause and effect relationship between expectations and failure?
No doubt, a poorly designed system will fail to meet expectations. But
sometimes users have unrealistic expectations without regard for constraints
of budget, time, manpower, etc., and the best system that developers could
produce will go unused because it doesn’t meet these high expectations. In
this latter case, the expectations were actually the cause of the failure, not
the other way round. Perception can be more important than reality.
Managers of MIS development projects have two things to manage: the
development of the system and the perception of the system. In earlier sections
we have discussed the methodologies for project development without any
reference to managing user expectations. However it is an integral part of the
MID development project. In this section we will cover this very important
aspect of project development activities.
First we will consider the importance of managing user expectations. Then
we will explore several strategies for managing user expectations. In looking
at these strategies, we will discuss which strategies are appropriate in which
situations. In conclusion, we will contemplate whether there are any “right”
or “better” strategies.
97/MITSDE
Importance of Managing User Expectations
The importance of the users’ involvement has been recognised at least for a
long time. Yet in many traditional discussions of MIS development, it has not
received adequate attention. The available evidence based on experience of
many MIS development projects shows that the apparent cause of many system
failures is user dissatisfaction with system scope, goals, or the system’s general
orientation to the business problem. MIS and MIS implementation failure
may well result from the improper management of user expectations.
In the following sections we will take a look at some techniques for managing
user expectations. We will consider traditional as well as current thinking on
the topic.
Documentation: The traditional approach to managing user expectations
has been a rather legalistic one. “Write down the customer’s requirements
and get the customer to agree with what you wrote.” The idea has been “let’s
make sure we document what we’re doing with the system. Then we will
have the customer sign off on the document. That way we’re covered.”
The documentation ef fort, at least in the beginning, was probably well-
intentioned. Conventional wisdom says that if the requirements of the system
are properly defined in the requirements stage of development, the resulting
system will be right. The inherent assumption is that if the system is designed
right, users will appreciate it.
Managers of system development realised that discrepancies arose between
the computer department’s view of the system and the user’s view. They felt
users didn’t know what they wanted, didn’t know what they needed, and didn’t
know what to expect when their systems were delivered. So project managers
focused on making documentation complete and detailed. The thinking is
“the users do not understand the systems we are creating”.
Even in the most methodically managed projects, stable requirements simply
do not exist. Early efforts to manage the customer focused not on managing
expectations but instead on controlling change. Project managers noticed that
users changed their requirements frequently. To fix the problem, they thought,
we must put restrictions on how changes take place to the system and
formalise the process.
These documentation-oriented methods are also very much practiced today.
They are very suitable in a contracting or consulting type situation in which
the customer is a separate legal entity from the company who is creating the
system for them. In this case, a legal contract is needed, and it is appropriate
to detail the deliverables in documents, legally binding or not. But the legalistic
approach seems less appropriate when the systems department and the users
work for the same organisation. Users may develop negative judgments about
the systems department precisely because they think the systems department
is treating them as adversaries.
A more elementary problem with this type of documentation is that often
users don’t understand it. If the documentation is not helping the users, it
serves only the confrontational purpose of shielding the systems department
from official accusations of incompetence; if no sign-off is obtained, even that
purpose is not served. Documentation remains an important part of the
systems development process, but it does not always serve the purpose of
managing user expectations.
98/MITSDE
Management Information System
Educate Users: The MIS project team must realise that it exists solely to
serve the information needs of users. If some changes are required by the
users they have to accept that and deliver what they need on time. This
approach is more cooperative than insisting that users must specify all their
requirements correctly and completely in advance. But it still doesn’t
emphasise the need for users to know how the IT technology or the systems
people work. Rather than making the processes of the systems department
some sort of mystery, it is better to educate the customer about processes
and the constraints in which systems people work.
The most important area about which to educate customers is the impact of
change. If the users and other stakeholders don’t understand the importance
of a requirements change, requirements discovery can lead to requirements
creep. The project manager must understand the MIS team’s development
lifecycle model and be able to explain it to the customers and stakeholders in
conceptual (rather than technical) terms. Let users know that there is always
a trade-off between cost, speed and reliability, convey the concept of “good-
enough” software. Educate users on how changes affect the cost of the project
and show them the benefit of deferring changes to future releases of the
application. Explain to the users that there will be problems.
It is very important to ensure that the developers are educated. Know the
users and their business well. Users will have more respect for developers
who know their business and will accept bad news from them more readily.
The education of both parties helps in making sure you speak the same
language.
When is the strategy of educating users not appropriate? Well, sometimes
users are going to want the short version of the story, the short answer to
their questions. If you start rambling about the parameters in which you are
working, users may think you are waffling. Also, you are limited in how
much time you can devote to this education process, both of the users’ time
and your time. The golden rule is: use the strategy of education unless you
have a specific reason not to use it.
Communicate Well with Users
Merely viewing the users as those to be educated is still a slightly
condescending approach. The idea behind expectations management is to
orchestrate the relationship. Good communication is central to the
relationship. How can MIS developers develop a good communication
relationship with users?
Honesty and forthrightness tend to work better than secrecy, but when
appropriate, it is all right to be diplomatic. Don’t assume that every request
must be fulfilled, but if possible, don’t just say no to requests that are out-of-
bounds. Instead, suggest a viable alternative. Explain the cost implications
of what they are asking while remaining sympathetic. It’s okay to help users
see your point of view and communicate what is feasible. Being asked to
provide a business justification for technology requests will help to separate
users’ wants from true needs.
In the traditional view of systems development, the requirements could be
gathered early in the process; then the developers would go away and develop
the system and the user might not see them again until the presentation of a
99/MITSDE
finished product. This linear view of systems development has been going out
of favour over the years in support of a more incremental approach. Determining
requirements is often a process of discovery. The contact with the users and
their involvement should be ongoing. Information systems development is
substantially different from many other product development efforts, provides
more opportunities to develop and manage user expectations. User perception
of participation in the development process is the most significant influence
on user satisfaction. Even after the system has been implemented, MIS people
should monitor users to see if they are happy and if requirements are changing,
and act on the feedback. Furthermore, the communication should be two-way.
Regular reporting on project status is essential: report successes, but also
report problems before they become crises.
The tactic of reporting deserves special attention. Keeping users abreast of
developments means they will rest easier, they will not be surprised by
outcomes, and they will be more convinced that the project is being well
managed; as a result, users’ attitudes toward the project will be better. Reports
should list accomplishments, issues, and metrics. Accomplishments can be
mundane but essential such as getting the team e-mail access. Issues are
potential obstacles to the project; this is where it is necessary to warn users
that something bad might happen. The metrics section is perhaps the most
crucial section of the report. It is important to have objective measures for
evaluating the progress of the project. Making goals objectively measurable
goes along with the idea of documenting to manage expectations. If users
know what concrete outcomes to expect, their expectations will be more
realistic. When they see concrete results, they will be more satisfied.
Measurements should address business issues, not merely technical ones.
Like educating users, communicating with users should be done whenever
possible. The only caution is again not to take up excessive amounts of users’
time. Reports should generally be written or electronic documents that are
brief may simply feature bullet-point lists. Such a document gives them freedom
to decide how much time to devote to reading the documents. Meeting weekly
for an hour to tell users how things are going might be excessive. Likewise,
when gathering information, use the most efficient means possible.
Prototyping: We have looked at various strategies for managing user
expectations: Clarify user requirements through detailed documentation. Have
users sign off on the requirements definition as well as any changes. Educate
users on the way systems development works. Communicate with users and
involve them in the process throughout the project life cycle. Report to users
on how the project is coming along. All these strategies may prepare users
to expect what is realistic and be more satisfied with it. If we take these ideas
a step further, wouldn’t it be nice if users could have a preview of what the
system will be like and have the opportunity to comment on it? That is precisely
the idea behind prototyping.
Prototyping means building a working model of the system. A prototype
doesn’t do everything the final system will do. Rather, it simulates some of
the essential features. For example, the user might be able to see how the
interface will look with regards to screen layout, menus, buttons, etc. Maybe
all of the buttons don’t work. Probably, the system is not connected to the
production database, so maybe only some phony data can be retrieved. But
the essence of the system is represented.
100/MITSDE
Management Information System
The prototype can be a great tool for zeroing in on users’ needs. Prototyping
has many benefits. It accommodates the communication style of the user instead
of the developer. The prototype gives the user and the developer some concrete
base to facilitate discussion, greatly alleviating communication problems and
misunderstanding. A prototype is much easier for a user to evaluate than a
requirements definition because it is closer to their everyday experience.
Instead of users being disappointed at the end of a project when the system
doesn’t do what it should, they are excited at being involved with developing
something new. With regard to cost, on the face of it this sounds inefficient
and expensive, but there are few things more expensive than a system which
the users will not use. Research has shown that prototyping leads to better
designs, better matches with user needs, and improved maintainability.
The benefits of prototyping are clear, and we may be tempted to think of the
prototype as a silver bullet. Although Bernard Boar is a strong proponent of
prototyping, he offers guidelines for when to use the technique and when not
to use it. A good candidate system for prototyping is not batch processing in
nature but rather full-screen periodic database reporting and interfacing;
prototyping helps most with developing a good user/machine interface.
Operational support and record management systems are good candidates
while heavily algorithmic systems and those for decision support and ad-hoc
retrieval and analysis are not; in other words, good candidates “are the
business” not “about the business.” Because of the time and resources
necessary, prototyping is not recommended for “crash” projects.
The characteristics of the users are important when deciding whether to use
prototyping. Although satisfying, prototyping requires users to devote
substantial resources to refining the model. Users should be sold on the
prototyping concept, having been dissatisfied with the pre-specification
experience. The users must be willing and able to make decisions. When a
model is ready to be reviewed, the process comes to a loud and visible halt if
nobody will review it.
6.9.4 Critical Issues for MIS Development and Operation
Although many organisations receive significant benefits from their MIS, these
still are high-risk / high-return systems, as shown by the large number of
unsuccessful MIS projects. Not only are MIS prone to fail, they can fail at any
point in the system’s lifetime. This should prompt companies to take the
issue of critical success factors seriously in developing their MIS. The following
is a suggested list-
• The MIS should be developed in response to and / or support a specific
business need. There needs to be a perceived need for such a system
within the organisation
• An executive sponsor who champions the project is crucial. There needs
to be a patron or sponsor in top management. Convinced of the need for
the system, the sponsor is able and willing to demand that the required
inputs for the system are made available and that outputs from the
system are delivered on time. He or she does not necessarily need to be
a direct user but will use, and demand, its outputs. A sponsor needs to
have a good overview of the system, what it entails in staff time, and
what it can do for the organisation and its employees.
101/MITSDE
• Managers and other employees affected by the proposed MIS need to
be integrated into the development and implementation and use of the
system.
• MIS support staff must have the necessary technical, business, and
interpersonal skills.
• MIS should achieve the desired objectives in as simple a way as possible.
Temptation to include more and more data items, or whole new modules,
into the system should generally be avoided. Systems are more likely to
fail due to too great a complexity than to simplicity. One useful rule is
not to admit new entities unless both, use and a user are identified.
• Effective data management is essential for the data to be relevant,
accurate, and attractively presented.
• A prototype must be released soon to capture executive interest while
it is still high.
• The system must be easy to use and navigate, requiring virtually no
training of users.
• Response time must be extremely fast.
• The MIS implementation should itself have goals, defined qualitatively,
quantitatively, and by time.
• Training in effective use of MIS must be provided for all managers
including top management. They all need to have a good knowledge of
the system’s contents and functions in order to exploit the system well
in management processes of planning, budgeting, monitoring, report
writing, and evaluation.
• The MIS should soon produce useful outputs that can be used by all
managers. This is the whole purpose of the system. If neglected, the
support of these constituencies will wane as most MIS information
declines in value with time.
• Once established, the system needs to be institutionalised, i.e., integrated
into the management processes of planning, decision-making, and
monitoring. This is crucial because it fulfills the primary reason for
having an MIS.
Summing Up
This chapter described the processes for designing, developing and
implementing MIS. It identified the difficulties of developing effective MIS,
then it discussed the techniques of determining management information
needs. This included approaches such as business systems planning, critical
success factor (CSF) method, and end/means (E/M) analysis. The chapter
also describes the systems life cycle development (SDLC) methodology as an
ordered approach for developing MIS. It also discussed the systems analysis
and design approach used for design and development of information systems.
Further, it explained the methods of effective management of MIS projects. It
discussed ways of managing user expectations in MIS development projects.
Self-assessment
1. What is the difference between systems analysis and systems design?
102/MITSDE
Management Information System
2. Name and describe various stages of systems development life cycle.
3. What is feasibility? Describe the purpose and areas of study to be
covered in an MIS feasibility study.
4. What is meant by the design stage?
5. Why has prototyping become a popular way to develop e-business
applications? What are the advantages and disadvantages of prototyping?
6. Describe in brief different methods of requirement determination.
7. Discuss the considerations for choosing the right method of requirement
determination.
8. Discuss the importance of people side of MIS development project.
9. How are critical success factors (CSF) used to determine management
information needs?
References
1. James A. Senn. Analysis and Design of Information Systems. Singapore,
McGraw-Hill Publishing Company, Second Edition, 1989.
2. Laudon and Laudon. Management Information System, 7th Edition;
Pearson Education Asia.
3. Robert Schultheis and Mary Sumner. Management Information System.
New Delhi, Tata McGraw-Hill Publishing Company Limited, Second
Edition, 2003.
4. Turban, Leidner, McLean, Wetherbe. Information Technology For
Management. John Wiley & Sons 5th Edition