The problems of managingsoftware projects

by Alan Wingrove

Experience suggests that projects involving a significant softwarecontent run a considerable risk of being completed late and overbudget, while the resulting software does not always meet the originaldesign specifications. This is in spite of the fact that the generalprinciples of project management are well understood. This paperdiscusses the particular difficulties often cited by managers ofsoftware projects.

1 Introduction

The general principles of project manage-ment are well established. Using them, it ispossible to complete projects on time,within budget and with a specifiedperformance. Why then should we be dis-cussing problems of managing softwareprojects? Are there general problems orjust particular problems with certain typesof software projects?

From the evidence it would appear thatany project which involves a significantsoftware content runs a high risk of beingcompleted late and costing significantlymore than was budgeted. There are alsofrequent reports that software designs donot always perform as well as they should.Project managers often complain thatthey meet difficulties when dealing withsoftware which lead to significant loss ofcontrol within the project as a whole.

The most significant of these com-plaints are:

• a general lack of visibility• incomplete and ambiguousrequirements• imprecise and incompletespecifications• a lack of agreed terminology• uncertainties in software/hardwareapportionment• rapidly changing technology• suitability of languages• inability to model systems• difficulties in resource and costestimation• inability to predict and measurereliability• difficulties with progress monitoring• complicated error and change control

• a lack of agreement on test metrics• problems with interfacing• problems with integration• difficulty of controlling maintenance.

The list of difficulties is considerable and,overall, paints a bleak picture. For-tunately, not all the problems are met onall the projects! Nevertheless, even singly,some of the problems are significant andfundamentally damaging to the wholeframework of project management.

2 Management

Any project must have a clear objective if itis to succeed. Reaching that objective

must depend upon the availability of ade-quate resources to complete the taskwithin a given time scale and an ability toplan, measure and control thoseresources.

There are today few projects of any sig-nificance (in the technological sense)which do not include some aspect ofcomputing and software. The amount ofsoftware (and we are here essentiallyequating software to the programmingcontent) in a project varies enormously.On the one hand there are projects wherethe software is the totality of the final prod-uct — for instance a computer operatingsystem, a compiler, a computer-aideddesign program or an office payroll sys-tem. On the other hand software may rep-resent only a small proportion of the totalproject, even though that proportioncould involve a task of considerable mag-nitude. Examples might be a computer-controlled chemical process plant or arailway signalling system.

Between the extremes lie a whole rangeof projects involving software, of differing

NEED

DEFINITION

s requirement

SYSTEMDESIGN

DETAILDESIGN

PRODUCTIONAND TEST

IN-SERVICE

specification

apportionment

technology

language

modelling

prediction

s design

code/build

integration

performance

operation

maintenance

Fig. 1 Project life cycle

Software Engineering Journal January 1986

requirements andspecification

1

<̂ hardware^

1

1 -

r

systemdesign

r

apportionment

detaildesign

<t

build

1 r

unittests

t

performancerequirements

r

designconformity

\ r

testrequirements

r

integrationand test

\ r

systemvalidation

1 i

system evaluationand certification

—H ^software^

\detaildesign

} t

code

} t

moduletests

Fig. 2 Project elements

size and complexity but all with one com-mon feature — total dependency on thesoftware working correctly.

It would be idle to pretend that the wellestablished techniques of managementused successfully with hardware projectsfor many years can simply be applied tosoftware. Similarly, the managementtechniques which have been developedfor controlling software are rarely applica-ble to hardware. So, in a sense, for a com-mon class of project we have identified amajor problem — that of integrating bothhardware and software managementtechniques. Nevertheless, the problemsare much wider than that. Even when theproject is predominantly software, con-siderable difficulties can be encountered.Before examining the difficulties in moredetail it would be sensible to describe, in ageneralised form, the make-up of aproject.

3 The project

A project is the framework within whichthe needs of a 'customer' are transformedinto a finished product by a 'contractor'.The individual considerations and oper-ations which make up the project life cyclecan be grouped into six distinct phases(Fig. 1) — from establishing a need for aparticular equipment or product through

to introducing it into service.Fig. 2 represents the process in block

diagram form, and this can be repre-sented as a V-flowchart (Fig. 3) whichshows the stage by stage developmentand testing of the system. In theory, pro-gression to a new stage of developmentdoes not occur until the review or testingcriteria for the preceding stage have beensatisfied and the design problems sortedout. In practice, of course, this ideal statecan rarely be satisfied. To meet timescales, some development is done in par-allel, solution of some design problemsmust be deferred and design compro-mises must be made. In some casesdesigns will be found to be infeasible, nec-essitating the customer revising therequirements, with consequent changesto the specification.

However, none of these perturbationsto the smooth course of a project shouldbe seen as an excuse for the failure ofproject managers properly to control thedevelopment of a system. With propertechniques and tools, it should be pos-sible to overcome all but the mostextreme disasters. So it may be that it is alack of these techniques and tools that isthe prime cause of much of the presentproblem, particularly when it comes todeveloping mixed hardware-software sys-tems. Let us look then in more detail at the

list of difficulties cited by project man-agers and listed earlier.

4 The problems

The most frequently voiced complaintfrom project managers is undoubtedlythat of a 'lack of visibility'. It is often diffi-cult to determine exactly what this means,but generally it expresses all the uncer-tainties and frustrations that have beenencountered in dealing with softwarecreation and integration within a project.

Methods of managing hardware pro-jects are well established and understood.The level of previous experience is exten-sive and so confidence in techniques fordetermining and controlling resourcesand progress is high. But, with software,the situation is often less satisfactory, par-ticularly when the software is only oneelement of a large project. In these cir-cumstances one often encounters thesituation where the manager is not acomputer or software specialist. Parts of asystem may be developed by differentsub-contractors at different geographicallocations and under quite different man-agement systems. Even co-ordinatingthese widespread activities is task enoughwithout the additional difficulties asso-ciated with software development.

The earliest problem encountered isusually that of obtaining a clear, completeand unambiguous statement of the cus-tomer's needs — in project terms, therequirement. For anything other than avery small or simple project, this perfectrequirements document is an impos-sibility. The customer is often unsure ofthe technical solution of his needs or,indeed, whether his needs can be com-pletely satisfied. There is likely to be ambi-guity since requirements are usuallyexpressed in natural language using thecustomer's own terminology. The bestthat can be hoped for is an unambiguousexpression of the needs (not 'wants' ordesires!) which can be transformed into asystem specification with the co-oper-ation of the customer.

Major problems will be inevitable if athorough process of requirementsreviews has not been carried through asthe system specification is evolved. It willbe almost inevitable that some changewill be necessary later as the designevolves. But it must be recognised thatchanges become ever more expensive asthe project proceeds, are a potentialsource of disaster and should be avoidedwhenever possible.

The lack of an established and agreedterminology contributes to the confusionin the early stages of a project. Termswhich are at one time used synonymously— error, fault, mistake, failure, bug — areat other times used with quite specific anddifferent meanings. Semantic arguments

Software Engineering Journal January 1986

denying the notion of software reliability— programs can only be right or wrong —do not inspire the sympathy of a systemsengineer looking for the reason for failurein a software-based system.

There is little guidance or experience ofoptimising the apportionment of hard-ware and software functions in a systemdesign. There is usually an overoptimisticview of the cost, flexibility and adaptabilityof software, particularly when used to cir-cumvent hardware problems. This oftenresults in a large number of design prob-lems being put to one side for later sol-ution — the dreaded TBD (to be decided)— which often means that, when the deci-sion has to be taken, no flexibility of sol-ution remains.

Rapid changes in computer and pro-gramming technology add to the con-fusion. Successive projects tend toincorporate the latest advances in tech-nology so that there is always little or noprevious experience to draw upon. Thepull of conservative design is no match forthe push of emergent technology. Evolu-tion of new programming languages isslower. Nevertheless, there often appearsto be little thought for the suitability of alanguage to do the task demanded by thesystem design. It is sometimes the casethat a preferred language is imposedupon a project without any thought for thedifficulties that this might cause.

The present inability to model systems,particularly when they are a mix of hard-ware and software; uncertainties inresource and cost estimation; inability topredict or measure reliability; all thesecreate difficulties in monitoring and con-trolling software projects. It is not so mucha question here of having no models withwhich to work as having a number of

models available which give widely differ-ing and confusing results when used.

Little advice appears to be available onhow to select a particular model for speci-fic projects — or why! The cost of gainingaccess to some models, the trainingneeded and the uncertainties of successfrequently dissuade a manager from tak-ing the initial step towards their use.

The actual transformation of a softwaredesign to a working program is probablythe best managed of all project phases.Errors in coding are expected, hunteddown and corrected. Methods and toolsare available to make the process as effi-cient as possible. Despite this, consider-able difficulties can be experienced.Reports of a lack of discipline in error andchange control and disagreements ontest methods and metrics can have cata-strophic consequences for interfacingand integration.

Finally, when a system is accepted intoservice, a lack of tight control on sub-sequent 'maintenance' (a mixture of cor-rection and enhancement) is anotherroad to disaster.

5 The picture

It has to be admitted that the manager of aproject which includes development ofsoftware has, at present, a very difficulttask. The situation is particularly seriouson projects which involve 'embedded'computers, since there appears to be analmost total lack of guidance on how tomanage the integrated development of amixture of software and hardware. More-over, there appears to be little effort beingdevoted to rectifying the situation. Evenwhere the project is wholly or predomi-nantly concerned with the development of

software, advice is fragmented and oftenconfused.

The system definition phase wouldappear to be that deserving the greatestattention. Reports that have appearedover the last five years or so suggest that50% or more of the totality of projectproblems and difficulties can be tracedback to some deficiency of the require-ments or system specification. Certainly,more dedication to requirements reviewswould pay dividends. This is somethingwhich concerns the customer, who isoften reluctant to spend substantialamounts of time sorting out the early'paperwork' and would rather see theeffort going into cutting metal or codingprograms. There needs to be a greaterawareness of the mounting cost of catch-ing errors as the project proceeds.Equally, the high cost of late changes tothe requirements or specification needsto be emphasised.

Currently there is considerable activityin the standards field, both nationally andinternationally. Unfortunately, little of theeffort appears to be co-ordinated, and atimely resolution of the problems of dif-ferent terms and definitions seems to beremote. Even some limited co-ordinationbetween the Alvey and ESPRIT Pro-grammes in Europe would be helpful.Until some internationally agreed defi-nitions and standards are accepted,semantic confusion will continue.

More attention needs to be paid to therelative advantages and disadvantages ofimplementing design solutions in hard-ware and software. The overoptimisticviews of both customer and contractor onwhat can be done with computers need tobe tempered by the problems that havebeen experienced on some projects. It

requirements

REQUIREMENTS REVIEW

systemspecification

acceptance/certification •

system validation

operationaltesting

integratedsystem test

_ / \ Isoftwarespecification

hardwarespecification

hardwareintegration tests

PRELIMINARY DEblbN RtVltW _ V _ \"V "X

moduleintegration tests

top-leveldesign

hardwaredesign

CRiTJpAL_DESI_GN_ REVIEW . . _

/sub-systemtests

/

moduletests

detaildesign

hardwarebuild

DETAIL DESIGN REVIEW x .

codetesting

codingCODE REVIEW— — — —— — — — — — — — ^ — — — — — — — — — — —- — — — — —— — — — — —\

Fig. 3 Project stages

Software Engineering Journal January 1986

should not be automatically assumedthat, because software functions canreplace hardware, then they should. Soft-ware frequently presents unexpectedproblems and can prove to be less reliablein service than hardware.

The rapid changes in computer andmicroprocessor technology are likely topersist for some considerable time tocome and present an intractable problem.The difficulties are greatest for the mostcomplex projects involving long timescales, where current state of the art canbecome of museum quality duringdevelopment! The penalty for the rapidexpansion of horizons is a woeful lack ofexperience and advice.

Similarly, the growing number of pro-gramming languages presents occa-sional difficulty. A language is not alwayschosen for a software project because it ismost suitable for the particular appli-cation. Often the choice is made on thebasis that the particular language is wellsupported by development tools, and thatis a sensible reason. Sometimes the useof a language is made mandatory to max-imise support and experience. In eithercase the choice may not be the most suit-able for the application.

Modelling of one sort and another hasattracted considerable attention over thelast decade, and with good justification. Ifa manager is to estimate accurately theresources needed for successfully com-pleting a project, then cost and reliabilitymodels are essential. Unfortunately, thecurrently available models can give widelydiffering answers to the same problem. Itmay be that we have reached a stage

where models have become too gener-alised and need to be adjusted or tailoredfor specific areas of application. Since theproject data and experience needed toparticularise the models are only gatheredover a long time period, it would seem thatthis area of difficulty will persist for sometime. Without models to plan the targetprogress for a project it becomes moredifficult to measure and track actualprogress.

The problems associated with versioncontrol should be considerably reducedas manual methods give way to auto-mated methods as integrated project sup-port environments (IPSEs) are intro-duced. The IPSE could also be of greatbenefit in reducing many of the humanerrors which contribute to the problems ofinterfacing, integration and configurationcontrol (maintenance) in service.

Disagreement on the metrics neces-sary for project control, reliability assess-ment and software testing is partlyassociated with the disarray over termi-nology and standards mentioned earlier.Some progress on this topic is beingmade in the UK, if only as a need to agreeupon the parameters to be used forgathering data for the Alvey SoftwareDatabank project.

6 Progress

It would be wrong to create the impres-sion that the software scene is a totaldisaster. Conversely, it would be equally

wrong to ignore the fact that, for a varietyof reasons, software projects have gaineda reputation for being completed late,over budget and often with disappointingperformance.

There is much work in progress whichshould eventually provide the projectmanager with many of the tools and tech-niques which are so badly needed. Thereis a growing awareness of the value andnecessity for investing in support for theproject manager and allowing sufficienttime within the project time scale forproper baseline review procedures andprogress reviews at defined milestones.Some progress is being made on stan-dards, terminology and metrics. Workcontinues on generalised cost andreliability models, but there is an urgentneed for work on investigating models forintegrated hardware-software projectmanagement. Introduction of the IPSEconcept should provide great benefits inboth management and reliability terms.

Until some definitive guides to manag-ing the process of software creation areavailable, particularly in conjunction withhardware, project managers will continueto work under great difficulty. Advice isavailable, but it tends to be scattered,diffuse and sometimes confusing. It is tobe hoped that the current Alvey Pro-gramme will produce not only the meth-ods, tools and technology to producehigh-quality software, but also the man-agement methodology by which they canbe applied.

A. Wingrove is with the Royal Aircraft Establishment, AW3, Farnborough, Hants. GUM 6TD,England.

Software Engineering Journal January 1986