Tag: Change Management

Project managers, to be effective, must be competent change managers.  Often, projects to introduce new or changed products or processes or to put on an event are planned without appropriately considering the change that the project result will cause in its environment.  Let’s discuss change management (as opposed to the control of changes that occur in scope and other aspects of the project) and see where it fits in the context of project management.

Two Kinds of Change

There are two principle types of change – intentional and unintentional. 

Intentional change is change we make happen.  It is planned and actively managed.  Intentional change is brought about by projects.

Unintentional change is change that seemingly just happens. 

But, nothing just happens.  Everything has a cause under a set of conditions.  The causes may be initiated by others or occur randomly, as in a storm.

One person’s intentional change may, and often does, result in unintentional change for those who are subject to the change’s impact and in the form of unexpected ripple effects.  As an initiator of intentional change you must do your best to predict and be ready to manage the unintentional change that occurs when you change something in a complex organization or environment.  Accept the reality that you cannot completely control and predict the outcome because of the complex interplay among people, processes, organizations, cultures and other factors.  You could say that a big part of risk management is identifying and handling risks of disruption caused by the performance of projects and the delivery of their results.

Change Management

“Change management is a systematic approach to dealing with change, both from the perspective of an organization and on the individual level. A somewhat ambiguous term, change management has at least three different aspects, including: adapting to change, controlling change, and effecting change. A proactive approach to dealing with change is at the core of all three aspects. For an organization, change management means defining and implementing procedures and/or technologies to deal with changes in the business environment and to profit from changing opportunities.”[1]   

Managing change is a project in itself.  Sometimes it is treated as separate project, for example a project to change the attitudes of customers by instituting new customer service procedures or to implement a new process to improve performance.  When projects are seen in this light, it is most likely (though not guaranteed) that the human aspects of change management (avoiding and managing resistance, providing time for the acceptance and integration of the new into the existing environment, etc.) will be integrated into the project. 

However, we see many technology and product development projects and even process change projects that do not fully address change management issues.  For example, consider a project, initiated by a business or government agency organization to implement a technology innovation (a new and improved computer based system).  The project is viewed as an IT project and as such put under the management of an IT project manager with the charter to deliver the new system.  To her the new system is basically the software and maybe some user documentation.

In a healthy situation, this project would be a sub project within the broader project or program to improve the organization’s performance.  Ideally there would be a competent PM at the higher level to whom the IT PM reports or at least must coordinate with.  The higher level project or program plan would include the IT sub-project plan and would address the change management issues.  It would ensure that there was coordination between the IT project and the related business projects (developing business processes, communicating, training, etc.) and that there was a risk analysis regarding the change impact of the implementation on the environment and its people.

In an unhealthy situation, and I have seen and heard of many, there may be nothing more than lip service regarding the implementation and the change it implies.  Sometimes business leadership and IT leadership as well, act as if they believe that there is some magical process that will cause the new system to appear and be immediately integrated into the existing environment. 

As PM’s you have the responsibility to look at your project realistically in the broader context of the organization and to advise business leadership of the need to ensure that change is managed appropriately to ensure the delivery of the benefits that justified the project’s initiation.  If you do not, you run the risk of delivering a lovely product that is never used or never reaches its potential.  That means your project will be considered a failure.

Become a competent change manager.

Don’t forget to leave your comments below.

In my previous blog, I listed and explained briefly what needed to be elevated to ensure we used correctly the main constraint of organisational/cultural change projects, namely the capacity and will to change of the humans involved in and/or impacted by such projects. In this blog entry and at least the four others to come, I will discuss the different means of elevating the “capacity” part of this constraint.

In my last blog entry, among possible means to elevate capacity, I identified at least four. Three were related to better managing knowledge issues: the know what, the know what to do and the know how to do. The fourth one was related to better managing resource availability issues, including human resources, monetary resources, physical resources, as well as time resources.

I will tackle the resource availability issues of organisational/cultural change projects in this and the next blog entry. Those issues are not that different from those on other types of projects. They are also often presented as the main subject around which revolves TOC[¹] when applied to project management. So before going too far discussing those, I believe we have to revisit what has been written about TOC-Project Management by the principal person concerned, Eliyahu M. Goldratt. So this is what I will do today.

Most people aware of Goldratt’s book Critical Chain [²], but who are not really using in real life the principles laid out there (as I was myself guilty of for a long time), believe that TOC-Project Management is only about paying more attention to project resources by:

• identifying them properly, and
• managing them more realistically through the setting-up, tracking and protecting of buffers.

In a not too distant past life, I myself stated many times that the critical chain was our traditional critical path including resource constraints and availabilities into it….and that, consequently, the critical chain was always longer than the critical path. This is a very reducing view of what Goldratt wrote and promotes, a view shared, alas,by many project managers. It is also a view shared by many critical chain project management software providers, who added buffer management functionalities to the usual CPM [³] scheduling algorithms used in traditional PM software packages…and then called it a day!

In fact, what I am currently trying to discuss here in these blog entries, about organisational/cultural change constraints, is also discussed in Goldratt’s writings: those writings go beyond simple resources availability issues to also cover behavioural as well as buy-in (associated with the will to change) issues, among others. I am just trying here to put those writings in a different perspective, in order to apply them specifically to organisational/cultural change projects. I really believe that my main contribution here will be to clarify misconceptions about TOC as it applies to project management, as well as (maybe) add some original proposals to elevate buy-in to the level required to accelerate and succeed the realisation of organisational/cultural change projects.

For now, to make sure we all have the same understanding of TOC-Project Management, I would rather like to let the master and his direct followers speak for themselves. I thus invite you to read or read again Goldratt’s business novel, Critical Chain (as I will do again myself) and/or peruse the new version (2009) of the Goldratt Institute’s very complete white paper introducing Theory of Constraints Project Management [⁴]. Once you have done so, please feel free to comment here about what you found in those readings that talks about other things than simple resource availability issues.

In the next blog entry, I will (at last) share my vision on what are those simple resource availability issues and how to deal with them.

Stay tuned !

I recently gave a conference in France on “Changeboxing”. This is an approach, based on timeboxing and emerging organizational change techniques that I developed to help client organizations accelerate the implementation of new project-oriented management processes (project, program and/or portfolio management). The approach considers that “major” cultural changes are associated with implementing these processes and proposes collaborative ways to get people to agree rapidly on how, when and what they will change.

The conference I gave aimed at explaining what were “major” changes, (often also called “transformational” changes), and at demonstrating that Changeboxing could accelerate those changes. But while preparing my arguments for the conference, I eventually got very confused, because I could really not pinpoint exactly if a given change was or was not a major or transformational change.

In my readings, I found out that “a transformational change implies a loss of original identity (purpose, values, beliefs); it is a significant alteration or disruption in peoples’ expectation patterns”. Wow! So people do not get what they expect any more and the change they see around them put in question their current values, their beliefs and even their very purpose in life. So this is very big stuff happening! I also found out in my readings that “transformation” was different from a normal “small” change in the following manner:

1. It goes on inside a person, not outside…..well how can we say that? What goes on outside has surely some effect on the inside of a person, those are not mutually exclusive.
2. It takes much longer…..sure, because it questions your identity, something you have lived with for a long, long time before this change.
3. It starts with an ending…..sure, the ending of your status quo and the disappearance of your current comfort zone.
4. It finishes with a new beginning…..let’s hope you end up at a better place than where you were at the start.I if not, why would anyone desire this change?
5. In between is a neutral zone…..basically saying that we have no clue about when and how this is going to happen, because how someone with react to a major change and accept it, if not desire it, is quite unforeseeable.
6. Transformational processes apply to organizations as well as individuals.

The sixth point was the one that really made me understand why I had such a hard time discriminating between major and minor changes. It’s bcause it really depends on perceptions and on who is being affected by the change. The same change might appear minor for an individual but it will impact the organisation s/he works for in a big way and vice versa.

I remember a presentation made by the communications specialist working on a major capital project from Hydro Quebec. In a given situation, she found out that “skidoo” roads were a very important matter for some people in Northern Quebec. Before she spoke to them, neither she, nor Hydro Quebec thought that changing the path of one of these roads was a big deal. After talking to those people, the urbanite that she was just realised she was changing something that people had been doing for generations, that this was a major transformation of their habits.

It is also the same for the two last survivors of a close-to-be-extinct species of frog in a small pond that we will dry out to build a new road. What are two frogs, anyway? Well, for the two frogs, this is of paramount importance and their dismissal is a major change to them!!!

So next time you want to know if the project you are about to realise involves a small or a major/transformational change, you do not need to look too far for an answer. The answer is always that your project implies a major change for one or many people having a stake in this project. There are no small changes, when it comes to the person who will experience this change, often without being asked. Your project will always include a major change for someone. In this respect, change management on a project is always required.

Last month’s blog discussed the project manager’s role in sharing PM knowledge with stakeholders as a means for creating an organic learning process. This month I will opine about the broader issue of knowledge management in the realm of project management.

PM Learning Historical Perspective

Before the 1990s most project managers were trained on the job through a combination of coaching and self discovery. The very largest projects, particularly in aerospace, engineering and construction used “professional” PM methods. Out of this experience has grown a cadre of professional PMs and practitioners who have evolved Agile and other approaches to managing projects to improve the probability of project success.

Knowledge management is an integral part of project management (KM). The knowledge consists of information about current performance (e.g., status reports, risk registers, etc.), information about the process (e.g., methodologies, best practices, tutorials, etc.) and information on past performance (e.g., estimating data bases, project archives, etc.)

Process Learning

The process information is at the heart of performance improvement. In the past, the principle approach here has been formal training and relatively rigid methodologies. This is changing and hopefully changing quickly. Would-be project managers can learn the basics with self paced courses but can only learn the realities in practical, well facilitated workshops and through ongoing dialogues with their peers and experts in the field.

Advanced PM

Advanced PM training has been pretty much a joke, with training providers offering up academic courses in the various areas of knowledge. How many PMs actually need an advanced risk course? Advanced learning in PM is about application, not academics. We need workshops and coaching blended with self-paced options for academic information and just-in-time sharing for best practices and specific how-to’s.

Knowledge management is the discipline that seeks to find the best way to share knowledge in the organization. Learning and development is a significant part of KM but certainly not the whole. KM is the realm of taxonomies to organize knowledge, technologies to collect and distribute knowledge and support social computing, and governance, editing and filtering to make sure the knowledge being shared is accurate and relevant and being used.

Consciously engineered KM reduces the burden on the PM to educate everyone on PM benefits, principles and responsibilities. The PM is still responsible for creating and maintaining a learning environment in his/her project but this is far easier when there is an organization-wide structure in place, supported by effective content.

What are you doing to integrate KM into your PM process?

Don’t forget to leave your comments

Overview of the Challenge

What approach should be taken by a PMO to successfully introduce new processes and tools and have them accepted by the client group?

Research Findings

Generally, the by-product of a mandated change is an atmosphere of uncertainty, anxiety and even suspicion. The corporate culture resists being changed and that can both hinder productivity and render those tasked with integration less than effective.

My research and experience is based on what occurred when changes were required to document and integrate a manual which captured procedures and processes in order to perform tasks within a standard set of measurable parameters.

Previously, work was performed by qualified staff, but it lacked the rigour and discipline of standardization. An operational business model was required to meet the expectations of the customer (stakeholder) and to provide staff doing the work with an instructional manual.

Approach and Tools

Based on the PMI project life cycle (what you need to do the work) and the project management process (what you need to do to manage the project) the steps that followed were:

Initiating Process
The needs of the organization were determined, a project manager selected, existing systems, processes and historical information were reviewed. Stakeholders were identified, objectives determined, assumptions and constraints documented and a charter and preliminary scope statement developed.

Planning Process
The planning approach was determined. A finalized scope statement created and a team determined. Work and workflow (WBS, activity lists, network diagram, resources) were determined along with time and cost estimates. A schedule and budget developed and quality, standards, roles and responsibilities determined. Communication requirements, risks, procurements, process improvement plans, measurement baselines, approvals gained and a kick-off meeting held.

Executing Process
The team was acquired. Scope completed, information distributed and received, continuous improvement followed, team building and team management recognition done, selection of vendors determined.

Monitoring and Controlling
Measurements against performance baselines and plans conducted. Variances addressed. Scope verified and recommendations for changes applied following change control methods. Risks addressed and issue logs maintained. Each team member’s performance was measured and reported on. Administrative contracts maintained.

Closing
Closure procedures developed. Contracts closed. Confirmation that work was done to requirement and formal acceptance of product obtained. Performance reporting completed and archiving done. Lessons learned conducted and documented. Hand-off of product done and resources released.

And most of the time was spent planning.

Implementation Approach, Results Achieved and Lessons Learned

Although a comprehensive, easy to use, approved and accepted instructional manual was the end product – the experience and knowledge obtained through managing the change and integration of the product provided great insight for the project team (and project manager). Below are some of the challenges, lessons learned and resolution strategies that were applied.

Deciding Not to Change is Not an Option
Meet with the Resisters. Understand the ‘Why’ behind these people. Explain the “what’s-in-it-for-me” part. Listen and be supportive. Encourage, communicate frequently, let them vent. Introduce them to a Change Champion (a Power User who is your advocate).

Change Champions
These people understand the benefits and have the attitude of “I’ll make this work for me”. Keep these people close. Reward and recognize them. They’ll become loyal followers.

MBWA
Management By Walking Around. Talk to those in the trenches, be seen, understand their needs, feel their pain. Once they get to know you, they’ll become more comfortable. You’ll have a chance to stress the goals and the direction of project.

Pizza
The single, most powerful change management tool! If you feed them, they will come. Conduct lunch and learn sessions. This informal setting offers a great forum to educate the users aside from the regular training sessions.

BLOG/Communicate
Keep communication clear and concise. But always communicate. Be honest. Address all issues ASAP – the good, the bad and the ugly. Especially the bad and the ugly! Keep an on-going issue log. Let the clients see the progress, and that you actually care about their issues and are working on a fix for them.

Your Dysfunctional Family
Do you have the right project team in place to deliver the project? Everyone brings something exciting to the party. However do you have the correct combination to successfully implement the project? A square peg in a round hole just causes grief for everyone. Make a change of staff if you need to. Everyone wins then.

How Good Are We?
You can’t manage what you can’t measure. Determine your success criteria and aim to meet or exceed it. Track your progress. Celebrate your successes with the team.

Become Roommates
Ensure your objective is not to ‘Cut and Run’. After change and integration, remain with the clients at their location, even if it’s just for a few hours. If there are problems or concerns, you are there to provide assistance or refer the problem up the line. Don’t walk out, leaving them resentful, at a loss and with no one to contact. Not only will it impact their daily work but also your reputation.

What does the PMO have to do to be Successful? Setting up for Success!

Make sure the odds are in your favour. Do what you need to and ensure you tip the scale so the odds for success are on your side.

1. Listen very carefully to management. You can give them what they ask for, but is it what they really want/need?
2. Be an expert – not a know-it-all, but a trained professional. Seek out the training you and the team need to accomplish the project.
3. Keep your promises. You committed to a budget, schedule and staff development. Deliver!
4. Never compromise your integrity. Ever!
5. The greatest motivation act one person can do for another, is to listen. This applies to both your team and your clients.
6. If you can laugh together, you can work together. Enjoy your work in project management and the people you work with. It will make life a whole lot simpler and less stressful.

And trust me on the pizza!!

---

Donna M. Ulrich, PMP has over 25 years of project management (in various capacities within projects) and consultant (owner of Cougar Management Consulting Corporation) experience, with the proven skills to deliver all aspects of projects, including strategic planning, staff management, training/development, process improvement, change management and customer satisfaction within the nuclear, telecommunications, IT, service/utilities, financial and healthcare industry. When not managing projects, Donna enjoys kayaking, reading, movies, theatre and travelling. Her favourite activity though, is being with her daughter Samantha, and Noah – the wonder-dog! Donna can be reached at [email protected]

2008, Donna M. Ulrich, PMP