Tag: Change Management

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

Editor’s Comments

It’s hard to believe that another year is behind us. And what a year it’s been at Project Times. We started out as a quarterly, became a monthly in late spring, and here we are now, coming to you twice a month.

In this issue Chris Vandersluis takes us back to the Cold War in his piece Perk Up for PERT, PERT being an early and successful programmatic approach to project scheduling used in the 50s and early 60s. On a recent visit to Australia, he found PERT alive and well and surmises that it will soon reappear in North America.

Ben Snyder sends us Dispatches from the PM Front Lines with his advice that it makes sense to get back to basics from time to time. He believes it’s especially important when you’re in or near the front lines of the project action. Among other things he discusses the impact of project politics on getting the job done.

Our bloggers are once again offering their take on topical PM subjects. Our discussion forums are ongoing and we hope you’ll contribute.

Finally, we’d like to thank you for joining us during the year and wish you a happy, relaxing and safe holiday. And, of course, a great ’08!