Risk Management Capability Maturity Model for Complex Product Systems (CoPS) Projects K T Yeo1,* and Yingtao Ren2
1
Division of Systems and Engineering Management School of Mechanical and Aerospace Engineering Nanyang Technological University 50 Nanyang Avenue, Singapore, 639798 Email:
[email protected] Tel.: +65 6790 5502; fax: +65 6792 4062
2
Department of Industrial and Systems Engineering University of Southern California 3715 McClintock Ave Los Angeles, CA 90089
ABSTRACT This paper aims at conceptualizing and developing a multi-level framework for the Risk Management Capability Maturity Model (RM-CMM), specifically for Complex Product Systems (CoPS) projects. CoPS is a special class of projects, which are high value, technology and engineering intensive products or systems that are typically used to produce consumer goods and services. The embedded and inherent complexity in terms of task and human relations in CoPS
1
projects can be a major source of risk and can contribute to persistent project challenges, failure and impairment. There is a need to build a progressive risk management capability to deal with the unique characteristics of these complex projects. The proposed CoPS-RM-CMM model defines two broad layers in systems “security” and organizational “robustness”. The understanding of complexity inherent in CoPS projects is drawn from the science of complexity and emergence which provides additional insights into the management of both predictable and emergent risk in CoPS implementation. The proposed model is also built upon a change management framework, which addresses the risk planning and control processes, organizational and people contexts, and technology contents of CoPS.
Key words: Complex Product System (CoPS); capability maturity model (CMM); emergence; complexity theory; project risk management
*
Corresponding author.
2
1. I&TRODUCTIO& The Capability Maturity Model (CMM) is a well established software engineering process improvement model developed by the Software Engineering Institute (SEI), Carnegie Mellon University. The concept of process capability maturity model has been applied to many aspects of organizational, human resource, people, project and product development as a means of assessment and as part of a framework for continuous improvement. However, there is an absence of a similar application to a special class of projects, namely, the Complex Product Systems (CoPS). There exists a need for a model specifically developed to deal with inherent risk due to task and human relational complexity associated with the CoPS. The main objective of this paper is to conceptualize and develop a multi-level framework for the Risk Management Capability Maturity Model (RM-CMM) for CoPS projects. When developing the model, we will take a systemic perspective to emphasize both logical and social aspects of risk management; and a strategic change management perspective to deal with the risk planning and control processes, organizational and people contexts, and technology contents of CoPS. Incorporating both the systemic and change perspectives in developing the maturity model represents an alternative and innovative approach to the original software engineering approach. What are CoPS? CoPS are high cost, engineering-intensive products, systems, networks and constructs [Hobday, 1998]. CoPS invariably embed high-technology product components and often engineering software. These product components are usually by themselves complex systems or subsystems. The inherent complexity, due to a large number of these product components, task and human interactions, can be a major source of project risk and uncertainty
3
contributing to persistent project challenges, failure and impairment. This concern motivates the proposal to develop an alternative risk management capability model for CoPS projects. CoPS are perceived to be having the following characteristics [Hobday, 1998]: It is multifunctional and involves multidisciplinary skill/knowledge inputs. Its system life cycle may last for decades and has a large product or system breakdown structure. It uses many customized components and equipment often involving long delivery lead time. System requirements analyses are client operator-driven. It involves high level of people-embedded knowledge in systems engineering, design and development. Its success depends on a high level of core competencies in systems engineering and integration and complex program management. Large scale CoPS are likely to be developed in stages to allow learning, risk management, and flexibility in response to market growth trends and competition. CoPS could take a form of a system of systems (SoS) as it goes through a progressive staged development. Management of multi-firm alliances and prior institutional arrangement to facilitate robust system implementation are common. CoPS are typically found in aerospace and defense, high-tech manufacturing such as semiconductor wafer fabrication, chemical and petrochemical, pharmaceutical, offshore oil and gas, energy; infrastructural development of airport, seaports, mass rapid transit, electricity generation and distribution; and environmental systems in water resource management and waste treatment. CoPS represent major national and commercial capital assets formation and are critical to national economic and social development and well-being.
2. QUESTIO&S CO&CER&I&G RISK MA&AGEME&T MATURITY
4
CoPS projects are characterized by inherent task and human relational complexity with associated risk, both predictable and emergent in nature. There is logically an intimate link between risk management capability maturity and success of projects, since risks are measured by their potential effect on achievement of project objectives. However, the implementation of risk management reaps varied degrees of success, and many are discouraged for failing to achieve desired benefits [Hillson, 1997]. Organizations wishing to implement a formal approach to risk management or to improve their existing approach need a better operational framework to appreciate the nature of risk and requisite capability maturity and against which to benchmark their current practices by continual learning and improvement. In CoPS projects, adverse events often emerge as “surprises”. Complex products and integrated systems tend to exhibit non-linear and emergent properties during production or implementation, as unforeseen and unexpected events and interactions often occur during design and systems engineering and integration phases [Boardman, 1990; Shenhar, 1998; Hobday and Rush, 1999]. A different view of complexity [Mitleton-Kelly, 2003] is emerging in recent years that may have important implications for management of complex product systems. Approaches based on the causal, linear logic of mechanistic sciences and engineering become counterproductive when the same organizations display the highly reflexive, context-dependent, dynamic nature of systems in which human actors learn, react, and adapt as new patterns emerge [Dent, 1999]. Singh and Singh [2002] discussed the basic elements of complexity and chaos theory and its implications for project and cost management. Ramaprasad and Prakash [2003] extended the concept of emergence to project management and called it “Emergent Project Management”, which was the method of using emergence to elicit local knowledge, integrate it with the global knowledge, and use the integrated knowledge to manage projects more
5
effectively. Human organizations can be more effective in designing and developing complex products and systems, when they themselves are perceived and understood as complex evolutionary systems. The emergence principles of complex systems offer important contributions to the integration of diverse perspectives and new creative insights into organizational effectiveness and in risk management capability building. The research questions of this paper are: What kind of factors can enable the CoPS project organization to be more effective in dealing with risks, both foreseeable and emergent? Do we need an operational model to frame these influencing factors? How can risk management capability be improved in a systematic, measurable and effective way? What are the characteristics of different levels of risk management capability maturity? This paper attempts to investigate these questions through developing a risk management capability maturity model for CoPS. The proposed conceptual model involves the integration of capability maturity modeling, project risk management, CoPS production system, complexity theory and emergence in relation to a complex, adaptive, evolutionary system and a change management framework in process, context and content as well as soft system thinking, as illustrated in Figure 1. When developing the model, we take a CoPS producer perspective and focus on the risks associated with completing the project meeting time, cost and quality objectives. -Insert Figure 1 here-
3. CAPABILITY MATURITY CO&CEPTUAL MODEL A major benefit of modeling capability maturity is to provide a framework for defining and selecting process improvement strategies by first determining the current capabilities of specific processes and identifying the areas of weaknesses and related issues most critical to process and
6
performance improvement within a particular domain, such as software engineering, systems engineering, product development or human resource management. A CMM may take the form of a reference model to be used as a guide for developing and building a maturing and defined process. CMM has been generalized to other areas including general project management [PMI, 2003; Crawford, 2002; Kerzner, 2001; Ibbs and Kwak, 2000] and new product development [Dooley et al, 2001]. These CMM’ s are process-oriented, formalized and developed into templates. The original CMM for software engineering developed by the Software Engineering Institute, Carnegie Mellon University, classifies software organizations into five levels of maturity based on the sophistication of their engineering and management practices namely: initial, repeatable, defined, managed, and optimizing. Organizations that do not have systematic software engineering methods and tools are classified as level 1 or 2. Their software development performances heavily depend on non-standardized factors such as managers’ experience, competency and even personal efforts. Firms classified as 4 or 5 have demonstrated process improvement and optimizing capabilities that allow them to meet schedule, cost, quality and functionality targets [Paulk et al., 1993]. Now the model has evolved to become CMMI, where “I” stands for “Integration” of Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing. There are several known risk management maturity models that have been proposed over the years. One of them is the risk maturity model developed by Hillson [1997], which has four maturity levels (Naive, Novice, Normalized, Natural) and are measured in terms of four attributes (culture, process, experience and application). The Risk SIG [2002] also proposed a risk management maturity model with four levels of maturity: Ad Hoc, Initial, Repeatable, and
7
Managed. However, these models are designed for general-purpose projects without addressing the issues of complexity and resulting emergent risks. They become inadequate when measuring CoPS projects. They lack adequate theoretical support and the application of relevant systems concepts. CoPS-RM-CMM is proposed with the view to overcome some of these limitations and conceptual weaknesses. The proposed model will consider core process maturity, maturity of the supporting project organization and technology content. A special area for the proposed model is to gain creative insights directly from complexity theory and emergence principles and to have an intrinsic ability to deal with dynamic changes and uncertainty.
4. PROJECT RISK MA&AGEME&T (PRM)-CURRE&T STATUS The management of risk in major projects has been one of the main topics of interest for researchers and practitioners. Risk management has been designated as one of the nine main areas of the Project Management Body of Knowledge [PMBOK, 2004] by the Project Management Institute (PMI). PRM is also seen as an integrative process that accompanies the project from its initiation, planning, execution and control phases up to its completion and closure. The project management process risk should, however, in principle, decrease as the project progresses to later phases; but we cannot rule out the threat of unforeseen emergent risk until successful handover to the client’s operations. The value of a formal and structured approach to PRM is becoming increasingly recognized as more organizations begin to reap the benefits of proactive management of risk and uncertainty. Risk management covers almost all other project management knowledge areas such as cost, time, quality, scope, resources (human and procurement), communication, and integration. The objectives of risk management include not only project or system level objectives, but also the
8
business objectives of value creation and profitability. Risk is pervasive and is increasingly extended to cover issues on safety, health and environment. A comprehensive approach to dealing with risk must, in principle, increase the chances of meeting or even surpassing pre-defined project objectives. This can be achieved by gaining a better understanding of the nature and sources of risk and approaches for risk mitigation. Many researchers and practitioners believe that managing risk is the single most important factor or function in ensuring successful project management [Chapman and Ward, 2003; Kerzner, 2000]. According to practitioners surveyed [Whittaker, 1999], IT project failure was most commonly attributed to lack of top management support and commitment, a weak business case and poor project planning. The highest ranked factor for project failure was poor project planning in two distinct areas: risks were not or inadequately addressed as part of the project planning process, and the risk management plan was weak. For risk management applications, Chapman and Ward [2003] suggested that comprehensive risk management processes tend to be most useful when dealing with projects involving substantial resources, significant novelty, long planning horizons, large size, task complexity, multiple organizations, and significant political issues. They also observed that organizations with an established risk management capability as a process can have an important advantage over competitors. A survey conducted by Raz et al. [2002] also showed that risk management techniques are mostly applicable to highly complex, uncertain, and risky projects. Risk management will be a core area in managing CoPS projects. However risk management specifically targeting CoPS projects is still a relatively underdeveloped. A study of Fortune 500 companies which evaluated the quality of project management and the success of their projects, showed that risk management was notoriously
9
weak [Ibbs and Kwak, 2000]. This study showed that the risk of variation and overruns are far from being under control. Risk management's maturity level was the lowest in comparison to all other eight PMBOK [2004] areas. Risk management was the only knowledge area in which its overall project management maturity level was below 3, which was considered immature, on a 15 scale. Consequently, it is strongly recommended that companies should put more effort into the risk management area. Zwikael and Globerson [2004] surveyed the quality of project planning, also found that the quality of risk management planning was ranked 8th (the score is 2.7 on a 1-5 scale) among the nine knowledge areas. A set of rather generic project risk management processes are contained in the PMBOK [2004] and the Project Risk Analysis and Management – PRAM [Chapman and Ward, 2003]. PRAM has a special importance because it was the first comprehensive process developed by a large team, including both practitioners and academics. The importance of the PMBOK [2004] processes lies in its relevance as an accepted ANSI standard. PRAM tends to reflect a more “British-European” way of performing project risk management; whereas, the PMI PMBOK’s risk management section was prepared by a mix of contributors from United States, Canada and Europe (mainly UK). Nevertheless, project risk management practices, as a whole, are not very dissimilar between North America and Europe. They both represent generic project risk management process models, though the manner in which the steps or activities in each model are labeled varies. A summary of the key elements from these models are extracted and shown in Table 1. These key risk management process elements are to be included as the systematic foundation and basic measurement instruments of the proposed model. -Insert Table 1 here-
10
For non-systematic measurement, one important research focus is the need to match management styles with uncertainty types. Shenhar [1998] has proposed a two-dimensional model for project classification according to: 1) technological (content) uncertainty, where projects are classified into Low-, Medium-, High-, and Super High-Tech; and 2) system scope, reflecting project complexity where projects are classified as assembly, system, and array. His survey showed that high uncertainty and high complexity projects need more risk management, system integration and configuration management effort. Similarly, Yeo [1995] built a framework of risk framing in technology acquisition projects by using the soft system methodology (SSM) and the availability of adequate and relevant mental models. The strategy of risk management is making the shift in framing problems through a highly dynamic planning and learning process -- from uncontrolled uncertainty to controlled certainty. De Meyer [2002] classified projects into four categories according to uncertainty profiles: variation, foreseen uncertainty, unforeseen uncertainty, and chaos. How to match different management styles to each type of project uncertainty is proposed. A review of the published literature shows PRM research has not addressed directly and specifically the problems unique to CoPS projects and the challenges of complexity, both in project tasks and human relations and organizations. The shortcomings are: •
The lack of a clear and deep understanding of the nature of risk in CoPS projects and inadequate classification of risk areas and risk events;
•
Previous RM approaches are too generic to provide explicit guidance for implementation of risk management in CoPS projects;
•
Probability-based theory based on historical occurrences does not explain unforeseen emergent risk;
11
•
Inadequate attention to view project management as a change management process, which deals simultaneously with the important aspects of a project as in risk management processes, organizational context and environment, and technological content;
•
General failure to address human cognitive and psychological weaknesses, organization learning and politics;
•
The lack of a contingency approach in differentiating the nature and sources of risk for a range of project types. In fact, not all risks can be identified during the project planning phase. Emergent risks, often unforeseen, can rarely be pinpointed by standard systematic risk identification techniques, no matter how well executed;
•
There is no systematic treatment on the proposition that PRM performance is a function of project organizational capability maturity.
5. A& I&TEGRATIVE CHA&GE MA&AGEME&T FRAMEWORK 5.1. The Process, Context, and Content Framework This model of strategic change analysis was originally developed by Pettigrew and Whipp [1991] as a means of generating insight into why some private sector organizations were better able than others to manage strategic change and improve their competitive performance. The model was based on empirical case studies. It was subsequently developed and extended in the context of healthcare sector by Pettigrew et al. [1992]. It is a reminder that change takes place in historical, cultural, economic and political contexts. Successful change is a result of the interaction among the content of what changes (the substance); the process of how the substance changes (implementation); and the organizational contexts where change occurs (both the internal and external environments). They emphasize the continuous interplay between these change
12
dimensions. The implementation of change is an “iterative, cumulative and reformulation-in-use process”. The process-context-content framework and its later variants have been widely used in analyzing and learning retrospectively from change programs in organizations [e.g. Pettigrew, 1987; Pettigrew et al., 1992; Buchanan and Boddy, 1992; Peppard and Preece, 1995]. It has also been used to help inform quasi-experimental before-and-after studies [Ross and McLaren, 2000]. This was a major piece of empirical research which added to the basic literature and provided a diagnostic checklist which can be used to assess the likely acceptance of a particular intervention in a specific locale. It provides a reference model for framing the sources and types of risks in CoPS-RM-CMM.
5.2. A Proposed Four-S Framework to Categorize Project Risks We have studied 51 published CoPS project cases, ranging from aerospace and defense, commercial aircraft manufacturing, power plant, mass rapid transit, airport development, to offshore oil platform; and identified areas or sources of risk which can be adequately framed by the change management model which is now delineated into four subsystems namely process-, organization-, and technology-related risks, denoted as Sp, S1, and S2 risks as well as environmental (Se) risk, as illustrated in Fig. 2. -Insert Figure 2 hereFrom Figure 2, Process-related risks (Sp) are those that originated from the lack of project management competence and processes. Organization-related risks (S1) are from the internal context, representing the project organization, within which the project is to be executed. The organizational context is appreciated in terms of leadership, human resource, corporate value and
13
culture, structure, systems and policies. For instance, an inappropriate organization reporting structure can lead to serious communication problems, staff pressures, conflicts and adverse relationships between participants. Organizational culture has influence on the project development process. Technology-related risks (S2) originated from the unfamiliarity with adopted new technology platform, design, technical standards, inadequate in-house technical expertise and inability to provide solutions to technical problems. Studies have shown that technical problems could have a huge impact on the likelihood of project success or failure, as in the case of the Challenger disaster. Thorough and critical technical risk analysis is essential. It should be noted that these risks are not independent. They interact with each other and can lead to mission risks. Organizational risks are usually related to “soft” problems in the project, while process and technology risks are “hard” problems. In the context of a social-technical system arrangement, S1 represents the primary organizational system which is to be “served”, while S2, the technical system, will do the “serving”, as in the case of complex information systems [Checkland and Holwell, 1998]. Environmental risks (Se) are multi-layered. At the macro level, there are political, economic, social and technological (PEST) risks which are external to the project organizations and generally uncontrollable. At the industry level, there are the risks related to the various competitive forces such as the threats from product or technological substitution, disparity in the bargaining power versus the buyers and suppliers, existing rivalry and new entrants [Porter, 1979]. At the project or system implementation level, there are risks due improper or inadequate prior arrangements with external institutions such government agencies, financial institutions, prime contractors, major equipment suppliers, clients, community and pressure groups. Miller
14
and Lessard [2001] emphasize the importance of external institutional arrangements for shaping and building large engineering projects are prime determinants of success. The change management framework containing the four-S subsystems can further be supported by the Soft System Methodology (SSM) [Checkland and Scholes, 1990], which is suitable for pre-project planning and problems analysis using a dialectical systemic approach with simultaneous consideration of both logic and culture. The four-S framework as illustrated in Figure 2, contains a six-element mnemonic CATWOE representation which are used for formulating the “root definition” in the SSM. Customer (C): Everyone who stands to benefit from acquiring and using a product or system is considered as a customer. If the acquired system involves sacrifices such as lay offs or suffering injuries, then those users are victims, rather than beneficiaries. Actor (A): The actors, or project team, perform the activities defined in implementing the system. Transformation process (T): This is the conversion of input to output, representing the project implementation processes. Weltanschauung (W): The German expression for worldview. This worldview makes the transformation process meaningful in context, and considers stakeholders’ interests. Owner (O): Every system has a proprietor or promoter, who has the power or authority to start up, suspend or shut down the project. Environmental constraints (E): External elements or prevailing conditions exist outside the project organizational context, and often are taken as given.
5.3. Required Capabilities for Various Types of Risk Factors Risk factors are triggers of risk events. A risk event is a discrete occurrence that may affect a project, positively or negatively [PMBOK, 2004]. To cope with the recurring risks in the CoPS project cases, three kinds of capabilities in process, organization and technology (corresponding
15
to Sp, S1, & S2 subsystems) are simultaneously needed, which will form the key capability areas of the CoPS-RM-CMM. The process of generating the required capabilities for the CoPS-RM-CMM is as follow: first, we analyze the key failure and success factors of each of the 51 CoPS project cases studied which are supported by an extensive literature review and field interviews with senior project managers, and then we classify these factors into different categories according to the Four-S Framework: S1-S2-Sp & Se. We combine the common success and failure factors by the categories in order to make the groupings and model more robust, taking care of both the positive and negative potentials of each group. Table 2 summarizes common risk factors and required capabilities (success factors) in CoPS projects. The success factors will serve as the capability components of the CoPS-RM-CMM. -Insert Table 2 here-
6. CoPS-RM-CMM The development process of the CoPS-RM-CMM is as follows: Firstly, critical risk factors and success factors of 51 published CoPS projects were identified and evaluated. Required capabilities were inferred and generated to cope with identified risk factors. Then, a list of most important elements of project risk management process and maturity was identified. Finally, we combined and synthesized these elements into the process-context-content framework. At the same time, we build the structure by referring to existing CMM models. The purpose of the CoPS-RM-CMM is to provide a framework to help CoPS producers and project teams to benchmark their current approach in risk management against five levels of RM capability maturity. This model provides clear guidance to CoPS producers wishing to develop
16
or improve their capability to manage risk and uncertainty, and allows them to assess their current level of maturity, identify realistic targets for improvement, and develop action plans for increasing their RM capability maturity. The model is designed to be a multi-dimensional model that avoids ambiguity by making a single level assessment for overall RM capability maturity [Chapman and Ward, 2003].
6.1. “Security” and “Robustness” We propose a two-tiered structure for two broad categories of strategy to deal with complex project risks: “Security” and “Robustness”. Security, at the more foundation levels, is built to deal with known, largely internal, and relatively controllable risks; while robustness is built to cope with emergent, largely external and relatively less controllable (at least initially) risks. Security is based on traditional mechanistic worldview, and is directly applicable to planning and control systems (as in systematic approach) and processes as well as in addressing technology contents and capabilities. Robustness is based on a strong and relevant emergence worldview, and is more related to higher-order and more systemic organizational capabilities. Both security and robustness work in combination and interact with each other and demonstrate the total comprehensive capability of a successful project delivery process of CoPS. The combination of systematic (often linear) approach and emergence represents an innovative synthesis of relevant systems thinking and knowledge. The system-emergence combined approach coincides and supports the proposed security-robustness model. CoPS case studies show that only when all the participants of the project have high risk awareness, the organization as a whole can identify, appreciate and report problems, analyze and articulate real situations, and respond to risk scenarios quickly based on an appropriate mental model.
17
The basic idea of the CoPS-RM-CMM is to enhance the predictability and controllability of CoPS producers at a collective level, and provide guidance to build capability to cope with varied risk areas including process-, organizational-, and technical-related risks as well as external threats. Predictability and controllability are relative capabilities. In project organization, some members are more capable in dealing with certain areas of risk than others. In an open communication environment, members are more willing to identify and report risk events to senior management. Increasing robustness through improving internal soft capabilities, such as mission orientation, teamwork, commitment, enlightened management, internalization, and strategic arrangement and coalition, can also contribute to higher level of controllability. The increase in capability to predict and control risks is dynamic and non-linear. Novel ways of dealing with risk events may emerge through interaction of project members. The architecture of the model is shown in Figure 3. -Insert Figure 3 hereThe model is built on the precept that risk management is essentially a strategic change management, and the change process is convergent to achieve desired results in terms of overall risk mitigation and reduction. The theoretically sound and practically useful research on “change” needs to involve the simultaneous analysis of the internal and external contexts, content, and process of change [Pettigrew, 1987; Yeo, 2002]. It is measured through the supporting structure and culture, the process through which risk events are managed, and how important technology or technological systems are utilized. In order to improve risk management maturity, organization must build capabilities in organization (context), project/risk management process (process), and technology/systems (content) simultaneously.
18
The proposed CoPS-RM-CMM has the following components: 1) Maturity levels – A hierarchy of five maturity levels is proposed, adopting the similar 5level structure for software engineering, SE-CMM: Ad Hoc, Initial, Defined, Managed, and Optimizing. Each maturity level is a defined position in an achievement scale that establishes the attainment of certain risk management capabilities. 2) Key capability areas – There are 10 key capability areas which are organized into three categories: organization context (S1), PM/RM process (Sp), and technology content (S2) from the perspective of strategic change management. Risk management is not only a process; it is also a strategic insight, and a philosophy on continual improvement. It should combine both traditional systematic worldview with emergence worldview. Being systemic is to consider both logic and social/culture simultaneously. The combined approach will have significant impact on the performance of CoPS projects and the performing organization. At the demarcating Level 3, the systematic approach attains a mature state where there is already a formal risk management process being established which can be applied to identify, assess and manage most predictable or known risks. A systems and process level “security” is achieved at this level 3. This level of maturity enables the project team to control the risk management process and deal with anticipated risks. The systems capability will provide adequate security for smaller or less complex projects. Differentiating characteristics of level 4-5 are gaining increasing “robustness”. At level 4-5, a team risk management approach proposed by SEI [Higuera et al., 1994] is adopted, that is, multiple parties involved in the project collaborate and coordinate closely in managing both known and emergent risks. Robustness will enable projects with ill-structured objectives and scope implemented in a turbulent environment to survive. Robustness is necessary to deal with
19
relatively unpredictable emergent risks. It is built on strong and capable leadership, culture, teamwork, alliances and political skills. At level 4, the focus is on managing CoPS network risk through institutional arrangements. The project team is mindful of the threat of emergence risks. The project leadership can also create conditions for positive emergence to occur. At level 5, the highest level of maturity that is capable of achieving optimum result leveraging on a combined set of positive variables.
6.2. Five Maturity Levels of CoPS-RM-CMM The five levels of CoPS-RM-CMM are shown in Figure 4: -Insert Figure 4 hereLevel 1: Ad Hoc: At this base level, the organization is unaware of the need for risk management and has no structured approach to deal with risk. No attempt is made to identify risks in the project or to develop mitigation plans. The management adopts a reactive and mechanistic mindset, assuming the future events will take care of themselves. The normal method for dealing with problems is to react after a problem has occurred in a haphazard manner. It is unlikely to find CoPS producers existing at this level. The project organization is likely to conduct projects in a functional or loose matrix structure. There is little mechanism to cope with unexpected events. The organization is weak in even basic systems approach in managing projects. Level 2: Initial: At the Initial level, some basic risk management activities are performed in organization's PM processes. There are rudimentary PRM systems and processes. Although the organization is aware of the potential benefits of risk management, serious efforts to implement organization-wide RM process are still lacking.
20
Level 3: Defined: At this demarcating level, the organization has developed and implemented a formal RM system into their corporate business processes, especially when dealing with CoPS projects. Generic risk management policies and procedures are formalized and implemented company-wide. The benefits are understood usually at the higher levels of the organization. In CoPS projects, a defined and systematic RM process is in place. Probability, impact and severity of risk events are measured qualitatively. Risk owners are identified and assigned to their respective risk areas. At this level, project managers can deal with most known or predictable risks. An organization-wide training program is implemented to ensure that the staff and managers have the knowledge and skills required to fulfill their assigned roles. The project structure is likely to adopt a balanced matrix with emphasis on project management. Level 4: Managed: At this level, measurable process goals are established for each of the defined RM processes in identification, assessment and response. Risk impact and severity can be measured quantitatively. Detailed measures of various risk response strategies are developed and documented, and risk mitigation outcomes and performance are monitored and analyzed. These data enable quantitative understanding of the process and an improved ability to predict performance of risk mitigation measures. Risk management activities are extended to include key project stakeholders, both internal and external. Key contractors and suppliers, clients and internal corporate management are involved intensively in the risk management process. Robustness is instilled purposefully into the project structure and process through institutional arrangements. At this level, the organization has established a risk-awareness mindset that requires a proactive approach to the management of risks. The organization has the means to instill a certain level of robustness into the project structure and mechanism to cope with high
21
level of task complexity and associated emergent risks. The project organization is likely to implement a strong matrix or project-based organization (PBO). Level 5: Optimizing: At the Optimizing Level, the organization has established a comprehensive RM plan, with defined RM goals and use of both qualitative and quantitative measures. Continuous process innovations and improvements to achieve higher level of RM performance have become mandatory and a norm. High level of robustness is instilled into corporate culture-attitude and behaviour, adaptive project organization, team empowerment, selforganizing guided by corporate protocols to reduce systemic risks and deal with unforeseen emergent risks. Societal networking, multi-faceted institutional arrangements and partnering with external stakeholders and government agencies are in place. Business risks (e.g. alignment between project objectives and business case) are considered seriously. Project team members are sensitive to risks and opportunities and the needs to communicate freely and build a teamwork environment. Further enhancements and synthesis are achieved by pilot testing of innovative ideas and exploring and appreciating the potentials of new technology and methodology. The project structure is project-based, highly flexible and responsive to changes in customer requirements and external environment. A supportive culture exists that allows positive emergence to occur.
7. KEY CAPABILITY AREAS Risk management capability maturity is vital to project and business performance. Organizations must be committed to such efforts for all projects and throughout the project life cycle from conception to divestment. To cope with the most frequently cited risks encountered in the CoPS projects, three categories of capabilities need to be built: PM and RM process capability,
22
organizational capability and technological capability. Ten key capability areas are consolidated and shown in Table 3. Improving risk management maturity requires equal attention be paid to the project planning and control process, culture (values and norms), people (teamwork and leadership), organization structure and technology simultaneously. For example, risk management process will not likely be implemented without project leaders’ support and a risk awareness culture. -Insert Table 3 hereThese key capabilities can be delineated into “Security” and “Robustness”. Security is mainly related to key capability areas of process and technology, as they form the systems foundation to deal with predictable and internal risks. Robustness is mainly related to key capability areas of people and organization, as they help to build the capability to deal with relatively unpredictable risks, as shown in Figure 5. -Insert Figure 5 here-
7.1. Organizational context: Building robustness Building robustness is addressing the S1 sphere of influence within the four-S framework. The organization is responsible for risk management by building required capabilities in culture, stakeholder coalition, leadership, and appropriate organization structure. The requisite varieties for building robustness are further described below:
1) Organizational culture and learning: Open communication to risk: Establishing an open communication environment in which project participants are willing to openly identify, discuss and report risks. An open culture enables the
23
team to be aware of the current situation, and manage risks proactively. Delaying bad news brings more surprises. To deal with emergent risks and changes in CoPS projects, information must be open and free flowing in a timely manner. Traditional managers tend to control information and mete it out on a “need to know” basis. Due to lack of communication, team members often feel that they are not in control perceiving only the project manager has the “master plan”. An “open-door” policy is necessary to promote open communication among project stakeholders. Periodic progress and trends meetings allow critical evaluation and forecast of “flash” trends. External evaluation could also be sought to provide more holistic and objective outsiders’ observation and perspectives. Feedback control and double-loop learning: Since in complex organizations it is impossible to predict at a detailed level, it is necessary to emphasize feedback and double-loop learning. Double-loop learning occurs when problems are solved by challenging and changing the fundamentally held values, views, assumptions, underlying theory as well as formulated strategy and actions. The current mode of learning is maintenance learning, which involves the acquisition of fixed outlooks, methods and rules that deal with known events and recurring situations, which promote already established ways of working in the systems and institutions, and aim at maintenance of status-quo [Banathy, 1993]. In Banathy’s view maintenance learning should be complemented by evolutionary learning, which is a form of creative and innovative learning that is essential to overcome the present predicament of human organizations when dealing with complexity and uncertainty. Evolutionary learning allows actors not only to deal with change but also to shape it. It helps us suspend old assumptions, and create new perspectives. Evolutionary learning allows co-evolution with the environment and increases competence in managing change.
24
Build an open learning culture: Learning can only thrive in an open, unthreatening environment where mistakes are recognized as part of the process of organizational development. Risk-taking mindsets are necessary to ensure new methods or innovations are tried and new business opportunity is captured. Systemic, double loop learning can only occur if sufficient resources are made available in terms of time, money, support infrastructure, management and organization. In the short run, the costs may well outweigh the benefits. However, if successful, in the mediumto long-term, the gains in productivity, performance and effectiveness promise to greatly outweigh the costs [Hobday and Brady, 1998]. Make cross-project learning a priority: Underlying many of the problems in CoPS projects is a difficulty of learning from project to project. Although the systematic capture and transfer of knowledge and best practices from one project to another is difficult in a complex project environment, it is by no means impossible. The project learning and knowledge management processes can be embedded in the evolving systems and culture in project based organizations.
2) Stakeholder Coalition Build good relationships and collaboration: A major characteristic of CoPS is the elaborate nature of organizational dynamics involving multiple stakeholders. Each of them has an important role in defining the project objectives and ensuring that risks are borne by the parties that are best placed to handle them. The CoPS producers need to develop external network of relationships with operator, sponsor, government regulatory agencies, and major equipment suppliers. Stakeholder involvements in risk sharing and collaboration are needed in the risk management process throughout the project life cycle.
25
Have a shared project vision: It is important to have a clear sense of mission and objectives for CoPS projects, which should be in line with corporate/business goals. The management must have honest and continuous sanity checks during project implementation to ensure the project stakeholders remains committed to the project mission.
3) Democratic and vigilant leadership Empowerment and democratic management style: The primary task of leadership, both at corporate and systems levels, in a CoPS project are to motivate the networked project organizations for coordinated task accomplishment by maintaining a state of sustainable tension and a high degree of interaction. By keeping the organization on its collective “edge,” and matching the degree of complexity in its environment, the project leadership must adapt rapidly to external changes with robustness and competence. A democratic leadership style creates the space of possibility for project team leaders and members to self-organize by leveraging local information and specific situations. Self-organization alone will not lead to emergent change if leadership prefers stability or attempts to control the change process. A self-organizing structure guided by a set of broad corporate protocols helps to institutionalize a culture of creativity and innovation by minimizing unnecessary rules, boundaries, and other barriers to individuals, and maximizing mutual leveraging and development. Vigilant leadership: Vigilant leadership implies continuous recognizing, evaluating, responding, monitoring, learning and adapting to the environment. The project leadership should monitor the external environment, scan for possible emergent threats and opportunities continually. Early warning signals should not just be ignored, but must be considered seriously by the leadership.
26
Foster network construction: In complex organizations, effective leaders learn to manage and develop networks [Marion and Uhl-Bien, 2001]. They foster and cultivate interdependencies within and outside the organizations [Marion and Bacon, 1999]. As Levin and Regine [2000] concluded in their ethnographic study of leadership in a dozen US and UK industries that were operating according to complexity principles such as, “Leaders generally felt that it was their responsibility to enrich connections in the system, to forge new connections where none existed or to improve existing connections” (p. 10). They build and tend to network at the aggregate and meta-aggregate levels. Good project managers gain widely respected reputations and build up professional communities from different firms with shared long term interests that cut across firm boundaries. This building of trust is important not only for the execution of ongoing projects but also for cross company collaboration in future projects [Hobday and Rush, 1999]. .egotiation skills and influence of leadership: In large CoPS projects, it is frequently necessary for system integrator to lead projects that involve customer, users, regulators and large suppliers. These organizations may become involved in key design tasks as well as engineering and production. The leadership role then becomes one of negotiation and influencing. The function of negotiator needs to be performed by a skilled project coordinator or manager in order to resolve conflicts and reach win-win decisions [Hobday and Rush, 1999].
4) Organizational structure and support The purpose of structure in a CoPS project organization is to enhance systemic flexibility, fitness, and innovation by minimizing the use of restrictive policies, rules, regulations, procedures, and boundaries between institutional components, while creating architecture and systems that maximize flexibility, interaction, development, and an emergent change process.
27
Project-based Organization: New and unfamiliar problems arising in CoPS often require the flexibility provided by organizations with adaptive structures. A comparative case study is used by Hobday [2000] to identify some of the strengths and weaknesses of two organization forms for CoPS: project-based organization (PBO) and traditional functional matrix organization (FMO). On the positive side, the PBO is an intrinsically innovative organization form as it creates and recreates new organizational structures around the demands of each CoPS project and each major customer. The PBO is more able to cope with emerging properties in production and respond flexibly to changing client needs and requirements. It is also effective at integrating different types of knowledge and skill and coping with the emergent project risks and uncertainties. However, the PBO is inherently weak where the functional matrix organization is strong: in performing routine tasks, achieving economies of scale, coordinating cross-project resources, facilitating company wide technical development, and promoting organization-wide learning. Teamwork and collaboration: Self-organization and emergent order are due in part to rich interactions and collaboration between teams and agents in a complex adaptive project environment. These phenomena are explained as gestalt connectivity with each agent working in alignment with other agents. In complex projects, using flexible teams and web-like design is effective. For example, teaming was an important feature of the Boeing 777 program [Cohen, 2000]. About 30 integrated-level teams (ILTs) individually integrating and coordinating more than 230 self-organizing design-build teams (DBTs) at the bottom, worked together on the Boeing 777 program. Each team was responsible for a particular component or sub-system and included personnel from all disciplines: design, manufacturing, operations, procurement, customer support, as well as customer and supplier personnel.
28
Top management support: CoPS projects have strategic importance for the survival of firms. The project would not go well without strong top management support, which has been one of the most frequently cited sources of project failure or success. Top management should give support and allocate resources to initiate and conduct risk management activities and build associated culture in risk consciousness.
7.2. RM and PM Processes: Building Systems Security The RM process is addressed by the Sp sphere of influence under the four-S framework, which is responsible for continuous and effective risk identification, analysis, response planning, monitoring and control, and the integration of RM process with other project management processes. Each of these processes plays a critical role, and a weakness in any one of them undermines the risk management process capability as a whole. The integration with other processes includes an assessment of the extent to which risk management is integrated with other management processes in cost, time, scope, quality, integration, and human and material resources. 1) Risk planning and identification: This capability area has two processes: risk management planning and risk identification. RM planning is the process of deciding how to approach and plan the risk management activities for a project [PMBOK, 2004]. The main activities include assigning responsibilities and ownership for risk management, defining risk parameters, and define risk sources and categories.
Risk identification is the process of deciding which risk
events might affect the project outcomes and documenting their characteristics [PMBOK, 2004]. Risk identification is the responsibility of all members of the project team. Risk identification "brainstorming" sessions can be conducted to help in the initial identification and appreciation of
29
risk areas and improve risk awareness. The utilization of historical risk data can help identify initial risks and train new employees. To be effective, a broad range of risks should be identified during the project planning phase. 2) Risk analysis: There are qualitative and quantitative aspects of risk analysis. Qualitative analysis evaluates potential risk areas and events to prioritize their effects on project objectives, while quantitative analysis is measuring the probability and consequences of risk events and estimating their implications on project’s objectives. Inadequate risk analysis can be a contributor to failure in complex projects. The interrelationships of risk events will also be assessed for spin-off or chain effects. The occurrence of a small event can lead to serious consequences. CoPS projects are conceived and developed based on a set of hypotheses, scenarios, or assumptions. These assumptions may be true or false. The assumption’s validity should be tested. 3) Risk mitigation: This capability area has two processes: risk response planning and risk monitoring and control. The former is developing procedures and techniques to enhance opportunities of success and reduce threats to the project’s objectives. Different risk handling strategies such as avoidance, transfer, mitigation and acceptance, can be used. No matter how perfect the risk response plan may be, it is futile if it is not executed for whatever reasons, including the lack of resources, funding or commitment. Risk monitoring and control is the process of keeping track of the identified risks, monitoring residual risks and identifying any emerging risks, ensuring the execution of risk plans, and evaluating their effectiveness in reducing risk. 4) Process integration and improvement: The RM process needs to be integrated with other PM processes. PM process capabilities are needed to cope with critical risk factors related to all
30
aspects of PM processes, such as effective integration and change management, and an integrated performance and reward system. Scope changes are common in CoPS projects. Failing to managing change lead to the impairment and failure of many large complex projects in major software and infrastructure development. The project team should perform objective and transparent assessment of the project progress. An integrated performance and rewards system must be in place, in which earned value management (EVM) is used to measure and control project progress.
7.3 Technology-Content Security The technology dimension is responsible for technology evaluation and adaptation, design, and system integration. Key attributes include supplier assessments, technical competence of CoPS producer, requirements analysis and capture, technology planning and forecasting, technology risk mitigation, detailed system design and test, system engineering and integration capability, technology knowledge capture and transfer, design flexibility, and alignment between technology and business objectives. In order to make risk management process effective, CoPS providers need to make use of IT, embedded software and knowledge systems as transformational contents.
An important tool in assessing technology maturity and manage technology risks is Technology Readiness Level (TRL). It is a systematic metric that provides an objective measure to convey the maturity of a particular technology. It classifies a technology into several maturity levels ranging from very low readiness to high readiness. The measure was originally developed by NASA [Mankins, 1995]. Today it is adopted by some United States government agencies
31
(e.g., Department of Defense) and many companies to assess the maturity of evolving technologies prior to incorporating that technology into a system or subsystem.
8. SUMMARY OF COPS-RM-CMM CHARACTERISTICS Major characteristics of CoPS-RM-CMM at each level are summarized in Table 4. -Insert Table 4 here-
9. PROGRESSI&G BETWEE& MATURITY LEVELS The proposed CoPS-RM-CMM aims at assisting organizations to enhance their levels of risk management capability progressively and creating benchmarks for companies which wish to rate themselves against key competitors to identify areas of relative strengths and weaknesses. Table 5 summarizes some proposed key activities and strategies that enable the moving towards the next higher level. The model uses a questionnaire-based appraisal (QBA) method to assess the RM capability maturity of a real-life CoPS project. The required RM capabilities (called items in the model) in Table 2 are converted into a series of questions or statements suitable for questionnaire survey purposes. Respondents are asked to indicate the level of applicability to this list of questions relating to RM capability maturity in reference to the CoPS project. The responses are measured on a five-point Likert scale from 1 to 5 in applicability of the items. The maturity of a key capability area is the average score of its items. This method provides quantitative results. Using this method, we can identify which capability areas are weak as well as the specific items that are weak and propose appropriate suggestions for improvement. -Insert Table 5 here-
32
10. CO&CLUSIO&S In this paper, a risk management capability maturity model for complex product system (CoPS) projects is proposed based an innovative integrative approach. The model draws on relevant theories, systems thinking, practices and methodology which include change management framework, soft systems methodology, project risk management body of knowledge and prevailing capability maturity modeling practices. Each of the five maturity levels is described with supporting key influencing factors drawn from published case studies. The model has five levels of maturity (Ad Hoc, Initial, Defined, Managed, Optimizing) and three capability area categories (Organization, Process, and Technology). The five levels of maturity are further delineated into two broad classes of systematic “security” and systemic “robustness”. The model has synthesized both the traditional rational planning and new emergence paradigms. The research on complexity and emergence brings fresh perspectives and enables a new paradigm for the risk and uncertainty management of CoPS projects. We consider the risk management of a CoPS project as a strategic change management process. In order to improve the risk management capability, the organization must build capabilities in organizational contexts-internal and external, risk management process, and technology/system simultaneously. The model allows CoPS producers or suppliers to benchmark their risk management capability against five standard levels of maturity. It also allows organization to identify strengths and weaknesses and what need to be done in order to improve and increase their ability to manage risk, complexity and uncertainty. The model provides a comprehensive conceptual tool to CoPS producers or suppliers interested in either implementing a formal approach to risk management or improving their existing approach.
33
ACK&OWLEDGEME&TS We would like to thank four anonymous referees for their valuable comments and suggestions which are much appreciated.
REFERE&CES: B.H. Banathy, From evolutionary consciousness to guided evolution, World Future 36 (1993), 77-79. D. Buchanan and D. Boddy, The expertise of the change agent: public performance and backstage activity, Prentice Hall, New York, 1992. C.B. Chapman and S.C.Ward, Project risk management: processes, techniques and insights (2nd edition), Wiley, U.K., 2003. P. Checkland and J. Scholes, Soft Systems Methodology in action, John Wiley, Chichester, 1990. P. Checkland and S. Holwell, Information, systems and information systems, John Wiley, Chichester, 1998. I. Cohen, Philip Condit and the Boeing 777: from design and development to production and sales. North America Case Research Association (NACRA) workshop, 2000. J.K. Crawford, Project management maturity model providing a proven path to project management excellence, Marcel Dekker/Center for Business Practices, 2002. A. De Meyer, C. H. Loch and M. T. Pich, Managing project uncertainty: from variation to chaos, Sloan Manage Rev (Winter 2002), 60-67. E. Dent, Complexity science: a worldview shift, Emergence 1 (1999), 5-19.
34
K. Dooley, A. Subra, and J. Anderson, Maturity and its impact on new product development project performance, Res Eng Des 13 (2001), 23-29. R.P. Higuera, al. et, An Introduction to Team Risk Management. CMU/SEI-94-SR-01, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pa., May, 1994. D.A. Hillson, Towards a Risk Maturity Model, Int J Project Business Risk Manage 1 (Spring 1997), 35-45. M. Hobday, Product complexity, innovation and industrial organization, Res Policy 26 (1998), 689-710. M. Hobday, The project-based organization: an ideal form for managing complex products and systems, Res Policy 29 (2000), 871-893. M. Hobday and T. Brady, Rational vs soft management in complex software: lessons from flight simulator, Int J Innov Manage, 2(1998), 1-43. M. Hobday and H. Rush, Technology management in complex product systems (CoPS) -- ten questions answered. Int J Technol Manage 17 (1999), 618–638. C.W. Ibbs and Y.H. Kwak, Assessing project management maturity, Project Management Journal 31 (2000), 32-43. H. Kerzner, Project Management: A Systems Approach to Planning, Scheduling, and Controlling (7th edition), John Wiley and Sons, New York, 2000. H. Kerzner, Strategic Planning for Project Management -- Using a Project Management Maturity Model, John Wiley & Sons, New York, 2001. J.C.
Mankins,
Technology
Readiness
Levels:
A
White
Paper,
http://www.hq.nasa.gov/office/codeq/trl/trl.pdf, Office of Space Access and Technology, NASA, 1995.
35
R. Marion, and J. Bacon, Organizational extinction and complex systems, Emergence, 1 (2000), 71-96. R. Marion and M. Uho-Bien, Leadership in complex organizations, The Leadership Quarterly Yearly Review of Leadership, 12 (2001), 389-418. R. Miller and D. Lessard, Understanding and managing risks in large engineering projects, Int J Proj Manag 19 (2001), 437-443. E. Mitleton-Kelly, “Ten principles of complexity and enabling infrastructures,” In E. MitletonKelly, (editor), Complex Systems and Evolutionary Perspectives on Organizations: The Application of Complexity Theory to Organizations, Pergamon, 2003, pp. 23-50. M.C. Paulk, B. Curtis, M.B. Chrissis and C.V. Weber, Capability Maturity Model for Software, version 1.1, Technical Report no. CMU/SEI-93-TR-24, Software Engineering Institute, 1993. J. Peppard and I. Preece, “The content, context, and process of business process re-engineering,” In G. Burke and J. Peppard (editors), Examining Business Process Re-Engineering: Current Perspectives and Research Directions, Kogan Page, London, 1995, pp. 157-185. A. Pettigrew, The management of strategic change, Basil Blackwell, Oxford, 1987. A. Pettigrew, E. Ferlie and L. Mckee, Shaping strategic change, Sage, London, 1992. A. Pettigrew and R. Whipp, Managing change for competitive success, Oxford, Basil Blackwell, 1991. M.E. Porter, How competitive forces shape strategy, Harvard Bus Rev 57 (1979), 137-145. Project Management Institute, Organization Project Management Maturity Model (OPM3) Knowledge Foundation, Project Management Institute, Pennsylvania, 2003. Project Management Institute, A Guide to the Project Management Body of Knowledge, Project Management Institute, Pennsylvania, 2004.
36
A. Ramaprasad and A.N. Prakash, Emergent project management: how foreign managers can leverage local knowledge. Int J Proj Manag 21 (2003), 199-205. T. Raz, A.J. Shenhar, and D. Dvir, Risk management, project success, and technological uncertainty, R&D Manage 32 (2002), 101-109. Risk Management Specific Interest Group, PMI, “Risk Management Maturity Model Version 1”, 2002. http://www.risksig.com/articles/rm%20report%20final%20version%2012.doc. F. Ross and S. McLaren, An overview of aims, methods and cross-case analysis of nine implementation projects: the South Thames Evidence-Based Practice (STEP) project. Kingston University and St George's Hospital Medical School, London, 2000. A.J. Shenhar, From theory to practice: Toward a typology of project management styles, IEEE T Eng Manage 45 (1998), 33-48. H. Singh, and A.Singh. Principles of complexity and chaos theory in project execution: a new approach to management, Cost Eng 44 (2002), 23-33. B. Whittaker, What went wrong? Unsuccessful information technology projects. Inf Manag Comput Security 7 (1999), 23-29. K.T. Yeo, Strategy for risk management through problem framing in technology acquisition. Int J Proj Manag 13(1995), 219-224. K.T. Yeo, Critical Failure Factors in Information System Projects. Int J Proj Manag 20 (2002), 241-246. O. Zwikael and S. Globerson, Evaluating the quality of project planning: a model and field results, Int J Prod Res 42 (2004), 1545-1556.
37
List of Tables: Table 1. Summary of the key elements of project risk management processes Table 2. Summary of common risk factors and required capabilities in CoPS projects Table 3. Summary of key capability areas of the CoPS-RM-CMM Table 4. Characterizing CoPS-RM-CMM Table 5. Activities or strategies for moving towards the next higher level
38
Table 1. Summary of the key elements of project risk management processes Risk Management Activity
RM planning
Identify
Assess
Response/handling
Closure/Post-project learning
Key elements Assign risk management responsibilities Risk parameter definition Plan risk management activities Strategic risk planning Steps/process outline Process launch Establish the context, up-front planning Define risk areas/categories Identify risk events Describe risk events Qualitative risk analysis Evaluate impact (I) and probability (P) of risk events P×I analysis Assumption analysis Classify/categorize risk events Prioritize risk events Quantitative risk analysis Risk response planning Use of different strategies (avoid/transfer/mitigate/accept) Risk ownership allocation Implement risk response plans (mobilization) Risk monitoring and control Communication and consultation Documentation/lessons learned Record lessons in the Risk Management Information System
39
Table 2. Summary of common risk factors and required capabilities in CoPS projects Category
Culture (S1)
Stakeholder coalition (S1)/(Se)
Leadership (S1)
Organization structure (S1)
Risk management process (Sp)
Project management process (Sp)
Risk factors (From 51 cases and literature review) 1. Fear-based culture, poor risk awareness 2. Lack of assumptions testing and learning 3. Poor cross-project learning, failure to learn from previous projects 4. Resistance to accept changes in management approach or technology 5. Rigidity of formal methods and systems 6. Poor sense of risk ownership 7. Lack of continuous viability and profitability analysis 1. Lack of user involvement and inputs in defining requirements in design phase 2. Poor relationship with client or customers 3. Communication problems with customer/users 4. The contract offered no clear clauses on incentives and penalties 5. Adversarial relationships among different parties 6. Lack of support from affected parties (such as community and public) 7. Supplier and contractor delays 8. Regulation changes 9. Lack of long-term arrangements 1. Lack of top management support and priority 2. Project members are not involved in decision making, authoritative management style 3. Poor relationship with corporate senior management 4. Poor communication and collaboration with external network partners 1. Weakness in matrix structure 2. Lack of cross functional collaboration 3. Poor teamwork, lack of communication between teams 4. Weak team identity 1. No earlier or clear identification of risks 2.Poor risk analysis/assessment 3. Insufficient contingency planning 4. No mitigation to identified risks 5. Lack of risk management process and practice
1. Ad Hoc or inadequate project planning and control systems 2. Poor front-end planning 3. Poor requirement analysis 4. High personnel turnover in project teams 5. Late involvement of key parties in the project
40
Success factors as Required capabilities (From 51 cases and literature review) 1. Open culture to recognize risk and mistakes 2. Double-loop learning, assumption testing 3. Learn the lessons of previous projects, utilize historical information from post-project reviews 4. Accept changes in culture and attitude, also in technology and management 5. Informal methods, experience and trust were viewed as important 6. Clear risk ownership allocation 7. Continuous viability and profitability analysis 1. Closer user involvement and capture requirements 2. Close relationship and collaboration with the client or customers. 3. Good communication with customer/users. 4. The contract include risk/reward arrangements, or incentive clauses to motivate contractors 5. Flexibility in compromises and agreements 6. Communicate with the community and public and address their concerns 7. Good relationship with key suppliers 8. Collaboration with regulators 9. Use partnership strategy 1. Top management support, project championship 2. Projects team members are empowered and selforganization are encouraged in certain contexts 3. Collaboration between project manager and function managers 4. Build external networks 1. High extent of project-based organization or strong matrix 2. Develop and use cross-function teams 3. Emphasize teamwork and communication within company and across companies 4. Create a sense of “ownership” and strong team identity Develop formal risk management systems and procedures for: -Risk identification -Risk analysis & prioritization -Risk response planning -Risk mitigation Continuous improvement in risk management process, formal process & information system. 1. Formal project management processes and approaches 2. Adequate pre-project planning 3. Quality of requirements analysis and capture, clear definition of requirements 4. A process of personnel continuation and sharing 5. Key parties involved early in the project core team
Technology/ System design (S2)
6. Lack of regular reviews of project progress 7. Poor oversight and monitoring, poor tracking of performance 8. Unclear roles and responsibilities 9. Contractual disputes
6. Regular reviews & monitoring 7. Measure project performance continuously
10. Excessive change orders, changes in user requirements 11. Lack of financial reserves
10. Change management & control procedures
12. Lack of project baseline system 13. Unrealistic timeline 14. Lack of integrated planning, control & monitoring information system 15. Dislocation of different teams 1. Ill-defined product/systems requirements & functionalities 2. Changing technical standards 3. Use technology to fix management problems 4. Lack of in-house technical experience and capability
41
8. Clear roles and responsibilities 9. Appropriate contract structure & administration
11. Build-in contingency reserves in setting the project budget 12. Robust baseline/budgeting system 13. Realistic time schedule 14. Integrated project information system for planning, control & monitoring 15. Co-location of teams preferred when feasible 1. Well defined requirements & functionalities & good communication with customers 2. Use proven standards; Have design flexibility to accommodate changes 3. Use appropriate and proven technology; No technology fix to solve management problems 4. Develop in-house technical capability & system engineering competence.
Table 3. Summary of key capability areas of the CoPS-RM-CMM Category Organization
Process
Technology
Key Capability Areas Organization culture Stakeholder coalition Leadership Organization structure and support Risk planning and identification Risk analysis Risk mitigation Process integration and improvement Project management process Technology
42
Organization & Leadership
General Definition
Level 2 Initial ● Recognition of benefits of risk management ● Organizational support at project levels ● Some initial recognition of need for RM processes/ methodologies ● Some risk management training ● Experimenting on some aspects of risk management process and tools applications
● Partial acceptance of risk management ● Initial assignment of responsibility and accountability for risks ● Weak team orientation ● Organizations good at doing repetitive works ● Project coordination style
Level 1 Ad Hoc ● No understanding of risk management principles or language ● Lip service to risk management ● Virtually no executive-level support ● Small “pockets” of interest ● No attempt to recognize the benefits of risk management ● No investment in risk management training and education ● Reactive to risk events, used to fire-fight
● Lack of senior management support and involvement ● Project success depends on individual efforts ● Resistance of change in a passive culture ● No learning from previous projects ● Unaware of the need for management of risk and uncertainty. ● Little or no attempt to learn from past projects or prepare for future projects. ● Functionally orientated.
Table 4. Characterizing CoPS-RM-CMM
43
● Reasonably high team orientation ● Informal training of RM skills and practices ● Risk awareness at the organizational level ● Recognition of risk ownership and allocation of risk and responsibility ● Task-orientation, Management by systems objectives ● Functional matrix
Level 3 Defined ● Integrated RM processes defined ● Management support to a RM formal system ● Return on investment for risk management training dollars ● Proactive behavior to risk and threats ● Lessons learned from past project projects ● Effective management of known/predictable risks ● Still mainly inward looking within the project and functional levels. ● Strong teamwork, even with external partners ● Continuous formal PM/RM training for project teams ● Strong project-driven organization, and heavy-weight project manager ● Risk awareness at the CoPS network level ● Organizational flexibility and willingness for change ● Adaptive leadership and management style. ● Balanced matrix
Level 4 Managed ● Appointment of a risk manager-formal or informal ● Risk sharing with other parties ● Institutional arrangements (coalition building, contractual, legal arrangements) ● Networked or leveraged risk management capability & Network innovation capability ● More focus on dealing with front-end engineering & planning ● High risk-awareness ● Capable of managing almost all predictable risks, and manage some emergent risks ● Institutionalized risk management process ● Strong risk-awareness culture with proactive approach to risk and opportunity management in the CoPS network ● Active use of risk information & prior experience to gain advantage ● Strong project-driven organization that is dynamic and energetic, and flexible ● Strong negotiation skills and ability to influence other parties ● Strong organizational learning to facilitate innovation and generation of new ideas ● Enlighted leadership and management style. ● Strong matrix or projectized
Level 5 Optimizing ● Cross-organizational and crossproject risk management collaboration and multi-learning ● Involvement of affected parties & internal stakeholders in the risk management process ● Strategic business risk planning ● Develop strategic alliances, institutional arrangements and partnering with external stakeholders ● Ability to manage both known risk and emergent risk.
● No formed PM processes or practices are available ● No PM data are consistently collected or analyzed ● No documentation of project lessons RM tools: No risk management tools in use
● Basic & narrow-range technology ● Single and simpler products
Process
Technology -Appropriately Embedded or Applied ● Mid-level proven technology ● Mid-range products
● Informal PM processes are defined ● PM problems are seldom systematically identified and analyzed ● Fragmented risk data are collected RM tools: Simple template and spreadsheet tools are used in some activities
44
● More advanced but proven technology ● Use major assembles ● Complex products
● Formal project planning and control systems are established and applied ● Formal RM system defined to identify, evaluate and mitigate risks ● Ensure real time monitoring of budgets and schedules using Earned Value Method and variance analysis ● Formal project databases maintained RM tools: Use well established template, software tools for qualitative analysis
● Advanced but proven technology ● Involve complex product assembly and integration ● Complex product systems (CoPS)
● Consistent and systematic RM for project portfolios ● PM data and processes are integrated internally ● PM and RM processes data are quantitatively analyzed, measured, and stored continuously ● Conduct prost project reveiws & capture lessons learned RM tools: Use sophisticated software simulation tools for qualitative analysis
● Advanced and some innovative technology ● Involve large-scale multiple complex assemblies and installation ● Complex products and systems (CoPS)
● RM processes are continuously improved and performance optimized ● Develop a network system of coalition and partnering with vendors and contractors ● Leverage good relationship with governmental authorities ● Cultivate goodwill with communities ● Develop and sustain goodwill and long term relations with lead customers ● PRM process integrated into PM processes. RM tools: Use sophisticated software tools for both qualitative & quantitative analyses with superior interpretation.
Table 5. Activities or strategies for moving towards the next higher level Transition Level 1 to Level 2 -Towards a more disciplined process
• • •
Level 2 to Level 3 -Developing a formal RM framework and standard
Level 3 to Level 4 -Enabling a predictable networked process (Towards an expected CoPS level capability) Level 4 to Level 5 -Continuously improving and optimizing process and working on networking and coalition (Towards a higher CoPS level capability)
• • • • • • • • • • • • • • • • •
Activities and strategies Initial training and education in project risk management Undertake awareness briefings to sell the vision of risk management and its potential benefits to the senior management Identify and use appropriate project risk management templates and historical risk data Provide formal tiered risk management training to develop in-house expertise and process knowledge Formalize the chosen risk management systems and processes Develop a culture that supports both the behavioral and quantitative sides of risk management Assessing and managing risk both qualitatively and quantitatively Plan, prioritize, mobilize and track risk management activities Identify proactively common known risk sources and reduce risks systematically Effective learning from experience Have key suppliers and customers involved in both PM and RM processes Develop a fully RM culture and appointment of a risk manager Manage emergent risk through high risk awareness and quick response Assess the project structure and instill robustness to cope with emergent risks Facility double-loop learning. Ensure continued commitment and active involvement of senior management Encourage the corporate-wide acceptance of a culture that supports empowerment and self-organizing guided by a set of protocols Continue to involve lead customers and suppliers in the shared risk process Develop societal network and community relations Continuously improve multiple capability in organization, PM & RM processes, software tools and technology applications
45
List of Figures: Figure 1. Relevant theory and conceptual framework for CoPS-RM-CMM. Figure 2. Four-S framework for categorization of sources of risk. Figure 3. CoPS-RM-CMM Architecture. Figure 4. Five levels of risk management capability maturity. Figure 5. Robustness, security and key capability areas.
46
Figure 1. Relevant theory and conceptual framework for CoPS-RM-CMM.
CoPS Production System
Project Risk Management
Change Management Framework & Soft System Thinking
CoPS-RMCMM
Complexity Theory & Emergence
47
Figure 2. Four-S framework for categorization of sources of risk.
Project management PROCESS Sub-system (Sp) -Risk management process -Project management process (T1)
Corporate/organizational CO&TEXT Sub-system (S1) -Customer or user (C) -Corporate culture and value (W) -Internal sponsor/Corporate management (O) -Project organization/support structure
Technical CO&TE&T Sub-system (S2) -Technology and design (T2) -Technical specialists and expertise -Technology maturity level
E&VIRO&ME&T Sub-system (SE) -External stakeholders: government, contractors, vendors… -PEST (political-economic-social-technological) external macro-environment (E)
48
Figure 3. CoPS-RM-CMM Architecture.
CoPS-RM-CMM
Capability Areas
Maturity Levels
Organization Optimizing
Process Technology 1 to m2
1 to m1 Capability Areas
Robustness 1 to m3
Capability Areas 1 to n2
Managed
Capability Areas
Defined
1 to n3 Items
Initial
Items
1 to n1
Ad Hoc
Items
49
Security
Figure 4: Five levels of risk management capability maturity.
Level 5: Optimizing Level 4: Managed
Increasing Robustness
Level 3: Defined Level 2: Initial
Increasing Security
Level 1: Ad Hoc
50
Figure 5. Robustness, security and key capability areas.
External
ROBUST&ESS
SECURITY
Internal
-Risk Identification & Planning -Risk Analysis -Risk Mitigation -Process Integration & Improvement -PM Process -Technology
Predictable
-Organization Culture -Stakeholder Coalition -Leadership -Organization Structure and Support
Level 1-3
Unpredictable
51
Level 4-5
