Most of my time is devoted to research projects management. So far, I’ve been involved in over 30 of them, in different roles and under different hats. From financial manager to beneficiary / research partner, dissemination / exploitation responsible, administrative coordinator and coordinator. And naturally all combinations of those statuses.
I divide my professional experience into “before I knew about Change Management (CM)” and “after I practice CM”. In my opinion it is so much better after, because thanks to it, I have a clearer view on my place and role in the “value chain” of the project delivery eco-system.
Maybe it’s the overall experience that I gained over two decades, but to me it seems that practicing CM methodologies certainly improves my skills, productivity, and most importantly the results of my work.
We all know that the Research Manager & Administrator (RMA) has different levels of involvement in projects. It varies from an “occasional” status (like, only periodic reporting) to “extensive” (like project monitoring, participating in meetings etc.). This also adjusts the “volume” of CM actions that are applied. There is no “one size fits all”.
I often use the broad term Change Management, which is a discipline in Management, however I practice a specific implementation of the methodology of CM as defined and thought by Prosci, a leading Change Management company headquartered in Colorado, USA. If I use some of their materials, I’m adding their copyright notice.
In this blog I am just giving a quick taste from a full featured workshop. If you are interested in having the workshop at your site or over an online session, don’t hesitate to contact us.
The first point to deal with, is if a project can be considered as a change? Spoiler: I think it is. Otherwise, there’s no point in writing all this blog 😉
Seriously, to examine this point, let’s start with the definition of CM. Change management focuses on the people’s side of a change. What is a change? And what are the other “sides”?
These are Process and Technology. So, we have People, Process and Technology. Now, consider it as a 3-leg stool like in the picture (Figure 1), and it is easy to understand that if you take out one of these three ingredients then the whole thing is not stable, risking falling. The project is as stable as the stool.
What is the process? It’s the project’s Plan/Goal/Objectives. The technology? It’s the Technology/Equipment/Tools that are used in the project. People? No need to explain that. There are no robots who manage projects, yet.
A project is a journey with known Start and finish dates. It has clear objectives and it’s the transition from the starting point to an end point. Therefore, a project is a change.
I like to start off with a concrete example that shows how much the theory matches the practice, or in other words: we all do CM whether we are aware of it or not. Here’s an example of a situation that we all know in collaborative projects, that’s well described by CM.
It is logical to assume that during the project journey (a.k.a. “the change”) not everything is smooth. Sometimes there are difficulties, often at the start, but also can happen anytime during project execution.
This picture (Figure 2) shows how a person, or a team, can cope with the change, which is starting to impact. In the Green zone everything is good. But once we face some difficulties, we can reach down to the Orange (or Red) zones. In the orange and red things are not so smooth and the productivity of the person/team is affected. The more deep the curve goes, the more negative impact of the change on that person or team. It is natural to expect a decrease in productivity in the beginning of the project, for many reasons. We are all humans. Sometimes it takes attention to bring the situation back to normal.
When several teams or people are involved (as the situation in collaborative projects), the situation becomes more complex. As seen in Figure 3, the more teams you have in a project, the odds to have a more severe situation increase. Different teams/partners react differently to a change. Some, will have marginal effect (like team A or team C). However, others can face a more severe effect (like team B or D). Note that team B can recover but what about team D? It resembles to a “defaulting partner” in project jargon and such a partner can negatively affect the whole project. So this is something to follow closely with the ultimate goal to prevent it or to minimize the damage to the project, if irreversible.
Note the terminology in the picture says on the Red zone “opt out from the change” which means “can opt out from the project” and this has serious implications. We don’t want it to happen.
This example shows how sometimes it may sound trivial, and yet it is a good visualization of the potential impact of CM, as a kind of external dashboard view of the project.
