A Framework for Classification of Change Approaches Based on a Comparison of Process Improvement Models

A Framework for Classification of Change Approaches Based on a Comparison of Process Improvement Models1 Otto Vinter2 Project Manager Software Process Improvement DELTA Software Engineering, Denmark otv@delta.dk Abstract In this paper we describe a framework for classifying possible change approaches according to the stage(s) in the life-cycle where the approach is most applicable The life-cycle model of the framework is based on an analysis of a number of existing life-cycle models for change from three different domains The focus of this framework is on the individual improvement project and the palette of available approaches to its project manager Introduction The Danish Talent@IT project (Vinter & Pries-Heje 2004) studies change approaches used by companies in order to define a model for successful improvements We want to find the applicability of these change approaches and how the applicability is related to a company’s ability to perform successful changes Studies by Somers & Nelson (2001) and Kinnula (2004) have shown that different change approaches should be applied depending on where in the life-cycle the change project is E.g Somers & Nelson (2001) have shown that “management commitment” is important in the beginning and conclusion of the life-cycle of the change project, and of less importance in the middle part And that “dedicated resources” are only important during the actual development of the changes Consequently, when we should recommend a project manager which change approach to use, a classification according to the life-cycle stage of a change project seems both relevant and promising It is also evident that there are change approaches, which extend across all of the life-cycle stages Such issues are commonly referred to as life-cycle independent or continuous issues These issues are also included in our framework for classification For a classification of change approaches by life-cycle stage we need a life-cycle model which extends over the entire life of a change from the original inception of the idea for the change until the stage A short version of this paper has previously been published in the proceedings of PROFES’05 (Vinter 2005) The present version is the first full version of the paper including detailed appendices The work was performed by the author while he was employed by DELTA and is one of the early results of the Danish research project Talent@IT: www.talent-it.dk The author’s present affiliation and address is: Otto Vinter, Software Engineering Mentor Web: www.ottovinter.dk Email: vinter@ottovinter.dk © 2006 Talent@IT and Otto Vinter where new ideas for change emerge based on the experiences and learning obtained from the resulting use of the changes Selecting an existing life-cycle model for our classification framework would of course be the most natural However, as we will show in this paper, some of the well-known models focus primarily on the earlier stages of a change project, while others put little emphasis on these and concentrate on the later stages A combination of existing life-cycle models into one comprehensive life-cycle model would seem to solve our problem Based on such a combined life-cycle model we will be able to classify all possible change approaches by the stage(s) where they will be most useful for a manager of a change project Life-cycle Models for Change Projects The life-cycle models we have studied and compared cover a number of change domains all characterized by having IT as an important enabler For further analysis we have selected from each domain two life-cycle models which seem representative (e.g extensively documented and referred to by others) The change domains we have selected life-cycle models from for our comparison are:    Software Process Improvement (SPI) – section New Technology Implementation – section Business Process Reengineering (BPR) – section All change models divide the execution of the project into a number of phases or stages The number of stages and the activities performed in each stage seem to vary quite a bit However, a closer look at the models shows an agreement on what should take place during a change project The differences are mainly in which stage it should take place and what emphasis the model places on the issue Our comparison of the life-cycle stages of the models can be found in section Based on our comparison of life-cycle models we have then constructed a combined model (section 7) by extracting the most representative stages and distribute the activities from the models on those stages We have done the same for the models’ life-cycle independent (continuous) issues We shall use this combined model as the framework for classification of change approaches on the Talent@IT project Finally, by means of a few examples we shall demonstrate how the framework can be applied (section 8) However, to fully populate this framework with known change approaches from industry and literature remains part of our future work on the Talent@IT project Life-cycle Models in “Software Process Improvement (SPI)” Systematic efforts to improve software processes originated in 1986 when the Software Engineering Institute at Carnegie Mellon University (SEI) was formed by the US military with the purpose of creating a model to assess potential software system suppliers The SPI domain contains many life-cycle models A comprehensive study of life-cycle models in this domain can be found in Kinnula (2001) Two of the most well-known SPI models are closely connected to maturity assessment frameworks: CMM (Paulk et al 1995) and SPICE (ISO 15504-1 1998) The work on the Talent@IT project is heavily influenced by these assessment frameworks We have therefore decided to analyze the SPI models related to CMM and SPICE:   IDEAL 1.0 SPICE (McFeely 1996) (ISO 15504-7 1998) IDEAL is the most well known model for SPI The model originates from the Software Engineering Institute (SEI) The model is the proposed model for how to perform improvements of software processes in the CMM assessment framework The model has been developed by SEI and later successfully applied on a number of actual industry cases IDEAL 1.0 (McFeely 1996) is the original and best documented version of the model A number of not too detailed descriptions exist of an updated version 1.1 (SEI 1997) Apart from calling the last phase “Learning” in stead of “Leveraging” there doesn’t seem to be much change in either phases or their content The life-cycle described by the model distinguishes five stages (called phases) as shown in Figure Four of the stages form a loop, which demonstrates the continuous nature of process improvement The model mentions one life-cycle independent (continuous) issue:  The Management Framework Figure 1: The IDEAL 1.0 Phase Model ISO 15504-7 (1998) is part of the international standardization effort based on the SPICE assessment initiative and is the proposed model for how to perform improvements of software processes in this framework It builds on and extends the IDEAL model However, as far as we know the model is a theoretical model and has not been tested in actual industry cases The life-cycle described by the model distinguishes eight stages (called steps) as shown in Figure The model describes two loops of continuous process improvement The inner loop describes the repetition of individual improvement activities The outer loop describes the wider organizational process The model mentions two life-cycle independent (continuous) issues:   Management Cultural Issues Improvements in organizational unit’s software process Examine organization’s needs Organisation’s needs Software process improvement request Institutionalised improvements Identified scope and priorities Monitor performance Improvement initiation Confirm improvements Re-assessment request Implemented improvements Initiate process improvement Analyzed re-assessment results Preliminary process improvement programme plan Prepare and conduct process assessment Assessment request Validated improvement results Sustain improvement gains (Parts and 4) current assessed capability Assessment results Analyze results and derive action plan Approved action plan Implement improvements • Process improvement programme plan for capability determination • Target capability profiles from capability determination • Industrial benchmarks (Part 8) • Practice descriptions from the assessment model in Part or another assessment model compatible with Part (Part 2) Figure 2: The ISO/IEC 15504-7 Model Steps Life-cycle Models in “New IT Technology Implementation” Implementation of new IT technology is a domain which is normally seen as closely related to the SPI domain However, the focus of change in this domain is not the improvement of processes per se but to improve the competitiveness of a company through implementation of new IT technology and accompanying processes There seems to be no common agreement on how to implement new IT technology The domain is typically characterized by the use of no model for the implementation However, two prominent models exist and were therefore selected for our analysis of models in this domain:   INTRo Cooper & Zmud (SEI 2003) (1990) INTRo (SEI 2003) is the result of the continuing efforts of the Software Engineering Institute (SEI) in the SPI domain, which have lead to the definition of a model for implementation of new (IT) technology in a company The model is directly focused on implementation of (customized) standard software products (COTS) The acronym INTRo stands for: IDEALSM-Based New Technology Rollout, which shows its close connection to the SEI model for software process improvement SEI has made the model generally available via their home page (www.sei.cmu.edu/intro/overview) and has created a “community of practice” around its use, where companies can exchange their experiences with the model Until now the model has been tested by more than 50 organizations, primarily US-based The life-cycle described by the model consists of seven stages as shown in Figure 3, where two of these should be carried out in parallel As the model is intended to be used for only one implementation, it does not describe how continuous process improvements should be handled – other than through the IDEAL model itself The model mentions six process threads that run throughout the life cycle of a project However in our context, only two of these are fully life cycle independent (continuous) issues:   Learning Culture Figure 3: INTRo Model Stages Cooper & Zmud (1990) have developed another well-known model for implementation of IT solutions in an organization The model is descriptive, based on a study of how the implementation of (customized) standard IT solutions for the support of business processes should take place in practice They evaluated the model on the implementation of IT solutions for Material Requirements Planning (MRP) Other evaluations of the model have been performed by Somers & Nelson (2001 and 2004) on the implementation of IT solutions for Enterprise Resource Planning (ERP) The life-cycle described by the model distinguishes six stages as shown in Figure The model is aimed at a single implementation project and therefore does not specifically address any loops for continuous process improvement The model mentions one life-cycle independent (continuous) issue:  Contextual Factors The contextual factors include issues about the company’s situation on the market as well as its internal culture Initiation Adoption Adaptation Acceptance Routinization Infusion Figure 4: The Cooper & Zmud Model Stages Life-cycle Models in “Business Process Reengineering (BPR)” Business Process Reengineering (BPR) is the third change domain we have studied BPR is designed for comprehensive organizational changes aimed at improving the competitiveness of a company, in which changed IT processes and technology implementations are a supporting element The concept of BPR was initially coined by Hammer (1990) To him, improving an organization’s processes cannot take place as a series of adjustments, only through a complete redesign of the processes (revolution instead of evolution) He talks about establishing a “clean slate” This attitude has been adopted by subsequent authors in the field Davenport (1993) e.g states that you should design completely new processes (process innovation) not only improve (reengineer) existing processes BPR has been successfully applied in a number of well-known cases However, it is also reported that the rate of failure of BPR projects is even higher than for SPI projects (70% according to Malhotra 1998) BPR is a domain characterized by an abundance of models It seems as if every consulting company has developed its own proprietary model Furthermore the life-cycles of the different models not even seem to have a common basic structure There seems, however, to be two strands among BPR models on the market: one which claims that BPR projects are only performed once in an organization, and one which believes in repetitive cycles of improvement Stoica et al (1999) give an overview of a number of publicly available BPR models The Talent@IT project believes in continuous improvement Therefore both of the models we have analyzed belong to the strand of BPR models which have life-cycles that include a stage for continuous improvement The BPR models we have analyzed are two relatively recent ones, which according to the authors are based on a combination of earlier models:   Muthu et al (1999) Kettinger & Teng (2000) Muthu et al (1999) have developed a BPR model combined from five well-known BPR models They not, however, explain how their model is related to these other models, and since the models have quite different focus it is unclear how they have arrived at their model The model itself, however, is very well documented in a detailed set of IDEF (FIPS 1993) diagrams It is not clear whether the model has been evaluated in practice by companies The life-cycle described by the model distinguishes five stages (called activities) as shown in Figure There seems to be agreement among the BPR models on the market that BPR projects are only performed once in an organization However, the model by Muthu et al includes a final stage indicating a continuous improvement The model mentions no specific life-cycle independent (continuous) issues, but emphasizes throughout the model stages the importance of handling resistance (a cultural issue) Figure 5: Muthu et al Model Activities Kettinger & Teng (2000) have developed one of the most recent models in the BPR domain The model is based on an analysis of 25 BPR models, both academic and commercial From these they have developed a combined life-cycle model They have subsequently checked the model through interviews in three companies that had completed BPR projects It is not clear to which extent the model has been evaluated in practice by other companies Strategy Linkage Change Planning Process Problems Social & Technical Re-Design Process Re-Generation Continuous Improvement Figure 6: Kettinger & Teng Model Phases The life-cycle consists of six stages (called phases) as shown in Figure One of these consists of two parts performed in parallel (Social Re-design and Technical Re-design) There seems to be agreement among the BPR models on the market that BPR projects are only performed once in an organization However, the model by Kettinger & Teng includes a final stage indicating a continuous improvement The model mentions no specific life-cycle independent (continuous) issues Comparison of the Life-cycle Models 6.1 Comparison of the models’ life-cycle stages We have based our comparison of the above models on the available detailed activity descriptions We have aligned the different stages in order to achieve the best possible match of the activities across the models The comparison of the models’ life-cycle stages can be found in Figure and more details on the activities in each stage supporting their alignment can be found in Appendix In Figure we have added our proposed combined life-cycle model as the rightmost column This model will be described in more detail in section The combined life-cycle model will be used for our classification of change approaches The comparison of activities prescribed by the models has shown that the content (e.g activities) in some life-cycle stages seems to be very much the same, even though the models use a different name for these stages In these cases we have aligned the stages of the models to the same row in Figure We have also found that some models have reserved a separate stage for some activities, where other models have included these activities in another stage This means that the models have a different number of stages even in cases where the overall content may be more or less the same We have marked with an “*” in Figure those cases where one model has included some of its activities in another stage, where another model has described these in a separate stage Thus a blank cell in the figure indicates that a model does not mention the type of activity which one of the other models does The stages in the models should not been seen as a strict sequential/time progression Stages can be executed overlapped or in parallel However, each stage has a unique and identifiable set of goals, activities (processes), and results (products) The comparison of the models’ life-cycle dependent activities clearly shows that improvements take place at two levels in an organization:   Strategic/organizational level Execution/project level The SPI models try to describe both of these levels in one common stage model, because they emphasize the importance of continuous improvements The BPR and IT technology implementation models on the other hand are aimed at one specific improvement action e.g focus specifically on the execution/project level, even though both of theses domains have great strategic and organizational implications Some models regard planning and staffing of the improvement project as so important that they have devoted a separate stage for these (ISO 15504-7, INTRo, and Kettinger & Teng), other models include this in another stage (IDEAL), and some models don’t mention it specifically (Cooper & Zmud and Muthu et al.) Software Process Improvement Models ISO 15504IDEAL 1.0 New IT Technology Implementation Models Cooper & INTRo Zmud Business Process Reengineering Models Muthu et Kettinger al & Teng Initiating Examine * Prepare for Reengineering * Initiate Diagnosing Assess Establishing Analyze Acting Implement * Project Initiation & Planning Problem / Domain Analysis Technology / Based Solution Definition Technology Customization & Testing WholeProduct Design * Rollout Leveraging Confirm * * Sustain * Monitor * Talent@IT Strategy Linkage Initiation Change Planning * Map & Analyze As-Is Process Process Problems Diagnosis Adoption Design To-Be Processes Social & Technical ReDesign Analysis Adaptation Implement Reengineered Processes * Development Initiation * Breakthrough * Combined Model * * Acceptance * Improve Continuously Evaluation Process ReGeneration Continuous Improvement Rollout * Routinization Routinization Infusion Infusion * * * Figure 7: Comparison of the Models’ Life-cycle Stages (a “*” means that similar activities are included in another stage) It is evident from Figure that the model by Cooper & Zmud is very detailed in the later stages of an improvement project where the improved process and product is deployed and used as part of the normal work of the organization In this area the BPR models seem especially weak (in particular the models we have not selected for analysis) It seems as if BPR models are more interested in planning the implementation than executing the plans The SPI models mention rollout and use, but not make an effort in describing how They assume that this happens as a natural consequence of the improvement project Cooper & Zmud is the only model which devotes a separate stage (Infusion) for the exploitation of the new technology in new ways following its implementation and use On the other hand, the Cooper & Zmud model seems very weak in the earlier stages of an improvement project E.g the Diagnosis/Assessment/Analysis of the organization’s current state before a new IT solution is implemented is confined to the selection (Adoption) of the proper IT product and vendor Similarly the Cooper & Zmud model sees no need for stages for evaluation or whether the goals have been achieved or not INTRo is the only model that defines a separate stage for those issues that are concerned with complementing the development and test activities of the IT technology, e.g the design of a comprehensive solution (Whole-Product Design) The stage is executed in parallel with the adaptation of the technology, and it seems that the other models see these activities simply as part of the normal development activities Cooper & Zmud, however, mention these activities as part of their model’s Adaptation stage Even though the model by Kettinger & Teng mentions such activities in their dual part stage: Social & Technical Re-Design, the activities here are aimed at designing new processes and technologies – not about creating holism in the design The ISO 15504-7 model defines as the only model a separate stage (Monitor) for measuring and monitoring an improvement project, although the description clearly states that this is an on-going activity across the stages and therefore should have been part of the model’s life-cycle independent (continuous) issues This is what we have chosen in our proposed combined life-cycle model 6.2 Comparison of the models’ life-cycle independent (continuous) issues The selected models describe life-cycle independent (continuous) issues in varying detail We have based our comparison of the above models on the available detailed descriptions We have aligned the different life-cycle independent (continuous) issues mentioned by the models in order to achieve the best possible match of the activities described in these issues across the models For our comparison we use the following two main groupings, which will be further detailed in the following:   Management Framework Cultural Issues Other groups of life cycle independent (continuous) activities than the above can be found in other models and assessment frameworks We have, however, limited our comparison to the above Comparison of the models’ Management Framework An overview of the models’ management framework can be found in Figure and more details on the individual management issues can be found in Appendix From the overview in Figure it can be seen that the models use different names (headings) for their individual management issues In our comparison we have aligned those issues which have similar content/meaning to the same row in the figure Details of the issues supporting this alignment can be found in Appendix The models also define different number of issues in the framework In cases where one model has described a management issue under a separate heading where another model has included this as part of another issue (heading), we have marked this with a “*” in the overview in Figure In Appendix the actual reference to the issue (heading) can be found Software Process Improvement Models ISO 15504IDEAL 1.0 Setting the Stage for SPI Organizing the SPI Program Planning the SPI Program Staffing the SPI Program Monitoring the SPI Programme Directing the SPI Program New IT Technology Implementation Models Cooper & INTRo Zmud Business Process Reengineering Models Muthu et Kettinger al & Teng Combined Model Talent@IT * Organizing for Process Improvement Planning for Process Improvement * Measuring Process Improvement Reviewing Process Improvement Activities * * * Organizing * * * * Planning * * * * Roles and Responsibilities * * * Monitoring Reviewing Figure 8: Comparison of the Models’ Management Framework (see Appendix for details) (a “*” means that similar activities are included in another issue) For models that not describe an issue separately, we have closely studied the reference text to extract statements which apply and used them in our comparison A “*” in the overview in Figure indicates that the model contains descriptions of the issue, however without any specific heading In    projects Plan the strategies for communication Develop and approve plans for all stages of the individual improvement projects Business, Process Improvement Programme, and Process Improvement Project Staffing the SPI Program Staff the organizational entities of the SPI program (SEPGs and TWGs) Recruit and select proper resources, and assign them Roles and Responsibilities (Cf Organizing for Process Improvement part 2) Monitoring the SPI Program Measuring Process Improvement Ensure that the SPI Process effectiveness Identify the project organization including:  the project team  senior management and  stakeholders Assign resources Champions are required for higher levels of infusion Ensure senior management commitment Establish a crossfunctional team:  Leader  Process owner  Reengineering team  Steering Committee  Reengineering Czar Name a process owner for the change Assign the roles of sponsor, owner, and driver/champion to the projects Delegate and communicate the necessary responsibilities to those roles Ensure that the roles have sufficient power, influence, and respect Ensure sufficient energy/drive/initiativ e at both individual and management levels Monitoring Manage rational and political factors Monitor the progress of action and the Recognize that the rejuvenated Ensure that the improvement activity is consistent with objectives and plans Review the progress Assess schedule, milestones, performance, and quality Assess business values, competitive factors, market conditions measures Process attribute and capability ratings Status of processes and practices The effectiveness of process and practices in meeting organization’s needs and business goals Directing the SPI Program Reviewing Process Improvement Activities Ensure that the strategic goals are consistent with organization’s vision and mission Insure that specific actions are in line with strategic goals Regular reviews done at all management levels to ensure that the improvement organization is effective Regular reviews of organization’s needs and goals throughout the IT implementation stages Control implementation through senior management involvement in mandating and coordinating the implementation effort Assert control through educational efforts results Perform attitude surveys Review performance processes must be maintained and improved projects are consistent with objectives and plans Assess schedule, milestones, performance, and quality Manage rational and political factors throughout the organization Reviewing Regular reviews done at all management levels to ensure that the improvement organization is effective Regular reviews of organization’s needs and goals Appendix 3: Cultural Issues of the Models IDEAL 1.0 Visible management commitment and sponsorship are key This commitment must be cascaded down the line organization Management must foster a positive attitude and accepting the changes Line managers (and other stakeholders) must demonstrate active sponsorship, ownership and involvement They must commit time and effort to participate in improvements Management commitment must be backed by resources ISO 15504-7 INTRo Cooper & Zmud Muthu e.a Kettinger & Teng Combined Model Cultural issues Culture Management Responsibility and Leadership Management Atitudes and Behavior Management leadership and commitment to improvement and organizational change Responsibility for creating the environment for continuous process improvement belongs to all levels of management, but particularly to the highest Senior management commitment to the costs and impact of assessment activities and improvement actions The management approach should take account of the Top management support (committed to, mandating, and coordinating the implementation) Backing through rational and political negotiations Middle management involvement Management of the process is guided by organizational change theories Develop execute consensus Ensure strategic direction from the top Continual communication between top management, the regeneration team and employees Management leadership and commitment to improvement and organizational change Management commitment must be visible and cascaded down the line organization Management must foster a positive attitude and accepting the changes Management must support, mandate, and coordinate the changes The commitment must be backed by resources to to implement improvement projects (practitioners) Management must ensure that the proven improvement activities are completed and institutionalized, and that organizational learning takes place Management must realize that they are a significant part of the organizational culture and may also be required to change as the organization changes Everyone in the organization should understand that improvements can result in substantial changes in their daily work Continuous commitment and consensus must be specific characteristics of software staff and development work Mitigation strategies to counter:  Risk that concern for meeting short term commitments reduces attention to longer term benefits  Resentment to divert scarce resources to process improvement projects implement improvement projects Management must ensure that the proven improvement activities are completed and institutionalized, and that organizational learning takes place Values, Attitudes and Behaviour Values, Attitudes and Behavior of the Organization Effective process improvement implies:  Focusing attention on both external and internal customer satisfaction  Targeting Understand the organizational culture and occupational subcultures Recognize cultural differences and construct a deployment approach that aligns with the Commitment to change Overcoming user resistance to change Recognizing and managing the diverse vested interests of stakeholders Infusion (change) takes time Understand the expectations of your customers Expect and face all kinds of opposition Recognize resistance to change and minimize through an assessment of cultural readiness to establish project buyin Focus on both external and internal customer satisfaction Employee satisfaction is targeted Process improvement is emphasized as a secured among those who will be implementing the improvements The climate for change must be identified, assessed, and analyzed:  Resistance and related barriers and leverage points  Day-to-day problems, priorities, firefighting, or overwhelming amount of changes  Current policies, regulations, and initiatives that will support or impede the SPI program  Approaches and support group networks  Sponsorship  Capacity for change (past improvement performance)  Motivation to     employee satisfaction by establishing an appropriate recognition system Involving the entire supply chain in process improvement Demonstrating management commitment, leadership and involvement by communicating purpose and goals Emphasizing process improvement as a part of everyone’s job and helping everybody to gain an understanding of their contribution to common goals Considering quality, cost and time scale goals as priorities to improve behavior and values of the organization Develop a resistancemitigation strategy Champions are required Beware of political forces (maneuvering and bureaucracy) part of everyone’s job Everybody has an understanding of their contribution to common goals Management commitment, leadership and involvement is demonstrated Recognize that a change in culture takes time Improvement projects should include those who will be affected by the changes Recognize and deal with resistance Surface covert resistance Be aware of the differing perspectives (vested interests) from different groups in the organization Perform an assessment of cultural readiness Visible and proven results of the process improvement projects improve Recognize and deal with resistance Surface covert resistance Surface unwritten expectations of senior management Be aware of the differing perspectives from different groups in the organization Improvement projects should include those who will be affected by the changes Regular and effective communication will alleviate some of the fear and uncertainty which leads to resistance to change Champions lobby to get an effort started Guiding an organization through a change in culture takes time    processes Establishing open communication with access to data and information Promoting teamwork and respect for the individual Objectively measuring process performance and making decisions based on realistic metrics agreed by all Quality, cost and time scale goals are priorities for improvement of processes Process performance is measured objectively, and decisions are based on realistic metrics agreed by all Process Improvement Goals and Motivation There must be a Motivation to Improve Scanning for desire present to improve software development processes (pain of status quo, motivation to improve) Management should provide the SPI team with the critical business needs for process improvement (vision) The organization’s needs should be analyzed to yield goals for improving the software process Targets should be set in terms of good practices (capability), and/or in terms of effectiveness of meeting the organization’s needs Industry benchmarks can be used to set appropriate improvement goals Visible progress (measurements) will increase staff motivation to achieve these goals Goals must be understandable, challenging and pertinent Strategies to achieve the goals should be understood and accepted by everyone Goals should be reviewed regularly and reflect changes in the organization’s organizational problems/opportuniti es Employing innovation and technological diffusion theories Infusion is related to the importance, impact, and significance of the change to the company Rational decisions may lead to Adoption success, not necessarily to Infusion success There must be a desire present to improve software development processes (pain of status quo, trigger to improve) Who needs the results (who pays the price of not changing) Types of pressure to change: Time, money, management, peers Types of motivators: Personal interest/drive, pay/benefits/rewards, career path, management commitment/particip ation, pull/push Motivational types:  Affective (values),  Continuance (long-term),  Normative (expectations),  Instrumental (external factors) needs Communication and Teamwork The SPI team will regularly communicate progress and results to the entire organization, to key organizational stakeholders, and to senior management in particular Senior management must communicate the business objectives, goals, and rationale for the SPI program, the urgency of those efforts, and their commitment to the effort Maintain and enhance sponsorship Encourage an open and honest communication Establish programs and mechanisms for collaboration Elicit input to get early and continuous Look for organizational, language, and personal barriers that cause lack of communication and teamwork Communication and teamwork require trust and skills Improve the quality and effectiveness of teamwork skills through education Individuals and groups responsible for the processes must understand that the objective is to improve the processes, not to assign blame Discuss assessment findings with the assessees before finalizing the recommendations Communication and Collaboration IT implementation is an organizational effort directed towards the diffusion of appropriate information technology to support particular tasks within a specific work context Appropriate userdesigner interaction and understanding Beware of inaccurate data Ensure proper integration with other IT Communication and teamwork require trust and skills An open and honest communication with access to data and information is encouraged Teamwork and respect for the individual is promoted Programs and mechanisms for collaboration are in place and used Early and continuous feedback is actively sought Causes for lack of communication and collaboration (organizational, language, and personal barriers) are found and reduced Progress and results are communicated to feedback Work with the solution providers Management should develop an incentive and recognition program for SPI Champions for SPI must have good interpersonal skills and the necessary leadership skills to lead the efforts, the entire organization, to stakeholders, and to senior management in particular Business objectives, goals, and rationale for the improvements, the urgency of those efforts, and the commitment to pursue the effort are communicated Recognition Recognition The recognition and reward system may help to encourage attitudes and behaviour for successful process improvement Visible success for those who participate in making the change An appropriate recognition and reward system should exist Education and Training Knowledge and Skills On-going education and training are essential for everyone to create and maintain an Build a knowledge and skill transfer strategy Educational programs to increase understanding of the need for change and the expected gains Organizational Management at all levels must be educated on process improvement concepts to increase perform planning and sponsorship building Champions must be qualified, experienced, and trusted by their peers New knowledge, skills, and behaviors must be learned and some old ways of doing things stopped (personal as well as organizational) Training and practice must be integrated into the project plans Establish courses in how to manage change Enhance change agent abilities environment for process improvement Effectiveness of education and training should be regularly assessed Training in process improvement concepts will increase the organization’s readiness for process improvement Process assessment concepts should be explained to all levels of the organization members are trained in the new procedures and IT application the organization’s readiness for process improvement On-going education and training are essential for everyone to create and maintain an environment for process improvement New knowledge, skills, and behaviors must be learned and some old ways of doing things stopped (personal as well as organizational) Build a knowledge and skills transfer strategy Quality and effectiveness of communication and collaboration skills should be improved Training and practice must be integrated into the project plans Champions for change must have good interpersonal skills and the necessary leadership skills Contextual Factors Champions must be qualified, experienced, and trusted by their peers Environment Characteristics of the:  User community (job tenure, education, resistance to change)  Organization (specialization, centralization, formalization)  Technology (complexity)  Task to which the technology is being applied (task uncertainty, autonomy and responsibility of person performing the task, task variety)  Organizational environment (uncertainty, interorganization al dependence) Acknowledge the characteristics of the:  User community (job tenure, education, resistance to change)  Organization (specialization, centralization, formalization)  Technology (complexity)  Task to which the technology is being applied (task uncertainty, autonomy and responsibility of person performing the task, task variety)  Organizational environment (uncertainty, interorganization al dependence) and the Interaction and the Interaction among these, such as the compatibility and economic advantage of the technology with organization and task characteristics among these, such as the compatibility and economic advantage of the technology with organization and task characteristics Organizational Learning Capture and retain lessons learned Lessons learned should be formally documented because lessons become lost and forgotten as SEPGs evolve and personnel rotate Creation of a repository or process database is vital to establish, maintain, and distribute a longterm memory capability The lessons learned should be transformed into generic templates and folded into a continuously updated approach that is disseminated to all Process Improvement involves continual learning and evolution Existing best practices should be adopted and institutionalized in the organization Strong processes provide experience of these Experiences about previous adoption of specific methods or tools in the organization should be assessed Process performance and process capability indicators are a basis for improvement Share information and knowledge practices throughout the organization in order to develop more lasting and complete business solutions Review the adoption or improvement experiences to determine what was accomplished and how the organization can implement change more effectively Integrate learning (knowledge) throughout the process Infusion seems to reflect social learning and political behaviors Learning models are useful when examining infusion Lessons learned should be systematically collected, packaged, and reused by the organization through specific activities incorporated and planned into the improvement activities The results of the process improvement efforts should be reviewed to identify:  successful practices, which should be adopted and institutionalized and  unsuccessful practices, which Lesson learned from past improvement efforts initiate the SPI action plan Lessons learned will be used during the Leveraging phase, where they will be reviewed and analyzed when preparing for the next cycle through the model Review past change and/or improvement efforts and identify successful practices to leverage and unsuccessful practices to avoid Review lessons learned from prior cycle goal setting activities Specific activities to gather lessons learned should be incorporated and planned into the SPI activities Track long-term usage of practices to see how widely they are adopted Maintain a state of actions Use a mixture of effectiveness measures and capability indicators to set targets for improvement Collect measurements on the practices/processes to show quantitatively the current status of processes and practices Collect good practices, keep records of comments on questionable practices, and highlight weaknesses in the practices Review the process improvement process itself in the light of experience Present the experiences to the entire staff should be avoided The process improvement approach should be refined by learning from the mistakes or omissions that have been made in previous efforts and the approach modified so they are not repeated Lessons should be learned from others’ efforts and from other organizations A support network should be established to keep making progress in learning new ways of doing things Share the results, lessons learned, problems encountered, and successes periodically with the entire staff awareness of the state of the practice Refine the SPI process by learning from the mistakes or omissions that you may have made in the previous cycle and modify your approach so not to repeat them again Learn from others’ efforts and from other organizations Validate findings by review with participants Distill lesson learned and desired modifications from feedback The SEPG will serve as the focal for organizational learning Establish a forum where SEPGs can exchange information to reduce the number of false starts and duplicate work Provide a support network to keep making progress in learning new ways of doing things Share the results, lessons learned, problems encountered, and successes periodically Distribute documented findings and recommendations to employees Plan and schedule lessons learned meetings ... stages than actually needed for classification of change approaches We have performed a pilot classification of changes approaches used in practice, where we wanted to be able to identify at... a clear need for helping and supporting project managers choosing the best change approaches for his/her project A framework for classification of change approaches for the strategic/organizational... programs and mechanisms for collaboration Elicit input to get early and continuous Look for organizational, language, and personal barriers that cause lack of communication and teamwork Communication