Skip to main content

Author: Claude Emond

Velocity Part 2; Identifying the Limiting Constraint of Cultural Change Projects

Written by Claude Emond on . Posted in Articles. 1 Comment on Velocity Part 2; Identifying the Limiting Constraint of Cultural Change Projects

A while ago, I wrote a blog entry to introduce briefly the contents of the Goldratt Institute’s new business novel Velocity: Combining Lean, Six Sigma and the Theory of Constraints to Achieve Breakthrough Performance1. I did this with the intention of writing later about how I could apply the principles laid out in the novel to the management of projects involving cultural changes, like the implementation of enterprise-wide project management processes. So this is my first shot at it: “identifying the constraint of a cultural change process in order to work on it”.

From reading “Velocity” (about how to optimize continuous improvement), a logical sequel to “the Goal”2 (about how to optimize recurring operations management) and “Critical Change”3 (about how to optimize project management), one can understand that identifying the limiting constraint in a process and working to elevate it (increasing the throughput of this bottleneck) is the key to improved performance. Then, in order to improve the performance of any process (be it temporary or permanent) we put in place to foster/promote/support/accompany a cultural change project, one has to identify the limiting constraint(s) of such an endeavour.

In early 2007, I started working on implementing a project portfolio management process with the Société de Transport de Montreal4. I told the project sponsor at the time, Sylvain Gonthier, a Human Resources Management specialist and then the deputy general manager of the organisation, that this implementation implied a change in the culture of the organisation, a major move towards a highly collaborative environment. His first reaction was to say that it would be a huge challenge since “we can not decide either what, how, how much, or when other people will change individually or collectively to fit a new culture”; we could not even decide what would be the nature of this new culture, because “we cannot direct cultural change, it will emerge IF IT HAS TO”. Since that day, I have pondered very often on what Sylvain told me then, as I saw this piece of wisdom materialize often through good and bad outcomes in all the project management process implementation projects of my clients and of other organisations.

So, clearly the limiting constraint of a cultural change management process has to do with the people living this change. If we want such a project to succeed, we need to act on what those people want or are ready to change, how much they are willing to change, how and which steps they will agree to follow to make this change both individually and collectively, as well as when they will make this change materialize. The limiting constraint in a project involving cultural change is “the capability and the desire to change of the people “invited” to change their individual and/or collective beliefs, values and the resulting culture”.

I further believe that this constraint, “the capacity and the will to change”, is the same on any project requiring major change management…so on all projects, since, as I wrote in my previous blog entry5, there is always someone within a project who will experience a major change in one way or another.

Now that the limiting constraint of cultural change projects has been identified, how do we “elevate” it? This will be discussed in future blog entries.

1 http://www.projecttimes.com/claude-emond/velocity-part-1-introduction.html
2 http://en.wikipedia.org/wiki/The_Goal
3 http://en.wikipedia.org/wiki/Critical_Chain_%28novel%29
4 http://www.stm.info/English/a-somm.htm
5 http://www.projecttimes.com/claude-emond/what-is-a-major-change.html

Don’t forget to leave your comments below

What is a major change?

Written by Claude Emond on . Posted in Articles. 5 Comments on What is a major change?

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.

Don’t forget to leave your comments below

The Tale of the Bow; Learning from Gabriel

Written by Claude Emond on . Posted in Articles. 7 Comments on The Tale of the Bow; Learning from Gabriel

I use an “erhu” (the two-string Chinese violin) as a training aid in coaching project management to workshop participants. I started to do this while giving PMP certification revision workshops for PMI-Montreal. This is something I have been doing now for more than four years. I have also published a little website on this, in collaboration with Prof Xianghui Liu, a Chinese university professor I met on MySpace [i].

I am spending eight to nine9 hours with PMP certification candidates. I give them the run on the Project Quality Management knowledge area. I also review all other eight areas (seen in other workshops) through 150 to 200 presentation slides, while trying to talk about exam preparation and to share my project management experience and some useful insights complementing the PMBoK.  I also have them go through a 100 question PMP exam simulation, including revising it with them before the day ends. This is a crazy day; so the erhu comes handy to create anchor points to make them remember something useful, as I try to find with them the nine sets of “two strings” that can explain how to best manage each of the knowledge areas.

When I discuss the overall “two strings” of global project management, the best practices string (knowing how-to-do) and the best behaviours string (knowing how-to-be), I usually go on with a story praising the high value of a project team, particularly if it is composed of very different people (both technically and perception-wise) instead of clones. To give an example of the value of diversity, I tell of something that happened to me in a workshop, some three years ago, when a learner of project management made a comment that made me grow beyond my paradigms. Here is this story, “The Tale of the Bow: Learning from Gabriel”, as I recount it to my workshops now, after I play the erhu for the first time to the participants:

I had just finished explaining the two-strings of project management (best practices/best behaviours) when one of the participants in the workshop asked me this question, with a strong Spanish accent: “Mr. Emond, I understand about the two-strings, but what is the significance of the bow?” One has to understand that the horsetail hair used to make the bow of the erhu is stuck in the space between the two erhu strings, so only one string is played at a time. To play a tune, one has to switch between the two strings, pushing or pulling on the bow’s hair.

It was the first time someone was asking me this question, although I had already been using the erhu as a project management training aid in front of hundreds of workshop participants. I was quite taken aback and, to this day, I believe that this man asked me this question because he was so different from all the other students I had trained before. He was from Argentina, and had been in Canada for less than two years, still struggling with the language and the culture. Because he was different from me and from all the others I had taught up to now, he asked a question I had never asked myself. He also gave me the answer to it, an answer which made me become a better project manager and coach.

Before this question was asked, I had come to believe that seeking the best behaviours in a project team (collaboration, respect, humility, helping each other, telling the truth, being committed, etc.) was far better than wasting one’s time implementing best practices; after 20 years as a project management specialist, I had given up on best practices because they had failed me and my clients so many times. I also thought that I had it made with the erhu and that, besides its two strings, there was nothing else in this instrument that could speak on project management. So when this man asked me this question, “what about the bow?” I was a bit annoyed at myself for not having an answer. I asked him to give his own answer to it! He thus proceeded and told me something that changed my vision on project management. He told me: “If I understand you, Mr. Emond (I was now burning in anticipation to know what he understood from me that I did not even understand myself!), if I understand you well, the bow is the integrator…the bow is the project manager…the project manager who has to always find the right mix of best practices and best behaviours to get the most of both worlds”

As he said this, the simple truth of it just struck me like lighting and my erring project manager soul was at last saved. This was the most profound insight I got on project management in many years. It came from one of my workshop participants, a man who came there to learn from me and who, because he was different from me, showed me a new road and made me grow as I started my journey on it. To this day, I am still journeying on this road and I am still learning while doing so.

After I told this story to some PMP certification workshop participants last February, a man came to me during the morning break. He extended his hand to shake mine as he presented himself this way: “Hello Mr. Emond, I am Gabriel, I am your Argentinean!” He told me he had come to Canada with his PhD in Biochemistry to work in this field. Since the day he learned “simultaneously” with me about this profession where one person, like a erhu’s bow, can get the best from his fellow project journeyers through seeking the best balance between brain and soul, he wanted to become a project manager. This goal brought him back to me, three years later, as he is now working to become a certified PMP. We finally met again on this road he inspired me to follow.

Thank you Gabriel!

[i] http://2-stringprojectmanagement.blogspot.com/  (English) and http://2-spm.blogspot.com/ (Mandarin Chinese)

Don’t forget to leave your comments below

Velocity. Part 1- Introduction

Written by Claude Emond on . Posted in Articles. 3 Comments on Velocity. Part 1- Introduction

E.M. Goldratt is quite well known for his “Theory of Constraints” (TOC) approach, largely popularized through two business novels: “The Goal” which introduced TOC to the world of recurring operations management and “Critical Chain”, which did the same for the world of project management.  Goldratt and his followers have done it again! This time for the world of continuous improvement management. In the brand new business novel, “Velocity” [1], Dee Jacob , Suzan Bergland, from the AGI-Goldratt Institute and Jeff Cox, one of the co-authors of “The Goal”, have put together a story telling about realizing rapid and significant continuous improvement results through integrating three approaches: TOC, LEAN and Six Sigma. They call this TOCLSS. Workshops and conferences promoting Velocity and TOCLSS are popping already all over the place.

The idea the novel tries to convey is that “improving everything is not the same as everything improving”, that most traditional continuous improvement ventures, including improving project management maturity, are bound to fail. Most of these approaches try to improve everything at the same time and result in very small improvement, because much effort is spent on improving things that will generate very small value, things that are simply not constraints. So LEAN, Six-Sigma and the like do not produce good results if applied without taking care of real organisational constraints. And since those constraints or bottlenecks are not well identified in most organisations, traditional approaches have us working very hard to achieve almost no improvements.

I had only finished reading the introduction to the novel and I already wanted to know more about the basics of TOCLSS. I was realizing that I was intuitively applying some of these elements with my clients in improving their project-based management processes; TOCLSS could give me a complementary model to both explain and improve my own approach to continuous improvement in the world of project management. I decided to “google” the thing. Well, I found that TOCLSS was already quite discussed on the Internet and had been preceded by a very similar integrated approach, TLS (standing for the same three things as TOCLSS). This integrated approach is even trademarked as iTLS ™ (for which an official certification exists) when applied in this specific sequence[2]:

  1. Apply TOC to focus on what needs to be fixed (focus on bottleneck)
  2. Apply Lean to eliminate waste (focus on value) 
  3. Apply Six Sigma to optimize process variability and error (focus on quality variability)

I also found a major article by R. M. Pirasteh and K. S. Farah[3] that summarizes the results of a study made in a large manufacturing company, on a vast continuous improvement program that covered 21 different plants.  This study involved over 200 continuous improvement team leaders, working on 101 different continuous improvement projects over a 2-year period:

  • 11 plants applied a Six Sigma approach – these 11 plants (52%) contributed only 7% of the total savings of the program
  • 4 plants applied a LEAN approach – these 4 plants (19%) contributed 4% of the total savings of the program
  • 6 plants applied TLS – these 6 plants (29%) contributed the most, 89% of the total savings of the program

Those are very significant results to support “constraint-based” improvement programs. I see how this can also be applied to project management processes improvement, with an adjustment to take into account adaptability, something I will talk about in my next blog. I find that I have a lot of pondering to do about achieving “Velocity” through TLS and how we can accelerate project management processes improvement by adapting TLS to the project world.

This is a major breakthrough, that has been going on for at least the last four years. Was I the only one of us sleeping through the birth of TLS? About time I woke up to Velocity!

[1] “Velocity: Combining Lean, Six Sigma and the Theory of Constraints to Achieve Breakthrough Performance – A Business Novel”, Dee Jacob , Suzan Bergland, Jeff Cox, Free Press, January 2010
[2] http://en.wikipedia.org/wiki/TOC_Lean_Six_Sigma
[3] “Continuous Improvement Trio – The top elements of TOC, lean, and six sigma(TLS) make beautiful music together”, REZA M. PIRASTEH and KIMBERLY S. FARAH, APICS Magazine, May 2006, https://www.projecttimes.com/wp-content/uploads/attachments/TOCLEANand6sigma.pdf   

Don’t forget to leave your comments below

Exercising Necessary Project Leadership When the Time Comes

Written by Claude Emond on . Posted in Articles. 8 Comments on Exercising Necessary Project Leadership When the Time Comes

Most of the projects I am involved with nowadays are organisational change projects, many related to the implementation of a true project management culture and all its relevant processes, behaviours and tools.

I use a “user-centric”, self-organizing, collaborative approach I call “changeboxing”, that I developed specifically for these types of projects. It is a mixture of agile project management “timeboxing” techniques and collaborative implementation approaches. It is based on voluntary work by concerned stakeholders of projects in an organisation, following an internal diagnosis where these stakeholders identify and confirm the organisational change they desire, and then work together to make it happen.

More often than not, the approach works quite well and accelerates new processes’ implementation and integration in the day-to-day life of the organisation they serve to improve. To succeed, however, the whole change process must be based on a real desire to change and to collaborate as a team towards the new project management culture…and complete transparency and trust among stakeholders. I have been coaching customers through this “changeboxing” approach to organisational change for five years now. When we have run into difficulties and the approach failed to deliver the expected harmonious change, it was always because a group of stakeholders were not sincere and would try to manipulate the others in preserving THEIR status quo. When such a roadblock appears, I really expect that upper management, as the sponsor/client of the changes, will take on its traditional role as the legitimate ultimate organisational authority. It must give a precise indication of its expectations, give clear direction and then just do what it’s supposed to do: DIRECT. This might look like a very rigid approach from “agile” me. Maybe! My belief is that exercising Situational Leadership [1] is an agile approach and that the S1 alternative (directing and telling) is quite a valid alternative when the context calls for it.

Alas, in all instances when such a roadblock appeared, none of the chief executives involved came forward to apply the required directive approach. They preferred waiting for the conflict to just settle by itself or to get some more “persuasive S2 alternative” change management going on in a context where the will to change is not there. Of course, the change then stalled and stalled; the status quo desired by the resisting group was maintained. And the organisation ended up worse that it was in the first place, because the vast majority that desired the change was deprived of it and will not collaborate next time we come to them to work on improving their organisational project management maturity.

I am really puzzled by the aversion to directing and using authority, which seems to be the norm now with upper managers. I give a course on “How to influence with limited or no formal authority” because, it seems, people do believe that it is so difficult to influence without formal authority. Yet, those who have legitimate authority seem to be in need of their own course: “When and how to use the formal authority that you already have”.

For me, the issue is very simple here. It is part of leadership to direct when need be, and there will always be instances where directing is the preferred, if not the only option. When times come for real change and a majority calls for it but cannot move forward, because of a group or a person, not wishing to be part of a team effort, resists obvious and necessary organisational change, project management leadership through directing is called for. Real project leadership can face adversity. Real project leadership is not a question of leading by consensus. Real project leadership is a question of leading and taking charge when times call for it. Let the true leaders rise and manage properly these organisations where change is necessary, that is all organisations.

1 Situational Leadership models explain that proper leadership style is contextual and that basically four different styles can be used depending of the context: S1-Directing, S2-Persuading, S3-Concerting, S4-Letting go (autonomous teams)

Don’t forget to leave your comments below