Research leading to the project capability building model

The PCB model presented in Chapter 7 was a product of inductive research (Eisenhardt, 1989: 535) based on the empirical findings of three successive research projects undertaken between 1994 and 2003. As shown in Table C.1, Project 1 identified Ericsson's move into a new category of projects. It proposed the hypothesis that Ericsson's new ‘turnkey project’ represented a generic move taking place across industries. But there was little evidence to support this claim until Project 2 which found that Cable & Wireless was also moving into the provision of a new category of projects which Project 3 referred to as ‘integrated solutions’. It was not until Project 3 that in-depth case study evidence was collected to confirm that five firms operating in different industries were developing the capabilities to move into the provision of integrated solutions projects.

The process of theory building was highly iterative and the long gestation period for the emergence of the theory reflects the empirical evidence. It has taken a long time for the organisations to build capability and to overcome organisational inertia as they move from a focus on exploring new possibilities to full exploitation of a new line of projects. Throughout the three research projects, data were collected in a variety of ways. The authors conducted 126 data-gathering interviews (lasting around two hours each) with strategic managers (including current and former CEOs), senior project managers, heads of functional departments and managers involved in project and line activities.

Project-based organisation: case objectives, method and limitations

The purpose of the case study in Chapter 5 is to examine the nature, strengths and weaknesses of the PBO in comparison with the functional form through the lens of two major projects carried out within a single firm: one in a PBO division and one in a functional division. The case is a study of a firm that produces a wide range of advanced, high-cost scientific, industrial and medical equipment. The senior management in the firm wished to learn from the operating experiences of PBD, which had been in pure PBO form for around two years. PBD had proved highly successful in meeting customer needs and project performance targets. A key strategic decision was whether or not to implement a pure PBO in FMD, a larger division. The management felt that there were lessons to learn from the good and bad experiences of both organisations. Although both PBD and FMD produced similar CoPS equipment, for geographical reasons the physical merging of the two sites was not an option in the foreseeable future.

The research method involved examining the experience of two similar, complex projects (termed project P in PBD and project F in FMD) in order to review and compare project processes, problems and performance and to draw lessons for both organisations. One of the problems of case study research of this kind is the counterfactual difficulty of knowing what would have happened (e.g. in terms of performance) if another organisational structure had been applied.

This chapter examines the importance of high-technology CoPS to the economy and describes their innovation dynamics, showing that management practices and challenges differ fundamentally from those of mass-produced consumer goods. CoPS, like consumer goods, are not ‘all the same’, so we develop a simple taxonomy of complex products and projects based on their system scope and intensity of innovation. Underlining a major theme of this book, the chapter shows how and why a firm's core productive organisation, management structures and capabilities are shaped by the complexity of the product that it produces.

In discussing the critical dimensions of product complexity we focus on the value and cost of the products and their degree of customisation for the buyer and user. The nature of the component inputs, complexity of component interfaces, range of knowledge and skills involved, and intensity of user involvement together determine the overall complexity of the product and the type of project needed to produce it. In this and subsequent chapters where the issues are explored in more depth, we show that the need to produce CoPS in low volumes to unique customer requirements calls for strong capabilities in the management of projects and integration of systems rather than volume production and mass marketing as in high-volume consumer goods. We also show that the project organisation is ideally suited for performing such one-off or temporary assignments, rather than the traditional functional organisations used to perform standardised and recurring activities.

The Business of Projects is a highly original book in what we have hitherto considered a crowded market.

Most books about projects deal with how to manage them ‘from the inside’ – what tools and techniques to apply in order to deliver the project ‘on time, in budget, to scope’. This is the reality faced by many thousands of project management practitioners who are tasked with doing just this. Increasingly, however, it is being recognised that such an orientation has its limits: there are whole areas which typically are barely addressed in many if not most of the traditional project management texts. Much of the early project developmental work for example is barely discussed. The linkage with enterprise strategy is hardly covered (nor indeed is the whole subject of project strategy itself). There is often scant information on dealing with commercial issues such as procurement (which may even be treated as separate and distinct from project management) and contract management. Technology issues – requirements management, testing, information management and configuration management – may similarly be seen as somehow not part of project management. The hugely important area of people – perhaps the most important area of all – is generally poorly handled. Little encouragement may be given to thinking about the benefits that the project is to deliver, or how to measure them or how to optimise the value that the project represents.

The project business emerged as a major new form of industrial organisation and management practice in the second half of the twentieth century. Since the 1960s there have been numerous studies of project management techniques, specific types of projects (e.g. R&D and new product development) and project activities in particular industries such as pharmaceuticals and construction. But until recently the wider significance of the project for innovation and business strategy has gone largely unnoticed. Managers, policy makers, business commentators and scholars have been preoccupied with understanding, adopting and refining the principles of high-volume production. These principles were pioneered by some of the world's largest and most successful American firms like Ford, General Motors and AT&T and later improved upon by Japanese corporations such as Toyota. These firms created large, top-down, hierarchical, functional organisations, well designed for producing and selling standardised consumer goods and services in high volumes and making repetitive decisions in the comparatively stable industrial environment of growing mass markets.

Efforts to implement and improve high-volume techniques have led to significant advances in management tools in recent years (e.g. lean production, business process re-engineering and mass customisation). Yet the returns from such improvements are diminishing and will continue to do so in the future. Even today, for many firms seeking stability in the face of fragmenting mass markets, accelerating technological change and intensifying global competition in low-cost manufacturing, the reliance on high-volume management techniques and large, semi-permanent organisations is appealing.

This chapter examines the learning processes that must occur for a project business to develop the capabilities to move into a new technology and market position. The long-term profitability, survival and growth of the project business depend on its ability to learn from new base-moving projects and to convert the knowledge gained into new organisational capabilities and improvements in project performance. However, research has emphasised the challenges that firms face when they attempt to capture the learning gained through projects and transfer it to their wider organisations (Middleton, 1967; Gann and Salter 1998 and 2000; DeFillippi, 2001; Grabher, 2003). There is a risk that the knowledge and experience gained are lost when the project finishes, the team dissolves and its members move on to other projects or are reabsorbed into the organisation. Unless lessons learnt are communicated to subsequent projects, there is also a risk that the same mistakes are repeated.

Despite the difficulties of project-based learning, several studies show that firms can and do achieve organisational learning through projects (Keegan and Turner, 2001; Ayas and Zeniuk, 2001; Prencipe and Tell, 2001). However, research on project-based learning has tended to focus on snapshots of learning practices within a single project or learning between projects, with few examples of ‘enduring engagement in learning and profound large-scale transformation’ as firms succeed over time in generating and diffusing the knowledge gained throughout their organisations (Ayas and Zeniuk, 2001: 61).

This chapter examines one of the core capabilities of producers of CoPS and other high-technology goods and services, namely systems integration. Systems integration is defined as the core technical and strategic capabilities which enable a project business to combine all the various production inputs, including components, subsystems, software, skills and knowledge, to produce a product, system, construct, network or service. The aim of the chapter is to assess the nature and importance of systems integration by examining historical and recent research. It shows how systems integration evolved from its original application in the 1940s and 1950s in the military arena to other CoPS sectors and more recently to high-volume, technology-driven industries.

As a capability, systems integration has become increasingly important for organising production both within and across firms. As the chapter shows, while systems integration began as a technical, operations task (part of the wider functional discipline of systems engineering), today it is a strategic business capability, central to the management of many high-technology projects. The more complex, high-technology and high-cost the product, the more significant systems integration is to the capability and strategy of the firm. The chapter shows how systems integration underpins the competitive strategy of the CoPS firm as well as the particular position the firm takes within the value stream of an industry.

Introduction

Although Java first gained fame with applets in Web browsers and then became a popular tool for creating large enterprise services, the developers of Java originally intended it for embedded applications in consumer devices such as TV remote controls and Personal Data Assistants (see Chapter 1). The term “embedded” generally refers to encapsulating a processor into a device, along with programs stored in non-volatile memory, to provide services and features specific to that device. Microcontrollers, for example, are the most common type of embedded processors.

By embedded Java we refer to a device that contains either a conventional processor running a JVM or a special type of processor that either directly executes Java bytecodes or assists a conventional processor with executing bytecodes. The motivations for device designers to embed Java depend on the particular device, but, in general, Java provides flexibility, interactivity, networking, portability, and fast development of the software for embedded projects.

Today several types of commercial devices come with Java built into them. As mentioned in Chapter 1, over 600 million JavaCards have been sold around the world as of mid-2004, and several hundred cell phone models include Java.

Embedded applications typically must deal with very limited resources. A full-blown J2SE application on a desktop with a Swing graphical interface might require several megabytes of RAM.