learning to learn, from past to future
Post on 11-Apr-2015
Embed Size (px)
International Journal of Project Management 20 (2002) 213219 www.elsevier.com/locate/ijproman
Learning to learn, from past to futureKenneth G. Cooper, James M. Lyneis*, Benjamin J. BryantBusiness Dynamics Practice, PA Consulting Group, 123 Buckingham Palace Road, London SW1W 9SR, UK
Abstract As we look from the past to the future of the eld of project management, one of the great challenges is the largely untapped opportunity for transforming our projects performance. We have yet to discern how to systematically extract and disseminate management lessons as we move from project to project, and as we manage and execute portfolios of projects. As managers, executives, and researchers in project management, we have yet to learn how to learn. In this paper, the authors discuss some of the reasons behind the failure to systematically learn, and present an approach and modeling framework that facilitates cross-project learning. The approach is then illustrated with a case study of two multi-$100 million development projects. # 2002 Elsevier Science Ltd and IPMA. All rights reserved.Keywords: Learning; Strategic management; Rework cycle; Project dynamics
1. Introduction As we look from the past to the future of the eld of project management, one of our great challenges is the largely untapped opportunity for transforming our projects performance. We have yet to discern how to extract and disseminate management lessons as we move from project to project, and as we manage and execute portfolios of projects. As managers, executives, and researchers in project management, we have yet to learn how to learn. One who does not learn from the past. . . Whether the motivation is the increasingly competitive arena of Web-speed product development, or the mandate of prospective customers to demonstrate qualications based on past performance, or the natural drive of the best performers to improve, we are challenged to learn from our project successes and failures. We do so rather well at the technical and process levels. . . we build upon the latest chip technology to design the smaller faster one. . . we learn how to move that steel, or purchase order, more rapidly. But how does one sort among the extraordinary variety of factors that aect project performance in order to learn what about the management helped a good project? We must learn how to learn what it is about prior good management that made it good, that had a positive impact on the
performance, and then we must learn how to codify and disseminate and improve upon those management lessons. Learning how to learn future management lessons from past performance will enable us to improve systematically and continuously the management of projects. A number of conditions have contributed to and perpetuated the failure to systematically learn on projects. First is the misguided prevalent belief that every project is dierent, that there is little commonality between projects, or that the dierences are so great that separating the dierences from the similarities would be difcult if not impossible. Second, the diculty in determining the true causes of project performance hinders our learning. Even if we took the time to ask successful managers what they have learned, do we really believe that they can identify what has worked, and what has not, what works under what project conditions but not others, and how much dierence one practice vs. another makes? As Wheelwright and Clark [1, p. 2845] note: . . . the performance that matters is often a result of complex interactions within the overall development system. Moreover, the connection between cause and eect may be separated signicantly in time and place. In some instances, for example, the outcomes of interest are only evident at the conclusion of the project. Thus, while symptoms and potential causes may be observed along the development path, systematic investigation requires observation of the outcomes, followed by any analysis that looks back to nd the underlying causes.
* Corresponding author. Tel.: +44-20-7730-9000; fax: +44-207333-5050. E-mail address: firstname.lastname@example.org (J.M. Lyneis).
0263-7863/02/$22.00 # 2002 Elsevier Science Ltd and IPMA. All rights reserved. PII: S0263-7863(01)00071-0
K.G. Cooper et al. / International Journal of Project Management 20 (2002) 213219
Third, projects are transient phenomena, and few companies have organizations, money, systems or practices that span them, especially for the very purpose of gleaning and improving upon transferable lessons of project management. Natural incentives pressure us to getting on with the next project, and especially not dwell on the failures of the past. And fourth, while there are individuals who learnsuccessful project managers that have three or four great projects before they move to dierent responsibilities or retiretheir limited span and career path make systematic assessment and learning of transferable lessons that get incorporated in subsequent projects extremely dicult. In order to provide learning-based improvement in project management, all of these conditions need to be addressed. Organizations need: 1. an understanding that the investment in learning can pay o, and that there needs to be two outputs from every project: the product itself, and the post-project assessment of what was learned; 2. the right kind of data from past projects to support that learning; and 3. model(s) of the process that allow: comparison of unique projects, and the sifting of the unique from the common; a search for patterns and commonalities between the projects; and an understanding of the causes of project performance dierences, including the ability to do analyses and what-ifs. In the remainder of this paper, the authors describe one companys experience in achieving management science-based learning and real project management improvement. In the next Section, the means of displaying and understanding the commonality among projectsthe learning frameworkis described.1 Then, an example of using this framework for culling lessons from past projects is demonstratedtransforming a project disaster into a sterling success on real multi-$100M development projects (Section 2). Finally, the simulationbased analysis and training system that provides ongoing project management improvement is explained.
2. Understanding project commonality: the rework cycle and feedback eects We draw upon more than 20 years of experience in analyzing development projects with the aid of computerThe framework discussed in this paper is designed to understand project dynamics at a strategic/tactical level . Additional frameworks and models will be required for learning other aspects of project management (see, for example, ).1
based simulation models. Such models have been used to accurately re-create, diagnose, forecast, and improve performance on dozens of projects and programs in aerospace, defense electronics, nancial systems, construction, shipbuilding, telecommunications, and software development [2,3,6]. At the core of these models are three important structures underlying the dynamics of a project (in contrast to the static perspective of the more standard critical path): (1) the rework cycle; (2) feedback eects on productivity and work quality; and (3) knockon eects from upstream phases to downstream phases. These structures, described in detail elsewhere, are briey summarized later [4,5]. What is most lacking in conventional project planning and monitoring techniques is the acknowledgement or measurement of rework. Typically, conventional tools view tasks as either to be done, in-process, or done. In contrast, the rework cycle model shown in Fig. 1 below represents a near-universal description of work ow on project which incorporates rework and undiscovered rework: people working at a varying productivity accomplish work; this work becomes either work really done or undiscovered rework, depending on a varying quality (quality is the fraction of work done completely and correctly); undiscovered rework is work that contains as-yet-undetected errors, and is therefore perceived as being done; errors are detected, often months later, by downstream eorts or testing, where it becomes known rework; known rework demands the application of people in competition with original work; errors may be made while executing rework, and hence work can cycle through undiscovered rework several times as the project progresses. On a typical project, productivity and quality change over time in response to conditions on the project and management actions. The factors that aect productivity and quality are a part of the feedback loop structure that surrounds the rework cycle. Some of these feedbacks are negative or controlling feedbacks used by management to control resources on a project. In Fig. 2, for example, overtime is added and/or sta are brought on to a project (hiring) based on work believed to be remaining (expected hours at completion less hours expended to date) and scheduled time remaining to nish the work.2 Alternatively, on the left of the diagram scheduled completion can be increased to allow completion of the project with fewer resources. Other eects drive productivity and quality, as indicated in Fig. 2: work quality to date, availability of prerequisites, out-of-sequence work, schedule pressure,2 In Fig. 2., arrows represent causeeect relationships, as in hiring causes sta to increase. Not indicated here, but a vital part of the actual computer model itself, these causeeect relationships can involve delays (e.g. delays in nding and training new people), and non-linearities (e.g. regardless of the amount of pressure).
K.G. Cooper et al. / International Journal of Project Management 20 (2002) 213219
morale, skill and experience, supervision, and overtime.3 Each