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. 

Introducing and Setting Up a Project Management Office

In my last article we delved into organizational maturity for setting up a PMO; this article will deep dive into how to introduce a PMO without disrupting the established system. The first step is good communication–clear and complete information reduces confusion and eliminates resistance based on fear and conjecture.

Communicate the mission, objectives and purpose of the PMO. Be open and transparent regarding the decisions and activities of the PMO. Inform the enterprise of the reason(s) the PMO exists, what it will do and how it will bring value to the enterprise. Also, demonstrate how the PMO will be a partner and not a hindrance in working toward the success of everyone in the enterprise.

Once the need to set up a PMO has been identified and the communication campaign is actively underway, the PMO must be designed from the beginning to meet the specific needs and environment of the business it supports. Project Management Offices take on many roles depending on their mission and objective, hence setting up a PMO is not a short-term activity. It requires significant effort to complete analysis, design, planning, review and implementation. Cooperation and involvement from the business is essential to ensure the PMO meets their needs. Involving the business early and often by keeping open communication channels and soliciting feedback will allow you to manage expectations regarding the amount of time and effort required to set up a PMO.

Setting the priorities of the PMO
In order to move ahead with the planning process, the business should first set the priorities of the deliverables and services of the PMO. Next, assemble a planning and implementation team that includes stakeholders in addition to the PMO subject matter experts. In my opinion, business stakeholders must be involved throughout this process to analyze and take ownership of business needs and progress. On the planning side, it should be phased out, using a rolling wave approach as opposed to a “big bang” approach. These phases should be scheduled out using the roadmap model with detailed planning occurring at the initiation of each phase. This makes the planning current and more relevant to the prevailing business condition.

Laying down project management processes
The next major task is to identify processes and tools required to support the services and functions the PMO will perform. Depending on business needs and budget, an organization may either develop in-house tools or purchase tools from vendors to help streamline projects. Project management processes should be designed to guide the project managers in the performance of the project. PM processes need to be adaptable to meet the needs of any project. A simple project with little risk may require a very light application of the process, whereas a complex project or a project with high levels of risk will necessarily require a more rigorous process.

Project management processes are generally based on standards or best practices such as PMI’s Project Management Body of Knowledge (PMBOK), PRINCE2 and agile. In addition to general purpose standards, organizations may also require and benefit from specialized project management best practices such as process improvement (Six Sigma), new product development and Go-To-Market.

Project Portfolio Management (PPM) is another function often found in PMOs. Organizations turn to PPM to manage their entire portfolio of projects, much like a portfolio of investments. In fact, projects are investments and companies expect to get the maximum return and benefit from these investments. PPM is the process by which they achieve this. Through project selection, project mix evaluation, portfolio monitoring and other activities, PPM is used to maximize returns on the portfolio.

Resource management (RM) often becomes the responsibility of the PMO because it is a natural partner with project management and project portfolio management. Within every organization there is a finite supply of resource types–including people, financial, and physical assets. Resource constraints affect both project work and operational work, the normal day-to-day work of the business. Accordingly, resource management processes should track the operational work (the day-to-day activities) in addition to project-specific work being done by the business in order to paint a complete picture of the total capacity or work an organization can truly deliver.

It is evident that these PMO functions are integrated and integral to the success of an organization. While organizations can adopt some of these elements, ultimately an organization needs to implement each of these disciplines to some degree to manage its program office effectively, even if they are being managed at different degrees of maturity. The project portfolio lifecycle encompasses elements of the project management process, the resource management process and financial management.

Keeping the PMO Relevant
To complete the whole cycle of project implementation and as part of a continuous improvement program, regular feedback from teams/project managers will help maintain the efficacy of the PMO at all times. It’s helpful to develop a continuous improvement program that includes:

  • Periodic reviews of the PMO objectives against the needs of the business
  • Measurements of the processes and tools such as effectiveness, adoption and consistent use
  • Identify areas for improvement

In the end, be sure to give new processes and tools time to be used long enough to overcome learning curves and to gather enough feedback and data to be able to make well-informed decisions. By their very nature, program management office teams are change agents. They institute new processes, implement new tools and may bring about changes in the way organizations conduct business. When planning for organizational change, the PMO must create conditions for change. Be aware of the politics of the organization, and build a base of support for change within the organization.

The third and final part of this series will touch upon metrics and how to measure success of PMO.

The Future of Project Portfolio Management – Perspectives from the Gartner PPM Summit

Gartner gave us an interesting look into the future of PPM this week, and projects as we know them may be left behind. I’ve been wondering about this for some time, as the pace of business continues to accelerate and business changes – represented by projects – are called on to deliver results faster and more frequently. But I’m getting ahead of myself.

Let’s rewind from projects back up the business stack for a clearer view. Gartner did this nicely from their opening keynote through their multitude of breakout sessions – many of which were standing room only. In this note I can only summarize the model, but I will delve more deeply into each area in future posts.

First, we must remember why we execute projects – to implement change in the business. Be it incremental improvements in efficiencies enabled by minor software enhancements, or transformational change in the form of a merger – projects have been our vehicle. Gartner rightly points out that the pace of this change is accelerating to the point where it is almost constant. Can the old annual planning cycles and waterfall projects really keep up with this pace?

Most projects today involve changes to some application system, as IT has become thoroughly embedded in most modern enterprises.  Techniques like Agile can continuously release improvements to these applications, taking in ideas for change and working them into a continuously prioritized stream of stories. And these stories – which represent useful business changes – can be released frequently. We are now talking weeks or months to roll out changes to applications, instead of years.

How to manage all those applications? Enter Application Portfolio Management. Much like managing a portfolio of projects, APM rationalizes and prioritizes applications. Andy Kyte (VP & Gartner Fellow) gave a dynamic presentation on APM for Executives that boiled this concept down to some simple truths. He reminded us that applications are really means to an end – business value. Using that as the goal enables us to make decisions not only about which apps should stay and which should go, but where they should reside. Do we really need all those systems in house, or would a SaaS or even a BPO model provide the desired business outcomes more efficiently?

This brings us to the top of the stack – business value. IT systems do not in and of themselves provide any value at all. So what does IT really provide? Business Capabilities! And here Gartner sounded an interesting new theme. Instead of seeing capabilities as just part of the EA stack, consider these like products. A SaaS shop like Daptiv, of course, delivers PPM capabilities as a product – and we see it that way. IT shops should consider that they are really delivering products like Purchasing Management, Workforce Management, and Strategic Sourcing. Viewing these as products allows IT to focus their efforts on delivering business value rather than just technology.

So now we see the full model being proposed by Gartner. It really uses some tried and true techniques from Enterprise Architecture and adds a few twists. We start with business capabilities at the top, which are now enabled by IT products – apps and supporting infrastructure to enable those capabilities. And we move away from simple application and project management to product management. And now that we have products to support, we implement a continuous change cycle – such as Agile – to ensure changes to the business outcome driven capabilities are implemented quickly and frequently.

The current pace of business is such that the old model has lost its usefulness and would leave us eating someone else’s competitive dust.

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.

Improving Adoption and Usage of PPM in Your Enterprise

What makes a Project Portfolio Management solution deployment successful?  A great deal of hard work?  Definitely.  But there are some other ingredients in that “special sauce” that makes your PPM deployment succeed.  Let’s explore.

A few years ago Jack Welsh of GE fame led a keynote speech on large programs.  He was presenting to the business leaders of some of the largest enterprises in the world.  The speech began something like this:

“If you can’t get top management to support your program, don’t even bother.  Don’t even waste your time.”

Why did Jack say that?  Because to him, adoption of the program and solution is so important that a both are doomed to fail without that top level support – all the way from the top to the bottom.  You can spend an extraordinary amount of time, effort and financial resources around setting up a program, developing a methodology and implementing your PPM solution but without the team being ‘on board’ with your solution you will have a very difficult time succeeding.

Once we can secure an executive sponsor, and have them attend the kick-off, and elaborate why the initiative is so important, what’s next?  The next step is to make sure your solution takes advantage of a very simple setting – allowing project managers to ‘align’ their project with one of a limited number of corporate initiatives.  This simple step will serve two purposes;  it will enable the project manager to understand where their project fits (and more importantly, how it contributes) to the company’s goals as well as act as an indicator to tell the PMO and executive committee which projects are going “rogue” – those which are not aligned to any goals or objective.  One of the best examples that come to mind comes from the early 1960’s, before man landed on the moon, when President John F. Kennedy was touring the NASA Manned Spacecraft Center.  A humble and down to earth leader, JFK encountered a janitor as he was being guided through the facility.  He stopped the entourage and approached the janitor and asked him what he does there.  The janitor replied: “I’m putting a man on the moon.”  Surely he knew he wasn’t directly flying an astronaut to the moon, nor did the director of the space agency tell him to answer that way if the president asks.  No.  The mission of the center was so clear from the very top to the very bottom that every single person knew what their contributions were working towards.

Next idea has to do with appreciation for the stakeholders and user community.  A solution’s adoption is most successful when everyone is able to contribute to its design and change.  It is essential for the PPM Steering Committee (the team who manages the solution’s use and configuration) needs to capture end user feedback in order for the solution to evolve and grow with the program.  Why is this so essential?  Simply because when we set out to design the program, we may not have taken everyone’s perspective into account.  We may also not have thought about how each role would interact.  But more importantly, you increase the chances of success by casting your feedback “net” as broadly as possible.  There’s an old story that helps demonstrate this idea.  On some highway, a trucker is driving his semi.  He approaches a bridge with a sign that warns of 13’ of clearance.  Thinking he can fit, he continues onward only to hear the sound of crushing metal and his truck quickly stopped.  He gets out of his rig and finds his trailer wedged under the overpass with no easy way to get out.  The state police are called followed by the civil engineer.  Bridge plans are reviewed and a crowd starts to gather.  A little girl walks up to the engineer and says “mister, why don’t you just take the air out of the truck’s tires?”  The truck is lowered and is now able to roll out.  Sometimes the best ideas come from the strangest places.  But even more important, one of the people in the community was able to share an idea that had a direct impact on solving a problem, creating a positive environment across the entire community.

Of course, there are many other aspects to user adoption of your PPM solution, but getting the support from the entire organization, from the top to the bottom, is essential to the success of your continued deployment.