Large-scale project managementIndexing terms: Engineering administration and management

Abstract: A forum on the total management of large-scale projects was organised within the Management &Design Division of the IEE,* with the objective of providing an interchange of ideas among engineersactively engaged in this field, at superior levels of responsibility. Part 1 of this record of the forum is asummary of the introductory address by Vice Admiral Sir Lindsay Bryson, who traced the history of projectmanagement in the defence procurement sphere, leading to the recent trend towards placing managementresponsibility with a prime contractor in industry, taking as an example the Sting Ray torpedo project. Theparticipants in the forum comprised some thirty invited members from the fields of industry, research anddevelopment, the public sector, and the armed services. They were invited to discuss a number of problemareas, and their views and experience have been collated and summarised in Part 2. This is intended to serveas a primer and checklist to assist those who are required to engage in such projects. It is proposed to initiatea further study of how project experience may be recorded, and to develop a recommended code of practice.

PART 1: INTRODUCTORY ADDRESS

Vice Admiral Sir Lindsay Bryson K.C.B., B.Sc.,

C. Eng., F.I.E.E., F.R.Ae.S.

1 Introduction

When I was asked to give this keynote address, and was pon-dering which of the large-scale complex projects that havebeen undertaken in my field of responsibility would be mostlikely to be of general interest, and in which our experiencemight be useful outside the defence procurement field (which1 believe to be rather specialised), it became clear to me thatthe bigger and more complex the tasks I looked at, the greaterthe joint involvement, at all stages, of those who might beregarded in simple terms as the 'customer' and the 'contractor'.Considering the total activity necessary to devise, provideand maintain the equipments essential to make our operationalforces effective, it was clear that there is a multiplicity ofcustomer/contractor relationships; and one of the mainrequirements for success in the overall endeavour is toidentify and arrange these relationships and set up the inter-faces in a way which can be effective and economical.

These thoughts led me to consider the great changes whichhave occurred in defence procurement since World War II,to look at the reasons for these changes, and to reflect uponthe effect they have had on the aims of management, thetasks identified and the methods of achieving the goals.

This is a very live subject as evolution to meet the everchanging situation continues. I believe it would be profitablefor me to outline some of the major changes that have oc-curred in the defence procurement field and to try to identifya few quite simple changes in concept which have had, andare having, a profound influence.

2 Equipment development in earlier years

First, a little history to put the present situation into context.In the World War II era, equipments making use of rapidlyevolving technologies were developed largely independently,and there was great dependence on the selection and trainingof men and women to bridge the gaps between them andcome some way towards gaining the operational advantagesvisualised.

The scientific study of the actual operational effectiveness

•The Forum took place on 12th March 1982, at the Institution ofElectrical Engineers, and the chair was taken by Dr. D. M. Leakey: itwas an activity initiated by Professional Group M4 (Management skillsand techniques)

Paper 2155 A, received 19th July 1982Vice Admiral Sir Lindsay Bryson is with the Office of Controller of theNavy, Whitehall, London SW1A2HB, England

achieved, and also of what might be offered by the exploitationof new technical capability, played a new and very significantrole, and the harnessing of resources, wherever they couldbe made available, greatly extended the involvement ofindustry in defence procurement and gave impetus to changefrom a situation in which the major part of the design workwas done within government organisations, with some manu-facture in industry, to an ever-increasing proportion of bothbeing carried out in industry. A similar situation had arisenfollowing World War I, when it was decided to sponsor thebuilding up of an aircraft industry and to ban the 'in-house'design of aircraft for production.

This situation continued into the postwar era and in newtechnology areas where industry had been heavily involved;e.g. aircraft electronics and now guided weapons, which werefollowing the aircraft pattern of procurement. Conceptsof system operation were gaining ground, but systems werestill largely visualised as consisting of separate elements,using human skill to provide the flexible and intelligentinterfaces necessary to enable them to work togetherefficiently.

In this phase, the ability to introduce improvements duringdevelopment, to continue to offer the highest possible per-formance, was thought by many to be the best way ofarranging to provide the most effective weapons when required(a kind of continuous development), and the 'cost-plus'method of working with industry thrived. Projects tendedto evolve continuously and often cost many times the originalestimate.

It was, however, becoming clear that the increasing per-formance theoretically possible by employing the most ad-vanced technology could only be achieved by the carefulintegration of separate equipments and weapons into systems,in which the performance and design of the various essentialparts were compatible and the interfaces between themdevised to allow them to operate together effectively. Theplanning and development of 'systems' evolved, such asguided-weapon systems, warships' overall systems for airdefence, air-traffic control, army field headquarters, etc.

At the same time, the top-level pressure, which had beenstriving to build up teams quickly to exploit new technologicalpossibilities for defence, gave place to a realisation, in somequarters, that the rate of progress was so great that the selec-tion of tasks and the definition of them, and the containmentof costs within forecast expenditure, were becoming majorproblems; which, with the increasing size of projects, it wasessential to grasp quickly.

3 Recognition of development as a continuous process

To review the problem of the underestimation of develop-ment costs, a steering group was appointed, under the chair-manship of Mr. Downey, and the report published in 1967

JEEPROC, Vol. 129, Pt. A, No. 8, NOVEMBER 1982 0143-702X/82/080625 + 09 $01.50/0 625

has been the basis for significant changes in concept andprocedure. One very significant advance, essential for largeprojects if momentum is not to be lost, was to advise thata project, from the earliest beginnings to the end of develop-ment, should be recognised as a continuous process. At pre-planned specific points at the end of each stage, decisionswould be taken on whether to proceed: but funding andwork must be arranged to continue during the decisionperiods. Thus:

(i) the services recognise the need for new equipment(ii) discussions lead to the formulation of a staff target,

which is approved(iii) approval is given for the feasibility study to proceed,

which enables the staff target to be refined as a staff require-ment

(iv) after approval is given the first phase of projectdefinition leads to the second phase, then to full develop-ment

(v) after acceptance trials to assess whether the requirementis met, production starts.

Complementary features, since introduced, inhibit changesin operational requirement during development and providea detailed definition of the task to be undertaken and acontract-acceptance specification to demonstrate achievement,and, finally, some means to obtain effective financialdiscipline. A Downey recommendation was that up untilthe end of project definition one should expect to haveto spend about 15% of the total estimated costs of develop-ment. My experience reinforces this, and, if anything, 15%may be on the low side.

The trend towards greater industrial involvement did notaffect all areas of defence procurement equally: the balanceof development work between industry and 'in house' covered(and still covers) the complete spectrum, from mostly 'inindustry' for aircraft and guided weapons, to mostly 'in house'for guns and ammunition. Such aspects as heavy armouredfighting vehicles and underwater weapons tended towardsthe 'in-house' end; industry being, in general, used as sub-contractors for specified parts and units, but the overalltask being dealt with by detailed direction from within theMinistry department. I believe there is a lesson to be learntfrom all this: an industrial base has survival as its objective,and measures its success in terms of profitability; whereas anintramural base will make every effort to meet a service need,and, certainly in the past, has perhaps been less conscious ofcost considerations and the need to end up with a marketableproduct.

4 An example: The Sting Ray project

4.1 Development of underwater weaponsSting Ray is the very complex lightweight torpedo, whichyou may be aware of from the news coverage it has received.By choosing this weapon as an example I have given a hostageto fortune, as it cannot yet be said to be 'successful' in thesense that it has yet to meet the service requirements withintime and cost. But it is a project in which, during develop-ment, we made the drastic change of switching from detailedcontrol from within the MOD to the appointment of a primecontractor in industry to take over the task.

It would be invidious to rehearse the history of our failuresto bring to fruition the many attempts to convert good ideasand concepts into effective in-water weapons in the torpedofield; they have to a high degree been matched by othercountries and, broadly, in my view, are due to a lack ofrealisation of the quality of engineering and the amount ofcareful in-water testing necessary to evolve both the skills

626

and specific designs to survive and operate in this mostdifficult and complex environment. The need to evolve specialmanagement methods to deal with guided weapons wasrecognised quite early in the postwar period, but did notpenetrate the underwater weapons area, which, because oftraditional attitudes and its very specialist nature, remainedaloof. This was very unfortunate, as to meet our needs incountering the massive underwater power of the Soviet bloc,weapons of very high sophistication (well beyond that re-quired for most airflight guided weapons) are essential andmust operate effectively in a more difficult environment.

4.2 Feasibility studies o f systemsFor my chosen example, the Sting Ray torpedo, conceptsfor advanced-performance weapons exploiting known tech-nologies to the maximum were the subject of feasibilitystudies which enabled work to start in 1971 on this develop-ment, to meet the naval- and air-staff requirement. To achievethe necessary performance to meet the sophisticated threatpredicted, each aspect of the complex weapon had to operateat the limits of engineering knowledge and in conditions forwhich scientific data was lacking on many critical aspects.The attempt to define the performance and engineeringrequirement for the various subsystems in the weapon,together with the interfaces, to have them developedseparately and then bring them together to produce theweapon with a minimum of interaction and stage-by-stagetesting during development, was doomed to failure. This is thetraditional pattern for design, when there is full and com-prehensive engineering and environmental knowledge available,and has been used with some success in other longer-standingactivities where innovation was relatively very slow. However,it was completely unsuited to the development of Sting Ray,in which the interaction between the separate functional units,which have to be developed separately by specialist teams, isvery close and must be dealt with continuously, as knowledgeand experience is built up.

4.3 Review of management methodsBy 1977, notwithstanding good basic concepts for the weapon,development was heading for disaster. A special investigationwas carried out by senior officers, experienced in the guided-weapon, aircraft and electronics fields, it was decided thatmanagement methods based on those developed for guided-weapons systems should be employed, and that to providethe essential flexibility, together with financial incentivesto create the drive for success in cost and time, as well asperformance, the task would be passed to industry byappointing a prime contractor.

There were many problems to be overcome in makingthis change successfully, though the prime contractor hadbeen supporting the intramural project team in a co-ordinatingrole; the many subcontractors were working on MOD 'cost-plus' contracts, and the terms and conditions were not directlytransferrable to the new prime contractor.

4.4 Basis of the contract with prime contractorSo the task was begun on a cost-plus basis to cover the initialperiod during which the job was to be appraised, and pro-posals were made for the completion of development andinitial production. The aim was to arrive at a contract basedon a target cost for the total task, which was to be specificallydefined by a set of 'agreed characteristics'. These agreedcharacteristics defined, as precisely as possible, the technicalinterpretation of the staff requirement and the engineeringand performance aspects which had to be achieved and demon-strated in specified trials, both during development and

IEEPROC, Vol. 129, Pt. A, No. 8, NOVEMBER 1982

MA

RC

ON

I SPA

CE A

ND

DEF

ENCE

SYS

TEM

S U

MIT

ED A

oo

lied

Ele

ctro

nic

s L

abo

rato

ries

Po

rtsm

ou

th

STIN

G R

AY P

ROJE

CT L

evel

1 B

ase

Plan

1 PR

OD

UC

TIO

N W

AR

SHO

T TO

RPED

O

2 AC

CEPT

ANCE

TR

IALS

DEPO

T W

ORK

UP

b 1

11

1

TRA

ININ

G

A ,T

IT",

O

NE

Fig

. I

The

pro

gram

me

plan

before the release for production by specified times. Thecontract includes bonuses that are paid or withheld relatedto worse or better performance than that specified in time,performance and costs.

A contract on those lines took over a year to draw upand agree, and involved much negotiation both betweenmy staff and the operational side, on the one hand, and theCompany, on the other. The incentive contract was agreedand signed at the end of 1979, and, since then, the Companyworking closely with my special team in MOD has built upthe momentum of the programme and has so far met allperformance and time requirements, and at slightly less thanthe forecast cost.

A very important feature of the contract negotiated (anda significant innovation) was that it covered both completionof development and the delivery of the first productionbatch to the acceptance standard. This made the criticaltransition from development to production the clear re-sponsibility of the prime contractor. The importance ofthis feature is shown by the complexity of the programmeplan (Fig. 1) which demonstrates the judgment necessaryin granting releases (at line 5) for the production stages (atline 1) when development trials (at lines 7-10) are still inprogress.

With this background, I can now fill in some of the aspectsof management methods employed.

and the subcontractors, and, together with the contributionfrom the MOD (e.g. trials facilities, aircraft, ships, targets,flight-in-air material, etc), these were brought together in acomplete development cost plan (DCP) which identified theresources, times and associated costs in a manner that providedfor the use by all parties of a project management planreporting system for grouped programmes supported bynetwork logic, and a monthly work package printout whichrelates the actual timings and cost to the plan. Costs arerecorded at current rates, and are also de-escalated to therate used in the DCP; the figures in the DCP therefore remainunchanged, except as amended through the contract changeprocedures.

It is interesting to note that the cost estimates made onthis detailed basis were some i\ times previous estimates,which is in line with the evidence quoted by Downey injustifying the need for better project definition: we areprimarily concerned with underestimation, rather than over-spending, a subtle but important distinction. Now, somefive years later, we expect development to be fully com-pleted shortly, and that the in-service date will be met withinthe agreed target cost. All aspects of performance have beendemonstrated, and preparations for the contract acceptancetrials are well advanced.

4.5 Project definition and cost estimationThe task of project definition, which the contractor under-took while continuing and consolidating the ongoingprogramme, had to be completed to the standard, and inthe detail, judged necessary for an incentive contract. Hereis a typical programme for project definition stage I (Fig. 2),which must provide the essential documents to negotiate thecontract. The assessment of the industrial resources wasconducted through the structure of a development cost planbuilt on work packages, each of which is in effect a 'sub-contract' for a task that a line manager is to complete, withagreed resources and cost. Several thousand of these workpackages were identified for tasks within the contractor

5 What we have learnt

5.1 Levels of a projectFrom what has been achieved in Sting Ray, we could say thatwe have learnt that, however complex a problem is, it canbe broken down level by level and handled at each levelby asking:

(a) What are we trying to do? Define the task in measurableterms, including all customer contributions

(b) How do we know we have done it? Agree the criteriafor success and how achievement will be demonstrated

(c) How much will it cost? Break down the work intowork packages, individually accountable subcontracts

(d) Decide if the total price is acceptable, and if so:

Document 10 15 20 25 30 35 40 weeks

1. Department managment organ isatioi2. Firms managment organisation3. Programme breakdown4. Work breakdown5. Work package register6. Programme network7. DCP cost 8. effort estimates8. Performance specification9. Environmental specification

10. Trials specification11. Master trials schedule12. Acceptance specification13. Operational policy14. Reliability plan15. Quality assurance plan1 6. External interface list17. Engineering specification18. Internal interface list19. Subsystem specifications list20. Production release plan21. Production cost estimates22. Technical risk areas23. Incentive proposals24. Market survey25. Agreed characteristics26. Covering report

A = agree S = skeleton D r draft

Fig. 2 Typical stage programme

628 IEEPROC, Vol. 129, Pt. A, No. 8, NOVEMBER 1982

(i) secure the commitment of all necessary resources(ii) negotiate the tightest incentive contract compatible

with the circumstances.

5.2 Managing the project teamThis, however, is clearly not the whole story. I am strongly ofthe view that 'success' in major large-scale tasks like this,particularly those involving considerable development,depends on harnessing the initiative, drive and mutual co-operation of many managers and their teams; usually withwidely differing motivations and considerably differentviewpoints regarding the overall task and their role in it.These managers must act together in the selection, definitionand achievement of the tasks, and this must include a vastrange of interests, often conflicting. The task of seniormanagement is to lead and inspire this diverse body; and inselecting, defining and carrying out the total project theformal management techniques used must be chosen tosupport and aid all levels of management, to enable them torelate tasks both vertically and laterally in the managementstructure, to identify the really key stages, and to achievethem on time. The achievements in Sting Ray, notwith-standing the problems, are due to:

(i) arranging the concentration of authority and re-sponsibility

(ii) achieving a clearly defined programme(iii) the single-minded pressure to do this with clear

objectives(iv) and the ability to get and use the resources necessary.

A major feature has been the concentration of responsibilityand authority, both within the MOD and within the primecontractor, and picking eminently suitable senior projectmanagers to lead both teams and co-operate very closely,with good access in each direction to crucial informationand management data. Much of the knowledge necessaryto design complex weapons, which can be relied upon togive the full design performance immediately when usedafter long periods of storage or deployment ready to use,can only be built up by much closer contacts between theusers and designers; and I foresee a need to develop muchbetter methods of achieving this.

5.3 Future objectivesNotwithstanding the progress made, we still have our problemareas. I am convinced we do not pay sufficient attentioneven yet to designing these complex systems for low-costproduction and high reliability, and believe that the inclusionof predicted unit production costs as part of a fixed pricecontract, which includes initial production, will result inthis being given considerable weight, even at the early stagesof design. While I consider that the degree of clarificationof the objectives in Sting Ray when passed to the primecontractor was a considerable advance, we need to encompassthe whole task, and to look forward to the contractedobjective being something like the following: e.g. producea weapon whose unit production cost for a batch of 500must not exceed £X, and whose performance meets theagreed characteristics in document Y with a reliability where-by, for the first 100 weapons fired by the services, the successwill be in excess of 2%.

I have not mentioned many of the important aspects, suchas export potential and the increasing significance of thisin defining weapon requirements, but hope that my ratherbroad-brush remarks will give you an overview of some ofthe management tasks and methods employed in large-scaledefence projects.

IEEPROC, Vol. 129, Pt. A, No. 8, NOVEMBER 1982

Part 2: SUMMARY OF THE DISCUSSION AT THEFORUM ON LARGE-SCALE PROJECTMANAGEMENT

edited by Allan Asbury, M.Sc, C. Eng., F.I.E.E.*

1 Stages of projects

7.7 Prefeasibility stageIn this stage, the high-risk levels are examined before thedetailed work is defined. It entails research, although theoutput often appears to be similar to that from the feasibilitystage. In the Ministry of Defence (MOD) context, it is ofespecial importance when staff targets for design and develop-ments contain high risk and there is seen to be a need to goahead.7.2 Feasibility studyAs defined by the MOD, the feasibility study is used toexamine closely the outputs of several research areas to seeif ideas may be turned into equipment. It is not believedthat the study provides an end point where a degree of con-fidence is established; e.g. a threat to be countered, establishedtimes, cost constraints, etc. Its aim is to establish confidencein that the possibilities of success are known, especially ifthe requirements are stringent.

The feasibility study requires the best technologistsavailable, and some should continue with the project, to pro-vide continuity. The MOD agrees the requirement for a numberof men for a specified time. The study is funded at cost and,thus, is relatively easy to control. This is a most importantstage of a project, since everything stems from the study.The MOD often places the study for a project with morethan one organisation. The cost is relatively small, i.e. \ —1% of the total development cost. The establishment offeasibility can be recognised by the level of confidenceachieved in the project team.

At the end of feasibility study, the various proposals areexamined and further effort is concentrated on one or twoof them. In practice, it has been found that time estimates arefrequently low and often costs are under estimated by afactor of three. Costs are considered to be very approximateat this point and the contractor should not expect to beheld to them.

Outside the MOD, another authority uses the feasibilitystudy to define the project (performance, overall costs, timescales and risk elements) in sufficient detail to allow manage-ment to decide whether to proceed or not. Practicality isconsidered to be the essence. For high-risk projects, thefeasibility study is considered to be more valuable fordefining the risk than relying upon marketing strategy.

There is no single criterion for deciding that feasibilityhas been proven. In new technology, design may be wellinto the project definition stage before notional feasibilityhas been adequately demonstrated. An example was citedwhere problems were met three quarters of the way througha reference design and, in consequence, a new definitionhad to be negotiated.

The concepts are similar in the automobile industry,except that the disciplines and the intensity of managementproblems differ. The technical feasibility may be self evident,but the economic and commercial feasibility has to bedemonstrated. The pressures to date have been more com-mercial and less technological, but are changing. Micro-electronics are making an impact on systems. In addition,the microelectronics industry is not familiar with the auto-mobile industry. MIL Specs, are proving to be inadequate

•Chairman of the Forum Action Committee, and co-ordinator ofresearch at the North Staffordshire Polytechnic, Stoke-on-Trent ST42DE, England

629

for the hostile environment encountered by the automobilesystems.

1.3 Project definition stage (PD)The question was posed: At what stage will the risks beseen to be sufficiently manageable to enable the contractorto accept a target cost incentive contract for the developmentstage?

The aim of the PD is to provide a development specifi-cation, to arrive at a sound development cost plan and toidentify the remaining risk. It usually comprises two separatephases, PDl and PD2. 15% of the total project developmentcost is expected to be incurred in PD. During PD, the optionsidentified in the feasibility study are examined in more detail,and by the end of PDl it should be possible to select one ofthem.

At the end of PD the design will be at the stage when itis possible to turn it into a production form (e.g. design,performance, interfaces). The contractor understands whatis to be achieved, how he will do it, and will have sufficientconfidence in the cost estimates to enable him to accept atarget cost incentive contract for the development stage. Therewill still be risk present, but it is expected that no majorchanges will be made after the incentive contract for develop-ment has been placed. The project definition stage is the keyto achieving sound contract negotiations for development.

1.4 Development stageThe aim of the development stage is to validate the assump-tions made in feasibility and project definition, and to producedrawings for production. No major alterations to require-ments are envisaged.

2 High-risk projects: Management aspects

In military projects there is a problem in achieving a com-mercial balance to allow a good target incentive contractto be placed. This is particularly difficult in the early stages,when the service operational requirements (OR) staff areexerting constant pressure for change; it is not possible inthese conditions to clear the risk sufficiently to allow incentivearrangements to be identified.

A solution might be for the OR staff to reduce their re-quirements, and, thus, the risk, to a sensible level. By usingthe three stages: feasibility study, project definition andfull development, with adequate emphasis at each stage,the risk should be reduced to manageable proportions. Reservefunding should be allowed for in estimates of developmentcost for work on identified risk areas. If risk is still un-avoidable, a cost-plus type of contract may be necessary.Such contracts are sometimes arranged, but they are notconsidered to be in the best interests of the customer or thesupplier. The most appropriate contractual arrangementmust remain a matter of judgment.

In another example of a high risk project, fixed costs wereestablished two years ahead of the start of feasibility studies,and any changes required resubmission for ministerial ap-proval. Project control was maintained in house, and fixedprice contracts were issued for those areas of work whichcould be adequately defined. The remaining work was doneintramurally. One problem in the latter instance was tomotivate the staff adequately to keep costs down.

Project control networks were smaller than those normallyexpected for a project of this size (approximately threethousand activities). In addition, however, each contractorwas obliged to develop and run his own networks and inter-faces. The subcontractor's work package was identifiedwith the cost-control package to level 2. Contractors' progresswas regularly monitored by in-house staff.

630

3 Contractual arrangements

The progress of a project should be continuous from start tofinish. Breaks and delays can have far reaching effects.Parliament's annual volting of funds may cause problemsfor the MOD, in this respect. Cancellation charges in bothtarget incentive and fixed price contracts reduce the temp-tation to 'dip feed' or cancel the project. Both target incentiveand fixed price contracts create strong internal disciplinesand help to control requests for changes.

When a contractor accepts a contract, not all the speci-fications will be fully proven and large risks may remainin some areas. Estimation will concentrate on eliminatingthe risk, hence covering possible cost changes. Where a UKcontractor has overseas competition for a military contract,the Government will usually fund design, but only with onecontractor. Competitive design at the feasibility stage is pre-ferred to the use of a sole contractor for military projects,but may not always be possible. Negotiating a fixed-pricecontract with one contractor is more difficult than settingup a competitive arrangement.

4 Bonus schemes

Bonus payments may be paid on performance achievementand/or time to key milestones. Cost incentives are a pre-requisite and are present in the sharing arrangements of theincentive contract. In the Sea Wolf contract, the bonus systemplayed a more. important part than had been originallyenvisaged. Discussions for setting the bonus were closelylinked to the programmed manufacturing and release points.Values were set at those which the contractor couldreasonably expect to achieve. Tight incentives were set anda bonus was paid for improvement on these targets. Partof the bonus paid to the contractor was then awarded tostaff for exceptional effort in holding the key milestones.

It was stated that the US award system was similar. Anagreed formalised procedure was included in contracts, andbonus was paid down to all levels of staff. Extra money ismade available for the contractor to provide the best re-sources and people at the beginning of government projects inBritain.

For the contractor, the bonus scheme has the extra ad-vantage that it represents immediate cash in the bank. Withthe target cost incentive contract, profits are taken at theend.

5 Commercial aspects

Some industries, such as nuclear power and Pharmaceuticals,are open to scrutiny by a sensitive public. Design must benot only technically excellent and satisfy the often changingrequirements of the operators, but must also satisfy regulatorybodies, inspectors and public groups, before a licence tooperate can be obtained. There is a strong need for regulatorybodies to recognise the commercial environment of theindustry.

Some UK service industries fail to recognise the impli-cations of world-wide competition on their customers, whoare obliged to pay the suppliers of the services for excellencerather than for sufficiency.

6 Specifications and documentation

The preparation of specifications is a prime function ofproject management. They define what is required, focusthought on the work to be done and bring together the ideasof different departments. Drafting must begin at the start ofthe project with the intention of providing a working specifi-cation before design begins, and not after the project is author-ised. The specifications must cover all aspects: technical,operating, maintenance, financial, commercial etc.

IEEPROC, Vol. 129, Pt. A, No. 8, NOVEMBER 1982

Specification check lists have proved invaluable as anaide-memoire. In the case of certain projects in the Far East,the work of several major contractors feeding the projectrequires co-ordination. The problems of co-ordination oftenexceed those of producing and delivering hardware to thesite. Standard interface charts, showing where various in-formation is required, may be scheduled into the projecttime frame.

It was suggested that no document should be producedby someone without the experience of using it, otherwisethe shortcomings could not be appreciated.

7 Handling and presentation of information

Control and reporting requirements are different and, there-fore, will call for different techniques. Senior managementis too busy to become involved in detail.

A discussion ensued on the relative merits of projectmanagement plans (PMP) and PERT systems. PMP providesbetter understanding of the project than PERT for staff.If associated with a weekly presentation, it allows possiblemilestone slips to be examined and to be reinstated by themanager. It opens up discussion about problems, resources,failures, etc. It is said to be the best management documentseen to date. It has, however, reported limitations in that itdoes not show the underlying logic leading to interaction.The project manager can say what he wants to do, but thePMP presentation will not show whether it is possible.

PERT provides so much detail that it becomes a draw-back. Senior management cannot readily get at the in-formation it needs. Updating is left to junior PERT engineerswho develop their own objectives and generate a PERTsystem only they can understand. In consequence, informationdeteriorates and any reported slip automatically moves theproject to the right. With the advent of visual display units,however, managers may now call up their own data directly.

There is no single universal system which will meet allrequirements. Bar charts based on PERT seem to be mostappropriate at board level. Managers can work directly fromreal-time charts, produced by the computer if necessary.At lower levels, subnets have been found to be of most use.They are understood and reliance is placed upon them.

The key seems to be to have good and appropriate graphics.The computer is valuable, but its presentations should relateto the needs of the user. Contractors have used PMP, linkedbar charts and PERT, all with success.

(a) a single repository for all project data to give a con-sistent view to all parties

(b) a security system which allowed each member of theteam to have access only to a subset of the data to matchhis role

(c) the rapid assimilation of new data(d) the ability to trace the effect of requirements through

to the implementation(e) an update of project costs as design was refined.

These objectives can be seen to be very similar to those ofthe main command, control and information system. Itwas decided that the project-control system was to be basedon two standard software products:

(i) IDMS — a database management system(ii) DDS — a recording system which allows data hierarchies

to be defined and assembled.

The system which has been developed consists of a numberof hierarchical data structures representing the various aspectsof the subject. These structures are detailed requirement,design, implementation and work breakdown structure(WBS). WBS is the key to all aspects of the project which arethe responsibility of the main contractor and also coversthose items which are the responsibility of subcontractorsand the customer. Each work package defines the 'endproduct', its cost, the next level of breakdown and how it isdependent on other WBS. These interrelationships provide atool for ensuring that the work matches the design and thatthe design reflects the total user requirement.

When all the data is recorded it is possible to derive logicalbuild sequences, schedules, budgets and resources required.These make it possible to monitor project progress, costsand critical aspects of the project that may need managementchanges, to generate documentation and user manuals andto help the development of acceptance schedules.

Finally, the customer has, in addition to the softwaresystem, a self-consistent computerised database which canbe used for assisting software maintenance, developing systemenhancements and automatically updating user manuals.These latter facilities help with postacceptance activitieswhich often account for 70% of the total project life cost.

Within the ICL project-management-systems organisationpersonal microcomputer work stations are being introducedto help in maintaining up-to-date records of each project.These will be transportable between projects and networkedto a central site.

8 Project management using computers

The subject was introduced by Dr. C. Monahan of ICL, whochose to illustrate the possible applications by dealing withthe software required by the naval command, control andinformation system. The software was required to covera wide and complex set of user requirements, exacting per-formance and availability criteria, demanding implementationtime scales, fixed budgets, maximum use of 'off-the-shelfproducts, extensible facilities and replication, and, finally,assistance in the maintenance phase.

In this situation ICL decided that the software activityconstituted a project in its own right which merited the bestattainable computerised project control. It is this systemwhich is now discussed. There are many readily identifiableareas in which software to help is already available for projectcontrol; e.g. PERT, financial packages, specifications ofrequirements, design tools, etc. The project-control systemwas to be a single tool to cover all areas and to give a compre-hensive communication medium throughout the total project.

Detailed objectives included:

IEEPROC, Vol. 129, Pt. A, No. 8, NOVEMBER 1982

'9 Communicating with the software and the computer

The difficulty of communicating the needs of a project of thesoftware expert was a frequent cause of concern, as was theresponse of the expert to the requirement. The use of standardsoftware packages will not necessarily improve this situation,because the documentation may only be intelligible to thesoftware expert. If the people using such a package do notunderstand how it works they can easily draw the wrongconclusions from the data supplied.

The personal microcomputer provides one way of buildingup the manager's knowledge of the capabilities and the weak-nesses of computer systems. With the growth of interactiveuse, attention must be given to the ergonomics of operatingsystems and displays. Unless the ultimate customer is awareof the computer system's potential he will not be able toask for all the advantage he could have. Fortunately, theequipment required to develop an understanding is relativelymodest in cost and software packages are available at lowcost to provide a starting point. A further advantage of inter-active working in both familiarisation and final use is that

631

data to help decisions can be presented to the user in discretepackages, each sufficient for the immediate decision, andthen lead on to the next appropriate package.

In the steel industry it has been shown that a few daysinstruction and modest expenditure on equipment will enablea plant manager to develop his own maintenance system.However, problems may arise when he wishes to extendhis system and he comes to the expansion limit of hisequipment.

Experience with computer aided design (CAD) for draughts-men has been very encouraging. The existence of draughtingconventions and a knowledge of the drawing's purpose helpsthe draughtsman to make good use of the computer's facilities.

10 Managing software design

It is not really possible for a manager to delegate the speci-fication of the requirements for a software system and hemust be aware of any logical decisions which condition theoutput information. If the specification is left in the handsof a computing expert and he decides the implementationwith the supplier's expert, there is a danger that no-oneelse will really understand what is happening.

The user of a computer system is frequently confused bythe capacity of the computer to collect and present in-formation. In some circumstances much of this informationmay be irrelevant or at least of secondary importance. Ideally,the manager needs only enough information to make hisdecision or his selection from the options available. It isimportant to remember that people manage projects andpeople should make the decisions — not computers. Thereis a commonly held misconception that if the right formulacould be found, then the computer could make the decisions.This overlooks the fact that the computer program will rarelytake into account all the relevant factors, and a change inthese may well alter the significance of the computer output.

It cannot be overemphasised that computers require ac-curate and up-to-date information, and this applies withspecial force in a data base used for project control or design.Inaccurate information can lead to incorrect managementresponse or faulty design.

When programs are generated by individual managersit is most important that they are tested to make sure the logicis correct and consistent with other programs which maybe used for project control. This is particularly true if the pro-grams change common accounting procedures, such as over-head allocation. This disadvantage of the personal computerapproach is outweighed by the advantage of the greaterawareness of the computer's potential.

11 Estimating software design effort

When a project involves hardware and software, it is commonexperience that hardware-design times and costs can beestimated much more closely than those for software. Ifthe inaccurate software information is fed into the project-control system, the resulting monitoring information willbe worthless. The problem is made worse by the fact thatthe software is not generally understood. There is a needfor techniques to estimate the time taken for. software designand a corresponding means of measuring progress.

It was suggested that it was necessary to spend enoughtime on software system design to give detailed definition ofeach function. This would enable the objectives of eachwork package to be defined with its interface. Only at thisstage could the software estimate be made reliably. As theproject proceeds the estimates for the remainder can beimproved and the completion date be more certain.

It is possible that projects involving hardware and soft-

632

ware might be better planned and monitored if the softwareis regarded as driving the hardware. This places emphasis onthe need to design and specify the software before finalisingthe hardware requirement. It was generally agreed that hard-ware designers had much more experience on which to basetheir estimates and that they tended to work in larger units.Software designers tended to work in lines of code ignoringthe fact that the design effort varies over a wide range. Iflarger units of software uere used, the estimate could be betterrelated to the design conception.

There is a well established practice of testing hardwareat key points during its manufacture. This does not seemto be the case with software and there is a good case forincorporating test facilities in software, even if they areremoved when the testing is complete, it is interesting tonote that software validation may account for up to 25%of the cost and in some projects it can only take place whenthe hardware is complete.

12 What is project management?

In the course of the discussion, it became clear that theprojects concerned ranged form defence weapon develop-ment to the procurement and installation of major plant.In the first, the interfaces between the specialist teams hadto be defined progressively to secure the best overall result.In the latter, the interfaces were largely determined fromthe outset and the problems arose in the co-ordination ofindependent contractors supplying part of the equipment.

In each case, there was a need for an addition to theexisting hierarchical management for the duration of theproject. This project organisation required most of the con-ventional tools of management, together with enough under-standing of all the disciplines involved to make decisionsfor the project as a whole with due regard to time, cost andperformance objectives.

13 Organisation of project management

It was suggested that hierarchical management, with theusual techniques covered by business schools, was adequatefor predictable situations, but not suited to project manage-ment. Matrix management involving responsibility to bothproject and technical manager was not readily accepted in thiscountry. Some considered it to be a North American fashionwhich would soon disappear.

The difficulties of project management were discussed,and it was pointed out that it required the company manage-ment to give the project manager authority, even though thecompany management could still contribute. This authoritywas needed, however, and it was quite impractical to givethe project manager all the responsibility if he had to goto other managers to obtain executive decisions. There wassome reluctance to recognise that decision making, ratherthan information handling, is the prime function of projectmanagement.

Some companies had established matrix-type projectcontrol, and one had project groups within both engineeringand manufacturing functions. In one organisation, internalcontracts were placed within some projects and each primecontractor was required to nominate an approved seniormanager for the contract. There was some concern thatproject engineers often moved into other work when theirproject was complete. This might be because they fearedthat they were losing touch with their special expertise, orbecause they simply wished to return to the relative cer-tainty of normal design engineering.

In some projects there was a need to drive subcontractorswho were not project oriented and, after a timely and

IEEPROC, Vol. 129, Pt. A, No. 8, NOVEMBER 1982

financially successful project, the project manager wouldnaturally move on to another project.

14 Abilities of a project manager

In his key position, the project manager must have a good senseof structure, both in designing the interdependence at theplanning stage and monitoring progress through the life ofthe project. This implies enough understanding of thedisciplines involved to perceive essential and optional char-acteristics. This understanding is also necessary to enablehim to discuss progress and performance with the expertsworking on the project. He must be able to ask the rightquestions.

He will usually come into project engineering after suc-cessful experience in one of the component disciplines. Thisnot only helps to cover that discipline in the project butalso lends authority to his judgment.

In the complex interactions of a project, the managermust be able to take the risk of being wrong, but, if thathappens, he must be flexible in recognising that he was wrong.Unlike engineering design, in which judgment can be verifiedby calculation or model test, project structure design canonly be seen to be wrong when it is tried.

The project manager must be able to express his objectivesand plans in unambigous written English, and when changesare required these must be recorded in a similar fashion.This must be combined with an ability to make, with thehelp of those responsible, realistic estimates of the effortrequired for a task and later the current state of progress.He will encourage trust in this manner, so that other projectstaff will help him and not just work in spite of him. Thisis a type of leadership which will bring success as a team.

15 Training project managers

As noted already the typical project manager will have aqualification and experience in one of the disciplines,usually engineering, involved in the projects he is to manage.There was general agreement that his training should includeshort courses, to enable him to appreciate the standard manage-ment techniques; such as cost accounting, budgetary control,critical-path methods and financial control, which mightbe relevant to his project work. These could be in-houseor arranged with one of the management schools and wouldgive him confidence in the other specialists' practice.

There was a clear analogy between the methods usedin the services to develop leadership, and the practical ex-perience required by the project manager. He must be placedin an exposed situation in which other people depend on him

and he has to make the decisions. Early tasks might be suitablylimited in scope to build up his confidence, and the con-fidence of his colleagues in him. The services also arrangefor key personnel to have experience in different roles, andthis example could be followed as far as practicable. Thismay be easier to arrange, where the organisation has acentralised project organisation rather than the ad hocarrangements usually made for a few projects.

The members of the forum thought that it should bepossible to go further than this, by providing potential projectmanagers with experience in making project judgmentsby means of case study or simulation. This would also providean opportunity to develop good methods of analysing mistakes.These 'game' projects naturally involve documentation, andthe experience gained can help to eliminate this commonweak link. The participants would be brought to understandthat decisions are not really instantaneous and involve groundwork over a substantial period before the final nominal timeof decisions.

16 Learning from experience

A number of contributors considered that project engineersin this country rarely made any endeavour to review thehistory of a project to extract the useful experience for otherproject engineers. Frequently, mistakes were not fully docu-mented and only those involved had a complete picture ofthe circumstances.

The Medical Defence Union analyses each case of litigationagainst a member, to see what lessons can be learned. Theinformation is then distributed to all members. This provides apossible model for action by engineers within their owncompany, or even by the IEE for British electrical companies.

This diagnostic activity would be far more effective if eachproject were organised to archive the appropriate informationas the project proceeds.

17 Proposals for further action

The preceding Section suggests that a study could be madeof the problem of recording project experience and arecommended code of practice developed.

In Section 11, the problem of estimating and monitoringsoftware development effort was mentioned. In this case,the IEE might be able to initiate research and study leadingto standard software tasks.

In Section 15, the possibility of case studies, or simulationsto enable engineers to develop and exercise project judg-ment, is proposed.

IEEPROC, Vol. 129, Pt. A, No. 8, NOVEMBER 1982 633