What role does the Information Systems Steering Committee play in the systems development process?

(introduction...)

UNIT 4: LEARNING OBJECTIVES

Once you have learnt this unit, you will be able to:

1. Understand and explain the MIS project management process and elements.

2. Describe stages of the system development life cycle (SDLC).

3. Know about MIS maintenance to maximize its utilization.

4.1 MIS project management

A typical functional organization structure for MIS projects, comprising of a steering committee and project team, is discussed below.

4.1.1 Steering committee for control and distribution

A management steering committee should be established to oversee the control and direction of MIS activities and projects. The committee should be chaired by a senior manager, preferably the chief executive officer, and be composed of a representative selection of management. The internal auditor should be a member to help to ensure that adequate controls on information are provided for, as well as to ensure that audit requirements are fully addressed. The composition of such a committee can vary. For instance, when the topic to be discussed is MIS priorities for the enterprise as a whole, there should be broad management representation. On the other hand, when the issue in question is sales reporting, the key participants should be from the sales and marketing departments.

The MIS manager/project manager should report to this committee on a functional basis and bring along such members of staff as are appropriate for a given meeting. The steering committee should agree on priorities, plans and related budgets for the information resource. Regular meetings should be held to review progress against plans, tackle problems and progressively examine, discuss and approve systems at their various stages of development in order to ensure that requirements are satisfied.

In addition to regular review meetings, special meetings may be held to review and approve, as appropriate, the satisfactory completion of milestones identified in the plan.

4.1.2 Project management and staffing

Although the enterprise may have a formal organizational structure in place for the MIS function, MIS development is best carried out on a project basis. At any given time, a number of MIS development projects may be under way, each with its own limited objectives and scope as well as the corresponding budget and schedule.

The project manager should be selected not only for his or her technical skills but for management ability as well. The project team should be composed of both MIS technical experts and user personnel who are familiar with their information requirements and can contribute their knowledge and efforts to the successful outcome of a given project.

Using a project management team

At the United States Printing Office in Washington, DC, an interdisciplinary team was set up to plan an information system when the public printer first said he wanted a system that would track the rapidly growing printing programme.

The Director of Information Resources formed a project team consisting of IS, finance and other professionals to draw up what it called a requirements document. According to the Director, there was “constant communication between IS and the project management team. We needed a group like the project management team because the systems analysts themselves don’t have the experience to understand the many disciplines involved, such as financial management and materials management.”

Source: Moad, 1988.

4.1.3 Systems development life cycle (SDLC)

A systems development life cycle (SDLC) is one term used for an organized approach to systems development, implementation, operation and maintenance. Once the system becomes obsolescent and/or ongoing, maintenance/operating costs over a few years exceed the estimated capital cost of a new system, and the cycle starts again. The SDLC methodology will be described in more detail in the following section.

4.1.4 Project milestones

As with any project type, management attention in the SDLC should focus principally on project milestones. At each milestone, management needs to be assured that the underlying tasks have been satisfactorily completed before giving approval to proceed to the next phase.

4.1.5 Documentation and reporting

The evidence of accomplishment in the SDLC should be in written form. The documentation and reporting produced during the life of a project constitutes the principal foundation on which management judgements, conclusions and decisions should be based. At certain milestones, such evidence should be supplemented by demonstrations and user tests on computer. The purpose of good documentation is not only to afford a basis for quality assurance but also to provide for continuity in development and maintenance. Further, it can help to avoid the situation whereby the enterprise can become totally dependent on a given individual or group and lay itself open to blackmail.

Traditionally, documentation has been the weakest element in systems development projects, which is why management must be particularly alert to any shortcomings in this area. The reason for documentation deficiencies is that talented developers want to spend their time on creative endeavor and not on the drudgery (they believe) of putting the results of their thought processes on paper. Actually, even a relatively small systems assignment tends to be of sufficient technical complexity to confound the human memory. Efforts are being made to automate the documentation process, notably through the development and application of CASE (computer-assisted systems engineering) tools. Current efforts focus on making it possible for CASE to generate application systems as well, a highly desirable progression!

The importance of following a sound SDLC methodology should not be underrated. As an analogy, imagine constructing a tall building without using architectural drawings or following a construction plan. The results would be a disaster! Yet this is precisely the way in which many enterprises have approached the relatively new discipline of developing, implementing and operating MIS systems. The unsatisfactory results might not be so obvious with the MIS systems, which are intellectual products, as they would be with a physical building. Nevertheless, the negative impact of unsatisfactory MIS systems is substantial and can cripple the management potential of the enterprise.

An SDLC methodology is a guideline for systematically developing MIS systems. The guidelines described in this module have been refined through practical experience in numerous MIS development projects and can be broken down into the major phases of: strategic planning; feasibility study; vendor selection; development; system testing; user training; implementation; operation; and periodic review. The SDLC may be further modified and adapted to suit management preferences, project characteristics and the MIS personnel in the individual enterprise.

4.2.1 Strategic planning

The MIS strategic plan should dovetail with, and be a component of, the business plan of the enterprise, and all elements in the SDLC should be planned and implemented in line with MIS strategy.

The process of producing the plan is similar to that described below in the next subsection; but the “study” is of the total organization’s requirements, and the outcomes and action plan become part of the organization’s strategy.

4.2.2 Feasibility study

The major activities in the feasibility study are discussed below.

Terms of reference. Terms of reference (TOR) need to be developed, discussed and agreed with management prior to launching the study proper. They should address: project objectives and scope; the background and series of events leading to the request for the study; the study approach, communications and reporting relationships; a description of the workplan to be followed together with the related schedule; project staffing, including participation by a steering committee and user counterpart personnel; and an estimate of associated costs and out-of-pocket expenses.

Orientation. Following management approval to proceed, the study team members should be phased out of their commitments so that they are available for their scheduled participation. The project steering committee, composed of senior individuals with a direct interest in the area under study, should be established and a chairman appointed. The members of the committee should be briefed on their roles and functional responsibilities.

The TOR study should be reviewed and refined, as appropriate, by the team. Interview guidelines, fact-gathering checklists and questionnaires should be prepared as appropriate. Review meetings should be scheduled with the steering committee at fortnightly or monthly intervals and aligned with project milestones. Suitable support arrangements should be made for office space, computer facilities, typing, photocopying, etc. Personnel affected should be made aware of the study and the overall mandate. Brief site visits and introductory meetings should be held with user management and counterpart personnel to complete the team’s initial orientation to the project.

Survey system. The survey system is carried out through interviews and fact gathering. Topics covered should examine the present situation, from a systems viewpoint, together with the perceived problems and the interviewees’ suggestions for improvement. Copies of pertinent forms and reports should be gathered during the interview itself or arrangements made for subsequent pick-up/delivery. Interviews should be supplemented by physically following the existing systems and paper trails, where appropriate. A first-hand view can best be obtained by talking to the people involved at their workplaces and having them explain the existing manual/mechanized procedures using current examples from work in progress. In addition to taking notes, the interviewer should again gather representative samples of any pertinent forms and reports. Depending on study objectives and scope, the type of documentation to be gathered or reviewed includes historical financial statements; business plans and strategies; policy and procedure manuals; documentation on existing computer systems; organizational structure, job descriptions and staffing levels; original blank sets of forms handled and photocopies of selected completed specimens illustrating their usage; sample copies of reports produced; and pertinent correspondence and other files.

The TOR study should determine the focus of the fact-gathering process.

Analysis. The analytical process should be carried out in parallel with the review and completed during this activity. The information gathered should be classified by selection component, summarized, and key information flows documented. Estimated transaction volumes, file sizes and report printing requirements should be assessed. An analysis of strengths, weaknesses and opportunities for improvement should be carried out in each of the various MIS components. Existing manual processes should be critically reviewed. Possibilities for abolishing certain process steps need to be evaluated. MIS components should be based on best practice and not necessarily on the existing operating practices. The analysis should be the subject of a workshop presentation to members of the steering committee and other interested parties. The workshop should provide an opportunity for a full discussion with the objective of gaining a general group consensus on the present situation as it pertains to the MIS area under study. The results of the workshop review should be documented in memo form and circulated to the participants.

Definition of requirements. The opportunities for improvement identified in the previous activity should be developed into a set of MIS requirements that need to be satisfied. The requirements should be placed in order of priority according to business needs and with due regard to a logical development sequence. The definition of requirements should be reviewed and agreed with the steering committee.

Conceptual design. A conceptual systems design should be developed to satisfy the definition of requirements. However, this activity may be bypassed if a package solution is anticipated. The design should include the following components: application relationships; database file structure showing the principal input transactions; data dictionary of fields to be recorded in the database and including name, description and other attributes; a cross-reference chart of files versus data elements; and a system flowchart and narrative for mechanized applications (this component may optionally be deferred to the detailed design step).

Various design methodologies may be used instead of, or in addition to, those illustrated here. The designer should feel free to use the tools with which he or she feels most comfortable, although a minimum set of standards should be adhered to in a given enterprise.

Increasingly sophisticated CASE (computer-assisted systems engineering) tools are becoming available to automate MIS design tasks. The more advanced methods are claimed to convert CASE design specifications to operational computer systems.

Alternatives. Numerous alternatives may be available to implement the systems concept, particularly as regards computerization. Typical alternatives to be considered, either alone or in combination, include centralized versus decentralized computing; class(es) of computer(s) to be used (mainframes, minis, micros); package or custom solution; operating system and language(s) to be used; in-house versus contract development; and data communications protocol(s) to be used.

The most promising alternatives should be identified and reviewed here in terms of advantages and disadvantages. The best combination, from a cost/benefit viewpoint, should be identified and justified in some detail.

Cost/benefit considerations. The costs of implementation and operation of a selected alternative should be estimated. The estimates should include a provision for cost overruns, typically 15-30 per cent. The corresponding tangible and intangible benefits of the new or revised MIS should be assessed. Where practicable, the benefits should be quantified in financial terms by user management. In some cases the requirements are of a “must have” nature and the quantified benefits tend to be immaterial.

Conclusions and recommendations. Based on the study findings, the study team’s conclusions and recommendations should be developed as to feasibility, scope and approach to the desired MIS. Where appropriate, a list of up to a dozen qualified vendors should be identified who could be approached for the supply of necessary hardware, software and services to support the recommendations.

Action plan. Assuming that the recommendations are to proceed with implementation, an action plan should be developed to carry out subsequent steps and activities. This plan should be based on subsequent SDLC guidelines covered in this module. The action plan should be refined and updated on a continuous basis throughout the life of the SDLC to reflect actual progress as against current plans.

Reporting. The study findings, conclusions and recommendations should be outlined and presented verbally to the steering committee. Following a full discussion, the study results should be refined and summarized in a written report.

4.2.3 Vendor selection

Following management approval, this step in the SDLC is aimed at achieving maximum benefits from optimum investment in the selection of suppliers of hardware, software and other services as appropriate.

The benefits of a turnkey approach should not be overlooked. The guidelines that follow apply to both single and multiple purchases.

Request for proposal. A written request for proposal (RFP), based on the feasibility study document, should be prepared for major expenditures, covering the following points: scope and purpose; guidelines for submission; evaluation criteria; requirements; conceptual design; and the action plan.

Cost should be examined separately.

Vendor briefings. A conference should take place within a week of issuing the RFP to provide a verbal overview and respond to questions for clarification.

Evaluation. Proposals should be scored against evaluation criteria and the results charted by score against cost. Care should be taken to ensure that “apples are compared with apples”.

On the basis of these results, up to three vendors should be shortlisted for final evaluation and selection through detailed discussion of their proposals and negotiation of their offers and costs. An agreement is then concluded with the selected vendor.

4.2.4 Development

MIS development implies the production of written specifications covering all aspects of the MIS. Detailed systems specifications (systems definition) should include:

1. Computer applications

- application relationships;- database file structure;- system flowchart;- menu content and structure;- video screen formats; and

- printer layouts.

2. Operating instructions

- schedules;- control procedures;

- back-up and archiving.

3. Clerical procedures

- flowcharts; and
- layouts of forms and documents.

4.2.5 System testing

The programme testing carried out during development is unlikely to lead to reliable application. System testing should therefore be carried out by users, assisted by the development team.

Any problems should be corrected by the development team and the test run again until runs of both high-volume and low-volume test data yield flawless results.

4.2.6 User training

Users should be trained on the operation and utilization of MIS applications through classroom instruction, supplemented by on-the-job pilot operation using small samples of regular transactions.

4.2.7 Implementation

Pre-implementation activities may call for site preparation and equipment installation. Once the above steps have been satisfactorily completed, a parallel run should be undertaken with both sets of procedures - existing and new.

This needs to be carefully planned to cope with a worst case scenario of 100 per cent increasing workload for a period of two or three months.

4.2.8 Ongoing operation and maintenance

A well-conceived MIS should settle down to a smooth and reliable operation. Ongoing maintenance should then be required to correct any problems uncovered during operations, to introduce enhancements and develop updates in line with changing business needs.

A formal request procedure should be put in place for scheduling and control of the maintenance function.

4.2.9 Periodic review

An independent review of the MIS should be carried out on an annual basis and, as requested, to determine the degree to which the system is satisfying its objectives.

The review should determine whether any corrective action is a maintenance matter and one requiring a fresh SDLC cycle; for capital budgeting purposes, MIS investments should be deemed to have a life of three to five years.

Checklist 6: Systems development

1. Defining the need

- What is your organization’s approach to the assessment and upgrading of its existing systems?

- How often is there a full-scale appraisal of your MIS systems?

2. An organized approach

- When a major review is undertaken, what is the process of analysis, selection and implementation?

- How does this compare with the SDLC model described in section 4.2?

3. In retrospect

- What are the strengths and weaknesses of recent MIS system changes in your organization?

- What has been learned by senior management, implementers and users?

4.3 System maintenance: day-to-day productivity

Another reason why the size of investment in IT fails to correlate with higher productivity is that big spenders often become excited about the latest technology but neglect to maximize the effectiveness of existing systems.

Such investments are often technology-driven rather than business-driven and, of course, we need both. This is probably where you, personally, can make your greatest contribution. You are probably not a technical person, nor are you, yet, the chief executive.

4.3.1 You - The internal client

We hope that this module will enable you, more effectively, to behave as an “internal client” of your MIS department, ensuring that you have the best and most appropriate hardware available in the company; the software packages are the latest versions; and you and your staff are fully briefed on how to maximize the benefits of the system.

4.3.2 Maximizing utilization

Today’s computers and telecommunications equipment are tremendously powerful machines with extensive ranges of capability and prodigious memories. But that capability is rarely used. For example, are you using the potential of your word processing system to reduce filing of documents? Did you even realize you could do so? What percentage of the facilities on your digital telephone do you use? Have you set up so-called “macros” which allow you to display the most important forms, letters, etc., on your screen without having to generate this information over and over again? Have managers changed their working styles or do they still, for example, provide handwritten draft text to be typed by secretaries and changed over and over again (because it seems so much easier with word processing!)? Learn everything you can about the capability of your systems and ask yourself and your staff whether an operation could be more quickly, easily and reliably done on the system. If so, what has to be done to automate it?

4.3.3 Good housekeeping

This is a major responsibility of computer users and, if neglected, can cut productivity to shreds or worse, lose precious information vital to the survival of the firm. Most productivity improvements are the result of incremental, day-by-day actions. Good housekeeping means saving files, creating back-up records, getting rid of files no longer used, logging information for speedy retrieval, and so on. Ensure that you and your staff have regular coaching sessions on good housekeeping - little things mean a lot!

Checklist 7: Day-to-day productivity

1. System assessment

- Discuss, with other managers, the hardware and software they use:

- Is it faster, more user friendly, more flexible than yours?
- How do they get the best from it?

2. System capability

- Are you aware of the full capability of your computers, telephones and networks? Calculate what percentage of their capability is used/not used.

3. Housekeeping

- How satisfied are you that you and your staff use the system efficiently:

- Filing and storing in a disciplined way?- Maximizing speed of retrieval?

- Deleting out-of-date files?

4. Your role as internal client

- Meet the staff of your MIS department and agree on a plan for:

- Upgrading your department’s system;

- Regular briefings for your staff on maximizing the system’s benefits and on good housekeeping.

Questions for discussion

1. What does MIS installation mean?2. What are the main MIS project management elements?3. What is the role of the SDLC?

4. What are the main components of MIS maintenance?


Page 2

The importance of following a sound SDLC methodology should not be underrated. As an analogy, imagine constructing a tall building without using architectural drawings or following a construction plan. The results would be a disaster! Yet this is precisely the way in which many enterprises have approached the relatively new discipline of developing, implementing and operating MIS systems. The unsatisfactory results might not be so obvious with the MIS systems, which are intellectual products, as they would be with a physical building. Nevertheless, the negative impact of unsatisfactory MIS systems is substantial and can cripple the management potential of the enterprise.

An SDLC methodology is a guideline for systematically developing MIS systems. The guidelines described in this module have been refined through practical experience in numerous MIS development projects and can be broken down into the major phases of: strategic planning; feasibility study; vendor selection; development; system testing; user training; implementation; operation; and periodic review. The SDLC may be further modified and adapted to suit management preferences, project characteristics and the MIS personnel in the individual enterprise.

4.2.1 Strategic planning

The MIS strategic plan should dovetail with, and be a component of, the business plan of the enterprise, and all elements in the SDLC should be planned and implemented in line with MIS strategy.

The process of producing the plan is similar to that described below in the next subsection; but the “study” is of the total organization’s requirements, and the outcomes and action plan become part of the organization’s strategy.

4.2.2 Feasibility study

The major activities in the feasibility study are discussed below.

Terms of reference. Terms of reference (TOR) need to be developed, discussed and agreed with management prior to launching the study proper. They should address: project objectives and scope; the background and series of events leading to the request for the study; the study approach, communications and reporting relationships; a description of the workplan to be followed together with the related schedule; project staffing, including participation by a steering committee and user counterpart personnel; and an estimate of associated costs and out-of-pocket expenses.

Orientation. Following management approval to proceed, the study team members should be phased out of their commitments so that they are available for their scheduled participation. The project steering committee, composed of senior individuals with a direct interest in the area under study, should be established and a chairman appointed. The members of the committee should be briefed on their roles and functional responsibilities.

The TOR study should be reviewed and refined, as appropriate, by the team. Interview guidelines, fact-gathering checklists and questionnaires should be prepared as appropriate. Review meetings should be scheduled with the steering committee at fortnightly or monthly intervals and aligned with project milestones. Suitable support arrangements should be made for office space, computer facilities, typing, photocopying, etc. Personnel affected should be made aware of the study and the overall mandate. Brief site visits and introductory meetings should be held with user management and counterpart personnel to complete the team’s initial orientation to the project.

Survey system. The survey system is carried out through interviews and fact gathering. Topics covered should examine the present situation, from a systems viewpoint, together with the perceived problems and the interviewees’ suggestions for improvement. Copies of pertinent forms and reports should be gathered during the interview itself or arrangements made for subsequent pick-up/delivery. Interviews should be supplemented by physically following the existing systems and paper trails, where appropriate. A first-hand view can best be obtained by talking to the people involved at their workplaces and having them explain the existing manual/mechanized procedures using current examples from work in progress. In addition to taking notes, the interviewer should again gather representative samples of any pertinent forms and reports. Depending on study objectives and scope, the type of documentation to be gathered or reviewed includes historical financial statements; business plans and strategies; policy and procedure manuals; documentation on existing computer systems; organizational structure, job descriptions and staffing levels; original blank sets of forms handled and photocopies of selected completed specimens illustrating their usage; sample copies of reports produced; and pertinent correspondence and other files.

The TOR study should determine the focus of the fact-gathering process.

Analysis. The analytical process should be carried out in parallel with the review and completed during this activity. The information gathered should be classified by selection component, summarized, and key information flows documented. Estimated transaction volumes, file sizes and report printing requirements should be assessed. An analysis of strengths, weaknesses and opportunities for improvement should be carried out in each of the various MIS components. Existing manual processes should be critically reviewed. Possibilities for abolishing certain process steps need to be evaluated. MIS components should be based on best practice and not necessarily on the existing operating practices. The analysis should be the subject of a workshop presentation to members of the steering committee and other interested parties. The workshop should provide an opportunity for a full discussion with the objective of gaining a general group consensus on the present situation as it pertains to the MIS area under study. The results of the workshop review should be documented in memo form and circulated to the participants.

Definition of requirements. The opportunities for improvement identified in the previous activity should be developed into a set of MIS requirements that need to be satisfied. The requirements should be placed in order of priority according to business needs and with due regard to a logical development sequence. The definition of requirements should be reviewed and agreed with the steering committee.

Conceptual design. A conceptual systems design should be developed to satisfy the definition of requirements. However, this activity may be bypassed if a package solution is anticipated. The design should include the following components: application relationships; database file structure showing the principal input transactions; data dictionary of fields to be recorded in the database and including name, description and other attributes; a cross-reference chart of files versus data elements; and a system flowchart and narrative for mechanized applications (this component may optionally be deferred to the detailed design step).

Various design methodologies may be used instead of, or in addition to, those illustrated here. The designer should feel free to use the tools with which he or she feels most comfortable, although a minimum set of standards should be adhered to in a given enterprise.

Increasingly sophisticated CASE (computer-assisted systems engineering) tools are becoming available to automate MIS design tasks. The more advanced methods are claimed to convert CASE design specifications to operational computer systems.

Alternatives. Numerous alternatives may be available to implement the systems concept, particularly as regards computerization. Typical alternatives to be considered, either alone or in combination, include centralized versus decentralized computing; class(es) of computer(s) to be used (mainframes, minis, micros); package or custom solution; operating system and language(s) to be used; in-house versus contract development; and data communications protocol(s) to be used.

The most promising alternatives should be identified and reviewed here in terms of advantages and disadvantages. The best combination, from a cost/benefit viewpoint, should be identified and justified in some detail.

Cost/benefit considerations. The costs of implementation and operation of a selected alternative should be estimated. The estimates should include a provision for cost overruns, typically 15-30 per cent. The corresponding tangible and intangible benefits of the new or revised MIS should be assessed. Where practicable, the benefits should be quantified in financial terms by user management. In some cases the requirements are of a “must have” nature and the quantified benefits tend to be immaterial.

Conclusions and recommendations. Based on the study findings, the study team’s conclusions and recommendations should be developed as to feasibility, scope and approach to the desired MIS. Where appropriate, a list of up to a dozen qualified vendors should be identified who could be approached for the supply of necessary hardware, software and services to support the recommendations.

Action plan. Assuming that the recommendations are to proceed with implementation, an action plan should be developed to carry out subsequent steps and activities. This plan should be based on subsequent SDLC guidelines covered in this module. The action plan should be refined and updated on a continuous basis throughout the life of the SDLC to reflect actual progress as against current plans.

Reporting. The study findings, conclusions and recommendations should be outlined and presented verbally to the steering committee. Following a full discussion, the study results should be refined and summarized in a written report.

4.2.3 Vendor selection

Following management approval, this step in the SDLC is aimed at achieving maximum benefits from optimum investment in the selection of suppliers of hardware, software and other services as appropriate.

The benefits of a turnkey approach should not be overlooked. The guidelines that follow apply to both single and multiple purchases.

Request for proposal. A written request for proposal (RFP), based on the feasibility study document, should be prepared for major expenditures, covering the following points: scope and purpose; guidelines for submission; evaluation criteria; requirements; conceptual design; and the action plan.

Cost should be examined separately.

Vendor briefings. A conference should take place within a week of issuing the RFP to provide a verbal overview and respond to questions for clarification.

Evaluation. Proposals should be scored against evaluation criteria and the results charted by score against cost. Care should be taken to ensure that “apples are compared with apples”.

On the basis of these results, up to three vendors should be shortlisted for final evaluation and selection through detailed discussion of their proposals and negotiation of their offers and costs. An agreement is then concluded with the selected vendor.

4.2.4 Development

MIS development implies the production of written specifications covering all aspects of the MIS. Detailed systems specifications (systems definition) should include:

1. Computer applications

- application relationships;- database file structure;- system flowchart;- menu content and structure;- video screen formats; and

- printer layouts.

2. Operating instructions

- schedules;- control procedures;

- back-up and archiving.

3. Clerical procedures

- flowcharts; and
- layouts of forms and documents.

4.2.5 System testing

The programme testing carried out during development is unlikely to lead to reliable application. System testing should therefore be carried out by users, assisted by the development team.

Any problems should be corrected by the development team and the test run again until runs of both high-volume and low-volume test data yield flawless results.

4.2.6 User training

Users should be trained on the operation and utilization of MIS applications through classroom instruction, supplemented by on-the-job pilot operation using small samples of regular transactions.

4.2.7 Implementation

Pre-implementation activities may call for site preparation and equipment installation. Once the above steps have been satisfactorily completed, a parallel run should be undertaken with both sets of procedures - existing and new.

This needs to be carefully planned to cope with a worst case scenario of 100 per cent increasing workload for a period of two or three months.

4.2.8 Ongoing operation and maintenance

A well-conceived MIS should settle down to a smooth and reliable operation. Ongoing maintenance should then be required to correct any problems uncovered during operations, to introduce enhancements and develop updates in line with changing business needs.

A formal request procedure should be put in place for scheduling and control of the maintenance function.

4.2.9 Periodic review

An independent review of the MIS should be carried out on an annual basis and, as requested, to determine the degree to which the system is satisfying its objectives.

The review should determine whether any corrective action is a maintenance matter and one requiring a fresh SDLC cycle; for capital budgeting purposes, MIS investments should be deemed to have a life of three to five years.

Checklist 6: Systems development

1. Defining the need

- What is your organization’s approach to the assessment and upgrading of its existing systems?

- How often is there a full-scale appraisal of your MIS systems?

2. An organized approach

- When a major review is undertaken, what is the process of analysis, selection and implementation?

- How does this compare with the SDLC model described in section 4.2?

3. In retrospect

- What are the strengths and weaknesses of recent MIS system changes in your organization?

- What has been learned by senior management, implementers and users?


Page 3

(introduction...)

UNIT 4: LEARNING OBJECTIVES

Once you have learnt this unit, you will be able to:

1. Understand and explain the MIS project management process and elements.

2. Describe stages of the system development life cycle (SDLC).

3. Know about MIS maintenance to maximize its utilization.

4.1 MIS project management

A typical functional organization structure for MIS projects, comprising of a steering committee and project team, is discussed below.

4.1.1 Steering committee for control and distribution

A management steering committee should be established to oversee the control and direction of MIS activities and projects. The committee should be chaired by a senior manager, preferably the chief executive officer, and be composed of a representative selection of management. The internal auditor should be a member to help to ensure that adequate controls on information are provided for, as well as to ensure that audit requirements are fully addressed. The composition of such a committee can vary. For instance, when the topic to be discussed is MIS priorities for the enterprise as a whole, there should be broad management representation. On the other hand, when the issue in question is sales reporting, the key participants should be from the sales and marketing departments.

The MIS manager/project manager should report to this committee on a functional basis and bring along such members of staff as are appropriate for a given meeting. The steering committee should agree on priorities, plans and related budgets for the information resource. Regular meetings should be held to review progress against plans, tackle problems and progressively examine, discuss and approve systems at their various stages of development in order to ensure that requirements are satisfied.

In addition to regular review meetings, special meetings may be held to review and approve, as appropriate, the satisfactory completion of milestones identified in the plan.

4.1.2 Project management and staffing

Although the enterprise may have a formal organizational structure in place for the MIS function, MIS development is best carried out on a project basis. At any given time, a number of MIS development projects may be under way, each with its own limited objectives and scope as well as the corresponding budget and schedule.

The project manager should be selected not only for his or her technical skills but for management ability as well. The project team should be composed of both MIS technical experts and user personnel who are familiar with their information requirements and can contribute their knowledge and efforts to the successful outcome of a given project.

Using a project management team

At the United States Printing Office in Washington, DC, an interdisciplinary team was set up to plan an information system when the public printer first said he wanted a system that would track the rapidly growing printing programme.

The Director of Information Resources formed a project team consisting of IS, finance and other professionals to draw up what it called a requirements document. According to the Director, there was “constant communication between IS and the project management team. We needed a group like the project management team because the systems analysts themselves don’t have the experience to understand the many disciplines involved, such as financial management and materials management.”

Source: Moad, 1988.

4.1.3 Systems development life cycle (SDLC)

A systems development life cycle (SDLC) is one term used for an organized approach to systems development, implementation, operation and maintenance. Once the system becomes obsolescent and/or ongoing, maintenance/operating costs over a few years exceed the estimated capital cost of a new system, and the cycle starts again. The SDLC methodology will be described in more detail in the following section.

4.1.4 Project milestones

As with any project type, management attention in the SDLC should focus principally on project milestones. At each milestone, management needs to be assured that the underlying tasks have been satisfactorily completed before giving approval to proceed to the next phase.

4.1.5 Documentation and reporting

The evidence of accomplishment in the SDLC should be in written form. The documentation and reporting produced during the life of a project constitutes the principal foundation on which management judgements, conclusions and decisions should be based. At certain milestones, such evidence should be supplemented by demonstrations and user tests on computer. The purpose of good documentation is not only to afford a basis for quality assurance but also to provide for continuity in development and maintenance. Further, it can help to avoid the situation whereby the enterprise can become totally dependent on a given individual or group and lay itself open to blackmail.

Traditionally, documentation has been the weakest element in systems development projects, which is why management must be particularly alert to any shortcomings in this area. The reason for documentation deficiencies is that talented developers want to spend their time on creative endeavor and not on the drudgery (they believe) of putting the results of their thought processes on paper. Actually, even a relatively small systems assignment tends to be of sufficient technical complexity to confound the human memory. Efforts are being made to automate the documentation process, notably through the development and application of CASE (computer-assisted systems engineering) tools. Current efforts focus on making it possible for CASE to generate application systems as well, a highly desirable progression!

The importance of following a sound SDLC methodology should not be underrated. As an analogy, imagine constructing a tall building without using architectural drawings or following a construction plan. The results would be a disaster! Yet this is precisely the way in which many enterprises have approached the relatively new discipline of developing, implementing and operating MIS systems. The unsatisfactory results might not be so obvious with the MIS systems, which are intellectual products, as they would be with a physical building. Nevertheless, the negative impact of unsatisfactory MIS systems is substantial and can cripple the management potential of the enterprise.

An SDLC methodology is a guideline for systematically developing MIS systems. The guidelines described in this module have been refined through practical experience in numerous MIS development projects and can be broken down into the major phases of: strategic planning; feasibility study; vendor selection; development; system testing; user training; implementation; operation; and periodic review. The SDLC may be further modified and adapted to suit management preferences, project characteristics and the MIS personnel in the individual enterprise.

4.2.1 Strategic planning

The MIS strategic plan should dovetail with, and be a component of, the business plan of the enterprise, and all elements in the SDLC should be planned and implemented in line with MIS strategy.

The process of producing the plan is similar to that described below in the next subsection; but the “study” is of the total organization’s requirements, and the outcomes and action plan become part of the organization’s strategy.

4.2.2 Feasibility study

The major activities in the feasibility study are discussed below.

Terms of reference. Terms of reference (TOR) need to be developed, discussed and agreed with management prior to launching the study proper. They should address: project objectives and scope; the background and series of events leading to the request for the study; the study approach, communications and reporting relationships; a description of the workplan to be followed together with the related schedule; project staffing, including participation by a steering committee and user counterpart personnel; and an estimate of associated costs and out-of-pocket expenses.

Orientation. Following management approval to proceed, the study team members should be phased out of their commitments so that they are available for their scheduled participation. The project steering committee, composed of senior individuals with a direct interest in the area under study, should be established and a chairman appointed. The members of the committee should be briefed on their roles and functional responsibilities.

The TOR study should be reviewed and refined, as appropriate, by the team. Interview guidelines, fact-gathering checklists and questionnaires should be prepared as appropriate. Review meetings should be scheduled with the steering committee at fortnightly or monthly intervals and aligned with project milestones. Suitable support arrangements should be made for office space, computer facilities, typing, photocopying, etc. Personnel affected should be made aware of the study and the overall mandate. Brief site visits and introductory meetings should be held with user management and counterpart personnel to complete the team’s initial orientation to the project.

Survey system. The survey system is carried out through interviews and fact gathering. Topics covered should examine the present situation, from a systems viewpoint, together with the perceived problems and the interviewees’ suggestions for improvement. Copies of pertinent forms and reports should be gathered during the interview itself or arrangements made for subsequent pick-up/delivery. Interviews should be supplemented by physically following the existing systems and paper trails, where appropriate. A first-hand view can best be obtained by talking to the people involved at their workplaces and having them explain the existing manual/mechanized procedures using current examples from work in progress. In addition to taking notes, the interviewer should again gather representative samples of any pertinent forms and reports. Depending on study objectives and scope, the type of documentation to be gathered or reviewed includes historical financial statements; business plans and strategies; policy and procedure manuals; documentation on existing computer systems; organizational structure, job descriptions and staffing levels; original blank sets of forms handled and photocopies of selected completed specimens illustrating their usage; sample copies of reports produced; and pertinent correspondence and other files.

The TOR study should determine the focus of the fact-gathering process.

Analysis. The analytical process should be carried out in parallel with the review and completed during this activity. The information gathered should be classified by selection component, summarized, and key information flows documented. Estimated transaction volumes, file sizes and report printing requirements should be assessed. An analysis of strengths, weaknesses and opportunities for improvement should be carried out in each of the various MIS components. Existing manual processes should be critically reviewed. Possibilities for abolishing certain process steps need to be evaluated. MIS components should be based on best practice and not necessarily on the existing operating practices. The analysis should be the subject of a workshop presentation to members of the steering committee and other interested parties. The workshop should provide an opportunity for a full discussion with the objective of gaining a general group consensus on the present situation as it pertains to the MIS area under study. The results of the workshop review should be documented in memo form and circulated to the participants.

Definition of requirements. The opportunities for improvement identified in the previous activity should be developed into a set of MIS requirements that need to be satisfied. The requirements should be placed in order of priority according to business needs and with due regard to a logical development sequence. The definition of requirements should be reviewed and agreed with the steering committee.

Conceptual design. A conceptual systems design should be developed to satisfy the definition of requirements. However, this activity may be bypassed if a package solution is anticipated. The design should include the following components: application relationships; database file structure showing the principal input transactions; data dictionary of fields to be recorded in the database and including name, description and other attributes; a cross-reference chart of files versus data elements; and a system flowchart and narrative for mechanized applications (this component may optionally be deferred to the detailed design step).

Various design methodologies may be used instead of, or in addition to, those illustrated here. The designer should feel free to use the tools with which he or she feels most comfortable, although a minimum set of standards should be adhered to in a given enterprise.

Increasingly sophisticated CASE (computer-assisted systems engineering) tools are becoming available to automate MIS design tasks. The more advanced methods are claimed to convert CASE design specifications to operational computer systems.

Alternatives. Numerous alternatives may be available to implement the systems concept, particularly as regards computerization. Typical alternatives to be considered, either alone or in combination, include centralized versus decentralized computing; class(es) of computer(s) to be used (mainframes, minis, micros); package or custom solution; operating system and language(s) to be used; in-house versus contract development; and data communications protocol(s) to be used.

The most promising alternatives should be identified and reviewed here in terms of advantages and disadvantages. The best combination, from a cost/benefit viewpoint, should be identified and justified in some detail.

Cost/benefit considerations. The costs of implementation and operation of a selected alternative should be estimated. The estimates should include a provision for cost overruns, typically 15-30 per cent. The corresponding tangible and intangible benefits of the new or revised MIS should be assessed. Where practicable, the benefits should be quantified in financial terms by user management. In some cases the requirements are of a “must have” nature and the quantified benefits tend to be immaterial.

Conclusions and recommendations. Based on the study findings, the study team’s conclusions and recommendations should be developed as to feasibility, scope and approach to the desired MIS. Where appropriate, a list of up to a dozen qualified vendors should be identified who could be approached for the supply of necessary hardware, software and services to support the recommendations.

Action plan. Assuming that the recommendations are to proceed with implementation, an action plan should be developed to carry out subsequent steps and activities. This plan should be based on subsequent SDLC guidelines covered in this module. The action plan should be refined and updated on a continuous basis throughout the life of the SDLC to reflect actual progress as against current plans.

Reporting. The study findings, conclusions and recommendations should be outlined and presented verbally to the steering committee. Following a full discussion, the study results should be refined and summarized in a written report.

4.2.3 Vendor selection

Following management approval, this step in the SDLC is aimed at achieving maximum benefits from optimum investment in the selection of suppliers of hardware, software and other services as appropriate.

The benefits of a turnkey approach should not be overlooked. The guidelines that follow apply to both single and multiple purchases.

Request for proposal. A written request for proposal (RFP), based on the feasibility study document, should be prepared for major expenditures, covering the following points: scope and purpose; guidelines for submission; evaluation criteria; requirements; conceptual design; and the action plan.

Cost should be examined separately.

Vendor briefings. A conference should take place within a week of issuing the RFP to provide a verbal overview and respond to questions for clarification.

Evaluation. Proposals should be scored against evaluation criteria and the results charted by score against cost. Care should be taken to ensure that “apples are compared with apples”.

On the basis of these results, up to three vendors should be shortlisted for final evaluation and selection through detailed discussion of their proposals and negotiation of their offers and costs. An agreement is then concluded with the selected vendor.

4.2.4 Development

MIS development implies the production of written specifications covering all aspects of the MIS. Detailed systems specifications (systems definition) should include:

1. Computer applications

- application relationships;- database file structure;- system flowchart;- menu content and structure;- video screen formats; and

- printer layouts.

2. Operating instructions

- schedules;- control procedures;

- back-up and archiving.

3. Clerical procedures

- flowcharts; and
- layouts of forms and documents.

4.2.5 System testing

The programme testing carried out during development is unlikely to lead to reliable application. System testing should therefore be carried out by users, assisted by the development team.

Any problems should be corrected by the development team and the test run again until runs of both high-volume and low-volume test data yield flawless results.

4.2.6 User training

Users should be trained on the operation and utilization of MIS applications through classroom instruction, supplemented by on-the-job pilot operation using small samples of regular transactions.

4.2.7 Implementation

Pre-implementation activities may call for site preparation and equipment installation. Once the above steps have been satisfactorily completed, a parallel run should be undertaken with both sets of procedures - existing and new.

This needs to be carefully planned to cope with a worst case scenario of 100 per cent increasing workload for a period of two or three months.

4.2.8 Ongoing operation and maintenance

A well-conceived MIS should settle down to a smooth and reliable operation. Ongoing maintenance should then be required to correct any problems uncovered during operations, to introduce enhancements and develop updates in line with changing business needs.

A formal request procedure should be put in place for scheduling and control of the maintenance function.

4.2.9 Periodic review

An independent review of the MIS should be carried out on an annual basis and, as requested, to determine the degree to which the system is satisfying its objectives.

The review should determine whether any corrective action is a maintenance matter and one requiring a fresh SDLC cycle; for capital budgeting purposes, MIS investments should be deemed to have a life of three to five years.

Checklist 6: Systems development

1. Defining the need

- What is your organization’s approach to the assessment and upgrading of its existing systems?

- How often is there a full-scale appraisal of your MIS systems?

2. An organized approach

- When a major review is undertaken, what is the process of analysis, selection and implementation?

- How does this compare with the SDLC model described in section 4.2?

3. In retrospect

- What are the strengths and weaknesses of recent MIS system changes in your organization?

- What has been learned by senior management, implementers and users?

4.3 System maintenance: day-to-day productivity

Another reason why the size of investment in IT fails to correlate with higher productivity is that big spenders often become excited about the latest technology but neglect to maximize the effectiveness of existing systems.

Such investments are often technology-driven rather than business-driven and, of course, we need both. This is probably where you, personally, can make your greatest contribution. You are probably not a technical person, nor are you, yet, the chief executive.

4.3.1 You - The internal client

We hope that this module will enable you, more effectively, to behave as an “internal client” of your MIS department, ensuring that you have the best and most appropriate hardware available in the company; the software packages are the latest versions; and you and your staff are fully briefed on how to maximize the benefits of the system.

4.3.2 Maximizing utilization

Today’s computers and telecommunications equipment are tremendously powerful machines with extensive ranges of capability and prodigious memories. But that capability is rarely used. For example, are you using the potential of your word processing system to reduce filing of documents? Did you even realize you could do so? What percentage of the facilities on your digital telephone do you use? Have you set up so-called “macros” which allow you to display the most important forms, letters, etc., on your screen without having to generate this information over and over again? Have managers changed their working styles or do they still, for example, provide handwritten draft text to be typed by secretaries and changed over and over again (because it seems so much easier with word processing!)? Learn everything you can about the capability of your systems and ask yourself and your staff whether an operation could be more quickly, easily and reliably done on the system. If so, what has to be done to automate it?

4.3.3 Good housekeeping

This is a major responsibility of computer users and, if neglected, can cut productivity to shreds or worse, lose precious information vital to the survival of the firm. Most productivity improvements are the result of incremental, day-by-day actions. Good housekeeping means saving files, creating back-up records, getting rid of files no longer used, logging information for speedy retrieval, and so on. Ensure that you and your staff have regular coaching sessions on good housekeeping - little things mean a lot!

Checklist 7: Day-to-day productivity

1. System assessment

- Discuss, with other managers, the hardware and software they use:

- Is it faster, more user friendly, more flexible than yours?
- How do they get the best from it?

2. System capability

- Are you aware of the full capability of your computers, telephones and networks? Calculate what percentage of their capability is used/not used.

3. Housekeeping

- How satisfied are you that you and your staff use the system efficiently:

- Filing and storing in a disciplined way?- Maximizing speed of retrieval?

- Deleting out-of-date files?

4. Your role as internal client

- Meet the staff of your MIS department and agree on a plan for:

- Upgrading your department’s system;

- Regular briefings for your staff on maximizing the system’s benefits and on good housekeeping.

Questions for discussion

1. What does MIS installation mean?2. What are the main MIS project management elements?3. What is the role of the SDLC?

4. What are the main components of MIS maintenance?


Page 4

The importance of following a sound SDLC methodology should not be underrated. As an analogy, imagine constructing a tall building without using architectural drawings or following a construction plan. The results would be a disaster! Yet this is precisely the way in which many enterprises have approached the relatively new discipline of developing, implementing and operating MIS systems. The unsatisfactory results might not be so obvious with the MIS systems, which are intellectual products, as they would be with a physical building. Nevertheless, the negative impact of unsatisfactory MIS systems is substantial and can cripple the management potential of the enterprise.

An SDLC methodology is a guideline for systematically developing MIS systems. The guidelines described in this module have been refined through practical experience in numerous MIS development projects and can be broken down into the major phases of: strategic planning; feasibility study; vendor selection; development; system testing; user training; implementation; operation; and periodic review. The SDLC may be further modified and adapted to suit management preferences, project characteristics and the MIS personnel in the individual enterprise.

4.2.1 Strategic planning

The MIS strategic plan should dovetail with, and be a component of, the business plan of the enterprise, and all elements in the SDLC should be planned and implemented in line with MIS strategy.

The process of producing the plan is similar to that described below in the next subsection; but the “study” is of the total organization’s requirements, and the outcomes and action plan become part of the organization’s strategy.

4.2.2 Feasibility study

The major activities in the feasibility study are discussed below.

Terms of reference. Terms of reference (TOR) need to be developed, discussed and agreed with management prior to launching the study proper. They should address: project objectives and scope; the background and series of events leading to the request for the study; the study approach, communications and reporting relationships; a description of the workplan to be followed together with the related schedule; project staffing, including participation by a steering committee and user counterpart personnel; and an estimate of associated costs and out-of-pocket expenses.

Orientation. Following management approval to proceed, the study team members should be phased out of their commitments so that they are available for their scheduled participation. The project steering committee, composed of senior individuals with a direct interest in the area under study, should be established and a chairman appointed. The members of the committee should be briefed on their roles and functional responsibilities.

The TOR study should be reviewed and refined, as appropriate, by the team. Interview guidelines, fact-gathering checklists and questionnaires should be prepared as appropriate. Review meetings should be scheduled with the steering committee at fortnightly or monthly intervals and aligned with project milestones. Suitable support arrangements should be made for office space, computer facilities, typing, photocopying, etc. Personnel affected should be made aware of the study and the overall mandate. Brief site visits and introductory meetings should be held with user management and counterpart personnel to complete the team’s initial orientation to the project.

Survey system. The survey system is carried out through interviews and fact gathering. Topics covered should examine the present situation, from a systems viewpoint, together with the perceived problems and the interviewees’ suggestions for improvement. Copies of pertinent forms and reports should be gathered during the interview itself or arrangements made for subsequent pick-up/delivery. Interviews should be supplemented by physically following the existing systems and paper trails, where appropriate. A first-hand view can best be obtained by talking to the people involved at their workplaces and having them explain the existing manual/mechanized procedures using current examples from work in progress. In addition to taking notes, the interviewer should again gather representative samples of any pertinent forms and reports. Depending on study objectives and scope, the type of documentation to be gathered or reviewed includes historical financial statements; business plans and strategies; policy and procedure manuals; documentation on existing computer systems; organizational structure, job descriptions and staffing levels; original blank sets of forms handled and photocopies of selected completed specimens illustrating their usage; sample copies of reports produced; and pertinent correspondence and other files.

The TOR study should determine the focus of the fact-gathering process.

Analysis. The analytical process should be carried out in parallel with the review and completed during this activity. The information gathered should be classified by selection component, summarized, and key information flows documented. Estimated transaction volumes, file sizes and report printing requirements should be assessed. An analysis of strengths, weaknesses and opportunities for improvement should be carried out in each of the various MIS components. Existing manual processes should be critically reviewed. Possibilities for abolishing certain process steps need to be evaluated. MIS components should be based on best practice and not necessarily on the existing operating practices. The analysis should be the subject of a workshop presentation to members of the steering committee and other interested parties. The workshop should provide an opportunity for a full discussion with the objective of gaining a general group consensus on the present situation as it pertains to the MIS area under study. The results of the workshop review should be documented in memo form and circulated to the participants.

Definition of requirements. The opportunities for improvement identified in the previous activity should be developed into a set of MIS requirements that need to be satisfied. The requirements should be placed in order of priority according to business needs and with due regard to a logical development sequence. The definition of requirements should be reviewed and agreed with the steering committee.

Conceptual design. A conceptual systems design should be developed to satisfy the definition of requirements. However, this activity may be bypassed if a package solution is anticipated. The design should include the following components: application relationships; database file structure showing the principal input transactions; data dictionary of fields to be recorded in the database and including name, description and other attributes; a cross-reference chart of files versus data elements; and a system flowchart and narrative for mechanized applications (this component may optionally be deferred to the detailed design step).

Various design methodologies may be used instead of, or in addition to, those illustrated here. The designer should feel free to use the tools with which he or she feels most comfortable, although a minimum set of standards should be adhered to in a given enterprise.

Increasingly sophisticated CASE (computer-assisted systems engineering) tools are becoming available to automate MIS design tasks. The more advanced methods are claimed to convert CASE design specifications to operational computer systems.

Alternatives. Numerous alternatives may be available to implement the systems concept, particularly as regards computerization. Typical alternatives to be considered, either alone or in combination, include centralized versus decentralized computing; class(es) of computer(s) to be used (mainframes, minis, micros); package or custom solution; operating system and language(s) to be used; in-house versus contract development; and data communications protocol(s) to be used.

The most promising alternatives should be identified and reviewed here in terms of advantages and disadvantages. The best combination, from a cost/benefit viewpoint, should be identified and justified in some detail.

Cost/benefit considerations. The costs of implementation and operation of a selected alternative should be estimated. The estimates should include a provision for cost overruns, typically 15-30 per cent. The corresponding tangible and intangible benefits of the new or revised MIS should be assessed. Where practicable, the benefits should be quantified in financial terms by user management. In some cases the requirements are of a “must have” nature and the quantified benefits tend to be immaterial.

Conclusions and recommendations. Based on the study findings, the study team’s conclusions and recommendations should be developed as to feasibility, scope and approach to the desired MIS. Where appropriate, a list of up to a dozen qualified vendors should be identified who could be approached for the supply of necessary hardware, software and services to support the recommendations.

Action plan. Assuming that the recommendations are to proceed with implementation, an action plan should be developed to carry out subsequent steps and activities. This plan should be based on subsequent SDLC guidelines covered in this module. The action plan should be refined and updated on a continuous basis throughout the life of the SDLC to reflect actual progress as against current plans.

Reporting. The study findings, conclusions and recommendations should be outlined and presented verbally to the steering committee. Following a full discussion, the study results should be refined and summarized in a written report.

4.2.3 Vendor selection

Following management approval, this step in the SDLC is aimed at achieving maximum benefits from optimum investment in the selection of suppliers of hardware, software and other services as appropriate.

The benefits of a turnkey approach should not be overlooked. The guidelines that follow apply to both single and multiple purchases.

Request for proposal. A written request for proposal (RFP), based on the feasibility study document, should be prepared for major expenditures, covering the following points: scope and purpose; guidelines for submission; evaluation criteria; requirements; conceptual design; and the action plan.

Cost should be examined separately.

Vendor briefings. A conference should take place within a week of issuing the RFP to provide a verbal overview and respond to questions for clarification.

Evaluation. Proposals should be scored against evaluation criteria and the results charted by score against cost. Care should be taken to ensure that “apples are compared with apples”.

On the basis of these results, up to three vendors should be shortlisted for final evaluation and selection through detailed discussion of their proposals and negotiation of their offers and costs. An agreement is then concluded with the selected vendor.

4.2.4 Development

MIS development implies the production of written specifications covering all aspects of the MIS. Detailed systems specifications (systems definition) should include:

1. Computer applications

- application relationships;- database file structure;- system flowchart;- menu content and structure;- video screen formats; and

- printer layouts.

2. Operating instructions

- schedules;- control procedures;

- back-up and archiving.

3. Clerical procedures

- flowcharts; and
- layouts of forms and documents.

4.2.5 System testing

The programme testing carried out during development is unlikely to lead to reliable application. System testing should therefore be carried out by users, assisted by the development team.

Any problems should be corrected by the development team and the test run again until runs of both high-volume and low-volume test data yield flawless results.

4.2.6 User training

Users should be trained on the operation and utilization of MIS applications through classroom instruction, supplemented by on-the-job pilot operation using small samples of regular transactions.

4.2.7 Implementation

Pre-implementation activities may call for site preparation and equipment installation. Once the above steps have been satisfactorily completed, a parallel run should be undertaken with both sets of procedures - existing and new.

This needs to be carefully planned to cope with a worst case scenario of 100 per cent increasing workload for a period of two or three months.

4.2.8 Ongoing operation and maintenance

A well-conceived MIS should settle down to a smooth and reliable operation. Ongoing maintenance should then be required to correct any problems uncovered during operations, to introduce enhancements and develop updates in line with changing business needs.

A formal request procedure should be put in place for scheduling and control of the maintenance function.

4.2.9 Periodic review

An independent review of the MIS should be carried out on an annual basis and, as requested, to determine the degree to which the system is satisfying its objectives.

The review should determine whether any corrective action is a maintenance matter and one requiring a fresh SDLC cycle; for capital budgeting purposes, MIS investments should be deemed to have a life of three to five years.

Checklist 6: Systems development

1. Defining the need

- What is your organization’s approach to the assessment and upgrading of its existing systems?

- How often is there a full-scale appraisal of your MIS systems?

2. An organized approach

- When a major review is undertaken, what is the process of analysis, selection and implementation?

- How does this compare with the SDLC model described in section 4.2?

3. In retrospect

- What are the strengths and weaknesses of recent MIS system changes in your organization?

- What has been learned by senior management, implementers and users?


Page 5

The importance of following a sound SDLC methodology should not be underrated. As an analogy, imagine constructing a tall building without using architectural drawings or following a construction plan. The results would be a disaster! Yet this is precisely the way in which many enterprises have approached the relatively new discipline of developing, implementing and operating MIS systems. The unsatisfactory results might not be so obvious with the MIS systems, which are intellectual products, as they would be with a physical building. Nevertheless, the negative impact of unsatisfactory MIS systems is substantial and can cripple the management potential of the enterprise.

An SDLC methodology is a guideline for systematically developing MIS systems. The guidelines described in this module have been refined through practical experience in numerous MIS development projects and can be broken down into the major phases of: strategic planning; feasibility study; vendor selection; development; system testing; user training; implementation; operation; and periodic review. The SDLC may be further modified and adapted to suit management preferences, project characteristics and the MIS personnel in the individual enterprise.

4.2.1 Strategic planning

The MIS strategic plan should dovetail with, and be a component of, the business plan of the enterprise, and all elements in the SDLC should be planned and implemented in line with MIS strategy.

The process of producing the plan is similar to that described below in the next subsection; but the “study” is of the total organization’s requirements, and the outcomes and action plan become part of the organization’s strategy.

4.2.2 Feasibility study

The major activities in the feasibility study are discussed below.

Terms of reference. Terms of reference (TOR) need to be developed, discussed and agreed with management prior to launching the study proper. They should address: project objectives and scope; the background and series of events leading to the request for the study; the study approach, communications and reporting relationships; a description of the workplan to be followed together with the related schedule; project staffing, including participation by a steering committee and user counterpart personnel; and an estimate of associated costs and out-of-pocket expenses.

Orientation. Following management approval to proceed, the study team members should be phased out of their commitments so that they are available for their scheduled participation. The project steering committee, composed of senior individuals with a direct interest in the area under study, should be established and a chairman appointed. The members of the committee should be briefed on their roles and functional responsibilities.

The TOR study should be reviewed and refined, as appropriate, by the team. Interview guidelines, fact-gathering checklists and questionnaires should be prepared as appropriate. Review meetings should be scheduled with the steering committee at fortnightly or monthly intervals and aligned with project milestones. Suitable support arrangements should be made for office space, computer facilities, typing, photocopying, etc. Personnel affected should be made aware of the study and the overall mandate. Brief site visits and introductory meetings should be held with user management and counterpart personnel to complete the team’s initial orientation to the project.

Survey system. The survey system is carried out through interviews and fact gathering. Topics covered should examine the present situation, from a systems viewpoint, together with the perceived problems and the interviewees’ suggestions for improvement. Copies of pertinent forms and reports should be gathered during the interview itself or arrangements made for subsequent pick-up/delivery. Interviews should be supplemented by physically following the existing systems and paper trails, where appropriate. A first-hand view can best be obtained by talking to the people involved at their workplaces and having them explain the existing manual/mechanized procedures using current examples from work in progress. In addition to taking notes, the interviewer should again gather representative samples of any pertinent forms and reports. Depending on study objectives and scope, the type of documentation to be gathered or reviewed includes historical financial statements; business plans and strategies; policy and procedure manuals; documentation on existing computer systems; organizational structure, job descriptions and staffing levels; original blank sets of forms handled and photocopies of selected completed specimens illustrating their usage; sample copies of reports produced; and pertinent correspondence and other files.

The TOR study should determine the focus of the fact-gathering process.

Analysis. The analytical process should be carried out in parallel with the review and completed during this activity. The information gathered should be classified by selection component, summarized, and key information flows documented. Estimated transaction volumes, file sizes and report printing requirements should be assessed. An analysis of strengths, weaknesses and opportunities for improvement should be carried out in each of the various MIS components. Existing manual processes should be critically reviewed. Possibilities for abolishing certain process steps need to be evaluated. MIS components should be based on best practice and not necessarily on the existing operating practices. The analysis should be the subject of a workshop presentation to members of the steering committee and other interested parties. The workshop should provide an opportunity for a full discussion with the objective of gaining a general group consensus on the present situation as it pertains to the MIS area under study. The results of the workshop review should be documented in memo form and circulated to the participants.

Definition of requirements. The opportunities for improvement identified in the previous activity should be developed into a set of MIS requirements that need to be satisfied. The requirements should be placed in order of priority according to business needs and with due regard to a logical development sequence. The definition of requirements should be reviewed and agreed with the steering committee.

Conceptual design. A conceptual systems design should be developed to satisfy the definition of requirements. However, this activity may be bypassed if a package solution is anticipated. The design should include the following components: application relationships; database file structure showing the principal input transactions; data dictionary of fields to be recorded in the database and including name, description and other attributes; a cross-reference chart of files versus data elements; and a system flowchart and narrative for mechanized applications (this component may optionally be deferred to the detailed design step).

Various design methodologies may be used instead of, or in addition to, those illustrated here. The designer should feel free to use the tools with which he or she feels most comfortable, although a minimum set of standards should be adhered to in a given enterprise.

Increasingly sophisticated CASE (computer-assisted systems engineering) tools are becoming available to automate MIS design tasks. The more advanced methods are claimed to convert CASE design specifications to operational computer systems.

Alternatives. Numerous alternatives may be available to implement the systems concept, particularly as regards computerization. Typical alternatives to be considered, either alone or in combination, include centralized versus decentralized computing; class(es) of computer(s) to be used (mainframes, minis, micros); package or custom solution; operating system and language(s) to be used; in-house versus contract development; and data communications protocol(s) to be used.

The most promising alternatives should be identified and reviewed here in terms of advantages and disadvantages. The best combination, from a cost/benefit viewpoint, should be identified and justified in some detail.

Cost/benefit considerations. The costs of implementation and operation of a selected alternative should be estimated. The estimates should include a provision for cost overruns, typically 15-30 per cent. The corresponding tangible and intangible benefits of the new or revised MIS should be assessed. Where practicable, the benefits should be quantified in financial terms by user management. In some cases the requirements are of a “must have” nature and the quantified benefits tend to be immaterial.

Conclusions and recommendations. Based on the study findings, the study team’s conclusions and recommendations should be developed as to feasibility, scope and approach to the desired MIS. Where appropriate, a list of up to a dozen qualified vendors should be identified who could be approached for the supply of necessary hardware, software and services to support the recommendations.

Action plan. Assuming that the recommendations are to proceed with implementation, an action plan should be developed to carry out subsequent steps and activities. This plan should be based on subsequent SDLC guidelines covered in this module. The action plan should be refined and updated on a continuous basis throughout the life of the SDLC to reflect actual progress as against current plans.

Reporting. The study findings, conclusions and recommendations should be outlined and presented verbally to the steering committee. Following a full discussion, the study results should be refined and summarized in a written report.

4.2.3 Vendor selection

Following management approval, this step in the SDLC is aimed at achieving maximum benefits from optimum investment in the selection of suppliers of hardware, software and other services as appropriate.

The benefits of a turnkey approach should not be overlooked. The guidelines that follow apply to both single and multiple purchases.

Request for proposal. A written request for proposal (RFP), based on the feasibility study document, should be prepared for major expenditures, covering the following points: scope and purpose; guidelines for submission; evaluation criteria; requirements; conceptual design; and the action plan.

Cost should be examined separately.

Vendor briefings. A conference should take place within a week of issuing the RFP to provide a verbal overview and respond to questions for clarification.

Evaluation. Proposals should be scored against evaluation criteria and the results charted by score against cost. Care should be taken to ensure that “apples are compared with apples”.

On the basis of these results, up to three vendors should be shortlisted for final evaluation and selection through detailed discussion of their proposals and negotiation of their offers and costs. An agreement is then concluded with the selected vendor.

4.2.4 Development

MIS development implies the production of written specifications covering all aspects of the MIS. Detailed systems specifications (systems definition) should include:

1. Computer applications

- application relationships;- database file structure;- system flowchart;- menu content and structure;- video screen formats; and

- printer layouts.

2. Operating instructions

- schedules;- control procedures;

- back-up and archiving.

3. Clerical procedures

- flowcharts; and
- layouts of forms and documents.

4.2.5 System testing

The programme testing carried out during development is unlikely to lead to reliable application. System testing should therefore be carried out by users, assisted by the development team.

Any problems should be corrected by the development team and the test run again until runs of both high-volume and low-volume test data yield flawless results.

4.2.6 User training

Users should be trained on the operation and utilization of MIS applications through classroom instruction, supplemented by on-the-job pilot operation using small samples of regular transactions.

4.2.7 Implementation

Pre-implementation activities may call for site preparation and equipment installation. Once the above steps have been satisfactorily completed, a parallel run should be undertaken with both sets of procedures - existing and new.

This needs to be carefully planned to cope with a worst case scenario of 100 per cent increasing workload for a period of two or three months.

4.2.8 Ongoing operation and maintenance

A well-conceived MIS should settle down to a smooth and reliable operation. Ongoing maintenance should then be required to correct any problems uncovered during operations, to introduce enhancements and develop updates in line with changing business needs.

A formal request procedure should be put in place for scheduling and control of the maintenance function.

4.2.9 Periodic review

An independent review of the MIS should be carried out on an annual basis and, as requested, to determine the degree to which the system is satisfying its objectives.

The review should determine whether any corrective action is a maintenance matter and one requiring a fresh SDLC cycle; for capital budgeting purposes, MIS investments should be deemed to have a life of three to five years.

Checklist 6: Systems development

1. Defining the need

- What is your organization’s approach to the assessment and upgrading of its existing systems?

- How often is there a full-scale appraisal of your MIS systems?

2. An organized approach

- When a major review is undertaken, what is the process of analysis, selection and implementation?

- How does this compare with the SDLC model described in section 4.2?

3. In retrospect

- What are the strengths and weaknesses of recent MIS system changes in your organization?

- What has been learned by senior management, implementers and users?


Page 6

(introduction...)

UNIT 4: LEARNING OBJECTIVES

Once you have learnt this unit, you will be able to:

1. Understand and explain the MIS project management process and elements.

2. Describe stages of the system development life cycle (SDLC).

3. Know about MIS maintenance to maximize its utilization.

4.1 MIS project management

A typical functional organization structure for MIS projects, comprising of a steering committee and project team, is discussed below.

4.1.1 Steering committee for control and distribution

A management steering committee should be established to oversee the control and direction of MIS activities and projects. The committee should be chaired by a senior manager, preferably the chief executive officer, and be composed of a representative selection of management. The internal auditor should be a member to help to ensure that adequate controls on information are provided for, as well as to ensure that audit requirements are fully addressed. The composition of such a committee can vary. For instance, when the topic to be discussed is MIS priorities for the enterprise as a whole, there should be broad management representation. On the other hand, when the issue in question is sales reporting, the key participants should be from the sales and marketing departments.

The MIS manager/project manager should report to this committee on a functional basis and bring along such members of staff as are appropriate for a given meeting. The steering committee should agree on priorities, plans and related budgets for the information resource. Regular meetings should be held to review progress against plans, tackle problems and progressively examine, discuss and approve systems at their various stages of development in order to ensure that requirements are satisfied.

In addition to regular review meetings, special meetings may be held to review and approve, as appropriate, the satisfactory completion of milestones identified in the plan.

4.1.2 Project management and staffing

Although the enterprise may have a formal organizational structure in place for the MIS function, MIS development is best carried out on a project basis. At any given time, a number of MIS development projects may be under way, each with its own limited objectives and scope as well as the corresponding budget and schedule.

The project manager should be selected not only for his or her technical skills but for management ability as well. The project team should be composed of both MIS technical experts and user personnel who are familiar with their information requirements and can contribute their knowledge and efforts to the successful outcome of a given project.

Using a project management team

At the United States Printing Office in Washington, DC, an interdisciplinary team was set up to plan an information system when the public printer first said he wanted a system that would track the rapidly growing printing programme.

The Director of Information Resources formed a project team consisting of IS, finance and other professionals to draw up what it called a requirements document. According to the Director, there was “constant communication between IS and the project management team. We needed a group like the project management team because the systems analysts themselves don’t have the experience to understand the many disciplines involved, such as financial management and materials management.”

Source: Moad, 1988.

4.1.3 Systems development life cycle (SDLC)

A systems development life cycle (SDLC) is one term used for an organized approach to systems development, implementation, operation and maintenance. Once the system becomes obsolescent and/or ongoing, maintenance/operating costs over a few years exceed the estimated capital cost of a new system, and the cycle starts again. The SDLC methodology will be described in more detail in the following section.

4.1.4 Project milestones

As with any project type, management attention in the SDLC should focus principally on project milestones. At each milestone, management needs to be assured that the underlying tasks have been satisfactorily completed before giving approval to proceed to the next phase.

4.1.5 Documentation and reporting

The evidence of accomplishment in the SDLC should be in written form. The documentation and reporting produced during the life of a project constitutes the principal foundation on which management judgements, conclusions and decisions should be based. At certain milestones, such evidence should be supplemented by demonstrations and user tests on computer. The purpose of good documentation is not only to afford a basis for quality assurance but also to provide for continuity in development and maintenance. Further, it can help to avoid the situation whereby the enterprise can become totally dependent on a given individual or group and lay itself open to blackmail.

Traditionally, documentation has been the weakest element in systems development projects, which is why management must be particularly alert to any shortcomings in this area. The reason for documentation deficiencies is that talented developers want to spend their time on creative endeavor and not on the drudgery (they believe) of putting the results of their thought processes on paper. Actually, even a relatively small systems assignment tends to be of sufficient technical complexity to confound the human memory. Efforts are being made to automate the documentation process, notably through the development and application of CASE (computer-assisted systems engineering) tools. Current efforts focus on making it possible for CASE to generate application systems as well, a highly desirable progression!

The importance of following a sound SDLC methodology should not be underrated. As an analogy, imagine constructing a tall building without using architectural drawings or following a construction plan. The results would be a disaster! Yet this is precisely the way in which many enterprises have approached the relatively new discipline of developing, implementing and operating MIS systems. The unsatisfactory results might not be so obvious with the MIS systems, which are intellectual products, as they would be with a physical building. Nevertheless, the negative impact of unsatisfactory MIS systems is substantial and can cripple the management potential of the enterprise.

An SDLC methodology is a guideline for systematically developing MIS systems. The guidelines described in this module have been refined through practical experience in numerous MIS development projects and can be broken down into the major phases of: strategic planning; feasibility study; vendor selection; development; system testing; user training; implementation; operation; and periodic review. The SDLC may be further modified and adapted to suit management preferences, project characteristics and the MIS personnel in the individual enterprise.

4.2.1 Strategic planning

The MIS strategic plan should dovetail with, and be a component of, the business plan of the enterprise, and all elements in the SDLC should be planned and implemented in line with MIS strategy.

The process of producing the plan is similar to that described below in the next subsection; but the “study” is of the total organization’s requirements, and the outcomes and action plan become part of the organization’s strategy.

4.2.2 Feasibility study

The major activities in the feasibility study are discussed below.

Terms of reference. Terms of reference (TOR) need to be developed, discussed and agreed with management prior to launching the study proper. They should address: project objectives and scope; the background and series of events leading to the request for the study; the study approach, communications and reporting relationships; a description of the workplan to be followed together with the related schedule; project staffing, including participation by a steering committee and user counterpart personnel; and an estimate of associated costs and out-of-pocket expenses.

Orientation. Following management approval to proceed, the study team members should be phased out of their commitments so that they are available for their scheduled participation. The project steering committee, composed of senior individuals with a direct interest in the area under study, should be established and a chairman appointed. The members of the committee should be briefed on their roles and functional responsibilities.

The TOR study should be reviewed and refined, as appropriate, by the team. Interview guidelines, fact-gathering checklists and questionnaires should be prepared as appropriate. Review meetings should be scheduled with the steering committee at fortnightly or monthly intervals and aligned with project milestones. Suitable support arrangements should be made for office space, computer facilities, typing, photocopying, etc. Personnel affected should be made aware of the study and the overall mandate. Brief site visits and introductory meetings should be held with user management and counterpart personnel to complete the team’s initial orientation to the project.

Survey system. The survey system is carried out through interviews and fact gathering. Topics covered should examine the present situation, from a systems viewpoint, together with the perceived problems and the interviewees’ suggestions for improvement. Copies of pertinent forms and reports should be gathered during the interview itself or arrangements made for subsequent pick-up/delivery. Interviews should be supplemented by physically following the existing systems and paper trails, where appropriate. A first-hand view can best be obtained by talking to the people involved at their workplaces and having them explain the existing manual/mechanized procedures using current examples from work in progress. In addition to taking notes, the interviewer should again gather representative samples of any pertinent forms and reports. Depending on study objectives and scope, the type of documentation to be gathered or reviewed includes historical financial statements; business plans and strategies; policy and procedure manuals; documentation on existing computer systems; organizational structure, job descriptions and staffing levels; original blank sets of forms handled and photocopies of selected completed specimens illustrating their usage; sample copies of reports produced; and pertinent correspondence and other files.

The TOR study should determine the focus of the fact-gathering process.

Analysis. The analytical process should be carried out in parallel with the review and completed during this activity. The information gathered should be classified by selection component, summarized, and key information flows documented. Estimated transaction volumes, file sizes and report printing requirements should be assessed. An analysis of strengths, weaknesses and opportunities for improvement should be carried out in each of the various MIS components. Existing manual processes should be critically reviewed. Possibilities for abolishing certain process steps need to be evaluated. MIS components should be based on best practice and not necessarily on the existing operating practices. The analysis should be the subject of a workshop presentation to members of the steering committee and other interested parties. The workshop should provide an opportunity for a full discussion with the objective of gaining a general group consensus on the present situation as it pertains to the MIS area under study. The results of the workshop review should be documented in memo form and circulated to the participants.

Definition of requirements. The opportunities for improvement identified in the previous activity should be developed into a set of MIS requirements that need to be satisfied. The requirements should be placed in order of priority according to business needs and with due regard to a logical development sequence. The definition of requirements should be reviewed and agreed with the steering committee.

Conceptual design. A conceptual systems design should be developed to satisfy the definition of requirements. However, this activity may be bypassed if a package solution is anticipated. The design should include the following components: application relationships; database file structure showing the principal input transactions; data dictionary of fields to be recorded in the database and including name, description and other attributes; a cross-reference chart of files versus data elements; and a system flowchart and narrative for mechanized applications (this component may optionally be deferred to the detailed design step).

Various design methodologies may be used instead of, or in addition to, those illustrated here. The designer should feel free to use the tools with which he or she feels most comfortable, although a minimum set of standards should be adhered to in a given enterprise.

Increasingly sophisticated CASE (computer-assisted systems engineering) tools are becoming available to automate MIS design tasks. The more advanced methods are claimed to convert CASE design specifications to operational computer systems.

Alternatives. Numerous alternatives may be available to implement the systems concept, particularly as regards computerization. Typical alternatives to be considered, either alone or in combination, include centralized versus decentralized computing; class(es) of computer(s) to be used (mainframes, minis, micros); package or custom solution; operating system and language(s) to be used; in-house versus contract development; and data communications protocol(s) to be used.

The most promising alternatives should be identified and reviewed here in terms of advantages and disadvantages. The best combination, from a cost/benefit viewpoint, should be identified and justified in some detail.

Cost/benefit considerations. The costs of implementation and operation of a selected alternative should be estimated. The estimates should include a provision for cost overruns, typically 15-30 per cent. The corresponding tangible and intangible benefits of the new or revised MIS should be assessed. Where practicable, the benefits should be quantified in financial terms by user management. In some cases the requirements are of a “must have” nature and the quantified benefits tend to be immaterial.

Conclusions and recommendations. Based on the study findings, the study team’s conclusions and recommendations should be developed as to feasibility, scope and approach to the desired MIS. Where appropriate, a list of up to a dozen qualified vendors should be identified who could be approached for the supply of necessary hardware, software and services to support the recommendations.

Action plan. Assuming that the recommendations are to proceed with implementation, an action plan should be developed to carry out subsequent steps and activities. This plan should be based on subsequent SDLC guidelines covered in this module. The action plan should be refined and updated on a continuous basis throughout the life of the SDLC to reflect actual progress as against current plans.

Reporting. The study findings, conclusions and recommendations should be outlined and presented verbally to the steering committee. Following a full discussion, the study results should be refined and summarized in a written report.

4.2.3 Vendor selection

Following management approval, this step in the SDLC is aimed at achieving maximum benefits from optimum investment in the selection of suppliers of hardware, software and other services as appropriate.

The benefits of a turnkey approach should not be overlooked. The guidelines that follow apply to both single and multiple purchases.

Request for proposal. A written request for proposal (RFP), based on the feasibility study document, should be prepared for major expenditures, covering the following points: scope and purpose; guidelines for submission; evaluation criteria; requirements; conceptual design; and the action plan.

Cost should be examined separately.

Vendor briefings. A conference should take place within a week of issuing the RFP to provide a verbal overview and respond to questions for clarification.

Evaluation. Proposals should be scored against evaluation criteria and the results charted by score against cost. Care should be taken to ensure that “apples are compared with apples”.

On the basis of these results, up to three vendors should be shortlisted for final evaluation and selection through detailed discussion of their proposals and negotiation of their offers and costs. An agreement is then concluded with the selected vendor.

4.2.4 Development

MIS development implies the production of written specifications covering all aspects of the MIS. Detailed systems specifications (systems definition) should include:

1. Computer applications

- application relationships;- database file structure;- system flowchart;- menu content and structure;- video screen formats; and

- printer layouts.

2. Operating instructions

- schedules;- control procedures;

- back-up and archiving.

3. Clerical procedures

- flowcharts; and
- layouts of forms and documents.

4.2.5 System testing

The programme testing carried out during development is unlikely to lead to reliable application. System testing should therefore be carried out by users, assisted by the development team.

Any problems should be corrected by the development team and the test run again until runs of both high-volume and low-volume test data yield flawless results.

4.2.6 User training

Users should be trained on the operation and utilization of MIS applications through classroom instruction, supplemented by on-the-job pilot operation using small samples of regular transactions.

4.2.7 Implementation

Pre-implementation activities may call for site preparation and equipment installation. Once the above steps have been satisfactorily completed, a parallel run should be undertaken with both sets of procedures - existing and new.

This needs to be carefully planned to cope with a worst case scenario of 100 per cent increasing workload for a period of two or three months.

4.2.8 Ongoing operation and maintenance

A well-conceived MIS should settle down to a smooth and reliable operation. Ongoing maintenance should then be required to correct any problems uncovered during operations, to introduce enhancements and develop updates in line with changing business needs.

A formal request procedure should be put in place for scheduling and control of the maintenance function.

4.2.9 Periodic review

An independent review of the MIS should be carried out on an annual basis and, as requested, to determine the degree to which the system is satisfying its objectives.

The review should determine whether any corrective action is a maintenance matter and one requiring a fresh SDLC cycle; for capital budgeting purposes, MIS investments should be deemed to have a life of three to five years.

Checklist 6: Systems development

1. Defining the need

- What is your organization’s approach to the assessment and upgrading of its existing systems?

- How often is there a full-scale appraisal of your MIS systems?

2. An organized approach

- When a major review is undertaken, what is the process of analysis, selection and implementation?

- How does this compare with the SDLC model described in section 4.2?

3. In retrospect

- What are the strengths and weaknesses of recent MIS system changes in your organization?

- What has been learned by senior management, implementers and users?

4.3 System maintenance: day-to-day productivity

Another reason why the size of investment in IT fails to correlate with higher productivity is that big spenders often become excited about the latest technology but neglect to maximize the effectiveness of existing systems.

Such investments are often technology-driven rather than business-driven and, of course, we need both. This is probably where you, personally, can make your greatest contribution. You are probably not a technical person, nor are you, yet, the chief executive.

4.3.1 You - The internal client

We hope that this module will enable you, more effectively, to behave as an “internal client” of your MIS department, ensuring that you have the best and most appropriate hardware available in the company; the software packages are the latest versions; and you and your staff are fully briefed on how to maximize the benefits of the system.

4.3.2 Maximizing utilization

Today’s computers and telecommunications equipment are tremendously powerful machines with extensive ranges of capability and prodigious memories. But that capability is rarely used. For example, are you using the potential of your word processing system to reduce filing of documents? Did you even realize you could do so? What percentage of the facilities on your digital telephone do you use? Have you set up so-called “macros” which allow you to display the most important forms, letters, etc., on your screen without having to generate this information over and over again? Have managers changed their working styles or do they still, for example, provide handwritten draft text to be typed by secretaries and changed over and over again (because it seems so much easier with word processing!)? Learn everything you can about the capability of your systems and ask yourself and your staff whether an operation could be more quickly, easily and reliably done on the system. If so, what has to be done to automate it?

4.3.3 Good housekeeping

This is a major responsibility of computer users and, if neglected, can cut productivity to shreds or worse, lose precious information vital to the survival of the firm. Most productivity improvements are the result of incremental, day-by-day actions. Good housekeeping means saving files, creating back-up records, getting rid of files no longer used, logging information for speedy retrieval, and so on. Ensure that you and your staff have regular coaching sessions on good housekeeping - little things mean a lot!

Checklist 7: Day-to-day productivity

1. System assessment

- Discuss, with other managers, the hardware and software they use:

- Is it faster, more user friendly, more flexible than yours?
- How do they get the best from it?

2. System capability

- Are you aware of the full capability of your computers, telephones and networks? Calculate what percentage of their capability is used/not used.

3. Housekeeping

- How satisfied are you that you and your staff use the system efficiently:

- Filing and storing in a disciplined way?- Maximizing speed of retrieval?

- Deleting out-of-date files?

4. Your role as internal client

- Meet the staff of your MIS department and agree on a plan for:

- Upgrading your department’s system;

- Regular briefings for your staff on maximizing the system’s benefits and on good housekeeping.

Questions for discussion

1. What does MIS installation mean?2. What are the main MIS project management elements?3. What is the role of the SDLC?

4. What are the main components of MIS maintenance?


Page 7

The importance of following a sound SDLC methodology should not be underrated. As an analogy, imagine constructing a tall building without using architectural drawings or following a construction plan. The results would be a disaster! Yet this is precisely the way in which many enterprises have approached the relatively new discipline of developing, implementing and operating MIS systems. The unsatisfactory results might not be so obvious with the MIS systems, which are intellectual products, as they would be with a physical building. Nevertheless, the negative impact of unsatisfactory MIS systems is substantial and can cripple the management potential of the enterprise.

An SDLC methodology is a guideline for systematically developing MIS systems. The guidelines described in this module have been refined through practical experience in numerous MIS development projects and can be broken down into the major phases of: strategic planning; feasibility study; vendor selection; development; system testing; user training; implementation; operation; and periodic review. The SDLC may be further modified and adapted to suit management preferences, project characteristics and the MIS personnel in the individual enterprise.

4.2.1 Strategic planning

The MIS strategic plan should dovetail with, and be a component of, the business plan of the enterprise, and all elements in the SDLC should be planned and implemented in line with MIS strategy.

The process of producing the plan is similar to that described below in the next subsection; but the “study” is of the total organization’s requirements, and the outcomes and action plan become part of the organization’s strategy.

4.2.2 Feasibility study

The major activities in the feasibility study are discussed below.

Terms of reference. Terms of reference (TOR) need to be developed, discussed and agreed with management prior to launching the study proper. They should address: project objectives and scope; the background and series of events leading to the request for the study; the study approach, communications and reporting relationships; a description of the workplan to be followed together with the related schedule; project staffing, including participation by a steering committee and user counterpart personnel; and an estimate of associated costs and out-of-pocket expenses.

Orientation. Following management approval to proceed, the study team members should be phased out of their commitments so that they are available for their scheduled participation. The project steering committee, composed of senior individuals with a direct interest in the area under study, should be established and a chairman appointed. The members of the committee should be briefed on their roles and functional responsibilities.

The TOR study should be reviewed and refined, as appropriate, by the team. Interview guidelines, fact-gathering checklists and questionnaires should be prepared as appropriate. Review meetings should be scheduled with the steering committee at fortnightly or monthly intervals and aligned with project milestones. Suitable support arrangements should be made for office space, computer facilities, typing, photocopying, etc. Personnel affected should be made aware of the study and the overall mandate. Brief site visits and introductory meetings should be held with user management and counterpart personnel to complete the team’s initial orientation to the project.

Survey system. The survey system is carried out through interviews and fact gathering. Topics covered should examine the present situation, from a systems viewpoint, together with the perceived problems and the interviewees’ suggestions for improvement. Copies of pertinent forms and reports should be gathered during the interview itself or arrangements made for subsequent pick-up/delivery. Interviews should be supplemented by physically following the existing systems and paper trails, where appropriate. A first-hand view can best be obtained by talking to the people involved at their workplaces and having them explain the existing manual/mechanized procedures using current examples from work in progress. In addition to taking notes, the interviewer should again gather representative samples of any pertinent forms and reports. Depending on study objectives and scope, the type of documentation to be gathered or reviewed includes historical financial statements; business plans and strategies; policy and procedure manuals; documentation on existing computer systems; organizational structure, job descriptions and staffing levels; original blank sets of forms handled and photocopies of selected completed specimens illustrating their usage; sample copies of reports produced; and pertinent correspondence and other files.

The TOR study should determine the focus of the fact-gathering process.

Analysis. The analytical process should be carried out in parallel with the review and completed during this activity. The information gathered should be classified by selection component, summarized, and key information flows documented. Estimated transaction volumes, file sizes and report printing requirements should be assessed. An analysis of strengths, weaknesses and opportunities for improvement should be carried out in each of the various MIS components. Existing manual processes should be critically reviewed. Possibilities for abolishing certain process steps need to be evaluated. MIS components should be based on best practice and not necessarily on the existing operating practices. The analysis should be the subject of a workshop presentation to members of the steering committee and other interested parties. The workshop should provide an opportunity for a full discussion with the objective of gaining a general group consensus on the present situation as it pertains to the MIS area under study. The results of the workshop review should be documented in memo form and circulated to the participants.

Definition of requirements. The opportunities for improvement identified in the previous activity should be developed into a set of MIS requirements that need to be satisfied. The requirements should be placed in order of priority according to business needs and with due regard to a logical development sequence. The definition of requirements should be reviewed and agreed with the steering committee.

Conceptual design. A conceptual systems design should be developed to satisfy the definition of requirements. However, this activity may be bypassed if a package solution is anticipated. The design should include the following components: application relationships; database file structure showing the principal input transactions; data dictionary of fields to be recorded in the database and including name, description and other attributes; a cross-reference chart of files versus data elements; and a system flowchart and narrative for mechanized applications (this component may optionally be deferred to the detailed design step).

Various design methodologies may be used instead of, or in addition to, those illustrated here. The designer should feel free to use the tools with which he or she feels most comfortable, although a minimum set of standards should be adhered to in a given enterprise.

Increasingly sophisticated CASE (computer-assisted systems engineering) tools are becoming available to automate MIS design tasks. The more advanced methods are claimed to convert CASE design specifications to operational computer systems.

Alternatives. Numerous alternatives may be available to implement the systems concept, particularly as regards computerization. Typical alternatives to be considered, either alone or in combination, include centralized versus decentralized computing; class(es) of computer(s) to be used (mainframes, minis, micros); package or custom solution; operating system and language(s) to be used; in-house versus contract development; and data communications protocol(s) to be used.

The most promising alternatives should be identified and reviewed here in terms of advantages and disadvantages. The best combination, from a cost/benefit viewpoint, should be identified and justified in some detail.

Cost/benefit considerations. The costs of implementation and operation of a selected alternative should be estimated. The estimates should include a provision for cost overruns, typically 15-30 per cent. The corresponding tangible and intangible benefits of the new or revised MIS should be assessed. Where practicable, the benefits should be quantified in financial terms by user management. In some cases the requirements are of a “must have” nature and the quantified benefits tend to be immaterial.

Conclusions and recommendations. Based on the study findings, the study team’s conclusions and recommendations should be developed as to feasibility, scope and approach to the desired MIS. Where appropriate, a list of up to a dozen qualified vendors should be identified who could be approached for the supply of necessary hardware, software and services to support the recommendations.

Action plan. Assuming that the recommendations are to proceed with implementation, an action plan should be developed to carry out subsequent steps and activities. This plan should be based on subsequent SDLC guidelines covered in this module. The action plan should be refined and updated on a continuous basis throughout the life of the SDLC to reflect actual progress as against current plans.

Reporting. The study findings, conclusions and recommendations should be outlined and presented verbally to the steering committee. Following a full discussion, the study results should be refined and summarized in a written report.

4.2.3 Vendor selection

Following management approval, this step in the SDLC is aimed at achieving maximum benefits from optimum investment in the selection of suppliers of hardware, software and other services as appropriate.

The benefits of a turnkey approach should not be overlooked. The guidelines that follow apply to both single and multiple purchases.

Request for proposal. A written request for proposal (RFP), based on the feasibility study document, should be prepared for major expenditures, covering the following points: scope and purpose; guidelines for submission; evaluation criteria; requirements; conceptual design; and the action plan.

Cost should be examined separately.

Vendor briefings. A conference should take place within a week of issuing the RFP to provide a verbal overview and respond to questions for clarification.

Evaluation. Proposals should be scored against evaluation criteria and the results charted by score against cost. Care should be taken to ensure that “apples are compared with apples”.

On the basis of these results, up to three vendors should be shortlisted for final evaluation and selection through detailed discussion of their proposals and negotiation of their offers and costs. An agreement is then concluded with the selected vendor.

4.2.4 Development

MIS development implies the production of written specifications covering all aspects of the MIS. Detailed systems specifications (systems definition) should include:

1. Computer applications

- application relationships;- database file structure;- system flowchart;- menu content and structure;- video screen formats; and

- printer layouts.

2. Operating instructions

- schedules;- control procedures;

- back-up and archiving.

3. Clerical procedures

- flowcharts; and
- layouts of forms and documents.

4.2.5 System testing

The programme testing carried out during development is unlikely to lead to reliable application. System testing should therefore be carried out by users, assisted by the development team.

Any problems should be corrected by the development team and the test run again until runs of both high-volume and low-volume test data yield flawless results.

4.2.6 User training

Users should be trained on the operation and utilization of MIS applications through classroom instruction, supplemented by on-the-job pilot operation using small samples of regular transactions.

4.2.7 Implementation

Pre-implementation activities may call for site preparation and equipment installation. Once the above steps have been satisfactorily completed, a parallel run should be undertaken with both sets of procedures - existing and new.

This needs to be carefully planned to cope with a worst case scenario of 100 per cent increasing workload for a period of two or three months.

4.2.8 Ongoing operation and maintenance

A well-conceived MIS should settle down to a smooth and reliable operation. Ongoing maintenance should then be required to correct any problems uncovered during operations, to introduce enhancements and develop updates in line with changing business needs.

A formal request procedure should be put in place for scheduling and control of the maintenance function.

4.2.9 Periodic review

An independent review of the MIS should be carried out on an annual basis and, as requested, to determine the degree to which the system is satisfying its objectives.

The review should determine whether any corrective action is a maintenance matter and one requiring a fresh SDLC cycle; for capital budgeting purposes, MIS investments should be deemed to have a life of three to five years.

Checklist 6: Systems development

1. Defining the need

- What is your organization’s approach to the assessment and upgrading of its existing systems?

- How often is there a full-scale appraisal of your MIS systems?

2. An organized approach

- When a major review is undertaken, what is the process of analysis, selection and implementation?

- How does this compare with the SDLC model described in section 4.2?

3. In retrospect

- What are the strengths and weaknesses of recent MIS system changes in your organization?

- What has been learned by senior management, implementers and users?