A proposed project termination audit model

Download A proposed project termination audit model

Post on 24-Feb-2017




2 download

Embed Size (px)


<ul><li><p>IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. EM-30, NO. 3 , AUGUST 1983 123 </p><p>A Proposed Project Termination Audit Model DANIEL D . R O M A N </p><p>AbstractProject postmortem analysis, if conducted at all, is generally cursory. Often organizational pressures preclude an independent and comprehensive examination of completed projects. A project audit or outcome evaluation can be extremely constructive and a valuable tool for both the technical and managerial organization. Not only can it help focus on objectives and the accomplishment of those object ives , but it can also provide guidance to the conceptual, formative, and operational phases of future projects. </p><p>INTRODUCTION </p><p>Project Life Cycle/Phases </p><p> LIFE CYCLE of most projects can be partitioned into four characteristic phases: a conceptual phase, a formative </p><p>phase, a operational phase, and a terminat ion phase. Much thought , research, and writing has been directed to the first three phases; relatively little has been done in examining the fourth phase, project termination, including project or "postm o r t e m " analysis. </p><p>Postmortem Analysis </p><p>Project postmortem analysis, if conducted at all, is generally cursory. There may be organizational pressure t o wrap the project up and move on to new areas. Such pressure plus a vague notion that a project has been successful where there has been no significant customer/client complaints, no major organizational disruptions, and reasonable profitability mitigate against incentive for constructive outcome evaluation. </p><p>An intelligent and comprehensive examination of completed projects can be instrumental in improving the conceptual, formative, and operational project phases for existing and future projects. Was the project terminated because its objectives were accomplished or was it terminated for convenience, worse yet , for failure? </p><p>Was the project compatible with organizational objectives? For instance, does the organization have an operational strategy? Did the project complement such strategy? Was it consistent with short- intermediate- and long-range goals? </p><p>A project audit or outcome evaluation can be an extremely constructive and valuable tool for bo th the technical and managerial organization. It can help focus on objectives, establish commonality between management and technicians, and lead to reconciliation of relevant factors involved with evaluating the project. </p><p>Manuscript received August 16, 1982; revised April 18, 1983. This paper was presented at the IEEE National Engineering Management Conference, Washington, DC, June 1982. </p><p>The author is with the School of Government and Business Administration, The George Washington University, Washington, DC 2O052. </p><p>AREAS FOR EVALUATION </p><p>The Five Areas </p><p>To effectively conduct an outcome evaluation, it is suggested tha t a comprehensive analysis be conducted in five areas: Technical Objectives, Cost and Budget, Human Resources, Project Termination, and the Technical and Managerial Project Implications. The elements in each of the five evaluation areas are subject to variation and degree of intensity of importance depending on the nature of the project . What is important is to identify the relevant and strategic project components in order t o provide perspective for project evaluation and future project management. Too often one overwhelming factor in one of the five evaluation areas can lead to a positive or negative perception of project success or failure. In all probability, most projects of any magni tude have had both good and bad experiences. Evaluation, in proper perspective, can provide guidance to perpetuate the good aspects, and hopefully, avoid or minimize the bad experiences in future projects. </p><p>Technical Objectives </p><p>Pos tmor tem evaluation of how well the project's technical objectives were accomplished can be divided into three distinct phases: the technical conceptual phase, the technical operat ional experience, and the ultimate technical product achieved. </p><p>In the conceptual phase, the project's technical objectives can be over- or underestimated. There can be a failure t o appreciate the magnitude of the technical problems encountered. At times, underestimating the degree of technical difficulty is done purposely in order to solicit project approval. Postmortem evaluation of the project's conceptual phase should look at such factors as: the project requirements including primary and secondary technical objectives; the proposed technical approach; and the supporting technical services required. Additional concerns include: performance specifications, the reasonableness of quality standards, the identification of facilities and equipment needs, and the achievement of schedule commitments. </p><p>Once the project is operational, some of the objectives set in the conceptual phase may change. Final project evaluation geared t o the conceptual objectives may be unrealistic from the technical product originally envisioned. Changes from original technological objectives to the final technical product can occur for several reasons. The state of the art may shift after the project inception. New and better technological approaches may be dictated in order t o avoid obsolescence </p><p>0018-9391/83/0800-0123$01.00 1983 IEEE </p></li><li><p>124 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. EM-30, NO. 3 , AUGUST 1983 </p><p>and/or to turn out a better end product t h a n was originally planned. </p><p>Some other factors which could modify the original technical objectives are: the tendency to overengineer the prod-, uct (this is especially applicable to military and other government projects); the inclination of technical people to seek perfection (this is related to the tendency to overengineer); the discovery late in the project's life that there were significant flaws in the original technical approach; pressure from management for quick and cheap results-this can be related to competitive, cost, and time factors; and it is possible that in the initial project startup enthusiasm the scope of technical problems were underestimated and, as a result, overoptimism on the solution of the technical phases of the project colored the original commitment . </p><p>The third phase involving the ultimate technical product achieved would entail evaluation of the following: meeting contractual technical objectives; extra or unforseen technical accomplishments which were not anticipated in the conceptual phase; technical objectives not achieved; the success or failure in meeting technical milestone schedules with an explanation thereof; and customer relations and satisfaction. </p><p>Cost and Budget </p><p>Evaluation of cost and budget achievements in relation to project objectives can, to some extent , be analyzed quanti-filatively. However, cost and budget evaluation should not be oversimplified inasmuch as several factors can affect original cost and budget estimates. Some cost and budget elements can be reasonably controlled, some can be anticipated, and some, such as major changes in the thrust of the project once underway, may be difficult t o predict. </p><p>Assuming there has been no drastic change in the technical aspects of the project it would be meaningful to compare actual expenditures of resources against planned expenditures. Resource expenditures reviewed could include comparison of staff requirement projections against actual persons employment , overhead allocations, facilities and equipment use, supporting services required, and external resources contracted for. </p><p>Provisions can be made in the postmortem evaluation for some types of cost and budget expenditures which can be anticipated, if not directly controlled, such as contingencies for inflation, unforeseen technical difficulties, uncontrollable customer dictated program stretchouts, and added costs resulting from the unavailability of material, equipment, or facilities when needed. </p><p>Some cost and budget factors that could be difficult to forecast are significant changes in the technical scope of the project resulting from internal technical miscalculations, customer requested changes, and/or a shift in the state of the art which would affect the final technical product if not accomodated. Comparative cost and budget evaluation based on original estimates can be inconclusive if the final project product is quite different from the project product originally planned. </p><p>Despite the range of difficulties indicated in evaluating cost and budget performance on a completed project, such evalua</p><p>tion is critical. The other four evaluation areas may score positively; but if costs and budgets are exceeded without some strong reconciliation or mitigating factors, the ability of the organization to survive and continue operations could be jeopardized. Further justification for review in this area would be to look for pat terns. Are there some project expenditures which are repeatedly miscalculated? Identifying such areas could be very meaningful in providing better project managerial control . It could help identify project phases or functional activities where there are tendencies t o consistently pad, areas of perennial overoptimism, technical imcompetence, or out and out estimating inepititudes. </p><p>Another consideration for cost and budget evaluation would be to review how budgets are derived and costs are experienced. Project budget changes, overhead allocation methods , and actual cost expenditures can be instrumental factors in the ultimate profitability or cost-effectiveness of a project. By carefully comparing actual against planned expenditures it might be possible to segregate areas where cost reduction would be possible wi thout impairing the project objectives or the morale of the people assigned to the project. This could lead t o added profitability and organizational flexibility. </p><p>Human Resources </p><p>In the final analysis, it is people who make or break project objectives. In almost all professions, hard and fast quantifiable standards of excellence for evaluative purposes are virtually impossible to synthesize. Despite subjectivity within the professions, peers generally know who is a good doctor , scientist, engineer, lawyer, or professor. Conceeding subjectivity in evaluating human factors in project management does not diminish the need and the importance of such evaluation. </p><p>Several avenues pertaining to human factors can be explored. What were the internal project working relationships? Did the project people interface well with other functional support areas? Were there too few or too many people assigned to the project? What type of people were assigned? What qualitative and quantitative people support was required external to the immediate project? Was there learning and professional growth? Were the project people professionally flexible, transferable, promotable? What was the ult imate disposition of the people assigned to the project? Were there any significant accomplishments as a result of the project? Was there a participative/consultative environment? What about communication, motivation, delegation? Did the people assigned to the project use their t ime effectively? Can some productivity index on the project be established? If so, to what extent were the project people productive? </p><p>Project Termination </p><p>Projects can be concluded because the project objectives were met ; the project can be terminated for convenience; or, the project may be terminated for default or failure. </p><p>In some projects, achieving technical and/or contractual objectives signals the end of the project. Termination may simply involve the submittal of a final report. On other projects, much remains to be done after the technical work has </p></li><li><p>ROMAN: PROJECT TERMINATION AUDIT MODEL 125 </p><p>been completed in order to legally conclude the project. Changes to the contract may continue well past t he ostensible completion because attention must be paid to one or more of the following: work in process, the disposition of special project equipment and purchased raw materials, procurement commitment t o long lead time items, miscellaneous reports, outstanding bills and claims, unconcluded contractual commitments , returning the project (area) back to its original condit ion, disposal of finished inventory, disposition of scrap, interorganizational transfers, royalty or patent licensing costs, final settlement negotiations, terminal project audit , and storage costs. </p><p>In a multiproject organization even a successfully terminated project can require considerable t ime and effort and involve many problems. Termination procedures indicated in the preceeding paragraph requires specialized people. Cleaning up project residuals is often tedious and unglamorous. Project terminat ion frequently is not given sufficient at tent ion in organizations where the paramount interest is in professionally directed technical effort. The orderly phasing out and phasing in of resources should not be neglected and termination procedures definitely should be reviewed and evaluated. </p><p>There are also many reasons why projects may not come to successful fruition. It is possible that a project is aborted for convenience before it has achieved its franchised objectives. Termination for convenience can result because organizational resources are constrained and other projects are perceived as having higher priority for available resources. It is also possible that the project may have a high organizational priority but is s topped because of insufficient resources. Other reasons why projects may be terminated for convenience are: new technology may make the present project not feasible; the initial project cost expectations have been exceeded; the potential market has changed and sales prospects in line with costs do not appear encouraging; there are legal implications; competitive forces are such as to discourage project cont inuat ion; other investment opportunities promise better re turns for the allocpted resources; the potential contribution t o organizational objectives does not warrant the project investment; there is questionable probability of technical success; and the internal or external political environment may shift with a subsequent diminishing of interest and support for the project. </p><p>The worst situation for project termination is where the project activity is stopped because of default. Default most often is related to unsatisfactory technical performance. Termination for default can also result because of: cost overruns, delivery delinquencies, quality discrepancies, legal violat ions, or unsatisfactory material or other substitutions. </p><p>In the project termination evaluation phase, termination for convenience may indicate poor planning and termination by default would be presumptive of poor performance. Both situations should, of course, be avoided. In project termination evaluation, whether termination is due t o successful complet ion, convenience, or default, management should determine: Wha...</p></li></ul>


View more >