Book 28 — Information System Design
by The Editor
3. Approach to System Specification
Since the earliest days of computer operations, it has been common experience that most large complex projects (and some apparently quite simple little ones) take far longer and cost far more money than was originally envisaged before they become fully operational. Indeed, more than a few have had to be abandoned as uneconomical — but only after considerable waste of time, effort, and money had been incurred. The bigger and more costly the project, the more likely such debacles become.
The underlying cause of all this waste is psychological. Opponents of a project can find many subtle, and some not-so-subtle, ways of obstructing progress. Proponents become over-ambitious for the kudos associated with instigation of, or participation in, a grandiose scheme, and are reluctant to acknowledge any possibility that the concept may be flawed or that technical or other unforeseen snags make it impractical. The longer the project has been pursued, the more difficult it becomes to stop it because of the resources already irrevocably committed and the number of people involved who fear for their jobs and reputations. Yet realism always prevails in the end.
The object of this chapter is to show how realism can be made to prevail from the very beginning of a project, thereby forestalling waste and protecting both jobs and reputations.
Any system intended for the benefit of any significant private sector business or public sector body is likely to be complex — not necessarily because of the tasks it has to perform but because of the operational, economic, political, and authoritative relationships it has to reflect. In the private sector, concern for continued profitability tends to counter lack of realism. In the particular case of a public sector system, the cost of which must be borne by the unwitting tax-payer, there should ideally be some strict supervisory system to ensure that the project is designed from start to finish to provide the tax-paying customer with essential services as cost-effectively as possible, and not diverted to cater for the whims and ambitions of politicians or their public servants.
Whether in the public or private sectors of the economy, there may be a debate about the rôle of an IT Director. There are those who argue that the rôle is no longer needed because computer users have generally become so well-versed in the art that they can look after themselves and evolve their own solutions to problems. However, it is not hard to see that in the context of a complex organisation such as a large business enterprise, a local authority, or a Ministry of central government, pursuing that philosophy may quickly result in anarchy, corruption, fraud, general mistrust, and inordinate waste of resources — because individual solutions will inevitably conflict with each other and provide much scope for jiggery-pokery.
Hence, even if the role of the IT Director as a person of perks and prestige is no longer required as co-ordinator, disciplinarian, and blame-bearer, the role must still be performed. The most cost-effective way of performing the role is to build it into the system itself.
Hence the system should be fully integrated and should reflect not only the tasks that must be performed but also the authority relationships that must prevail among the various users of the system.
In the early days of computing, it was fashionable to undertake a feasibility study before anybody concerned with an embryonic project went anywhere near a keyboard. Now that there is little reason to doubt the theoretical feasibility of programming virtually any information-processing task, this step is usually omitted and there is a tendency to begin to 'model' bits of the project before the overall concept has been defined. This practice should cease. The feasibility study should be replaced by a System Specification Study, the output of which is a complete and consistent system requirements document. This document will serve as the basis for invitations to tender for all or parts of the system and as a procedures manual for all those involved with the system.
The aim of the Systems Study is to clarify the rôles of all participants, whether implementers, operators, users, maintainers, or ultimate beneficiaries, and to map these relationships and the data flows to which they give rise so as to remove any ambiguity regarding who is to do what, why, when, where, how, and on whose behalf.
The study will involve people at all levels in the organisation as well as a representative cross-section of its 'customers'. It will commence with a 'top-down' appreciation of the requirements, proceed by identifying any logical conflicts or constraints arising from or affecting the envisaged requirements, obtain agreement to changes necessitated by such conflicts or constraints, and conclude with a 'bottom-up' review to ensure consistency and integrity throughout.
The 'deliverable' is a document which fully defines the system and its functionality clearly, concisely, but comprehensively. It will facilitate accurate costing in time and money and enable rigorous quality control over system procurement, implementation, setting to work, maintenance, and routine operation.
Obviously, the production of such a document implies spending a fair proportion of overall project cost up front. This should be considered as an insurance premium against the risks attendant upon venturing into the unknown with no clear idea of the desired outcome or the hazards that might be encountered on the way. It saves the cost of documenting the system after it has been built. Furthermore, it is not unknown for the cost of producing a good specification to be more than recovered by way of penalty clauses from careless or over-optimistic suppliers.
Two main resources are required. The first is a Methodology in which the results of the investigation can be expressed consistently, concisely, clearly, and unambiguously. There are various 'methodologies' on offer, but all of them should:
Having selected a methodology, the second essential resource is a talented, conscientious Chief Analyst who is thoroughly competent in the use of the chosen methodology and can supervise its application by other analysts. The chosen person need have no great technical knowledge of computer systems or programming; indeed, such knowledge may be a disadvantage as it may distract the analyst from the main task.
- Facilitate modular design so that development can proceed in small low-risk steps.
- Be readily comprehensible to everybody with an interest in the system or who plays any part in system development, implementation, or operation.
- Compel elicitation of accurate and complete knowledge from the intended users and operators of the system.
- Map all authority relationships so that potential clashes may be identified and avoided.
- Facilitate critical examination of the existing system, if any.
- Facilitate comparative evaluation of possible alternative solutions.
- Specify entity relationships, data flows, and volumes to facilitate adequate capacity planning.
- Produce an unambiguous processing specification as a basis for application development using whatever software tools or methodologies may be favoured by the organisation.
- Provide a sound quantitative basis for budgeting resources and costs for all subsequent stages of project development.
- Enable a Project Manager to co-ordinate and control all activities involved in implementation, setting to work, quality assurance, and maintenance.
In general, any information processing task which is entirely logical and precisely specified can be programmed. What is important is that the person chosen have intellectual flair, considerable patience, and the moral courage to probe deeply and to challenge every assertion which conflicts with established fact.
Ideally, the methodology itself should present the facts so clearly and logically as to leave no room for egotism: however, conflicts often arise from illogical causes.
If it is to be successful, the Systems Specification Study must first cover all the activities of the organisation from a strategic point of view to establish a logical program for modular construction. This will determine the order of priorities for subsequent in-depth study and specification of selected processing modules. Hence, personnel at all levels in the organisation must be consulted at some point in the study, and it is therefore essential that the project have the commitment and enthusiastic support of the Chief Executive without whose authority the Study Leader may encounter insuperable obstacles further down the line.
Improvement always implies change, and even changes for the better may be uncomfortable to begin with. One of the most significant, if immeasurable, advantages of conducting a thorough specification study before changes are implemented is that the consultation process affords an opportunity to gain the confidence and support of those whose working conditions are likely to be affected thereby. Without this support, the best-laid scheme will be subject to obstruction, delay, and loss of control over costs. The active support of workers eager to enhance their own effectiveness is conducive to a harmonious, expeditious, and effective implementation.