An integrated approach to systems development

An integratedapproachto systemsdevelopment by DAVID MILNER

How a consultancy has been using its own formal development methodology

I

ncreasingly DP departments are recognizing the need for a good systems development methodology to provide a framework for systems development. Method/l, developed by Arthur Andersen & Co, provides such a framework. In addition to being used within the firm’s consultancy division it is used extensively by clients throughout the world.

The development methodology

Abstract: A management consultancy developed its own systems development methodology in the 197Os, which it is continuing to use in updated form with success. Implementation at client sites taught the company many valuable lessons, such as the need for a supportive framework for staff who are using such a methodology for the first time. Keywords: data processing, systems development, project management. David Mimer is a manager in the Management Consultancy Division of Arthur Andersen & Co’s London office. He has spent most of his career with the firm designing and installing malor computer systems for clients in both public and private sectors. He is heavily involved in the support of the Method/l user group on behalf of Arthu.r Andersen & Co.

~0127

no 3

april19851

of the

Method/l was developed in the later 1970s by Arthur Andersen & Co., initially for use by the firm’s Management Consultancy Division in planning, designing and installing computer systems for clients. The idea of a methodology was not new to the firm at that time, as a predecessor to Method/l had been in use for more than 10 years. However it was recognized that something new was required; the pace and complexity of systems development had changed and new techniques needed to be incorporated in the methodo-

l

Clearly, the option of custom developing a methodology was practical because of the size of the organization (in excess of 6000 consultants). For smaller organizations this is usually not the case. In developing Method/l we considered the key success factors for developing systems: Projects need to be delivered on time and to budget if management are to be satisfied, and if business plans, such as the introduction of new products, are to be supported. Users must be satisfied that the system meets their requirements, and that they have been sufficiently involved in its development to accept it as their system. Costly staff must be used effectively . Systems should be easily maintainable and not solely dependent on an individual’s knowledge for support and enhancement.

logy * Two reasons for developing a methodology, rather than buying one off the shelf were: l

To have a methodology which was comprehensive, covering the whole development process, including management and technical steps, in an integrated way. Though other methodologies had clear strengths

0011_684W85/030013-06$03.00

0

1985 Butterworth

in one aspect or another of systems none covered the development, whole field. In order to provide a base for the future, a methodology was needed which could be enhanced and maintained to meet changing needs. A purchased product which might have been out-of-date in a few years would not meet this need.

Features and techniques to help ensure that these objectives are met are built into the structure of Method/l.

& Co (Publishers)

Ltd.

13

Features of the methodology

l

A good system development methodology should provide a number of major features:

l

l

l

l

l

l

A framework for the whole of the systems development process, not just, for example, project management or systems design. Guidelines and techniques to support project management, which is at least as complex as system design and the applications addressed. Without good project management properly integrated techniques, with the development process, there is little chance of success whatever the design and implementation techniques used. Comprehensive definition of activities to be performed and the documentation to be provided. DP and users staff, management should have clearly defined roles and responsibilities and a common understanding of tasks and products required. Much effort can be wasted in ‘reinventing the wheel’, or in failing to do the right things at the right time. Flexibility in providing guidance creative without restricting thought. A methodology should remove the day-to-day problems of how to go about systems development, leaving staff free to think about the system being created. Recognition that all user requirements cannot be specified ‘up front’. The methodology should recognize the need for iteration in specification as users’ ideas develop and change, and should provide for user participation at appropriate stages of the development project. Use of modern techniques, such as structured methods of functional and data design, which are effective in improving the productivity of inexperienced staff and in the production of more maintainable systems.

14

l

l

The ability to cater for a wide range of systems development environments. Systems development in database, TP and online and traditional batch processing environments requires different techniques and emphasis on different activities. As new techniques become available which improve or assist in systems development they should be incorporated within the methodology if it is not to become rapidly outdated. Methods of checking for completeness and quality.

These features have been incorporated in Method/l to provide a comprehensive and integrated approach to systems development. The systems development lifecycle is organized into four phases: l

Information planning, in which the

organization’s strategies for information technology, applications and system software are developed and related to the organization’s business plans. A medium term (three to five years) action plan is developed and costed. l

Preliminary systemsdesign, in which

the user requirements for a system are defined and the functional and technical specifications produced, software packages selected and the installation phase is systems planned. l

Systems installation, in which the

system is constructed, tested and installed, users are trained, and the user, operations and maintenance documentation is created. l

Production systemssupport, in which

the system is maintained and enhanced, and through which new system requirements are identified, to feed back into information planning.

A phased approach is taken for two major reasons: l

l

To provide .management checkpoint reviews of the project at significant stages of development, so that decisions about whether to proceed or change the direction of the project, perhaps in the light of a changing business environment, may be taken. To ensure that only work which is necessary at that stage of development is done. Thus if a major change in direction is agreed or the project is halted, the minimum of work has been wasted or requires reworking.

A key feature of the documentation of the methodology is the planning charts. These illustrate the tasks to be performed within each phase of development and the relationships between tasks. The planning chart in Figure 1 illustrates the tasks involved in the preliminary system design phase. The planning charts also identify quality assurance checkpoints. These are points at which DP management review the quality of the project work, and usually coincide with the initiation or completion of a major segment of work. Quality assurance is supported by checklists designed to focus on areas of risk and to provide direction to the review. Method/l is documented in a series of binders. For each development phase there are two binders, one of which contains a description of each task and step illustrated in the planning charts, explaining how, why and when it is performed, its relationship to other tasks and the inputs and outputs of the task. This binder is crossreferenced to the second binder, which contains worked examples and descriptions of each of the task inputs and outputs. The tasks and steps in the task descriptions manual are organized hierarchically for simplicity and ease of use.

data processing

t

1

L -

i-

-t

~0127 no 3

april 1985

15

The project management binders are organized differently. They contain descriptions of techniques which are used across all development phases, including: project organization, systems development management approach, sample work programmes and responsibilities/skill matrices, structured estimating guidelines, to help estimate the size of projects and the resources required, project control, quality assurance, documentation management.

Implementation One of the most crucial questions to be addressed when considering the use of a methodology is how to implement it. The benefits sound fine, but how do you go about achieving the desired results? Where do you start? Implementation involves changing attitudes of data processing staff. This is often difficult, particularly with more experienced staff, who may regard the introduction of a new methodology as an implied criticism of their existing way of working rather than seeing it as a way of extending and leveraging their skills. Changes in attitudes and working practices take time. It is not possible to implement a methodolo~ overnight and gain any real benefits as nothing, in reality, will be changed. The implementation project needs to be managed with an emphasis on achieving a change in attitudes. As such it requires strong ‘people’ management skills tied to an awareness of the types of problems that will arise and how to overcome them. It is also important to realise that although a systems development methodology is a great help with many problems, it is not a panacea. A company needs to have management application and commitment and a

16

sound or~ni~tion structure to allow any methodology to be effective. A good example of how Method/l should be implemented drawing on experiences with a number of clients is illustrated below.

The first step was to develop a strategy assessing how best to introduce the methodology to the organization. Factors which affect this are: The size of the data processing department. The maturity of the inst~lation and the number of development projects currently under way. Organizations which are relatively new, with few old systems in place, will face different problems to more mature installations which have a strong focus on maintenante .

The extent of existing standards and documentation. The quality and experience of data processing staff and system users. The strategy adopted for this client was in three parts: immediate implementation of systems project management techniques on development projects and support functions, implementation of Method/l design techniques and documentation through a selection of pilot projects, with ‘tuning’ of the methodology to fit the organization, full implementation of design techniques and documentation on all projects. I~ta~~at~onof systemsproject ~~gement techniques Project managers were introduced to these techniques through a series of formal training sessions over a twoweek period. During the following eight weeks managers had one-to-one reviews with experienced consultants.

The techniques were generally well received by project managers who were, after two to three weeks, starting to feel confident that they understood and could use them. The individual reviews were found to be particularly useful to correct misunderstandings and reinforce the formal training as they allowed managers to ask questions and gain a deeper understanding of the techniques in a relatively risk free environment. The short-term effect on systems developments was a rapid improvement in the quality of project status notation and a clarification of where projects were in difficulty. In the longer term, the planning of new projects improved as project managers gained experience in using the estimating and planning techniques, as did the speed and decisiveness of response to problems which arose. Pilot projects Shortly after the introduction of systems project management techniques, work started on the introduction of the design techniques and documentation. This was done through a number of pilot projects: to allow difficulties in use to be identified and dealt with in a restricted and controlled environment, to train a group of the company’s staff to spearhead the full implementation and become ‘inhouse’ experts, to enable other supporting material to be developed.

Projects selected as pilots were at, or near to, a natural breakpoint in their development. This was possible because company’s previous the approach was formalized to the extent of having a number of defined products and review points, e.g. feasibility study, systems specification etc. Selection was also based on complex-

data processing

ity of the project. It was felt necessary to have a balance of simple projects which could be completed without running into problems, to use as teaching vehicles and to demonstrate some short-term success to build morale and confidence, and complex projects which woulc’ ‘test’ the methodology and staff and surface any real difficulties in using it. Four projects were thus selected; two short and simple and two more complex. In training project teams, standard training material was modified to put emphasis on specific areas of weaknesses in the company. In this company’s case there was little understanding of data analysis and this was judged to be a key area to address in the pilot projects. Formal training included the use of case study problems. These were found to be very helpful in making staff focus on the documentation and techniques in the context of a ‘real’ problem. Again this formal training was followed up by regular expert reviews of the use of the techniques. The main problems the pilots were:

encountered

on

manuals themselves, modifications were written as standalone sections and referenced in the overview manual. This allowed tailoring while still allowing the standard annual updates to the methodology, provided by Arthur Andersen & Co., to be incorporated with minimal effort. These documents were initially drafted at an early stage and refined throughout and after the pilots, over a timescale of about nine months. A recurring problem was balancing the necessary training with the day-today pressures of project and support work, making it impossible to have all people attend the right sessions at the right time. By necessity, a flexible approach to the training had to be taken, including reruns of sessions and individual tutorials, but a very strong-willed approach was needed to stop the training programme falling into disarray because of the pressures upon it.

Full im~l~entation Fult implementation of ~ethod/l followed the completion of the pilot projects. This involved: an assessment of the results of the pilot projects and identification of outstanding issues and problems requiring resolution, planning when Merhodl would be introduced to existing development projects and then making this hap-

* A late realisation by staff that they needed to work at learning the techniques they were trying to use. Despite the formal training, it was found that many staff really did not face up to thinking about how to use the techniques until they had tried once and got into difficulty. l A rf3iStanrc tO change. During the pIlot proiects the methodology was ‘tuned’ to fit the company’s environment by the production of a methodology and stiandards overview manual and the production of specific documentation based on the Method 1 ex.ample documents selected _ The overview manual acts as a large index to the methodology and associated standards in the company. Rather than modify the Method/l

~0127 no 3 aprii 1985

pen, training 01. all the data processing development staff, setting up a review and quality assurance framework to monitor and support the progress of the full implementation. The pilot projects raised a number interesting issues including: l

of

What should be done about existing systems documentations particularly when projects are converted to Method/l part way through the development.

0

The need for organizational change, where the clear definition of development tasks within the methodology highlighted the need for clearer definitions of responsibilities and reporting lines, particularly in the areas of database design and data administration.

Method/l was introduced to projects as they arrived at natural breakpoints, such as at the end of system specification, in the same manner as in the pilot projects. At this point the system documentation was reviewed and a ‘minimum set’ of Method/l working papers created, rather than attempting to rewrite all documentation in the Method/l format. The remainder of the documentation was indexed and reorganized to make it easily accessible. Training was organized using material developed for the initial training, but this time client staff who had worked on the pilots participated in the teaching, again as a step towards self support within the organi-

zation . The majority of the problems in the full implementation were in management of the implementation project itself. Short-term pressures from other work made commitment of resources for training and for ‘first time through’ usage of the methodology difficult to obtain. This made it absolutely essential to have clear, short-term, measurable targets to maintain momentum i,n an area which may often seem, in chc eves _ of senior management, nebulous or, after the initial enthusiasm. ii drain on resources. In addition, there needs to be a strong supportive framework
17

l

through the use of quality assurante checklists, which provide key questions to check on whether or not the methodology is being used properly and effectively.

At what stage could we say the methodology was fully implemented? In reality this is a continuous process which never stops; new staff join the organization and must be trained, new techniques become available and so on. However, from a management perspective, there needs to be an ‘end’ to the initial high investment stage, by which time some of the benefits of implementing methodology the should be mater&&sing. This stage should be reached within about nine months, by which time in this company a number of projects had completed significant phases of development, and the company had become relatively selfsupporting in the use of Method/l.

Future direction Method/l is an integral part of Arthur Andersen’s consulting practice. As such, there is a high level of commitment to its future develooment and enhancement to ensure that it remains up-to-date and relevant. Recent developments include:

l

l

The introduction of personal computer-based packages to assist project managers in estimating manpower effort, project control and change control. The introduction of a personal computer-based design assist package, Design/l, which provides for automation of much of the design documentation, with crossreferencing, validation and library facilities, and the facility to construct conversation prototypes. Included within Design/l are many aids designed to help productivity, in-

&ding the provision of standard design structures for common program types. These recent developments are now in use by Arthur Andersen and clients and have been very well received. The automated tools reduce the potential difficulties of implementation, and the productivity of staff and the quality of work produced have been improved as a result of the introduction of Design/l. We rely on Metho~l in our own practice and are strongly committed to its future enhancement. In the relatively near future we expect to make more of it available in an electronic form and gradually merge it with automated development tasks. A methodology is not static; it must be updated and enhanced to keep pace with, and lead, changes in the world of systems development. iI Arthur Andersen & Co., 1 Surrey St, London WCZR ZPS, UK.

Reprints Reprints of all articles in this joumal are available in quantities of 100or more Reprints are essentiaifor the company that wants to distribute impartial comment on its activities to potential customers and clients l for the company that wants to up-date its technical staff on new techniques and new technologies l for the company that wants to publicize its research and development work * for the training course organizer who wants to assemble key reading material for his students l for the university or technical college lecturer who wants to distribute the latest information on a topic under study l

For full details of prices and availability of reprints, please write to The Reprint Department Butterworth Scientific Limited FORox WestbnryHouse BuryStreet Guildford Surrey GU2 SBE England

18

data processing