- Email: [email protected]
Actual Resource Management
Copy ri ght © IFAC Ex perie llce ",ith the IVla nageme llt o f Software Projeus. Heidelberg. FRG. 1986
ACTUAL RESOURCE MANAGEMENT P. A. Bennett The Cl'lIlrl' .1111' SoJiwarl' Ellgilleerillg Limiled, Bel/will Drille. Flixbo/(}ugh. Scu lllhOJpe. Soulh HU/JIberside DN 15 8R T , L'K
Abstract. The failure of software projects to maintain budgets and schedules has a significance to manufacturing industry. Many project managers fail to realise the status of the project and as a conse quence loose control . Th ough complex software development systems can be adopted there is a simpler method of maintaining control ; resource management .
Keyw orks .
Resource manage ment;
Computer software;
INTRODUCTION
Critical path analysis ;
PERT
into detailed and manageable components , typically, in the case of systems and subsystems. Whatever the level of component determined by the Project Manager it must be possible to assign expected star t and end dates to them .
An essent i al element of a successful software project is the ability o f the Project Manager to plan and control an abstract entity; the software effort itself . A s i milar difficulty exists in many areas of project management from shipbuilding to constructing a power plant . Software project management has one distinct aspect in that the entity being controlled is both the product and the means of producing it . In addition the software effort often presents an image of genious without the substance .
To ensure that a project, however well defined , procee ds at a satisfactory rate to an agreed schedule the re is a requirement f or careful scheduling of the project resources over t ime with frequent monitoring points during the life of the project . Failure to plan , revise and schedule a project during its life has led to many projects failing. Frequent monitoring will not, h owever, prevent project failure but should signal early difficulties so that the Project Manager can take what possible corrective action is ava ilable to him to avert a disastrous fai lure .
The discipline of project management is defined in BS4335 (1985) as "the mobilization and management of resources for the purpose of comple ting a project", in the case of a software project this resource is principal ly a human one . Whilst project control is similarly defined as "an extension of monitoring in which some action (not necessarily corrective) is applied to a project and the implementation is later measured to chec k its effectiveness and possibly supplemented by further action. The plan may also be revised".
IMPORTANCE OF SOFTWARE TO INDUSTRY In a recent article in the Financial Times (1985) reference was mad e to a report which cla imed that "c ost and time overruns of 100 per cent o r more are
not uncommon and in the UK over 55 per cent of projects were found to have seriously exceeded their budgets ". Comments such as these abound in todays press and unfortunately seem to fairly reflect the inabi lity of software project managers to maintain any measure of control over their projects. But why do comments such as these warrant space in such esteemed papers as the Financial Times?
This paper describes a system of project monitoring which has been successfully applied to a number o f large complex process control developments in a manufacturing environment. The paper discusses some of the issues involved and describes one method of control . First , however, it is necessary to establish a few principles f or successful project control. Each project should have clearl y defined objectives contained in one document . The discipl i ne of having to document the project objectives focusses the attention of the Project r4anager on the principal issues involved in the project and forms the basis for approval of the project by the company senior management and the customer . Suc h a document , often called a Project Proposal , should not only contain details of what is to be included in the project but also state what is not to be included. In this way the Project Proposal sets out the extent of supply for the project .
Over recent years there has been a dramatic reduction in the cost of raw computing power coupled with an increasing awareness by Management that the unit cost of their product or service can be significantly reduced by the prudent introduc tion and use of computers . It is not uncommon today to discover that a major capital development project for, say , the construction of an industrial chemical p l ant is dependant upon satisfactory operation of a set of computers for the eff i cient operation of the plant . As we all know, computers require software and , equally we know that software p rojects very often go over budget and overrun .
At an early stage in the project some indi vidual must b e nominated to ta ke on the role o f Project Manager with direct ove rall responsibility for the success of the project. It will be one of the Project Manager ' s tasks to break down the project
Though software plays a s ignificant role in the satisfactory outcome of a project it may only present 1- 2% of the total project costs . One cons equence of a delay in the software for such a 131
132
P. A. Benne tt
capita l project as this may mean a delay in the operation of the entire plant . With even a relatively small industrial plan t cost ing, say, £50M at an interest rate on capital of , say, 15% per year the cost of even one days delay is £20,550 on interest alone. At current contract rates for programmers this 1S equivalent to 1 28 man- days of effort. It would need to be an enourmous software project to consume this amount o f e ff ort ! Software projects can get into difficulties for a variety o f reasons ; - ambiguous specifications - the level of technology employed - the plant, hardware and software integration but experience shows t ha t the most common r eason is t hat the Project Manager has not maintained control of resources. The s cheduling and controlling of complex software projects requires the skills and techniques of exper ienced project management. Whether the project is involved in the bui lding of a power station , planning routine maintenance , scheduling human effort or controlling material usage they all r e quir e close mo nito ring of four dynamic components ; the progress plan, resource utilisation, cumulative spend and the project plan . A mis take in the assessment can be the cause of an ulitimately dramatic overspen d on budgets, and po tentially worse, overruns on the target finish da tes . Software projec ts, whether they originate fr o m within the DP department or concern the development of a process control system using i n-house engineering staff or that of the suppliers, all too frequently fail to recognise the inter- relationships of progress , r esource utilisation, schedules and their singular and combined effect upon projec t milestones and deadlines. Is it surprising then that the application of computers to industry has become ta inted with a reputation of inability to contain costs and meet deadlines? This scenario is expected to change as more project management software packages be come available for a Pro ject Manager's desk-top PC and the emergen ce of new exciting forms of proj ect management software. Network analysis techniques such as Critical Path Analysis and PERT have been around for about 25 years. They have been used on constructi on projec ts and large defence projects where the network of activities was drawn by hand at great length . The preparati on of a complex activity network could well take a team of work study engineers days or more typic ally weeks to complete. To ease the burden o f preparation o f CPA/PERT network software packages have been developed that run on an organisation's mainframe computer. This d evelopment gave planner s the benefit of reducing the time to prepare an initial ne twork but also carried with it the dual disadvantages of work study engineers needing to develop a skill in preparing data in an acceptable format from the DP department who in turn placed a low priority on the CPA/PERT package. Though this approach helped the work study engineer to provide the Project Manager with regular monthly reports, by the time reports became available they were no longer representative of the positi on o n a dynamic project . In the last few years Project Managers have started to have ready access to their own desk- top computers and there has been a corresponding intr oduct ion of CPA/PERT packages for this type of low cost local computing facility. Now the Project Manager is able to plan reasonable complex projects himself , as well as updating himself with the latest position . Desk - top PC-based Network Analysis packages have b een used for planning and controlling construction sites, market research
exercises and office relocation where the r e is a strong relationship between a large number of activities. To manage a software proje ct within time and budget often seems to many observers to be an impractical notion . Yet is need not be so if the Project Manager has the right methods available to him. Before discussing one such method it is ne cessary to consider the 'special' aspec ts of software influencing the choic e of a project control model .
' SPECIAL' ASPECTS OF SOFTWARE Many software engineers still maintain that software development and production is n ot a s cience but an art . Whilst there is an element of c rea tivity in a software engine er's work there is also an even larger element o f science . It is this second premi se which suggests to the author that software projects should be controlled with something more construct i ve than intuition . The planning of a software project can be likened to the acti viti es of a construction site where each item of software to be produced is analogous to a building activity. This is a reasonable model at the general level but does suffer from two significant shortcomings ; programmers are in short supply and each programmer will typically be working on more than one item of so f tware at any given time . Since programming effort is current ly a scarce resource then it should be s cheduled with a degree of sophistication to ensure o ptimum productivity. Brooks (1975) discusses at length his experience o f proje ct management on th e development of the IBM OS/360 operating system . Brooks observes what all e xperienced software Project Managers know: that it is not possible to get o ne man-week of productive effort for each week worked from a progra mmer. The reasons for this are many but incl ude lost productive effort due to sickness, holid ays, fatigue and even coffee breaks. In this situation how does a Project Manager keep a track of his conformance to plan and most importantly his fore cast f or completi on as agreed at the ou tset of the proje ct? When a Project Manager is initially planning a proje ct, estimates are proposed , discussed and finally agreed for specific activities within the project . These activities could be program modules, sub -sy stems , systems or whatever dependant upon t he perspective of the Project Manager . Standards for estimates can only be created for tasks or similar tasks undertaken ofte n enough for a measure of confidence to exist . Estimates based on previ ous ex peri ence are unreliable unless an accurate record is kept of other similar projects and th e Project Manager has the ability and expe rience to interpre t these records. Intuitive estimates are the least reliable since they depend entirely upon the memory , the experience, ability and aspirations of the estimator . To help the Project Manage r develop estimates of the amount of effort required, a number of resource models have been developed by researchers from a variety of backgrounds. Typicclly these models are based upon some initial estimation of the " size" of the software in thousands of lines of source code or upon multiple parameters such as staffing levels, type of pr oduct being developed, project procedures and the like . Whilst it may be
Actual Resource Management
133
possible to use one such model for a particular product or company organisation it cannot be
universally assumed that the model will apply in all cases. Therefore, caution must be expressed in selecting anyone model. A review of numerous models is contained in Basili (1981) and Boehm (1984). It is the experience of the author that many of these models only serve to strengthen the confidence of t he Project Manager in the empirical estimates made by the Project Manager and are of little use in controlling the project once it has started. Resource management , therefore, needs to be dynamic, involve project team members in estimating and accurately reflect the progress to date with some level of forecasting.
100
Testing
rJl ;:l
-:;; ....,
50
Development
rJl
...., ()
'"
....., o ~
O ~______~~~~~~~________________
Project Time
Fig. 1.
Project Progress
Many years of project management on idustrial capital development projects (Bennett, 1977, 1982) with the r eoccurring problem of scheduling too few resources over too short elapse time for too large a project lead the author to a radical appraisal of the tools required to successfully control projects . This scenario all too often reflects the sentiments felt when an experienced Project Manager faces a project lasting 2 - 4 years and on whose success depends the successful plant operation . In this case the satisfactory completion of the overall project depends upon the software being ready on schedule. Experience has shown that however the initial estimates were derived (and they may be contractually binding) they will change as the project progresses. A successful outcome at all times relies upon the paramount objective of maintaining the project target end date and to do this without overspending . This concept became known locally as Actual Resource Management .
ACTUAL RESOURCE MANAGEMENT During a project several levels of estimates will be put forward f or each activity and provision for reassessment must be included in the project plan. At the start of a project an estimate of effort and the timescales for each activity and the whole project should be agreed by those parties to whom t he Project Manager is responsible , typically a customer . This is called liThe Initial Plan ll and is recorded on a Project Progress Sheet . The Initial Plan should be widely distributed through the project. In this way all parties to the project including the project team of software engineers are aware of the anticipated rate of spend of effort , expected timescales and rate of progress expected to be achieved . Importantly it sets down for the Project Manager an agreed project comp leti on date which should be regarded as changeable only under extreme circumstances. The estimates may be derived from previous experience , intuition or some standard basis but however derived they should reflect a reasonable position from which to start a project. Before discussing the method developed by the author to control projects it is necessary to have in mind a few principles derived from an ideal project . Figure 1 shows a graph of the ideal rate of progress for a project with three distinct phases; design, development and test . Figure 2 shows a graph of resource usage for the same project. Figure 3 shows the initial project plan recorded on a Project Progress Sheet for a fictitious software project with estimates which will have been approved by senior management and, presumably, the customer. It is assumed that the project is to supply a software system controlling some industrial plant as part of the overall capital development .
'" ()
H
;:l
o rJl
'"'"
1=..._ _ _ _ _ _ _ _ _ _ _ ._
._~ _
Project Time
Fig. 2.
Resource Usage
The estimates will have been derived following inspection of records kept on previous projects, detailed examinations of the Invitation to Tender by the Project Manager and his management and finally ~y the Software Manager. A resource estimation model may have been used to add confidence to the estimates but it would be foolish to allow such a model to have been used as the only estimator. Since each activity has a manpower estimate and start/end dates will have been placed against it then the estimate for each activity also contains a considered view of the
level of productivity expected. Experience has shown that at this early stage of a project it is not sensible to assume that it is possible to achieve more than 0.75 man- weeks per week from any team member .
From the initial plan it is now possible for the Project Manager to construct a number of graphs indicating various management aspects including;
activity schedule, project status and resource usage for the tota l development time of the project . At this point milestones can be declared for the total project. For clarification the project status is determined by
Project status
effort expended effort expended + estimated x 100% effort to complete
As the project proceeds regular accounting periods, typically month end, call for a review of the project against the agreed plan at which a "progress report" is submitted to the Project Manager. The progress report (Fig. 4) will record the amount of effort expended on each activity, the estimated effort to complete and revised start/end dates. These estimates are submitted to the Project Manager by the individuals assigned to that activity. The Project Manager can then ca l culate the resource spent this period along with variance and status for each activity.
1~
P. A. Bennett
Similarly he can calculate spend, variance and status for the total project. In this way the individual, as well as the Project Manager, b ecomes more experienced in estimat i ng the work required for each task . This is an important part of the method as it attaches respons ibi l i ty for the estimates to each level of the project thus strengthening the individual ' s commitment to the project and his work within it . At the accounting period the Project Manager can now update his management graphs with the latest information on effort and schedules (Figs. 5 , 6 , 7). By project ing forward the remaining effort and schedule he is then able to determine whether the project is likely to overrun or overspend . Similarly , he can determine whether the proj ect will have sufficient resources allocated to it i n order to complete the project as current ly planned. At this stage the Project Manager can reschedule (Fig . 8) the activities in order to maintain a satisfactory completion date, resource usage and budget (Figs. 9 , 10 , 11). This method of estimate , record , review and reschedule has been found to maintain a sense of project unity as well as offering frequent project appraisal .
CONCLUSION Software projects increasingly o ft en form an integral part of much larger projects, typically on the development of new chemical plants or steelworks . All too frequently though these major economic developments are put into jeopardy because of the inability o f the Soft ware Project Manager to contain his spending of resources within budget and maintain a satisfactory rate of progress against a plan. There are many reasons for this and principal amongst these is the lack of information on the project status and equal lack of control . There is no doubt that research programmes such as ESPRIT will come up with elaborate schemes involving complex systems to control software projects . The question here is "do we really need complex management systems and are they necessary"? This paper has been based upon the personal experiences o f the author who has successfully controlled many projects with the simple method explai n e d. Software projects need not overrun or overspend by default . They shou ld be controlled like any other engineering project by close monitoring of resources , frequent review of progress and a read iness to undertake revision of the plan in order to maintain the main objective ; to complete on schedule .
ACKNOWLEDGEMENTS The author wishes to acknowledge the encouragement given to him by his colleagues at The Centre for Software Engineering in preparing this short paper and their determination in converting the pr oject management concepts outlined in t h e paper into a commerc ial software product ; ARMS - Advanced Resource Management Sys tem .
REFERENCES BS4335 . Glossary o f Terms Used in Project Network Technique s , British Standards Instituti o n. London . Basili , V. R. (1981) . Resource Model s. In Software Metrics, A.J . Perlis, F . G. Sayward and M. Shaw (Eds.) , MIT Press , Chapter 6,
pp. 1 11-1 30. Bennett, P . A. and Bailey, K. (1977). A Mu1ti Computer Hi erarchy on a New Rod Mill. In Digital Computer Applications to Process Control, H.R. van Hauta Lemke and H. B. Verbruggen (Eds.) , North-Holland, pp. 209- 216 Bennett, P.A. and Dyer, K. D. F. (1982). The Appl i cation of Process Oriented Software to a Blast Furnace . In Trends in On-L ine Computer Control Systems , lEE, London , pp . 63-65. Boehm, B. W. (1984) . Software Engineering Economi cs . IEEE Transactions on Software Engineering, January 1984, pp . 4 - 21. Brooks, F . P . (1975) . The Mythical Man-Month . Addison- Wesley. Financial Times (1986). Success lies in clearer objectives , February 27, pp. 26 .
Ac tual Resource Management
Ini tial Plan Activity ffort 1 2 3 4 5 6 7 8 9 10 11
Project Management Specification & Design Device Drivers
I/O Scanner Motion Control Alarm Processing Set Point Control Communications
Trend Analysis Camera Scan Reports & Printing Data Summary Product Quality Control Algorithms Graph Package Interlocking Ligh t Density File Scheduler Unit Testing Integration Test Delivery & Site Testing Simulation
12 .13 114 ·15 16 17 18 19 20 21 22 23 Commissioning 24 Acceptance/Approval
Project
Start Date
To Date Finish Date
90 . 0 65.0 22 . 0 10.0 15 . 0 39 . 0 12 . 0 15.0 17.0 20 . 0 26 . 0 8.0 1] .0 18 . 0 15 . 0 12 . 0 9 .0 18 . 0 50 .0 30 . 0 8.0 25 . 0 20 . 0 4.0
16.04.85 16.04 . 85 14 . 08.85 28.08 . 85 09 . 09.85 30.09.85 10 . 12 . 85 01.02 . 86 01 . 01 . 86 15. 0 1.86 01.03 . 86 01 . 04 . 86 29 . 04 . 86 08.04 . 86 26.05 . 86 19 . 06 . 86 08.07.86 01.08 . 86 09 . 09 . 86 16.12 . 86 03.12.87 17.02.87 01.03.87 10.07.87
18 . 07.87 13.02.86 19 .11. 85 19 .11.85 20 .1 2.85 15.03.86 15 . 02 .86 31 . 05.86 31 . 05 . 86 1 7 .05 . 86 13.09.86 1 3 . 09 . 86 10 . 08 . 86 24.08 . 86 06.10 . 86 06 .09.86 30 .08.86 01.12 . 86 20 .1 2.86 30.01.87 17.02 . 87 09 . 05 . 87 10.07.87 18 . 07.87
559 . 0
16. 04 .85
18.07.87
Revised Effort
S~~~; .
135
Estimated To Complete Revised !Effor t Finish
Effort This Period
Var.
in Effort
Project Status %
n"t:<,
Fig. 3 Initial Plan
Ini tial Plan Activity
1 2 3 4 5 6 7 8 9 10 11
Project Management Specification Design Device Drivers I/O Scanner
Motion Control Alarm Processing Se t Point Control Communications
Trend Analysis Camera Scan Reports & Printing Data Summary Product Quality Control Algorithms Graph Package Interlocking Light Density File Scheduler Unit Testing Integration Test Delivery & Si te Testing Simulation
12 13 14 15 16 17 18 19 20 21 22 23 Commissioning 24 Acceptance/Approval
Project
To Date
ffort
Start Date
Finish Date
90 . 0 65 . 0 22 . 0 )0 . 0 15 . 0 39 . 0 12 . 0 15 . 0 )7 . 0 20 . 0 26 . 0 8 .0 11 . 0 18 . 0 15 . 0 12 . 0 9. 0 18.0 50 . 0 30 . 0 8 .0 25 . 0 20 . 0 4 .0
16 . 04 . 85 16.04.85 14. 08 . 85 28.08.85 09 . 09 . 85 30 . 09 . 85 10.12.85 01.02 . 86 01 . 01 . 86 15 . 01.86 01.03.86 01.04 . 86 29 . 04 .86 08 . 04 . 86 26.05 . 86 19.06.86 08 . 07 . 86 01.08 . 86 09 . 09 . 86 16.)2 . 86 03.02.87 17 . 02 .87 0 1. 03 . 87 )0.07.87
18.07 . 87 13 . 02.86 19.11.85 19.11.85 20 . 12.85 15.03 . 86 15.02.86 31.05 . 86 31.05.86 17 . 05 . 86 13 . 09.86 13 . 09.86 )0 . 08.86 24 . 08.86 06 . 10.86 06 . 09 . 86 30 . 08 . 86 01.12.86 20.12 . 86 30 . 01.87 17 . 02 . 87 09 . 05 . 87 10.07.87 18.07.87
559 . 0
16 . 04 . 85
18 . 07 . 87
Estimated o Complete
Var.
Projec Status
Effort This Period
in Effort
18.07.87 13.02.86 19. 11.85 19.11.85 20.12 . 85 28 . 02 .86 15.02 . 86 31.05 . 86 31.05 .8 6 17.05 . 86 13 . 09 . 86 13.09.86 )0.08 . 86 24 . 08 . 86 06 . 10 . 86 06 .09 . 86 30 . 08 .86 01 . 12 . 86 20.12 .86 30 . 01.87 l7 . 02.87 09.05 . 87 10.07 . 87 18 . 07 .87
3.5 3 .0 6 .0 5 .0 3 .0 10. 0 0.0 0 .0 0 .0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 .0 0 .0 0 .0 0 .0 0 .0 0 .0 0.0 0 .0
0 .0 5 .1 - 0 .9 2 .0 0.0 1.0 0.0 0 .0 0 .0 0.0 0.0 0 .0 0 .0 0 .0 0 .0 0 .0 0.0 0.0 0.0 0 .0 0.0 0 .0 0 .0 0 .0
24 . 4 55.7 71 . 1 75.0 40.0 25 . 0 0 .0 0.0 0 .0 0.0 0.0 0.0 0.0 0.0 0 .0 0.0 0.0 0 .0 0.0 0.0 0 .0 0.0 0.0 0 .0
101. 1 16.04.85 465.1 18 . 07.87
30.5
7.2
17.9
Rev i sed Effort Start Date 22 . 0 39 . 1 15 . 0 9.0 6.0 10 . 0 0 .0 0.0 0.0 0.0 0 .0 0 .0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 .0 0.0 0.0
16.04.8: 16.04 . 8: 14.08 . 8: 28 . 08 . 8: 09 . 09.8: 30.09 . 8: 10.1 2 . 8: 01. 02 .8E 01 . 01 . 8E 15 . 01.8E 01.03.8E 01.04 . 86 29 .04.86 08.04 . 86 26.05.86 19 . 06 . 86 08.07.86 01 . 08.86 09 . 09.86 16 . 12 . 86 03 . 02.87 17 . 02 . 87 01.03.87 10.07 . 87
Fig. 4 Progress Report
ReVIsed ffort Finish Date 68.0 31.0 6.1 3.0 9.0 30 . 0 12.0 15.0 17.0 20 . 0 26 . 0 8.0 11. 0 18 . 0 15 . 0 12.0 9 .0 18 . 0 50 .0 30.0 8 .0 25 .0 20 . 0 4.0
%
,
P. A. Bennett
136
(f)
W 1-4
I~ H
IU
TIME IN PROJECT WEEKS Fi g . 5
80
:
/,
W I-
,
W
r~ " • . •
,,
< .
'
·· ·1-· .. • .. • .. • ..•. .• . -• ..• . ,.
H _ , "0 "
.
"
· •. • •• •
•• • , - . , • • •• • •• • • , • • •• •• • •• •
.J il.
r
o
u
W (!!
IZ
IJJ
(J
Cl:
IJJ
il.
40
60
Fi g. 6
e0
100
•• • •• • •• • • •
Actual Resource Management
137
(f)
y.
w W
:1 Z
a:
r
Z H
w
u Cl:
J
o w
(f)
Cl:
o0
20
40
80
60
100
TIME IN PROJECT WEEKS Fig . 7
Capital Plant 1
IH K f~o 29
I
EHDDATES:- 31107/1987 31187/1987 18/07/1987
30 VI/ZZI/O , If'}
I'llll!ZLJ
o o I'ZZl2I 'allllllllJ
rlZllll WIIn fZZZll
, 'lllIllIlJ ~
VII/oo/om
tJ/JII71jjjJjlJ
rIllllll1l1J
Si
12WOOZl//1Z7711
100
r/OmoWZODa 'alllIIllJ
FllI1lI1!llI!J eWIIJOm70J
e. 20
40
TINE IN PROJECT
~IEEKS
Fig . 8
60
80
100
P. A. Bennett
138
. ............
o (1 //1I11//7/7IIA rI/O/l/// II I1 I1 ///!) ~
t'llLl PZ7I//Z/zO//I/I/II/IIIZJ PfIZflll/llIlIlllI?II//J
VIIOZM/m rl/l/lZZlfl/lld
VlW/W7II11l/IJ vl7////I/I/I///11
'lIlIll1lZl.J
vZZVM;vZZVVV7/zm VI////!JI/i(IOIl7lI///ZlJ
W/1W7I,7/7/WllVWI@ 1/7111111121/11////7////I7A f///II/if (II/IIIIIIJ
Pl7lZiZ/l/jzmm!l!m7/VV !j7/1l t116 1117I1I//JJIZIII77J
Yl//l//ovvzzvmJplV/J rzzz2Z2Zl (f!
W H
I-
5
H
:> U
cr
,
......
H
I-
0
.....
0
,", 2e .
40
60
W1E IN PROJECT WEEKS Fig. 9
0)
':i W W ::I Z
r
Z H
w
U
it: J
o fJ!
W
...
IV'
W1E Hl PROJECT
~.JEEKS Fig. 10
S0
Actual Resource Management
.,./
139
.'
./
. .'
. ~.
.,.'
.,
W
flJ.I .J 0.. E
o tJ
W (!)
Z W tJ
Cl:
W
Ii.
88 TH1E IN PROJECT
~HKS Fig. 11
108
ACTUAL RESOURCE MANAGEMENT P. A. Bennett The Cl'lIlrl' .1111' SoJiwarl' Ellgilleerillg Limiled, Bel/will Drille. Flixbo/(}ugh. Scu lllhOJpe. Soulh HU/JIberside DN 15 8R T , L'K
Abstract. The failure of software projects to maintain budgets and schedules has a significance to manufacturing industry. Many project managers fail to realise the status of the project and as a conse quence loose control . Th ough complex software development systems can be adopted there is a simpler method of maintaining control ; resource management .
Keyw orks .
Resource manage ment;
Computer software;
INTRODUCTION
Critical path analysis ;
PERT
into detailed and manageable components , typically, in the case of systems and subsystems. Whatever the level of component determined by the Project Manager it must be possible to assign expected star t and end dates to them .
An essent i al element of a successful software project is the ability o f the Project Manager to plan and control an abstract entity; the software effort itself . A s i milar difficulty exists in many areas of project management from shipbuilding to constructing a power plant . Software project management has one distinct aspect in that the entity being controlled is both the product and the means of producing it . In addition the software effort often presents an image of genious without the substance .
To ensure that a project, however well defined , procee ds at a satisfactory rate to an agreed schedule the re is a requirement f or careful scheduling of the project resources over t ime with frequent monitoring points during the life of the project . Failure to plan , revise and schedule a project during its life has led to many projects failing. Frequent monitoring will not, h owever, prevent project failure but should signal early difficulties so that the Project Manager can take what possible corrective action is ava ilable to him to avert a disastrous fai lure .
The discipline of project management is defined in BS4335 (1985) as "the mobilization and management of resources for the purpose of comple ting a project", in the case of a software project this resource is principal ly a human one . Whilst project control is similarly defined as "an extension of monitoring in which some action (not necessarily corrective) is applied to a project and the implementation is later measured to chec k its effectiveness and possibly supplemented by further action. The plan may also be revised".
IMPORTANCE OF SOFTWARE TO INDUSTRY In a recent article in the Financial Times (1985) reference was mad e to a report which cla imed that "c ost and time overruns of 100 per cent o r more are
not uncommon and in the UK over 55 per cent of projects were found to have seriously exceeded their budgets ". Comments such as these abound in todays press and unfortunately seem to fairly reflect the inabi lity of software project managers to maintain any measure of control over their projects. But why do comments such as these warrant space in such esteemed papers as the Financial Times?
This paper describes a system of project monitoring which has been successfully applied to a number o f large complex process control developments in a manufacturing environment. The paper discusses some of the issues involved and describes one method of control . First , however, it is necessary to establish a few principles f or successful project control. Each project should have clearl y defined objectives contained in one document . The discipl i ne of having to document the project objectives focusses the attention of the Project r4anager on the principal issues involved in the project and forms the basis for approval of the project by the company senior management and the customer . Suc h a document , often called a Project Proposal , should not only contain details of what is to be included in the project but also state what is not to be included. In this way the Project Proposal sets out the extent of supply for the project .
Over recent years there has been a dramatic reduction in the cost of raw computing power coupled with an increasing awareness by Management that the unit cost of their product or service can be significantly reduced by the prudent introduc tion and use of computers . It is not uncommon today to discover that a major capital development project for, say , the construction of an industrial chemical p l ant is dependant upon satisfactory operation of a set of computers for the eff i cient operation of the plant . As we all know, computers require software and , equally we know that software p rojects very often go over budget and overrun .
At an early stage in the project some indi vidual must b e nominated to ta ke on the role o f Project Manager with direct ove rall responsibility for the success of the project. It will be one of the Project Manager ' s tasks to break down the project
Though software plays a s ignificant role in the satisfactory outcome of a project it may only present 1- 2% of the total project costs . One cons equence of a delay in the software for such a 131
132
P. A. Benne tt
capita l project as this may mean a delay in the operation of the entire plant . With even a relatively small industrial plan t cost ing, say, £50M at an interest rate on capital of , say, 15% per year the cost of even one days delay is £20,550 on interest alone. At current contract rates for programmers this 1S equivalent to 1 28 man- days of effort. It would need to be an enourmous software project to consume this amount o f e ff ort ! Software projects can get into difficulties for a variety o f reasons ; - ambiguous specifications - the level of technology employed - the plant, hardware and software integration but experience shows t ha t the most common r eason is t hat the Project Manager has not maintained control of resources. The s cheduling and controlling of complex software projects requires the skills and techniques of exper ienced project management. Whether the project is involved in the bui lding of a power station , planning routine maintenance , scheduling human effort or controlling material usage they all r e quir e close mo nito ring of four dynamic components ; the progress plan, resource utilisation, cumulative spend and the project plan . A mis take in the assessment can be the cause of an ulitimately dramatic overspen d on budgets, and po tentially worse, overruns on the target finish da tes . Software projec ts, whether they originate fr o m within the DP department or concern the development of a process control system using i n-house engineering staff or that of the suppliers, all too frequently fail to recognise the inter- relationships of progress , r esource utilisation, schedules and their singular and combined effect upon projec t milestones and deadlines. Is it surprising then that the application of computers to industry has become ta inted with a reputation of inability to contain costs and meet deadlines? This scenario is expected to change as more project management software packages be come available for a Pro ject Manager's desk-top PC and the emergen ce of new exciting forms of proj ect management software. Network analysis techniques such as Critical Path Analysis and PERT have been around for about 25 years. They have been used on constructi on projec ts and large defence projects where the network of activities was drawn by hand at great length . The preparati on of a complex activity network could well take a team of work study engineers days or more typic ally weeks to complete. To ease the burden o f preparation o f CPA/PERT network software packages have been developed that run on an organisation's mainframe computer. This d evelopment gave planner s the benefit of reducing the time to prepare an initial ne twork but also carried with it the dual disadvantages of work study engineers needing to develop a skill in preparing data in an acceptable format from the DP department who in turn placed a low priority on the CPA/PERT package. Though this approach helped the work study engineer to provide the Project Manager with regular monthly reports, by the time reports became available they were no longer representative of the positi on o n a dynamic project . In the last few years Project Managers have started to have ready access to their own desk- top computers and there has been a corresponding intr oduct ion of CPA/PERT packages for this type of low cost local computing facility. Now the Project Manager is able to plan reasonable complex projects himself , as well as updating himself with the latest position . Desk - top PC-based Network Analysis packages have b een used for planning and controlling construction sites, market research
exercises and office relocation where the r e is a strong relationship between a large number of activities. To manage a software proje ct within time and budget often seems to many observers to be an impractical notion . Yet is need not be so if the Project Manager has the right methods available to him. Before discussing one such method it is ne cessary to consider the 'special' aspec ts of software influencing the choic e of a project control model .
' SPECIAL' ASPECTS OF SOFTWARE Many software engineers still maintain that software development and production is n ot a s cience but an art . Whilst there is an element of c rea tivity in a software engine er's work there is also an even larger element o f science . It is this second premi se which suggests to the author that software projects should be controlled with something more construct i ve than intuition . The planning of a software project can be likened to the acti viti es of a construction site where each item of software to be produced is analogous to a building activity. This is a reasonable model at the general level but does suffer from two significant shortcomings ; programmers are in short supply and each programmer will typically be working on more than one item of so f tware at any given time . Since programming effort is current ly a scarce resource then it should be s cheduled with a degree of sophistication to ensure o ptimum productivity. Brooks (1975) discusses at length his experience o f proje ct management on th e development of the IBM OS/360 operating system . Brooks observes what all e xperienced software Project Managers know: that it is not possible to get o ne man-week of productive effort for each week worked from a progra mmer. The reasons for this are many but incl ude lost productive effort due to sickness, holid ays, fatigue and even coffee breaks. In this situation how does a Project Manager keep a track of his conformance to plan and most importantly his fore cast f or completi on as agreed at the ou tset of the proje ct? When a Project Manager is initially planning a proje ct, estimates are proposed , discussed and finally agreed for specific activities within the project . These activities could be program modules, sub -sy stems , systems or whatever dependant upon t he perspective of the Project Manager . Standards for estimates can only be created for tasks or similar tasks undertaken ofte n enough for a measure of confidence to exist . Estimates based on previ ous ex peri ence are unreliable unless an accurate record is kept of other similar projects and th e Project Manager has the ability and expe rience to interpre t these records. Intuitive estimates are the least reliable since they depend entirely upon the memory , the experience, ability and aspirations of the estimator . To help the Project Manage r develop estimates of the amount of effort required, a number of resource models have been developed by researchers from a variety of backgrounds. Typicclly these models are based upon some initial estimation of the " size" of the software in thousands of lines of source code or upon multiple parameters such as staffing levels, type of pr oduct being developed, project procedures and the like . Whilst it may be
Actual Resource Management
133
possible to use one such model for a particular product or company organisation it cannot be
universally assumed that the model will apply in all cases. Therefore, caution must be expressed in selecting anyone model. A review of numerous models is contained in Basili (1981) and Boehm (1984). It is the experience of the author that many of these models only serve to strengthen the confidence of t he Project Manager in the empirical estimates made by the Project Manager and are of little use in controlling the project once it has started. Resource management , therefore, needs to be dynamic, involve project team members in estimating and accurately reflect the progress to date with some level of forecasting.
100
Testing
rJl ;:l
-:;; ....,
50
Development
rJl
...., ()
'"
....., o ~
O ~______~~~~~~~________________
Project Time
Fig. 1.
Project Progress
Many years of project management on idustrial capital development projects (Bennett, 1977, 1982) with the r eoccurring problem of scheduling too few resources over too short elapse time for too large a project lead the author to a radical appraisal of the tools required to successfully control projects . This scenario all too often reflects the sentiments felt when an experienced Project Manager faces a project lasting 2 - 4 years and on whose success depends the successful plant operation . In this case the satisfactory completion of the overall project depends upon the software being ready on schedule. Experience has shown that however the initial estimates were derived (and they may be contractually binding) they will change as the project progresses. A successful outcome at all times relies upon the paramount objective of maintaining the project target end date and to do this without overspending . This concept became known locally as Actual Resource Management .
ACTUAL RESOURCE MANAGEMENT During a project several levels of estimates will be put forward f or each activity and provision for reassessment must be included in the project plan. At the start of a project an estimate of effort and the timescales for each activity and the whole project should be agreed by those parties to whom t he Project Manager is responsible , typically a customer . This is called liThe Initial Plan ll and is recorded on a Project Progress Sheet . The Initial Plan should be widely distributed through the project. In this way all parties to the project including the project team of software engineers are aware of the anticipated rate of spend of effort , expected timescales and rate of progress expected to be achieved . Importantly it sets down for the Project Manager an agreed project comp leti on date which should be regarded as changeable only under extreme circumstances. The estimates may be derived from previous experience , intuition or some standard basis but however derived they should reflect a reasonable position from which to start a project. Before discussing the method developed by the author to control projects it is necessary to have in mind a few principles derived from an ideal project . Figure 1 shows a graph of the ideal rate of progress for a project with three distinct phases; design, development and test . Figure 2 shows a graph of resource usage for the same project. Figure 3 shows the initial project plan recorded on a Project Progress Sheet for a fictitious software project with estimates which will have been approved by senior management and, presumably, the customer. It is assumed that the project is to supply a software system controlling some industrial plant as part of the overall capital development .
'" ()
H
;:l
o rJl
'"'"
1=..._ _ _ _ _ _ _ _ _ _ _ ._
._~ _
Project Time
Fig. 2.
Resource Usage
The estimates will have been derived following inspection of records kept on previous projects, detailed examinations of the Invitation to Tender by the Project Manager and his management and finally ~y the Software Manager. A resource estimation model may have been used to add confidence to the estimates but it would be foolish to allow such a model to have been used as the only estimator. Since each activity has a manpower estimate and start/end dates will have been placed against it then the estimate for each activity also contains a considered view of the
level of productivity expected. Experience has shown that at this early stage of a project it is not sensible to assume that it is possible to achieve more than 0.75 man- weeks per week from any team member .
From the initial plan it is now possible for the Project Manager to construct a number of graphs indicating various management aspects including;
activity schedule, project status and resource usage for the tota l development time of the project . At this point milestones can be declared for the total project. For clarification the project status is determined by
Project status
effort expended effort expended + estimated x 100% effort to complete
As the project proceeds regular accounting periods, typically month end, call for a review of the project against the agreed plan at which a "progress report" is submitted to the Project Manager. The progress report (Fig. 4) will record the amount of effort expended on each activity, the estimated effort to complete and revised start/end dates. These estimates are submitted to the Project Manager by the individuals assigned to that activity. The Project Manager can then ca l culate the resource spent this period along with variance and status for each activity.
1~
P. A. Bennett
Similarly he can calculate spend, variance and status for the total project. In this way the individual, as well as the Project Manager, b ecomes more experienced in estimat i ng the work required for each task . This is an important part of the method as it attaches respons ibi l i ty for the estimates to each level of the project thus strengthening the individual ' s commitment to the project and his work within it . At the accounting period the Project Manager can now update his management graphs with the latest information on effort and schedules (Figs. 5 , 6 , 7). By project ing forward the remaining effort and schedule he is then able to determine whether the project is likely to overrun or overspend . Similarly , he can determine whether the proj ect will have sufficient resources allocated to it i n order to complete the project as current ly planned. At this stage the Project Manager can reschedule (Fig . 8) the activities in order to maintain a satisfactory completion date, resource usage and budget (Figs. 9 , 10 , 11). This method of estimate , record , review and reschedule has been found to maintain a sense of project unity as well as offering frequent project appraisal .
CONCLUSION Software projects increasingly o ft en form an integral part of much larger projects, typically on the development of new chemical plants or steelworks . All too frequently though these major economic developments are put into jeopardy because of the inability o f the Soft ware Project Manager to contain his spending of resources within budget and maintain a satisfactory rate of progress against a plan. There are many reasons for this and principal amongst these is the lack of information on the project status and equal lack of control . There is no doubt that research programmes such as ESPRIT will come up with elaborate schemes involving complex systems to control software projects . The question here is "do we really need complex management systems and are they necessary"? This paper has been based upon the personal experiences o f the author who has successfully controlled many projects with the simple method explai n e d. Software projects need not overrun or overspend by default . They shou ld be controlled like any other engineering project by close monitoring of resources , frequent review of progress and a read iness to undertake revision of the plan in order to maintain the main objective ; to complete on schedule .
ACKNOWLEDGEMENTS The author wishes to acknowledge the encouragement given to him by his colleagues at The Centre for Software Engineering in preparing this short paper and their determination in converting the pr oject management concepts outlined in t h e paper into a commerc ial software product ; ARMS - Advanced Resource Management Sys tem .
REFERENCES BS4335 . Glossary o f Terms Used in Project Network Technique s , British Standards Instituti o n. London . Basili , V. R. (1981) . Resource Model s. In Software Metrics, A.J . Perlis, F . G. Sayward and M. Shaw (Eds.) , MIT Press , Chapter 6,
pp. 1 11-1 30. Bennett, P . A. and Bailey, K. (1977). A Mu1ti Computer Hi erarchy on a New Rod Mill. In Digital Computer Applications to Process Control, H.R. van Hauta Lemke and H. B. Verbruggen (Eds.) , North-Holland, pp. 209- 216 Bennett, P.A. and Dyer, K. D. F. (1982). The Appl i cation of Process Oriented Software to a Blast Furnace . In Trends in On-L ine Computer Control Systems , lEE, London , pp . 63-65. Boehm, B. W. (1984) . Software Engineering Economi cs . IEEE Transactions on Software Engineering, January 1984, pp . 4 - 21. Brooks, F . P . (1975) . The Mythical Man-Month . Addison- Wesley. Financial Times (1986). Success lies in clearer objectives , February 27, pp. 26 .
Ac tual Resource Management
Ini tial Plan Activity ffort 1 2 3 4 5 6 7 8 9 10 11
Project Management Specification & Design Device Drivers
I/O Scanner Motion Control Alarm Processing Set Point Control Communications
Trend Analysis Camera Scan Reports & Printing Data Summary Product Quality Control Algorithms Graph Package Interlocking Ligh t Density File Scheduler Unit Testing Integration Test Delivery & Site Testing Simulation
12 .13 114 ·15 16 17 18 19 20 21 22 23 Commissioning 24 Acceptance/Approval
Project
Start Date
To Date Finish Date
90 . 0 65.0 22 . 0 10.0 15 . 0 39 . 0 12 . 0 15.0 17.0 20 . 0 26 . 0 8.0 1] .0 18 . 0 15 . 0 12 . 0 9 .0 18 . 0 50 .0 30 . 0 8.0 25 . 0 20 . 0 4.0
16.04.85 16.04 . 85 14 . 08.85 28.08 . 85 09 . 09.85 30.09.85 10 . 12 . 85 01.02 . 86 01 . 01 . 86 15. 0 1.86 01.03 . 86 01 . 04 . 86 29 . 04 . 86 08.04 . 86 26.05 . 86 19 . 06 . 86 08.07.86 01.08 . 86 09 . 09 . 86 16.12 . 86 03.12.87 17.02.87 01.03.87 10.07.87
18 . 07.87 13.02.86 19 .11. 85 19 .11.85 20 .1 2.85 15.03.86 15 . 02 .86 31 . 05.86 31 . 05 . 86 1 7 .05 . 86 13.09.86 1 3 . 09 . 86 10 . 08 . 86 24.08 . 86 06.10 . 86 06 .09.86 30 .08.86 01.12 . 86 20 .1 2.86 30.01.87 17.02 . 87 09 . 05 . 87 10.07.87 18 . 07.87
559 . 0
16. 04 .85
18.07.87
Revised Effort
S~~~; .
135
Estimated To Complete Revised !Effor t Finish
Effort This Period
Var.
in Effort
Project Status %
n"t:<,
Fig. 3 Initial Plan
Ini tial Plan Activity
1 2 3 4 5 6 7 8 9 10 11
Project Management Specification Design Device Drivers I/O Scanner
Motion Control Alarm Processing Se t Point Control Communications
Trend Analysis Camera Scan Reports & Printing Data Summary Product Quality Control Algorithms Graph Package Interlocking Light Density File Scheduler Unit Testing Integration Test Delivery & Si te Testing Simulation
12 13 14 15 16 17 18 19 20 21 22 23 Commissioning 24 Acceptance/Approval
Project
To Date
ffort
Start Date
Finish Date
90 . 0 65 . 0 22 . 0 )0 . 0 15 . 0 39 . 0 12 . 0 15 . 0 )7 . 0 20 . 0 26 . 0 8 .0 11 . 0 18 . 0 15 . 0 12 . 0 9. 0 18.0 50 . 0 30 . 0 8 .0 25 . 0 20 . 0 4 .0
16 . 04 . 85 16.04.85 14. 08 . 85 28.08.85 09 . 09 . 85 30 . 09 . 85 10.12.85 01.02 . 86 01 . 01 . 86 15 . 01.86 01.03.86 01.04 . 86 29 . 04 .86 08 . 04 . 86 26.05 . 86 19.06.86 08 . 07 . 86 01.08 . 86 09 . 09 . 86 16.)2 . 86 03.02.87 17 . 02 .87 0 1. 03 . 87 )0.07.87
18.07 . 87 13 . 02.86 19.11.85 19.11.85 20 . 12.85 15.03 . 86 15.02.86 31.05 . 86 31.05.86 17 . 05 . 86 13 . 09.86 13 . 09.86 )0 . 08.86 24 . 08.86 06 . 10.86 06 . 09 . 86 30 . 08 . 86 01.12.86 20.12 . 86 30 . 01.87 17 . 02 . 87 09 . 05 . 87 10.07.87 18.07.87
559 . 0
16 . 04 . 85
18 . 07 . 87
Estimated o Complete
Var.
Projec Status
Effort This Period
in Effort
18.07.87 13.02.86 19. 11.85 19.11.85 20.12 . 85 28 . 02 .86 15.02 . 86 31.05 . 86 31.05 .8 6 17.05 . 86 13 . 09 . 86 13.09.86 )0.08 . 86 24 . 08 . 86 06 . 10 . 86 06 .09 . 86 30 . 08 .86 01 . 12 . 86 20.12 .86 30 . 01.87 l7 . 02.87 09.05 . 87 10.07 . 87 18 . 07 .87
3.5 3 .0 6 .0 5 .0 3 .0 10. 0 0.0 0 .0 0 .0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 .0 0 .0 0 .0 0 .0 0 .0 0 .0 0.0 0 .0
0 .0 5 .1 - 0 .9 2 .0 0.0 1.0 0.0 0 .0 0 .0 0.0 0.0 0 .0 0 .0 0 .0 0 .0 0 .0 0.0 0.0 0.0 0 .0 0.0 0 .0 0 .0 0 .0
24 . 4 55.7 71 . 1 75.0 40.0 25 . 0 0 .0 0.0 0 .0 0.0 0.0 0.0 0.0 0.0 0 .0 0.0 0.0 0 .0 0.0 0.0 0 .0 0.0 0.0 0 .0
101. 1 16.04.85 465.1 18 . 07.87
30.5
7.2
17.9
Rev i sed Effort Start Date 22 . 0 39 . 1 15 . 0 9.0 6.0 10 . 0 0 .0 0.0 0.0 0.0 0 .0 0 .0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 .0 0.0 0.0
16.04.8: 16.04 . 8: 14.08 . 8: 28 . 08 . 8: 09 . 09.8: 30.09 . 8: 10.1 2 . 8: 01. 02 .8E 01 . 01 . 8E 15 . 01.8E 01.03.8E 01.04 . 86 29 .04.86 08.04 . 86 26.05.86 19 . 06 . 86 08.07.86 01 . 08.86 09 . 09.86 16 . 12 . 86 03 . 02.87 17 . 02 . 87 01.03.87 10.07 . 87
Fig. 4 Progress Report
ReVIsed ffort Finish Date 68.0 31.0 6.1 3.0 9.0 30 . 0 12.0 15.0 17.0 20 . 0 26 . 0 8.0 11. 0 18 . 0 15 . 0 12.0 9 .0 18 . 0 50 .0 30.0 8 .0 25 .0 20 . 0 4.0
%
,
P. A. Bennett
136
(f)
W 1-4
I~ H
IU
TIME IN PROJECT WEEKS Fi g . 5
80
:
/,
W I-
,
W
r~ " • . •
,,
< .
'
·· ·1-· .. • .. • .. • ..•. .• . -• ..• . ,.
H _ , "0 "
.
"
· •. • •• •
•• • , - . , • • •• • •• • • , • • •• •• • •• •
.J il.
r
o
u
W (!!
IZ
IJJ
(J
Cl:
IJJ
il.
40
60
Fi g. 6
e0
100
•• • •• • •• • • •
Actual Resource Management
137
(f)
y.
w W
:1 Z
a:
r
Z H
w
u Cl:
J
o w
(f)
Cl:
o0
20
40
80
60
100
TIME IN PROJECT WEEKS Fig . 7
Capital Plant 1
IH K f~o 29
I
EHDDATES:- 31107/1987 31187/1987 18/07/1987
30 VI/ZZI/O , If'}
I'llll!ZLJ
o o I'ZZl2I 'allllllllJ
rlZllll WIIn fZZZll
, 'lllIllIlJ ~
VII/oo/om
tJ/JII71jjjJjlJ
rIllllll1l1J
Si
12WOOZl//1Z7711
100
r/OmoWZODa 'alllIIllJ
FllI1lI1!llI!J eWIIJOm70J
e. 20
40
TINE IN PROJECT
~IEEKS
Fig . 8
60
80
100
P. A. Bennett
138
. ............
o (1 //1I11//7/7IIA rI/O/l/// II I1 I1 ///!) ~
t'llLl PZ7I//Z/zO//I/I/II/IIIZJ PfIZflll/llIlIlllI?II//J
VIIOZM/m rl/l/lZZlfl/lld
VlW/W7II11l/IJ vl7////I/I/I///11
'lIlIll1lZl.J
vZZVM;vZZVVV7/zm VI////!JI/i(IOIl7lI///ZlJ
W/1W7I,7/7/WllVWI@ 1/7111111121/11////7////I7A f///II/if (II/IIIIIIJ
Pl7lZiZ/l/jzmm!l!m7/VV !j7/1l t116 1117I1I//JJIZIII77J
Yl//l//ovvzzvmJplV/J rzzz2Z2Zl (f!
W H
I-
5
H
:> U
cr
,
......
H
I-
0
.....
0
,", 2e .
40
60
W1E IN PROJECT WEEKS Fig. 9
0)
':i W W ::I Z
r
Z H
w
U
it: J
o fJ!
W
...
IV'
W1E Hl PROJECT
~.JEEKS Fig. 10
S0
Actual Resource Management
.,./
139
.'
./
. .'
. ~.
.,.'
.,
W
flJ.I .J 0.. E
o tJ
W (!)
Z W tJ
Cl:
W
Ii.
88 TH1E IN PROJECT
~HKS Fig. 11
108