Report Saari 012004 PDF

Helsinki University of Technology Laboratory of Industrial Management Report 2004/1
Espoo 2004
RISK MANAGEMENT IN DRUG DEVELOPMENT PROJECTS
Hanna-Leena Saari
Helsinki University of Technology Laboratory of Industrial Management P.O.Box 9500 FIN-02015 HUT Finland Phone: +358 9 451 2846 Fax: +358 9 451 3665 Internet http://www.tuta.hut.fi/
ISBN 951-22-7105-2 Printed ISBN 951-22-7106-0 Electronic ISSN 1459-806X Printed
Monikko Oy Espoo 2004
Helsinki University of Technology Risk Management in Drug Development Projects
TABLE OF CONTENTS
SUMMARY ................................................................................................................................................................ I 1.
1.1. 1.2. 1.3. 1.4. 1.5.
INTRODUCTION...........................................................................................................................................1
BACKGROUND AND MOTIVATION .............................................................................................................................. 1 RESEARCH QUESTION AND OBJECTIVES .................................................................................................................... 1 RESEARCH SCOPE ....................................................................................................................................................... 3 RESEARCH APPROACH AND METHODS ...................................................................................................................... 3 STRUCTURE AND CONTENT OF THE STUDY ............................................................................................................... 5
2.
2.1. 2.2. 2.3.
PHARMACEUTICAL INDUSTRY AND ITS NEW PRODUCT DEVELOPMENT PROJECTS .....7

DESCRIPTION OF THE PHARMACEUTICAL INDUSTRY................................................................................................. 7 DRUG DEVELOPMENT: PROCESS AND SPECIAL CHARACTERISTICS ........................................................................ 12 PROJECT MANAGEMENT IN THE PHARMACEUTICAL INDUSTRY .............................................................................. 21
3.
3.1. 3.2. 3.3. 3.4.
PROJECT RISK MANAGEMENT............................................................................................................29

RISKS AND RISK MANAGEMENT .............................................................................................................................. 29 RISK MANAGEMENT PROCESS ................................................................................................................................. 34 ORGANISING AND IMPLEMENTING RISK MANAGEMENT ......................................................................................... 48 STUDIES ON THE PRESENT STATE OF RISK MANAGEMENT IMPLEMENTATIONS IN COMPANIES ............................ 55
4.
4.1. 4.2. 4.3. 4.4. 4.5.
PROJECT RISK MANAGEMENT IN DRUG DEVELOPMENT PROJECTS ..................................57

LITERATURE VIEW ON RISK MANAGEMENT IN DRUG DEVELOPMENT PROJECTS .................................................. 57 RISK TYPES IN DRUG DEVELOPMENT PROJECTS ..................................................................................................... 59 RISK MANAGEMENT PROCESS ................................................................................................................................. 60 RISK MANAGEMENT TOOLS ..................................................................................................................................... 62 ORGANISING AND IMPLEMENTING RISK MANAGEMENT IN DRUG DEVELOPMENT PROJECTS ............................... 66
5.
5.2. 5.3. 5.4.
CASE COMPANY AND METHODOLOGY............................................................................................70

RESEARCH AND DEVELOPMENT PROJECTS IN THE CASE COMPANY ....................................................................... 70 PROJECT RISK MANAGEMENT IN THE CASE COMPANY........................................................................................... 73 METHODOLOGY OF THE EMPIRICAL STUDY ............................................................................................................ 74
6.
6.1. 6.2. 6.3. 6.4. 6.5.
EMPIRICAL ANALYSIS ............................................................................................................................76

FIRST-STAGE INTERVIEWS: DEFINING THE RISK MANAGEMENT PROCESS ............................................................ 76 SUGGESTION FOR THE RISK MANAGEMENT PROCESS IN ONE CORE THERAPY AREA ............................................ 87 SECOND-STAGE INTERVIEWS: GENERALISING THE PROCESS TO COMPRISE OTHER CORE THERAPY AREAS ........ 95 WORKSHOP: REFINING THE RISK MANAGEMENT TOOLS ........................................................................................ 98 SUMMARY OF THE EMPIRICAL STUDY ................................................................................................................... 104
7.
7.1. 7.2. 7.3. 7.4.
DISCUSSION AND CONTRIBUTIONS OF THE STUDY ..................................................................106

DISCUSSION ............................................................................................................................................................ 106 CONTRIBUTIONS, CONCLUSIONS AND MANAGERIAL IMPLICATIONS .................................................................... 110 RELIABILITY AND VALIDITY OF THE RESEARCH AND GENERALISABILITY OF THE RESULTS ............................... 113 RECOMMENDATIONS FOR FURTHER RESEARCH .................................................................................................... 114
Hanna-Leena Saari
ii
REFERENCES.......................................................................................................................................................117 APPENDICES ........................................................................................................................................................125 APPENDIX 1. STRUCTURE OF THE INTERVIEWS APPENDIX 2. OCCUPATIONAL TITLES AND DEPARTMENTAL PROFILES OF THE INTERVIEWEES APPENDIX 3. DIFFERENT RISK IDENTIFICATION METHODS AND THEIR ADVANTAGES AND DISADVANTAGES APPENDIX 4. EXAMPLES OF QUALITATIVE PROBABILITY AND IMPACT SCALES APPENDIX 5. PROBABILITY-IMPACT MATRICES APPENDIX 6. DIFFERENT RISK ASSESSMENT METHODS AND THEIR ADVANTAGES AND DISADVANTAGES APPENDIX 7. DESCRIPTION OF A PREVIOUS INDEPENDENT STUDY BY THE AUTHOR CONCERNING PRESENT STATE OF
PROJECT RISK MANAGEMENT IN THE CASE COMPANY
APPENDIX 8. FURTHER ILLUSTRATIONS ON THE RESULTS OF THE FIRST-STAGE INTERVIEWS
Hanna-Leena Saari
SUMMARY Pharmaceutical industry is changing rapidly: markets are growing and consolidating with constant mergers of big conglomerates. In order to remain competitive, companies have to be specialised, fast and flexible. Therefore, project management in new product development must be efficient and effective. This emphasises the importance of risk management. The original motivation for developing a structured risk management process in this study is based on the awareness that effective risk management enables proactive project management. Project risk management literature has focused much on delivery projects in different industries, of which construction industry is widely represented. This study posed a challenge for the risk management literature by attempting to apply it to research and development projects in a highly regulated and volatile pharmaceutical industry, in which projects are extremely long, complex, costly and prone to failure. The gap in the existing knowledge was addressed by the use of various sources of literature and empirical evidence from a case company in the pharmaceutical industry. The research question of this study is: how risks should be managed in practice in drug development projects. The research question is addressed by first conducting a literature study aiming at identifying distinctive characteristics of the pharmaceutical industry and drug development projects. Furthermore, the literature study consists of defining the concepts of risk and risk management and describing risk management processes, approaches, tools, and techniques. On the basis of the literature review, anticipated best practices for risk management in drug development projects are defined. The practical applicability of this model is then assessed in a case company. The case company is a North European pharmaceutical company focusing on developing drugs in three therapeutic areas. The research approach of this study is a combination of constructive and case study research. In the first phase of the literature study the pharmaceutical industry, drug development projects and their management were characterised. It was concluded that the industry is fragmented and the consumer of drugs is usually separated from the purchaser and the eventual decision maker. Patents and regulations also play an important role. Furthermore, the industry has faced a number of changes during the recent years: in the industrialised countries population is ageing and lifestyle expectations have risen; there are pressures for price reductions; generic drugs are used more; there is a constant flow of mergers and acquisitions in the industry; and technology and science advance with huge leaps. Drug development was found to be complex, long, resource-intensive and risky, especially for small firms. Thus, it is important to detect problems early to avoid waste of time and resources. Drug development projects consist of several sub-projects and the project organisation is multi-layered. The industry has been slow to implement project management, and the maturity of project management is at a low level. The
Hanna-Leena Saari
project teams also create easily a strong sense of ownership for their projects. Furthermore, in many pharmaceutical companies project managers have only an influencing role. In the second phase of the literature study risks and risk management were defined, and the benefits of risk management were outlined. Several processes were illustrated and a generic risk management process was proposed. The generic process made the feedback loop from monitoring and control to risk management planning explicit, and we also introduced a phase for risk management closing as a part of this process. Several tools were presented for each phase. Finally, important aspects for risk management were presented, such as hard and soft risk management, risk knowledge management and risk management as team work. The reviewed literature discussing risk management and drug development projects focused mainly on business level or portfolio level risks. Thus, a new framework for managing risks in drug development projects was developed together with a categorisation of pharmaceutical risks as based on the reviewed literature. It was concluded that initial risk analysis should be performed already before starting project planning. Project planning in itself is a laborious task in the industry. In addition, communication and knowledge management together with team-based working were seen to be important. Qualitative risk management methods should suit the industrys needs also for companies with a rather low level of project management maturity. The risk management framework derived from the literature analysis was applied in the case company. The proposed process was first refined to suit the needs of one therapy area. The generalisation of the process to other therapy areas of the case company was rather straightforward. However, the adoption of the literature-based suggestion of a proposed set of tools proved to be somewhat more difficult. The tools were considered as applicable, but the use of the whole tool set may be too resource-intensive to be implemented as such. This occurs even though the suggestion was focused on the use of rather qualitative methods with regard to available literature. This study contributes to the present theoretical risk management knowledge by adding one application to one new empirical application area. In addition, the study provides a starting point for additional studies of the subject and highlights the need for further studies in the risk management field of research. As a conclusion, we stated that risk management in drug development projects is somewhat different than in other industries. This occurs because of the special characteristics of the industry and its projects. To account for these, risk management should be rather qualitative, teambased and much focus should be placed on communication and knowledge management. This study suggests further research to test the developed risk management framework in practice. The general risk management theory needs to be studied further: the longHanna-Leena Saari
term applicability and effectiveness of the methods and tools presented in literature should be studied in different application areas. The purpose would be to recognise which methods and tools would suit best in which application areas. Several implications for managers of pharmaceutical companies can be derived from the study. First, there is a challenge for the entire industry to promote and implement systematic risk management in drug development projects with top management being the main change agent. Communication, openness and interproject learning must also be fostered throughout the pharmaceutical companies, which may relate to changes in organisational culture and climate.
Hanna-Leena Saari
1. INTRODUCTION 1.1. Background and Motivation
Pharmaceutical industry is changing rapidly. Markets are growing and consolidating with constant mergers of big conglomerates. To be able to respond to the changing requirements and increasing competition, networking is essential for survival. Biotechnology is growing in importance. Thus, research and development needs to increase its productivity because markets are becoming more price-sensitive. Also, legislation imposes new challenges for the industry. To remain competitive, companies have to be specialised, fast and flexible. Therefore, project management in new product development must be efficient and effective, and risk management can no longer be forgotten. Research and development activities are by nature very risky: when the objective of work is to develop something new there are always a number of uncertainties present. Even though risk management cannot guarantee the successful launch of new products, it is widely recognised as an essential tool to manage research and development projects. Risk management has also been identified as a knowledge area of project management further emphasising the importance of taking risks into account in all endeavours. The motivation for developing a structured risk management process is based on the awareness that effective risk management enables proactive project management. It would be possible to tackle problems already before they materialise and thus avoid or minimise their negative consequences for project progress and outcomes. However, to gain full potential of managing risks, the process has to fit the organisational context and the special requirements of the pharmaceutical industry. Additionally, effective tools must be developed that suit the process and enable its implementation. Project risk management literature has focused much on delivery projects in different industries of which construction industry is widely represented. This study poses a challenge for the risk management literature by attempting to apply it to research and development projects in a highly regulated and volatile industry in which projects are extremely long, complex, costly and probability of failure is high. The gap in the existing knowledge is addressed by the use of various sources of literature and empirical evidence from a case company in the pharmaceutical industry. 1.2. Research Question and Objectives
The research question in this study is: How should risks be managed in practice in drug development projects?
Hanna-Leena Saari
The aim of this study is to investigate project risk management in drug development projects from a very practical viewpoint. Thus, it is considered what kind of activities should be conducted when managing risks, i.e. the risk management process, and what kinds of tools and techniques exist to support risk management. Both of these aspects are discussed in the context of drug development projects. To be able to answer the research question, several objectives need to be fulfilled. The objective of the study is to: Identify the distinctive characteristics of the pharmaceutical industry and drug development projects. Define the concepts project risk and project risk management. Describe different risk management processes, approaches, and assisting tools and techniques. On the basis of the previous objectives, define the best practices of managing risks in drug development projects. Apply this knowledge in drug development projects of a case company by creating a risk management framework consisting of a risk management process description and tools and techniques customised for the case companys requirements.

The main focus of this study is to develop the risk management process for drug development projects. Risk management tools to be used with the process need to be identified to enable the implementation of the process. Figure 1 illustrates the logical flow of research objectives that aim at solving the research problem presented at the top of the figure.
How should risks be managed in practise in drug development projects?
Distinctive characteristics of pharmaceutical industry and drug development projects
Best practises for managing risks in drug development projects
Risk management framework for the case companys drug development projects
Definition of project risks and risk management
Risk management processes, approaches, and tools and techniques
Figure 1. Research problem and objectives of the study
Hanna-Leena Saari
1.3.
Research Scope
As already specified by the research question, this study concentrates on drug development projects, i.e. pharmaceutical research and development projects. For example, product support projects and further development of formulations are excluded from the study. Both risks and risk management are in the focus of the study in the context of the drug development project. However, to understand the projects, organisation, company and environment must be analysed in proper detail. Concentrating on projects means that risk management at subproject, program or portfolio-levels will not be fully addressed in this study. In addition, it should be noted that risk management tools stand for those methods and techniques that can be used to implement the risk management process. Software tools may thus be a part of or a way to implement these techniques, but software programs as such are out of the scope of this study. In this study, a project point-of-view for risk management is taken thus ruling out investment and financing-based risk management. Some other issues, such as project portfolio management and knowledge management are introduced in conjunction with risk management. It is assumed that the reader is familiar with these concepts and they are not explored in detail. Additionally, new product development and project management are introduced very briefly in chapter 2 with the intention to only define the setting in which the research is located. 1.4. Research Approach and Methods
The research approach of this study is a combination of constructive and case study research. A construct is formed on the basis of literature study. However, within this study, the construct is not implemented in practice and thus empirical validation will not be obtained. The practical applicability of the construct is still assessed with empirical information from a case company operating in the target industry and thus case study research is used (Uusitalo 1991: 75, and Jrvenp and Kosonen 1999: 19). The aim of this study is not so much on creating new scientific knowledge but rather on forming a construct that is applicable in practice and at the same time increasing theoretical understanding on the research subject. The research will use a combination of literature study and an empirical case study as research methods. Literature is first reviewed to form a thorough picture of the problem area. The aim of the literature study is to gain understanding of current practices of project risk management with their advantages and disadvantages and form hypothesis on what kind of process and tools should be used in the specific context of drug development projects. After that, this knowledge is applied in practice in a case
Hanna-Leena Saari
company operating in the pharmaceutical industry. The case company represents a volatile industry that is dependent on its environment. The competitive situation is difficult and governments regulate the industry tightly. Additionally, drug development projects are longer, more complex and regulated than the projects on which most risk management research focuses. The pharmaceutical industry and drug development projects thus pose a challenge for traditional risk management theory and are a valuable object of study. Literature used in gaining proper understanding of the existing theory will represent several different knowledge areas. First, general project management literature will be reviewed to comprehend the status and importance of risk management in project management and in managing business by projects. Literature concerning project risk management will be the main source of information to solve the research problem and the objectives of the study. To understand the special features of drug development projects, literature describing them will be studied, too. This clarifies the challenges that risk management in this kind of projects has to cope with. Last, internal documents of the case company will be used to gain insight of the special environment of the organisation for which the process requirements and tools were designed. Figure 2 presents a view of the research methods used in the study. It illustrates in detail what kind of information was gathered with different methods to fulfil the objectives of the study and through them answer the research problem. Literature study will provide answers to the first three study objectives, i.e. identifying distinctive characteristics of pharmaceutical industry and drug development projects, defining the concepts of project risks and risk management, and outlining risk management processes, tools and techniques. The requirements of the risk management process for the case company will be developed with the help of two-staged interviews. The first interviews will aim at scanning the process requirements and formulating the process for one specific set of projects. These interviews will be semi-structured. The issues discussed during the interviews are presented in Appendix 1. The next interviews will elaborate the suitability of the process to other project settings and will be performed as open-ended interviews. In formulating and refining the process at first, a workshop with all the interviewees is needed. Risk management tools will be developed with the help of a workshop with program leaders and project managers. However, initial selection of risk management tools will be done on the basis of the literature study.
Hanna-Leena Saari

How should risks be managed in practice in drug development projects? Distinctive characteristics of pharmaceutical industry and drug development projects Risk management processes, and tools and techniques Definition of project risks and risk management
Literature
Literature
Best practices for risk management in drug development projects
Literature
Risk management process description
Interviews Workshop
Requirements of the process Finalising the process description, validation
Risk management tools and techniques
Literature Workshop
Initial tool selection Final selection and development of tools
Figure 2. Role of research methods in answering to the research problem
In this study sampling for the interviews and workshops is purposive to guarantee that all relevant parties have representation in data gathering. Interviews will be focused. In total 22 interviews and two workshops will be held. The purpose of the two-staged interviews is to guarantee that at least one project setting is studied in proper detail. The interviewees at the first stage include business unit head, program leader, project managers, and project team members of most important line organisations representing the selected project setting. At the second stage program leaders and project managers of other project sets are interviewed. A more detailed description of the interviewees and workshop participants is provided in Appendix 2. 1.5. Structure and Content of the Study
The study objectives and their relation to the chapters of this study are presented in Figure 3. After this introductory chapter, chapter two concentrates on presenting the overall setting of this study by exploring innovation management and new product development together with project management. The chapter aims at answering the first study objective, i.e. defining the distinctive characteristics of pharmaceutical industry and drug development projects. Furthermore, project management and role of project managers are explored. Chapter three focuses on risk management and aims at fulfilling the next two study objectives. The concepts of risk and risk management are first defined. Additionally, benefits of risk management are outlined. Next, several risk management processes are presented and a generic risk management process is developed. On the basis of that, all phases of the generic risk management process are discussed outlining their content and tools that can be used in the phase. Risk management is also examined at different
Hanna-Leena Saari
project life-cycle stages. Important different views to risk management are then presented to deepen the understanding of the practice. These views comprise of issues such as risk management at different organisational levels, hard and soft risk management, the role of risk knowledge management and risk management as team work. The chapter ends with a review of results from studies describing how risks are actually managed in companies. Chapter four concludes the literature study of the previous chapters by presenting a synthesis of these two literature streams as a recommendation for best practices of risk management for drug development projects. Additionally, a risk categorisation model for drug development projects is presented. This chapter also aims at fulfilling the fourth study objective. Chapter five begins the empirical part of this study by presenting the case company and its drug development projects. In chapter six, the results of the interviews and workshops are reported and the best practice model is developed to suit the case company and its projects. The literature study and empirical study are compared in chapter seven and their differences are examined. Conclusions are also drawn and managerial implications of the study presented. Furthermore, the theoretical and empirical contribution of the study is assessed together with the validity, reliability and generalizability of the research approach and results. Finally, recommendations for further studies are presented.
Chapter 7
How should risks be managed in practise in drug development projects?
Distinctive characteristics of pharmaceutical industry and drug development projects
Chapter 2
Risk management processes, approaches, and tools and techniques
Best practises for managing risks in drug development projects
Definition of project risks and risk management
Chapter 4
Chapters 5 and 6
Chapter 3
Figure 3. The structure of the study in comparison with study objectives
Hanna-Leena Saari
2. PHARMACEUTICAL INDUSTRY AND ITS NEW PRODUCT DEVELOPMENT PROJECTS Innovation is the life-blood of organisations: only by renewing themselves and developing new products organisations can stay competitive in the ever-changing business environment. Projects are often used to implement new product development. Both of these concepts are highly future-oriented and thus they are both uncertain in nature. At present, also the pharmaceutical industry is facing a period of changes both in structural and competitive aspects. Thus, more pressures are imposed on drug development projects: their project and risk management must be of good quality to be able to compete successfully. This chapter is devoted to presenting the pharmaceutical industry and its new product development projects. It also aims at setting the ground for the rest of this study by presenting the concepts of innovation management, new product development, and project management. The role of risk management is highlighted both in new product development and project management discussions. Furthermore, project management practices in pharmaceutical projects are discussed considering their relationship to general project management practices. The emphasis of this chapter is to outline the distinctive characteristics of the pharmaceutical industry and drug development projects that have to be taken into account when developing risk management practices, i.e. to fulfil the first study objective. Each section of this chapter is concluded with a table gathering the main distinctive features discussed in the section. 2.1. Description of the Pharmaceutical Industry
Pharmaceutical industry differs from most other industries in its structure, intellectual property rights, regulations and R&D intensiveness. Recent changes have also affected all of the abovementioned topics thus reforming the entire industry and and making it even more challenging as an environment, see Figure 4. These issues and their significance is discussed next.
Hanna-Leena Saari
Industry structure
R&D intensiveness
Special characteristics of the pharmaceutical industry
Intellectual property rights Recent changes
Regulations
Figure 4. Special characterictics of the pharmaceutical industry
2.1.1. Industry Structure

The pharmaceutical industry is highly fragmented. There are hundreds of companies competing in the industry that has been divided into more than twenty therapeutic areas. (Fagan and Hayes 1998: 2). These form separate sub-markets that are dominated by only few products and their manufacturers. This domination enables the manufacturers to set high prices for their products and gain above-normal profits. (Craig and Malek 1995: 319). Many companies have spread their business risk between drugs and also between therapeutic areas (Senn 1998: 253). Companies are very vulnerable, however, because even the top companies rely on the sales of only five products (Craig and Malek 1995: 319). The main feature of the demand for pharmaceutical products is the separation of the consumer, purchaser and decision-maker. Drugs can be purchased either directly by the patient or the physician prescribes them. The physicians make the decision regarding what drugs they prescribe usually on the basis of the drugs safety, efficacy and quality. In the end most drugs are paid by insurance companies or governments. The end result of this separation is that the demand is price-inelastic, i.e. the price of the product does not affect the purchasing decisions much. (Craig and Malek 1995: 311-313 and Trott 2002: 401). Price controls imposed by the governments for the pharmaceutical industry have restricted the pricing of drugs, however. Price controls have been established during a change of healthcare policies all around the world. (Halliday et al. 1997: 64). One form of price control is generic substitution that allows a pharmacy to sell to the patient an equivalent but cheaper drug than the one that the physician prescribed (Sosiaali- ja terveysministeri 2002: 8-10).
Hanna-Leena Saari
2.1.2. Recent Changes in the Industry

An ageing population with a greater emphasis on quality of life and higher lifestyle expectations create new opportunities for the pharmaceutical industry. Also, in the future there will be more diseases that require treatment. (Arlington 2000: 76). On the other hand, there are pressures to reduce the healthcare costs and thus the use of generic drugs has increased, because the generic drug usually costs 30-90% less than the patented drug (Jacob and Kwak 2003: 292 and Fagan and Hayes 1998: 2). Simultaneously, also the time to develop new drugs has increased contributing to the shortening of the drugs patent-life. This is mainly due to increased regulations that have been formed to respond to the changing medication usage, e.g. the increased treatment of chronic diseases. (Agnew 2000: 1953). Additionally, many people use several different drugs at the same time forcing the new drugs to be tested to eliminate harmful drug interactions. It is also more difficult to get the sales permission nowadays: many drugs that were sold twenty years ago would not be acceptable anymore. (Jacob and Kwak 2003: 292). As a response to the longer development times, increased costs, shortened patent lives and increased competition, pharmaceutical companies realised that they must do more and better research, and the company with the biggest investment possibilities was considered to perform best (Jacob and Kwak 2003: 292-293). Because the fastest way to achieve more drug development capacity is to merge, the industry has witnessed a constant flow of acquisitions and mergers during the past years (Agnew 2000: 1952). At present there are four pharmaceutical companies in the list of twenty biggest companies in the world (Katajamki 2003). As the new conglomerates undoubtedly have more resources to spend in drug development they have the opportunity to be faster and more effective in bringing new drugs into markets. The challenge lies in being able to move quickly and exploit the rapidly advancing technologies, such as combinatorial chemistry, high throughput screening, molecular genetics, and stem cells. Also, to sustain acceptable growth the new conglomerates need to launch at least four or five new drugs each year. So far many of the companies have fallen behind of this target. (Jacob and Kwak 2003: 292-293). In addition to mergers facilitating drug development also other kinds of partnering agreements have become common. New technologies are sought through licensing, joint ventures, R&D contracts etc. (Fagan and Hayes 1998: 5, 8).
2.1.3. Intellectual Property Rights and Regulations

As described in the previous sections, the patent system of the pharmaceutical industry is a major distinction from other industries. This issue is also under lot of change pressures. The patent gives an exclusivity to sell a certain product for a specific amount of time, but other products treating the same disease can also be on the market. Thus,
Hanna-Leena Saari
10
the industry representatives state that the manufacturer of the patented drug does not enjoy a monopoly position. (PhRMA 2002: 31). Even though the patent-time for new products is 20 years in the USA, the effective life of the patent is only eleven or twelve years, because of the lengthy drug development process (PhRMA 2003: 58). Critics of the patent system state, however, that drug manufacturers charge monopoly prices for their new products (Trott 2002: 398). In fact, the congress of the USA has proposed weakening the patent protection of pharmaceuticals. This poses a requirement for the industry to convince the governments of its pricing decisions. Furthermore, it must show how R&D in pharmaceuticals is different from other industries where competition is the main driver of innovation and price cuts. (Trott 2002: 399, 401). The industrys will to defend the current patent system is understandable. Sales diminish after patent expiration, while the drugs market share falls typically approximately 85%. At present, the principal forms of protection from the attack of generic drugs are brand development, i.e. extensive marketing, and further research to develop the product enough to get a new patent. (Blau et al. 2000: 660 and Trott 2002: 384-385). In addition to intellectual property rights, the tight regulations distinguish the pharmaceutical industry from other industries. Government authorities control the development and sales of drugs in order to avoid hazards in which drugs have proved to be dangerous when used. All companies must apply for a marketing authorisation for each new pharmaceutical product they want to launch. To get this authorisation, certain trials have had to be done with certain results. At present, in addition to safety and efficacy, the drug must also be cost-effective to get the marketing authorisation. (Craig and Malek 1995: 331, 333). A delay in the marketing authorisation is expensive: it has been calculated that a one day delay may cost as much as one million USD in lost sales for a blockbuster drug (Fagan and Hayes 1998: 4).
2.1.4. Importance of Research and Development

Research and development is vital for success also in the pharmaceutical industry, where innovation is said to be the major factor of economic growth (Craig and Malek 1995: 313). Trott (2002: 72) categorises the pharmaceutical companies to be science-based firms where science and technology developed in own R&D departments have proved to be a major contributor to the companys growth and success. Additionally, pharmaceutical industry is one of the few sectors still often following the classical technology-push model of innovation where innovation starts from scientific research (Trott 2002: 339). This has now started to change, however, because of the more demanding competitive requirements. Investments in drug development have increased steadily and have almost doubled, being 17 billion USD in 1996 and 32 billion USD in 2002 (PhRMA 2003: 13). Anyhow, some critics have questioned the innovativeness of pharmaceutical companies. For
Hanna-Leena Saari
11
example, Angell (2000: 1903) argued that nowadays too many companies develop socalled me-too drugs that imitate a product already on markets but are different enough to be patentable. The rest of the differentiation is done with extensive marketing. It has also been argued that pharmaceutical companies spend more on marketing than on research: the less important the drug, the more it needs advertising (Angell 2000: 1903). For example, GlaxoSmithKline employs 10 000 scientists and 40 000 salespeople (Trott 2002: 401).
2.1.5. Summary: Special Characteristics of Pharmaceutical Industry

The pharmaceutical industry is characterised by its structure, demand patterns, patent system, stringent regulations, and importance of innovation together with the changes that have occurred recently. These special characteristics are summarised in Table 1. It is clear that the industry is different from other industries thus stressing the need to take these issues into account when developing risk management practices.
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 1. Special characteristics of the pharmaceutical industry Characteristic Industry structure Demand pattern Patent system Stringent regulations Importance of innovation Recent changes Fragmented industry: dominance in distinct therapy areas. Vulnerable, multinational companies. Extremely profitable compared to other industries. Price controls, differential pricing, barriers to entry. Separation of the consumer, purchaser and decision-maker. Derived and directed demand. Price-inelastic demand. Enables monopoly pricing. Safety, efficacy and cost-effectiveness requirements for marketing authorisation. Science-based firms. Firms still use classical technology-push model of innovation. Ageing population, great emphasis on quality of life, high lifestyle expectations. Price reduction pressures, pressures to reduce healthcare costs. Increased use of generic drugs, easier introduction of generic drugs. Increased regulatory requirements: drugs developed for chronic diseases for patients using many drugs at the same time. More difficult to get marketing authorisation. Increased development times. Reduced patent protection time. Consolidation, increased amount of partnering agreements. Technological and scientific advances.
12
2.2.
Drug Development: Process and Special Characteristics
In this section, the process of drug development is presented and the general statement of drug development being risky, long and costly is examined. New pharmaceutical products can be divided into four groups: new chemical entities, i.e. unique new products, duplicated products, compound products and alternative dosage forms of products. Most of the development investments are used in the development of new chemical entities. (Craig and Malek 1995: 323). This is also the product this study focuses on. Thus, drug development should henceforth be understood as the development of new chemical entities. However, innovation management and new product development are studied first at a general level to create the basis for further discussions concentrating on drug development.
Hanna-Leena Saari
13
2.2.1. Innovation Management and New Product Development

At present innovation is considered to be an important component of company success. Adapting to constantly changing business environment contributes to creating competitive advantage and is a factor of company survival (Tidd et al. 2001 and Trott 2002). In most industries dominant companies have been able to innovate. Innovations have also lead industrial revolutions and they contribute to the growth of companies and also entire economies. Interestingly, innovation can provide growth nearly regardless of the larger economic conditions. (Trott 2002: 4-5). Several different kinds of strategic advantages can be reached through innovation. For example, by developing a novel product or service, a company can offer something no one else can and be the first-mover. Also, with a novel process, operations can be more effective than competitors: faster, with lower costs, more customised etc. Sometimes innovation leads to rewriting the rules of competition making old products and services redundant. (Tidd et al. 2001: 7). Trott (2002: 12) defines innovation to be the management of all the activities involved in the process of idea generation, technology development, manufacturing and marketing of a new (or improved) product or manufacturing process or equipment. Thus, innovation is a management process with the output of a new product or process. There are also other types of innovations, such as organisational innovation, management innovation, production innovation, commercial/marketing innovation and service innovation (Trott 2002: 14). Innovations can be major, i.e. radical, or minor, i.e. incremental technological advances (Trott 2002: 13). Figure 5 presents Tidd et al.s (2001: 8) view of dimensions of innovation that captures the same idea.
Transformation Perceived extent of change
Radical
Incremental Product Service What is changed Process
Figure 5. Dimensions of innovation space (Tidd et al. 2001: 8)
Traditionally, innovation was thought to be a linear process beginning from research and development, then going into manufacturing and ending at marketing the product. This is referred to as technology-push model. Also, a view of the process starting from marketing and then going through research and development to manufacturing and end
Hanna-Leena Saari
14
users has been presented. This, on the other hand, is referred to as market-pull model. However, these models do not explain how innovation happens but they rather concentrate on what is innovations point of initiation. (Trott 2002: 17-18). The current understanding is that innovation takes place when organisations capabilities interact with science base and marketplace. Figure 6 presents the interactive model of innovation presented by Trott (2002: 19). The information flow is not necessarily linear and the marketplace and the science base interact with all functions and not just with R&D or marketing. Innovation can originate from any point in the model.
Latest sciences and technology Advances in society TECHNOLOGY PUSH
Idea
R&D
Manufacturing
Marketing
Commercial product
MARKET PULL
Needs in society and the marketplace
Figure 6. Interactive model of innovation (Trott 2002: 19)
The relationship between the terms innovation management and new product development is examined in the following. Trott (2002: 200) describes new product development to be an important part of innovation management. Innovation management concentrates on developing necessary conditions where innovation can occur while new product development is about transforming business opportunities into tangible products. On the other hand, the basic motivation for research is to generate these opportunities either in-house or by acquiring new technologies from external sources (Trott 2002: 291). There are many differences between the nature of research and new product development. Research is more risky and radical, and there are more projects and more freedom in strategic and operative terms. In new product development the technologies are more mature, objectives are clear and measurable, projects are bigger and methods more formal. (Martinsuo et al. 2003: 24-25). New product development provides the ground for long-term economic success, because it is the only way a firm can guarantee that its products are continuously better than its competitors products (Trott 2002: 201). Several different models have been developed for new product development. The simplest and oldest of these is the socalled departmental-stage model in which all departments, e.g. R&D, manufacturing and marketing, do their part of the work in isolation and then pass the project forward to the next department. Nowadays it is clear that this kind of a process hinders new product development with its restricted amount of communication and market input. Also activity-stage models are frequently discussed. These are quite similar to
Hanna-Leena Saari
15
departmental-stage models but focus more on activities and also facilitate iteration between activities. More recent developments of this model are concurrent engineering models where some activities are performed in parallel. The representative of most recent thinking is the network model of new product development. This model views new product development as a knowledge accumulation process where new knowledge is acquired from different departments and also from external sources. (Trott 2002: 215219). Innovation management poses a major challenge for managers: they need to create a balance between creativity and efficiency. Companies need to perform daily activities efficiently in order to be competitive today. On the other hand, to be competitive in the future they need to create new products and thus foster a creative environment enabling free flow of ideas. (Trott 2002: 65-66). Projects are often used as a way to structure new product development efforts to provide a solution for the dilemma. Project characteristics such as definitive start, objectives and end together with a restricted duration help the monitoring, managing and rewarding of new product development efforts. Projects also provide a flexible structure to cope with tough competition and changing business environment. (Martinsuo et al. 2003: 47). Certain factors have been presented in the literature that affect the success of new product development projects. Brown and Eisenhardt (1995) summarised earlier research conducted on the subject and concluded that process performance, i.e. speed and productivity of product development, is influenced by project team, project leader, senior management and suppliers. Product performance, i.e. products fit with companys competencies and market needs, is affected by project leader, customers and senior management. Furthermore, product and process performance in combination with a market that is large and growing and has low competition contribute to the financial success of the product. (Brown and Eisenhardt 1995: 366-372). Innovation is by nature risky business. It is a complex process that is highly oriented towards the future. Its essential objective is to develop new products with the results being always somewhat uncertain (Keizer et al. 2002: 213). Thus, a right attitude for risk is pivotal for successful innovation. Risks must be accepted in a sense that the company must be able to make risk-assessment decisions, and take calculated risks in a balanced manner. (Trott 2002: 66, 71). Risk management is also a determinant of successful new product development. In fact, one of the main tasks of new product development is to decrease the uncertainties in technologies and markets. (Martinsuo et al. 2003: 69-70). Early risk diagnosis and management is also essential to launch new products successfully (Keizer et al. 2002: 213). Nowadays, risk management is perceived as an important part of product innovation because of tough competition and severe consequences of failures (Halman and Keizer 1997: 204).
Hanna-Leena Saari
16
It can be concluded that innovation is a critical process for companies and that new product development can be managed by projects. For the new product development projects to be successful a good project team is needed with senior management support and supplier and customer involvement. Also, risk management is an essential contributor to new product development project success. However, before projects and risk management are examined in more detail, drug development and its special characteristics are presented based on this sections discussions.
2.2.2. Drug Development Process

There are three major steps in the life cycle of the pharmaceutical products: discovery, development and launch. The activities in the discovery step are so creative and complex that it is extremely hard to define all its stages. In this step the aim is to select the most promising compounds from the vast set of screened compounds. The selected compound is the one that best affects the target and has no obvious toxicological features. (Blau et al. 2000: 660). Regulations have such a huge impact on the next step, i.e. development, that different activities can be more easily described. Figure 7 depicts the drug development process starting from discovery. The description of different stages is combined from several sources (Blau 2000: 660, Halliday et al. 1997: 77, Kutzbach 1998: 54, PhRMA 2003: 3, Trott 2002: 339-342). It should be noted, however, that the model is an ideal and rather theoretical description of the situation. Normally, the phases are done somewhat concurrently and the complexity is increased by conducting several projects in parallel. Preclinical testing focuses on the preparation of the first human administration of the compound. Several studies are conducted in laboratories and with animals to predict what are the effects and side effects of the compound when it is given to humans. In addition, patent applications are important at this point to secure exclusivity when the drug reaches markets. When authorities grant the approval to treat first humans, clinical trials can begin, i.e. the drug can be given to humans. In Phase I studies the drug is given to approximately 20 to 80 healthy volunteers to test the drugs safety at a given dose level and to see how the human body reacts to the drug. Animal testing is also continued. If unacceptable behaviour is detected, the study may have to be terminated. In Phase II the drug is given to few hundreds of patients having the targeted disease. In these studies evidence for the drugs efficacy is looked for together with the determination of effective dosage and administration frequency. Animal testing continues with long-term toxicology studies. Pilot plant studies are conducted to be prepared to produce the drug in big enough quantities for the Phase III studies. Market research is also initiated. If the drug does not treat the disease or is inferior to competing products the development is frozen or the compound is taken back to
Hanna-Leena Saari
17
discovery for further refinement. If the drug proves to be effective, authorisation for starting Phase III studies is applied. Phase III trials focus on getting statistical verification of efficacy already discovered in Phase II studies. This is the most expensive part of drug development requiring thousands of patients and extensive global co-operation. The objective is that the administration of the drug is as similar as possible to the conditions in which the drug is used when it is on market. Regulatory authorities are involved in designing the studies and they can give benchmarks that would ascertain the approval of the drug. In addition to efficacy, drug-drug interactions are studied and comparisons with competing products will be carried out. Further evidence about the side effects, toxicity and general safety of the drug is searched for. Long-term toxicity studies go on together with production process optimisation, plant design and manufacturing site assessment. All results must be documented and if statistical proof is not gained, the project will be terminated. For the regulatory approval, all documentation must be gathered up and delivered to the authorities. The regulatory authorities have also posed questions and requests during the development and these must be answered. Marketing strategy is developed together with designing the promotional material and training the sales force. The commercial production facilities are built and price negotiations with suppliers and distributors are conducted. After the marketing approval is received, the product can be launched. When the product is on the market, so-called Phase IV studies are conducted to identify rare adverse events that were left unnoticed in Phase II and III studies. Furthermore, changes in the occurrence of known adverse events and new therapeutic indications are looked for. Usually, studies that support marketing are also conducted.
Hanna-Leena Saari

Discovery/ Preclinical Testing Laboratory and animal testing Phase I 20-80 volunteers used to determine safety and dosage Phase II 100-300 patient volunteers used to look for efficacy and side effects
18
Phase III 1000-5000 patient volunteers used to monitor adverse reactions to long-term use Regulatory review/ approval Additional postmarketing testing 0 4 8 Years 12 16
Figure 7. Drug development process (PhRMA 2003: 3)
2.2.3. Risk Level of Drug Development

As already discussed in section 2.1.3 the pharmaceutical industry justifies the patent system by stating that it is the only way that pharmaceutical companies can engage in the risky investment of developing new drugs. In this section the risk level of drug development is examined. The drug development process presented above is a stage-based process in which authorities determine in several points whether the development project can go on. At present it is somewhat difficult to get one product onto markets: of 5000 screened compounds at the discovery stage 250 move to preclinical tests. Only 5 of these compounds get into clinical testing and one gets the marketing approval from authorities. Thus, only 1 of 5000 screened compounds never reaches the markets. To make things even more complicated, only 30% of launched products ever achieve enough profits to pay back their development investment. Half of the money spent in development is spent in those products that never reach markets. (PhRMA 2003: 3-4 and Fagan and Hayes 1998: 3). Still, Angell (2000: 1902-1903) argues that for big companies drug development is not that risky because they have enough drugs in their pipeline to launch the needed amount of products. For smaller companies that can afford only few concurrent development projects, the development risks are considerably larger. To avoid major losses and delays back-up strategies and fallback options should always be planned. During the early stages of development it is also possible to do parallel research e.g. for different indications. (Kennedy 1998b: 11, 14). Toxicological and clinical studies have the biggest risk of undesired outcomes. While clinical studies account for approximately 40% of
Hanna-Leena Saari
19
total R&D costs it is important that all projects with poor prospects are eliminated as early as possible (Trott 2002: 341).
2.2.4. Complexity, Length and Cost of Drug Development

As one of the characteristics of drug development projects referred to very often, i.e. its riskiness, was already examined, in this section the statements that drug development is complex, long and costly are examined. Basically, drug development is more complex than new product development in other industries because there are many projects being conducted in parallel, the development is highly regulated, it takes an extremely long time to develop a product and a large amount of monetary and intellectual resources are involved. As outlined in section 2.2.2 in addition to the clinical studies there are also other studies and development efforts going on simultaneously. Animal testing continues throughout the development period. The drug must be developed into a form that is effective to manufacture and production plants must be designed and even built. Marketing strategies and campaigns must be planned already during development. Specialists of regulatory affairs must be continuously involved in the development effort, too. The time to bring a pharmaceutical product into markets has become longer mainly due to the transfer of developing drugs for chronic diseases requiring more clinical trials, more patients, and thus more time (PhRMA 2002: 18). As can be seen from Figure 8 especially the length of clinical trials has increased. PhRMA (2003: 2) estimates that the development of a new drug takes 10 to 15 years which is significantly longer than in many other industries.
Hanna-Leena Saari

Development Time (Years) 16 14 12 10 8 6 2,5 5,1 3,2 5,9 6,1 8,1 2,4 4,4 Approval Phase Clinical Phase Preclinical Phase 11,6 2,1 5,5 6,3 14,2 2,8 14,2 1,8
20
4 2 0
1960s
1970s
1980s
1990s
Figure 8. Total drug development time from synthesis to marketing approval (PhRMA 2002: 19)
Drug development has increased in complexity because the tools used and target diseases have become more complex (PhRMA 2003: 3). This complexity and increased time used in development has induced a rise in costs. According to Arlington (2000: 80) the amount of clinical studies has risen from 36 in 1991 to 68 in 1995. Furthermore, average number of assessments per trial has doubled and so has the needed amount of patients. The risk of failure has also an effect on costs: the R&D costs of failed development projects must be covered by a few very successful products (PhRMA 2002: 20). When expenses of project failures have been included, the cost of developing a new drug was calculated to be 802 MUSD in 2000 while in 1987 the figure was 231 MUSD and 54 MUSD in 1976 (PhRMA 2002: 21). The amount spent in drug development has also risen significantly: during 1993-2000 top 20 companies increased R&D investments on average by 10% a year in nominal terms. Partly this rise comes from the fact that there are more drugs in the pipelines at the moment. Still, output is less than one new drug per company per year. (Arlington 2000: 74). The pharmaceutical industry is thus facing a challenge to increase the quality and amount of new products to sustain growth. For example, developing me-too drugs, see section 2.1.4, can be regarded as ineffective use of resources (Craig and Malek 1995: 314). Moreover, intellectual resources are a critical part of drug development: staff costs account for a significant portion of R&D costs. One critical task is also to obtain and retain high quality staff and make sure that their knowledge is up-to-date. (Halliday et al. 1997: 73).
Hanna-Leena Saari
21
2.2.5. Summary: Special Characteristics of Drug Development

The drug development projects are characterised by the level of risk, complexity, length, costs and intellectual resources required in developing new products. These special characteristics are summarised in Table 2. Some of these are the same as the industry characteristics outlined before. These issues highlight the need for effective risk management and must be taken into account during its development.
Table 2. Special characteristics of drug development projects Characteristic Risk level Complexity Length Resources Of 5000 screened compounds one product is launched. Of all launched products only 30% pay back the R&D investment of the project. Big companies have enough products in their pipeline to recover R&D costs. Smaller companies cannot afford to develop many drugs simultaneously, thus risks are higher. Many parallel projects. Highly regulated development. Length of development. Amount of resources needed. More complex tools and target diseases. It takes 10 to 15 years to develop a new drug. The cost of developing a new drug has risen from 54 MUSD in 1976 and 231 MUSD in 1987 to 802 MUSD in 2000. Increased R&D spending of 10% a year in top twenty companies. Output less than one completely new drug per year. Ineffective use of resources because of the development of me-too drugs. Cost of being late 1 billion USD per day. Staff costs account for a significant portion of R&D costs.
2.3.
Project Management in the Pharmaceutical Industry
Regarding the complex nature of drug development projects and the high cost of being late or failing, it would seem intuitive that project management would flourish in the pharmaceutical companies. However, the industry has been slow to implement project management practices and is thus behind other industries in this area (Jacob and Kwak 2003: 291 and Kennedy 1998a: iii). Still, the importance of project management is recognised: it is seen as a pivotal contributor to getting products on market and achieving excellence in drug development (Kennedy 1998a: iii and Elliott 2000: 42) and more emphasis is being placed on the application and development of project management practices. As in the previous section, projects and project management are
Hanna-Leena Saari
22
discussed at a general level first before concentrating on the special characteristics of project management in the pharmaceutical industry.
2.3.1. Projects and Project Management

A project is a temporary endeavour undertaken to create a unique product or service (Project Management Institute 2000: 4). Projects have a definitive start and end and their end products should be different from other products and services. Many organisations use projects to do those activities that cannot be performed with normal operations or processes. (Project Management Institute 2000: 4). By definition, as projects are unique, there is more uncertainty and thus also risk in project-oriented work compared to normal operations. Turner (1999: 35) states that organisations use projects when their business objectives are achieved more effectively by projects i.e. when benefits are bigger than the risk associated with the work. Changes in business environment have promoted the use of projects. Rapid technological change has made the future of businesses unpredictable, globalisation has changed market structures and deregulation has transformed industry structures (Artto 2001: 14). Organisational structures need to be flexible to enable fast responses to changes and projects are one popular way to create flexibility in organisations. (Martinsuo et al. 2003: 10). In addition, in a networked business environment, projects support knowledge-intensive operations that nowadays form the core of many organisations (Artto 2001: 5). Projects can be divided roughly into two groups: external and internal projects. For example, R&D, internal development, change and reengineering projects represent internal projects while external customer delivery projects are external projects. (Artto 2001: 6). All these projects are different in nature and their special features must be taken into account when managing projects. For example, Turner (1999: 25-26) has presented a classification that distinguishes four project types according to how well project goals are defined and how well the working methods used for reaching the goals are defined, see Figure 9. Turner also suggests that when goals and methods are well defined the chance of success increases while the chance of success is smaller when goals and methods are not well defined. New product development projects are located in the upper left quadrant while research projects are situated in the upper right corner of the figure.
Hanna-Leena Saari
23
Type 2 Projects Product development Water Work methods well defined Yes
ce an ch ss r e e t ea ucc Gr of s
Type 4 Projects Research and organisational change Air Type 3 Projects Systems development Fire
No
e nc ha r c ure e t ea ai l Gr of f
Type 1 Projects Engineering
Earth
Yes
No Project goals well defined
Figure 9. Goals and methods matrix (Turner 1999: 26)
Projects can be defined to consist of four stages: proposal and initiation, design and appraisal, execution and control, and finalisation and closing (Turner 1999: 11). On the other hand Project Management Institute (2000: 30) defines these steps to be also management process groups that appear at all project life-cycle stages. After each stage a tangible product should be completed, for example feasibility study or prototype. All stages start with initiation and planning and move through execution and control to closing. After each stage there is a review of project performance and deliverables, and it is determined whether the project should continue to the next stage. (Project Management Institute 2000: 11). Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. (Project Management Institute 2000: 6). A project manager must concentrate on the special feature of projects, on managing people, and on the desired results (Turner 1999: 4-7). Project management can be seen to consist of different knowledge areas and processes, see Table 3. They are all highly interconnected, some dealing with performing project work and some supporting the work. (Project Management Institute 2000: 8).
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 3. Project management knowledge areas (Project Management Institute 2000: 8) Project management knowledge areas Project integration management Project scope management Project time management Project cost management Project quality management Project human resource management Project communications management Project risk management Project procurement management
24
Risk management is one of the knowledge areas, but its importance is great in completing projects successfully mainly because of the inherent uncertainty prevalent in them. Turner (1999: 229) states that risk management is the essence of project management. Also, in Arttos (2001: 14) opinion risk management is a vital function of project management. The importance of risk management has grown lately, because of the increased uncertainty in doing business and risk managements potential value for business. Programs and their management represent a further consideration of project management. A program is defined to be a group of related projects managed in a coordinated way. Programs usually include an element of ongoing work. (Project Management Institute 2000: 204). Many methods and tools that are used in project management are also used when managing programs. There are, however, slight differences in the focus areas and importance of the methods.
2.3.2. Drug Development as a Project

Pharmaceutical projects are huge in terms of money and time consumed, and human resources required. In fact, a drug development project constitutes of managing many sub-projects performed by different line organisations such as the preclinical studies, clinical studies, process development, and marketing planning. Even most of single studies would be regarded as big projects in other industries. Thus, the drug development project could also be viewed as a program. (Lead 2000: 149). Features of drug development projects are examined with the help of project problems, i.e. by discussing what are the main reasons for difficulties in these projects. In fact, the present understanding is that project problems should be detected as early as possible and that it is an achievement and not a failure to terminate a project early (Kennedy
Hanna-Leena Saari
25
1998b: 21). According to Lead (2000: 208-212) there are four main causes for project problems: poor resource management, poor project management, insufficient scientific experience, and unexpected and difficult technical issues. First, insufficient resources can lead to several problems in executing a project. For example, poor resource management can cause inadequate planning, starting activities too late, corner cutting leading to repetition of tasks, poor quality and mistakes under too much pressure, and overwork resulting in reduced morale and personal commitment. (Lead 2000: 208-210). Second, problems from poor project management usually start from inadequate planning and communication. All project participants should understand who is responsible for each activity. Communication is also important between various departments engaged in the development so that no unnecessary delays are passed on to other departments. To avoid delays in authorisation processes, good knowledge of regulatory requirements is needed. Detection of early warning signals of problems starting to occur should be one of the main tasks in project management. (Lead 2000: 210-212). Third, insufficient scientific expertise is a serious problem. Inexperienced team members need proper support to plan trials adequately and interpret the results gained from the trials right. A failure in either of the tasks may result in repetition of activities. Fourth, unexpected technical problems can occur in every project no matter how well it was planned. Still, a good project manager can minimise the effects of these problems by early detection and good problem-solving skills. (Lead 2000: 212). On the other hand, Kennedy (1998b: 12-13) outlines technical reasons for project failures. As much as 46% of projects fail because of lack of efficacy. Animal toxicity and adverse effects in man account for the second biggest reasons for project failures. The reasons for project problems outlined above do not seem to be different from problems occurring in other industries. Thus, it could be concluded that pharmaceutical projects, even though long, risky and costly, do not differ too significantly from the general understanding of project nature. The importance of scientific knowledge and early detection of problems may be more significant, however, to avoid repeating expensive and long trials, and to terminate poor performing projects as early as possible.
2.3.3. Project Management in Drug Development Projects

Cooke-Davies and Azymanow (2003) studied the differences between project management maturity in the pharmaceutical industry and five other industries. Also, big and medium-sized pharmaceutical companies were compared with each other. The results showed that medium-sized companies perform better than bigger companies in three dimensions: strength of project vs. functional matrix, strength of project culture and organisational leadership. The main reason for this was stated as the closeness of the project management to senior management and the proximity of the upper
Hanna-Leena Saari
26
management, in time and hierarchy, to the management of drug development projects. However, big pharmaceutical companies scored better in matching the project team to project stage and type, and in the capability of project management staff. When pharmaceutical companies were compared to the industries from which project management practice once initiated, it was clear that these industries, i.e. defence and petrochemicals, performed better. However, the defence industry scored lower than medium-sized pharmaceutical companies in organisational leadership. (Cooke-Davies and Azymanow 2003: 476-477). Pharmaceutical companies were also compared to other industries with regard to project management maturity. On average, engineering-based industries of the study, i.e. telecommunications and construction, scored better than the pharmaceutical and financial services industries. Pharmaceutical companies performed lowest of all in the extent to which project information is centralised and under the projects control. Moreover, big pharmaceutical companies scored extremely low on organisational leadership compared to others. However, as the bright spots for the pharmaceutical industry, medium-sized companies scored second highest, right after construction, in the strength of the project matrix and the project culture. (Cooke-Davies and Azymanow 2003: 477-478). When thinking about the drug development projects as such, one of their major milestones is to get the marketing authorisation. Thus, it can be said that in addition to the drug itself a major end product of the project is the documentation for authorisation application. The target is moving constantly during the development time and thus it is difficult to make specific plans of how to reach the project objectives. Actually, the project team must be prepared to cope with constant changes and failures. Therefore, it is fair to state that planning is at the same time an extremely important and difficult part of project management in the pharmaceutical industry. A further complication is that even though time to market is usually the main objective, many of the critical development activities are incompressible. (Murphy 1989: 36-37). The opportunities to decrease development time by planning are thus limited. Clinical and toxicology studies are usually those determining the critical path of the project. On the other hand, regulatory guidelines facilitate the planning significantly by giving specific instruction on what studies need to be done and in which order to gain the required authorisations. (Kutzbach 1998: 53, 68). Rolling-wave planning principle is usually used so that only the next phase is planned in detail and the rest of the phases are planned in outline. Before moving to the next phase, detailed planning is conducted. Planning is a team effort with representatives from all line organisations involved in the project. (Kutzbach 1998: 71). Development strategies are directed by the target product profile determined at the beginning of the project. The target product profile is the specification of the product that is going to be
Hanna-Leena Saari
27
introduced into the market. It includes the required efficacy and side effect profile of the drug, how it should be supplied and used, in which patient groups, for what purpose, the time of market introduction and the cost of goods. (Kennedy 1998b: 2, 4). The project manager needs to have very good interpersonal, leadership and communication skills to manage the cross-functional project team. As the drug development projects last long, the project team develops a strong sense of ownership for the project and thus it may become extremely hard for them to detect and admit there are problems and to recommend project dropping. The project team is composed of individuals with narrow speciality areas, which makes it more difficult for them to communicate with each other and realise how the contributions of different line organisations fit together. The gaps between team members are further enlarged by the fact that historically R&D has been performed in an organisational structure based on strong functional lines. (Murphy 1989: 35-36). However, nowadays companies attempt to break down the functional barriers. It can be concluded that the project management practices are not significantly different from other industries. Project planning is perhaps somewhat different regarding its long timelines, amount of changes during the project and the tight regulatory requirements affecting the planning process. The technical uncertainty, however, poses a significant challenge for planning and monitoring practices in drug development projects. Furthermore, project management is less mature, especially in the big pharmaceutical companies, than in other industries.
2.3.4. Role of Project Manager

Because of the highly specialised skills required in the execution of project work, the project manager is responsible only for making sure that the skills within the project team are used and that a good plan for the project is developed (Kennedy 1998b: 3). Anyhow, the project manager is not a direct authority for the project team members but rather has an influencing role (Murphy 1989: 36). Project Management Institutes Pharmaceutical Special Interest Group reports interesting results regarding the role of project manager in a survey conducted within the member companies. According to the results, experienced project managers are mainly viewed as good technicians who can keep track of time and cost but who do not provide the leadership skills of communication and risk management. Additionally, experience in project management has mainly come from other industries. Practitioners in the industry still continue to believe project management is different in the pharmaceutical industry. (PMI Pharma SIG 2002: 6). Considering the important role of innovation and new product development for pharmaceutical companies and the risks inherent in the projects it seems surprising that project managers do not enjoy a privileged and recognised position of leading the most
Hanna-Leena Saari
28
vital long-term operations of the firm. Because of the great impact of drug development project success and failure for the long and short-term health of the company project managers could be empowered more to be able to ensure that enough suitable resources and senior management support are given to the project.
2.3.5. Summary: Special Characteristics of Projects and Project Management in Drug Development
The projects and project management in drug development are characterised by the special features of projects, project management and the role of project manager. These special characteristics are summarised in Table 4. It is clear that there is a lot to improve for the entire industry in this respect. The fact that project management has not been practised for long in the industry and that it is not that mature a discipline must be accounted for when developing risk management for the industry.
Table 4. Special characteristics of projects and project management in drug development Characteristic Projects Project Management Consist of several sub-projects. Technical uncertainty: lack of efficacy is the reason for 46% of project failures. Critical importance of scientific knowledge and early detection of problems. Industry has been slow to implement project management practices and is less mature in this respect. Medium-sized companies perform better than bigger ones by having a stronger project-orientation both organisationally and culturally and by having senior management more closely involved with project management. Many critical activities are incompressible. Regulatory guidelines facilitate project planning. Target product profiles. Project team develops a strong sense of ownership. Project team composed of individuals with narrow speciality areas. Not a direct authority, rather has an influencing role. Experienced project managers viewed as good technicians who can keep track of time and cost but who do not provide the leadership skills of communication and risk management. Experience in project management comes from outside of the pharmaceutical industry. Practitioners in the industry continue to believe project management is different in the pharmaceutical industry.
Role of project manager
Hanna-Leena Saari
29
3. PROJECT RISK MANAGEMENT In this chapter, project risk management is examined on the basis of general project risk management literature. A vast amount of literature is available discussing the topic. Most of this, however, concentrates on external delivery projects. The purpose of this chapter is to offer an overview of the concept and practice of risk management. Then, it should be possible to give a literature-based proposal of how risks should be managed in drug development projects. Risks and risk management are presented as concepts and their characteristics are outlined in the following section. In addition, the importance of risk management is discussed based on the reasons why risk management is practised and its benefits. This section aims at fulfilling the second study objective, i.e. defining risks and risk management. However, the subsequent sections examine the third study objective, i.e. describe risk management processes, tools and different approaches to the subject. In these sections, models for risk management suggested in the literature are presented and their similarities and differences are outlined. A generic process incorporating common aspects of the models is suggested and its different phases are discussed on the basis of literature. The tasks to be completed in each phase are described together with some tools facilitating the work. Risk management is also examined regarding different life-cycle stages of the project and the different priorities are highlighted. In addition, it is discussed when risk management should be started. Some important different approaches for risk management are presented then to provide a more in-depth view of the subject. For example, risk management is discussed in connection with different organisational levels and knowledge management. In addition, a notion of hard and soft risk management is introduced together with considerations of risk management as team work and its role in decision-making. Last, issues that have to be accounted for when designing and implementing a new risk management process is outlined and the way risks are managed at present is described. 3.1. Risks and Risk Management
The term risk is used often in everyday life, but its meaning may vary. The aim of this section is to lay ground for further discussion of risk management by defining and explaining the concepts of risk and risk management. Additionally, motivation for risk management is promoted.
3.1.1. Definition of Risk

A project is established when a company wants to exploit an opportunity that would be inefficient to deal with normal operations. While, by definition, each project is unique, some degree of uncertainty always exists. As uncertainty is a characteristic of projects, so
Hanna-Leena Saari
30
is risk. Risks are and always will be an essential part of project-oriented working. In effect, no one can avoid project risks. In todays business environment with rapid change and increased competition, companies have to be more prepared for risks and their management than before. (Wideman 1992: ii, I-1 and Raz et al. 2002 101-102). A lot of definitions have been presented for project risks. The main commonality between many of these definitions is that risks are uncertain events thus having a probabilistic dimension. On the other hand, the most prevalent difference is the positive aspect of risks. Basically, when things are uncertain, there is always a chance that things may go better or worse than expected. For example, an activity may take a longer or shorter time to complete than estimated in beforehand. An opportunity would be to exploit the quick completion of the task and by that finalising the project earlier than planned. A risk, on the other hand, would be the delay of the entire projects completion because of one task being late. In this study the basic meaning of risk is considered to be as Chapman and Wards (1997: 7) definition for risk, i.e. project risk is the implications of the existence of significant uncertainty about the level of project performance available. The relationship between risk and opportunity can be perceived as different from the traditional definition of risk used in finance. In the financial world, the more benefits one wants to gain, the more risk one must take. In contrast, in project risk management risks and opportunities are considered to be two possible outcomes of uncertainty. Amount of information and predictability affect the level of uncertainty in projects. (Pitknen 1999: 20-22). Whether considering risks or opportunities or both in risk management should not matter, while the tools used and underlying concepts should fundamentally be the same (Hillson 2002a: 236 and Ward and Chapman 2003: 101). Uncertainty can materialise in two distinct ways in projects: as uncertain values and uncertain events. Uncertain values are an outcome of the fact that estimations are always uncertain. Thus, for example cost or duration estimates can always vary more or less in either positive or negative directions. Uncertain events, on the other hand, represent uncertainty about what will happen. It is not always possible to know how things will turn out, even though it may be possible to construct scenarios describing different options. (Grey 1995: 18, 31, 41).
3.1.2. Risk Categorisations

The fundamental nature of risks can be further described by outlining different kinds of risks. Several categorisations are presented in the literature on the basis of risk source, effect of risk or level of control. There are usually interactions between the risks in different categories and one risk can affect or have a source in several categories. Turner (1999: 230-234) categorises risks according to their impact and where their control lies. There are two categories under the heading impact of the risk: business
Hanna-Leena Saari
31
risks and insurable risks. Business risks are uncertain values having both opportunity and risk sides while insurable risks only have a negative side. Control of risk can be either internal or external to the company or they can be legal risks. Internal risks include technical or non-technical risks and external risks can be predictable but uncertain or unpredictable. One further categorisation of uncertainties is to divide them into knowns, knownunknowns, and unknownunknowns. Knowns are things that are certain, such as death. Known-unknowns are uncertainties that can be identified but their effects are not known. Last, unknown-unknown is something that cannot be imagined, such as AIDS before the first case was reported. (Wideman 1992: III-2). Wideman (1992: III-3) presents a further division of risks based on their effect: scope risks, quality risks, schedule risks and cost risks. In addition, Frame (1994: 81) categorises risks according to functions: technical, market, financial, and human risks. Other risk divisions are presented in Table 5. All these categorisations lack one important source of uncertainty: assumptions. Especially implicit assumptions create a huge risk for the project if left unaddressed (Chapman and Ward 2002: 46). In fact, assumptions should be managed as risks (Royer 2000: 10).
Table 5. Examples of different kinds of risk categorisations Frame 1997: 23 Technical problems Incompetent staff Regulatory changes Changes in the players Actions of competitors Environmental traumas Poor time and cost estimates Pitknen 1999: 25-26 Project risks (macro-risks, contractual risks, financial risks and operational risks) Information risks (external information risks and internal information risks) Property risks Personnel risks Pitknen 1999: 23 Contractual/ environmental risks Management/ process risks Personnel risks Technical risks Keizer et al. 2002: 214 Technology Market Finance Operations
3.1.3. Definition of Risk Management

As for risks, several definitions of project risk management have been presented in the literature. The definition used in this study is adopted from Project Management Institute (2000: 127), i.e. risk management is the systematic process of identifying, analysing, and responding to project risk. The purpose of risk management is to
Hanna-Leena Saari
32
improve project performance by systematically identifying and assessing risks, developing strategies to reduce or avoid them and maximising opportunities. In effect, risk management is a creative and constructive process. (Chapman and Ward 1997: 9 and Wideman 1992: I-2). Actually, risk management is something that is done every day. When work is unfamiliar or complex and risks are hard to identify and assess, a need for an explicit process arises. In fact, even small or medium-sized projects can involve so much uncertainty that an unaided human cannot comprehend it all. (Grey 1995: xi, 2). As the definition implies, risk management should be a systematic process. Another distinctive characteristic of risk management is it being proactive, i.e. problems should be anticipated already before they materialise. Reactive risk management is often called as crisis management and it consists mainly of selecting suitable responses (Wideman 1992: I-5). Project risk management can also be considered to be an extension of project planning thus contributing to the reduction of crisis management (Chapman and Ward 1996: 12 and Khknen 1998: 190). The features of business and projects in question have an effect on how useful proactive risk management is. The higher the level of uniqueness and uncertainty and the larger the project, the more useful proactive risk management is. (Khknen 1998: 190). Grey (1995: ix-x) presents three different views of the relationship between project management and risk management. One view of risk management is that it is a part of project management, being the responsibility of the project manager or some team member. Opposite to this view is the idea that project managements main purpose is to manage risks, i.e. risk-driven project management. The third view is that risk management should encompass all project management activities but there are also tasks that could be left to consultants or specialists.
3.1.4. Importance of Risk Management

Several authors have listed benefits of risk management and also reasons for risk management being as popular a topic at present as it is. There are several reasons that increase the need for more systematic and effective approaches to risk management. Increasing global competition, more demanding customers, increasing pace of technological development and complexity of business opportunities, and reduced lifetimes of products have contributed to this. The fact that consequences of failure can be catastrophic today has affected this development, too, together with the existence of user-friendly risk management software and increased amount of education and training. (Chapman and Ward 1996: 12, Khknen 1997: 75, Frame 1997: 22). Especially the ability to diagnose and manage risks is increasingly considered as essential within innovation management (Keizer et al. 2002: 213). The main benefits of risk management found from literature are listed in Table 6.
Hanna-Leena Saari
33
Table 6. Summary of benefits of risk management (Chapman and Ward 1997: 41, 44-45, Grey 1995: 10-12, Simister 1994: 7, PMI RiskSIG 2002a: 5-6, Artto and Hawk 1999: 1, Raz et al. 2002: 108, Keizer et al. 2002: 220, Githens and Peterson 2001: 1,3) Benefits of risk management Project performance Increased understanding and consistent opinions More accurate plans Risk response plans Facilitates thinking processes and communication Documentation is a by-product Better chances of success. Avoidance of schedule and budget overruns. Reduced time-to-market and overall project cost. Senior managements improved understanding of trade-offs. Increased understanding and more realistic attitude to of the task. Mutual understanding and agreements of target values. Fewer unresolved issues in a plan subjected to risk analysis. Consistent opinions in a project team as a result from risk analysis. Allows the formulation of more realistic and accurate plans. Common planning focus for global cross-functional projects. Provides leverage on the front-end of a project and helps to avoid costly performance, cost and schedule problems downstream. Allows an assessment of contingencies that actually reflect risk. Establishment of risk response plans and control efforts while estimating risk magnitudes. Encourages project team to define the completion criteria of a project. Fosters critical thinking. Helps to overcome complexity: manageable pieces. Encourages creative and lateral thinking. Order-of-magnitude increases in communication. Breaks down functional and organisational barriers. Enlarges co-operation across group and company boundaries. Provides focus for the initial thinking process. Provides an unambiguous vehicle for communication. Provides a record to assist new project team member to get up to speed quickly. Provides a record that explains the rationale for key decisions and captures corporate knowledge in a manner useful for subsequent similar project teams.
At this point it should be clear what project risks and risk management are and why risks should be managed, i.e. the second study objective has been fulfilled. Risk management is examined in more detail in the following by presenting risk management processes, tools facilitating its implementation and different approaches to it.
Hanna-Leena Saari
34
3.2.
Risk Management Process
There is no single best risk management process that would suit all situations. Rather, a number of different kinds of processes and approaches have been presented in the literature. The process must be tailored to meet the requirements of the company in question. The issues affecting the choice of the process include the business environment and the size and complexity of the projects in question (Raz et al. 2002: 108). The purpose of this discussion is to outline what kinds of processes exist, develop a general framework and with its help present different kinds of tools that can be used to implement the process.
3.2.1. Different Models for Risk Management

Most of the models suggested for risk management include from three to nine phases. Even though they all represent more or less the same idea, the level of detail in what is included in the phases is different. The most common sequence of activities flows from risk management planning, risk identification and assessment to response planning and risk monitoring and control. The biggest differences discovered were whether some kind of planning is included in the process and how many different steps is taken in the assessment phase. Also, the degree to which the utilisation of experiences is stressed varies, for example, between Chapman and Wards and Project Management Institutes processes (Pitknen 1999: 42). Some examples of these kinds of processes are given in Table 7. Even though the phases may be named in different ways, the content of the phases may still be the same, in varying levels of detail, however. Furthermore, some activities may occur in different order in some models.
Table 7. Different risk management processes Turner 1999: 229 Project Management Institute 2000: 127 Risk management planning Risk identification Qualitative risk analysis Quantitative risk analysis Risk response planning Risk monitoring and control Chapman and Ward 1997: 50-51 Define Focus Identify Structure Ownership Estimate del Cao and de la Cruz 1998: 55 Project Process Identification Analysis Jordanger 2000: 94 Define objective, assumptions, constraints Identify and define relevant uncertainties Quantitative vs. qualitative assessment of probabilities and consequences Grouping of uncertainties Define management basis Project execution
Identify Assess
Evaluate Plan Manage
Evaluation Planning and immediate actions Monitoring and control Post-process learning
Develop strategies for mitigation Monitor and control
Hanna-Leena Saari
35
One further example would be Greys (1995: xii-xiii) suggestion for a risk management process. Otherwise it is similar to these, but the planning phase concentrates on identifying stakeholders and their success expectations so that the issues that might put the project success in danger can be identified. On the other hand, Chapman (2001: 149-159) presents a process in which a lot of emphasis is on selecting the team members and analysis tools for risk management, and educating team members in their use. Most of these processes are offered as generic solutions with little indication of where and when they should be used. Del Cao and de la Cruz (1998: 55) are an exception by implying that their process should be used in small and medium-sized projects with low and medium complexity levels. One further interesting detail is that it is also the only process suggesting that something should be done also after the project, i.e. postprocess learning phase, even though this seems quite natural and intuitive. The risk management process is continuous during the entire project life cycle. Therefore, some kind of repetition of the process is necessary. Of the models presented above only Chapman and Ward (1997) have explicitly defined their process to be iterative with the level of detail increasing with more iterations. This issue has also been discussed by Steyn (2002) and Buchan (1994). Steyn (2002: 79) presents a way to apply the Theory of Constraints (see e.g. Goldratt and Cox 1992) to risk management. The loop of control is an essential way to make sure that the process constraint, i.e. biggest risks, are known all the time even though risk mitigation activities are conducted and the project environment changes. Also Buchan (1994: 29) has addressed the continuity of risk management by stating that sooner or later the risk scope changes unless it is controlled. Then, the risk must be identified and assessed further. There has been some discussion about the relative importance of different phases. Elkjaer and Felding (1999: 16) state that risks must be identified and managed to enable their prevention. Even further, if risks are not identified, they cannot be managed thus giving greatest weigh to the risk identification phase (Chapman 2001: 147 and Peltonen et al. 2001a: 17). On the other hand, if it is considered important to have an accurate risk assessment, then risk identification and assessment have the most impact (Chapman 1998: 333). Artto (1997: 353) presents considerations on how risks should be managed if the assessment phase would be bypassed relying on the statement that risks can be affected by responses only. Anyhow, it can be concluded that if a phase was deemed to be useless, it would not have stayed in all these process descriptions. The assumption would thus be that all phases support equally but in different ways the overall goal of improving project performance. All the phases are examined next in more detail describing their content and the tools that can be used. The sections follow the phases of this studys proposition for a general risk management process depicted in Figure 10. The phases are the same as in the processes described above. There is, however, a loop back to risk management planning
Hanna-Leena Saari
36
from the monitoring and control phase. After the monitoring and control phase there is also a possibility to proceed to risk management closing, including all the activities completed when the project has ended. There is a decision point in the picture representing the possibility for two different ways to proceed.
Risk management plan Risk identification Risk assessment Risk response planning Monitoring and control
Risk management closing
Figure 10. Proposal for a generic risk management process
3.2.2. Risk Management Planning

The aim of risk management planning is to decide how risk management activities are approached in the project (Project Management Institute 2000: 129). Thus, it is a strategic, i.e. non-operative, activity covering the entire project from start until end (DeBakker et al. 2002: 1). Risk management planning is an important part of the project, while only then it can be ensured that risk management will be comparable to the risk level of the project (Project Management Institute 2000: 129). In fact, Hallman and Keizer (1997: 212) suggest that a quick risk scan should be performed before each project to determine what is the appropriate level of risk management required. During the planning phase the subject of risk management must be defined and scoped, and the management effort must be planned in terms of resources, timing, scope, methods used etc. The team responsible for risk management must also be assembled, responsibilities determined and participants motivated. (Peltonen et al. 2001a: 14). The reporting process must also be defined. In terms of methods used, metrics for risk assessment must be determined already in beforehand. In addition, project activities should be outlined at a high level encompassing approximately 20-50 activities to facilitate risk management. It is also useful to have a look at the company-level risks that may affect the project. The project manager and project team should not be responsible for managing these risks thus scoping the risk management of the project. (Chapman and Ward 1997: 87). Finally, to be able to define proper response strategies, a risk strategy must be defined. The response strategy depends naturally on the project and the risk, but still the choice should be based on clearly defined standards. (Wideman 1992: VI-1). As a result of the planning phase a risk management plan should be composed. An effective plan is said to be appropriate, affordable and achievable. That is, risk
Hanna-Leena Saari
37
management must suit the project, must not require too much resources and it must be possible to implement the plan (DeBakker 2002: 1). Table 8 represents a suggestion for the content of the risk management plan provided by Project Management Institute (2000: 130). For the budgeting of risk management, Royer (2000: 7) suggests that 5% of risk mitigation budget should be allocated to risk identification and monitoring. The list of contents provided should not be considered as complete or binding. Rather, every organisation should add things they perceive as necessary. For example, company risks affecting the project or the risk strategy adopted in the project might be listed already in this document.
Table 8. Contents of a risk management plan Project Management Institute (2000: 130) Risk management plan Methodology to be used in risk management. Roles and responsibilities. Budget for risk management of the project. Timing. Scoring and interpretation of qualitative and quantitative analyses. Thresholds for determining when actions must be taken. Reporting formats. Tracking.
3.2.3. Risk Identification

Risk identification aims at distinguishing the issues that may affect project outcomes and determining their characteristics (Project Management Institute 2000: 131). The idea is that those issues that have been anticipated in advance are easier to handle (Royer 2000: 6). Risk identification must be formal in a sense that all risks must be considered and not just those that are familiar or easy to manage (Chapman and Ward 2002: 168). In addition to risks, also triggers indicating the materialisation of a risk must be determined (Project Management Institute 2000: 133). The identified risks must be documented and it is important to be careful with the task: documented risk statements should be unambiguous and understandable. The format in which each risk must be stated can be defined in beforehand (Krogstie et al. 1999: 887). For example, a risk statement may be formatted as an if-then or a conditionconsequence expression (PMI RiskSIG 2002a: 9-10). Risks can be identified with the help of several techniques. Royer (2000: 7) has categorised these techniques to experience-based and brainstorming-based methods, while Chapman (2001: 149) distinguishes between interviews of individuals and
Hanna-Leena Saari
38
working-group techniques. The identification phase is very challenging because experience, creativity and imagination must be used for discovering all possible risks and at the same time the mindset must be extremely open for all kinds of suggestions so that all aspects and also difficult issues are addressed. Checklists and prompt lists are one of the most common tools in risk identification. They consist of the organisations knowledge of risks and opportunities (Artto et al. 2000: 27). While checklists include risk statements experienced or identified in previous projects categorised under several risk sources, prompt lists are composed of questions that aim at shaping the understanding of risks (Pitknen 1999: 30). There has been much debate about whether checklists are appropriate. The main issue is that even though it is extremely easy and intuitive to use, it can become limiting thus harming the quality of risk identification. More pros and cons of the technique are outlined in Table 21 in Appendix 3. Hillson (2002b) presents the concept of risk breakdown structure as support in structuring risk knowledge. He defines risk breakdown structure to be a source-oriented grouping of project risks that organises and defines the total risk exposure of a project. Each descending level represents an increasingly detailed definition of sources of risk to the project. As other breakdown structures used in project management, e.g. work breakdown structure, the risk breakdown structure would facilitate the comprehension of risks by structuring and organising them into manageable chunks of information. Other visual methods for identifying risks exist, too, such as cause-effect diagrams, flow charts and influence diagrams (e.g. Project Management Institute 2000: 133). Another main technique for risk identification is brainstorming, i.e. ideation in a group where the objective is to create as many suggestions as possible by using others ideas and allowing no criticism at first. Even though it is a popular method, it is not easy to make it work optimally. The outcome of brainstorming is affected by group composition considering, e.g. the background and status of participants. As the technique requires a different mindset than the daily operative work, the sessions need to be given a special title, held in a unique place or at a unique time. (Chapman 1998: 338). Chapman and Ward (1997: 120-121) state that brainstorming can even be too creative to be effective. However, there are several characteristics of the technique that are advantageous: involvement of individuals with variety of backgrounds, withholding judgement of identified risks, utilising the thoughts of others, and attempting to view the situation from unfamiliar perspectives. Advantages and disadvantages of brainstorming technique outlined in literature are presented in Table 21 in Appendix 3. Chapman (1998: 339-340) has presented Nominal Group Technique as an alternative for brainstorming. In fact, it has proved to perform better than brainstorming in creating more and better ideas more effectively. In the technique, ideas are written on paper and recorded on a flip chart after which they are discussed. This increases the level of individual participation as well as depersonalises problems by focusing on issues
Hanna-Leena Saari
39
and not people. The technique should work both in complex and simple projects and is simple in process terms (Githens and Peterson 2001: 4). Risks can also be identified by interviews or questionnaires. For example Elkington and Smallman (2002: 56) suggest the use of informal interviews to get everyone involved in the process. When experienced people are interviewed, their tacit knowledge about project risks can be utilised directly thus facilitating knowledge transfer from past project to the new ones (Pitknen 1999: 30). Past experiences and industry standards can also be used in designing questionnaires (Noor et al. 2002: R4.3). Decision-conferencing techniques (Chapman and Ward 1997: 121) and workshops (Pitknen 1999: 30) are often used as the venue for risk identification when working group techniques are used. These involve a creative atmosphere, use of a facilitator and oftentimes also real-time computer support. This support is needed especially if diagramming is used for facilitating the understanding of the relationships between risks and their causes and effects. For example, with flowcharts the actions and decision points of the project process can be illustrated and different alternatives indicated. Influence diagrams show causal influences, time ordering of events and also other relationships. Causal relations can also be depicted with cause-effect diagrams. (Project Management Institute 2000: 133 and Pitknen 1999: 30). All the techniques discussed above and also some other methods, such as the Delphi technique, are summarised in Appendix 3 together with their advantages and disadvantages.
3.2.4. Risk Assessment

In the assessment phase the identified risks are further analysed to determine their relative importance. This is defined by assessing the probability of the risk and its effect on project objectives if left unaddressed either with qualitative or quantitative techniques. The time-criticality of risks and how much it can be affected determine the importance of risks. After assessment risks can be prioritised and the probability of achieving project objectives can be stated more realistically. The main purpose of risk assessment is to know which risks are important to enable effective use of resources in response activities (Williams et al. 1997: 74 and Ward 1999a: 331). Project risks are usually assessed as a product of probability and impact thus forming the expected value of the risk. Contingency reserves can also be assigned on the basis of risk assessment. Qualitative and quantitative assessment can be done either simultaneously or separately. However, it may not always be necessary to use quantitative techniques, as will be discussed in section 3.3.7. (Project Management Institute 2000: 133, 137 and Chapman and Ward 1997: 50-51). The assessment should be started with the especially important issues so that they are elaborated thoroughly and that the motivation for the task endures. In this phase it should be considered, when in the project life cycle the risks materialise, i.e. their timeHanna-Leena Saari
40
criticality together with the risks probability and impact. In addition, a synthesis of individual assessments should be aggregated to form a big picture of the riskiness of the project and what the specific areas for concern are. (Chapman and Ward 1997). It is essential to consider also the joint effects of several risks as well as their individual contribution to the project success (Wideman 1992: II-2 and Elkington and Smallman 2002: 57). The utilisation of the knowledge of experienced people in the organisation and other project managers is vital in assessing risks (Elkington and Smallman 2002: 50). Klakegg et al. (1999: 919-920) remind that risk assessment sessions are not places for decision-making. Additionally, the process should be kept as depersonalised as possible so that the focus is on issues and not on people. Several tools have been suggested in the literature for risk assessment. Grey (1995: 4) distinguishes between issue-based techniques, scoring techniques and quantitative techniques. Moreover, risk assessment tools can be divided into individual interview-based and working group-based methods (Chapman 2001: 149). The main issues to be considered when selecting the techniques to be used is to make sure that it is not more complicated than necessary, does not require too much time and resources and are suitable to team-based working if that is used (Peltonen et al. 2001a: 15). Some qualitative assessment methods are described in the following and after that a few quantitative methods are presented. Qualitative assessment is often simpler than quantitative estimation. It is also easy to use and integrate with normal working practices. They can contribute to a better understanding of risks and thus facilitate decision-making on risk responses. (Khknen 2001: 2). The most basic approach for qualitative estimating is to verbally describe the effects and probability of the risk. In addition, ratings can be used to assess the risk. (Elkjaer and Felding 1999: 18). A very common way to rate probabilities and impacts is to give them a grade of low, medium, high or fatal, or numbers from 1-5 or 1-10 on the basis of a pre-defined ranking. These are very simple and intuitive practices and are often used. However, Chapman and Ward (1997: 167) stress the need for being explicit about the limits between the grades. Some examples of scales for assessment of impact, probability, level of control and manageability of risks are presented in Appendix 4. Even though the estimation is very imprecise, Elkington and Smallman (2002: 51) state that especially probability assessment is always more or less an educated guess, no matter how advanced tools one uses. Probability-impact matrices are a means to illustrate the probability and impact scales of low, medium and high, see Figure 11. Two suggestions for the usage of probabilityimpact matrices are presented in Appendix 5. There are two opposite opinions about this technique. Pinto (2002: 24), for example, considers probability-impact matrices to facilitate brainstorming of the project team about the most likely risks and to apply a simple formula to the risks. It is especially useful in team working and helps in creating a
Hanna-Leena Saari
41
shared understanding of the priority of various risks. However, the technique could be enhanced by adding a short written description about the reasoning behind the grade to facilitate communication and learning. (Khknen 1999: 3). Krogstie et al. (1999: 889) recommend also to use this kind of a simple matrix for communicating the risks between different organisational levels, i.e. to managers and to project workers.
High
Impact Medium
Low Low Medium High Probability
Figure 11. Example of a probability-impact matrix
However, as Rimpilinen and Peltonen (2000: 23) state, all projects may have to have different scale definitions depending on the project size and importance. This makes comparisons between projects difficult and even impossible at the portfolio level (Pinto 2002: 25). Several other shortcomings of the method have been outlined in the literature. First, the matrix does not allow any uncertainty of the estimates, forcing to a false sense of security (Chapman and ward 2002: 146-147). There is also a danger that after risks are assessed this harshly once, they are not revised during the project. The priority numbers given for the risks on the basis of probability and impact ranking have no absolute meaning creating more distortion than understanding. Sometimes these meaningless figures have been calculated together to form a measure of total project risk falsifying the analysis even more. To avoid using the risk priority numbers incorrectly, it is suggested that instead of numbers, priorities could be resembled with alphabetics (Ward 1999a: 332-333). In fact, Chapman and Ward (1997: 140) argue that using the probability-impact matrix gives the same information, only less effectively, as a rough categorisation of risks into major and minor risks. The information required to make assessment decisions can be gained either from interviewing experts and project stakeholders or discussing the risks as a team. In the interviews the objective can be to analyse risks using either qualitative or quantitative assessment methods (e.g. Chapman and Ward 1997: 180-186 and Pitknen 1999: 30, 34). In addition to risk identification, questionnaires can also be used to assess the impact and probability of risks. With this approach the flaw is that those risks that are not included in the questionnaire are not addressed leaving some possible additional risks unidentified. They can be used to get an overall view of the importance of the risk, as well as other qualitative methods. (Grey 1995: 7).
Hanna-Leena Saari
42
The simplest way to quantify risks is to assign a numerical value for their impact and probability. An expected value of the risk is then calculated. These 1-point estimates are easy to understand even though it is difficult to determine especially the probability as a specific number. (Khknen 1999: 3). Risk impact can usually be converted into monetary terms thus enabling comparison between risks and even projects (Pitknen 1999: 33). When risk impact and probability is known, decision trees can be constructed to illustrate the costs or rewards of flow of events or decisions. Then, the decision with greatest value can be calculated. (Project Management Institute 2000: 139). The problem of having to come to a specific probability value is avoided in so-called 3point estimates, where only the best, worst and most probable impacts are evaluated (Khknen 1999: 4). A weighed average can then be calculated: weighed average = (best case + 4 x most probable case + worst case)/6 (Project Management Institute 2000: 76). This technique for uncertainty estimation has been developed for complex and very uncertain projects with innovative contents. 3-point estimation helps to overcome the effects of too much optimism and lack of historical data. (Wideman 1992: IV-8). Furthermore, it is a computationally efficient assessment technique (Grey 1995: 28-29). However, even though there is no need to assess probabilities, the estimation of absolute maximum value of risk impact may be difficult or even impossible. Extreme values can also be significantly underestimated thus reducing the reliability of the assessment. (Chapman and Ward 1997: 174). Risks can be represented by probability distribution functions, such as Poisson, exponential, normal and beta distribution. Probability distribution modelling of risks can provide more precision for the assessment. However, too often this precision is false, because the initial data may be too vague to be fitted into a probability function or the assumptions behind the distributions do not hold. (Chapman and Ward 1997: 171-172). In fact, the use of probability distributions assumes randomness and repeatability of events, and does not take into account the limitations of human comprehension or flow of knowledge during the project (Pender 2001: 80). Probability distributions are not widely used, because they are perceived to unlink the assessment from every-day work of project managers (Khknen 1999: 4). The most often used simulation method for project risk analysis is the so-called Monte Carlo technique. In Monte Carlo simulation, all variables are modelled with value ranges and probability distributions. Then, numerous iterations are performed with variables ranging randomly within their probability distributions. As a result, the probability function of e.g. the total project duration is received. (Wideman 1992: C-3). Monte Carlo roots the model in the project plans and establishes a straightforward relationship between decisions and the model (Grey 1995: 129-130). The shortcomings of the technique arise from the difficulty of determining probability distributions and value ranges. Probability distributions do not always suit well to the situations and usually
Hanna-Leena Saari
43
there is not enough data to construct an own distribution. Moreover, the modelling of correlation between events is often not accurate. (Conrow 1997: 4-6). These assessment tools and some others, such as sensitivity analysis, are presented in Appendix 6 together with their advantages and disadvantages. The tools need to be used with care acknowledging their underlying assumptions and flaws. Assessments are always subjective estimates and to ensure their reliability honesty must be guaranteed. The natural tendency of human beings to underestimate ranges of possible values must be admitted. (Chapman and Ward 1997: 176). The amount of risk is further underestimated, because the interconnectivity of risks is not accounted for. Advanced analytical models may be needed to model complex integrating events. (Wideman 1992: III-6). Last, Chapman and Ward (2002: 267) remind that those things that are not known should not seem to be such. Thus, if an estimate is uncertain it should have a value range of impact and probability assessments rather than just one figure. In this way estimates become transparent and more reliable.
3.2.5. Risk Response Planning

During risk response planning actions to reduce threats of the project and increase opportunities are decided upon. Responsibilities for taking care of these activities and monitoring risks are determined, too. (Project Management Institute 2000: 140). It is said that each risk must have at least one response activity and one individual as a responsible person (Chapman and Ward 1997: 143). The effectiveness of risk response planning is determined by risk severity, timeliness, rationality of responses and the level of agreement and ownership of everyone involved (Project Management Institute 2000: 140). In addition to specific responses for each risk, some general responses affecting several risks should be considered. In addition, if one risk source is assessed to be very significant, several responses should be developed to affect the risk source. After responses have been planned, it should be determined how much risk remains if all actions succeed, i.e. residual risk, and what kind of secondary risks the response actions could initiate. (Chapman and Ward 1997: 129 and Project Management Institute 2000: 143). No specific tools have been suggested in the literature for determining risk responses. However, if several response options exist, e.g. decision trees can be utilised to select the best one. Instead, several generic response strategies have been suggested, see Table 9. As at least one response must be determined for all risks, the minimum option is to accept the risk (Chapman and Ward 1997: 55). However, a risk should be taken only when remedial costs are larger than the possible costs imposed by the risk (Wideman 1992: I-5). When deciding which response strategy to employ, the degree of influence must be considered: if it is impossible to control a risk, there is no point in planning
Hanna-Leena Saari
44
extensive avoidance measures (Elkjaer and Felding 1999: 19). Baccarini and Archer (2001: 142) suggest that only those risks assessed to be high are required to have a response plan. Otherwise, normal project management practices can take care of the risk. On the other hand, Royer (2000: 9) suggests that when risks have high probability or impact they must be examined in detail and medium probability or impact risks must have a response strategy while for those risks having low probability and impact only monitoring metrics can be developed. If these kinds of decision rules are used, it may be most effective to determine them on a case-by-case basis depending on the projects risk level, strategic importance, risk-taking strategy of the company in question etc.
Table 9. Generic response strategies and their difficulty (Chapman and Ward 1997: 114 and Pitknen 1999: 39) Type of Response Convert risk to opportunity Avoid Modify objectives Increasing difficulty Transfer Share Insurance Prevent Mitigate Develop contingency plans Keep options open Monitor Accept Remain unaware Change the probability of occurrence. Modify the impact of a source of uncertainty. Set aside resources to provide a reactive ability to cope. Delay choices and commitment, choose versatile options. Collect and update data about probabilities of occurrence, anticipated impacts, and additional risks. Accept risk exposure, but do nothing about it. Ignore the possibility of risk exposure, take no action to identify or manage risk. Plan to avoid specified sources of uncertainty. Reduce or raise performance targets, change trade-offs between multiple objectives. Method of Dealing with Uncertainty
Every identified risk must have a manager and an owner. The risk owner is responsible for managing the risk as well as bears the possible consequences. Responsibilities can be assigned with formal or informal contracts. Within an organisation, informal contracts are usually sufficient while between organisations formal contracts may be needed. (Chapman and Ward 1997: 150). Responsibilities cannot be assigned arbitrarily, but they must reflect the source and controllability of the risk. Thus, those able to control the risk must be the ones managing it, too. (Wideman 1992: VI-1). Still, Chapman and Ward (2002: 199) warn not to expect delegation of responsibility to be simple. Rather, an ongoing dialogue is needed.
Hanna-Leena Saari
45
After the responses have been decided upon, it is possible to construct several kinds of reports outlining risks and responses. Risk/response diagrams depict primary risks, responses, secondary risks and links between them together with residual risks. The diagram represents the basic risk management issues in one picture thus facilitating shared understanding and enabling a disciplined understanding of the situation. However, it is difficult to construct and therefore it is not widely used. (Chapman and Ward 1997: 134). Project risk maps are another way of representing the situation before and after planned responses, see Figure 12 (Khknen 1998: 196).
1000
100
+/- %/Yield
10
0,1 0 25 50 75 Probability % 100
Figure 12. Project risk map (Khknen 1998: 196). Risk isobar presents the acceptable level of risk
A risk register should be created after responses have been planned and should include for example risk description, causes and triggers, impact and probability, interactions to other risks, timing of impacts, description of the responses and the responsibilities, and secondary and residual risks (Ward 1999a: 335). Risk register should be updated as an ongoing process to ensure that risk information is up-to-date. It can also be used as a reporting tool during the monitoring and control phase. It is also a tool for maintaining and auditing history data and can facilitate bringing new team members up to speed effectively. (Patterson and Neailey 2002: 369). Chapman and Ward (1997: 224) call this kind of a document a risk analysis report. With the information stored in risk register, it is possible to construct base and contingency plans. These are presented next with other kinds of documents created from information generated during the risk management process so far. Before any risk identification and assessment, there are reference plans that reflect the current understanding of the plans. Reference plans are dynamic documents evolving as the project progresses. On the other hand, after risks have been identified and assessed, more realistic targets can be established and incorporated into the project plan. This plan is then called the base plan. It includes the proactive response actions determined and also the effects of those risks that have low impact but medium or high probability. (Chapman and Ward 1997: 222-224). On the other hand, contingency plans account for
Hanna-Leena Saari
46
the effects of those risks that have been accepted. Usually, contingency reserves consist of certain amounts of money, time and resources that are then consumed during the project as risks materialise. (Project Management Institute 2000: 143). Last, action lists are documents in which actions induced by the risk management process are listed. This document should support the monitoring and control phase by defining risks and their responses, responsible persons, status of response actions and deadline or date of completion. (Artto et al. 2000: 101-102).
3.2.6. Monitoring and Control

Risk monitoring and control is the ongoing phase throughout the project in which identified risks are monitored and the need for additional risk identification is observed. The effectiveness of responses is also examined by comparing achieved performance to planned progress. In addition, prioritisation of risks is revised and exceptions and changes reported. Monitoring and control goes on during the entire life cycle of the project initiating additional identification, assessment and response planning when necessary. (Project Management Institute 2000: 144 and Chapman and Ward 1997: 51). Only very little emphasis is given to this phase in literature. However, Project Management Institutes (2000: 144) view of the purpose of this phase is presented in Table 10.
Table 10. Purpose of monitoring and control (Project Management Institute 2000: 144) Purpose of monitoring and control is to determine, if: Risk responses have been implemented as planned. Risk response actions are as effective as expected, or if new responses should be developed. Project assumptions are still valid. Risk exposure has changed from its prior state, with analysis of trends. A risk trigger has occurred. Proper policies and procedures are followed. Risks have occurred or arisen that were not previously identified. Contingency plan should be implemented. Corrective action should be taken. Project should be replanned.
According to Turner (1999: 254) monitoring and control consists of four stages: planning, monitoring, reassessment of new risks at key milestones and transition stages, and taking action to overcome variances. On the other hand, Chapman and Ward (1997: 236-241) suggest that the phase consists also of crisis management and change control. Thus, the project team should be prepared also to fight against crises even though with proper risk management many risks have been anticipated before they materialise. Also,
Hanna-Leena Saari
47
effective communication practices must be in place to ensure that if something is going wrong, the information reaches the project team and project manager. Pitknen (1999: 41) adds to this list monitoring secondary risks. Project manager and risk owner are the persons that need to ensure that risks are continuously monitored in order to spot the occurrence of trigger events and to identify new risks. The risk owner should also report the effectiveness of responses, if any unexpected effects occur because of implemented responses, and if some corrections are needed in responding to risks. (Royer 2000: 9 and Project Management Institute 2000: 144). Thus, it is important that response plans are also monitored in addition to the risk itself (Williams et al. 1997: 74). Techniques for implementing monitoring and control can be divided into two categories: meetings and documents. Basically, risks should be discussed in routine meetings by, for example, adding them as a fixed agenda item (e.g. Krogstie et al. 1999: 890 and Chapman and Ward 1997: 238). Updated risk documents such as risk registers could be reviewed as part of these regular meetings or in project progress reports (Pyra and Trask 2002: 42). Project risk response audits examine and document the effectiveness of responses and the risk owner. Also, technical performance measurement and Earned Value analysis can be used to track project progress compared with planned performance (Project Management Institute 2000: 145). Krogstie et al. (1999: 890-891) recommend the application of a risk matrix depicting five to ten most important risks and their development and a project risk watch list describing these risks in more detail in regular project progress reports. Additionally, Jordanger (2000: 100-101, 104) presents the use of top-ten lists as an effective way to focus attention and communicate between hierarchical levels. According to him, the lists should include manageable risks that are time critical and have a significant impact on project performance. The risks should be selected into the list with managements qualitative evaluation rather than straight from calculations performed in the assessment phase. Monitoring and control is the phase initiating the feedback loop. The risk management process should be revised when project situation changes, new information arises, feedback from other projects is gained and at the end of project stages, before gate reviews in which risks should be discussed. In fact, the process of reassessing risks should go on until risks are prevented, mitigated or accepted. (Elkjaer and Felding 1999: 19, Pitknen 1999: 41-42 and Tritle et al. 2000: 49). When risks are eliminated entirely or realised they should be removed from project plans (Chapman and Ward 1997: 239). This continuous nature of risk management also poses requirements for tools used in risk identification, assessment and response planning: all analyses must be easy to update (Peltonen et al. 2001a: 15).
Hanna-Leena Saari
48
3.2.7. Risk Management Closing

After the project has been completed, risk management needs closing as well as other project management processes. In fact, the use of systematic risk management practices enables the effective project management review (Chapman and Ward 1997: 262). In risk management closing the documents that have been gathered and updated during the entire project will be stored for future use, e.g. into a risk database. Moreover, checklists and prompt lists etc. must be updated if needs for changes have been noticed during the project. The lessons learned should contain all necessary information gathered from risks during the project such as all identified risks, materialised and avoided risks, effects of materialised risks, response actions and their effectiveness, and responsibilities. Still, project information should be kept updated during the entire project so that other projects are able to utilise this knowledge simultaneously (Royer 2000: 10). As a conclusion, a wide variety of tools and techniques for managing project risks exist all having their own advantages and disadvantages. The suitable tools must be chosen regarding the situation and environment in which it is used. In the following section, issues that have to be taken into account when organising and implementing risk management are discussed. 3.3. Organising and Implementing Risk Management
The processes and tools presented above provide a somewhat mechanistic view of risk management. The aim of this section is to deepen the understanding by presenting additional and even alternative views of risk management. Only those aspects that were perceived to be most important for risk management were selected to be examined in this study.
3.3.1. Life-Cycle View of Risk Management

Uncertainty varies over time and it is at its highest during the early stages of the project when only little information is available. At that time, also degrees of freedom are greatest. The level of uncertainty decreases when time passes, as e.g. more information is gained. More commitments are made, too. When risk management is started early it is more difficult but also more useful, while there are still opportunities to change and modify plans. On the other hand, at later stages it is difficult to make changes, even though risk analysis is easier when more is known about the project. However, the project is most vulnerable for risks that materialise at the end of the project. Risk management should thus be started as early as possible and especially before major resource commitments are made and before too much is at stake and continued actively throughout the project. (e.g. Wideman 1992: II-5 and II-6, Pitknen 1999: 22 and 49, and Chapman 1998: 246). In fact, it seems that the earlier risk management is started the more successful the project is (Elkington and Smallman 2002: 56).
Hanna-Leena Saari
49
Risk management principles stay the same during project life cycle even though the amount of work and the required level of detail change (Jordanger 2000: 105). In different project phases, available information and evaluation metrics can vary. At the early stages, qualitative analysis is more suitable while quantitative analysis can be used at later project stages. (Tritle et al. 2000: 49). When thinking about the specific project life-cycle stages, a preliminary risk evaluation should be performed already after the project idea has born and before planning has been started. When the technical design is finished, technology-related risks can be accounted for and after project planning schedule and budget risks can be addressed. Before the project execution starts, risks of outsourcing and risks initiated by different stakeholders must be considered. (Pitknen 1999: 50 and Turner 1999: 285). Wideman (1992: IV-2) adds to this list also product life-cycle risk analysis that should be done before project execution. According to Chapman and Ward (1997: 248), however, it is difficult to implement a systematic risk management process before planning stage of project life cycle. During project execution risk management is mostly about coordinating and controlling activities together with change management (Pitknen 1999: 51). The analyses done previously must be revised periodically, however. Thus, the question of when risk management must be started is left unanswered and it could be concluded that this, too, has to be determined on a case-by-case basis.
3.3.2. Risk Management at Different Organisational Levels

All projects have risks, but all the organisational levels above and below projects also have their own risks. Artto et al. (2000: 7) present an organisational model for risk management that describes the different kinds of risks taken care of at a certain organisational level, see Figure 13. In addition to the risks depicted in the model, a subset of risks at one organisational level contributes to the set of risks at the subsequent level (Jordanger 2000: 104). Hauge (1996: 513) also adds to this personnel risks that are managed at the portfolio level.
Hanna-Leena Saari
50
Financing
Damage Control & Insurance Policies
Business Units
Project Portfolio Perspective
Country Risk Considerations
Business Operating Systems/Units Departmental Organisation Units
Business Risk Management
Single Project Perspective

Bid Preparation Bid Contract (Order) Start-up
Risk Management Process Bid

Screening Preparation Bid Execution Commisplanning sioning manufact Closeout Aftersales Guaran
Contract (Order)
Start-up
Execution Commisplanning sioning manufact Closeout
Aftersales Guaran
Operations/ Individual Projects
Screening
Technical Risk, Reliability Eng.
Figure 13. Organisational model for risk management (Artto et al. 2002: 7)
Risks encountered at the project level may affect upper organisational levels also in other ways. When same risks impact several projects, upper management should take the responsibility for managing them (Noor et al. 2002: R4.3). These kinds of risks pose a higher aggregate risk for the organisation as a whole thus requiring also more coordinated activities for their mitigation and avoidance (Royer 2000: 12). Furthermore, the responsibility for managing certain risks may be transferred between organisational levels, while other levels may have the power to affect the risk source (Jordanger 2000: 104). Business risk management should cover risk management at all organisational levels (Artto et al. 2000: 7). Hauge (1996: 513) suggests that risk management could often be more efficient if done at lower organisational levels. This, however, increases the amount of communication and co-operation needed between the organisational levels. The communication could be facilitated for example by transferring top-ten risk lists between organisational levels (Jordanger 2000: 104). When risks are identified and assessed at project level, they are often attempted to be summarised to form a statement of overall program or portfolio risk. However, most of the ways to aggregate risks into upper organisational levels are problematic and sometimes even dangerous. Conrow (1997: 6) suggests as a remedy for this the elevation of the highest risks of a project to upper levels unaltered
Hanna-Leena Saari
51
3.3.3. Hard and Soft Risk Management

The risk management processes and techniques outlined in literature have much focused on what tools to use and how risks should be quantified. This approach was also taken in section 3.2 when risk management processes and tools were introduced. However, Green (2001: 53) criticises these approaches to focus too much on technicalities only capable of coping with situations that are technical, static and well-defined. The actual practice of risk management rarely follows the models presented in the literature thus questioning their applicability to real-life situations. This can also be seen in section 3.4, in which current risk management practices will be elaborated. However, Green (2001: 53) has distinguished a new paradigm, soft risk management, not focusing on quantitative methods but rather emphasising the team nature of risk management, the importance of an independent facilitator and risk management as a means of continuous learning. From the literature used in this study it is also possible to find other indications of hard risk management being insufficient. Turner (1999: 249) states that the ultimate purpose of risk management is communication to all parties involved in the project. Moreover, Klakegg et al. (1999: 919) stress the importance of a structured communication process that should be lead by a facilitator. This would increase trust within the project team, as increased openness would lead to more successful risk analysis sessions thus improving project performance. Artto et al. (2000: 107), on the other hand, outline issues that will become more important in the future of risk management, such as co-operative models, creativity, adaptability together with organisational and individual learning. Furthermore, risk knowledge bases will become organisational memories contributing to learning (Artto and Hawk 1999: 3). The importance of knowledge management facilitating risk management and at the same time organisational learning is often stressed in other sources as well. Knowledge managements contribution to effective risk management is discussed in the following section.
3.3.4. Risk Management and Knowledge Management

Risk knowledge is essential for effective risk identification, assessment and response planning. It is mostly experience-based information learned during working in different projects. Experience-based knowledge is tacit and is context and time-specific. Risk knowledge can emerge from a variety of sources, such as problems and best practices, actual occurrences from current projects, and plans and status report data. (Artto et al. 2000: 22, 30). Thus, risk knowledge should flow between past and future projects as well as among ongoing projects. This is by no means an easy task, while it is hard to transfer tacit knowledge that is personal and difficult to formalise into words (Nonaka 1994: 20).
Hanna-Leena Saari
52
Several of the tools discussed earlier in sections 3.2.2-3.2.7 can also be used to manage risk knowledge. New lessons learned can be gathered by analysing current projects. Moreover, checklists are a means to collect all lessons learned data into a tool that is accessible and easy to use. Risk databases, for example risk registers, can also be used to gather such risk knowledge that can be formalised and store it into one place. In order to be effective, lessons learned, checklists and risk databases must always be updated during and after a project when the need arises. (Artto et al. 2000: 25-28 and Pitknen 1999: 47). Also other techniques are available for enhancing knowledge management and transfer. Old project data and documentation can be used in new projects, even though it is difficult to develop this into a systematic practice. Project practitioners should also be offered possibilities to develop themselves by offering learning programs. Formal and informal roundtable meetings are also a means to gather project managers to discuss present issues and management practices regularly. However, the simplest way to guarantee knowledge transfer between past and present projects is to use experienced people in the project team or in a strong supporting role. In addition, reporting and close-out processes should be developed to support organisational learning. (Artto et al. 2000: 25-28, Artto and Hawk 1999: 4 and Pitknen 1999: 47).
3.3.5. Risk Management as Team Work

Most authors of risk literature think that risk management is essentially a team effort (e.g. Chapman 1998, Wideman 1992, Williams et al. 1997, Artto and Hawk 1999 and Peltonen et al. 2001a). Teamwork is effective in risk management as well as in other practices, while it combines the knowledge of several individuals and personnel groups (Peltonen et al. 2001a: 14). To facilitate knowledge management, it is important to have experienced team members (Pitknen 1999: 31). Moreover, all team members must be such key people of their organisational unit that they are able to communicate, co-operate and make commitments concerning his or her own unit and also able to implement the actions decided upon (Klakegg et al. 1999: 918). A facilitator is often suggested to participate in team working. The facilitator should be independent and come from inside the company. The tasks of a facilitator encompass at least developing project participants knowledge of risk management with on-the-job training and courses, participating in risk analysis, developing work processes and assisting in status reporting. (Jordanger 2000: 93). The aim is that in addition to helping the project manager, the facilitator also focuses on establishing an informed, open-minded and creative atmosphere for risk management to take place in (Klakegg et al. 1999: 911).
Hanna-Leena Saari
53
3.3.6. Risk Management and Decision-Making

There is always more or less uncertainty involved in decision-making (Wideman 1992: I1). In risk management, decisions have to be made during risk response planning when determining the response strategy. Thus, risk identification and assessment can be seen to be decision-support tools (Buchan 1994: 29). In fact, risk management can support decision making throughout the entire project process (Pitknen 1999: 73). In addition to decisions determining how the project will proceed, risk information can also be used in portfolio-level decisions. Go/no-go/maybe decisions should always involve a risk evaluation (Chapman and Ward 1997: 15-16). However, risk information should be used as a means to balance the portfolio risk and evaluate projects fairly: if high-risk projects always suffer from for example budget cuts, risks will be soon denied and avoided thus teaching project participants to be risk-averse rather than open and honest (Wright 1997: 136). Thus, risk information is important for decision-making, even though it must be used with care.
3.3.7. Necessity of Risk Quantification

Most hard risk management methods rely on quantitative modelling of risks. The applicability of quantification and thus also hard risk management is now discussed. According to Chapman and Ward (1997: 298), even though representing hard risk management, identification of all key risks and defining responses to them is the most important thing, whether or not quantitative methods are used. Additionally, Artto (1997: 353) questions the usefulness of numerical methods on the basis of their rare use in practical applications and presents a view of risk management based on the assumption that only responses can affect risks. Khknen (1999: 1) has also noticed that the most common barrier for successful implementation of risk management practices has been risk assessment: too often companies get stuck with risk modelling and its results. Turner (1999: 240) suggests the use of qualitative methods rather than quantitative. It has also been stated that whatever techniques used, risk assessment can never be complete because of limited amount of available resources and bounded rationality of human beings (Green 2001: 55). Often it is enough just to get risks prioritised relative to another (Peltonen et al. 2001a: 17). As all risk assessments are more or less based on subjective estimates, risk rankings are only valid for that particular point of time (Patterson and Neailey 2002: 369). Quantitative analysis results should always be interpreted with care, especially those composed at early stages of a project (Tritle et al. 2000: 50). In addition, determining exact probabilities and risk impacts reduce the reliability of the assessment (Artto 1997: 354). Anyhow, quantitative risk assessment is necessary if numerical justification is needed for the acceptance of response plans (Williams et al. 1997: 73).
Hanna-Leena Saari
54
3.3.8. Necessity of Formal Risk Management

If quantitative analysis is as flawed as described in the previous section, the question is, are formal risk management approaches applicable at all. Chapman and Ward (2002: 50) state that formal approaches are usually less biased than informal and intuitive processes. Raz et al. (2002: 107) also stress the importance of a systematic and methodically applied process. On the other hand, Chapman (2001: 147) argues that literature reveals a tendency for risk management applications to be too prescriptive and mechanistic. Whether to use a formal risk management process depends on how mature project management is in the organisation. If project management is a new and immature paradigm, too complex models should be avoided. (Elkington and Smallman 2002: 56). Artto et al. (2000: 10) outline the implicit limitations of risk management processes. Risk management processes only emphasise the project execution phase leaving project sales and after-sales phases unaddressed. The focal point of attention is risks that can be dealt with project management practices. Moreover, information used in risk management is subjective and derived only from experienced project participants and recorded experiences of past projects are often excluded. Last, no suggestions are given as to when in the project life-cycle risk management should be applied. Thus, the question of the usability of formal risk management methods and risk quantification is still left unanswered even though strong arguments are given for both approaches. Perhaps also with this conflict the most reasonable way to proceed is to acknowledge these statements and select a suitable approach for each specific context. This issue is elaborated further in section 3.4 that presents studies of how risks are managed in practice in companies at the moment.
3.3.9. Issues in Designing and Implementing Risk Management Processes

Several attributes describing the optimal risk management process have been presented in the literature. First, the process should be creative, supportive and built on trust and confidence (Chapman and Ward 1996: 12). Risk management process should also be iterative with a specific objective for each pass, as simple as effective, structured, robust, adaptable, complete and it should use best practices instead of common practices (Chapman and Ward 2002 and Turner 1999: 249). Documentation should be included as an integral part of the process, while it is harder to ignore written risks (Williams et al. 1997: 73). However, too detailed documentation and analysis requirements may result in a process that is not cost-effective (Ward 1999b: 42). Project participants should rather be able to remember and apply the selected analysis methods themselves during the project life cycle (Khknen 1999: 2).
Hanna-Leena Saari
55
The project context also affects the risk management process. According to Ward (1999b: 37) even though predefined processes help in determining what steps should be accomplished, it does not guarantee the effectiveness of the process. Therefore, the process needs to be adapted to the project environment in which it will be used. In lowrisk projects, for example, sophisticated and detailed systems are not required for managing risks. There could even be a need for a formal procedure for determining whether formal risk management must be carried out in the project. Other issues affecting the design of risk management processes include the location of risk management relative to the project organisation, supporting information systems, availability of information in addition to organisational structure and culture, i.e. attitude to risk management and available resources. Last, risk management must be fitted into the other processes of the company, for example, risk management in innovation must be suitable to the innovation process. (Ward 1999b: 38-40 and Halman and Keizer 1997: 204). Risk management process development efforts progress usually from simple qualitative methods towards more sophisticated quantitative methods associated with knowledge management aspects. For example, qualitative approaches such as prompt and risk lists are oftentimes the first step followed by quantitative analysis, establishing risk databases and incorporating opportunities into the analyses (Artto and Hawk 2000: 3 and Ward 1999b: 41). Anyhow, no matter how elegantly designed a process is, its successful implementation is critical. The implementation should be followed by improving understanding about risk management tools, establishing the role of risk management in the organisation, changing working practices, and a continuous development and learning process. (Khknen 1997: 76). This all requires constant and visible top management support and sponsorship (Grey 1995: 70 and Williams et al. 1997: 77). 3.4. Studies on the Present State of Risk Management Implementations in Companies
In this section, the present state of risk management is described based on research, i.e. it is outlined, how risks are managed in practice in companies at the moment, thus questioning the applicability of some processes and tools presented earlier. According to Royer (2000: 6) risk management is not usually dealt with such an intense attitude as other project management processes. Risk management is usually related strongly to other management practices (Raz and Michael 2001: 11), even though Green (2001: 56) states that too often risk management is disconnected from everyday project management. However, it seems that effective risk management processes are not common (PMI RiskSIG 2000b: 4).
Hanna-Leena Saari
56
Several studies have investigated the risk management applications in different industries. Raz and Michael (2001: 12) found out that there was a positive relationship between the extent of risk management tool usage and project management performance. Still, risk management techniques were not often used, while project managers did not regard them as a part of their jobs, they were unaware of suitable techniques and were over-optimistic (Raz et al. 2002: 107). The way and scope risks are examined depends often on the project manager. Usually, risks are discussed in expert teams, such as project team meetings. (Peltonen et al. 2001b: 8). According to Simister (1994: 6-7) checklists have been the most favoured risk management tool. In addition, other traditional techniques, such as brainstorming, Monte Carlo simulations, PERT and sensitivity analyses, have been used broadly. On the other hand, Raz and Michael (2001: 10) left decision and fault trees, and influence diagrams out of their study, because experts stated that they are not used in practice. According to Pitknen (1999: 47) and Raz and Michael (2001: 15) risk identification is conducted properly in most organisations and there are no particular differences between companies. The most often used techniques are group work and utilisation of previous experiences in the form of checklists or participation of experienced persons. However, it seems that from this point onwards risk management tends to be more problematic and controversial. Low/medium/high categorisation was most favoured in risk assessment and the scale was regarded to give enough precision. Use of software tools was rare, too. Response planning was the least systematised phase. Sometimes, a responsible person was only nominated for a risk and he or she could then determine the actions performed. (Pitknen 1999: 40). Smith (2003: 44) also states that few companies actually implement the actions to avoid or mitigate risks decided upon during response planning (Smith 2003: 44). Additionally, there were shortcomings in reacting to events as well as in monitoring and controlling practices (Rimpilinen and Peltonen 2000: 8). Raz and Michael (2001: 11) concluded that tools used in monitoring and control do not contribute much on project success. Perhaps the most important thing would then be to use at least some kind of a tool. Finally, according to Pitknen (1999: 42), project and risk management performance is reviewed at the end of the project when risk lists are updated. Some companies also conducted follow-ups regularly during the project. It can be concluded that the most sophisticated techniques are rarely used in practice thus questioning the appropriateness of quantitative tools described in literature. However, as all phases of the risk management are not often implemented, it seems useful to have some formality when a risk management process is implemented. In this chapter risks and risk management were examined in detail thus fulfilling the second and third study objectives. In the following chapter, a synthesis of the literature study presented in chapters 2 and 3 is provided as a description of best practices for risk management in the pharmaceutical industry.
Hanna-Leena Saari
57
4. PROJECT RISK MANAGEMENT IN DRUG DEVELOPMENT PROJECTS From the previous chapter it is quite clear that as there are several different approaches for risk management, the special conditions and requirements of the environment in which risk management is going to be implemented has to be considered carefully. The aim of this chapter is to provide insight into how, on the basis of the literature study, risks should be managed in the pharmaceutical industry thus providing a synthesis of chapters 2 and 3. In this chapter, some notions found from literature considering project risk management in drug development projects are presented first. After that, the literature study is formed into a synthesis as a recommendation for best practices of risk management in drug development projects thus fulfilling the fourth study objective. The synthesis consists of a proposed for a risk categorisation together with a discussion of a risk management process and tools in drug development projects. Issues regarding the organisation and implementation of risk management in drug development projects are also highlighted. In addition to literature, insight about the industry and risks of drug development projects gained during the interviews in the case company, is also used in this chapter to some extent. As already stated, most risk management literature has concentrated on external delivery projects and they have often been developed and tested in industries such as construction and petrochemicals. Furthermore, as discussed in section 2.3.3, the project management practices are less mature in the pharmaceutical industry than in these industries thus complicating the adoption of risk management practices from theory. 4.1. Literature View on Risk Management in Drug Development Projects
Significant effort was put to a search of literature concerning project risk management in the pharmaceutical industry. This, however, revealed the lack of such literature. The literature discussed drug development projects and their risks only in the viewpoint of business risk management. This section is therefore mostly derived from pharmaceutical business risk literature as far as it can be applied also to project risk management. Thus, it seems that project risk management is not widely practiced in the pharmaceutical industry. The importance of risk management has been recognised, however. For example, Pass and Postle (2002: 70) have illustrated a categorisation of risks in pharmaceutical R&D including both business and project-level risks, see Figure 14.
Hanna-Leena Saari

Commercial - Product value - Competitive advantage - Financial return - P&R Risk in R&D Strategic - Business model - Disease - Therapeutic area - Patient population - Portfolio considerations Discovery - Platform technology - Mechanistic approach - Strength/durability of concept - Predictability of targets and models Development - Patient population - Clinical endpoints - Safety/efficacy/economic - Comparator (s) - Predictability of trials Regulatory - Risk/benefit ratio - Value for money
58
Figure 14. Risks posed by pharmaceutical R&D (Pass and Postle 2002: 70)
The traditional approach to managing business risk arising from risky R&D has been to ensure that a sufficient amount of compounds is under development to get enough products on markets. This has lead to the belief that the biggest companies will survive and nothing else can be done to manage risks. (Pass and Postle 2002: 70). As already depicted in section 2.2.3 there is a vast knowledge about the average success probabilities of different drug development stages. This can be used e.g. when estimating the risk level of a certain project by adapting the figures to the characteristics of the compound. However, this approach takes no initiative to managing the risk but rather just to expressing it. The stage of development affects the risks of drug development projects. In Phase I the probability of completing the studies successfully is higher than in later phases because study subjects are healthy. On the other hand, in Phase III a lot is already known about the drug. An important risk not always recognised in Phase I, however, is the risk of design errors that affect the rest of the project. Moreover, considering the regulatory authorities it is always somewhat difficult to determine how long it takes to get an approval to proceed to the next stage. Each regulatory agency has rules about how long it can take to process the application. The ethical approvals, however, are more complicated, because a lot of local knowledge is required in estimating the duration of getting the approval. (Rose 1998: 208-210). As risk management in drug development projects is so scarce, Reynolds (1998) has focused on what the pharmaceutical industry should learn from other industries in this respect. First, variances should be raised from any level into the project team and if the issues can be dealt with contingency, all project team members should have the power to release it. Second, a risk register should be used to estimate future costs, variances
Hanna-Leena Saari
59
and actions. Special action teams could be introduced to manage off-line activities such as risk mitigation and process enhancements. Last, risks should be one of project teams weekly meeting topics. (Reynolds 1998: 93, 96-98). Thus, the first challenge is to introduce project risk management to the pharmaceutical industry and drug development projects. Only after that the practices can be developed to be optimal for the industry and company in question. 4.2. Risk Types in Drug Development Projects
The nature of the major risks of the pharmaceutical industry must be understood when risk management in drug development projects is developed. In pharmaceutical projects, the methods for reaching the project objectives are usually quite well known, while regulations determine most of the trials and also the results needed. Uncertainty thus arises from other sources. Still, risks caused both by the product itself and the means to achieve it must be considered. In this study it is suggested that the risks of drug development projects might be roughly divided into controllable and non-controllable risks. The risks related to the inherent features of the compound cannot be affected and the only possible response action is to quit the project if adverse events occur. Thus, for example safety and efficacy issues can be recognised as possible show-stoppers already at the outset of the project. Project activities can and should also be planned to spot these features as early as possible to enable the fast abandoning of the project. Additionally, these characteristics can be monitored intensively to spot any indications of problems. Controllable risks would then include other risks, such as schedule, budget, resource and knowledge-related risks. It is apparent from the literature reviewed that risks may be different from each other in their relative importance. Commercial risks are huge and they are difficult to predict because of the long time horizon of introducing new products into the markets. Competitors may have launched new products, therapeutic practices and recommendations may have changed, the compound may be regarded unapplicable or dangerous, new compounds may have replaced it, the entire market may not exist anymore and so on. Budget overruns are not usually that critical in drug development project as for example risks affecting schedule or scope: development costs do not account for much in net present value calculations while the expected revenues are usually so much larger. Budget overruns can be more destructive to small companies than to the huge conglomerates of the industry that have enough resources to cover overruns. However, for the product to be profitable at all, it usually has to perform better in some attributes than competitors products in order to gain market share. Furthermore, time-to-market is critical. Products must be launched within a certain time window, for example, to be first on markets or to replace products before patent expiry.
Hanna-Leena Saari
60
Thus, on the basis of this study, it seems that external risks together with schedule and scope risks are the most significant risks in drug development projects. Even though Pass and Postle (2002: 70) attempted to draw a summary of R&D risks in the pharmaceutical industry, there is still room for development. The model is somewhat mechanistic leaving out, for example, regulatory changes and changes in the marketplace. Resource risks are also totally neglected, such as whether there is enough knowledge of the compound or markets in-house and whether there are enough resources available for the project. Partner risks were also left out of the model and discovery risks were considered to be technical risks. This study attempts to address this problem by presenting a draft suggestion for the risk categorisation of drug development projects representing the risk source, see Figure 15. The suggestion was built on Pass and Postles model by adding the issues described above that were derived from literature in sections 2 and 4.1. Some categories also include some propositions for the sub-categories or issues that could be included in one category.
Clinical Pharmacokinetics Technical risks Toxicology Industrialisation IPR risks Partner/subcontractor/ contractual risks Regulatory risks Pharmacology Formulation Analytics Process development Scientific advances Competitors
Commercial risks Scientific recommendations Markets and marketing
Launch risks
Project management risks
Resource/personnel risks Availability Knowledge
Figure 15. A draft suggestions for the categorisation of risks in drug development projects
4.3.
Risk Management Process
The overall aim of risk management in drug development projects, as well as project management in general, is to maximise the success probability of the selected projects. Risk management can also support in minimising the costs of failure by detecting problems early. In addition, decisions regarding what projects to start and what to end can be made based on more realistic information. Additional benefits can be gained, too, such as enhanced and open communication, increased risk awareness and realism in project planning and assessment. Risk management also forces to document project progress thus facilitating the gathering of lessons learned information. However, timeto-market may not be significantly reduced when risk management is implemented, because most critical activities are incompressible, as mentioned in section 2.3. Schedule
Hanna-Leena Saari
61
overruns may instead be reduced by minimising the amount of repeated tasks. As drug development projects are highly uncertain and large, proactive risk management should be very useful. Especially, when developing truly new proprietary drugs, risks should be managed properly. In general it seems, on the basis of literature reviewed in section 4.1, that the risk of drug development is managed more by the means of portfolio management than project risk management. No reported attempts to apply project risk management were found, either. Thus, it is proposed that the practice has not been abandoned but rather has not yet been implemented widely. The recent changes in the industry depicted in section 2.1 highlight the need for effective risk management also in this sector. Its implementation will not be easy, however. Complexity of drug development projects makes risk management more demanding than in simple projects. On the other hand, it also makes formal risk management processes more necessary. Low maturity level of project management may also make it more difficult to implement systematic risk management: if there is no habit of managing projects, adding risk management may seem like a huge step. Thus, this study suggests that a slow start with qualitative approaches may be necessary. Still, it should be kept in mind that more sophisticated and detailed methods and processes may prove to be useful in this context of high-risk and complex projects. Risk management practices should therefore be developed when the maturity of project and risk management allows it. As the expertise of many different disciplines is needed in drug development projects, a project team incorporating representatives of all these disciplines would be too big to be effective. Thus, the project team needs input for risk management from others, too. In this study, it is suggested that the information flow between lines and project team members must be guaranteed by, for example, making sure that risks are addressed in the line before they are discussed in the project team. Then, experience of people in the lines could also be utilised even though there would not be enough people with long working history for every project team. As far as the risk management process that is recommended for drug development projects is concerned, this study proposes that a restriction should be made to consider first only uncertain events. At the second stage of development uncertain values can also be accounted for, while their assessment would require more advanced numerical methods. Risk management process phases are discussed step by step in the following section introducing the approaches most suitable for drug development projects today. The process follows the phases of the generic risk management process introduced in section 3.2.1.
Hanna-Leena Saari
62
4.4.
Risk Management Tools
As was shown in section 3.2, there is a vast amount of tools available for managing risks. Now, these tools and processes are analysed from drug development project point of view. The section is concluded with a summary of all the tools suggested to be used in the pharmaceutical industry.
4.4.1. Risk Management Planning and Risk Identification

On the basis of the literature study, it is suggested that risk management should be planned in drug development projects as described in section 3.2.2 just as any other project activity. Only then risk management can be comparable to the project risk level and enough resources is also reserved for it. Moreover, it brings more structure into the process and it is easier to follow the plans. This study proposes the following approaches for risk identification in drug development projects. In addition to risks, also trigger events must be identified. Because of the vast amount of specialist information needed, risk identification should be a team process. A brainstorming-based method may be useful to facilitate identification of new risks that may appear considering the new compound and new competitive situation in question. However, also experience plays a huge role. Thus, experience-based brainstorming could be used as an identification technique. Checklists consisting of high-level categories together with experienced people would support the process. The checklists, such as the categories in Figure 15, would ensure that all relevant risk types are considered. Experience could also be sought from old documents and risk databases. An applied version of Nominal Group Technique could be used as the brainstorming method. All project team members would bring the risks of the lines they represent into the team. These would be posted on a board anonymously and discussed openly. Then, new risks would be identified and with the help of diagramming techniques relationships between risks would be depicted. The discussions should be kept at a reasonable level of detail in the project team to facilitate communication and at the same time keep everyone involved in the conversation. Study-level discussion may prove to be effective enough when risks are considered. A facilitator may be needed in risk identification. He or she should come from the same organisation, while understanding the industry, company and drug development process is essential. Project managers might, for example, act as facilitators of each others projects. Additionally, real-time computer support may be needed for effective documenting of risks and then relations. As an output, a list of all identified risks, their categories, relationships between the risks together with triggers should be produced. Thus, this study suggests risk identification to be a team activity using high-level checklists, experience-based brainstorming, applied nominal group technique and
Hanna-Leena Saari
63
diagramming. Risk triggers should be identified, too, and the use of a facilitator may prove to be effective.
4.4.2. Risk Assessment

On the basis of the literature study it seems that, in addition to risk impact and probability, time-criticality and controllability of the risk must be discussed during risk assessment. At first, qualitative assessment may prove to be effective enough, because of the less mature level of project and risk management. The nature of drug development projects make it more difficult to reliably quantify risks so that the information would be more precise than when gained from qualitative assessment. It is suggested that risk impact and probability could be assessed on a scale of 1-5 with all grades having project-specific definitions. Some company-wide guidelines should be given for the definition of these scales. In addition, a verbal explanation of the impact is necessary so that the analysis would be easy to update when needed. Assessment of time-criticality is important in drug development projects, because of the long time-frame of the project. There may be risks that can materialise only during certain activities later in the project life cycle. Then, it would be more effective to concentrate on the urgent risks first. Timing of risks and when they should be affected could be determined as a date or a range of dates. The controllability of risks should be determined in order not to spend resources on avoiding risks that cannot be affected. This assessment could be done as easily as determining whether or not the risk can be controlled and assigning a Yes value for controllable risks and No for others. This study suggests also that risk assessment should be started with particularly important issues. In the case of drug development projects the amount of risks may be so devastating that all risks cannot be assessed in detail. Thus, the input of the project team, manager and facilitator is needed to make a distinction between major and minor risks, i.e. what risks are left unaddressed and covered with normal project management practices and which risks need to be assessed and influenced. The interconnections between risks can help this task by presenting which risks affect many others thus creating a bigger risk than by itself. As well as in risk identification, it seems that team work is needed in risk assessment, too. Probability-impact matrices could help in the assessment process by depicting the distribution of assessed risks. This can facilitate the understanding of how risky the project is and also force assessments to be realistic: if there are no risks in the most extreme classes, either the assessments have not been truthful or the scale definitions are deficient. Range estimates should be allowed for representing uncertainty of the assessment if necessary. As suggested in the study, qualitative estimates could be the starting point for risk assessment. However, they cause significant limitations for discussions about risks. First,
Hanna-Leena Saari
64
risk assessments of different projects are not comparable directly. Second, an aggregate value for how risky a project is cannot be assigned. An output of risk assessment should be the risk list completed with impact, probability, time-criticality and controllability assessments. In summary, this study suggests that risks should be assessed qualitatively. Probability and impact could be expressed on a scale of 1-5, time-criticality as a date and controllability as either Yes or No. The scale 1-5 should be defined and a verbal description of the impact should be provided. Risks should be processed in the order of importance as team work. Probability-impact matrices could be used to facilitate risk assessment.
4.4.3. Response Planning

On the basis of the literature study it is suggested that several issues must be determined within the response planning phase: response strategy, responses, timing of the actions, responsibility, ownership, residual and secondary risks, and general responses, for example more resources, if applicable. These issues are the same as presented in various literature sources. Individual responses should be planned only for the biggest risks while those risks that were not assessed in detail are accepted. Again, the risks should be discussed in the order of priority determined on the basis of impact, probability and time-criticality. It is suggested that a corporate policy should determine how much risk is acceptable. It should also help in selecting response strategies, i.e. how big risks should be avoided, mitigated etc. Top management should formulate this risk-taking strategy and communicate it to the organisation. Furthermore, only one person can be responsible for a risk and it cannot be assigned without a mutual agreement. This study suggests that adapted versions of project risk maps could be used as a tool for risk response planning. This could be simply constructed as a probability-impact matrix that also depicts the effects of responses. After risk response planning the risk list should be completed with the data generated in this phase. This risk list should be in a form of a risk database with possibilities for getting different kinds of reports to facilitate communication, and monitoring and control. Moreover, all proactive response actions should be added into the project plan, if possible. Otherwise, actions should form a time-ordered action list that could also be one report available from the risk database. Thus, this study suggests a variety of issues that must be determined for each risk. A corporate policy should help in deciding how risks should be approached. Probabilityimpact matrices together with risk lists and databases should assist in response planning and also in monitoring and control. Finally, responses should be incorporated into project plans when possible.
Hanna-Leena Saari
65
4.4.4. Monitoring and Control and Risk Management Closing

On the basis of the literature study it is suggested that the purpose of monitoring and control is the same in drug development projects as in any other project, see section 3.2.6. The phase initiates the feedback loop back to risk identification when necessary and at least before decision points so that updated information is available to enable better decisions. Monitoring and control should be an ongoing process by its nature and incorporated in everyday work of all project participants. However, to facilitate this, risk monitoring should be a part of all project team meetings to introduce the practice to team members. Standard risk reports should also include a part in which the current status of risks and risk management activities is presented. Top-ten or top-twenty lists could be used for the communication between organisational levels. The entire risk database should also be open for all those who need more information and updated continuously. Probability-impact matrices could be used to depict the general risk level of the project for others. In addition, the risk database should have a record of past risk assessments. Then, it would be possible to see how the risk has developed over time. Project manager and risk owner are responsible for monitoring the risks and associated responses while the entire project should constantly be on guard for new risks. Effective communication and information transfer of deviations and changes should also be stressed. During closing the high-level risk lists used in risk identification should be updated and risk registers closed by updating its information for the last time. This gathering of risk knowledge is especially important in long projects, such as drug development projects, when the amount of projects within one persons career is limited. Still, risk knowledge should be transferred between projects continuously. Lessons learned information should be gathered also regarding risk management, risk management process and tools. The process and tools should be developed further when new ideas arise to ensure their compatibility with new requirements. In summary, this study suggests that risks should be discussed in every project team meeting to facilitate the continuity of monitoring and control. Some reports, such as top ten or top twenty lists, were proposed, too. The risk database should be updated continuously throughout the project and closed during risk management closing. The risk management process and tools should be developed further, if needed, too.
4.4.5. Summary: Risk Management Tools in Drug Development Projects

Figure 16 summarises the previous discussion by depicting all the information that should be gathered from a risk during risk identification, assessment and response planning. Furthermore, a column for risk status is included to facilitate the monitoring of the risks. Tools that are used in different phases are also listed at the bottom of the picture.
Hanna-Leena Saari

Risk ID 1 2 3 4 5 6 ... Description Risk 1 Risk 2 Risk 3 Risk 4 Risk 5 Risk 6 ... Trigger (Joint) Impact (1-5) Probability (1-5) Time-criticality (date) Controllability (+/-) Response strategy Response action(s) Schedule Responsible person Risk owner Residual risk Secondary risk Risk status Impact (Verbal description)
66
Risk identification High-level checklists + Applied NGT + Diagramming
Risk assessment Qualitative analysis + Probability-impact matrix
Response planning Corporate risk-taking strategy + Probability-impact matrix
Monitoring and control Top-ten/twenty lists + Probability-impact matrix + Action lists
Figure 16. Issues discussed and tools used in different risk management phases
4.5.
Organising and Implementing Risk Management in Drug Development Projects
In this section the risk management process of drug development projects is further refined on the basis of the literature study. At first, some propositions regarding the project life cycle are presented. Planning a drug development project already requires substantial effort. Thus, before deciding to start planning the project some information of the project risks needs to be gathered to make an informed decision whether the project planning is worth starting at all. It is suggested that a preliminary risk analysis should therefore be performed already before project planning. However, thorough risk identification and assessment should take place during project planning when enough is known about the sequence of activities, schedules, budgets etc. The final go-decision can then be made using risk information as input. In addition to better decisions, early risk management has also another advantage: the project team has not yet developed such a strong sense of ownership for the project allowing it to make better and more reliable risk analyses. Drug development projects consist of multiple layers of projects as discussed in 2.3. Thus, this study suggests that information transfer between layers is essential. Basically, all layers would need risk analyses of other levels for their own risk analysis. However, with the suggested approach using qualitative tools it is not possible to aggregate risks of one level into subsequent levels. Still, communication about possible risk impacts can
Hanna-Leena Saari
67
help in determining risks at other organisational levels. Project team members are the key people in ensuring that all relevant parties are aware of the risk management efforts of the project. Even though risk information will and should be an essential part of decision-making, it should be used with care. In addition, top management should be aware of the possible gains of projects and make effective decisions balancing risk and return. This should be easier for small and medium-sized pharmaceutical companies in which top management is close to project management. It is also suggested that knowledge management has an important role in drug development projects. As the costs of failure are relatively large, all experiences should be utilised to avoid making same mistakes twice. However, there may not be enough experienced persons for all project teams and then this knowledge must be acquired otherwise. Ensuring open information transfer may be more challenging in the pharmaceutical industry because of the traditional barriers between functions and lines. For example, documentation should be regarded as a part of every-day work and standard templates should be developed for documents to facilitate this. Because of the project length, transferring knowledge between present and future projects is not enough. Rather, all ongoing projects must also transfer knowledge and lessons learned right from the beginning of the project to facilitate fast enough knowledge distribution. There might, for example, be regular meetings of project managers where projects and their management are discussed and best practice information transferred. According to this study, soft risk management is stressed in drug development projects as highlighted by the importance of communication, team work and knowledge management. Still, implementing soft risk management may pose some problems depending on the organisation, while many people working in drug development projects are more used to working methods that are scientific, numeric and precise. Thus, risk management relying on communication and team work may seem awkward and ineffective. Team work is suggested to be necessary for effective risk management when the team and the project is composed of several distinct speciality areas. However, it has not been common to work as teams in the pharmaceutical industry. Achieving efficiency in risk management may thus take some time before the team works adequately. This can be facilitated by adequate team design following the aspects presented in section 3.3.5. There should be experienced people in the team and only those people that really are needed should be in it. Team building and creating trust is also essential for effective risk management to enable open communication within the team. The facilitator or the project manager must also make sure that the atmosphere is blame-free and positive when risks are discussed. The amount of risks can be huge in a drug development project. Thus, to comprehend all risks, also the complex ones, it is proposed that a formal process is required. Other
Hanna-Leena Saari
68
reasons demanding formal risk management process are e.g. the riskiness and complexity of drug development projects as already described earlier. A formal process may also unify the information gathered within projects thus facilitating program and portfolio decisions. When implementing the risk management process, the position of project managers must be considered. If they are not perceived to have enough authority, top management must step in and take a leading role in the implementation. In any case, top management should support the process in a visible way. Sufficient resources must be ensured because no matter how things were previously done, new working practices will always take more time. All project workers should be trained to understand the basic concepts of risks and risk management to allow the development of a risk-aware culture. In summary, this study suggests that there is a need for initial risk analysis before project planning is started. Thus, the first complete round of risk identification, assessment and response planning should be done at the project planning stage. It is also suggested that knowledge transfer and management and team work are important in drug development projects, and soft risk management approaches are stressed even though a formal process is proposed to be needed. Finally, some issues to be taken into account during the implementation of risk management were proposed. A summary of the discussion is presented in Figure 17 as the issues raised are connected to the associated special characteristics of drug development and project management in the pharmaceutical industry outlined in Table 2 and Table 4 in chapter 2.
Need for risk management training Project length Knowledge management Initial risk analysis Risk level Team work Formal process Complexity Communication between organisational layers Top management support Projects Project management
Figure 17. Summary of issues to be taken into account in organising and implementing risk management in drug development projects. The issues written in italics can be described as soft risk management approaches.
In this chapter risk management in drug development projects was discussed and methods were suggested. The leading idea was that as project and risk management are not yet widely practised in the industry, the first implementation should not be too
Hanna-Leena Saari
69
sophisticated and heavy. The main thing is to introduce risk management to drug development projects and try to promote risk thinking in the industry. The aim, however, would be to develop risk management even further as project and risk management mature in the industry. At this point the first four objectives of the study have been fulfilled and the last one, i.e. applying the knowledge in the drug development projects of a case company, remains to be addressed. In the following, the empirical setting of this study is outlined.
Hanna-Leena Saari
70
5. CASE COMPANY AND METHODOLOGY The aim of this chapter is to introduce the case company and the structures and practices of its drug development to lay the ground for further discussions. In international terms, the case company is a small player. Still, its projects follow the same drug development process that was described in section 2.2.2. This chapter is written on the basis of the case corporations annual report from 2002 and internal documents. Other sources have been mentioned in the text. First, the case company is described and after that the focus is on its drug development projects. The present state of risk management in the case company is described and finally the methodology of the case study is presented in detail.
5.1.1. Case Company

The case company is an independent business division of a North European health care company that develops, manufactures and markets pharmaceutical products. Its turnover was approximately 500 MEUR in 2002. The vision of the case company is to become a significant European pharmaceutical company with global operations and competing with proprietary products. The case company has a strategic niche focus on three core therapy areas. Other businesses include human pharmaceuticals outside core therapy areas, animal health and pharmaceutical ingredients. The case company has invested heavily on R&D during recent years. In 2002 the R&D investment accounted for over 20% of company turnover and one third of the case companys turnover came from proprietary products. Furthermore, international operations are growing steadily. International marketing and sales is handled either in-house or by partners, depending on the market and the product. 5.2. Research and Development Projects in the Case Company
In this section, the role of projects in the case company is first described by depicting the structure of its R&D portfolio. The project players are presented, too, together with the drug development process.
5.2.1. Structure of the R&D Project Portfolio in the Case Company

The R&D portfolio of the case company is divided into three core therapy areas under which molecule programs are located. Each program consists of several projects that again consist of functional programs and their sub-projects, see Figure 18. For example, a project has a clinical program that consists of several clinical studies. One project aims at developing one drug with one formulation for one disease to be sold in selected markets. Separate projects are established to for further development of the molecule.
Hanna-Leena Saari

R&D portfolio
71
Core Therapy Area 1
Core Therapy Area 2
Core Therapy Area 3
Molecule Program
Molecule Program
Project
Project
Functional Program
Functional Program
Sub-project
Sub-project
Figure 18. A schematic illustration of the R&D project portfolio of the case company
5.2.2. Project Organisation of the Case Company

Portfolio management board is responsible for the portfolio. It acts as the project sponsor and is responsible for the prioritisation and go/no-go decisions of each project. The project portfolio is reviewed at regular intervals two times a year. Each core therapy area has its own business team headed by the business unit head. This team is responsible for creating and implementing the business units strategy by the means of molecule programs and projects. Each program has a program leader who leads a program core team. It is a cross-functional team responsible for planning and implementing programs. A program can consist of new product development projects and associated product improvement projects. The program core team also suggests program alternatives for the business team that then decides which projects to initiate. At the project level the project team is headed by the project manager and is also a cross-functional team. It is responsible for planning the project and its sub-projects, and delivering the project on time and specification. The team consists of permanent and non-permanent members. The latter are included in the team on an as-needed basis depending on the stage of the project. Permanent members include the project manager and leaders of functional teams, see Figure 19. The project team meets regularly approximately once a month to discuss the project.
Hanna-Leena Saari

Clinical Team Leader Preclinical Team Leader Project Manager Functional Team Leader Functional Team Leader
72
Marketing Team Leader Pharmaceutical Development Team Leader Functional Team Leader
Figure 19. A schematic presentation of the structure of the project team
Each functional team takes care of one functional program and the sub-projects within it. The team can consist of representatives of different specialist areas, such as pharmacology, toxicology and pharmacokinetics in the preclinical team, or of the leaders of sub-projects, such as clinical trials. As a result of implementing a process organisation and current restructuring of the organisation these teams are subject to change, however. The aim is that the amount of different teams and the resulting meetings will be reduced so that working would become more efficient. This study is anyhow completed based on these team structures, still bearing in mind the adaptability of the risk management framework to the situation in the future.
5.2.3. Drug Development Process of the Case Company

The case company models its projects as a stage-gate development process where several stages are conducted separated with go/no-go decisions. The process is depicted in Figure 20. At the concept stage leads for new projects are evaluated. These ideas may come from several sources. The leads are studied initially and profitable ones are selected for further consideration. At the feasibility and definition stage, the leads are examined further by developing business cases and project specifications. Development opportunities are prioritised and this ranking is reviewed at later stages. During the planning stage the project is planned in detail until the end of Phase IIa and the rest in outline. The development stage follows the same steps as the general drug development process described in section 2.2.2. The aim of the project completion stage is to review, evaluate and learn from the development project. The project and project documentation are also officially closed and the project team is disbanded and rewarded. In the gates, project progress is reviewed and it is decided whether the project should proceed to the next stage. Thus, gate decisions are made after each stage and also when schedule, scope or budget of the project changes significantly according to predefined limits. The project must prepare a document for each decision-point and a standard template has been developed to ensure a consistent approach across projects. The
Hanna-Leena Saari
73
template includes development plans of different line organisations together with strategy and market considerations, resource plans, SWOT analysis, and risk analysis and management. Furthermore, the rationale for the new decision must be described.
CONCEPT FEASIBILITY & DEFINITION PLANNING DEVELOPMENT LAUNCH IN PROJECT KEY MARKETS COMPLETION
Concept Specification Detailed feasibility studies Outline business cases Program definition
Project/Product Specification
Development Specification Change control
Discovery GATE Competition Licensing Ideas Basic feasibility & prioritization of opportunities
Detailed time plan, resources, technical spec, manufacturing strategy & business case
GATE
GATE GATE GATE GATE GATE GATE
Figure 20. The case companys stage-gate process for drug development projects
5.3.
Project Risk Management in the Case Company
The present state of project risk management in the case company was studied by the author in a separate research reported in 2002. The unpublished research is described in outline in Appendix 7. The main findings reported in the study of project risk management in the case company are presented in the following. In the drug development projects of the case company, risks are identified at the functional program level and documented at the project level before portfolio-level decision points and presentations. Thus, actual project-level risks are not usually systematically identified. The recognition that different organisational levels manage different kinds of risks is still not wide. At present, all line organisations must assess their risks in a scale of low/medium/high for the portfolio management board briefing material. In addition to the qualitative description of the impact, risks are sometimes given an overall score that covers both the probability and impact. The approaches of risk management differ substantially between the line organisations represented in the study. Three functional departments have own systematic ways to quantify their risks. One department utilises the FMEA process, i.e. Failure Mode and Effect Analysis, see e.g. FMECA (1999), and another has implemented the Riskit process, see e.g. Kontio (1997). In the FMEA process, risks are quantified on a scale of 1-10. In the Riskit process, on the other hand, risks are assessed qualitatively on a scale of 1-5 while the third department quantifies its risks on a scale of
Hanna-Leena Saari
Start Pre-Phase I Start Phase I Start Phase IIa: POC Start Phase IIb, plan Phase III Start Phase III Start Regulatory submission
GATE
GATE
74
low/medium/high. The scales used in the portfolio management board briefing material are usually not defined leaving room for very subjective assessments. Moreover, the grade high is given to a risk very seldom: only approximately one tenth of risks are defined to pose a high risk to the project. Responses are usually planned, but responsibilities are not usually assigned. Thus, risks and the implementation of risk responses are not systematically monitored. The project manager is usually responsible for risk management. Because of the low amount of risk documentation, previously identified or experienced risks can only be utilised in risk identification, assessment and response planning by having experienced people involved in the process. After the study, the template for portfolio management board material has been updated to force the projects to assess both probability and impact of the risks and to define management activities, responsibilities and follow-up dates. However, the quality of the documents varies between projects. It also seems that in some projects this kind of documentation has not lead to actions in managing risks as much as desired. Still, the awareness of project risk management and its importance has grown in the case company. 5.4. Methodology of the Empirical Study
As already described in section 1.4, two sets of interviews accompanied with two workshops were used to gather empirical data to develop risk management in the case company. The process flow of the empirical study is presented in Figure 21. The first set of interviews, i.e. first-stage interviews, aimed at formulating a draft process for one core therapy area. The interviewees consisted of the program leader and business unit head of this area together with its project managers and experienced team leaders of all major line organisations. Altogether 15 interviews were completed at this stage. After the interviews, a workshop was held to validate and refine the process proposal. Eight of the interviewees were able to attend the workshop. Then, the defined risk management process was generalised to apply to all core therapy areas by interviewing other project managers and program leaders. In total, seven persons were interviewed. An initial proposal for tools to be used in risk management was constructed on the basis of the literature study and further refined in a workshop to which all project managers and program leaders were invited of which five were able to attend. Additionally, the participants of different stages of the study are depicted in Figure 22 and outlined in more detail in Appendix 2.
Hanna-Leena Saari

One core therapy area: - Business unit head - Program leader - Project managers - Project team members
75
First-stage First-stage interviews interviews
Process Process description description for for one one core core therapy therapy area area Workshop Workshop 1 1
Participants of the first-stage interviews
Validation Validation of of the the process process description description 2nd 2nd stage stage interviews interviews
Other core therapy areas: - Program leaders - Project managers
Generalization Generalization of of the the process process to to other other core core therapy therapy areas areas Suggestion Suggestion for for risk risk management management tools tools Workshop Workshop 2 2
All core therapy areas: - Program leaders - Project managers
Defined Defined risk risk management management tools tools for for the the case case company company
Figure 21. The process flow of the empirical study
Portfolio management board
Company level
Core Therapy Area 1 Program leader
Core Therapy Area 2 Program leader
Core Therapy Area 3
CTA level
Program leader Program level
Project manager
Program core team members Team leader Project team members Team leader
Project manager Team leader Team leader Team leader
Project manager
1st stage interviews + workshop 1
2nd stage interviews + tool development (workshop 2)
Project level
Figure 22. Participants of the study in the case organisation
Hanna-Leena Saari
76
6. EMPIRICAL ANALYSIS This chapter reports the results concerning the last study objective and applies the knowledge gained from the literature study in practice by creating a risk management framework for the case company. The results of the first-stage interviews are first described in detail, and the risk management process derived from the interviews is presented. A result of the interviews is also a further refinement of the model for risk categorisations in drug development projects. The process was validated in a workshop and the improvement suggestions of this workshop are outlined. Then, the results of the second-stage interviews are presented and, as a result, conclusions for refining the process are drawn. Last, the proposal for the risk management tools is presented together with the results gained from the second workshop. 6.1. First-Stage Interviews: Defining the Risk Management Process
The first-stage interviews were semi-structured and included questions outlined in Appendix 1. First, some general information about risks and risk management was presented for the interviewee to guarantee that the definitions were clear and that the concepts were understood in the way defined in the study. Additionally, the present state and importance of risk management were outlined to motivate the interviewee. The interview followed the flow of the stage-gate process of the case companys drug development projects. However, many interviewees were not able to see any differences in risk management at different project stages. In addition, some team members, even though very experienced, had not participated at all stages of a project. For example, the practice of having a structured project closing has been implemented only very recently and thus all project participants may not have been involved in it. Launch stage was also often skipped because of the lack of experience. Sometimes it was hard to keep the interviewee focused on the subject, while most of the interviewees were eager to tell their experiences of materialised or avoided risks. Some cultural differences also made the interview situation and workshops more challenging. It was also interesting to note that e.g. questions related to the participants of risk management, how detailed the discussion should be, and storing and reuse of documentation were found difficult to answer thus revealing lack of experience and knowledge within the area. Some reluctance to answer can also be explained with the recent changes in the case company. The answers were documented and collected to represent all the views to one question. Sometimes a persons reply for a certain question in fact matched better with another question. This was then documented to the answers of the more suitable question. The data was refined into tables that are easier to analyse. The conclusions were then drawn as combinations of the answers or by taking the most common answer as the solution. Sometimes these were complemented by insightful individual comments. Other issues
Hanna-Leena Saari
77
were discussed in the interviews, too, but these are reported only as far as risk management is concerned. In this section, reported interviews and conclusions are presented in an integrated manner, i.e. conclusions are drawn practically in every paragraph. The distinction between reported interview results and conclusions is kept as obvious as possible. The refined tables illustrating the results of the interviews are presented in Appendix 8. References to these tables are provided in the text. The goal of project risk management The interviewees felt that the aim of risk management should be in facilitating project work, i.e. planning and execution, and in decision-making, see Table 30 in Appendix 8. Risk managements contribution to decision-making was seen to be especially big at the early stages of the project, i.e. during feasibility and definition. Risk management could facilitate decision-making by giving opportunities for comparisons between projects and continued assessments of the investments viability. Risk managements contribution to enhancing project performance was mentioned a few times. However, this could be seen as an extension of supporting project planning and execution: if a project is wellplanned and well-executed, it is more likely to succeed. Some definitions for how project performance can be enhanced included making sure that the given constraints of time, cost and scope are achieved, increasing success probability, supporting the process of ensuring the compounds safety and efficacy and ensuring successful launch. Some respondents felt that product launch should no longer be a part of a drug development project thus suggesting that the project would end after the marketing approval is received. Quite many interviewees gave no answer especially considering the feasibility and definition stage and the launch stage. Often, this lack of responses is due to low or no experience of that project stage. On the basis of these answers a definition for the goal of risk management for the case company was derived to: support project management, planning and decision-making; make sure that given objectives of scope, time and budget are achieved; and support early problem recognition. What issues are discussed at different project stages Both external and internal issues were raised to be important to be discussed during risk management at different project stages, see Table 31 in Appendix 8. External issues, such as markets, competitors and regulations, were stressed especially during the feasibility and definition stage. It was interesting to note that IPR, contract and subcontracting issues were mentioned only once and that no interviewee mentioned partner risks as issues that should be considered. Schedule and scope risks were emphasised during planning and development stages. In fact, many interviewees mentioned that unexpected study results must be discussed in the project team. Examples of such studies would be efficacy, dosage, side effect and toxicology studies. Also, the ability of animal models to predict humans and whether the production
Hanna-Leena Saari
78
process can be designed effectively were mentioned as issues that should be considered during the development stage. There were only few answers considering launch, suggesting that more investigations should be directed towards that area. The answers dealt with production process issues together with availability of raw materials and the final product. On the basis of the answers it can be said that in the case company external risks are not thought to be an issue that should be discussed and monitored every day during the development stage. Still, being insensitive to changes in the marketplace and competitive environment can lead to unprofitable products even though no technical, schedule or budget risks materialise. Thus, the project manager and program leader should act as advocates of market-based thinking also when risks are addressed. The issues that should be discussed in the case companys project teams were defined broadly as those risks that affect the project objectives formulated in the project definition so that predefined limits are exceeded. Who is responsible for risk management The answers about who should be responsible for risk management at different project stages were quite unanimous, see Table 32 in Appendix 8. The program leader should be in charge of risk management at the feasibility and definition stage and the project management should take care of risk management at other stages. In fact, according to the official principle, the project manager should be dominated only at the start of the planning stage. The program leader should have a supporting role throughout the project, however. Some interviewees wanted to draw a line between what risks should be managed at the program level and at the project level stating that external risks are the program leaders responsibility and internal risks are the project managers responsibility. This division would, however, be too straightforward and restrictive to be feasible. As in the previous theme about issues that should be raised in the project team, the answers considering the launch stage were few in this question, too. There were a lot of people giving no answer to this question. In many cases this was due to the uncertainty of what are the roles of program leaders and project managers in reality and in theory. Who should participate in risk management As there is no project manager and project team nominated at the feasibility and definition stage, the program leader and program core team should take care of risk management at that stage, see Table 33 in Appendix 8. However, they may need support and information from line organisations not represented in the team. During planning and development, the project manager and the project team should be the main contributors to risk management even though some input and support may be needed from other line organisations, too. Again, the answers for the launch stage were few and thus it is difficult to say anything about it. Anyhow, it could be determined that both program core team and project team, if there still is one, should both actively participate
Hanna-Leena Saari
79
in risk management efforts. Furthermore, the participants at project completion stage will vary depending on the project. Should risk management efforts be team-based A clear consensus exists that risk management should be team-based at least until the launch stage, see Table 34 in Appendix 8. However, some interviewees think that it should rather be a combination including also individual effort in gathering functional risks. The low answer rate considering project completion stage can be explained by the interviewees low experience of the stage. Thus, it could be concluded that risk management in the case company should essentially be team-based with additional efforts individually or in functional teams. What should the time horizon for risk management be The majority of the interviewees thought that the risk management efforts, especially risk identification, should involve the entire project as the timeline of risk considerations, see Table 35 in Appendix 8. Still, as projects are planned according to the rolling-wave principle, it may not be possible to conduct very detailed analyses regarding the later stages of the project. Some other answers reflect the interviewees desire to determine how the drug development project should be defined, i.e. what its endpoint should be. Thus, the question did not provide any major new information, the answers being quite obvious. How detailed should the risk discussion be The answers for the question of how detailed the risk management discussion should be at project level were somewhat dispersed, see Table 36 in Appendix 8. A conclusion could be drawn that risks that affect the entire project and/or other line organisations should be discussed and the team leaders should consciously filter the information so that information flow is as effective as possible within the project team. When should risk identification be restarted The most common answer for the question of when a re-iteration of the risk management process should be started, i.e. when risks should be identified and assessed again, was before decision-points, see Table 37 Appendix 8. This reflects the opinion of risk management being more about supporting decision making rather than controlling and managing the project. It was mentioned a few times that risk management should be continuous and this would decrease the workload before decision-points. However, a combination of these views is needed, i.e. a continuous process is the aim. As a first step, risks should be re-analysed in more detail when needed and at least before decision points and portfolio reviews.
Hanna-Leena Saari
80
The means of achieving a continuous risk management process during development stage The main idea of the interviewees regarding how risk management could become a continuous process included both having it as an agenda item in meetings and extensive communication, see Table 38 in Appendix 8. Thus, a discussion of the top ten or twenty risks could be required at all meetings, at least at project and program levels. However, to prepare for these meetings, the issue may have to be raised in the functional teams, too. The actions that were scheduled to be started, ongoing or finished at the time of the meeting should be controlled. These two activities should, however, be complemented with effective communication. Only then meetings will be effective and reports delivered to the right persons at the right time. The project manager should be the main advocate of open and extensive communication within the project team and for other interest groups. Where should risk documents be stored The question of where the risk management documents should be stored was fruitless. The most probable storage alternative, i.e. the case companys document management system, was mentioned twice, see Table 39 in Appendix 8. However, most respondents did not answer the question at all. It could be concluded that it does not matter what the physical location of risk management documentation is as long as it is easily accessible and retrievable for all those who need it. How to ensure that collected risk information is utilised in future projects The next question regarding how to ensure that gathered risk information is used in future and ongoing projects was not too useful, either. Only four interviewees had any suggestions, ranging from proper archiving to effective communication, see Table 40 in Appendix 8. Still, the project team could be advised to check old risk management information after identifying and assessing risks to validate the completeness of the analysis in relation to previous projects. What could be used as a common measure for risk assessment enabling comparison between projects Most often, the interviewees suggested the use of monetary terms as a means for assessing risks so that comparisons between projects would be possible, see Table 41 in Appendix 8. However, it may not be feasible for all risks to be expressed in money. For example, at the beginning of the project, the effects of small delays or scope changes may be difficult to assess, while the view of the markets after 15 years may not be exact enough. Additionally, the project team may not have the competence to do the assessment by themselves. Time was also suggested as a measure, even though this may not be effective for some risks, either. The third common answer was to maintain the
Hanna-Leena Saari
81
low/medium/high assessment framework used at present. The scales should be defined explicitly and in a unified way, however. The proposed method for risk assessment for the case company generated on the basis of the literature study would suggest a somewhat more detailed impact assessment, e.g. on a scale of 1-5, and also require a verbal explanation of the impact. The scale should be predetermined and monetary and time estimates should be incorporated in the scale and the verbal explanation. This would introduce risk thinking to the case company thus facilitating the possible future transition to more quantitative assessment techniques. Where does the input for the risk analysis come from For the issue of where the input for risk management comes from, the answers were basically all the same, even though the idea was stated in different ways, see Table 42 in Appendix 8. The input for risk management inevitably comes from experts that work in line organisations, including also individuals who work in the project team. The only difference is whether risks should be first identified in line organisations and only after that discussed in the project team, or do the project team members have enough expertise to discuss these issues only in the project team. This question is hard to determine universally for all project teams in the case organisation, while the expertise and experience of project team members vary greatly, and the availability and quality of information differs between compounds and indications, too. Thus, the approach chosen may be project-specific, and should be determined when project objectives and project team composition are known. Anyhow, the importance of the project manager and program leader as sources of input should not be underestimated even though view may be less technical. Should all or only a part of risks be discussed in the project team The question whether all or only a part of risks should be addressed in the project team proved to be unuseful after already talking about issues to be discussed at different project stages, see Table 43 in Appendix 8. Thus, the question was not raised with all interviewees. Anyhow, it seems that it is not feasible to make an explicit division of what risks are discussed at which organisational levels, e.g. projects should only consider internal, operational risks while strategic and external issues are handled at the program level. In fact, the information for these discussions may come from project team members and they may significantly affect the project objectives and the way the project is conducted. Rather, project team members and the project manager must constantly assess whether the issues are relevant for the project and whether the project can affect them. Should responses be reactive or proactive Also the question whether the planned responses should be reactive or proactive provided only self-evident answers, see Table 44 in Appendix 8. The proposal for the
Hanna-Leena Saari
82
case company is to plan proactive responses always when possible and feasible, i.e. the costs for implementing responses do not exceed risk impact. Otherwise, reactive plan b:s should be planned or contingency reserves calculated. Actually, only by implementing this kind of response planning the case company would take a step forward in practising risk management. How should new risks be brought into the attention of the project manager and team The answers for the question about how new risks or spotted variations to already identified risks should be brought into the attention of the project team and project manager emphasise the importance of effective and direct communication, see Table 45 in Appendix 8. The communication should flow from the team leaders both to the project manager and to the line organisation managers, and the other way around, i.e. the project manager should constantly be active in getting information by, for example, asking questions. The ideal flow of communication begins from the project worker who should notify his or her own superior and the functional team leader about variations and new risks. The team leader, on the other hand, should inform the line organisation managers, other project workers in the line organisation that are affected by the risk and the project manager and project team. However, no formal process will be designed to describe the information flow. Rather, the project manager and team leaders should constantly stress the importance of open communication and also facilitate free information flow by being available and easy to approach. How can project workers be motivated for managing risks The interviewees were also asked to suggest actions for ensuring the adoption of risk management, i.e. motivational activities. Most interviewees regarded the implementation to pose no motivational issues, while risk management should be seen as regular project work and is essentially just another way to structure the work that is already done, see Table 46 in Appendix 8. Still, some important issues were mentioned, such as raising the awareness of risk managements importance, together with education and ensuring enough resources for the activities. It is clear that even though there are plenty of good reasons for introducing risk management and even though it is a natural activity for human beings, some thought must be given to ensure everyones motivation to the development. Extensive training should be provided to educate both project participants and users of the risk information. In addition, risk management activities should be added into the project plans to guarantee proper resourcing. Especially in the beginning of risk management implementation all tasks are bound to take more time than before. Thus, to enable proper risk identification, analysis and response planning, resources must be ensured so that the benefits of risk management could be realised.
Hanna-Leena Saari
83
When and how should risks be raised above the project level No particularly good data was obtained about when and how risks should be raised to upper organisational levels, see Table 47 in Appendix 8. It is clear, again, that open, honest and direct communication is the key for being successful with this. The only conclusion that can be drawn is that everyone should either use their own intuition or predefined scales and decision-rules could be defined to determine whether the issue should be discussed at upper organisational levels, such as in program core team meetings. Who could and should use the information generated by risk management activities, and who should be the owner of the risk management process Several parties were identified for the question regarding the possible users of risk information, more or less the entire organisation, see Table 48 in Appendix 8. However, care should be taken to ensure that the information is not used counter-productively. Some of the interviewees were also asked which department or who should be the owner of the risk management process thus being responsible for implementing and developing the process. No definitive suggestion was gained, however, see Table 49 in Appendix 8. After the latest organisational restructuring both project management department and core therapy areas department are a part of the same organisational entity. Thus, it could be suggested that the ownership could reside somewhere within that organisation. This question was further elaborated in the subsequent interviews. How public should risk management documentation be Additionally, the interviewees were asked to assess how public the information that is generated during the risk management process should be. The opinions varied a lot, see Table 50 in Appendix 8: the answers ranged from being entirely open for the whole company to being available only for the project team. It is interesting to note the contrast between answers of possible users and availability of information, i.e. if the information is not accessible, how all the identified users could utilise it. The suggestion for the case company would be to start with somewhat restricted access rights consisting of the project team and the organisational levels above both in line and project dimensions. Additionally, other project managers, and program leaders should be able to retrieve the information. This practice should then be expanded on an asneeded basis.
Hanna-Leena Saari
84
How often are there changes in the project The question about assessing the general rate of change in drug development projects gave an overall sense about how change is perceived in the organisation and how often it would be feasible to require an update of risk information. The answers are presented in Table 51 in Appendix 8. Change is perceived to be constant, even though its pace varies during the project life cycle and depends on the compound and indication in question. For bigger changes, a new decision from the portfolio management board must be obtained. Thus, a general advice could be given that risk information should updated at least before decision points and semi-annual portfolio reviews. Otherwise, the project manager and team should themselves assess the need for a new risk identification and analysis session. Additional information from the interviews: Definition of risk categories The interviews provided additions, adjustments and examples for the suggestion for risk categories presented in section 4.2, see Figure 23. Project risks were defined to be single events affecting the project outcome causing it to deviate from the predefined schedule and budget ranges. Examples of technical risks include safety risks that are always fatal, the validity of animal and analytical models used, and the compounds keeping qualities that may pose adjustments to the target product profile, i.e. project scope. In addition, regulatory risks were specified to include at least regulatory changes and product compliance issues. Project management risks could be divided into risks arising from the defined schedule, scope, budget or being managerial risks. For example, a very tight and complex timetable may be prone to delays thus initiating a project risk. The category of strategic risks was also introduced including, for example, issues of whether the project was correctly chosen and whether the defined target product profile is valid. Strategic risks were also a part of Pass and Postles (2002) model that was introduced in section 4.1 but they referred to a rather different context of business-level strategy considerations.
Hanna-Leena Saari

Clinical Pharmacokinetics Technical risks Toxicology Industrialisation/ Production IPR risks Pharmacology Formulation Analytics Process development Scientific advances External risks Scientific recommendations Markets and marketing Competitors
85
Regulatory changes Partner/subcontractor/ contractual risks
Product compliance
Launch risks
Regulatory risks
Project management Scope Project management risks Cost
Strategic risks
Schedule
Design errors
Figure 23. Adjusted model for risk categories of drug development projects
In fact, when internal documents from the previous portfolio review and portfolio management board briefing material is examined, it was possible to classify risks into these categories. All categories were used, even though the majority of mentioned risks were technical or regulatory. Launch, IPR, project management, resource and strategic risks were mentioned significantly more rarely. This depends much on the project in question, however. Anyhow, while the amount of technical risks identified was usually quite significant, these could be categorised further to clinical, pharmacology etc. risks as depicted in Figure 23. Additional information development ideas from the interviews: Other requirements and
Additionally, several other requirements and development ideas were identified for the risk management process in the interviews. It was suggested that risks should be identified and assessed for the first time at the planning stage to enable an objective approach without too much emotions and status issues being involved. Not surprisingly, some reluctance to increase workload and use new tools was apparent. However, the introduction of new practices and tools has usually been successful in project teams. The risk management process must still be as tightly as possible connected to current working practices. To enable effective working, unnecessary bureaucracy should be avoided, too. Anyhow, a concern was presented that the quality of risk analyses may be questionable if they are not validated e.g. by senior experts in the line organisations. Peer reviews could also be used for validation. In fact, if risks are first identified and validated in the line organisation, the team leader can be sure he or she has senior management support. The risk management process should facilitate the fast spotting of variations and the quick communication for all relevant parties. For this to happen, all project workers should understand what risks and risk management are, what are the projects risks and
Hanna-Leena Saari
86
who is responsible for them. This includes that it should be clear how to react to unexpected exceptions. Some kind of warning limits could be established to guide the decisions of when to take an issue forward. At the project level these limits should be predefined ranges determined on the basis of corporate risk-taking strategy that should be defined by the case companys top management. Some interviewees stated that all line organisations should use the same techniques for risk analysis to ensure the utilisation of same language and criteria. However, all line organisations are different and it may not be feasible to control their working practices too much. As some line organisations have already established formal risk management processes, as already discussed in section 5.3, it would not enhance the adoption of the new project risk management process if they were required to abandon their old processes. Still, these functional risk assessments must be converted to correspond to the risk assessments required at the project level. It was also suggested that the risk identification, assessment and response planning sessions should have a distinctive title to give them a separate identity. Then, all participants would be aware of what is going to happen and what is expected of them. The role of a facilitator was also discussed and a suggestion was made that the project manager could act as a facilitator in functional teams. This could improve the information flow between the team leader and the project manager but would also significantly increase the workload of project managers as far as risk management is concerned. If partners are involved, the risk management process may change, while risk management must cross organisational boundaries, too. The organisational level for this joint operation varies, however, depending on the project, partner and the issues discussed. Additional information from the interviews: Support for soft risk management practices Many issues raised in the interviews support the usage of soft risk management principles in the case company. For example, the importance of fast and effective communication was stressed often. There was a general agreement that risk management should essentially be a team-based activity although sometimes individual work may be needed, too. It was mentioned that even though the assessment method should be scientifically proved, the numbers themselves do not account for anything. Rather, they have to be challenged and to do this the idea behind the numbers must be revealed by intense communication. Communication is also needed when upper organisational levels are informed about project risks. The importance of knowledge management was recognised many times. For example, the validation issues rose from the fact that the project team members are often not as experienced as they should be to analyse risks properly. This initiated a thought that, in general, each project should have
Hanna-Leena Saari
87
a steering group nominated to give advice about how the project could be run, e.g. which studies should be made. In general, as the case company is small when measured in international terms, it should take advantage of its strengths. The organisation should be able to utilise informal interaction channels effectively and thus avoid too much formalisation of communication practices. Reports should be seen as complements to every-day discussions between organisational levels. Knowledge management issues are not as complex, either, as most of the employees know each other and from whom to ask if problems arise. 6.2. Suggestion for the Risk Management Process in One Core Therapy Area
On the basis of the first interviews a workshop was held to discuss the suggestion for the risk management process in one core therapy area. All first-stage interviewees were invited and eight of 15 were able to attend. The aim was to present the risk management process developed on the basis of the interviews and to validate and refine it. First, the drafted process was presented, after which all participants were given approximately five minutes to think about the good and bad points of the proposal and create their own improvement suggestions for the shortcomings. Then, two groups were formed on the basis of the persons physical location, while the workshop was held as a videoconference in two different cities. The groups were to form a synthesis of the participants own improvement suggestions and then present these to others. Finally, there was discussion about these improvements. The comments expressed during the presentation were written down and the participants documented their synthesis to slides. In this section, the process draft is first presented followed by the improvements done after the workshop. After that the comments of workshop participants are reported. The idea in developing the process was that it should be integrated both to the project management and stage-gate processes of the case company. The project management process developed for the company follows basically the process described in Project Management Institutes (2000) standard. This process and how the proposed risk management process relates to it is depicted in Figure 24. Even though two different processes have been depicted, the intention is to have the risk management process integrated into the project management as an essential component. The risk management process is basically the same as suggested in section 3.2.1 to be the generic risk management process. Only initial risk analysis is added for decision-making purposes. It can be seen that initial risk analysis consisting of high-level risk identification and assessment takes place during the initiating phases of the project. Risk management is planned during project planning. Then, risks are also thoroughly identified, assessed and responses planned. During project execution and monitoring, risks are monitored and controlled, and when the project is closed, risk management is closed, too. The loop back to risk identification, assessment and response planning is
Hanna-Leena Saari
88
partly synchronised with the loop back to project planning. For example, before decision points, i.e. starting another stage, the plans for the stage are refined according to the rolling-wave planning principle. However, as described next, risk management may loop back at other times, too.
Executing Processes Initiating Processes Gate to planning Planning Processes Monitoring Processes Closing Processes
Project management process
Risk management process
Risk management planning Initial analysis Gate to planning Identification Assessment Response planning
Monitoring and control
Closing Processes
Initiating Processes Initial analysis
Gate to planning Gate to planning
Risk management Planning planning Processes Identification Assessment Response planning
Executing Processes Monitoring and control
Monitoring Processes
Closing Processes Closing Processes
Figure 24. Case companys project management process in relation to the proposed risk management process. The intention is that instead of two separate processes, these would become one integrated process.
The case companys stage-gate process is depicted in Figure 25 in relation to the proposed risk management process. In the figure the box titled RA, RP means the iteration back to risk identification, assessment and response planning from the monitoring and control phase. As can be seen from the figure, initial risk analysis should be conducted already at the feasibility and definition stage. At the planning stage, risk management is also planned together with the first thorough risk identification, assessment and response planning. During the development and launch stages, risks are monitored and controlled and a loop back to risk identification, assessment and response planning is done always before decision-points. Risk monitoring and control should induce ad hoc decision-points, e.g. when new risks are identified, big risks
Hanna-Leena Saari
89
materialise or when the trigger events of fatal risks occur. At the project completion stage also risk management issues are closed. Additionally, not depicted in the picture, the loop back to identification, assessment and response planning, i.e. to the thorough updating of risk information, is needed prior to the semi-annual portfolio reviews.
Concept Feasibility & Definition Planning Start Pre-Phase I Development Launch in key markets Project completion
Start Phase I
Start Phase II
Start Phase IIb, plan Phase III
Initial analysis
Gate to Planning
Risk mgmt planning Identification Assessment Response planning RA, RP RA, RP
Monitoring and control RA, RP RA, RP RA, RP RA, RP RA, RP RA, RP RM closing
Figure 25. Case companys stage-gate model in relation to the proposed risk management process. The box RA, RP means the iteration back to risk identification, risk assessment and response planning.
Even though the scope of this study was to develop risk management at the project level, an attempt to draw some limits between program and project-level risks and risk management was made, because most of the interviewees clearly wanted more clarity for this. Still, the case company should be aware of the limitations of such definitions: especially during the current organisational changes the definitions must be validated very often, if they are used at all. In Table 11, the goal of risk management is stated both at the project and program levels, together with a description of issues that should be addressed, and a definition of responsibilities and participants.
Hanna-Leena Saari
Start Regulatory submission
Start Phase IIa: POC
Start Phase III
90
Table 11. The goal, issues, responsibilities and participants of risk management at program and project levels Project level Goal Support project management, planning and decision-making: make sure that given objectives of scope, time and budget are achieved and support early problem recognition. Risks affecting the project objectives described in the project definition so that predefined limits are exceeded. Project manager Project team and line organisations Program level Support in planning and decisionmaking: is this business case viable, what risks can be influenced, are project and program objectives achieved? Life-cycle view: issues affecting the overall profitability of the program and the business case of the project. Program leader Program core team
Issues discussed
Responsibility Participants
The initial risk identification and assessment, as defined earlier, takes place at the feasibility and definition stage and is a part of project initiating activities. The aim of this is to identify the biggest risks already during feasibility study so that the decision to proceed to planning can be made based on more complete information. Risks should be assessed very roughly regarding their probabilities and impacts. It should also be assessed whether it is possible to manage the risks in question. The analysis should remain at a level representing the information that is known at the time. For example, before project planning is begun, schedule risks can be addressed only with regard to how small the window of opportunity is for the product launch. The program leader should be responsible for this stage, while the project has not yet been initiated. Risk management is planned when the project is planned, too. The inputs needed for risk management planning are at least the project definition including project objectives, the project team, and the roles and responsibilities within the team. This study also offers several tailored tools and methods to choose from. As the output, a short risk management plan is written. It could address the issues of risk management scope, methodology, roles and responsibilities, timing and budget, scores given and their interpretation, thresholds, reporting formats and risk tracking practices. The way most of these issues might be approached is proposed already in this study, but they should, naturally, be adapted to the project at hand. These issues could be discussed at one of the initiating meetings of the project team and then documented by the project manager. The input, output and actions of project risk management planning are outlined in Table 12.
Hanna-Leena Saari
91
Table 12. Input, output and actions of project risk management planning in the case company Risk management planning Input Actions Output Project definition. Team, roles and responsibilities. Suggested methods and tools to choose from. Discussion at a project team meeting. Risk management plan (management scope, methodology, roles and responsibilities, timing and budget, scores given and their interpretation, thresholds, reporting formats and risk tracking practices).
Risk identification, assessment and response planning should also be conducted during project planning. Thus, responses can be included in the final schedule and the budget can be modified to account for responses and contingencies, too. This phase is repeated several times during the project life cycle, but the first time will probably be the most time-consuming and the subsequent iterations should be more directed towards updating the initial analysis. As an input for this, the project definition and risk management plan are needed together with basic project assumptions. The work breakdown structure, schedule and budget are also necessary. Experiences from previous projects should be utilised if possible, too. Finally, depending on the approach chosen, risk lists of all line organisations may be required. There are two possibilities for how to approach the risk identification and assessment: each line organisation may first gather their contribution to project risks and then these analyses are discussed in the project team, or the project team identifies the risks themselves. The approach should be chosen on the basis of the project team composition and the project in question. Whatever the approach chosen, the output of this phase should be a common agreement of the projects risks, their assessment and the responses that will be implemented. This should be achieved by the means of team work. All risks should be first identified together with their triggers and categories, their interrelationships modelled, they should be assessed in terms of impact, probability, time-criticality and manageability. Then, response strategies should be defined for all risks, e.g. if the risk should be handled elsewhere, the transfer strategy could be chosen, or if the risk is negligible, it can be accepted as such. Risk response actions and their schedules are planned and responsibilities are assigned for their implementation and for monitoring and controlling the risk. Furthermore, residual and secondary risks should be estimated. Thus, a prioritised list of risks and response actions to these are defined as the output of this phase. As a by-product, the understanding of the project as such should be enhanced, too. The input, output and actions of project risk identification, assessment and response planning are outlined in Table 13.
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 13. Input, output and actions of project risk identification, assessment and response planning in the case company Risk identification, assessment and response planning Input Actions Output Project definition (incl. project objectives) and assumptions. Work breakdown structure. Schedule. Experiences from previous projects (lessons learned and tacit knowledge). (Functional risk analyses). (Discuss risks of all line organisations and) identify new risks. Identify trigger events and categorise risks. Find interdependencies and root causes. Assess risk impact, probability, time-criticality and controllability and prioritise risks.
92
Determine response strategies, response actions, schedules, assign responsibilities, identify residual and secondary risks. Identified and prioritised risks. Risk response plan. Better understanding of the project.
Risks are monitored and controlled as a part of project execution and monitoring during development and launch stages. The outputs of the previous risk management stage are needed for this together with the knowledge of the present state of the project, its activities and environment. Risks are monitored and controlled by intense and reciprocal communication between the project workers and team leader, team leaders and project manager, team leader and functional head, and project manager and program leader. Naturally, information flows also from different sources and by different routes, but these are the flows that at least must be ensured and supported. Risks should be discussed at all project team meetings to check whether something has happened at least for the biggest and most time-critical risks, whether response actions are taken as planned and whether they have the planned effect on the risks. Also, new risks that have been identified and the necessity of a loop back to risk identification should be discussed. Additionally, risks should be regularly reported to management both at the project and functional organisations. Risk lists should be updated continuously during the project. Thus, updated risk lists together with the decision to return back to risk identification are results of the monitoring and control phase. The input, output and actions of project risk monitoring and control are outlined in Table 14.
Hanna-Leena Saari
93
Table 14. Input, output and actions of project risk monitoring and control in the case company Risk monitoring and control Input Actions Output Identified and prioritised risks. Risk response plan. Knowledge of present situation of the project, its activities and environment. Find out if something has happened at least for the biggest and most time-critical risks. Find out if response actions are taken as planned. Find out if the implemented responses have the planned effect on the risks. Update risk lists stored in a database. Updated risk lists. Decision to loop back to risk identification.
Risk management closing is a part of project closing activities. Then, a final update for risk management information is performed to describe what actually happened during the project. This information is then closed in the risk database. In addition, the risk management processes and tools are developed further if the need arises. For example, the accuracy of the risk assessments should be evaluated and reported to facilitate better assessment in other projects. The project manager is responsible for this stage, but is supported by the program leader and project team members. The input, output and actions of project risk management closing are outlined in Table 15.
Table 15. Input, output and actions of project risk management closing in the case company Risk management closing Input Actions Output Risk lists and response actions. Update risk management information to describe what actually happened during the project. Close the risk register of the project in the risk database. Refine the risk management process and tools if needed. Lessons learned information regarding risk management process and tools.
As a summary, the responsibilities of project managers, team leaders, i.e. project team members, and program leaders are outlined in Table 16.
Hanna-Leena Saari
94
Table 16. Responsibilities of project managers, team leaders and program leaders in the case company regarding risk management Project manager Makes sure that projectlevel risks are managed. Communicates intensively with all project workers and other stakeholders, e.g. the project team members, program leaders, program core team members etc. Inter-functional risk owner at project-level. Updates risk lists. Encourages open communication, ensures a blame-free atmosphere, facilitates team working. Program leader Responsible for managing Program-level and program risks. Active communication with project manager and upper managerial levels about project and program risks. Inter-functional risk owner at program-level. Takes care of the initial risk identification and assessment at feasibility and definition stage. Takes issues forward if necessary. Supports the project manager and project team in risk management. Team leader Communicates actively with the line organisation and other project team members. Participates actively in project risk analysis sessions. Brings knowledge of functional risks and validates the analysis in the line organisation. Intra-function risk owner. Finds out if variations have occurred and acts according to plans: implements response actions/informs others/etc.
Several advantages and shortcomings of the proposal were identified in the workshop. One advantage of the proposed process was its continuity together with its approach that takes into account the several levels of the project organisation. The involvement of experts and line organisations in the analysis was seen to be important, as was also the definition of the team leaders essential role. The risk database into which all risks would be gathered was also supported. The suggested formal process forces projects, at first, to address risk management and especially also monitor and control them, which was perceived to facilitate the realisation of the benefits of risk management. On the other hand, the difficulty of distinguishing between project and program-level risks was identified, even though more detailed definitions was also requested. The risk management process was also perceived to be too formal and complicated to facilitate efficient issue resolution. No improvement suggestions could be formed, however. The functional-level risk management was perceived to have a too minor role in the process, while most risks will materialise there. Because this is out of the scope of this study, the development effort of risk management should, after implementing risk management at the project level and collecting experiences for some time, continue to place more attention to the line organisations. It was also stressed that risk information must be distributed widely and openly. To facilitate this, positive aspects could be included in the reports, too. In general, the reward aspect of risks should be stressed more. A
Hanna-Leena Saari
95
suggestion was also made to use some kind of examples when implementing the process: this might enhance the motivation of project workers to manage risks. Thus, as can be noticed from these comments, the process proposal received mixed feedback. Some issues were seen both as advantages and shortcomings, such as process formality and the division of project and program-level risks. In the future, the further development of risk management should also address the program and functional levels in more detail as in this study. Risks should be addressed in a positive way in reports and, as much as possible, the potential positive effects of risk management activities should be stressed. However, no improvement suggestions were given to the risk management process itself. The only tangible proposals regarded implementation and reporting. The necessity of the division between project and program-level risks and risk management still remained uncertain. 6.3. Second-Stage Interviews: Generalising the Process to Comprise Other Core Therapy Areas
In the second-stage interviews those other project managers and program leaders that did not participate in the first round were interviewed, totalling up to seven interviewees. In these interviews, the proposal for the first core therapy areas risk management process was presented and discussed. In fact, the persons in charge of projects in another organisational entity were interviewed, too. Their projects focus on developing generic drugs and product improvements. The process for developing generic drugs is basically the same as in proprietary drug development. However, it is faster and the main risks include those related to IPR issues and the success of commercialisation. The interviews could be characterised as open-ended interviews involving a presentation and informal conversation. As the proposed process was presented, the interviewees were asked to comment it and suggest improvements. The interviews were more difficult to analyse than the first-stage interviews because of the open-ended nature. The comments were documented during the interview and codified into categories representing the main meaning of the comments. Now, these answers are reported with the help of these categories. The basic risk management process proposed was supported and seen as natural and correct. Its formality was perceived to enhance the quality of project working in general, too, while it would force all line organisations to consider risks. Risk monitoring in meetings was also seen to be relevant. However, if risk management information must be updated before portfolio reviews and gate decisions, the meetings must be synchronised with these events. For the interviewees, this seems to be a natural development. The starting of risk management already at the planning stage was supported, too. One reason was that at this stage the project team can still be objective
Hanna-Leena Saari
96
and, thus, the assessments are more reliable and it is also still possible to affect the project. The definition of the issues to be discussed was perceived to be relevant. Still, it is important to include, for example, launch risks already from the beginning. Assigning the biggest responsibility for risk management to the project manager was agreed on. In fact, the responsibility descriptions were praised for outlining also more obvious responsibilities, such as communication, to stress their importance in the projects. It was also seen vital to explicitly require the team leaders to communicate both with their operational line managers as well as the project manager, while often the link with either is much stronger than with the other thus limiting the amount of communication in the other direction. Forcing the documentation of risks was perceived to be relevant, too, because it leaves a track of what was known and assumed when a go-decision was made. In general, this kind of a process was perceived to facilitate also taking actions with regard to risks and not just discussing them in meetings. However, one should be prepared for issue and crisis management, while the case company is still so young in proprietary drug development that all risks cannot be anticipated with its experience. The interviews produced several improvement suggestions and ideas to the risk management process. First, the use of outsiders was perceived to be important in the process. They could both facilitate the risk sessions in the teams and also validate the assessments. This was seen especially valuable in the beginning of the implementation of the risk management process. For example, it was suggested that project managers and program leaders could facilitate risk analysis of other projects thus improving the information flow between projects and perhaps even keeping the assessments more in line with each other. On the other hand, the project manager could facilitate the risk identification sessions in the line organisations. The process and tools should, however, be so easy that the line organisations can, after a while, master these on their own. When assessing risks, the facilitator should be cautious about making a distinction between risk effects and risks, while it is impossible to assign probabilities and impacts on risk effects and thus a lot of time can be wasted. As some line organisations already have their own way to identify risks, they should not be forced to do things in the same way as other line organisations, even though the output for the project is expected to be similar. Thus, an opportunity to have a facilitator in risk identification sessions should be offered for the line organisations, but their use should not be required. Second, it was unanimously perceived to be better to first identify risks in line organisations and only after that discuss them in the project team: this would be the only way to reach the needed level of insight, while the input comes mostly from the line organisations. Then, the operational line risks would also have the operational line managers approval and support. The team leaders could themselves decide who should take part in the risk identification of their line organisation.
Hanna-Leena Saari
97
Third, three different ways to validate the risk analyses were suggested. The risk assessments could be taken back to the functional teams from the project team and validated there, or then the line organisation manager could approve them. Finally, the project manager or program leader of another project or a complete outsider could challenge the assessments thus validating them. While the line organisation manageer should be informed about the project risks anyway, this could also be a possibility to easily validate the assessments. Additionally, the validity of the results would increase if outside facilitators were used. Fourth, updated risk management information should be a requirement for getting a godecision from the portfolio management board. For the risk documents to be easily updated, verbal impact descriptions are needed. Then, the reasoning behind the assessments is clear even after some time has passed. The cost and time impacts of responses should always be assessed so that it will not be more costly to avoid or mitigate risks than to take them. It was perceived to be important to incorporate response actions into the project schedule to ensure their implementation. However, there might be activities that are such in nature that they cannot be included in the project schedule. Then, an action list could be constructed to include all of these in one place. The risk lists should also be incorporated into the project master documents, i.e. the project plans. Finally, it was stated that discussing risks in all meetings would be too much. This depends naturally much on the project and its stage. However, addressing risks in every project team meeting can still be recommended, even though some flexibility must be allowed. While all line organisations have different ways to communicate and report, the only advice that can be given is that every project team member is responsible for communicating all necessary information for all necessary parties. However, for the communication about risks to be open, everyone must have the right attitude towards it. For example, management must make it clear that good and honest risk assessments are valued and no project should be punished just for discussing risks. For the implementation of the process, some suggestions were given. First, the entire organisation should be trained to deal with risks starting with project teams. It is also important to stress the advantages and reasons for implementing risk management. Furthermore, an owner must be determined for the process. It can be concluded that in its outline, the process developed for the first core therapy area can be easily generalised to involve all other core therapy areas, too. In addition, some changes and additions were suggested. These are outlined in Table 17. Some other more general improvement suggestions were given, too, that dealt with project team composition, communication and implementation of the risk management process.
Hanna-Leena Saari
98
Table 17. Improvement suggestions for the proposed risk management process derived from the second stage interviews Improvement suggestions Use an outside facilitator Risk identification first in line organisations a default Validation Other project managers or program leaders in project teams. The project manager in line organisations. Exceptions allowed for this practice. Line organisation maneger heads should validate the risk assessments when they receive normal risk reports from the projects. Use of other project managers and program leaders as facilitators. An updated risk list required. Include verbal risk impact descriptions. Assess cost and time impacts of responses. Incorporate into the project schedule as separate tasks when possible. Action lists for other responses. Functional, project and program risks outlined in project plans. Flexibility allowed for this practice. All risks cannot be anticipated with the current amount of experience.
Decision points Risk assessment Response action decisions Response actions reported Risk lists Risk monitoring and control in all project team meetings Be prepared for crisis management
6.4.
Workshop: Refining the Risk Management Tools
The aim of the second workshop was to discuss the risk management tools that were developed to suit to drug development projects on the basis of the literature study and adapt them to suit the needs of the case company. This section begins with a presentation of the suggested tools and concludes with the results of the workshop. The results consist of the decisions made in the workshop of how to refine and complement the suggested set of tools. Figure 26 outlines the set of tools suggested for the different phases of the risk management process agreed upon during the previous interviews. The process phases are the same as in Figure 24 presented in section 6.2. Additionally, almost all of these tools were presented already in Figure 16 depicted in section 4.4.5. A template is developed for the initial, high-level risk analysis completed at the feasibility and definition stage. A template document is also prepared for the short risk management plan. Detailed instructions are prepared for how the workshops, in which risks are identified, assessed and responses planned should proceed. Risk categories are provided
Hanna-Leena Saari
99
to facilitate the categorisation of risks and to ensure that all aspects of risks have been considered. Diagramming tools should be used, too, to depict the relationships between risks. During the risk assessment phase, predefined scales for impact and probability are utilised, together with probability-impact matrices. Several risk response strategies are offered from which the project team can just choose the most suitable one. Probabilityimpact matrices can be used to illustrate the risk situation after the responses have been implemented. For monitoring and controlling risks, risk status categories are defined. Some risk report templates are defined, such as top ten or twenty lists, and action lists. Risk register facilitates risk documentation and processing throughout the process, from risk identification until risk management closing. During risk management closing, information from the risk register is updated for the last time and closed in the risk database. All these tools are discussed in more detail in the following.
Initial risk analysis
Template
Risk management plan
Risk identification
- Workshop instructions - Risk categories - Diagramming - Risk register
Risk assessment
- Impact and probability scales - Probability-impact matrix - Risk register
Risk response planning

- Response strategies - Probabilityimpact matrices - Risk register
Monitoring and control

- Risk status definitions - Reporting tools - Risk register
Plan template
Risk database
Figure 26. Risk management process and the tools used in different phases
A suggested template for the risk analysis at the feasibility and definition stage is presented in Table 18. It is derived from the issues outlined in Figure 16 in section 4.4.5. Only the most relevant issues for the decision-makers were selected. For example, at this point, it is not yet feasible to decide how the risks should be managed, but rather can they be controlled at all. The assessment scales are only defined to be low/medium/high to keep the analysis at a general level. However, this means that projects cannot be compared with each other with regard to their level of risk. Risk category is also suggested here, to facilitate as complete an analysis as possible.
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 18. Template for the initial risk analysis ID Risk description Risk category Impact (Low/Medium /High) Impact: verbal description Probability: (Low/Medium /High)
100
Control (Yes/No)
Table 19 presents the suggestion for the contents of the risk management plan template developed. It was derived on the basis of Project Management Institutes suggestion presented in section 3.2.2. The aim is that the document as such should be as short as possible, even though it is important that these issues are addressed in a project team meeting.
Table 19. Contents of the risk management plan Risk management plan 1. 2. 3. 4. 5. 6. 7. 8. 9. Scope of risk management Methodology Roles and responsibilities Budgeting Timing Scoring and interpretation Thresholds Reporting formats Tracking
Workshop instructions include the order in which the discussions should proceed, i.e. from identifying all risks, assessing them and developing responses one by one starting from the intuitively biggest risks. Also, all the tools and their use are presented in the document. The preliminary suggestion for risk categories is the same as defined on the basis of the first-stage interviews and illustrated in Figure 23 in section 6.1. From these categorisations, it should be possible to draw a chart depicting how many risks have been identified in each category, see Figure 27. The number of identified risks, i.e. height of the pillars, is only exemplary for descriptive purposes. The number of identified risks does not represent the importance of the risk. If there are categories with no or very few risks, attention should be directed towards these. It should be noted,
Hanna-Leena Saari
101
however, that there can be projects in which, with good reasons, there are no risks in certain categories.
30 25 20 15 10 5 Project management Technical Resource Strategic External Partner 0 Number of identified risks
Figure 27. An example of a chart for completeness check. The height of the pillar resembles the number of risks identified in each category
A diagramming technique should be used for depicting the relationships between different risks. There is a software tool in use in the case company that allows for example the use of cause-effect diagrams and relations diagrams, see e.g. Figure 28.
Risk 1 Risk 2
Risk 3
Risk 4
Risk 5
Risk 6
Risk 8
Risk 7
Figure 28. An example of a relations diagram
In the risk assessment phase, a scale from one to five is suggested to be used both for impact and probability assessments. Probability-impact matrices are drawn on the basis of these, see Figure 29.
Hanna-Leena Saari

5
102
Impact
1 1 2 3 Probability 4 5
Figure 29. Probability-impact matrix depicting the amount of risks in each impact and probability
As predefined response strategy alternatives, the possibilities outlined in Table 9 in section 3.2.5 are suggested. This list may, however, be unnecessarily long. Probabilityimpact matrices can also be used in response planning for describing the changes in risk impact and probability after the responses have been implemented. An example of such a matrix is presented in Figure 30.
5
Impact
1 1 2 3 Probability 4 5
Figure 30. An example of a probability-impact matrix in which the effects of responses are depicted
As already stated, the response actions should be incorporated into the project schedule. This should be done manually, while no automatic linkage will be developed to connect the risk register and project schedule. The risk lists should be attached to the project plans. In addition, the risk register should be stored in the case companys document management system with proper access rights. For the monitoring and control phase, risk status definitions must be determined. An initial suggestion for these is presented in Table 20. Risk report templates must be defined consisting of top ten or twenty risks taken from the risk register and probabilityimpact matrices to depict the entire risk position of the project. However, it is not necessary to include all available information to these reports, while they are not used by the project team but by the upper management. Information available in the reports
Hanna-Leena Saari
103
should include risk description, risk impact and probability, time criticality, planned response actions, responsible person and risk status.
Table 20. Proposal for risk status definitions Risk status 1. 2. 3. 4. 5. Identified Assessed Responses implemented Occurred Avoided
The risk register should be a table including all issues depicted in Figure 16 in section 4.4.5. These should be defined for all risks. Ideally, the risk register could be a tool that automatically generates visualisations and reports used in the risk management activities. It could be structured as a database and should enable the use of different filters so that, for example, probability-impact matrices could be presented that include only certain risk categories. In the risk management closing phase this risk register should be closed to represent the actual progress of the project and its risks, i.e. what risks materialised and what their effects were, what risks were avoided or mitigated and how etc. This risk data should be stored in the case companys document management system where everyone has access to it. These tools were presented for the program leaders and project managers in a workshop that aimed at refining the suggestion, for example, by defining assessment scales, risk categories and response strategy alternatives. Those who were unable to attend the workshop were interviewed afterwards to get their input to the development, too. The results of this workshop will be described in the following. In the workshop, the proposed tools were presented and discussed. Some definitions were determined and the implementation of the risk management process and tools was discussed. In general, the risk management tools were agreed on and perceived to be valid. However, at the present situation, there is not enough time to undertake all the practices suggested. Especially, the issues to be defined for all risks were reduced to include only the most essential attributes. Thus, after the enthusiasm of applying sophisticated methods in the interviews was over and constraints of the reality were evident. It was still determined that the suggestions were relevant and they should present the goal for the development of risk management practices, even though at first it is only implemented partly. The aim is, however, to enable the recognition of risks even with small project management resources.
Hanna-Leena Saari
104
The suggested initial risk analysis form was thought to be fine and usable. The template for the risk management plan was accepted, too. However, it was suggested that as long as the standardised methods that are agreed on at present are used, they do not have to be addressed in the plan. Of the items that should be defined for each risk, response strategy, residual and secondary risks were discarded. The probability and impact scales were kept as low/medium/high as done before in the case company. Specific definitions for these were determined, however. Anyhow, it should be kept in mind that when this kind of an assessment scale is used, projects cannot be compared with each other. It was suggested that when huge risks arise that are about to kill the entire project, they could be analysed by using all the different attributes suggested. The proposed risk categories were perceived to be fine, even though it was determined that during their use they will probably be refined further. The completeness check was approved and regarded as useful if it is easily obtainable. Risk diagramming was also thought to be applicable especially for fatal risks, even though it most probably will not be used in regular project work. The probability-impact matrices were perceived to be excellent in depicting the overall risk level of the project. The matrices proposed to be used for checking risk response effectiveness was approved to be useful. However, they cannot be used while residual risks will not be defined. Risk status definitions were also refined to suit the way projects are managed in the case company. The suggested reports were approved. The possibility for manual input was also appreciated. Furthermore, the closing processes were approved. For the implementation of the risk management process and tools, a project currently at the beginning of the planning stage was chosen to be a pilot project. In this, both project and program level risks will be identified using the tools. Additionally, the risk management process owner was appointed. 6.5. Summary of the Empirical Study
In the empirical study, two rounds of interviews and a workshop were held to define a risk management process for the case company. Additionally, one workshop was arranged to refine the tools derived from the literature to the needs of the case companys drug development projects. First, a risk management process was defined and validated for one core therapy area. The process was tightly linked with the project management and stage-gate processes of the drug development projects. Then, the process was generalised to all core therapy areas by including insights of representatives from all therapy areas. The advantages of the defined process were stated to be the its continuity, it taking into account several levels of the project organisation, its transparency, explicitness and formality. Many interesting additions and improvement suggestions were presented. For example, it was stated that if risks are identified and assessed already at the planning stage, the results could be objective, while at the later
Hanna-Leena Saari
105
stages so much personal issues are at stake that the assessments may well be somewhat unreliable. Validation was demanded for the assessments e.g. from line organisations. The use of an outside facilitator, such as the project manager of another project, was also suggested several times. Additionally, the application of the soft risk management approach was supported by the emphasis placed on communication and knowledge management. Still, even though a risk management process is defined and implemented, the case company should be prepared for crisis management, while it has such a short history of proprietary drug development that it may be impossible to identify all or even most of the risks. Several tools were proposed for the project managers and program leaders of the case company in a workshop. These were regarded as useful and thus received partial validation. However, the proposal had to be adapted significantly to correspond to the available resources. For example, risk impact and probability will be assessed only on a scale of low/medium/high, and residual and secondary risks, risk owners and response strategies are left unaddressed. A risk categorisation was refined from what was concluded on the basis of the literature study and initially validated in the workshop and in a review of past risk documentation. The assessment scales were defined together with risk status statements.
Hanna-Leena Saari
106
7. DISCUSSION AND CONTRIBUTIONS OF THE STUDY The literature study aimed at developing a best practice framework for managing risks in pharmaceutical projects, while the empirical study attempted to apply this knowledge to develop a model for risk management for a case company operating in the industry. The purpose of this chapter is to compare these two studies and examine the differences between them. The aim is to ensure that the research problem is answered. This includes also the presentation of managerial implications, and the assessment of validity, reliability and generalizability of the study and its results. Furthermore, the contribution of the study to the theory and practice is evaluated and topics for further research are suggested. 7.1. Discussion
A generic process for risk management was developed during the literature study, see section 3.2.1, and it was adapted to suit the practical needs of the case company. The process incorporated an explicit loop back to risk management planning and identification from the monitoring and control phase. This feedback loop is especially important in drug development projects: it ensures the continuous updating and reevaluation of risk information during the project, which is essential in such long-lasting projects. A slight modification was constructed for the process when it was adjusted into drug development projects. It was noticed that an initial risk analysis is needed already before a decision is made to start the planning stage of a project, because even that stage requires a considerable amount of time and resources. This stage should be added to the generic risk management process introduced earlier, while the drug development process is generic to all projects in the industry and it can be assumed that there is a planning stage in all projects. In addition, a risk management closing phase was added to comprise the activities that have to be done to close risk management efforts in the same manner as other project management practices. Thus, the generic process is modified to correspond to the requirements of the industry. Figure 31 illustrates the process also distinguishing the specialities of drug development projects. This process was accepted to be used as such in the case company, even though it was developed further to incorporate e.g. role and responsibility definitions.
Hanna-Leena Saari

Initial risk analysis
107
Gate to planning Risk management plan Risk response planning Monitoring and control
Risk identification
Risk assessment
Figure 31. Generic risk management process for drug development projects. The process phases written in italics are added to the process because of the special characteristics of the pharmaceutical industry.
Another part of the risk management framework constructed on the basis of both literature and empirical studies was a model for risk categorisation. A first suggestion was drafted on the basis of the literature study and then refined in the empirical study. The interviews provided many examples of risks in different categories. Furthermore, strategic risks were introduced.
Clinical Pharmacokinetics Technical risks Toxicology Industrialisation/ Production IPR risks Pharmacology Formulation Analytics Process development Scientific advances External risks Scientific recommendations Markets and marketing Competitors
Regulatory changes Partner/subcontractor/ contractual risks
Product compliance
Launch risks
Regulatory risks
Project management Scope Project management risks Cost
Strategic risks
Schedule
Design errors
Figure 32. A model for risk categorisations in drug development projects
For the risk management tools and methods selected on the basis of the literature study, an acceptance was gained in the case company, but only in principle: the tools were considered as applicable, but not good enough to devote the time and resources needed for their implementation. The set of methods proposed is depicted in Figure 33 with the insight of what parts were left unimplemented in the case company. The issues that
Hanna-Leena Saari
108
were not adopted are marked with strike-out and the ones that were changed are written in italics. The assessment scales were altered, and response strategy, risk owner together with secondary and residual risks were disbanded. Next, the reasons for the case company not wanting to adopt all tools are examined and it is discussed whether these reasons could be true for all companies in the pharmaceutical industry.
(Joint) Impact (low/medium/high)
Controllability (Yes/No)
Time-criticality (date)
High-level checklists + Applied NGT + Diagramming
Figure 33. The proposed issues to be defined for all risks during the risk management process and associated tools in comparison with the items to be implemented in the case company. The issues that were not adopted are marked with strike-out and the ones that were changed are written in italics.
One of the most practical reasons for abandoning part of the suggested methods was the lack of resources for this endeavour. In the beginning the implementation of these practices is bound to take time from usual everyday duties of project team members and program managers. If all the suggested issues were considered, the entire process of identifying, assessing and defining responses to the risks might prove to be extremely long and time-consuming. The size and complexity of a drug development project multiplies the amount of identified risks thus also increasing their processing time. This fact is interesting, while the suggested tools represent the low end of the methods presented in the literature, i.e. there are many methods that are more sophisticated and detailed. The question remains, do any companies have enough resources in practice to do these sophisticated analyses repeatedly during their large projects. Another issue to
Hanna-Leena Saari
Risk ID 1 2 3 4 5 ...
Risk 1 Risk 2 Risk 3 Risk 4 Risk 5 ... Monitoring and control Top-ten/twenty lists + Probability-impact matrix + Action lists
Risk identification
Description
Trigger
Response strategy
Response action(s)
Schedule
Responsible person
Risk owner
Residual risk
Secondary risk
Risk status
Probability (low/medium/high)
Qualitative analysis + Probability-impact matrix
Impact (Verbal description)
Risk assessment
Response planning Corporate risk-taking strategy + Probability-impact matrix
109
be considered is whether any companies in the industry have enough resources to implement the suggested framework or is the case company an exception. As was stated in section 5.3 risk management has not been practised for long in the case company. This may have also affected the preparedness of the organisation to adopt all the tools and methods suggested. Project management discipline has been structured only for some years thus suggesting that the maturity level of project management is still developing. For example, secondary and residual risks are somewhat difficult concepts as such and their use might require training. Perhaps in an organisation that has a longer history of project management and enough resources to be provided for risk management, the proposed framework could be adopted as such. However, as described in the literature study the project management discipline is not that mature in the entire industry. To assess this issue further, the maturity level of the case companys project management compared to other companies in the industry should be known. One further concern that should be addressed is whether this set of methods and issues defined for each risk is an optimal and effective combination. On the basis of the literature a minimum set of methods was derived to allow for the less mature level of project management in the industry. After that, the list was reduced in the case company on the basis of project managers and program leaders knowledge gained during practical application of project management. Thus, the selection of issues and methods was not based on scientific facts but rather on project practitioners own intuition. This is naturally a valid selection method with regard to the case company but no generalisations to the entire industry can be made based on this. Furthermore, the natural tendency of human beings is to resist change, which should also be taken into account when assessing the validity of the decisions. Generic approaches to risk management in drug development projects were also discussed. A soft approach was taken for risk management, mainly because of the highlighted need for communication, team work and knowledge management in the long, risky, big and complex drug development projects. This approach was also supported by the finding of a less mature level of project and risk management in the pharmaceutical industry. Thus, the risk management approach should mainly focus on effective team working, communication, knowledge management and interproject learning. The proposed tools and methods are qualitative in nature. Figure 34 illustrates these issues.
Hanna-Leena Saari
110
Need for risk management training Project length Knowledge management Initial risk analysis Risk level Team work Formal process Complexity Communication between organisational layers Top management support Projects Project management
Figure 34. Issues to be taken into account in organising and implementing risk management in drug development projects.
Even though risk management was here described as a distinctive process, it was noted that it should in fact be an integral part of project management and stage-gate product development processes. The formality of the process should rather be understood as a model of the steps needed and the order in which they are to be taken. Thus, risk management should not be considered as a separate entity of work but rather an additional point of view to project planning, execution and follow-up. Moreover, risk management brings new issues and questions to consider in gate decisions: for example, have the risks been identified and analysed thoroughly and have the agreed upon proactive actions been taken. The decision criteria could perhaps be derived from the descriptions of the risk management contents associated with each stage of the drug development process. In addition to the consideration of risk management being an integral part of project management and stage-gate processes, an important part of successful risk management is a proper and effective division of responsibilities. Especially in a multi-layered organisational structure, such as in the pharmaceutical industry, the responsibilities for managing risks and handling certain risk types must be defined clearly and communicated to the project team and even the entire organisation. These definitions should be aligned with other responsibilities. It is, however, extremely important to make sure that communication is enabled between and within these organisational layers. 7.2. Contributions, Conclusions and Managerial Implications
This study contributes to the present theoretical risk management knowledge by adding one more field of application to the empirical base of the discipline. It provides a starting point for additional studies on risk management and highlights the need for further studies in the risk management field of research. What comes to the knowledge
Hanna-Leena Saari
111
of project and risk management practices in the pharmaceutical industry, this study provides input by suggesting a new approach for risk management. As stated in the study, risk management in the pharmaceutical industry has concentrated much on business and portfolio risk management. Thus specific project risk management is suggested to be an additional strong application area to both risk and project management in the pharmaceutical industry. Besides the traditional mechanistic pointof-view, risk management is also considered as a soft discipline focusing much on organisational issues, communication and learning. This study also contributes to the practical management of drug development projects by suggesting a practice-oriented framework for how risks should be managed in the projects. However, this study did not conduct a market test for the framework. This study should be viewed as a starting point for practical application of risk management by providing an initial suggestion that must be adapted and refined before and during implementation in organisations. As a conclusion, it must be first stated that risk management in drug development projects is somewhat different than in other industries because of the length, complexity, size and high risk level of the projects and low maturity of project management. Risk management is particularly important for small pharmaceutical companies while they cannot develop many drugs simultaneously. Big conglomerates also need to improve their performance in introducing new drugs and making more effective use of their resources. To account for the special characteristics of drug development, risk management should be team-based, and much focus should be placed on communication and knowledge management. Because of the size and complexity of the project, all risks cannot be identified and assessed only by individuals. The amount of small speciality areas represented in the project team magnifies the need for team-based risk management. This raises the need for increased communication, as does also the multi-level nature of the project organisation. Last, the importance of knowledge management is emphasised by the length of the project and the huge cost of failure. Knowledge must therefore be transferred actively between ongoing projects as well as between subsequent projects. There is no room for unnecessary failures in the industry at present. The techniques used in risk management of drug development projects should be qualitative in nature. As project management and risk management maturity increases, it should be considered whether quantitative tools would be more effective. Care should be taken at least in the beginning to make sure that all phases of the risk management process are taken. Risk management in drug development projects should start with an initial risk analysis already before project planning is started, because project planning is already a resource-intensive and long-lasting activity. Ideally, risk management is not
Hanna-Leena Saari
112
another distinct process but rather an add-on to the project management and stage-gate processes of drug development. The proposed risk management framework may be too heavy to be used continuously in everyday project work. Therefore, each organisation must refine it to serve their own situation and needs. The proposed method was designed for an industry in which the general maturity level of project management is rather low. Thus, pharmaceutical companies with more mature management practices should consider whether to implement the suggested framework in its entirety or to select more sophisticated and detailed tools. The last conclusion deals with the risk management literature and imposes a recommendation for further research. During the study it became evident that quite many of the practices introduced in the literature are too complex and laborious to be implemented in practice. For example, the methods suggested in the proposal studied in this study represent the qualitative end of the tools outlined in the literature and still it was perceived as too complex to be implemented in the case company. There is also an interesting recommendation in the literature concerning big projects. Usually, the most sophisticated and detailed methods are recommended for big and complex projects. These methods are bound to require more time and resources than the simpler qualitative methods. At the same time big and complex projects have quite a number of risks and the amount is most probably bigger than in smaller projects that use qualitative tools. The amount of risks thus multiplies the amount of time and resources needed to complete the risk assessment and most probably ends up in unbearable quantities. The research in risk management should therefore take a more realistic view to the applicability of the frameworks and, in addition to the ideal models, start constructing models that actually could be used in everyday work. This issue will be elaborated more in section 7.4. This study has several implications for managers of pharmaceutical companies can be derived from the study. First, there is a challenge for the entire industry to promote and implement systematic risk management in drug development projects. Project management should be allowed to develop and gain a recognised status. However, to ensure the effectiveness of risk management, other working methods need to be developed, too. Attention should be paid to team composition so that project teams would be effective and their performance would be maximised. This might require the project manager to have authority over who is assigned to the team. Enough resources should be guaranteed for the project teams to manage risks. The risk management practices have to be adapted to the companys needs and resource availability. The knowledge management practices of the company need to be developed, too, to ensure a flow of risk knowledge between projects. Thus, communication and openness must be fostered throughout the company. In addition, effective interproject learning is an essential component for maximising the benefits of risk management. All the
Hanna-Leena Saari
113
development efforts described above need visible top management commitment and support to succeed thus suggesting top management to be the main change agent. 7.3. Reliability and Validity of the Research and Generalisability of the Results
As the focus of the study was to provide a practical method for risk management, an empirical case study was selected as research approach. A two-staged approach was taken for the interviews to enable a more extensive view to the case companys projects. As only one core therapy area was examined first it allowed a decent coverage of the most relevant line organisations. Then, the interview of project managers and program leaders was used for getting an overall picture for the generalisability of the process to the other core therapy areas of the case company. The aim of selecting the interviewees with the means of purposive sampling was to get all relevant line organisations involved in the research. The sufficiency of the material, on the other hand, was addressed by the two-staged research process. The workshop held after the first-stage interviews was used to validate the results of the interviews. The second-stage interviews served a purpose of validating the first interviews, while no significant changes had to be made to the process. All second stage interviewees agreed on the suitability of the process thus further validating the results of the first-stage interviews. A consensus was reached within the second workshop about which tools to select. This supports the assumption that these selections would be suitable for the case company. The literature used in the study consisted mainly of peer-reviewed articles and books. However, some information was gained from less reliable sources, such as the Internet. Thus, care had to be taken to apply this information in this study, even though the main aim of this kind of information was to present alternative and even contradictory views to other literature referenced or highlight the most recent understanding of issues. There was only one person studying the subject, i.e. also interviewing and analysing the results. Thus, the interviewer may have unintentionally affected the interviewees or analysed the results to lead to the desired conclusions. This pitfall was, however, realised and thus it was consciously attempted to be avoided throughout the study. Additionally, some validity and reliability may have been lost due to the organisational changes that the case company has had to deal with during the last year. For example, roles and responsibilities were somewhat unclear leading, among others, to the low response rate of some questions. In addition, top management was not interviewed because of the turmoil in the case company during the study. For example, the composition of the portfolio management board was not known and the reporting routes of projects were not defined when the information was needed. Thus, the suggestions for which issues to elevate to the management were merely second-hand opinions. It is also difficult to confirm the results of the study with previous knowledge, because only a few studies were found discussing the subject matter in this specific application area. Last, the
Hanna-Leena Saari
114
construct developed in the study needs market testing which remained at a rather superficial level in this study. As the practical applicability of the risk management framework was assessed in a small pharmaceutical company with three core therapy areas, the transferability of the results to bigger companies and other therapy areas must be considered, because some adjustments may be needed. In a bigger organisation, for example, more formal communication may be required and there may be ready-made templates to which risk information must be adjusted. Some special software tools may be needed to manage the risk management data of the projects while there most probably will be more projects ongoing. Each company must take into account their needs and maturity levels. For example, for a company that has implemented advanced project management practices the suggested framework may not be effective. In addition, if risk information is used in portfolio-level decision making to, for example, compare projects, the qualitative methods proposed will not be sufficient. As far as the transferability between therapeutic areas is concerned, at least in the case company it proved to be very straightforward thus suggesting the suitability of the framework to other areas, too. However, the selection of the tools and methods of the framework to be implemented in the case company was done on the basis of the organisations own needs and experiences. Each organisation must therefore carefully assess their own situation before selecting the risk management methods used. Additionally, the selections of the case company were not tested in practice suggesting the use of even more caution when adapting the model to ones own needs. Finally, the framework may be applicable in other industries sharing the same characteristics of projects and project management as the pharmaceutical industry. This was not validated and therefore at least careful consideration should be given to the assumptions behind the framework and their suitability to the industry or company in question. 7.4. Recommendations for Further Research
The most obvious recommendation for further research is to implement the suggested risk management framework and test its effectiveness in a real-life situation. This would then provide the market test still needed for the construct. At first, it may be enough to implement the framework in a few projects at different life-cycle stages and only follow them through some decision-points, as drug development projects are extremely long. However, experiences from long-term use should be gathered later, too. With regard to the pharmaceutical industry, it should be studied whether the success probabilities of projects could be defined more accurately with the help of risk assessments. At some level, these two aspects deal with the same issues, but the relation may not be too straightforward. If it were possible to derive success probabilities out of risk assessments, it might improve the position of risk management and the effectiveness of pharmaceutical companies.
Hanna-Leena Saari
115
Additionally, the general risk management theory needs to be studied further. First, the studies of how risks are managed in practice in companies reveal that most often the tools used are very qualitative and often only a part of the risk management process phases are implemented. This questions the practical applicability and effectiveness of the methods suggested in literature. Most of the presented risk management methods have been implemented in some organisations, but usually there is no information of the long-term use of the model and thus its perceived effectiveness is not reported. Even though the model would have been thought to be advantageous in the first implementation, it still does not prove its applicability in the long term. Second, risk management literature presents a vast variety of processes, tools and techniques, with only little indication to their practical application. When thinking from the perspective of a project manager wanting to manage risks in his or her project, the project manager is faced with a vast number of models, but no help is provided for choosing the best and most effective methods regarding the project and its environment. Thus, research should be directed in addition to finding new risk management processes and methods to how and where the existing ones should be used to give optimal results. This might increase the application of risk management if the project practitioners could more easily decide which approaches to use given the project, its environment and the amount of resources available. A third research topic is induced by the resource constraints of companies. Risk management, as well as any other work method, cannot require excessive amounts of resources. It would be interesting to find out what is the minimum amount of activities to be conducted from the risk management processes and tools provided in the literature so that the time spent in risk management would still be effective. The idea behind this is that at some point, if not enough is done, the time would have been spent more effectively for project work or other project management tasks than risk management. This kind of considerations could prove to be effective for those companies who strive for cost reductions, minimise their human resources and have no time or resources to implement a complicated approach. The adoption of a too minimal framework or the abandoning of the entire concept would then be avoided and more companies could be able to implement effective risk management practices. The need is increased by the fact that today there are so many new management fads that it would be impossible to implement them all. Some of these are, however, interconnected so that if one is adopted, another is already needed, e.g. risk management and knowledge management, or portfolio management and project management. Realistically, it cannot be expected that any organisation could implement these all in such a complex form as presented in the literature. Fourth, risk management in big projects is usually recommended to be performed in a very sophisticated and detailed way, as already stated. However, as big and complex projects have a lot of risks to be identified and analysed, the resource load may well be
Hanna-Leena Saari
116
unbearable consisting of the training of project team members and the actual risk assessment and response planning and their updating. The question to be studied would then be, is this really worth it, i.e. are projects completed more effectively and does the company see enough results to compensate for the resource usage. This is an important issue to be considered even though the measurement of the benefits of risk management or the comparison of two approaches for their benefits is difficult. As a conclusion from these suggestions for further research, more realism is needed in the literature and research of risk management. At present, too many studies recommend new risk management approaches with no short or long-term consideration of their applicability in practice, while the optimal application areas of the approaches are left unaddressed.
Hanna-Leena Saari
117
REFERENCES Agnew, B. 2000. When Pharma Merges, R&D Is the Dowry. Science, 17 March. pp. 1952-1953. Angell, M. 2000. The Pharmaceutical Industry To Whom Is It Accountable? The New England Journal of Medicine, Vol. 342, No. 25. pp. 1902-1904. Arlington, S. 2000. Pharma 2005: An Industrial Revolution in R&D. Pharmaceutical Executive, January. pp. 74-84. Artto, K.A. 2001. Management of Project-Oriented Organization Conceptual Analysis in Project Portfolio Management: Strategic Management through Projects. Editors Artto, K.A., Martinsuo, M. and Aalto, T., Helsinki, Project Management Association Finland. pp. 5-22. Artto, K.A. 1997. Focusing on risk response development and risk measures to be taken - can risk estimating even be skipped in an RM application? in Managing Risks in Projects edited by Khknen, K and Artto, K.A. London, E&FN Spon. pp. 353-361. Artto, K.A. and Hawk, D.L. 1999. Industry models of risk management and their future. Proceedings of the 30th annual project management institute 1999 seminars & symposium Philadelphia, Pennsylvania, USA. 8 p. Artto, K.A., Khknen, K. and Koskinen, K. (Editors). 1999. Managing Business by Projects. Project Management Association Finland and NORDNET. 1298 p. Artto, K.A., Khknen, K. and Pitknen, P.J. (Editors) 2000. Unknown Soldier Revisited: A Story of Risk Management. Helsinki, Project Management Association Finland. 114 p. Artto, K.A., Martinsuo, M. and Aalto, T. 2001. Project Portfolio Management: Strategic Management through Projects. Helsinki, Project Management Association Finland. 176 p. Baccarini, D. And Archer, R. 2001. The Risk Ranking of Projects: A Methodology.International Journal of Project Management, Vol. 19, No. 3. pp. 139-145. Blau, G., Mehta, B., Bose, S., Pekny, J., Sinclair, G, Kuenker, K. And Bunch, P.R. 2000. Risk Management in the Development of New Products in Highly Regulated Industries. Computers and Chemical Engineering, Vol. 24, No. 2-7. pp. 659-664. Brown, A.L. and Eisenhardt, K.M. 1995. Product Development: Past Research, Present Findings, and Future Directions. Academy of Management Review, Vol. 20, No. 2. pp. 343-378. Buchan, D.H. 1994. Risk Analysis Some Practical Suggestions. Cost Engineering, Vol. 36, No. 1. pp. 29-34.
Hanna-Leena Saari
118
Chapman, R.J. 2001. The Controlling Influences on Effective Risk Identification and Assessement for Construction Design Management. International Journal of Project Management. Vol. 19, No. 3. pp. 147-160. Chapman, R.J. 1998. The Effectiveness of Working Group Risk Identification and Assessment Techniques. International Journal of Project Management, Vol. 16, No. 6. pp. 333-343. Chapman, C. and Ward, S. 2002. Managing Project Risk and Uncertainty: A Constructively Simple Approach to Decision Making. Chichester, John Wiley & Sons, Ltd. 498 p. Chapman, C. and Ward, S. 1997. Project risk management: Processes, Technoques and Insights. Chichester, John Wiley & Sons, Ltd. 322 p. Chapman, C. and Ward, S. 1996. Why You Need Risk Management? Project Management, Vol. 2, No. 2. pp. 12-14. Cooke-Davies, T.J. and Arzymanow, A. 2003. The Maturity of Project Management in Different Industries: An Investigation into Variations between Project Management Models. International Journal of Project Management, Vol. 21, No. 6. pp. 471-478. Craig, A-M and Malek, M. 1995. Market Structure and Conduct in the Pharmaceutical Industry. Pharmacology and Therapeutics, Vol. 66, No. 2. pp. 301-337. del Cao, A. and de la Cruz, M.P. 1998. On the Management of Risks in Construction Projects: Small and Medium Sized Projects with Low and Medium Levels and Zero Situations. Project Management, Vol. 4, No. 1. pp. 54-61. Elkington, P. and Smallman, C. 2002. Managing Project Risks: A Case Study from the Utilities Sector. International Journal of Project Management, Vol. 20, No. 2. pp. 49-57. Elkjaer, M. and Felding, F. 1999. Applied Project Risk Management Introducing the Project Risk Management Loop of Control. Project Management, Vol. 5, No. 1. pp. 16-25. Elliott, M. 2002. Scheduling a cure. IIE Solutions, June. pp. 42-45. Fagan, P.L. and Hayes, R.H. 1998. The Pharma Giants: Ready for the 21st Century? Harvard Business School Bublishing, Boston, 6 May. pp. 1-34. Frame, J.D. 1997. Establishing Project Risk Assessment Teams in Managing Risks in Projects edited by Khknen, K and Artto, K.A. London, E&FN Spon. pp. 22-27. Frame, J.D. 1994. The New Project Management: Tools for an Age of Rapid Change, Corporate Reengineering, and Other Business Realities. San Francisco, Jossay-Bass, Inc., Publishers. 328 p.
Hanna-Leena Saari
119
Githens, G.D. and Peterson, R.J. 2001. Using Risk Management in the Front End of Projects. Proceedings of the Project Management Institute 32nd annual seminars & symposium, Nashville, TN. 4 p. Goldratt, E.M. and Cox, J. 1992. The Goal: A Process of Ongoing Improvement. 2nd edition. Great Barrington, MA, The North River Press. 351 p. Green, S.D. 2001. Towards An Integrated Script for Risk and Value Management. Project Management, Vol. 7, No. 1. pp. 52-58. Grey, S. 1995. Practical Risk Assessment for Project Management. Chichester, John Wiley & Sons, Ltd. 140 p. Halman, J.I.M. and Keizer, J.A. 1997. The Risk Diagnosing Methodology RDM in Managing Risks in Projects. Editors Khknen, K. and Artto, K.A., London, E & FN Spon. pp. 204-213. Halman, J.I.M. and van der Weijden, P.M. 1997. In Search of Best Practices in Risk Management in Managing Risks in Projects. Editors Khknen, K. and Artto, K.A., London, E & FN Spon. pp. 31-40. Halliday, R.G., Drasdo, A.L., Lumley, C.E. and Walker, S.R. 1997. The allocation of resources for R&D in the worlds leading pharmaceutical companies. R&D Management, Vol. 27, No. 1. pp. 63-77. Hauge, L.H. 1996. Risk Management in Multilevel Organisations. IPMA World Congress on Project Management, June 1996, Paris, France. pp. 513-523. Hillson, D. 2002a. Extending the Risk Process to Manage Opportunities. International Journal of Project Management, Vol. 20, No. 3. pp. 235-240. Jacob, W.F. and Kwak, Y.H. 2003. In search of innovative techniques to evaluate pharmaceutical R&D projects. Technovation, Vol. 23, No. 4. pp. 291-296. Jordanger I. 2000. Uncertainty Management in Statoils Development Projects in Unknown Soldier Revisited: A Story of Risk Management. Helsinki, Project Management Association Finland. pp. 87106. Jrvenp, E. And Kosonen, K. 1999. Johdatus tutkimusmenetelmiin ja tutkimuksen tekemiseen. HUT Industrial Management and Work and Organizational Psychology. Teaching material No 1. 104 p. Katajamki, M. 2003. Pfizer ohitti Microsoftin yritysten suuruuslistalla. Kauppalehti, 19 June. pp.12. Keizer, J.A., Halman, J.I. and Song, M. 2002. From Experience: Applying the Risk Diagnosing Methodology. The Journal of Product Innovation Management, Vol. 19, No. 3. pp. 213-232.
Hanna-Leena Saari
120
Kennedy, T. 1998a. Preface in Pharmaceutical Project Management. Editor Kennedy, T., New York, Marcel Dekker Inc. pp. iii-iv. Kennedy, T. 1998b. Strategic Project Management at the Project Level in Pharmaceutical Project Management. Editor Kennedy, T., New York, Marcel Dekker Inc. pp. 1-24. Kennedy, T. (Editor) 1998. Pharmaceutical Project Management. New York, Marcel Dekker Inc. 290 p. Klakegg, O.J., Marianeschi, M.M. and Risan, . 1999. Building Trust the Power of Analysing Risk Using Resource Groups in Managing Business by Projects. Editors Artto, K.A., Khknen, K. and Koskinen, K., Project Management Association Finland and NORDNET. pp. 909-920. Krogstie, J., Hauge, T., Haugland, C., Sandvold, ., Stenslie, R. and Stette, F. 1999. Practical Experiences with a Framework for Proactive Risk Management in Large-Scale IS Projects in Managing Business by Projects. Editors Artto, K.A., Khknen, K. and Koskinen, K., Project Management Association Finland and NORDNET. pp. 883-897. Kutzbach, C.A. 1998. Project Planning: From Basic Concepts to Systems Application in Pharmaceutical Project Management. Editor Kennedy, T., New York, Marcel Dekker Inc. pp. 51-80. Khknen, K. 2001. Integration of Risk and Opportunity Thinking in Projects. PMI Europe 2001, 4th European Project Management Conference 6-7 June 2001, London. 7 p. Khknen, K. 1999. Integration of Qualitative and Quantitative Risk Analysis. 15th Triennal Conference of the International Federation of Operational Research Societies - IFORS, The Operations Research Society of China, China, Peking, 16-20 August, 1999. 8 . Khknen, K. 1998. Holistic Principle for Applying Project Risk Management Methods and Tools. Transactions of 15th International Cost Engineering Congress, Amsterdam, 20-22 April 1998. pp. 189-197. Khknen, K. 1997. Implementation of Systematic Project Risk Management in Companies From Immediate Needs to the Prospects of the Future in Risk Management in Managing Risks in Projects. Editors Khknen, K. and Artto, K.A., London, E & FN Spon. pp. 75-83. Khknen, K. and Artto, K.A. (Editors) 1997. Managing Risks in Projects. London, E & FN Spon. 375 p. Lead, B.A. 2000. Programme Management in Pharmaceutical Research and Development. Denver, Interpharm Press. 214 p. Maloff, B.L., Valentino, K.L., Nelson, R.J. and Broxup, B.R. 1997. Maximizing Return on Investment and Minimizing Risk in Partnering with Preclinical CROs. Drug Information Journal, Vol. 31, No. 3. pp. 857-863.
Hanna-Leena Saari
121
Martinsuo, M., Aalto, T. and Artto, K. 2003. Projektisalkun johtaminen: Tuotekehitysprojektien valinta ja strateginen ohjaus. Helsinki, Metalliteollisuuden kustannus Oy. 177 p. Murphy, P.L.1989. Pharmaceutical Project Management Is It Different? Project Management Journal, Vol. 3, September. pp. 35-38. Noferi, J.F. and Worden, D.E. 1999. Regulatory Risk Management The Evolving Paradigm. Pharmaceutical Executive, September. pp. 148-158. Nonaka, I. 1994. A Dynamic Theory of Organizational Knowledge Creation. Organization Science, Vol. 5, No. 1. pp. 14-36. Noor, I, Joyner, T. and Mrtin Jr., R.J. 2002. Challenges of Implementing Risk Management Processes. 2002 AACE International Transactions. pp. R04.1-R04.6. Patterson, F.D. and Neailey, K. 2002. A Risk Register Database System to Aid the Management of Project Risk. International Journal of Project Management, Vol. 20, No. 5. pp. 365-374. Pass, D. and Postle, M. 2002. Unlocking the Value of R&D: Managing the Risks. BioPharm, June. pp. 67-71. Peltonen, M., Pursio, S. and Vlisalo, T. 2001a. Riskianalyysimenetelmt ja niiden arviointi: Menetelmien edut ja rajoitukset projektiriskien arvioinnissa. Tampere, Tekes and VTT Automaatio. 26 p. Peltonen, M., Pursio, S. and Vlisalo, T. 2001b. Yritysten projektiriskien ja projektien kokemustiedon hallinnan kytnnt ja menettelytavat: Haastattelututkimuksen tulokset. Tampere, Tekes and VTT Automaatio. 21 p. Pender, S. 2001. Managing Incomplete Knowledge: Why Risk Management Is not Sufficient. International Journal of Project Management, Vol. 19, No. 2. pp. 79-87. Pinto, J.K. 2002. Project Management 2002. Research Technology Management, Vol. 41, No. 2. pp. 22-38. Pharmaceutical Research and Manufacturers of America PhRMA. 2003. Pharmaceutical Industry Profile 2003. Pharmaceutical Research and Manufacturers of America, Washington. 85 p. Pharmaceutical Research and Manufacturers of America PhRMA. 2002. Pharmaceutical Industry Profile 2002. Pharmaceutical Research and Manufacturers of America, Washington. 102 p. Pitknen, P. 1999. Project Risk Management Applications in Industry. Helsinki, Project Management Association Finland. 89 p. Project Management Institute. 2000. A guide to a project management body of knowledge Upper Darby, PA, Project Management Institute. 216 p.
Hanna-Leena Saari
122
Project Management Institutes Pharmaceutical Special Interest Group, PMI Pharma SIG. 2002. Benchmarking Project Management in the Pharmaceutical/Biotechnology Industry. Pharmaceutical SIG Newsletter, June. p. 6. Project Management Institutes Risk Special Interest Group, PMI Risk SIG. 2002a. Universal Risk Project Final Report. February 2002. 46 p. Project Management Institutes Risk Special Interest Group, PMI Risk SIG. 2002b. Risk Management Maturity Level development. April 2002. 22 p. Pyra, J. and Trask, J. 2002. Risk Management Post Analysis: Gauging the Success of a Simple Strategy in a Complex Project. Project Management Journal, Vol. 33, No. 2. pp. 41-48. Raz, T. and Michael, E. 2001. Use and Benefits of Tools for Project Risk Management. International Journal of Project Management, Vol. 19, No. 1. pp. 9-17. Raz, T., Shenhar, A.J. and Dvir, D. 2002. Risk Management, Project Success, and Technological Uncertainty. R&D Management, Vol. 21, No. 2. pp. 101-109. Reynolds, I. 1998. Perspectives from Other Industries: Best Practices and Evolving Trends in Pharmaceutical Project Management. Editor Kennedy, T., New York, Marcel Dekker Inc. pp. 81100. Rimpilinen, A. and Peltonen, M. 2000. Riskien ja kokemustiedon hallinta projekteissa: Menetelmt, standardit, ohjelmistot. Tampere, Tekes and VTT Automaatio. 47 p. Rose, L.B. 1998. Clinical Trials Quantum Leap or Last Gasp? in Pharmaceutical Project Management. Editor Kennedy, T., New York, Marcel Dekker Inc. pp. 203-232. Royer, P.S. 2000. Risk Management: The Undiscovered Dimension of Project Management. Project Management Journal, Vol. 31, No. 1. pp. 6-13. Sahiluoma, V. 2003. Pfizer nousee ykkseksi maailmalla ja Suomessa. Kauppalehti, 17 April. pp. 9. Senn, S. 1998. Further Statistical Issues in Project Prioritization in the Pharmaceutical Industry. Drug Information Journal, Vol. 32, No. 1. pp. 253-259. Simister, S.J. 1994. Usage and Benefits of Project Risk Analysis and Management. International Journal of Project Management, Vol. 12, No. 1. pp. 5-8. Smith, P.G. 2003. A Portrait of Risk. PM Network, April. pp. 44-48. Steyn, H. 2002. Project Management Applications of the Theory of Constraints beyond Critical Chain Scheduling. International Journal of Project Management, Vol. 20, No. 1. pp. 75-80.
Hanna-Leena Saari
123
Tidd, J., Bessant, J. And Pavitt, K. 2001. Managing Innovation: Integrating Technological, Market and Organizational Change. 2nd edition. New York, NY, John Wiley & Sons, Inc. 388 p. Tritle, G.L., Scriven, E.F.V. and Fusfeld, A.R. 2000. Resolving Uncertainty in R&D Portfolios. Research Technology Management, Vol. 43, No. 6. pp. 47-55. Trott, P. 2002. Innovation Management and New Product Development. 2nd edition. Essex, Pearson Education Limited. 426 p. Turner, J.R. 1999. The Handbook of Project-Based Management: Improving the processes for achieving strategic objectives. 2nd edition. London, McGraw-Hill. 529 p. Uusitalo, H. 1991. Tiede, tutkimus ja tutkielma: Johdatus tutkielman maailmaan. Juva, WSOY. 121 p. Ward, S.C. 1999a. Assessing and Managing Important Risks. International Journal of Project Management, Vol. 17, No. 6. pp. 331-336. Ward, S. 1999b. Requirements for an Effective Project Risk Management Process. Project Management Journal, Vol. 30. No. 3. pp. 37-43. Ward, S. and Chapman, C. 2003. Transforming Project Risk Management into Project Uncertainty Management. International Journal of Project Management, Vol. 21, No. 2. pp. 97-105. Wideman, R.M. (Editor) 1992. Project and Program Risk Management: A Guide to Managing Project Risks and Opportunities. Upper Darby, Project Management Institute. Williams, R.C, Dorofee, A. J. and Walker, J. A. 1997. Risk Management in Practice: Lessons Learned. Software Engineering Process Group 1997. pp. 71-78. Wright, J.F. 1997. Project risk management and organisational learning in Managing Risks in Projects. Editors Khknen, K. and Artto, K.A., London, E & FN Spon. pp. 129-137. Internet Resources Conrow, E.H. 1997.Some Limitations of Quantitative Risk Analysis Approaches Used in Project Management. Retrieved on June 18, 2003 from http://www.acq.osd.mil/io/se/risk_management/papers_speeches_briefs/lqra.pdf DeBakker, K., Stewart, W.M. and Sheremeta, P.W. 2002. Risk Management Planning How Much is Good Enough? 5th European Project Management Conference, PMI Europe 2002, Cannes France, 19-20 June 2002. 5 p. Retrieved on June 11, 2003 from http://www.risksig.com/articles/euro2002/1289.pdf
Hanna-Leena Saari
124
FMECA 1999. FMEA Methodology. Retrieved on July 29, 2003 from http://www.fmeca.com/ffmethod/methodol.htm Hillson, D. 2002b. The Risk Breakdown Structure (RBS) as an Aid to Effective Risk Management. 5th European Project Management Conference, PMI Europe 2002, Cannes France, 19-20 June 2002. 11 p. Retrieved on June 11, 2003 from http://www.risksig.com/articles/euro2002/1060.pdf Kontio, J. 1997. The Riskit Method for Software Risk Management, version 1.00 CS-TR-3782 / UMIACS-TR-97-38, 1997. Computer Science Technical Reports. University of Maryland. College Park, MD. Retreived on July 29, 2003 from http://www.soberit.hut.fi/~jkontio/riskittr.pdf Sosiaali- ja terveysministeri. 2002. Geneerinen substituutio: Hyv lke halvemmalla. Sosiaali- ja terveysministerin esitteit 2002: 9. 12 p. Retrieved on July 7, 2003 from http://www.stm.fi/suomi/eho/julkaisut/02_9esite/esi02_9.pdf
Hanna-Leena Saari
Concept
Feasibility & Definition Planning Development Goal of RM? Goal of RM? Goal of RM? Issues discussed? Whose responsibility? Participants? Team/individual effort? Time horizon being analysed? Level of detail of the analysis When new risk analysis should be conducted? How do we get this to be a continuous process? Time horizon being analysed? Level of detail of the analysis When new risk analysis should be conducted? Participants? Team/individual effort? Whose responsibility? Issues discussed? Goal of RM? Issues discussed? Whose responsibility? Participants? Team/individual effort? Time horizon being analysed? Level of detail of the analysis Issues discussed? Whose responsibility? Participants? Team/individual effort? Time horizon being analysed? Level of detail of the analysis
Launch in key markets
Project completion Whose responsibility? Participants? Team/individual effort? Where should the documents be stored? How do we ensure that this data is utilised later?
Hanna-Leena Saari
Assessment: common comparable measure? Where does the input come from? Issues discussed: all project-related risks/some part of risks What is the desired degree of anticipation? How participants should be motivated? How new risks/changes are brought into PMs and project teams attention? When should issues be discussed above the project team? Who should/could use risk information generated? Who is responsible for the entire RM process? Implementation, development etc. How public the risk documentation of a project should be? Rate of change in projects and its environment in general?
APPENDICES
Questions
Appendix 1. Structure of the interviews
General questions
125
Helsinki University of Technology Risk Management in Drug Development Projects Appendix 2. Occupational titles and departmental profiles of the interviewees First-stage interviews (WS means that the person participated also in the workshop) Occupational Title Vice President Project Manager Project Manager Project Leader Clinical Program Leader Clinical Program Leader Assistant Vice President Assistant Vice President Special researcher Industrialisation Manager Team Leader Global Brand Manager Regulatory Affairs Manager Vice President Development Engineer Second-stage interviews Project Manager Project Manager Project Manager Vice President Project Manager Project Leader Project Leader Tool Development (workshop) Project Manager Project Manager Project Manager Project Manager Program Leader Project Management Project Management Project Management Project Management Core Therapy Areas Project Management Project Management Project Management Specialty Products Specialty Products Core Therapy Areas Core Therapy Areas Departmental Profile Project Management Project Management (WS) Project Management (WS) Core Therapy Areas Research and Development (Clinical Development) (WS) Research and Development (Clinical Development) Research and Development (Clinical Development) (WS) Drug Discovery and Pharmacology Research and Development (Toxicology) (WS) Industrialisation (WS) Research and Development (Pharmaceutical Product Development) (WS) Core Therapy Areas Global Regulatory Affairs Core Therapy Areas Portfolio Management (WS)
126
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Appendix 3. Different risk identification methods and their advantages and disadvantages
127
In the next table risk identification techniques are outlined with their advantages and disadvantages. The source literature is also presented.
Table 21. Advantages and disadvantages identification techniques Technique Checklists and prompt lists Advantages Effective in focusing attention on managing project risks provided they are supported by appropriate administrative procedures. Convenient. Simple. Useful memory joggers. A guide to existing risk & opportunity knowledge. Easy to use. Disadvantages Takes a very simple view of project uncertainty. Risk drivers are assumed to be independent. Can become intimidating. Length may discourage more selective analysis of a subset of risk drivers. Risk drivers not on the list are likely to be ignored. List may be more appropriate for some projects than for others. Individual risk drivers may be described in insufficient detail to avoid ambiguity and varying interpretations. Does not encourage the development of a more sophisticated attitude to assessing and quantifying risk. Can be limiting. Tend to be seen as exhaustive leading to a false sense of security. Little help in assessing the overall level of risk represented by a project or in determining realistic target budgets and timescales. References Chapman and Ward 1997, Project Management Institute 2000, Grey 1995, Artto et al. 2000, Pitknen 1999
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Brainstorming Improve problem analysis by providing more possible solutions and unusual approaches to a problem. Increases the chances of obtaining an excellent idea. Involvement of individuals with a variety of backgrounds. Withholding judgement. Utilising thoughts of others. Attempting to view situations from an unfamiliar perspective. Involvement of individuals with a variety of backgrounds. Withholding judgement. Utilising thoughts of others. Attempting to view situations from an unfamiliar perspective. Helps to reduce bias. Keeps any person from having undue influence on the outcome. Elimination of direct social contract. Provision of feedback. Opportunity to revise opinion. Increases the level of individual participation. Better than brainstorming. Problems depersonalised. Works in complex and simple projects. Simple process. Time consuming and expensive. Lack of opportunity for socioemotional rewards. Feeling of detachment. No opportunity for verbal clarification or comment. Conflicts not resolved. May be too creative. May be too creative. Prone to negative effects of personality excesses. Difficult to create a criticism-free atmosphere. Doesn't structure much. The smaller problems that can have severe consequences for project success are not identified.
128 Chapman and Ward 1997, Project Management Institute 2000, Pitknen 1999, Chapman 1998, Halman and Keizer 1997
Synectics
Chapman and Ward 1997
Delphi technique
Project Management Institute 2000, Chapman 1998
Nominal Group Technique
Chapman 1998, Githens and Peterson 2001
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Generates risks quickly. Focuses on problems not people. Encourages open communication and active participation. Tolerates periods of conflict and wild creativity. Facilitates regular review of project risks. Mandatory use enables rapid implementation of a risk management process. Simple and convenient. Risk drivers may not be described in sufficient detail. Inter-dependencies not highlighted. Limited guidance on the relative importance of risk drivers.
129
Summary risk register
Ward 1997 and 1999
In the following, some other possible tools for risk identification are presented.
Table 22. Additional identification tools Technique Pondering Interviews of experienced people Taxonomy-based questionnaire survey Risk breakdown structure Decision-conferencing techniques Risk identification workshop Documentation reviews SWOT analysis Influence diagrams Flowcharts Assumptions analysis Cause-effect-diagramming References Chapman and Ward 1997 Pitknen 1999 Noor 2002 Hillson 2002b Chapman and Ward 1997 Pitknen 1999 Project Management Institute 2000 Project Management Institute 2000 Project Management Institute 2000 Pitknen 1999 Project Management Institute 2000 Project Management Institute 2000
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Appendix 4. Examples of qualitative probability and impact scales
130
Table 23 presents a five-step scale for risk impact assessment in terms of cost, schedule, scope and quality objectives.
Table 23, Evaluating risk impact (Project Management Institute 2000: 136) Evaluating Impact of a Risk on Major Project Objectives (ordinal scale or cardinal, non-linear scale) Project Objective Cost Schedule Very Low 0.05 Insignificant Cost Increase Insignificant Schedule Slippage Scope Decrease Barely Noticeable Quality Degradation Barely Noticeable Low 0.1 <5% Cost Increase Schedule Slippage <5% Minor Areas of Scope Are Affected Only Very Demanding Applications Are Affected Moderate 0.2 5-10% Cost Increase Overall Schedule Slippage 5-10% Major Areas of Scope Are Affected High 0.4 10-20% Cost increase Overall Schedule Slippage 10-20 % Scope Reduction Unacceptable to the Client Very High 0.8 >20% Cost increase Overall Project Schedule Slips >20% Project End Item is Effectively Useless Project End Item is Effectively Unusable
Scope
Quality
Quality Reduction Quality Reduction Requires Client Unacceptable to Approval the Client
Khknen (1999) provides a simple five-step example of classification for risk scoring: Probability: 1) Highly unlikely 2) Unlikely 3) As likely as not 4) Probable 5) Highly probable Impact: 1) Insignificant 2) Marginal 3) Serious 4) Critical
Hanna-Leena Saari
131
5) Catastrophic Royer (2000: 9) defined a three-step scale as following: Risk severity: High (without mitigation, project objectives, i.e. scope, cost, time, are in jeopardy) Medium (without mitigation and monitoring, project deliverable/milestone is at risk) Low (No deliverable/milestone is currently at risk, but an issue bears watching, and is a candidate for active mitigation) High (without mitigation and monitoring, the project deliverable/milestone completion will interrupt the projects critical path) Medium (Without mitigation and monitoring, project deliverable/milestone completion will enter the project critical path) Low (No project deliverable/milestone is at risk unless delays become excessive; therefore, it should be documented and monitored)
Risk probability:
Krogstie et al. (1999: 888-889) presents a six-step scale for impact, probability and manageability: Impact: 1) Marginal impact; exposure slight 2) Moderate impact; progress disrupted with manageable extensions to short-term schedule and cost 3) Medium impact; progress disrupted with large extensions to schedule and cost across short and medium terms 4) High impact; significant disruption to schedule, cost and products over the medium and long terms 5) Extreme impact; significant disruption to successful delivery of project objectives, products and benefits 6) Critical influence; threatens success of the project Probability: 1) Highly improbable occurrence 2) Unlikely occurrence 3) Possible occurrence 4) Probable occurrence 5) Very probable occurrence
Hanna-Leena Saari
132
6) Extremely likely occurrence Level of control: 1) No control 2) Minimal realistic control 3) Shared or partnered control 4) Moderate hands-on control 5) Extensive direct control 6) Total direct control Jordanger (2000: 92) outlines scales for manageability of risks: 1) Get more information about the uncertainties. If this is all you can do, the manageability is weak. 2) Influence probability of events and outcomes. If the project significantly can reduce probability of negative events or increase probability of positive events, the manageability is strong. 3) Influence consequences. If the project can significantly reduce consequences of negative events or increase consequences of positive events, the manageability is strong.
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Appendix 5. Probability-impact matrices
133
Probability-impact matrices can be used to easily determine the risk score of a risk on the basis of the probability and impact assessments done earlier. Table 24 presents a table in which the probability and impact have been assessed on a nonlinear five-step scale. The risk score is determined by taking the number in the conjunction of the impact and probability values determined. For example, if a risk has a probability of occurrence of 0.5 and an impact on objectives of 0.20, its risk score is 0.10. Each organisation must decide which is the combination of probability and impact that will be defined to pose a high risk to the project. That is, it has to be defined whether a 0.10 risk is low, medium or high. Table 24 presents one possibility for this definition.
Table 24, Probability-Impact Matrix (Project Management Institute 2000: 137) Risk Score for a Specific Risk Probability 0.9 0.7 0.5 0.3 0.1 0.05 0.04 0.03 0.02 0.01 0.05 0.09 0.07 0.05 0.03 0.01 0.10 Risk Score = P x I 0.18 0.14 0.10 0.06 0.02 0.20 0.36 0.28 0.20 0.12 0.04 0.40 0.72 0.56 0.40 0.24 0.08 0.80
Impact on an Objective (e.g. cost, time, or scope) (Ratio Scale)
Royer (2000: 10) presents a way in which a score can be given to a risk even when probability and impact are analysed only with a scale of Low/Medium/High, see Table 25. After probability and impact are assessed, the severity/probability factor rating, SPR, can be found from the conjunction of these two grades. For example, if a risk has a high probability of occurrence and medium impact on project objectives, its severity/probability factor rating is two.
Table 25, Risk severity to probability factor matrix (Royer 2000: 10) High Medium Low Severity Factor 2 1 1 Medium Probability Factor Severity/Probability Factor Rating (SPR) 3 mitigation strategy and detailed contingency plan 2 mitigation strategy and outlined contingency plan 1 mitigation strategy 0 treat as a project assumption 2 1 0 Low 3 2 2 High
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Appendix 6. Different risk assessment methods and their advantages and disadvantages
134
First, advantages and disadvantages of qualitative techniques are outlined, see Table 26
Table 26. Advantages and disadvantages of qualitative risk assessment methods Technique Probability impact matrix Advantages Allows PT to brainstorm the most likely project risks and apply simple formula to them. Communicative. Aids in creating a shared understanding on the importance of various risks for the project. Simple. A basis for making prioritisation lists. Useful if interpreted realistically. Most valuable for the way they highlight separate issues and give some indication of which are the most important. Disadvantages Shortcomings result from a checklist approach, see checklist. Ratings have no absolute meaning. Danger of prematurely defining high & low risks with no further considerations. Responsibility addressing. References Chapman and Ward 1997, Ward 1999, Pinto 2002, Khknen 1999, Rimpilinen and Peltonen 2000, Project Management Institute 2000
Questionnaires
Arbitrary. Possible for real priorities to be different from those indicated by the scores. Confusion between a risk's likelihood and its impact. Takes no account of your ability to cope with a risk. No consideration on other risks that are not mentioned in the questionnaire.
Grey 1995
Other qualitative risk assessment methods and references to them are outlined in Table 27.
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 27. Other qualitative risk assessment techniques Technique Project assumptions testing Data precision ranking Interviewing Priority ranking of qualitatively assessed risks High/low values, intermediate scenarios Expert judgement References Project Management Institute 2000 Project Management Institute 2000 Project Management Institute 2000 Pyra and Trask 2002 Chapman and Ward 1997 Pitknen 1999
135
In the following, also quantitative techniques together with their advantages and disadvantages are outlined, see Table 28.
Table 28. Advantages and disadvantages of quantitative risk assessment methods Technique 1-point estimates Triangular distribution Advantages Forces to think about possible scenarios. Specified with three values. Computationally efficient. Sufficient in the vast majority of practical situations. No need to estimate probabilities. Provide more precision. Spurious precision. Usually provide less specific estimates. Randomness assumed. Repeatability assumed. Limitations of human comprehension. Flow of knowledge with time not accounted for. Fuzzy parameters, limitations of language. Too easily unlink the analysis from live project environment and plans. No extreme values. Grey 1995 Chapman and Ward 1997, Pender 2001, Khknen 1999 Disadvantages Preparation of probability estimates. May cause significant underestimation of extreme values. Use of an absolute maximum value. References Khknen 1999 Chapman and Ward 1997, Grey 1995, Khknen 1999
Probability distribution function
Beta distributions
Looks natural.
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Monte Carlo Allows you to work in terms of real units. Allows models to be firmly rooted in the plans of a business or project. Makes the relationship between the output of models and real-world decisions relatively straightforward. Enables analysis of options with quantitative and qualitative factors. Not as simple a model as possible. No statistically sound basis to specify distributions. No basis for estimating most likely values. No basis to create custom tailored distributions when real world data is absent. Modelling correlation between risk elements accurately illusive. Incorporates the deficiencies of sensitivity analysis.
136
Grey 1995, Project Management Institute 2000, Conrow 1997
Analytic hierarchy process (AHP)
Tritle et al. 2000
Other quantitative risk assessment methods and references to them are outlined in the next table.
Table 29. Other quantitative risk assessment techniques Technique Decision tree analysis Sensitivity analysis Discrete distributions References Project Management Institute 2000 Chapman and Ward 1997, Project Management Institute 2000 Grey 1995
Hanna-Leena Saari
137
Appendix 7. Description of a previous independent study by the author concerning present state of project risk management in the case company
The research was conducted in the summer of 2002, from June 3rd to August 30th. In this appendix, the research question, study objectives and scope of the study are first presented. Then, research methods are described. A summary of the results of this confidential study regarding the case company and the first study objective, i.e. present state, is presented in section 5.3. Research question and study objectives: In the study the research question was: How are project risks managed in practice and how should the procedures be improved? The first main objective of the study was to find out how project risks are managed currently in the case company and more specifically in its research and development projects. Also, to get a perspective, other business divisions of the case corporation were examined. The first main objective was studied with the help of four subobjectives. These sub-objectives were the following: Find out what are the tools, methods and/or processes used in risk management what kind of documentation is usually done during the risk management process, for example risk management plan, and identified risks and responses to them what kind of resources are used and how much time is explicitly spent on risk management how are the outputs of a risk management process, for example risk lists and best practices, used in other projects
at present in the case companys pharmaceutical research and development projects, and in other business divisions of the corporation. The main emphasis of the study was on this first objective to create a firm basis for future development of risk management processes in the case company. Furthermore, the sub-objectives acted only as a guide to investigate the present situation of risk management and not as a closed set of questions to be answered. The second main objective was to identify how the risk management practices could be improved. The objective was not to create a single, universally applicable risk management process but to identify the major areas of improvement and present enhancement ideas that can be easily implemented within these areas.
Hanna-Leena Saari
138
Scope of the study: As already specified by the research question, the study concentrated on pharmaceutical research and development projects in the case company. For example, product support projects and further development of formulations were excluded from the study. Also, research and development projects in other business divisions of the corporation were studied as a benchmark. There are several processes that influence the development of risk management. Project portfolio management requires certain information to be produced during risk analysis. It also affects the way risks are responded to: some risks may be handled at the portfolio level while others at the project or functional program level. Current project management processes affect the way risks are managed now and how it should be done in the future. Risk management should be incorporated to other project management processes as much as possible. Knowledge management determines the amount of organisational learning in risk management. For the risk management process to be effective, the results of previously conducted risk management activities should be used in future projects as well. These results might include identified risks and used processes. It is also desirable to incorporate the risk management process to the functional processes as well. Also, change management processes need to be linked to the risk management process. Finally, information systems can be the key to the utilisation of different risk management practices and also act as a link to other processes. Ideally, information systems should not inhibit the use of diverse risk management practices but provide essential input into the process. Even though the study did not focus on these issues they still had to be acknowledged in this study. The constraints and requirements imposed by them should be identified and taken into account when improving risk management practices. The implications to project portfolio management and knowledge management were discussed somewhat more. The risk contents considered in the study were not limited to certain risk types. The restriction would be quite impossible, because the meaning of project risk is still somewhat unclear in the organisation. Also, the amount of risk management and risk documentation was not too extensive to require restrictions about the risk contents. The study was further scoped with the interviews that are discussed in the next section. Research methods: The study was conducted with focused interviews and examining existing project documentation. Some literature on risk management and pharmaceutical R&D projects was also reviewed. Focused interviews suited the study, while the area that was examined was not well known in the case company. Thus, it was not possible to form purposeful and complete questions that could have been used in questionnaires. In
Hanna-Leena Saari
139
interviews, it is possible to ask for more information and further questions if the need arises. Also, focused interviews allow one to form a more comprehensive and thorough picture of the phenomenon under study. The downside of focused interviews is that the analysis of the results is quite difficult. The information gained can be of different types and requires a lot from the researcher to be able to make conclusions of desired quality. The results were even more mixed in the case company because the meaning of risk and risk management is not the same in the whole organisation. Thus, these definitions were introduced in the beginning of the interviews. The structure of the focused interviews is presented in the end of this appendix. The research approach was analytical. One first got acquainted with the subject, then studied and analysed the present situation and finally came to conclusions about how the situation can be improved. Before conducting the actual interviews some preliminary interviews were completed to see the big picture of the situation. Also, after the information gathering as well as analysis and synthesis phases some interviews were done to find out more improvement ideas and to see whether the improvement ideas are realistic. The basic set of the study included all the persons from the business divisions investigated, who participate in research and development projects as leaders of various parts of the project. A sample was taken to be able to restrict the amount of interviews done. The sample was taken so that all major functional areas were represented. Also, it was desired that persons from different levels of the project organisation took part in the session, i.e. functional team leaders, functional line managers and line or project workers. This was not realised in all interviews, however. Taking a sample as opposed to taking a random sample of sufficient size naturally decreases the generalizability of the results. Some people were interviewed alone and others participated in group-interview sessions. The session lasted from one to two hours. Some literature on pharmaceutical R&D projects and risk management was reviewed to prepare the interviews. This was also of help when making improvement suggestions to the risk management processes. The end result of the study included descriptions of the risk management processes in use and the documents composed during the process. Also, the amount and type of resources was described. A general argument of the level of risk management was stated with the help of the benchmark information from the other business divisions and models found form the literature. Last, improvements to all the points presented above were suggested. Structure of the interviews Purpose of the interview: How are risks managed at the present
Hanna-Leena Saari
140

What risk management documentation is done Who is responsible for risk management and how much time is spent explicitly Are the outputs of risk management used somehow How could the situation be improved
Beginning: What is the purpose of the session How are the results going to be used What is the future of the development effort What are risks and risk management
Participants: Background information of the interviewees (education, title etc.) Responsibilities and tasks usually allocated to the interviewees in projects
Processes, tools and resources: Where and when are risks discussed? Is risk management planned as other activities in the projects? What are the inputs to the process? How, when and by whom are risks identified? What kind of risks? How and by whom are the effects and probabilities of risks assessed (qualitatively, quantitatively)? How are the risks prioritised? When (proactivity or reactivity) and how (response strategies) are the risks acted upon? By whom? How is the development of risk items followed? Or the effect of risk responses? By whom? Is the approach same in all projects? How often are the risks identified/assessed etc.?
Documentation: Which parts of the risk management process are (identification/assessment/etc.)? By whom? When? Where? How? What documents should be reviewed? documented
Resources: Are there clear roles and responsibilities for taking care of risk management?
Hanna-Leena Saari
141

How much time is spent to risk management? Who is the primary person responsible for risk management? Who participates in the process?
Use of output: What kind of information from other or past projects is taken advantage of?
Future: How risk management should be developed? How much time can be allocated to risk management? Who should be responsible for and participate in risk management?
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Appendix 8. Further illustrations on the results of the first-stage interviews
142
In this appendix the results of the first-stage interviews are presented in a refined form as tables. Each table presents the answers for one question presented in Appendix 1. The first part of the questions dealt with different stages of the drug development project. Thus, these questions are presented with tables that outline answers and all stages to which the question is connected. A plus sign denotes the fact that a certain answer was stated for a stage at least once while a minus sign in one cell means that this answer was not connected to the stage in question. The caption of each table and also the table headings present the question analysed in the table. Furthermore, there is a column providing examples and additional information for the answer.
Table 30. Interviewees answers for the definition of the goal of project risk management Goal Planning Decisionmaking Enhance own work Avoid tunnel vision Enhance project performance Feasibility and definition + + Planning + + Development + + Launch + Examples Aim: cut time. Comparing projects, assessing the viability of the investment.
+ -
+ + +
+ + +
+ Make sure that the given constraints of time, cost and scope are achieved, increase success probability, support the process of ensuring the compounds safety and efficacy, ensure successful launch.
Aid in executing project work Updating risk information Managing risks
+ +
+ +
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 31. Interviewees answers for what issues are discussed at different project stages Issues discussed Markets Competitor s Pricing Regulatory guidelines Changes in the medical science Contracts and CROs IPR Schedule Scope Results of the studies Budget Scientific issues Production process Availability of raw materials and the product Feasibility and definition + + + + Planning + + + Development + + + Launch + Examples
143
Situation now and in the future.
Changes in the treatment methods.
+ + + + +
+ + +
+ + +
Some attributes of TPP are not achieved. Efficacy, dosage, side effects, toxicology, keeping qualitites. E.g. predictability of animal models.
+ -
+ + -
+ + -
+ +
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 32. Interviewees answers for who is responsible for risk management Responsibility Program leader Feasibility and definition + Planning Development Launch Project completion + Additional information
144
Leader of the program core team, during planning, responsible for production and commercial risks, responsible for external risks. Supporting role. Leads the project team, coordinates efforts, responsible for the schedule, responsible for internal risks, during launch: clinical studies and regulatory issues. Responsibility for budget risks. Responsibility spread: pharmaceutical product development, industrialisation and global sales. Responsibility spread: pharmaceutical product development, industrialisation and global sales. Responsibility spread: pharmaceutical product development, industrialisation and global sales.
Discover y Project manager
+ -
Line organisati ons Pharmaceutical product development
Industrial i-sation
Global sales
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 33. Interviewees answers for who should participate in risk management Participants Project manager Project team Program leader Program core team Brand manager All line organisati ons Feasibility and definition + + + + + + Planning Development Launch Project completion + + + + -
145
Additional information
+ + +
+ + + + +
+ + + + -
Internal risks.
External risks.
Pharmaceutical product development, marketing, medical marketing, preclinical, clinical, supply chain management, registering, global sales, business development (if the product is in-licensed), support functions involvement, also health economics.
Those participating in planning/ execution Experienced people Industrialisation, marketing and registration
Validation of the analysis or active participation.
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 34. Interviewees answers for should risk management efforts be team-based Feasibility and definition Yes No A combination of these + + Planning Development Launch Project completion + -
146
Additional information
+ +
+ +
+ +
Project managers task. First individual/tea m effort needed in gathering functional risks, after that team work in the project team: brainstorming, stupid questions allowed, open discussion.
Table 35. Interviewees answers for what the time horizon for risk management should be Time horizon Entire project Feasibility and definition + Planning + Development + Launch + Additional information The near future can be discussed in more detail.
Until launched at key markets Life cycle of the product Until proof of concept (end of Phase II) A certain limit from launch, e.g. 2 years
+ + -
+ + +
+ -
+ -
Risk management will turn into change control some time after launch.
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 36. Interviewees answers for how detailed the risk discussion should be Time horizon Near future in more detail, entire project in outline The big issues that have an effect on the entire project Risks that affect the time, cost and scope unbearably; define limits in beforehand Project level Feasibility and definition + Planning + Development + Launch + Additional information
147
E.g. when schedules are endangered, if efficacy problems or side effects are reported, new competitor information from business intelligence or other sources. As time is always limited, a required limit could be defined. Each team leader should have the insight to determine which risks to take into the project team, sometimes all functional risks could be reviewed, too. It is better to inform too much than too little.
As detailed as possible Study level Use own assessment to determine
+ +
+ +
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 37. Interviewees answers for when risk identification should be restarted When new risk analysis Before decision-points Before portfolio reviews When the situation changes Development + + + Launch + Additional information
148
I.e. before gates, when starting a new stage, before strategy and budget rounds. E.g. when new information is gained, partners get involved or new investments are planned, when new risks arise or the old change. Only update needed at decision points.
Continuous When needed
+ +
Table 38. Interviewees ideas about the means of achieving a continuous risk management process during development stage Means An agenda item in meetings Additional information Project team and program core team, at the start of meetings. Idealistic to think that the process could ever be completely continuous. The project manager should communicate intensively with the project team members. When ideas are on paper they can be more easily updated and followed. Include risks in reports and documents. Have risk management ghost busters, which are outsiders to the project, regularly challenge the analyses.
A part of standard project reports Communication
Review Bind tightly into the work of the project team Good and easy-to-use tools Require an update once a year from the project manager
Table 39. Interviewees answers for where risk documents should be stored Storage Document management system Store all standard risks, i.e. not project-specific, in an open database Public place Active distribution to all project managers in addition to the document management system Additional information Have a joint folder where all lessons learned data would be stored.
Hanna-Leena Saari
149
Table 40. Interviewees answers for how to ensure that collected risk information is utilised in future projects Means Store all documents in one place Proper archiving Good communication Send a summary document for all project workers Could be used at least in project planning Additional information
Table 41. Interviewees answers for what could be used as a common measure for risk assessment enabling comparison between projects Measures Money Additional information All things cannot be expressed in monetary terms, some scope and schedule variations can be transformed into monetary units.
Time Scope Low/Medium/High Should include a description of the risk and why it is listed, there should be a common definition for the categories.
Questions that must be answered Measure not important: the issue must only be discussed in the project team, assessment can be done elsewhere
Table 42. Interviewees answers for where does the input for the analysis come from Source of input Line organisations Additional information The team leader must first discuss issues in the line organisation to get input from seniors. Risks are identified and assessed in line organisations, responses are determined in the project team and implemented in the line organisation.
Experts Individuals in the project team
Hanna-Leena Saari
150
Table 43. Interviewees answers for whether all or only a part of risks should be discussed in the project team All/partly All Only operational risks Risks affecting project progress Additional information Also external issues must be discussed. Some project team members may have to acknowledge changes in external and strategic issues as well.
Table 44. Interviewees answers for whether responses should be reactive or proactive Proactivity/reactivity Proactive Reactive Additional information The goal, all risks cannot be dealt with proactively. Define plan B:s, the first step in introducing risk management.
Table 45. Interviewees answers for how new risks should be brought into the attention of the project manager and team Ideas Effective communication Additional information Open culture needed, the team leader should directly inform both project manager and line organisation manager, project manager responsible for communicating actively with project team members, team leader must constantly communicate with project workers. The team leader status must be such that all workers know who should be informed if variations occur.
Project workers should turn to team leader, who should inform other parts of the line organisation, including line organisation manager, and project manager and team if necessary Meeting agenda and standard reports No standard approach needed Unofficial routes
Hanna-Leena Saari
151
Table 46. Interviewees answers for how project workers can be motivated for managing risks Motivation ideas No problem Additional information Ensure proper information flow, rely on workers professional pride, just another way of doing the same things done today. Inform everyone why risks are managed, why it is important, and how does this affect other peoples work, risk management not criticism or pessimism.
Awareness and education
Ensure enough resources and time Process and tools should be regarded as useful Bind risk management closely to project work Incorporate risk management as a part of personal goals of project team members Risk management would become a part of regular bonus system.
Table 47. Interviewees answers for when and how risks should be raised above the project level When and how According to predefined decision rules Program core teams decision, program leader takes forward Inform program core team about the bigger issues Project manager and team decide which risks and when to take them into higher levels Additional information Criteria changes according to company strategy, project managers responsibility. Project manager must present project risks in program core team meetings.
Table 48. Interviewees answers for who could and should use the information generated by risk management activities Users of risk information Project team Other projects Functional teams Line organisation Program core team Business unit heads Management Portfolio management board
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 49. Interviewees ideas for who should be the owner of the risk management process
152
Process owner Project management department Core therapy areas process Development manager at company level Whoever, as long as works in close collaboration with users
Table 50. Interviewees answers for how public risk management documentation should be Access rights for documentation The case company Project team All project managers All program leaders Other projects Line organisations Upwards in the project and line organisations Everyone working in the project Not for everyone Strategic issues should not be published Rights for reading the document. To avoid dishonesty of results if there is competition between projects, can be published after the project is completed. On an as-needed basis. Additional information Take care when documenting patentability issues, enables learning. Right to modify the document.
Hanna-Leena Saari
Helsinki University of Technology Risk Management in Drug Development Projects Table 51. Interviewees answers for how often there are changes in the project Rate of change After strategy and budget rounds Changes precede decision points Additional information Twice a year.
153
Portfolio management board decisions quite restricted, i.e. after changes a new decision must be made. Normal turnover. Even once a month.
Project environment: at least once a year Project personnel: quite often Schedule: quite often New and unknown molecule or indication: more changes New partner: unanticipated changes Change not regular Regulatory changes: can be predicted Scope should not change at all Study results may change the way things are done At first, changes can occur at great pace, later studies are longer and thus changes occur more seldom. Things may remain static for years and then many things may change at the same time.
Hanna-Leena Saari

Report Saari 012004 PDF

Uploaded by

Copyright:

Available Formats

Report Saari 012004 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Report Saari 012004 PDF

Uploaded by

Copyright:

Available Formats

Helsinki University of Technology Laboratory of Industrial Management Report 2004/1

RISK MANAGEMENT IN DRUG DEVELOPMENT PROJECTS

ISBN 951-22-7105-2 Printed ISBN 951-22-7106-0 Electronic ISSN 1459-806X Printed

Monikko Oy Espoo 2004

Helsinki University of Technology Risk Management in Drug Development Projects

PHARMACEUTICAL INDUSTRY AND ITS NEW PRODUCT DEVELOPMENT PROJECTS .....7

PROJECT RISK MANAGEMENT............................................................................................................29

PROJECT RISK MANAGEMENT IN DRUG DEVELOPMENT PROJECTS ..................................57

CASE COMPANY AND METHODOLOGY............................................................................................70

EMPIRICAL ANALYSIS ............................................................................................................................76

DISCUSSION AND CONTRIBUTIONS OF THE STUDY ..................................................................106

Helsinki University of Technology Risk Management in Drug Development Projects

APPENDIX 8. FURTHER ILLUSTRATIONS ON THE RESULTS OF THE FIRST-STAGE INTERVIEWS

Helsinki University of Technology Risk Management in Drug Development Projects

Helsinki University of Technology Risk Management in Drug Development Projects

Helsinki University of Technology Risk Management in Drug Development Projects

Helsinki University of Technology Risk Management in Drug Development Projects

1. INTRODUCTION 1.1. Background and Motivation

Helsinki University of Technology Risk Management in Drug Development Projects

Distinctive characteristics of pharmaceutical industry and drug development projects

Best practises for managing risks in drug development projects

Definition of project risks and risk management

Risk management processes, approaches, and tools and techniques

Figure 1. Research problem and objectives of the study

Helsinki University of Technology Risk Management in Drug Development Projects

Helsinki University of Technology Risk Management in Drug Development Projects

Helsinki University of Technology Risk Management in Drug Development Projects

Best practices for risk management in drug development projects

Risk management process description

Requirements of the process Finalising the process description, validation

Risk management tools and techniques

Initial tool selection Final selection and development of tools

Figure 2. Role of research methods in answering to the research problem

Helsinki University of Technology Risk Management in Drug Development Projects

How should risks be managed in practise in drug development projects?

Distinctive characteristics of pharmaceutical industry and drug development projects

Best practises for managing risks in drug development projects

Definition of project risks and risk management

Figure 3. The structure of the study in comparison with study objectives

Helsinki University of Technology Risk Management in Drug Development Projects

Helsinki University of Technology Risk Management in Drug Development Projects

Special characteristics of the pharmaceutical industry

Intellectual property rights Recent changes

Figure 4. Special characterictics of the pharmaceutical industry

2.1.1. Industry Structure

Helsinki University of Technology Risk Management in Drug Development Projects

2.1.2. Recent Changes in the Industry

2.1.3. Intellectual Property Rights and Regulations

Helsinki University of Technology Risk Management in Drug Development Projects

2.1.4. Importance of Research and Development

Helsinki University of Technology Risk Management in Drug Development Projects

2.1.5. Summary: Special Characteristics of Pharmaceutical Industry

Drug Development: Process and Special Characteristics

Helsinki University of Technology Risk Management in Drug Development Projects

2.2.1. Innovation Management and New Product Development

Incremental Product Service What is changed Process

Figure 5. Dimensions of innovation space (Tidd et al. 2001: 8)

Helsinki University of Technology Risk Management in Drug Development Projects