Abstract
What makes a project successful? Can a successful project also be a failure? Yes, if the intended users of a project deliverables (like a new system implementation) are not adequately prepared. Further, the project team may have disbanded before this is fully recognized. The broad view of Project Change Management focuses on avoiding this problem. The good news is that Project Change Management consists of common sense elements, particularly when looking backwards at a completed project. The bad news is that Project Change Management may not receive the proper priorities within the overall project plan precisely because it is so common sense.
Introduction to Change
The Roles of Leadership, Power, and Paradigms
Leadership involves influence. There are many definitions for leadership. One approach is to view leadership as a process involving influence by the leader to get followers to pursue some course of action … to accomplish some objective. Cartwright (1958) noted that power is the influence exerted by some people over others. This includes the influence that a leader exerts over followers. As contributors to Cartwright's book, French and Raven (1958) described five different types of power:
- Reward … based on a follower's perception that the leader will provide rewards if expectations are met
- Coercive … based on a follower's perception that the leader can punish the follower if expectations are not met
- Legitimate … based on a follower's belief that the leader has a legitimate right to influence and that the follower has an obligation to accept that influence
- Referent … based on the follower's desire to have an identity with the leader
- Expert Power … based on the follower's perception that the leader has special knowledge … in relation to his own knowledge as well as against an absolute standard
The output of the leadership process usually involves a change from the status quo. Since this process requires influence, one should recognize that this can involve multiple types of power and could potentially range from being physically coerced by a tyrant to being mesmerized by a charismatic leader. Further, the leader's intent can be misinterpreted because of a follower's paradigms.
Paradigms function as filters that enable individuals to see, or not see, data. Kuhn (1996) discussed this phenomenon over 40 years ago when The Structure of Scientific Revolutions was first published. Specifically, Kuhn described paradigms from the perspective of accepted scientific theories and models. Kuhn suggested paradigms represent the consensus of the scientific community; i.e., a structure for classifying data about a particular subject.
A paradigm's filtering mechanism can misclassify or even ignore relevant data. It tells an individual what's possible and what's not possible. This helps explain how scientists can sometimes ignore data that they consider “anomalous”.
Barker (1992) discussed paradigms from a business perspective. In particular, paradigms are the rules that enable each individual to interpret the world. Barker also discusses the “going-back-to-zero rule” (p. 140). This occurs when there is a paradigm shift (like the implementation of a new system). In this situation, everyone starts over with respect to their knowledge (and expert power). Individuals who have significant knowledge and experience in the old system potentially have a lot to lose, and therefore may be more resistant to the changes.
Leaders can convey their paradigms to others through the Pygmalion Effect. The name comes from mythology where the sculptor Pygmalion fell in love with one of his statues and begged the Goddess Venus to bring the statue to life.
The Pygmalion Effect is also referred to as a self-fulfilling prophecy. This is well documented in educational settings. A teacher's expectations for a student (either to do well, or to not do well) impacts how the student ultimately performs. There is even evidence of the Pygmalion effect in the software development process. Carreira and Silva (1998) described a situation where Quality Assurance (QA) reviewers tended to not review as closely the code developed by someone believed to be a top-notch programmer. The key take away here is that the expectations a leader communicates … both spoken and non-verbal … impact the way stakeholders ultimately react. Since the leadership process is typically focused on change from the status quo, it's useful to view models for change from different perspectives.
The Different Ways Change is Viewed
Van de Ven and Poole (1995) proposed a taxonomy of four categories of change models. According to the life cycle approach, change is imminent and prescribed. The evolution approach states that change is more of a probabilistic progression. Both of these categories seem adaptable to biological processes. The third change model category, teleology, assumes that change involves a movement toward a goal or end state. The fourth category is dialectical models. In this category, change (and stability) results from opposing forces. These latter two categories of change models appear more applicable to understanding change management from a project perspective. This taxonomy is useful in describing the causes of change. Other authors discussed what happens during change.
Goodstein and Burke (1991) discussed several models of change. One attributed to Lewin described change as a three-phase effort. Specifically, the phases of change are unfreeze, change, and refreeze. Goodstein and Burke also discussed another change model, attributed to Beckhard and Harris, which described the three phases as present state, transition, and future state.
Kubler-Ross (1969) formulated a five-phase model of change while working with terminally ill patients. According to Kubler-Ross, change involves denial, anger, bargaining, depression, and (finally) acceptance.
Two other authors discussed change from different perspectives. First, Kotter (1996) described an eight-stage model:
- Establishing a sense of urgency
- Creating the guiding coalition
- Developing a vision and strategy
- Communicating the change vision
- Empowering broad-based action
- Generating short-term wins
- Consolidating gains and producing more change
- Anchoring new approaches in the culture
The first of these eight stages can be viewed as the unfreezing phase of Lewin's model. The second through seventh stages seem to be more involved with the change itself (Lewin's second phase). Finally, Kotter's last stage is very similar to Lewin's refreezing phase.
Second, Gladwell (2000) discussed three “agents of change”. The first is “The Law of the Few”; i.e. only a few key people need to adopt the change for the remainder of the group to follow. The second is “The Stickiness Factor”; i.e., elements of the proposed change must memorable. Finally, the third is “The Power of Context”; i.e. the proposed change must fulfill a need within a context.
Thus, there are multiple ways that the change process is viewed.
Project Change Management Perspectives
Different Viewpoints
There are also multiple perspectives on how change management is defined within a project context. A narrow view focuses on version control of programs and systems in an Information Technology (IT) setting. Schiesser (2006) is typical of this view: “Change management is a process to control and coordinate all changes to an IT production environment” (p. 119). Similarly, others consider change management as the project scope control effort. There can also be confusion with personal and organizational change management from an organizational development perspective. Further discussion requires a definition of project change management.
Definition of Project Change Management (PCM) As a Process
If change is the movement from a current state to a future state, then change management can be defined as the mechanism or process to facilitate that movement. In this context, Project Change Management (PCM) is the leadership of the process to enable groups of individuals to move from a pre-project current state to a post-project new state.
Hammer and Champy (1993) defined a business process as “a collections of activities that takes one or more kinds of input and creates an output that is of value to the customer” (p. 35). The activities of the PCM processes could include providing understanding (to the stakeholders affected by the project), enabling new stakeholder skills, and assessing stakeholder readiness for the change.
Difficulties in Explaining the Broad Nature of PCM
The multiple perspectives regarding what constitutes project change management contribute to the difficulties in communicating what is involved. As with many project activities, narrow definitions seem to make it easier to complete the tasks. This same narrow view can lead to considering the project complete when all of the project activities are deemed “checked off” as complete. There should be no problem with this if the project scope has been appropriately translated to the project activities. However, it's easy to discount the “soft” aspects of project change management and focus on the verifiable aspects.
Nelson (2006) discussed a study of IT projects which “discovered that projects that were found to meet all of the traditional criteria for success–time, budget and specifications–may still be failures in the end because they fail to appeal to the intended users or because they ultimately fail to add much value to the business” (p. 28). A later section in this paper asks the question whether this also applies to non-IT projects.
PMBOK® Guide Considerations
The 3rd Edition of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) has several chapters that discuss elements of PCM. Much of the discussion in Chapter 10 (Project Communications Management) applies. In particular, three processes within Communications Management are directly applicable to PCM: communications planning, information distribution, and manage stakeholders. The next section discusses the importance of effective communications in the Project Change Management efforts.
The concepts addressed in Project Human Resource Management (PMI, 2004, Chapter 9) also apply when viewed from an end user perspective rather than the project team. Specifically, the tasks performed by end users following the project implementation must be assessed and appropriate training provided. These principles are similar to the human resource planning and the develop project team processes. The next section discusses end user training as a two-phase effort: training development and training delivery.
Similarly, the concepts addressed in Project Scope Management (PMI, 2004, Chapter 5) apply to PCM. The PCM activities are part of the project scope and therefore must be defined, included in the work breakdown structure, controlled, and ultimately accepted as part of the project deliverables.
Elements of a Broad Project Change Management Plan
The minimum elements of a PCM plan are communications, training development, training delivery, and assessment of stakeholder readiness. If needed from a project management perspective, additional elements can be included in the PCM plan.
Communications
It's generally recognized that project communications, both internal and external to the project team, are important for all stakeholders. These include both routine and ad hoc communications. Obviously, internal project team communications are impacted by the size and location(s) of the project team.
The expected end users of the project are a critical subset of the project's stakeholders. Although a few end users may be on the project team and therefore have access to current information about the project, most end users are dependent on the project team to provide periodic communications. These periodic communications help to shape the end users' paradigms about the project, and ultimately impact the degree of acceptance of the project results. These should all be addressed in the Communications Plan.
Training Development
Training is a two-phase effort. The first phase involves the assessment, design, and development of any training required to enable the end users to use the project's result. Essentially all of the end users will need an overall orientation to the system or product. For some, this orientation will be sufficient. Many end users will need more specific training to enable them to use the system or product for their particular work responsibilities.
If the system or product has created fundamental changes in the way work is done (including creating new work tasks), these should be addressed in the training design and development. Similarly, any training development needs that arise from business process re-engineering efforts should be addressed here as well.
The training development effort should result in both materials used in the direct training and reference material to be used by the end users after the project has been completed. If the project's objective is to replace a system, there may be changes in terminology that the end users must learn. It is useful to prepare a cross reference guide that provides a translation between the old and new system terms.
Training Delivery
The second phase of training involves the delivery of the training to end users. In addition to the traditional instructor-led classroom approach, there are other options that allow scheduling flexibility. If the end users to be trained are geographically dispersed, a distance learning tool can allow a real-time, instructor-led class with students in their individual work locations. Further, these distance learning sessions can be recorded for later playback – either by the participants or by end users who were unable to attend the “live” session. It may be possible to provide the orientation training only via recorded sessions. Typically, these orientation sessions are prerequisites to more task-specific training. This recorded session approach allows the end user students to prepare for the task-specific training at their individual pace.
Stakeholder Readiness
Ultimately the success of the implementation is a function of the end users' adoption of the project results. Projects sometimes use the term “Go Live” to refer to the point in time at which the new system or product becomes operational. The process to make the Go Live decision, particularly for IT system implementations, can involve the assessment of a number of key factors. These decision factors can include the status of testing, confirmation of key Go Live assumptions, and even the weather forecast for the Go Live time period. The readiness of the end users for using the new system should also be a Go Live decision variable, even though it may be subjective. Forcing a Go Live to meet a project schedule when the end users aren't adequately prepared can be a recipe for disaster.
Additional Elements
There are several additional elements that could be included in the Project Change Management plan, depending on the needs of the project and the Project Manager. These include the Support Plan for both the Go-Live event and the immediate timeframe following the Go Live event. The latter is sometimes referred to as the “storm period”. If appropriate, the PCM plan could also include business process reengineering (BPR). At a minimum, BPR impacts the training effort. It's possible that the BPR may be a direct result of the new system.
Observations and Insights
There are several lessons learned from a PCM perspective. Some are discussed below, in no particular order. The sources include published materials, experiences from executives across several industries, and personal insights.
Manage Expectations … Define Success
All project managers know the importance of getting agreement on the project's expected outcomes early in the project. The end users' understandings of these expected outcomes (as filtered through their paradigms) influence their perceptions of the project's ultimate success. And these perceptions impact the realization of project benefits.
Some end users may not like the definition of project success. The day-to-day lives of some may be worse after the project is completed. Project benefits are assessed at the macro, not micro level. Further, all end users may point to the inevitable problems that arise post-implementation as proof that the project failed. It's important to define project success up front, and repeatedly reinforce that definition. Obviously, project communications play a key role. In essence, it's an education effort.
Communications Really are Important
A common phrase in project management and elsewhere is “Communications, Communications, Communications”. Although this is addressed in the Communications Plan, it's worth emphasizing the linkage here. As mentioned previously, end user perceptions impact their adoption of the change caused by the project. Those perceptions are shaped by a variety of factors, including both their individual paradigms and the Pygmalion Effect paradigms inherent in the project communications. The Project Communications Plan will contain the “what” of the messages, but paradigms are also shaped by “how” the messages are communicated. This goes well beyond the media used to transmit the messages.
The typical end user doesn't have access to the business case that resulted in the project's approval. Therefore, the typical end user probably does not have an appreciation for why the change is being undertaken. For some, it's sufficient to explain that the expected benefits outweigh the pain that results from change. Explaining the “why” of change is as important as the “how”. One caveat – not every end user benefits from the change.
Training Gaps Are Frustrating
There is sometimes a gap between the system used for training and the final project results. This is frustrating to end users trying to use a new system. This gap can occur because training development can be a long lead time item. It may be necessary to base the training on interim versions of the system. To the extent possible, any gaps in training can be addressed by providing updates in refresher training sessions for end users just prior to the project Go-Live. This refresher training may be beneficial even if there are no training updates, per se.
Should the Focus be on Adopters or Complainers?
An adopter is an individual who embraces a change, such as a new technology. It's not necessary here to distinguish between early and late adopters. However, it is helpful to remember Gladwell's “Law of the Few” and try to have key influencers among the visible adopters. A complainer is at best a reluctant adopter. At worst, a complainer becomes a stumbling block to a successful implementation. Where should a Project Manager devote attention – to the path of least resistance (the adopters) or the path of most resistance (the complainers)? Obviously, context is an important variable here. If the individual who is complaining has a legitimate concern or is a key influencer, the Project Manager must address the concerns. However, some individuals simply resist change (perhaps because of Barker's “going-back-to-zero rule”. In this case, the Project Manager should focus on increasing the number of adopters and accelerate to the tipping point.
Quick Wins Provide Momentum
Quick wins can generate enthusiasm about the project's expected outcomes and also add to the list of adopters. Other terms used in addition to “quick wins” include “low hanging fruit” and “no regrets moves”. These quick wins serve at least two useful purposes. One involves the purpose for undertaking the project in the first place – to achieve the benefits associated with the project results. Quick wins accelerate the realization of those benefits. The second purpose is to generate excitement about the project and thereby add to the list of adopters.
A PCM Focus fits with Traditional Project Management Tasks
It is important to dedicate resources to the PCM effort. Both Project Managers and Sponsors may consider the project change management costs as overhead, and therefore seek to minimize them. It's extremely important to view project change management as an investment, rather than a cost. Adequate PCM staffing and expenditures should be in project budgets.
Likewise, all of the PCM activities should be included in the project plan. If subsidiary project plans are created for other functional areas, one should also be considered for PCM. The PCM activities should also be included in the project schedule. With proper planning, PCM activities should not be on the critical path.
Soft Dollars are Still Real Money
Because a part of the success of PCM is not easily quantified, the benefits of the overall PCM efforts may be considered soft. From a “get in, get it done, and get out” perspective of project management, it seems logical to exclude the subjective aspects of PCM from the project plan. The project sponsors who represent the interests of all stakeholders should resist this. The soft dollar costs of not focusing on PCM still are real costs the organization incurs. They just don't show up as a project cost.
Summary
An integrated view of PCM makes sense intuitively while looking backwards at a project. On the front end, however, the project planning focus on traditional issues associated with the project deliverables may diminish the priorities given to PCM. Also, the project management team may have a narrow view of PCM and consider it adequately addressed in the integrated change control process description.
Further, the results of some PCM activities, like training, may not be assessed as readily as other project activities like user acceptance testing. It's possible that the project team has disbanded before there is full recognition that the PCM efforts were not effective.
Some of the discussion in this article used IT terminology and examples. Is there a difference between IT and non-IT projects from a PCM perspective? Probably not. Non-IT projects still have end users who have to be adequately prepared to use the project outcomes. This preparation begins when the initial communications about the project starts to impact the end users' paradigms, and continues through the point when the project is declared complete.
In summary, Project Change Management is a critical yet potentially overlooked component of successful project management. A broad view of PCM increases the likelihood of project success, as viewed by the end users. The ultimate success of a project is related to the realization of the benefits identified in the project approval stage. And that's where the end users become the critical path, so to speak.