Life after project completion: Is a project complete without benefits realization?

In our day-to-day project management and PMO activities, the easiest and the most important thing missed is planning ahead for what happens AFTER we cross the finish line. So technically speaking, once project managers hand over the reins of the completed project to the business owner, their job is just half done. For a project to be considered complete, project managers must focus on the other half, which is “Benefits Realization”.

Benefit realization is the confirmation that the value a project was expected to generate really does get delivered.  In our everyday project management lives it is easy to get buried in details around task management, risk mitigation, resource capacity, balancing budgets and all the other moving parts.  We often forget why we set out to do the project in the first place:  the delivery of a product or service, an enhancement or improvement, or a capability.  For example to meet some new regulation, standard or market demand.  But what if, after we deliver the goods, and did exactly what the customer asked for, we realize that all the effort and resources we used to deliver the project don’t amount to what they were supposed to?  That’s exactly what benefits realization is all about.

We’ve all heard of ROI – return on investment.  It is the concept of an investment of some combination of resources (people, money, equipment, etc.) yielding a benefit to the investor.  A high ROI means the investment gains compare favorably to investment cost. As a performance measure, it is one of the best methods to evaluate the efficiency of an investment.  ROI does not exclusively have to be in financial terms.  It can easily be an operational advantage, an improvement in position, or other positive change.  In order to compare the efficiency of a number of different investments we need to compare like measures, which is why a financial ROI is one of the most commonly used.  Unfortunately, without benefits realization, our ROI is simply a guess.  And that is why benefits realization is so important.

I’ve discussed with   many of our clients about this and have found out that there is a need for a wide degree of maturity around the realization process.  This is an indication that while the concept of realization is gaining interest, it is still far from a mature practice.  Which presents a great opportunity for those organizations that are not doing it – now is a great time to implement this practice.

How to launch a benefits realization initiative?

One of the best approaches involves setting goals, tracking against those goals and including a ‘hand-off’ step, similar to the passing of the baton in an Olympic relay race.  Tactical steps you can take include:

  • Set your sights:  using whatever calculation available, combined with experience and validated by results from similar projects, come up with a target for what the value you think the project will deliver.  Set that as the initial estimate.  Enlist the help of a financial leader or controller to help set the original estimates.
  • Continual monitoring:  Using the initial estimates or targets as a first guess, continue to refine the success factors throughout the lifecycle of the project.  These are often called forecasts or committed values and are more accurate than the original estimates.  It is best to continue revising these figures throughout the lifecycle of the project.  The objective here is to have these forecasted numbers eventually match the actuals.
  • Start tracking actuals now:  some project can actually generate benefits even before the project is complete.  What a great win for the project team to be able to report these.
  • Put a plan in place: Add a milestone or stage beyond the Complete step called Close or ‘Realization’ and set a validation step 3, 6 or 12 months after the project is complete.  It sets the expectation that the work is not over at Complete.
  • It is outside of the project manager’s responsibility:  As the project comes closer to its Complete or End date, engage the financial sponsor and the process owner (the person who is benefiting or owning the project’s or product’s outcome, improvement or change) and have them start validating and “owning” the numbers.
  • Go back to the beginning:  how accurate were your original estimates compared with your forecasts and your actuals?  Take those learning and apply them to future estimates.  This is called continual improvement – applying lessons learned and best practices to improve the entire PMO.

One last point is that it isn’t always about the money.  Sometimes projects generate other value, such as an improvement in customer satisfaction, or increase market share by launching a game changing product.  It is important to be able to quantify the value of these types of projects even if they do not generate direct revenue or cost improvements.  Many organizations call these ‘Level 2” or “Indirect Benefits”.

Finally, is a project complete without benefits realization?  To the project manager who’s already run their marathon and marked the project as complete, I expect their answer to be ‘yes’, but common sense tells us otherwise.  As a best practice, one of the most important factors in a projects success isn’t “how we did it” – coming in under schedule or under budget – but “what we did” – that the project delivered what it set out to do.

Implementing and Monitoring Organizational Change: Part 3

While its relatively straightforward to monitor the performance of a risky technical component, track defects, and make a binary “go” or “no go” decision as to whether that component can be used,  monitoring and controlling the effectiveness of organizational change activities are often more difficult, given their emotional and typically subtle nature.  How do we know that individual employees are accepting the change or are we about to experience a mutiny?  How do we know that the impacted organizations have been able to adapt and accept the changes, or are the supporting roles, processes and procedures going to undermine or undo all of our efforts?  How fast can we expect a change-averse culture to change?  How do we know if we’re going too fast? Can we go faster?

The solution is the same as for the technical component; we establish a monitoring mechanism which tests the response of the impacted areas against the desired result.  The big difference is in how the monitoring and measuring is done.  In the case of the technical component we establish a performance standard and collect empirical data which measures performance against that standard.  If the standard is met we’re in the clear, if not it triggers a contingency plan.  With organizational change both the performance standard and the data collected may be more qualitative and subjective but it still serves its purpose; determining if there is (or is not) a problem and if a problem does exist, doing something different to influence the outcome.

For example, consider the project where the first indication that training or change management were not successful is when a major business process (like billing or payroll) cannot be executed?  Clearly we need ways to identify and implement course corrections long before they reach the critical stage of final implementation. 

Issue Log Monitoring

One approach to monitoring is to use the project issue log or create an additional log  for concerns; items which are not immediately solvable or actionable.  Assuming that the team is diligent in reporting organizational change related issues or concerns, the frequency and severity of issues can signal a developing problem, especially when sudden increases are observed in a single area.    If the team also compares the issue and/or concerns log with the risk register, which has clearly identified organizational change risks, certain elements in the logs will stand out and can be interpreted as increasing risk probability or trigger a contingency plan.


Surveys or questionnaires to monitor critical elements associated with organizational change provide a more structured approach to monitoring organizational change risks.  In this approach the project team creates a survey designed to elicit feedback from the organization about its perception of the project and the organizational change factors which may contribute to the success (or failure) of the effort.  By conducting the survey at regular intervals and comparing result from survey to survey, the team can quickly identify areas which require more attention and intervention.

  While creating and administering a survey represent additional time and cost to the project there are a number of benefits to be considered:  1)Collecting this information forces regular and systematic review of the project as it is perceived by the impacted organizations, 2)  As the survey is used from project to project it can be improved and reused, 3)The survey can quickly collect feedback from a large part of the organization, increasing the visibility of the project and reducing unanticipated or unwelcome reactions. 


In conclusion, organizational changes and the management of those changes can be a critical component for project success.  While the discipline of organizational change management may not be the primary focus of the project,, attention is required to understand what organizational changes may be required and their impact to both organizations and individuals.  Understanding the nature and scope of these changes enable the project team to more effectively plan, execute, and monitor their execution and effectiveness. 

Linking Business Strategy and Projects


Most of us recognize that having a strategy is a critical element for growing and improving an enterprise.  It is the strategy that defines the purpose or mission of the enterprise, establishes a clear vision of what we want to become, and provides goals or targets for accomplishing that envisioned future state.  In short, the strategy defines where we are going and ensures that we are all working in concert toward that same destination.

Unlike strategies, which broadly span the organization and are directional in nature, projects are tactical; they focus on creating specific capabilities, deliverables or outcomes.  Optimally, our projects (what we do) are in direct support of our strategy (where we want to go) and become the mechanism by which our strategies are implemented.  If we undertake projects that do not align with our strategy, we risk expending valuable time and resources on efforts that may not contribute to the long-term success of the organization.

Creating a clear linkage between strategy and projects can be a challenge, particularly in large organizations, but the benefits are well worth the effort.  In this article we will explore some practical approaches to establishing a clear linkage and using that linkage to realize tangible business results.

Create an Integrated Plan

In most cases, the translation of strategic objectives directly to individual tactics (or projects) results in a disjointed, scattershot approach where some strategic objectives are addressed by multiple, overlapping projects while other strategic objectives are ignored at the project level.  To avoid this, the successful organization creates an integrated plan that recognizes and records interim levels of goals and objectives that essentially cascade strategic objectives down through an organization.

Structure the Plan to Establish Alignment  (Top Down)

An integrated strategic plan helps us ensure that we’ve covered all the bases by successively defining how each level within an organization is going to contribute to the achievement of a set of objectives established at the level above.  For example, if the Executive Committee has established a set of strategic objectives, the second level of the integrated plan may consist of strategic initiatives or strategic goals that each division leader identifies for their division in support of the strategic plan.   The level below the division repeats the process to define how they’re going to support the division goals by defining programs, and so on until at the lowest level of the plan specific tactics or projects are defined (see Figure 1).

While the above example uses the organization hierarchy as the framework for creating the integrated plan, other hierarchies like line of business, product line, or geographical location may be more appropriate for organizing and building the top down integrated plan.  Regardless of the structure of the hierarchy, the process is top down, with each successive level identifying and defining their goals.  Each level clearly identifies who is accountable for performance at a given level and who provides oversight for the level below.  One could also argue that the integrated plan provides us with a model for sponsorship, with each level acting as the sponsor for the efforts directly below it in the hierarchy.

Figure 1:  The Integrated Plan

While the number of levels in the plan may vary based on the size and complexity of the organization, the structure of any level must recognize the objectives in the level directly above, thereby encouraging greater alignment as objectives are pushed out across and through the enterprise.

Quantify Goals and Objectives

While the communication of goals and objectives has value in maintaining ‘directional correctness’ for the organization, quantifying those goals and objectives provides clear targets for planning and measuring performance.

In quantifying objectives we need to focus on both sides of the business case: The return or benefit expected and the amount of investment expected to achieve that return.   Quantified cost and benefit targets remove ambiguity from the planning process.  If we create a plan assuming unlimited return or unlimited investment we have no way of evaluating or determining which initiatives, programs or projects actually represent the most advantageous mix in our portfolio of strategic investments.

Validate the Integrated Plan Bottom Up

As the Integrated Plan is created by cascading objectives from top to bottom, each successive level down is validated by the level above.  In other words, the individual or group responsible for a level must review the aggregate of plans from the level below to ensure that the individual pieces and parts from the lower level will, in the aggregate, accomplish the higher level objectives.

Perhaps the most difficult part of the bottom up validation process is dealing with the imprecision of the process.  While we do want to make sure that what is being planned at a lower level will realistically yield expected benefits for expected investment, there are no guarantees.  Consequently, in doing our validation we should not expect lower level numbers to tidily add up to the higher level numbers, but instead manage to realistic ranges of variations and recognize that as the plan is executed, adjustments and decisions will be needed to maintain alignment.

Be Flexible and Iterative

While we have presented a fairly structured top-down approach, it is important to remember that creating the integrated plan is not a rigid, linear process.  For example, it is not necessary to wait to start creating a lower level of the plan before the higher level is set in stone.  In many organizations, the construction of the integrated plan is an ongoing process where each level of the hierarchy is continuously adjusting based upon new information as it becomes available or in response to changing business needs.

Tracking:  Maintaining Alignment

While creating an integrated plan goes a long way in creating alignment to the strategy, maintaining that alignment over time is equally critical.  The primary difference here is that while creating the plan is typically driven top down, information used for tracking progress flows from the bottom up.  The key here is that the flow of information needs to be directed upward through the integrated plan in such a way that each successive level has the appropriate level of information for decision making.

As with any type of tracking, the first challenge is to determine what type of information is meaningful, determining the appropriate source for that information, and creating the processes to collect, analyze, and distribute it.  Additionally, we need to establish accountability and timeframes for information collection.

Collecting Information

Typically data collection for tracking starts at the project level.  Fortunately we have a plethora of mechanisms and processes for doing this and, in most organizations, accountability lands squarely with the Project Manager.

Where it gets fuzzier is when strategic goals and objectives cannot be tied to a single project or measured during project execution.  Tracking the realization of benefits is a good example of where the information from the project(s) is not adequate for tracking progress to a goal.  Let’s say we have a goal of increasing client satisfaction with our website by 20% before year-end as measured by survey responses.  To accomplish this objective, we have identified 3 projects to improve different aspects of the site.  Two of the projects will build on the work done on the first.   We’re making the assumption that each of the projects will yield some improvement in customer satisfaction, but the full benefit won’t be realized until all three projects have been completed.

In this example, we do need to understand projects, both individually and in the aggregate, but this information does not provide any measurement for tracking achievement of the 20% improvement in customer satisfaction.  In this case, we need to recognize that the tracking process that yields the appropriate information resides not in the projects, but instead at a higher level of our integrated plan.  Furthermore, whoever is responsible for setting and achieving the objectives in that level of the plan is also accountable for reporting on the progress at that level.  In other words, when we talk about performance information flowing upward through the integrated plan, it is realistic to assume that additional information and analysis will be added at each level.

Data Collection and Reporting Cycles

Establishing the frequency for reporting against the various levels of the plan may vary widely even within a single enterprise.  That said, establishing minimum requirements including frequencies and content of status reports and plan updates is critical to ensure that the right information is available at the right time.  One approach to establishing these requirements is to determine key review meetings at or toward the top of the hierarchy and work backwards from there.

If the Executive Committee meets quarterly to review the strategic plan, then the level below should be doing their analysis and tracking quarterly – with enough time before the meeting to compile the results.  Lower levels will report more frequently, with the general guideline that each successive level updates its plans and reports at least once, if not twice, before the status report at the next level is due.  Unless there is a compelling business case for doing otherwise, tracking and reporting more than weekly tends to add overhead without much offsetting benefit.

Maintaining the Integrated Plan

Like any other kind of plan, the integrated plan is a model of what we expect to happen.  It gives us a yardstick by which we can measure our progress against our goals.   It is not exactly what will happen nor is it something that will continue to add value if not maintained.

Whether we’re updating the plan to address a performance variance, or changing a high-level strategic goal to respond to market forces, the integrated plan may need to change.  Processes for making and communicating these changes keep the plan relevant and helps maintain the linkage between projects and strategy.


In summary, linking individual project efforts to a strategy is more than throwing a bunch of projects at the wall and seeing what will stick.  Building an integrated plan that cascades strategic objectives down through the enterprise creates a clear linkage between strategies and tactics (projects) while clearly identifying interim level goals, objectives, and accountability.  The integrated plan also provides a practical approach to collecting information for tracking progress and making adjustments across an organization.

While creating and maintaining an integrated plan can be challenging, the value-add of ensuring alignment to a strategy is well worth the effort.

Organizational Change Management – Part 2: How Does Change Impact Individuals?

When we make a change, individuals may be asked to take on unfamiliar or uncomfortable new roles.  Life becomes less predictable and less controllable.  Individual status and standing is affected as those who used to be considered experts become learners, just like everyone else.   By examining and discussing an organizational change in light of how strongly it impacts individuals and how they are likely to react can provide valuable insight into risks associated with resistance, non-acceptance, poor morale, fear, turnover, etc. While the project team can take an initial pass at this, participation by affected individuals from multiple organizational levels will provide a more realistic perspective as well as valuable input around mitigation strategies.

Questions to use in identifying risks from disruption may include:

  • Are different skills required to use the new process (or tool, or methods)? Are they related to the existing skills?
  • How much of a change does this represent to the person/people performing the work?  Will this create more work or less?
  • Where did the request or idea for the change come from?  Do the new processes address a problem identified by the people doing the work or is the primary impetus external (required by someone other than the impacted organizations)
  • Will this change result in staff changes, reallocation or reassignments?  Do people believe it will?
  • What is the level of additional effort required to make the change?  Do individuals see the additional effort as excessive?  Is the organization willing to accept a temporary drop in productivity as a result?

 How Does Change Impact Organizations?

Organizational structures refer to the organizational constructs which have the potential to support (or derail) an organizational change.   By the organizational constructs we mean the structures that define the organizational hierarchy (who’s in charge, who reports to who), the agreed upon roles, responsibilities and levels of authority.  The organizational structures define who makes decisions and, in some cases, defines the processes for how those decisions get made.  Organizational structures exist at many levels; across the enterprise, within individual departments and in the form of temporary organizations which may include committees, task forces and project teams.  An individual project can both affect and be affected by organizational structures.  Additionally, the organization structure of the project itself may contain risks:  conflicting functional objectives or approaches, different toolset and standards, or different reporting relationships can inject risk into the project.  This is especially true when the members of the project team are from different companies where the interaction between the members of the team may have contractual or financial implications to one party vs. the other (Hendrickson 1998).

All projects are subject to risks related to organizational structures.  Loss of sponsorship or priority resulting from leadership changes, changes in decision-making processes, renewal of commitments from reorganized functional areas all introduce risk into the project.  Also in any project, the structure of the project team itself may be the source of certain risks.  Weak matrix teams must consider the risks associated with negotiating for priorities and scarce resources with functional managers, while dedicated project teams must manage the risks associated with staying connected to and consistent with the direction of other parts of the organization.

There is however evidence that there are two other types of risks specifically associated with organizational change:  1) the impact of changes on the way an organization is structured and interacts with others and 2) how well the project integrates or fits into the larger organization.

When a project is going to impact an organization structure, our organizational change strategy must consider the socio-political implications of the changes being proposed.  Often changes are perceived by an organization or the individuals within it as a threat to power, control, influence, status, access or resources (including people and money).  Concerns may also arise about the dynamics of interactions between organizations based either on past experiences or a desire to preserve the status quo.  In either case the reactions, both rational and emotional, may manifest as vehement objection to total withdrawal of support for the project.  What at the outset of the project may seem like a straightforward set of decisions about who is going to do what, become complex negotiations escalated up to the most senior levels of the enterprise.  In some environments, even a minor change to the composition or responsibilities of organizations may require huge amounts of time and resource to redefine and document the detailed process and interactions of those reconstituted groups.  While some organizations are adept at making these changes, others are much more resistant and may require more time to fully design, document, and review before they will accept or relinquish responsibilities.  In efforts where the organizations cross corporate boundaries (multi-company efforts) contracts may need to be renegotiated or terminated.

In considering organizational disruption consider the following questions about the proposed or planned changes:

  • Will this affect the overall role of an organization?
  • Does this affect the level of control a department has over their work?  Will this be seen as a loss (or gain) of control?
  • How will the project team interact with the departments?
  • How will this affect how organizations interact?  Will it make one organization more dependent upon another?  Less dependent?
  • Does this affect staffing levels or reporting relationships?
  • Do we know the procedural requirements of the functional department.  Are there any processes or procedures which are a mismatch to how we intent to operate?

Implementation Activities

Once the nature and scope of potential changes have been identified and understood it is reasonable to assume that the appropriate activities needed to effectively address the organizational change requirements of the project can and will be effectively executed.  But here again, those project teams not familiar with or sensitive to organizational change activities may find themselves challenged to determine how best to execute the organizational changes needed for successful project implementation.   Fortunately, there are a number of approaches that can be used, individually or in combination, to address organizational change.

Communication and Commitment

Good communication across an organization is always important, but when an organizational change is involved the importance increases.  Communication from the most senior levels of management demonstrating commitment and support of the change is critical and is most effective when the rationale of and urgency for the change is clearly explained.  When Lou Gerstner took over a troubled IBM in 1993 he recognized that employee communication was an essential part of the effort to transform the organization and return it to profitability.  Gerstner knew that the impending changes would cause pain in the organization but that they were necessary given the magnitude of IBM’s crisis.  He recognized that as CEO his role was to “strongly and continuously” communicate both the crisis and the plan for addressing it:

“All of this takes enormous commitment from the CEO to communicate, communicate, and communicate some more.  No institutional transformation takes place, I believe without a multi-year commitment by the CEO to put himself or herself constantly in front of employees and speak in plain, simple, compelling language that drives conviction and action throughout the organization.”  (Who Says Elephants Can’t Dance?: Leading a Great Enterprise through Dramatic Change,  Louis V. Gerstner, 2003)

While Gerstner’s transformation effort was far broader than the organizational changes associated with most projects, the need for strong consistent executive commitment and ongoing communication of that commitment are equally essential.

Two-way communication between the project team and the impacted organizations is also a critical component for successful organizational change.  While executive communication focuses on why the change is needed, these need to focus on the content of the change (the what) and how it will be implemented.  By communicating what and how, impacted individuals and departments have more time to think about and adjust to the upcoming change.  Likewise for the team – open, two-way communication between the project team and the impacted organizations can significantly reduce the “element of surprise”, where unknown objections or problems surface at the last minute.

Phasing and Chunking

Another strategy for mitigating risk is associated with organizational changes is to introduce the changes gradually either by phasing in the changes within the project or by dividing a larger projects into phases or ‘chunks’.  From an organizational change perspective the incremental approach has a number of benefits.  First, smaller changes cause less disruption which in turn may reduce the amount of organizational and individual resistance.  Second, smaller efforts may be seen as more achievable, encouraging support and buy-in from impacted organizations.  Third, lessons learned in earlier stages, about the organization and how it reacts to change, can be integrated into later efforts.  Lastly, individuals and organizations involved in earlier organizational changes can be called upon to assist in “selling” the effort to others.


In implementing new products, systems and processes we often ask individuals to quickly acquire and apply new knowledge on the job.  Even with the best most comprehensive training programs turning “what one learned” into “what one does” back on the job can be frustrating and stressful.  Combined with the demands of “getting the job done” these frustrations and stresses can result in a backlash that threatens the success of the project.  One strategy that reduces impact  is providing coaches to support the initial implementation.  The role of the coach is to help people quickly work through problems or issues, share knowledge about nuances of the new product or process, and act as a conduit for feedback to the team on usability issues or other functions and features that were great ideas in the lab, but not in practice.

The most effective coaches are individuals who were actively engaged and part of creating the new product or system being implemented.  These people intimately understand not only the mechanics of using the product or process, they understand why certain things were done the way they were and the intent of certain design decisions. Optimally the coach is able to share that knowledge – enabling the new user better understand the rationale and apply the change more effectively.

Part 1: The Role of Organizational Change Management in Project Success

In its most fundamental form change management is what we do to control and manage the impact of a change.  For example, Project Change Management provides us with a mechanism for controlling and managing changes that left unchecked could prevent a project from accomplishing its objectives.  System/Configuration Change Management is how we ensure that changes to computer systems and applications have been adequately tested and controlled so as to minimize the risk that a change will cause an error or interruption in service.  But how are we managing the impact of changes on people in the organization?  Are we deliberately taking action to control the impact of change and encourage adoption or the change or are we assuming that everyone will joyfully embrace change and adopt whatever is being introduced without question, resistance or complaint?

Experience shows that the most successful change efforts, whether they involve the introduction of a new product, business processes, or a business model, include a conscious effort to understand and manage the impact to people and affected organizations.  Indeed, Organizational Change Management (OCM) is quickly becoming one of the disciplines or practice areas recognized as essential to project success and we will frequently see specialists and consulting firms specializing in OCM either involved in major projects or in helping organizations implement OCM processes.  But in organizations or projects that don’t have formalized processes or resources to dedicate to OCM activities, the responsibility for identifying, planning and executing OCM-related activities falls to the manager and the project team.  In this article, we will explore why OCM needs to be considered in every project and how effectively identify, plan and manage those changes to support project success.

Organizational Change Management as a Project Component

Organizational change is generally defined as making changes within an organization that will affect the way the way individuals and groups operate and interact.  Introducing new processes or technologies may change the way jobs are performed, redefine roles and responsibilities, or change reporting structures.  More often than not organizational changes involve new expectations, new processes and tools, new partnerships and relationships.

In some cases changes to the organization are intentional and the role of Organizational Change Management in the project is obvious.  Organizational transformation initiatives and projects are undertaken with the primary objective of consciously introducing specific and often sweeping changes designed to improve organizational performance.  These projects focus on the changing the way the entire organization or a large part of it operates.  Transformation projects involve radical restructuring of job responsibilities, operating processes, and reporting relationships, major changes to how employees are evaluated and compensated and, in some cases, attempts to change the underlying organizational cultures and behaviors.  While these projects and their parent initiatives introduce significant organizational change, these are fairly well documented and the literature is filled with case studies and strategies for managing the changes resulting from kind of endeavor.

In other projects however, organizational change is not the primary project objective but instead a by-product or a component of the project:  something that impacts the organization in such a way that the organization and its people must change to adapt to or absorb that impact.  Much like a rock hitting a pile of sand, organization changes form as a result of the impact whether or not it was intended or accidental.  For example, consider a project to move a department from one office space into another – while the project team might be focused on the move itself, the people being moved are focusing on things like is the new space comparable to their old space?  Is it larger? Smaller?  Located closer to a window? Farther away?  Might their new location be perceived as  more or less prestigious than their current space?  Is the new space that someone else has been given a reward?  Or perhaps a punishment?

Organizational impacts may also result from the deliverables of the project or from how the project is organized and how it operates.  In other cases the impact is to the project itself; internally or externally introduced organizational impacts that force some organizational elements within the project to change.  Whether internal or external, caused by the project or affecting it, all of these impacts have the potential to significantly change the schedule, cost or scope of a project or program and, as such, require mindful and effective management.

Identifying Organizational Change Impacts

Like managing anything else, the first step in managing organization change is to identify what kinds of organizational impacts may result from the project effort.  Like in risk management there are organizational changes that we can anticipate and others that may appear from nowhere.  Needless to say, we want to anticipate and plan for as many as possible.

Identifying organizational impacts and changes can be difficult even when they are the primary objective of a project and expert resources are deployed to carry them out.  In fact, a large number of transformation projects are challenged or fail outright.  If the success rate is that low in initiatives where organizational change is directly linked to the project objectives and, hopefully, have been considered and planned for, it’s not surprising that organizational impacts resulting from other types of projects are not addressed in the project planning or execution processes and remain invisible until they become significant barriers to project success.

Why are organizational impacts and their attendant risks so often overlooked in projects?  Project management texts frequently identify and describe organizational risks, numerous published case studies on project failures cite organizational change issues as major contributors to project failure, and most experienced project managers have sat through at least one risk brainstorming sessions where someone on the team has brought up an issue or risk relating to organizational change.  In fact, most project managers and teams recognize the potential for risks associated with organizational change, but tend to dismiss them as unmanageable, indefinable or inconsequential.

So the first challenge is simply recognizing that organizational change will be needed for the project to accomplish its objectives.   While sometimes obvious, there are often projects where the need for change is more subtle or where the agreed upon deliverables may be in conflict or inconsistent with the beliefs or values of the organization.  For example, an effort to implement a heavyweight, detailed control process in an organization that prides itself in its speed and agility will require much more attention to organizational change than the same effort might take in an organization that highly values structure, discipline and rules.  In other words, for the project to succeed the mismatch must be recognized and the appropriate changes to the project and/or the target organization must be made.

Even when we recognize that our project will require some level of organizational change management,  we encounter a second challenge; clearly identifying and defining the specific impacts that may  result from or be created by any given project or effort so that efforts to mitigate or manage them can be included in the plans for the project.   This difficulty stems in part from the fact that the reaction to, and much of the impact of organizational change is emotional.  Rather than facing a straightforward issue or risk like ‘ part x doesn’t perform to specifications’,  the project manager is faced with concerns about changing behavior and beliefs, impacting morale and job satisfaction, and anticipating a myriad of emotional reactions which may not respond to a fact-based rational response.  In short, while many of us intuitively know that there will be an impact, we may be hard-pressed to define that impact and come up with effective approaches to dealing with them.

Recognizing the need for organizational change management as a component of an effort and establishing strategies and plans for meeting that need are critical first steps but much more is needed to ensure at organizational impacts are understood and effectively managed in a project.

Planning for Organizational Change impacts

Once we’ve identified where organizational change is likely, we can plan for it.  Obviously planning for organizational change is more proactive than dealing with it as an issue during the project.  Planning can include identifying organization change management activities as part of the project scope and schedule or addressing it as part of the Risk Management Plan.  Needless to say, your approach should be driven by the scope and impact of the change.  The more extreme the change and the more people effective, the greater the need for proactive organizational change management.

Any effort to plan for organizational change must consider: 1) A single project may introduce a number of different organizational impacts, 2) changes may impact different individuals and groups in a variety of  ways and 3) organizations are made up of people will not all perceive or react to the change(s)  in the same way.

Likewise, teams planning for organizational change need to be mindful that the sources of organizational changes are not always obvious.  While most of us are fairly sensitive to how the outcome of our project might require changes in the way individuals and groups operate and interact, we may not recognize that the execution of the project itself may introduce major organizational impacts.  Take for example the major project that requires significant participation of people normally assigned to operating groups. Whether the assignment is full time or in addition to their ‘real jobs’,  these people and the people who are not assigned to the project are being asked to change the way they operate and interact.

As another example, in the early 1980’s I was involved in a project to convert a loan collections operation from a paper-based system for keeping records and notes on collection calls to an on-line system.  The new system required collectors to type their notes using a keyboard.  While quite a bit of planning was done around implementing the new system and training the collectors to use it, and we had not considered the possibility that some of the collectors might not have keyboard skills (the majority did not).  As soon as this came to light, we arranged for training and practice sessions in touch-typing.  Fortunately we caught the issue early enough to minimize any cost or schedule impact.

Unfortunately the lack of keyboard skills was just the beginning of our problems.  It turns out that no one had considered the impact of the transition on productivity:  Forced to use a new technology with newly acquired, beginner-level skills, collections the first month after implementation dropped by 40%.  While some productivity drop had been anticipated by the organization’s management, what was not anticipated was the huge turnover in the collection staff that occurred shortly after the implementation.  It turns out that the collectors’ compensation plan was heavily based on commissions and bonuses for dollars collected and a number of them  were aggressively recruited by a competitor and left for compensation packages that would enable them to recover the income they had lost during the initial implementation.

Here was a case where we recognized the potential impact of using a keyboard, but we didn’t think beyond the objectives of the project to the individuals within the organization.  The moral of the story is that we need to consider a broad set of possibilities in order to really plan for organizational change.  This means looking at how we might be disrupting both individuals and the organization as a whole.

Change is by nature disruptive.  The introduction of new systems, processes, products, tools and methods all have the potential to upset the normal operation of the organization and how individuals see themselves in that organization.   If t we are unable to effectively manage the level of disruption, the backlash will prevent a fully successful realization of the desired project outcomes.  Likewise, if the project team is effective in managing and minimizing the disruption the effected organizations will be more likely to accept and readily adopt the changes being implemented.