What are methodologies good for?

What are methodologies good for? Too much reliance can be placed on techniques of software development

by RICHARD VERYARD

T here are many organizations and individuals recommending their own methodologies for solving

business pro’blems and for developing and implementing business systems. In particular, there are several such methodologies for computer systems development. Most of them are ‘sold’,

in that their adoption entails the purchase of a book or other documentation, training courses, or perhaps a

_~

Abstract: The provision of information

systems and services to an organization may

be based either (on common sense or on a

formal methodology. One man’s common sense is another man’s idiosyncracy. A formal

methodology helps people systematically share

their working methods and results. A

methodology is (a system whose output is a

solution to a problem. In data processing, the

output may be partly in the form of computer software.

Methodologtes should be evaluated in systems terms, using such criteria as

effectiveness, efficiency, reliability, stability,

simplicity, ease of use, flexibility, measurability, visibility, user acceptability,

etc.

Many methodologzes are unbalanced.

Future development of methodologies should

take account of such system-based

requirements.

Keywords: dato processing, computer

software, methodology.

Richard Veryard is a senior 1ecturer:consultant at Data Logic.

computer software package. Many managers, consultants and

analysts have to consider two ques- tions. First, whether to adopt such a formal methodology and second, which one to buy. The latter choice is complicated by the competition between the methodology vendors; there are sometimes trivial differences between methodologies solely to dif- ferentiate them as products in the marketplace’. It is not easy to separate the essential features of each methodology from its marketing features .

Meanwhile, the methodology vendors themselves are under great pres- sure to maintain their offerings. They must keep up with new attitudes and priorities in the data processing indus- try (such as the relative cost of man-

power and machine power), new techniques or fashions (such as proto- typing) and new types of user require- ment (such as knowledge engineering or robotics). Essentially their objective is to win new customers without alienating existing ones.

In this article, some general points about methodologies will be made, which should be of interest both to those evaluating and selecting methodologies and to those designing and improving them. The conclusions will not necessarily be universally valid; the author prefers to be comprehen- sible than comprehensive.

How projects and systems fail

Among the reasons for projects not achieving their objectives and targets are some connected with the methods used on the project. For example:

l unnecessary tasks are performed, l necessary tasks are not performed, l tasks are incorrectly or inadequate-

ly performed.

Each of these can often be blamed on the methodology followed by the project, which may be:

too vague and non-specific, too rigid and inflexible, not properly understood/not pro-

perly followed, totally unsuitable for this kind of

project.

is not sufficient excuse to say that

the project team or the users were fools; a good methodology should be foolproof.

This is related to the problem of maintenance, which is unpopular among DP staff because of its lack of glamour. Most formal information systems methodologies concentrate on systems development at the expense of maintenance. In prac:tice it is often only those staff considered bright enough to learn the complexities of a new methodology ,who are allowed to take advantage of it, while for the rest maintenance is eq,uivalent to stagna- tion. Yet they may be the ones most in need of formal gui’dance.

~01 27 no 6 jLtly/august 1985 0011-684X/85/060009-04$03.00 0 1985 Butterworth & Co (Publishers) Ltd 9

If practised analysts or programmers are promised training in a formal methodology, do they see this as a reward for good behaviour or as a sign of the manager’s dissatisfaction with their work! If either is frequently true, then there may be something seriously wrong with the image of methodologies, which the methodology vendors are partly to blame for.

What is a methodology?

Formal or informal

A tentative de~tion of a methodology might be a generalized set of methods and procedures used on projects.

There is no alternative to using a methodology. The choice is between using an explicit formal one and the implicit tradition and common sense (TACS) methodology. TACS is the default or fallback for people who do not know any other option; it may also be chosen as a deliberate policy.

The trouble with TACS is that everybody interprets differently the demands of common sense. ‘Com- mon’ sense is paradoxically not common at all, if by that we mean shared, held in common. TACS relies on personal intuition, perhaps based on past experience, which is often idio- syncratic. Whether this is desirable or not will depend on the circumstances.

Experienced chefs regard a recipe as a set of hints and adapt the ingredients and methods according to taste and convenience. Similarly, experienced systems analysts believe themselves not obliged to obey the rules as religiously as their junior colleagues.

There is therefore a definite tendency for formal methodologies, once introduced, to drift into informality and to be adulterated with elements of TACS, unless positive steps are taken to refresh the und~stan~mg and to maintain the purity of the methodo-

&Y.

10

System or ad hoc

A formal methodology is often pre- sented as a checklist, a sequence of tasks and activities which must be carried out in order to develop an application system. A project follow- ing the methodology starts at a given point (perhaps a statement of user requirements, perhaps just vague dissatisfaction) and produces a solution (perhaps in the form of a fully-d~u- mented computer system with all the trimmings).

We can regard this process itself as a system, taking a given input and producing a given output. So-called ‘hard’ methodologies start from a need (e.g. a specific problem or opportun- ity) and produce a product (such as a computer system). So-called ‘soft’ methodologies start from an open situate, where specific problems and opportunities have not yet been iden- tified, and produce a plan for improving the situation. The output from the latter may become the input for the former.

Nowadays the systems development process itself is being increas- ingly computerized. Automated tools are becoming available for systems analysts and designers, as well as for programmers and these tools can be expected to grow in sophistication and scope.

A methodology can be regarded as the specification of a systems development system, involving interaction between people and machines. The methodologies we are discussing here are intended to help develop exactly such systems.

Compromise is implied:

‘A complete methodo~o~ specification may be i~~ssibly long to write and teach, and to cover every possible real situation would waste developers’ time during training’.

Therefore it seems reasonable Co

apply systems thinking to the methodologies themseives, both to evaluate and select a methodology and to design and improve one. A methodo-

logy which claims to be universally applicable must be capable of being used on itself.

How are methodologies evaluated?

Some writers define the objective of a methodology in rather narrow terms. For example, MacDonald’s objective is ‘to ensure effective utilization of the corporate information resource3’, from which he somehow derives requirements for the methodology in terms of its approach, scope, usability and support. The trouble with such discussion is that it does not provide much of a base for comparison between methodologies.

One way of testing a methodology would be to set objectives which were known to be unachievable. How long would it take the project team to discover that they had been set an impossible task? The better the methodology, the sooner the impossi- bility would be confronted.

Brooks and Smith4 compare what they call ‘bottom-up’ methodologies, such as SSADM with ‘top-down’ methodologies, such as that recom- mended by James Martin. According to their analysis, bottom-up methodologies tend to be:

safe acceptable controllable cumbersome expensive (limited scope for ex- ploiting new tec~ology) inefficient

On the other hand, top-down methodologies are characteristically:

‘cleaner’ more radical expensive (staff skills required) difficult to control there is a risk of producing the wrong solution

Let us try to be more systematic about this.

data processing

policy

Qualities of methodology as system

Systems can (and should) be evaluated according to several qualities:

effectiveness, efficiency, reliability, stability, simplicity, ease of introduc- tion and use, measurability and visibility, among others. How do these apply to the evaluation of methodologies?

Effective

A system is effective if it achieves its

purpose. So we must ask:

Does the methodology work! Does it solve the problems, or produce the products, that it is intended to? Do projects that follow the metho-

dology turn out successfully?

There is dif’ficulty here. Checkland points out that ‘in logic’ we can never know wheth’er good or bad results are produced beNcause of or despite the use of a particular methodology. How- ever, this is a theoretical uncertainty rather than a practical one; it is similar to the difficulty of comparing the ability of two managers by measuring the performance of their departments. We can never know for certain whether a manager is good or just lucky, but as long as the luck

holds perhaps we need not care. If he or she succeeds without doing the things we believe a good manager ought to do, it may be our beliefs which need revision.

Efficient

A system is efficient if it does not waste resources. So we must ask:

l Are all lhe tasks and activities prescribed by the methodology strictly necessary?

l Are all legitimate short cuts ex- ploited?

l Is there any redundancy of effort?

Many methodologies deliberately in-

clude tasks and activities which are logically redundant, to improve the

effectiveness and reliability of the systems development process. Mul- tiple models of the same thing, cross- checking and quality control add to

the time and resources consumed by a project, but they cost less than allow- ing an error to continue undetected.

It is worthy of note, however, that certain proprietary methodologies

claim to remove all redundancy from information systems, while themselves prescribing an indeterminate amount of redundancy in the produc- tion of systems models which they are unable to quantify.

Reliable/accurate

A system is reliable if it always produces exactly the intended results. As a secondbest, it should give clear warning to the user when the results are at all dubious. So we must ask:

l What risks are involved in using

the methodology? l How are the risks minimized? l At what stage of a project can we be

certain of success? l What quality control procedures

are there, and how do they work?

Stable

A system is stable if it is not oversen- sitive to minor errors and alterations. So a methodology should be ‘fault tolerant’ and allow for human im- perfections, both of the systems developers and of the users.

Another aspect of stability is self preservation. Does the methodology contain a mechanism for halting the tendency to drift into informality, impurity and invisibility?

Flexible

Flexibility is related to long-term

stability. A system is flexible if it can be changed to fit new business or

technical requirements. So the

methodology should be capable of

incremental change, for example, so that existing documentation does not

need rewriting each time the consultants change their minds.

Simpleleasy to learn and use/acceptable to users

The system is simple and requires well-defined skills to operate it. So we need to know whom the methodology is aimed at, whether relatively experi-

enced or inexperienced programmers and analysts.

The concept of user friendliness is a

much-abused one. It is easier to describe it negatively, in terms of the absence of features which tend to

irritate people. A methodology should not rely on a stodgy and boring manual. It should be ea.sy to motivate project staff and end users to follow it

with enthusiasm.

Measurablelheuristic

The system allows its own performance (effectiveness, efficiency, etc.) to be easily monitored. A methodology should be integrated with a project control system, so that we can predict the success of a project before

it has finished. The competence of the staff and the suitability of the methodology itself should be monitored. A methodology can be regarded as a learning system (heuristic). So it is reasonable to ask how experience is systematically accumulated and used, either within one project or from one project to another.

Visiblelcomprehertsible

People using the system are allowed to see enough of the workings and struc- ture of the system to understand how it works, how to control it, and what

its scope is, i.e. the extent of its

suitability and power.

~0127 no 6 july/august 1985 11

The alternative to this is mystery, If the system produces results by some magical process, then it becomes the property of an initiated elite, which is not only socially undesirable but also prevents the uninitiated from making an effective contribution.

Therefore a methodology should make apparent, both to DP staff and to end users, exactly how their contributions at each stage of the project will affect the final product. This is useful because it enables people to judge the appropriate level of detail at each stage, and to distinguish the status of different contributions, e.g. separating tentative suggestions from firm requirements. It also makes it more likely that im~rtant facts will be brought to light, which strict adherence to the methodology would have ignored.

Every conceivable situation is handled. Some methodology vendors see this criterion as paramount. Whenever a test case is discovered which the methodology will not handle, the methodology must be changed to take account of it, even if it makes the methodology more complicated or less elegant. Where this is a matter of automatic policy, it appears to this author to be mis- guided. A choice must be made between a special-purpose methodology, which is highly effective and efficient for a narrow range of problems, and a general-purpose methodology, which works moderately well on a wide range of problems. However, the distinction between a general-purpose system and a universal system should be clear. The IBM PC is a general- purpose computer, but is obviously not suitable for every application; a semi-skilled odd job man is a general- purpose labourer who cannot perform brain surgery.

A related danger is that the methodology becomes non-specific and

12

vague. As Boulding points out in a different context:

We always pay for generality by sacrificing content, and all we can say about practic- ally everything is almost nothing.

Objectives bell-de~ned

The objectives of a methodology should be made very clear, whether it is to enable experienced staff to do an even better job faster, or to enable inexperienced staff to cope in complicated situations. And the critical success factors should be defined in advance. Under what circumstances shall a project be deemed a failure?

Conclusion

Methodologies are systems. Therefore systems thinking and systems engineering principles should be applied to them. There are many desirable but conflicting qualities of a good methodology; there are established methods, included in many of the methodologies themselves, for resolv- ing such conflicts.

It is surprising that the methodology vendors appear to have been too blind to apply their own methods to their own product. Yet this appears to be the case, particularly when one or two of the desirable qualities are emphasized at the expense of the others.

According to Edward de Bono, the most difficult part of learning to think is learning to think about one’s own thinking. Self reference is a field of paradox, where angels fear to tread. Yet we must have grave doubts about a methodology designed by people who do not practise what they preach. A methodology should be forced to prove its own worth by applying its own methods to itself.

Most methodologies do not fulfil several of the systematic criteria out- lined in this paper. Many projects have failed because the wrong methodology was used, or the right methodology in the wrong way. Methodo-

logy users often misunderstand what the potential benefits are; methodology vendors sometimes misunderstand what the users’ real needs are.

Yet data processing practitioners should not be daunted, for these are exactly the kind of difficulties faced in nearly all systems development projects. Much of the collective experience of solving such problems is already built into the methodologies themselves. All that is needed is for this potential to be recognized and for the methodologies to be used properly. The next generation of systems development methodologies will be better balanced and will bring great benefits, if only we can be a little more systematic.

References

Tagg, R ‘Too many methodologies’ in Baker, G (ed) Data Analysis Update British Computer Society Database Group (1983) Maddison, R (ed) ~nf~ati~ Sys- tems Methodologies Wiley Heyden (1983) MacDonald, I ‘Systems development in a shared data environ- ment: the Information Engineer- ing methodology, in Baker (ed)’ Brooks, C and Smith, J ‘The Evolution versus Creation debate’ Data Processing Vol 26 No 7 (Sept 1984) Checkland, P ‘Towards a system- based methodology for real-world problem solving’ Journal of Systems Engineering Vol 3 No 2 (1972) Checkland, P Systems Thinking, Systems Practice John Wiley (1981)

Further reading

Veryard, R ‘The importance of visibility in systems’. Unpublished paper, Data Logic (1985) Maddison, R (ed) rnfo~~~~on Systems Development: A Flexible Framework British Computer Society Database Group ( 1984) 0

Data Logic Education, 29 Marylebone Road, London NW1 SJX, UK.

data processing

Documents

What are methodologies good for?