The Old “Resistance To Change” Dodge

One of the most dangerous failure modes to afflict Project Management Offices (PMOs) is easily identifiable by its post-mortem analysis, if that analysis is articulated in such a way as to place the blame proximate cause of the failure on the organization’s “resistance to change.” Indeed, typing that phrase into a search engine will return myriad hits, examining the problem from psychological, organizational behavior and performance, sociological, or historical grounds, and every angle in-between. But when “resistance to change” on behalf of the organization is the reason pointed-to by a failed PMO implementation, I think that the PM-related aspects to advancing this capability within the macro-organization indicates another set of causes, rendering such conclusions suspect.
First, let’s stipulate that, in order to advance, well, any capability within the macro-organization, we’re really looking at two distinct but related problems: (1) how to identify the optimal (or even workable) technical solution, and (2) formulating its accompanying implementation strategy. If I’ve seen it once, I’ve seen it a dozen times: a new PMO Director will come in full of confidence that the management strategies with which they are familiar will certainly work in this new environment, if only the staff will follow instructions. If (when) those strategies fail, then the fault must have been due to “resistance to change” on behalf of that same staff, the organization beyond the PMO personnel, or some combination of the two, since the exact same technical approach worked so well previously, dontcha know. The reason for the failure is virtually never perceived as the PMO Director’s inability to identify the optimal technical solution in a novel situation, or a viable implementation strategy. This managerial conceit is toxic to the PMO’s technical agenda, and potential for success. The good news, though, is that it can be avoided with a few basic concepts included in the original approach to advancing the PM capability. I want to break these basic concepts down into two bins: one for managerial leadership, and the other for executing the implementation strategy. GTIM Nation regulars know of my three rules for effective managerial leadership:
1.The effective manager-leader must be advanced enough to identify the optimal technical approach in the current environment. Recycling old strategies without proper consideration of their appropriateness in the new organization is an invitation to PMO crash-and-burn.
2.The effective manager-leader must care about the personnel in their organization. If you don’t care about your people, they will quickly pick up on it, and they won’t care about you – or your technical agenda (no matter how well-developed) – either.
3.The effective manager-leader must have sufficient confidence in the selected technical agenda that, even if they were to find themselves without a supporting organization, they would pursue that agenda anyway.
Let’s add these three ground rules to the ones for developing an implementation strategy. True to the title of this blog, they were derived from Game Theory. Without going into the details, the distilled take-aways are:
1.Make the actual participation level involved in advancing the capability falling-off-a-log easy to do. If the needed level of support for advancing the targeted capability is minimal (or even non-existent), then any opposition to such change has nothing to push against.
2.For those whose active participation is required, if they fail to do so, don’t just notice. Do something about it. Call them out, put them on the spot, challenge them, use their previous words of support to remind them … whatever, just don’t let it slide. “Retaliate” is a bit harsh of a term, but if withheld needed participation goes without response, then your implementation strategy will fail to the pathologies of the Silent Veto, or the Slow Roll.
3.If those from whom you need participation are participating, but their data is sub-standard, they’re golden. Better data can be far, far more easily achieved than cooperation where it’s absent.
Incorporating these elements into your leadership and implementation strategies all but removes any legitimate “resistance to change” phenomena in the macro-organization, leaving only those elements within the team who will oppose you on the most specious of grounds. The optimal (or even a workable) technical approach, coupled with an implementation strategy tailored specifically to the macro-organization, and rolled out in such a way as to minimize the additional effort needed to achieve it removes almost all of the rational bases cited in all of those articles and columns on how to deal with such resistance, just without the avalanche of psychobabble that’s often attached to them.
Essentially, resistance to change is baked into the organizational cake. Blaming it for any given PMO’s demise is analogous to attributing the loss of a football game to a bunch of players in different uniforms preventing your team from scoring. PMs that understand this will see a much greater success rate.
PMs that don’t will blame “resistance to change” in the post-mortem analysis.