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.

Why is team collaboration not enough?

Expanding beyond team/social collaboration to business collaboration

The term “collaboration” has become one of the primary hot topics for businesses and analysts throughout the industry lately.  At its most basic level, “collaboration” simply means “working with others in a coordinated fashion toward a common goal.”  But few actually attempt to define what it really means in the context of business and PPM.

If you ask most people what capabilities define collaboration in the workplace, they generally talk about the sharing of information within a given team:  document management, threaded discussions, activity feeds, instant messaging, shared calendars, task assignments, facilitation of problem solving and idea development, communication of decisions and meeting minutes, etc.  This is all good, and certainly helps a team move forward in coordinated fashion toward the common goal of completing a project or specific unit of work.  Nearly all PPM solutions provide functionality to address each of these needs within the scope of a project.  SaaS PPM solutions are particularly well-suited to providing this level of team collaboration since, by their very nature, they are accessible to all team members regardless of geographic diversity and the information they contain is always available in near real-time.

I would argue, however, that this limited view of collaboration is incomplete.  Looked at from a broader perspective, an entire organization can be viewed as a collection of units which must all work together in a coordinated fashion toward the common goal of alignment and execution against the business’ corporate vision and strategic objectives.  Thus, business-level collaboration is necessary to establish the direction for an entire organization.  “Business Direction” includes the definition for the organization’s Vision, Goals and Strategies.  By sharing and collaborating on the Business Direction, the business teams will be better prepared to drive the various work efforts.  True business-level collaboration therefore depends on the free flow of information between the project teams and the outside world – management, other departments, executives, stakeholders, etc. – to facilitate proper alignment and effective decision-making throughout the entire organization.  It is this level of “business collaboration”, as opposed to individual “team collaboration”, which is often missing from a company’s collaboration strategy.  All too often, anyone not on the core project team is actually excluded from access to the system of record for project performance and must therefore depend upon periodic status updates or word-of-mouth communications to understand, participate, or make critical business decisions on project information.

Business collaboration provides a level of transparency and visibility to project details throughout an organization.  At its heart, business collaboration makes heavy use of enhanced dashboarding and powerful reporting capabilities to expose appropriate project information to those who are outside the core project team.  Ideally, facilitation of business collaboration also provides processes and methods for these external resources to submit inquiries and participate in discussions, access project documentation, and all of the other traditional collaboration capabilities as well.

When examining the collaboration strategy within your organization, be sure to keep the big picture in mind.  Team-level collaboration is certainly important.  But enabling collaboration across departments and across levels within a larger organization can often be even more critical to the success of the entire business.

Educause 2012 Takeaways

The Educause annual conference is the nation’s largest gathering for higher education IT professionals and Daptiv was present for the well attended 2012 conference in Denver.  Issues that attendees were concerned about were diverse but several interesting themes emerged over the course of attending sessions and having one-on-one conversations with end users and CIOs.  One particularly well attended discussion on Project Management was intriguing, many pain points seemed common across education IT departments and Project Management Offices. Here are some of our takeaways from the conference:

Increasing Demand Placed on IT: Demands placed on IT departments are becoming large and disparate with multiple university departments demanding conflicting projects from an increasingly resource strained IT staff.  With this increased pressure, CIOs and managers are looking for a way to streamline and manage their suite of projects.

Prioritization: Many attendees were seeking best practices and methodologies for prioritizing their portfolio of projects.  Several attendees shared their successes and failures but several threads were common though all successful processes:  easy to communicate and simple to deploy.  Many attendees sought visualizations and reporting that would allow them to quickly judge the size of a project vs. its projected benefit.  The easier it is to demonstrate relative importance and prioritize one project over another, the easier it is to communicate with and receive buy in from competing university departments.

Communication: Ensuring everyone is in the loop on project decisions is critical.  Lacking a single source of truth for project management, implementing an effective communication plan can be difficult.  Project Managers and IT needs to communicate early and often with stakeholders.  Schools and universities which emphasized their success in communication reiterated this point.  Every stakeholder needs to feel that they are part of the dialogue.

Flexibility vs. Standards: Project Management Offices, once built to solve the above issues often face their own hurdles.  Being flexible enough to maintain engagement with stakeholders while ensuring accountability with standards is itself a challenge.  Flexibility needs to be built into the DNA of the PMO and IT Department early and must be matched in any tool used to manage their projects.  It should be up to the department to develop the processes, not have an outside process thrust upon them.  In the words of one attendee, “The tool used should be process agnostic”.

How to save a failing project and when to walk away from one?

PMOs and project managers are faced with failing projects more often than they would like to and it often turns out to be a demoralizing experience for all stakeholders. Consequently, it is vital for PMOs to recognize the signs of a failing project and take corrective action before it is too late. In order to engineer a successful turnaround, PMOs and PMs need to watch for certain leading indicators of project failure.

 

Leading indicators of project failure

  • Progressive scope creep:  While some scope changes may be necessary, constant updates to the project scope indicates that the project sponsor and other stakeholders don’t have their business case buttoned up or the assumptions under which the project was sanctioned are no longer valid.
  • High rate of churn in project staff:  It is normal to have long projects to have planned rotation of staff.  However, you need to watch for unplanned attrition from the project team.  Each person who leaves in an unplanned way takes with him/her knowledge of the project.  Areas of the project can be put at risk and the team may need to revisit some past decisions because no one knows why the decision was made.  All this results in extra time and cost with no increase in value.
  • High cash burn rate: Are you tracking your Cost Performance Index (CPI)?  CPI = Earned Value/Actual Cost.  If your CPI is trending less than 1, then you are not using your budget efficiently and are burning through cash.

Reversing the trend (Turning around a failing project)

  • Revisit the scope statement periodically (say once a month) and verify if you are still delivering the same project.  If the nature of the scope change is so drastic that it will potentially change the deliverable, take it up with the project sponsor and decide if the project should be stopped in its current state.
  • Review the staffing situation every month.  Evaluate how many unplanned vs. planned exits have occurred.  If a critical resource or a member of the project leadership team has left, it is a red flag.  Summon a meeting with all stakeholders and the project sponsor to assess the situation and plan to bring in an alternate equally capable resource who is committed to delivering on the project.
  • If your CPI is trending less than one month over month, you are putting the project in a financially unsustainable situation.  You should jump into cost control mode and only approve critical expenses.  If you are buying from an outside vendor, use your purchasing team to negotiate a lowest possible price or do this yourself.

Walking away from a failing project

Pulling the plug on a project that is underway is often not an easy thing to do.  There usually are a lot of personal and political forces at play.   More often than not, people will waste money (and time) in order to justify costs they’ve already spent.  The key here is to maintain objectivity and avoid the Sunk Cost Fallacy.  Meet with your project sponsor and review the costs-benefits of the project and be prepared to justify why the project should be cancelled or stopped.

What is a successful Project Management Office?

This is a question that has been posed many times and answered many times.  Yet, we continue to see PMOs failing very often.  Does it mean that the answers that have been presented are incorrect?  Not necessarily.  In fact, most answers surrounding metrics and value are relevant but don’t address the question of “fit”.  The metrics that make sense for one business may not make sense for another.

At the end of the day it is about demonstrating value to the business as a whole.  A successful PMO is a PMO that is focused on business value and helps the C-suite succeed in its strategic objectives.  Daptiv’s four-part PMO Success Webinar series explores this in more detail.  The goal of the webinar series is to provide real-world insights on how PMOs can become strategic assets to the business.