An integrated approach to systems development

by DAVID MILNER

How a consultancy has been using its own formal 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.

I ncreasingly DP departments are recognizing the need for a good systems development methodo-

logy 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 of the methodology

Method/l was developed in the later 1970s by Arthur Andersen & Co., initially for use by the firm’s Manage- ment Consultancy Division in plan- ning, designing and installing com- puter 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 complex- ity of systems development had changed and new techniques needed to be incorporated in the methodo-

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

l

in one aspect or another of systems development, none covered the 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.

Clearly, the option of custom deve- loping 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 con- sidered 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 effect- ively . Systems should be easily maintain- able and not solely dependent on an individual’s knowledge for sup- port and enhancement.

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

~0127 no 3 april19851 0011_684W85/030013-06$03.00 0 1985 Butterworth & Co (Publishers) Ltd. 13

Features of the methodology

A good system development method- ology should provide a number of major features:

l A framework for the whole of the systems development process, not just, for example, project manage- ment or systems design.

l Guidelines and techniques to sup- port project management, which is at least as complex as system design and the applications addressed. Without good project management techniques, properly integrated with the development process, there is little chance of success whatever the design and imple- mentation techniques used.

l Comprehensive definition of activi- ties to be performed and the docu- mentation to be provided. DP staff, management and users should have clearly defined roles and responsibilities and a common understanding of tasks and pro- ducts required. Much effort can be wasted in ‘reinventing the wheel’, or in failing to do the right things at the right time.

l Flexibility in providing guidance without restricting creative thought. A methodology should remove the day-to-day problems of how to go about systems develop- ment, leaving staff free to think about the system being created.

l Recognition that all user require- ments 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.

l Use of modern techniques, such as structured methods of functional and data design, which are effec- tive in improving the productivity of inexperienced staff and in the production of more maintainable systems.

l The ability to cater for a wide range of systems development environ- ments. Systems development in database, TP and online and tradi- tional batch processing environ- ments requires different techni- ques and emphasis on different activities.

l As new techniques become avail- able which improve or assist in systems development they should be incorporated within the metho- dology if it is not to become rapidly outdated.

l Methods of checking for complete- ness and quality.

These features have been incorpor- ated in Method/l to provide a com- prehensive 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 infor- mation 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 systems design, in which the user requirements for a system are defined and the functional and technical specifications produced, software packages selected and the systems installation phase is 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 systems support, in which the system is maintained and en- hanced, and through which new system requirements are identified, to feed back into information plan- ning.

A phased approach is taken for two major reasons:

l To provide .management check- point 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.

l To ensure that only work which is necessary at that stage of develop- ment 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 deve- lopment and the relationships be- tween 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 initia- tion or completion of a major segment of work. Quality assurance is sup- ported by checklists designed to focus on areas of risk and to provide direc- tion 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 plan- ning 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 or- ganized hierarchically for simplicity and ease of use.

14 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 re- sponsibilities/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 achiev- ing 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~ over- night 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’ man- agement 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

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 stra- tegy 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 mainten- ante . 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 sys- tems project management techni- ques on development projects and support functions, implementation of Method/l de- sign techniques and documentation through a selection of pilot pro- jects, with ‘tuning’ of the methodo- logy to fit the organization, full implementation of design tech- niques and documentation on all projects.

I~ta~~at~on of systems project ~~gement techniques

Project managers were introduced to these techniques through a series of formal training sessions over a two- week 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, start- ing to feel confident that they under- stood and could use them. The indivi- dual reviews were found to be particu- larly useful to correct misunderstand- ings and reinforce the formal training as they allowed managers to ask questions and gain a deeper under- standing of the techniques in a rela- tively risk free environment.

The short-term effect on systems developments was a rapid improve- ment 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 techni- ques, as did the speed and decisive- ness of response to problems which arose.

Pilot projects

Shortly after the introduction of sys- tems project management techniques, work started on the introduction of the design techniques and document- ation. This was done through a num- ber of pilot projects:

to allow difficulties in use to be identified and dealt with in a re- stricted and controlled environ- ment, to train a group of the company’s staff to spearhead the full imple- mentation and become ‘inhouse’ experts, to enable other supporting mate- rial to be developed.

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

16 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 weak- nesses in the company. In this com- pany’s case there was little under- standing 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 encountered on the pilots were:

* 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 method- ology 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 selec- ted _

The overview manual acts as a large index to the methodology and associ- ated standards in the company. Rather than modify the Method/l

~0127 no 3 aprii 1985

manuals themselves, modifications were written as standalone sections and referenced in the overview man- ual. This allowed tailoring while still allowing the standard annual updates to the methodology, provided by

Arthur Andersen & Co., to be incor- porated 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-to-

day 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-

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 of interesting issues including:

l What should be done about exist- ing systems documentations parti- cularly 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 responsi- bilities and reporting lines, particu- larly 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 specifica- tion, 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 attempt- ing to rewrite all documentation in the Method/l format. The remainder of the documentation was indexed and reorganized to make it easily acces- sible.

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 to- wards self support within the organi- zation .

The majority of the problems in the full implementation were in manage- ment 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 methodo- logy 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 re- sources.

In addition, there needs to be a strong supportive framework <or the management and sr:~ff who ar’e using the methodology ior the iirst time. This was provied in two ways:

* by experienced stati: who had worked on the ptlot pro:ects pro- viding detailed assistance within the project teams,

17

l through the use of quality assur- Future direction &ding the provision of standard ante checklists, which provide key

Method/l is an integral part of Arthur design structures for common pro-

questions to check on whether or not the methodology is being used

Andersen’s consulting practice. As gram types.

properly and effectively. such, there is a high level of commit- These recent developments are now in

ment to its future develooment and use by Arthur Andersen and clients

enhancement to ensure that it remains and have been very well received. The

At what stage could we say the metho- dology 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 the methodology should be mater&&sing. This stage should be reached within about nine months, by which time in this com- pany a number of projects had com- pleted significant phases of develop- ment, and the company had become relatively selfsupporting in the use of Method/l.

up-to-date and relevant. Recent developments include:

l The introduction of personal com- puter-based packages to assist pro- ject managers in estimating man- power effort, project control and change control.

l The introduction of a personal computer-based design assist pack- age, Design/l, which provides for automation of much of the design documentation, with crossreferen- cing, validation and library facili- ties, and the facility to construct conversation prototypes. Included within Design/l are many aids designed to help productivity, in-

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 introduc- tion 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 elec- tronic 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 100 or more

Reprints are essentiai-

l for 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

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