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.

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.

Organizing the Optimal PMO

Organize to fit the work. 

This seems like a simple concept, but whether you’re setting up a new PMO, or expanding/re-organizing an existing PMO, getting the right organization can be daunting. Not only do you need to define the right roles, you also need to think about getting the right people with the best knowledge, skills and abilities to fill those roles.  Here are some thoughts about how you can go about building an optimal PMO organization. 

While there seems to be general agreement that a PMO provides a focal point for projects and project-related processes, practices and tools, there is no cookie-cutter definition of what is PMO is, what it does or who is needed to run it.  PMOs are by nature highly situational; they reflect the unique needs and challenges of their client or parent organization. Needless to say understanding and articulating your PMO’s value proposition and business objects are the critical starting point.  A critical point to remember is that when you start the discussion about organizing, you really need to focus on what you do.

What your PMO does, or needs to do, to meet its objectives and provide value is the key step in translating those too often broad, lofty strategic statements into the tactical, assignable activities that real people need to execute.  It’s very similar to the way we define projects – we start with strategies and business objectives and we end up with defined deliverables, tasks and assignments.

So assuming that you’ve been diligent about defining what you do, here are some thoughts about who you might need to do it.  

PMO Administrators:  Most PMOs are heavily tasked with collecting data, distributing information and coordinating review and governance activities. In a perfect world all of these things would be auto-magical but in the real world someone needs to make them happen.  From sending ‘gentle reminders’ to managers that their reports are due to coordinating calendars and distributing meeting materials, the PMO administrator plays a key role in making sure that the internal processes run smoothly.  The best administrators also play a role in creating and communicating those internal processes across the PMO stakeholder community.  Superior organizational skills, patience, persistence and good people skills are all a must!

PMO Analysts:    There are potentially several different analytical positions and job titles appropriate to a PMO; process analyst, information analyst, tools analyst, business analyst, etc..  So what does an analyst do?  In the PMO context, the analysts are the people who dive into the details:

  • A process analyst defines the individual elements that make a process – what needs to be done and how – and helps in communicating that across the organization.  The process analyst is the person who works with subject matter experts to work through the details of how a process will work, create the process documentation, educate process users and stakeholders about using the processes, and continually improve, update and enhance the process as your organization matures. 
  • Information or reporting analysts determine what kind of data is needed to support decision-making, set up the mechanisms for collecting that data and critically examine the data, turning it into meaningful information can be used by decision makers.  If you ask a really good information analyst a general question about how a particular category of project is performing, you will never get a response of ‘fine’ – you’re more likely to get a dashboard report showing consolidated information on key indicators for that project type. 
  • Tool analysts are the people in your organization who know more than anyone else about the capabilities of the tools you use to manage projects and portfolios.  They can tell you what your tools can and can’t do but they can also get creative and help you use your toolset to craft solutions to your business problems. 
  • Business analysts liaise with your organizational stakeholder community to understand their needs and requirements and help translate these into systems, processes and tools that will meet those needs.  Business analysts work with the stakeholder community continuously to ensure that what is delivered meets the needs and requirements; as such, they play a huge role in ensuring stakeholder satisfaction.

Great  analysts – of any kind – are excellent at open listening and are exceptional  critical-thinkers.  They use details, but they don’t get bogged down in them and can explain their methods and thinking to others.

 

Project Managers:  The great debate is not about what project managers do, but whether they should be centralized in the PMO.  One side argues that because the PMO is responsible for the practice of project management, all project managers should report and/or be accountable to the PMO.  The decentralization side argues that project managers should have a strong working knowledge of the business or technical aspects of projects and should thus report into the functional area executing or sponsoring the project.  PMO’s are concerned about adherence to project management standards, and mitigate risk by having deploying professional project managers.  Functional areas are concerned with the quality of the project deliverables and the need to understand the project’s business and technical issues.

 

The answer is that both sides are right and wrong.  In practice, most successful organizations are those that recognize the need for a mixed model.  Large, complex, cross-functional Programs and Projects require a dedicated manager who can effectively oversee the project across the enterprise.  As a ‘center of practice’ the PMO is the appropriate ‘home’ for these project (or program) managers.  Conversely, a smaller, intra-functional project may not require the same level of project management rigor and could be effectively managed by a functional resource – a ‘project leader’ as opposed to a ‘project manager’.  Using a mixed approach is not without its challenges, but there are also some compensating benefits. 

 

 A key challenge is determining the criteria for which projects require ‘project managers’ vs. ‘project leaders’ , which then need to be applied to during the project intake process.  Those criteria should be focused on risk mitigation, not availability of qualified project managers. Assigning a project leader to a mission-critical project because all the PMO’s project managers are busy invites disaster.  There must also be clear expectations and accountability for things like status reporting – as information generated by project leader is needed by the PMO to provide enterprise-level visibility into projects and portfolios. 

 

Key benefits of centralized project managers include ensuring an adequate level of management for large complex projects, and providing the enterprise as a whole with subject matter experts in project management. These expert PMs can assist in establishing project management processes, educating or assisting others in their use, and increasing the overall project management maturity of the organization.

 

The PMO Manager/Leader:  Last, but not least, we come to the head of the PMO.  In his 1990 Harvard Business Review article, ‘What Leaders Really Do,’ John Kotter asserts that management is fundamentally different from leadership.  According to Kotter good managers deal with complexity by planning and budgeting, organizing and staffing, and controlling and problem solving.  By contrast, leaders cope with change; setting direction, aligning people to that direction, and motivating and inspiring people to keep in the right direction.   

 

The effective PMO manager is both manager and leader. This individual establishes the plan for what the PMO will do, manages the work and the staff and ensures tactical objectives are met.  At the same time the head of the PMO fills the pivotal leadership role for the PMO team and for the practice of project and portfolio management across the organization. While the PMO manager spearheads efforts for creating and maintaining processes to ensure consistent predictable project performance, the PMO leader is continually working across the enterprise to encourage the adoption of those processes and the use of the information they provide.  The effective PMO leader is continuously adapting themselves and the PMO to support the needs of the organization. 

 

In conclusion, setting up and organizing a PMO requires forethought and preparation.  Some things to keep in mind:

  • Understand what your PMO does (and what it doesn’t do)
  • The optimal PMO organization is situational to its environment; no two will be the same.
  • Get the right kind of people to do the right work in support of the PMO mission.
  • Always remember your roles as manager and leader

 

And, of course, organize to fit the work.

What Does The CEO Want From The PMO?

Project Management Offices, and those with an enterprise flavor (or e-PMOs), tend to think they’re all about project portfolio management and project execution and performance. But these topics can sometimes be lost on a CEO as they don’t innately sound like they relate to the company’s vision, strategy, or performance. Thus, when cost-cutting time comes, the PMO looks like one more piece of G&A bureaucracy ripe for the chopping block.

What does a CEO really look for? To a CEO, the company is driving toward a vision – hopefully a compelling vision to the marketplace; a good example is Google’s “Organizing the World’s Information.” That vision translates into strategies to implement and further the vision. Those strategies require changes to be made in the corporation to either implement the strategy or to course-correct. The CEO is more than willing to invest in these changes to help drive the company forward.

Projects, of course, are the main vehicles used to implement change. They aren’t just isolated business cases proposed as pet projects by department heads – they should actually be creating the changes required to drive the company into the future. So, what PMO directors really want to show the CEO is how the PMO helps orchestrate and execute these changes.

First, the PMO needs to ensure that all changes connect to strategic goals and investment priorities. Each change should carry an investment classification – Run, Grow, Transform is a popular model. I like Strategic, Improvement, and Run. It provides a quick justification for the change – we need this change to keep the business running, make it more efficient, or to further corporate strategy. For strategic projects it is important they align with the stated corporate strategies. If not, is it really furthering the vision of the company?

Key PMO Value: Making sure the right changes (projects) are selected

On the orchestration side, the PMO’s involvement with portfolio planning is critical. There are two basic modes: the Annual Operating Plan (AOP) and the funneled intake process. Often, both are employed. The AOP usually emanates from the executive team as a set of strategies and initiatives with proposed funding amounts attached. The PMO’s job is to make sure these initiatives get fleshed out, planned, funded, and finally executed. They are an invaluable resource to the CEO in making sure business plans become reality.

The intake model is more typical and involved, sorting through numerous requests for changes and deciding which to pursue. Here again the PMO is valuable as the facilitator of the process, providing objective information on the alignment and relative value of each request to enable steering committees or executives to make sound business-focused investment decisions.

Either way, if the CEO sees the PMO as effectively aiding the planning of organizational changes they will be in good stead.

Best Practices for Success: Effective Reporting, Performance Metrics

When reporting on execution progress, don’t just group a project list under investment classes or strategies. Do you really think the CEO has time to wade through all that data? There are better ways of reporting progress more suited to the executive suite.

First – they are interested in how much has been invested and the returns from those investments. To highlight the investment side, pie charts dividing the budgets by investment class, strategy, and business unit work really well. Returns are trickier as not all changes result in direct dollars to the bottom line. Some are measured in market share, customer satisfaction, or other non-financial metrics. The key is creating a benefits scoring model that rationalizes the various stats into benefit units. Then report the expected benefit points out per portfolio and follow up – if you can! – with the actual results post-change.

Next up on the CEO’s list – how are the investments faring? Now we’re talking standard project performance metrics, but grouped up to the portfolio level. Budget pie charts of project health (Red, Yellow, Green) work well for a high level view. If they want more info on critical projects the single-page or 4-square status report serves the purpose.

One question frequently asked by the C-Suite is when will these changes hit the organization? The best tool I’ve seen  is the project landing map. This usually has a Gantt bar for the life of the project and milestone markers for only the go-live events. It’s a graphical timeline of change impacts across the enterprise.

If you want to put this all together in a nice neat package for corporate execs the portfolio deck does the trick. I’ve seen this used at Fortune 500 and even Fortune 100 companies at the CEO level to great effect. This is a published (often pdf) document that  starts high level but has more detail in the body for reference if needed. A common format would be:

-          Investment Pie Charts

-          Project Landing Map

-          Portfolio list (not project list) showing budget, actual, variance totals along with average health and average schedule variance.

-          Program list (largest and/or most important programs/projects only) grouped by strategic portfolio with standard health, financial, and schedule status indicators

-          4-square project status reports for all projects listed above

So to give the CEO what they want, think like a CEO instead of a project or portfolio manager. When you’re running a company, you want to know you’ve made the right investments in strategic change and that those investments are paying off.

Are You Agile, Iterative or Hybrid?

By Ian Knox

We see many software teams that describe themselves as agile, but still develop project plans, assign resources to tasks and track time on their project. Agile purists would argue these teams are not truly agile because they are breaking some agile principles, such as encouraging empowered and self-organizing teams, and enabling a responsive, efficient development process. Are these teams agile, traditional iterative, or some hybrid of the two?

The reality is many enterprise software organizations are comfortable with traditional project management techniques, but want to move towards an agile development approach. They are typically engaged in project-driven work versus a software product with an unending feature backlog. They also have to contend with shared resources, such as database administrators, network specialists and architects that may not be assigned to their projects full time.

Many of these organizations are moving from traditional iterative development to a hybrid methodology that incorporates some of the best ideas from agile, but fits with their culture and needs. For instance, they will take to heart the principles in the agile manifesto and introduce practices such as daily stand-up meetings, writing story-based requirements, targeting shorter development cycles and assigning a product owner. In addition, they will modify their traditional milestone-driven development to incorporate more planning and feedback loops to react to inevitable changes in project requirements.

These hybrid agile teams may also model user stories as tasks in a project plan (although they will measure progress in story points vs. task hours). They will work with resource managers to assign shared resources (such as DBAs) to tasks on their project. And they will report back
on progress to executives using standard project management metrics such as percent complete, scheduled finish date and project health.

There are lots of benefits to a hybrid agile methodology and many enterprise software development teams are adopting this approach. Adding agile practices over time is highly recommended so teams can absorb the changes while still delivering on their commitments. For these teams, we also think it’s the best way to get to some of the end goals of the agile movement: a focus on customer satisfaction, frequent software delivery, close co-operation between business people and developers, and creating an empowered culture with motivated individuals.