Project Management Casebook David I. Cleland, Karen M. Bursic, Richard Puerzer, and A. Yaroslav Vlasak Library of Congress Cataloging-in-PublicationData Project management casebook /edited by David I. Cleland ... [et al.]. P. cm. Includes bibliographical references. ISBN: 1-880410-45-1 (pbk.) 1. Industrial project management--Case studies. I. Cleland, David I. HD69.P75P728 1997 658.4'04--dc21 97-3116 CIP l Copyright O 1998 by the Project Management Institute. Al rights resewed. Printed in the United States of America. No part of this work may be reproduced or transmitted in any form or by any means, electronic, manual, photocopying, recording, or by any information storage and retrieval system, without prior written permission of the publisher. Book Team Editor-in-Chief: James S. Pennypacker Book Designer: Michelle Owen Copyeditor: Toni D. Knott Copyeditor: Amy Goretsb Copyeditor: Mark S.Parker Cover design by: James S. Pennypacker and Dewey Messer Production Coordinator: Mark S. Parker Acquisitions Editor: Bobby R. Hensley PMI books are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please write to the Business Manager, PMI Publishing Division, 40 Colonial Square, Sylva, NC 28779. Or contact your local bookstore. The paper used in this book complies with the Permanent Paper Standard issued by the National Information Standards Organization (239.48-1984). Quesnel Air Terminal: DesignIBuild Works in the Public Sector Tom W. Nash, Transport Canada, Airports Group Ian Barrie, Public Works Canada, Air Transportation PMI Canada Proceedings, 1994, pp. 105-9 A prospector approaching the city of Quesnel in 1864 and a Japanese businessman arriving by corporate jet in 1994 would experience the same first impressions. They would see a Cariboo roadhouse as they approached the city. But the 1994 version of the roadhouse would be the new terminal at the city's airport. The construction of a new air terminal building at Quesnel Airport on a classic Cariboo theme proved to be a breakthrough project for two departments of the Canadian federal government. Using the designhuild delivery method provided a means to address client concerns about building costs. Although not a large project, building the new 505-square mile air terminal has brought the project team national recognition for innovation in project management from Transport Canada. The project demonstrated that public agencies, if suitably challenged, can provide leadership, be responsive to customers, and flexible in program delivery. Finding opportunities for people to become agents of change is always a tough management challenge. When a change in business practice leads to success, it can energize an organization, and the impact can be far greater than initially conceived. Some say that if you want to change the result, you have to change the environment where processes dictate that result. What this project showed was that relatively small changes in the initial project environment can lead to much more substantial changes in attitudes and processes. The lessons learned may benefit public service project managers everywhere. Changes in the Aviation Industry Over the past decade the aviation industry has been going through dramatic change. Airlines have faced deregulation, mergers, escalating costs, and record operating losses. In Canada, although there is a policy to transfer airports from federal government operation to local control, most of the airports receiving scheduled airline services are operated by the federal government. Airlines long complained about plans for new air terminal buildings (ATBs),calling them over-designed, overbuilt, and overpriced. These concerns could be attributed to Transport Canada's design and construction standards, which had been developed over many years. Although many of the standards had been reduced to guidelines, organizationalinertia enforced their continued application in many instances. Motivating Initial Project Lacked Airline Support In Quesnel, as in other Canadian locations, the airline's rental rates were based on a cost recovery formula whch tied the per-square-meter rent directly to the cost of providing space, based on conventional design and estimating. It cost Transport Canada over $200 per square meter to provide air terminal space using traditional project delivery methods, and the airline serving Quesnel would not support the project at rental rates based on these costs. It can be difficult for the public sector to be responsive to customers; most public agencies do not get their funds directly from their customers. However, in the case of Transport Canada's marts Group, the federal government experiences the impact of direct customer involvement. Airline concerns about the costs of providing air terminal space spurred Transport Canada to look for ways to reduce project costs, including alternative means of delivering the project. Expectations Changed as Opportunities Emerged Initially, a small task force of four people from two federal departments investigated opportunities to reduce project costs by using preengineered or modular buildings. After discussions with potential suppliers of preengineered structures, the project teams and Transport Canada management looked more deeply into the array of opportunities available. If these initial investigations had not identified the extent of interest in the industry for providing design/build services, management might have proceeded immediately to a tender process targeted at the suppliers of modular buildings. Although the client had some experience with the design/build process in constructing specialized airport electrical projects such as the desigdsupply and installation of field electrical centers, they had not seriously pursued the idea of delivering a public air terminal building by design/build. Internal discussions on the advantages and risks of using a design/build approach were reinforced by a review of the literature on variations of design/develop/buildllease contracts and discussions with project managers who had design/build experience. Project Management Casebook The airlines, local community leaders, and Transport Canada had accepted the possibility that some quality aspects might have to be sacrificed, and that a potentially uninspired design solution might result if management chose to construct a preengineered building. The project team even explored ways and means of improving the appearance of modular buildings. But once bidders had a chance to submit their concepts on how they would address client requirements, these expectations changed. A Change in Process Dramatically Changed the Results The construction of federally owned and operated airport terminals has historically been predicated on the design/bid/build process: Transport Canada establishes requirements, in-house specialists or consultants prepare a design package, and contractors are invited by public tender to bid on constructing the facility. Under the design/build method, contractors bid based on a performance document; the contractor is responsible for producing the design as well as the completed building. We began by seeking bids through public advertising. The Request for Proposals-Stage 1 package outlined the project requirement criteria, provided details of the site soils and services, and provided bidders with details on the evaluation criteria we would use to select a contractor. Following the evaluation and ranking of the bids, the top three bidders, ranked by best net value, were invited to participate in stage 2. This second stage provided additional information on project requirements and included comments specific to each of the three bidders' stage 1 proposals to bring them into line with Transport Canada's expectations. The bidders were allowed to amend their proposals and were re-evaluated to select the successful contractor. The concepts each bidder produced at the initial stage did not change significantly through the final stage. Other process differences included the means we used to calculate the building estimate. We needed enough assurance on costs to seek project approval. On a traditionally delivered project, staff would complete a preliminary design of the building to produce a reasonably accurate budget estimate that would satisfy project review and approval requirements. Completing this degree of design would have been counterproductive in a designhuild project, so the project manager had to find other means of satisfying senior management and their reviewers that the budget estimate for the project would be firm, and the budget ceiling would not be exceeded. We accomplished this by calculating comparative cost analysis of preengineered buildings and previously delivered air terminal projects and by interviewing developers who had experience in the designhuild method. During the process, project personnel looked at what the customer was prepared to pay and developed building concepts and project budgets to meet those limits. As a result, project development costs and estimated construction costs were substantially lower than the costs of using the traditional method. Making the Case When we were able to demonstrate that rental rates would be 30 percent below rates for a traditionally delivered building, the airline signed on. The airline's agreement to these rental rates cleared the way for project approval. Headquarters staff recognized the need to adjust the project review and approval process to accommodate the different means of developing a project Motivating Quesnel ATB Project Process DesignIBuild vs. Traditional I I Development Estimate w AppyI I -.-luation & Award Fva I Bidders Develop Conceptual Designs Final Design & Construction Traditional: Design, Tender, Build: I Based on preliminam II Final Design -rr.---' & Funding J \\ Tender J L Construction 1 \\ 1 budget. They helped develop arguments to support changes in the budget approval criteria and procedures. Customizing the Design The contractor also realized a process benefit. When the developers are to use their own designer, contractors get the design when they need it and can start on the structural aspects of the building without waiting for the final finishing details. In this project, the developer proposed a classic Cariboo roadhouse design. In preparing for the bid, the developer visited Quesnel, talked to city officials, and found that the city had just recently adopted the classic Cariboo theme for the town. In addition, Quesnel city officials expressed the desire to have locally manufactured wood products incorporated into the building, and this request was incorporated in the request for proposals document; the developer responded. The request for proposals competitive process provided bidders the opportunity to present their ideas on how local products and labor could be used on the project. Project management generally agreed that the traditional method of project delivery would not have delivered a Cariboo roadhouse design. As a result of these process adjustments, the local community is happy with its degree of involvement in consultations; the airlines agreed to rental rates that proved firm, and Transport Canada was delighted with the quality of the building, given the relatively low budget. Project Management Casebook Project Personnel Roles Changed From the perspective of project management in the two federal departments, the Quesnel ATB project had significant impacts on the traditional roles of the project personnel. In the traditional delivery process, in-house or contracted design specialists would develop a proposed facility based on preliminary operational requirements, and the developing concept would be subjected to numerous in-depth reviews for both operational and technical suitability, usually with reference to the "standards" for design. In the designhuild delivery process, the project manager prepared a simple sketch reflecting the client's space requirements incorporated into a modular building layout. The project manager had to ensure that client requirements were met in terms of performance expectations, rather than the specific technical data of the traditionally used standards. Likewise, the evaluation team had to be sensitized to compare each bidder's concept on the basis of performance expectations. On a traditional delivered project, once the contract is awarded the role of Public Works Canada's project managers is to enforce the time, cost, and quality of work stipulated in the contracts. With the designhuild method, the project manager becomes more of a pilot steering the contractor through the final design and construction activities to ensure the client's expectations of scope, time, cost, and quality are met. This change in role was demanding since policies and procedures had not been developed to aid this form of project delivery. Yet, in this context of seemingly incompatible or restrictive procedures, one of the most important lessons of the project emerged. It is easier to gain support for changing procedures when a project under implementation clearly requires an adjusted process. Once a change has been made, it is far easier to follow the path a second time. This can be an effective means project managers can use to change process systems to meet their needs. The method adopted for delivering the Quesnel air terminal is being followed to deliver another larger-scale terminal for the Sandspit airport. The Pacific Region has adopted the proposal package used for Quesnel as a general package. It was edited to meet the specific performance criteria required for the Sandspit Airport air terminal building. Client Role and Relationships Changed The client also has many role adjustments to make. Transport Canada's Airports Group in the Pacific Region partners with engineers and architects at Public Works Canada (PWC).Each year, PWC project managers implement twenty or more projects together with their Transport Canada client. Notwithstanding the excellent working rapport between the joint staff, traditional ways of doing business did change. Transport Canada usually assigns a technical specialist as project leader on behalf of the airport manager. In addition, support staff review project designs and specifications to ensure they meet client needs. The Transport Canada project leader on the Quesnel ATB project found that communication requirements expand significantly when traditional processes are changed. Staff members responsible for detailing the client's operational and technical requirements had to redefine their relationship Motivating with the project manager and all other parties. Instead of scripting long lists of specific requirements, which in-house or consultant designers traditionally use, they focused on describing the performance characteristics required for the building. Instead of reviewing designs, selected technical staff members were assigned to the committee reviewing proposals for design and construction. Once a developer/contractor was selected, a new discipline came into force: the client was under greater pressure to complete design reviews quickly and minimize changes to the project scope. The emphasis was to get project requirements agreed to up front. This need to define project requirements up front is not new to management. However, it did take a new process operating under time constraints to shake the requirements providers into adopting the idea. The management directive, that any requirements not provided up front would not be included later, played a key role in the success of the new project delivery method. Transport Canada's senior management also found its role changed. Senior management members' interest and involvement in a different project delivery method meant they had to evaluate and manage new risla. How can quality be assured when you don't spec* materials and construction methods?Could the project be delayed if the best overall bid is not the lowest bid, thus requiring application for the authority to skip the lowest bidder? Since the process is different, do we have the requisite knowledge and skills available to manage it? Government agencies try to avoid taking risks. Government departments look differently at the risks taken in delivering a project by design/build, compared with how private sector firms regard those risks. Operating in the "fish bowl" of public scrutiny, government officials are very sensitive to the concerns and opinions of a broad constituency of interested parties. Ensuring continued support for a different approach to project delivery required greater than normal emphasis on consultation and cornmunications. Key people were kept informed by steering committees, technical committees, airport site advisory committees, special meetings, briefing notes, and frequent one-on-one meetings and phone calls. All these techniques apply in normal project delivery but the frequency of meetings and the range of expertise among participants expanded with this project. When a public enterprise takes on a design1build project that is a significant departure from how business is usually done, new relationships form, old relationships are enhanced, and processes change. If the process is successful, it can change how the players view their jobs and their capabilities. This type of initiative in a public sector environment can trigger further empowerment and system change. The project team became committed to solving problems aggressively; they wanted success and, individually and collectivelyl they sought opportunities to further improve the project delivery processes. Listening to customers and addressing their concerns directly can have a revolutionary impact on an organization that traditionally defines project requirements for others. Although design/build is not a guaranteed way of reducing project costs, it does offer an alternative method of delivery that can gain momentum as Project Management Casebook government departments continue to look for ways to deliver programs more cost effectively. The design/builder can often provide innovations that are transferable to new projects. The designhuild team has strong incentives to find ways of reducing costs and expediting the project. The approach can deliver cost-efficient innovations from the developer. For example, speed in project design and delivery is often cited as a primary reason to seek a developer who is a desimuilder. In the case of the Quesnel ATB, although speed of delivery was not a driving priority, the project proceeded eight weeks ahead of original schedules. The obvious lesson is that the process can accelerate schedules, and the project manager should be prepared to respond and exploit the opportunity. Since the developer's schedule created the requirement for the project manager and the client to assess their proposals more quickly, decisions were made and implemented fast. Decision-makers and reviewers not only made the effort to meet the shorter turnaround times, but they recognized that responsiveness was a key element in maintaining the quality of the relationship between the developer, project manager, and the client. This broad-based understanding of the importance of working cooperatively has been instrumental in setting up the correct environment for implementing the next design/build project. The cooperative relationship required frequent and open communication. The emphasis placed on developing communication plans, setting up work groups and committees, and holding more frequent meetings supported the collaborative effort. In the early stages of the project, the communications requirement was even more of a challenge because the project team did not have a building design to show interested parties. It was also necessary to explain how the design/build process varies from the design/bid/buildprocess that many people understand. On the other hand the increased need for communications was offset by the project manager having a "smgle point of contact1' with the designerhuilder. For future projects, additional consideration will be given to allowing for contingencies in setting the project budget. The client must evaluate risks and be prepared to consider that components of the project budget are targets to be met within reasonable tolerances, as opposed to fixed amounts. To this end, the public sector project manager would be wise to increase the contingency budget on designhuild projects. Applying new techniques in the public service environment can deliver collateral benefits. Public enterprise project managers can use design/build as a tool, not only for delivering projects for clients in a new way, but as a means of demonstrating that they are capable and willing to innovate. In a world that demands innovation and flexibility from public servants, this change in attitude can deliver the biggest benefit of all. Motivating QUESNAL TERMINAL: DESICN/BUILDWORKS IN THE PUBLIC SECTOR AIR 1. This case illustrates how, due to the pressure from a group of stakeholders, the project found a creative way of achieving the desired result. Stakeholders are a very important element of any project. Develop a generic set of stakeholders for any project. 2. Who were the specific stakeholders for this project, and what was their stake in the project? 3. This project worked with the public sector and thus existed in the "fish bowl" of public scrutiny described. In order to continue funding for the project, the project management must be sensitive to its relationship with the public. How did project management deal with this concern successfully? 4. The use of the designhuild method for the contractor allows the fulfillment of many goals and requirements of the stakeholders in an innovative manner. What are some of the advantages of this method that are mentioned in the case? 5. The designhuild method resembles an interdisciplinary team made up of members from engineering, design, and manufacturing. Due to the development of such a team, many positive effects are felt in the project. This type of team is also know as a product-process team or the concurrent engineering process. What are the advantages to this type of team or process? 6. It is stated in the case that "listening to customers and addressing their concerns directly can have a revolutionary impact on an organization that traditionally defines project requirements for others." Compare this statement to the well-known Hawthorne effect, which shows that attention paid to employees impacts the conscientiousness of employees in their work. How ICL Used Project Management Techniques to Introduce a New Product Range Peter Kayes, School of Technology and Information Studies, Thames Valley University, U.K. International Journal of Project Management, October 1995, pp. 321-28 ICL was a product of the United Kingdom (U.K.) merger mania of the 1960s, when the Labor government endeavored to create strong U.K. companies to protect the U.K.'s technological base from United States (U.S.) domination. However, within a few years of its formation, the U.K.'s leading computer supplier was in trouble. A new managing director was brought in from one of the major U.S. computer suppliers, and he brought a new management style with him. This paper looks at how project management techniques were used at ICL in the 1970s and how they helped the company to cope with organizational challenges and to manage the risks of introducing a new product range of mainframe computers into the market. Examples of successful projects that were undertaken during this period are provided. The paper also speculates on the extent to which this has helped ICL survive through the late 1980s and early 1990s, during which time the industry has undergone major structural changes. The experiences and project management techniques described are still relevant to ICL and the information technology industry as a whole today. I worked in the U.K. computer industry from 1967 to 1982, before moving into higher education to teach. For most of this time I was with ICL, where I witnessed the transformation of a traditionally run U.K. company into a project-driven organization. This resulted from the appointment of a new managing director and his perception of how the company needed to operate to stay in business. I spent some eight years as a project manager in the remodeled company, working in a variety of situations with different project structures. This paper looks at the impact of the introduction of a project management approach in the company. BACKGROUND ICL was created in 1968 as a result of a merger between ICT (International Computers and Tabulators) and English Electric Computers; it was to be the mainstay of the U.K. computer industry. The merger brought together the major U.K. suppliers of commercial computer systems at that time; they had between them some 50 percent of the U.K. mainframe market. The merger was encouraged by the U.K. Labor government, which took office in 1964, and believed that the indigenous U.K. computer industry was on the point of extinction (1). This recognized the realities of the investment costs of competing in the international computer market. ICT had a highly successful range of computers, the 1900 series, and some 2000 of these systems had been sold. Its architecture was based on 6 bit characters and was viewed by some as dated. English Electric was marketing a range of computers known as the System 4 range, which was IBM 360 compatible and was made in the U.K. under license from the RCA Corporation. Only 200 systems had been sold, but the architecture was competitive and used 8 bit bytes. These two ranges of computers were incompatible with each other. A decision was taken to develop a new range of computers as a result of a study of various options. The technical case for the choice was based on competitive comparisons and research and development work worldwide. It drew strongly on work being carried out at Manchester University, U.K., where the MU5 was the latest in a line of developments which had led to other major advances in their time, such as the Atlas computer. It also drew on research at the Massachusetts Institute of Technology, U.S., and the University of Eindhoven, Netherlands, where Dijkstra had been developing concepts for structuring operating systems (2). The marketing decision carried risks. The justifications given for the decision included technical and internal political factors and not simply commercial reasons. It was thought that a new ICL product would help to build the new corporate identity, and this case was advanced as a break with the past. The strategy was high risk because of the usual need for customers to be able to transfer their programs onto a new machine. Lack of forward compatibility removed the competitive advantage normally enjoyed by a supplier in terms of its existing customers. To try to sell customers machines which were incompatible with their present ones increased the risk of losing them to competitors. A customer who had been tied to ICL for years by the proprietary design of the software would have a free choice of supplier when considering a move to the "new range." However, on the other hand, there were the technical issues of the two existing incompatible ranges and the outdated design of the majority of the company's systems. The development of the "new range" (the 2900 series as it became known) took five years from the initial design documents to the early prototype systems. Some 200 programmers worked on the operating system alone, and this cost 1,000 staff years of development effort before the first version was released for limited field use in 1974/75. The cost of this development had been budgeted for, but the work took longer than expected, and it was toward the end of this period that the managing director of ICL, Geoff Cross, turned his attention to the development side of the company. Geoff Cross was recruited from Univac in the early 1970s to rescue ICL, which was losing money in a stagnant market; there was also increasing competition from minicomputer manufacturers such as Digital Equipment Corporation and Data General. His first priority was to address the sales situation, which he did with considerable success, increasing sales volume by sharpening up the sales force, introducing new products such as the 2903/4 minicomputers, and developing new ways of selling, such as the creation of customer centers offering bureau services. By 1974, time was running out for the older models as the customer base was being won over to the new 2900 systems. The sales volume of the old systems was declining, and the first 2900 systems were due to be shipped at the beginning of 1975. The business plan required that they be delivered on time to maintain the revenue stream. The director of the systems programming division (SPD) was having difficulty holding development work to deadlines. MANAGEMENT OF LARGE DEVELOPMENTAL PROJECTS CADES Approach to Software Development For some years, the SPD had used project management techniques, such as PERT, to help monitor and control development work. From the beginning, the VME/B operating system development work was supported by the use of a database system, CADES (computer-aided design and evaluation system), and modular design techniques. CADES was used as both a management tool and a design aid. A structured approach to software development was becoming fashionable at this time, after years of anarchy when it was unusual for a computer programmer to stick to deadlines. Folklore indicated that any program would take twice as long to produce as planned, regardless of whatever forecast was made. The computer industry's version of Parkinson's Law was that work expanded to fill twice the time available! In an attempt to bring more professionalism to software development, engineering techniques were adopted. This is one facet of what is now referred to as "software engineering." As in network analysis, structured software design and modular programming techniques require a problem to be broken down into a series of small manageable tasks. A module of code is then written to perform each task. A sound design will identify how many modules are required and how they interrelate. It is possible to design each task to require a similar amount of code. On the basis of experience, it is possible to estimate how much testing is required to get a module working. This makes it possible to estimate fairly accurately how much work is required to complete the overall job and to monitor progress. CADES was used to support this management approach. A team of 200 systems staff was involved in the development of VME/B for a period of five years through to the early releases. This amounted to a huge project that comprised in excess of 1,000 staff years of effort. This was a massive investment, which cost some 50M in today's terms, that had to be managed. A central design team of twenty people was responsible for the development of the operating system, which was divided into subsystems, as shown in Figure 1. Each designer had responsibility for one subsystem. The designer monitored the production of the subsystem under the direction of the chief designer. The production was undertaken by programmers in teams of ten to twenty, under a line manager. Each of these was responsible for writing the modules of a subsystem, and one member of the design team was responsible for the work of each programming team. A central support team of twenty was responsible for running the CADEs database, which was an overhead of 10 percent of development costs. Figure 1: VME DEVELOPMENT TEAM As modules were written, their specifications were coded and entered into the CADES database, which performed certain checks, eliminating some syntax and logic errors. Software interfaces were checked for correctness and access permission. Procedure calls and data definitions were generated, thus reducing the risk of errors as well as capturing design and usage data. Modules were expected to consist of no more than 150 lines of code, to avoid the problems associated with long unstructured programs. It was expected that each module would take one programmer one week to write. The logical structure defining which modules were required was produced at an early design stage for "sign-off" by the designers. It was thus possible to estimate the total time required to write the software and to monitor progress. Problems not addressed at this stage were those of system testing and the need to rewrite or "enhance" modules as developments progressed. The benefits of CADES can only be estimated, as it was used on a unique project on the basis of faith and experience of previous similar developments. The rationale was that 80 percent of the costs associated with software are incurred by maintenance work post release. The objective of CADES was to provide a discipline and databank that might be capable of halving these costs. Whether this was ever realized cannot be measured. There were many other benefits, some more tangible than others: The database provided mechanisms for change control, and version numbers for each module. The number of bugs created during development was expected to be significantly lower than for a conventional process, because of the code generation and automated checking. It was thought that the number of these was at least 50 percent less than the typical number in conventional software development at that time. The database provided lists of modules that used items of data and other similar crossreferences. These could be used by the designers to identify the impact of any design change (how many and which modules would be affected), thus helping in the evaluation of a proposal and in the estimation of the cost of implementing it. The database was used to produce microfiche listings of the code of the system and, ultimately, online diagnostic access for support staff dealing with customer problems. These processes would have been more expensive to provide separately. The management approach used up to this point combined features of a functional hierarchy and features of a coordinated matrix (4). It had limited success while all the developments were within the area of responsibility of the senior manager in charge of VME/B; but, as soon as other software teams such as the compiler writers team became involved, there were disputes about who was responsible for what, where the causes of bugs lay, and so on. Further measures had to be taken. Project Managing the System Releases The SPD had always relied on a traditional hierarchical management structure, and it had no experience of coping with the challenges it now faced. A secondary matrix structure was introduced as part of the new management style by the team of U.S. project managers that Geoff Cross had recruited. Their brief was to make sure that the delivery dates were met. Their direct line to the top meant that when they wanted something done, it got done. Their approach was never to accept that something could not be done, but to ask, "What do you need to get it done?" This simple question was central to their success. It enabled people to ask for additional resources to meet targets, rather than allowing them to use the lack of them as an excuse for missing targets. If someone asked and was convincing, he got what was asked for. The direct line to the top meant that budget provision could be found, resources transferred, or savings made elsewhere, in less critical areas if necessary. The provision of short-term resources in selected areas is relatively inexpensive in a company with 30,000 staff. In some cases, staff members were transferred or seconded from other parts of the company, with very little adverse impact in the short term. In some cases, secondees were people who needed training in the new products and so there was a direct benefit. This approach illustrates the advantages of overriding normal line structure, in which managers can be reluctant to release people because of their focus on short-term service and operational needs, despite the long-term strategic advantage of investing in staff training. If a line manager does not have any direct responsibility for a new product, releasing people is seen as a problem. In a highly technical area of development such as this, throwing resources at the problem does not necessarily solve it. When particularly difficult problems were encountered, the question became, "Who do you need to solve this?" and the key specialists were enlisted. In other cases, the decision was to go without a feature until it could be fixed and to release the product with "known shortfalls" rather than delay the release. The justification for this was that it enabled progress to be made along the critical path in all the areas which worked satisfactorily while the problem was investigated. The approach of finding additional resources concentrated the minds of those responsible for the new products. It made them take responsibility for their actions as they had no excuse for doing otherwise. The blame culture was banished, and this contrasted with the previous management style of shouting at people to do things without providing any additional resources. For me, this was a very positive introduction to a different form of project management. Other structures were established to reinforce a project management style throughout the organization and to short-circuit line decision-making: A national network of experienced project managers was set up to communicate via project manager bulletin sheets. Quarterly meetings were organized to identify common matters of process, expose specific successes and failures, and identify mechanisms to overcome corporate bureaucracy. Monthly meetings, latterly called "troikas," brought together the three key operational players from across the organization at a tactical level (from the manufacturing, hardware/software validation, and customer services departments) who had the opportunity to fix anything, allocating materials and skills directly to a given task anywhere in the world. Multidisciplinary teams were brought together to build, test, and then support the early releases of the software. Through direct reporting to a control center established by the "mafia," the traditional management blocks inherent in the SPD hierarchy were bypassed. When a resource was needed, the director of the SPD was instructed to find it. The cost in relation to the total SPD budget was tiny, but when someone is buried in a hierarchy, it is difficult to get a cry for help heard. The team responsible for these system tests used milestones to measure success. Standardized estimates of the number of "test shots" needed per module were used during alpha and beta testing. These were based on experience and were related to the complexity of the module. They were often low, perhaps consisting of one or two shots only, and they provided good progress monitoring information weekly. Milestones were created on the path to the first delivery dates, and they were immovable. Resources had to be deployed to ensure that activities did not jeopardize the achievement of a milestone. Concern that the system was not ready was not allowed to delay delivery, although most people thought that they would be given more time to get it "working" right up until the last minute. The software was shipped on the due dates. One of the challenges posed by high-technology products, especially during the early stages of a new project introduction, is that hardware and software innovation is a regular if not weekly phenomenon. It is quite impossible for a hardware and software configuration to be system tested in a cloned validation or test environment. Local and network cabling can only be tested on-site. Real workloads always test a system in ways different from a simulation. These and other local environmental conditions mean that only a test on-site is a conclusive confidence test. Even then, ongoing developments such as new releases of software or changes in the customer workload create major continuing challenges for project management. Establishing a Support Structure ICL had to find a way to ensure that the staff members out in the field preparing customers' systems received the support that they needed. These customer support teams had to work with a very fragile system that was delivered on time but had a great many bugs and was largely untested in the live environment. They also had little relevant first-hand technical experience. The novelty of the new product was such that a project approach was needed to create an initial support structure. This had three facets: a central support team to which staff were seconded project managers appointed for key accounts to negotiate with and share responsibility with operational managers dedicated project teams responsible for working with early customers to help ensure the installations were successful. The central support team was a natural development of the functions carried out during the final systems tests. New staff were drafted into the team from other areas of the company, such as field engineering support, to help train people for later work on customer sites. A four-shift operation was established to ensure twenty-four-hour support for the customer support teams, who were working under enormous time pressures. The specialist technical knowledge required was to be found in this support unit, and the team acted as a means to spread this expertise through cross-training while the staff were on shift. Large shift bonuses were offered to compensate for the twenty-four hour seven-day-week pattern. The overall cost was again low in the context of the SPD budget, but the arrangement broke all the rules in terms of demands on staff and the level of rewards paid to compensate them. The combination worked because sufficient numbers of able people came forward to join the unit. Good management of people issues was essential in making the package successful once the most technically appropriate approach had been identified. The SPD was then asked to appoint project managers to take responsibility for supporting key customer project teams. The purpose of this was to provide a mechanism for a sales support team to obtain specific support for its project from the development staff (see Figure 2). The SPD project manager was responsible for serving as liaison between sales and development staff to ensure that the technical specification required to meet customer needs was met by agreed dates. The sales staff knew what the customer wanted, and the development staff knew what was going to be available and by when; these did not always match up. Figure 2: PROJECT MANAGER AS INTERFACE BETWEEN SALES AND DEVELOPMENT STAFF The project managers appointed by the SPD knew who to talk to, and they were technically competent to understand the issues and options. This often meant adjusting the sales team's expectations about what was realistically possible within a reasonable budget. In some cases, prices were negotiated to bring developments forward by providing additional effort for which the sales teams were prepared to pay; in other cases, the availability dates of key facilitie were adjusted and some brought forward when other facilities could be traded out. On this occasion, the members of the sales team had to concentrate on what they really wanted, rather than demand everything. The key question was, "What will it cost?" By now, the development staff had learned not to say that something could not be done. Instead, they estimated the cost and impact of responding to a request. The project manager also had the job of ensuring that any agreement was then fulfilled by monitoring the delivery of the items negotiated. Once the system was ready, responsibility was then transferred to the dedicated customer project team. This was a relatively small-scale implementation project. DEDICATED PROJECT TEAMS The major issue for both ICL and its customers in relation to the introduction of the new computer systems was the containment of risk. To this end, ICL used elaborate procedures to ensure that all sales proposals had been signed off by senior managers across the company before orders were sanctioned: the so-called "Blue Border" procedure. This constituted a detailed project plan describing the configuration, applications, finances, and support proposals. For the introduction of the early 2900 systems into customer sites, the company adopted a policy of creating a dedicated project team headed by a senior project manager for each customer. This was part of the sales proposal, and the cost of the project team was taken into account in the profit and loss calculations included in the Blue Border. The early appointments of project managers were all made by the senior support manager, one of the "mafia." The first fifty installations had such project teams. Their sizes varied according to the value and complexity of the installation. There was a relatively larger size and company contribution for the earlier systems of these fifty. The sales force had been particularly effective in convincing these customers of the need to protect their major investments through sound project control to minimize the shared risk of failure. The company also made a major contribution by providing scarce specialist technical skills to help the customers through these early development days. A typical project comprised around ten staff years of support over a two-year period, although some were much larger. The team offered specialist skills to help each customer prepare for her new installation, as shown in Figure 3. Delivery of the system was midway through this period, and much of the preparatory work consisted of conversion of programs to run on the new machine. Either the customer resourced this (in some cases, this amounted to fifty or more staff years of work), or it was subcontracted. Figure 3: TYPICAL ICL PROJECT TEAM My job as project manager for one of these installations in the local government market had many facets. I had to recruit a suitable team to support the customer. I had to clarify the customer requirements and match these to the availability of hardware and software. I also had to negotiate with subcontractors, acting as a go-between for the customer and contractor when these were within the ICL group (see Figure 4). This inevitably entailed some renegotiation, both with the customer and within the company. Each project pioneered something. My site was the first site to be required to run a full-production workload for the customer and replace an existing system. Most installations up to that point had been used for development purposes only. The cost justification to the customer hinged around the old system being removed within one year. From the company's point of view, future orders from other customers in this sector of the market depended upon this installation being seen to be a success. I was in a strong position to get agreement for what was needed within the company and to obtain customer agreement to proposals that were realistic if it helped it to stay within budget. This was achieved by adjusting its expectations to what was possible within the time-scale and agreeing to standards by which success could be measured. Figure 4: RELATIONSHIPS TO BE MANAGED BY PROJECT MANAGER A project definition was drawn up by the project team, in consultation with customer staff, as a detailed statement of our mutual understanding of its requirements, taking into account the state of development of the product. This differed from the original sales proposal but was a negotiated and more detailed derivative of it. Arrangements were agreed upon for monitoring the work of project team members so that the customer would be willing to accept invoices for this as agreed in the sales terms. Within the company, I was required to report monthly to a project review meeting held by a senior support manager. There was thus internal accountability to someone with relevant experience who was able to monitor the risks, test my knowledge of the current state of developments in the company and on-site, and explore my contingency plans. This review was important as there was no previous experience in this sales area of installing a 2900 system. The local support staff and managers needed to learn fast and were able to do this through involvement with the project and attendance at the meetings. Part of the reporting included an update on the project milestones that had been drawn up. These were derived from the agreed project definition and our view of what was needed to meet this. Milestones were recorded and monitored centrally for all the 2900 projects at this time, along with project status reports indicating whether things were under control or going wrong. A green-amber-red system was used. I used a combination of PERT networks and bar (Gantt) charts to monitor the state of the project and the resourcing needs. This was all done manually, largely because of the relatively small scale of the project, which involved no more than six ICL people over a two-year period. I had previously used a computerized PERT system on a project when I had to report progress to partners in the U.S. every two weeks. Although this project was of a similar size, the computerproduced output added credibility to our progress reports! Performance standards that were agreed included serviceability and usability statistics measured in terms of the mean time between failures (MTBF) and the percentage of computer time that was used on productive work. The customer had not bothered with any such statistics on his previous system, knowing what it could do, and it was essential that we defined procedures for monitoring the system performance in addition to agreeing what would be acceptable. This was essential, not only to test whether we were meeting the agreed levels, but also to monitor improvements over time as a result of actions we took, especially if we fell below the required level. Being cynical, a statistic of 98 percent serviceability also sounds quite impressive, while a period of downtime of three hours a week sounds bad, although the two are equivalent. In reality, actual measurements often present a more favorable picture than impressions. Otherwise, it is only the bad news that is reported. The statistics are essential for objectivity and as a means of measuring progress. The project was a success. The old 1900 system was switched off in 1978, twelve months after the 2900 system was delivered. All the application programs were running on the new system, and reasonable levels of reliability were being achieved. Fifteen years later, ICL is still the supplier of computer equipment to the site. Two 3900 mainframe processors run many of the applications under VME, although there has latterly been a trend toward the use of Unix boxes, also supplied by ICL. The site heralded considerable success for ICL in the local government market, with many other 2900 systems being ordered and installed after 1977. There were other residual technical problems that had been anticipated and which took several more years to resolve, but the long-term success of the site illustrates that this was considered acceptable by the customer. The project approach was highly appropriate and very successful for these projects. It gave the project managers high status and considerable power and autonomy to get things done, while there was still accountability to the center. It gave both the company and its customers a significant boost in coming to terms with a major technical and organization challenge. The projects were successful because project staff were able to develop a positive relationship with the customers, were seen to be there to help, and gained the confidence of the customers. The ability of the project managers to cut through the bureaucracy of the company was a key element of this. We were "close to the customer" (5). In any matrix and express escalation project management system, there have to be some rules. Within ICL, these operated as follows: At critical customer system review meetings (CCSRMs), any customer or system problem could be placed on the weekly agenda by almost anyone. Inclusion in a CCSRM meant that all faxes were responded to within the first hour, and progress was monitored every four hours, twenty-four hours a day, 365 days a year. Special investigation report (SIR) meetings took place every two weeks in the corporate boardroom (attended only by corporate and divisional directors) to monitor any CCSRM actions that had been outstanding for more than one day without a solution or at least a time-framed plan to achieve a satisfactory solution. Anyone who caused a senior manager or director to take urgent action over a weekend or at night needed the confidence that such escalation was warranted. Equally, woe betide anyone who did not apply enough priority or corrective action, or who over exaggerated minor local issues into priorities. These measures did ensure that serious issues were addressed, and they provided support for the project management structures. During the second phase of the introduction of the 2900 system (the installation of the next fifty systems), a streamlined structure was used, often with one experienced project manager looking after several sites, each with much smaller project teams. By then, the risks were lower, less was new, and more people who had relevant experience were available. The customers were still exposed to risk because of the scale of the change they were undertaking, and therefore they still needed support, but the risk was by then more one-sided. Customer support became more of a mainstream support responsibility, and the structure gradually changed back to a balanced matrix approach. PROJECT MANAGERS AS CHAMPIONS Project management is the natural way to work in the computer industry because of the high degree of novelty of most projects, the dependence on technology, and the high rate of change of this technology. Notwithstanding this, many of the issues faced by project managers are people based, requiring good interpersonal skills and a sound grasp of general management concepts, as I hope I have illustrated by my examples. Ideally, a project manager will have a combination of relevant technical and managerial skills, this being more essential on a small project where the project manager needs to provide technical leadership. On a large project, it is more possible to rely on other members of the team for the technical skills, as long as the project manager is able to exercise good judgment when necessary. Reference 6 reflects much of the ICL project management style. The ICL project teams were empowered and were forces for innovation. The project manager was the "customer champion" within the company who protected the customers' needs. There was also an element of the project manager being a product champion within the company, helping to identify and resolve problems, some of which were unique to the project at that time. The role was antibureaucratic, cutting through the lethargy of existing hierarchies. There were exceptions when resistance could still be found, but an empowered project manager does not give up! This is illustrated by a later example when we were developing a performance improvement package (PIP) to help customers get more work through their 2900 systems, addressing a major concern of the customer base about poor performance. A project team was brought together to pool expertise on how to address the problem. A set of fixes was developed and tested on pilot sites, showing a significant overall improvement in system throughput of about 20 percent for relatively little implementation effort. We wanted to release this package to all sites, and we approached the software distribution center for help. It refused to put our performance manual out with its next mailing because it did not conform to its standards of presentation and editing. The fact that it was addressing an urgent need made no difference. To use the distribution center's system would have caused a delay of at least six months. Instead, we found an alternative source of distribution and support and got it out into the field within one month. This may appear to be an example of a line operational manager not understanding the dynamic nature of the business, but this is an unfair analysis. It was actually an example of conflicting standards, where two parts of the organization had different objectives. In our view, it was as important for the company to be seen to be responding quickly to concerns as it was to come up with technical solutions. A six-month delay would have rendered the package irrelevant, as the next major software release was planned in that time-scale to incorporate many of the enhancements we had developed. This final point also illustrates the need to maintain a link between operations and projects. It serves no long-term purpose for project managers to solve problems on a one-off basis and for the organization as a whole not to benefit from this. Solutions must be fed back to ensure that there is no unnecessary reinventing of wheels. There is not much that I would change if I were applying project management principles today. ICL has delayered, like many other organizations, creating more autonomy, and empowering staff members to determine their own objectives and be accountable accordingly. This was the way we worked in our project teams, and it was a recipe for success, although this can never be guaranteed. Potential conflicts can sometimes be resolved by reference to the corporate mission (something we did not have in 1979). I would also want to ensure there were mechanisms to share experience without constraining people to do things a particular way. The "project" culture relates to the management of change, which is something that has always been a feature of the computer industry. Increasingly, this is becoming relevant to other industries and sectors of employment, even the U.K. Civil Service, which is experiencing unprecedented change. Relevance to ICL Today The project management approach introduced by Geoff Cross did much to enable ICL to survive the 1970s and the major challenges faced by the company at that time. Many people learned new skills during this period. When Geoff Cross left the company after five years to return to North America, the company went through a period of uncertainty. The senior managers who took over did not have as sound a grasp of the project management approach, and there was a partial return to the previous hierarchical style of working. Many of us found this period frustrating, being unable to get messages through to the senior levels of the company about what needed to be done. By 1980, the company was again in difficulty. Robb Wilmot was recruited from Texas Instruments to take over as managing director, and he set about restructuring the finances of the company and reducing the cost base, shedding over 5,000 jobs. Opportunities for partnerships were sought, and in 1981 this resulted in an agreement with Fujitsu to supply technology and components. The company became profitable, propping up its subsequent parent organization STC, which, having taken over ICL, itself got into trouble (7). By the end of the 1980s, Fujitsu had acquired an 80 percent stake in ICL, and the company has remained profitable and successful since, despite the severe impact of the world recession and the rapid technological and commercial developments in the industry which have affected most of ICL's competitors. An account of the U.K. government PAYE project describes how ICL evolved during this period (8). The PAYE contract was won toward the end of 1980 by a consortium comprising ICL, Computer Sciences Corporation, and PACTEL. The project was based on 2900 series computers, and project management techniques were used to ensure that the project was successful. The features considered key to the success of the project were good planning and the preparation of a secure software environment, careful documentation of requirements, change control, commitment to success by senior management, and no attitude of "it cannot be done," but rather "yes, but this is what it will cost." Many of the senior managers at ICL today experienced the cultural shift in the company during the 1970s. The lessons of that period were the importance of focusing on customer need, working single-mindedly to achieve goals, deploying resources accordingly, not accepting excuses for things not being done or being late, and empowering managers to use the organization to achieve their goals. The current chairman and chief executive, Peter Bonfield, was brought into ICL by Robb Wilmot, and became managing director after the STC takeover in 1984. He describes his managers as entrepreneurs. They have a free hand to do as they want as long as it is profitable and in their target area. He believes in delegating, and he likes winners (9). This has a strong resonance with the project management style introduced in the 1970s. The lessons of that period will have been a valuable preparation for many in the company who have helped ICL to remain profitable in a hostile climate. The techniques of project management are as relevant today as they have ever been, because of the need to minimize risk and achieve project deadlines. Thirty-five percent of new products launched fail commercially, and 45 percent of total new product expenditures are on unsuccessful projects (10). Meeting deadlines is one of the two top issues faced by IT executives (11). Conservatism is still to be found among managers in traditional hierarchical organizations (12), and the introduction of project managers is seen as a threat to their status. However, increasingly, these traditional hierarchies are being transformed into dynamic structures as businesses are reengineered. Dedicated project teams need to be located where the main risks need to be managed (13), which was the approach adopted by ICL with the introduction of the 2900 series. The client as the project champion, committed to its success, brings together the concepts of the need for senior management commitment (8) with the effective supplier-customer relationship ICL fostered with its dedicated project teams working to help the customers achieve their objectives. In all these situations, the project manager needs a combination of technical and people management skills in order to anticipate problems and risks while developing the working relationships needed to resolve or avoid them. The need for an effective relationship with the customer is as important as the relationships within the project team and with other colleagues or superiors in the manager's organization. Roman (14) in summarizing the characteristics of an effective project manager, cites the ability to bring out the best in people as one such people management skill. Action-centered leadership combines meeting the needs of individuals and the needs of the team in achieving the goals (8). A project manager is involved with innovation and managing change. The conventional operations manager is involved with managing continuity and existing processes effectively. Peters (6) suggests that change is on the increase, and that there is a shift away from mass production towards variety. This is confirmed as the view of IT managers (11). Bonfield encourages entrepreneurship and initiative. As the pace of change continues to increase, project management will play an increasingly important part in all organizations as they endeavor to manage the activities going on around them. While the parts played by Robb Wilmot and Peter Bonfield in rescuing ICL in the 1980s were essential elements that enabled ICL to survive, the project management skills learned under Geoff Cross prepared people to survive in the increasingly competitive environment of the 1990s. Acknowledgments The author would like to thank Ed Sampson, previously a fellow project and support manager at ICL and latterly a colleague at Thames Valley University, U.K., for a number of specific suggestions and reminders of approaches used at ICL which have been included in the text. Thanks are also due to Dennis Ramsay, marketing director for the National Accounts Division at ICL, for confirming the accuracy of the account. REFERENCES Wilson, H. 1974. The Labor Government, 1964-70. U.K.: Penguin. Dijkstra, E. W. 1968. "The Structure of the T.H.E. Multiprogramming System." Communications of the ACM. 11, 341-46. Buckle, J.K. 1978. The ICL 2900 Series. U.K.: Macmillan. Turner, J.R. 1993. The Handbook of Project Management. U.K.: McGraw-Hill. Peters, T.J., and R.H. Waterman, Jr., 1982. In Search of Excellence. U.K.: Harper and Row. Peters, T.J. 1987. Thriving on Chaos. U.K