I know a project manager who operates in a very difficult environment. She is extremely capable at her job, has a lot of respect from her teams and can always be relied upon to deliver a successful outcome. However, the individual she reports to—and who is a key stakeholder or sponsor for virtually every project—is not very capable, struggles to understand the work being performed, micromanages to try and compensate for his lack of comprehension, and introduces frequent, inappropriate change in response to his own boss (who shows many of the same traits).
As you might imagine, this creates a number of challenges for the PM. She finds herself acting as a “shock absorber,” protecting the team from as much of the uncertainty, irrelevance and error happening at higher organizational levels, while needing to aggressively manage the information reaching management levels on the progress of each project.
That is not only a highly stressful environment, it is potentially at odds with the way the organization expects her to operate. So is this okay? Can rules be bent in an attempt to get to the right outcome, or is this project manager behaving inappropriately? That’s what I want to consider in this article…
Role expectations and reality
Let’s start with something simple: the expectations of the role of project manager. Certainly one of the most important elements of the job is the successful delivery of projects, and that requires the leadership and support of an empowered and engaged project team. Without a doubt, the PM in this case is doing that—her teams thoroughly enjoy working on her projects, and she has a track record of delivering success.
However, there is also the expectation that a PM will deliver projects in accordance with the organization’s approved approach, and here things may be less clear. The PM complies with all of the methodology and process requirements, and completes status reports on time; so in that regard, there are no issues.
But there are aspects that are more questionable. For example, this PM deals with a lot of change requests that come from her manager, and frequently she chooses to ignore them. In some cases, the requests are from the manager himself; sometimes they are simply being passed along from the manager’s manager (there is never any pushback between those two management levels).
The PM will always review the requests, but if she feels they aren’t appropriate, she will effectively filter them out. Because the organization doesn’t enforce formal change control, this is something she can do without questioning. She will always explain to her manager (or her manager’s manager) why she isn’t incorporating the change; because they trust her ability (and have some awareness of their own shortcomings), they accept it—but still the behavior is something many organizations would question. (It is also something PMI would suggest is at odds with the code of ethics.)
The project manager takes this approach because she believes she has a better understanding of what the project needs than either her manager, or her manager’s boss. If we are being honest, she does have a better understanding in the vast majority of cases, but does that excuse her decision to ignore clear direction?
Given that the outcome of the requested changes is usually that the requests are rescinded after the PM has explained to her leadership why they aren’t a good idea, you could argue she is actually improving the chances of project success. By not only avoiding a disruptive and unnecessary change—but also the unwinding of that change after the fact—the project remains focused on what is ultimately needed. In addition, the team isn’t left with the sense that leadership keeps changing their mind about what they want, and are therefore more likely to stay engaged and motivated.
At the same time, she is ignoring requests from not only her manager but a senior project stakeholder. Regardless of the reason for doing so, can we really condone that behaviour? In this situation, it works because both the manager and the manager’s boss have a huge amount of respect for the PM—her skills, experience and judgment. But in most cases, the outcome of the PM’s actions would be (at best) career limiting. So how should these situations be handled?
Walking the tightrope
I could turn the rest of this article into an analysis of how to educate the managers, but I’m not sure that would be particularly insightful—we all know we need to try and help them understand why their actions are disruptive, guide them toward a change management process that encourages analysis and provide them with information in a way (and at a level) that satisfies their natural inclination to try and micromanage. The PM has done all that and more; and trust me—in this situation, the individuals concerned represent a real challenge.
So instead I want to look at how a PM can walk this tightrope of doing what is necessary to deliver successful projects while trying to respect the correct way of delivering those initiatives. I hope you won’t find yourselves in too many situations as bad as this, but we all know that sometimes the world simply isn’t as straightforward as we would like it to be.
In this particular situation, the projects are conducted with relative autonomy. There isn’t a PMO overseeing the work on a weekly basis, and reports don’t have to be submitted beyond the department—so the PM doesn’t have an external governance function to satisfy. That’s becoming more unusual, and my first piece of advice is to ensure that if you do have to “bend the rules” in a particular scenario, you should always try and communicate that to a PMO or governance function first.
I’m not suggesting you ask for permission; the risk there is that they will say no. Instead, you advise there will be some elements of the project where you have to take a non-standard approach because of the stakeholders you are dealing with. In many cases, there will be an awareness of the challenge presented by one or two individuals or groups, and there won’t be a need for any further explanation.
If that isn’t the case, you provide details of how you are going to manage those exceptions—and that’s what I’m going to address next. Whenever there is any situation where the approach the PM feels is necessary is misaligned with the “right” way of delivering the project, the PM must document their actions. This must include:
● What they are doing, and which elements of the overall project approach are not being followed.
● Why those actions are being taken—with complete clarity, this is not a time for political correctness or diplomacy. This should include all of the reasons. In my example, the PM explains the need to protect the team from changes that are likely to be reversed, to avoid frustration in the team from a perception that stakeholders don’t know what they are doing and are indecisive, etc.
● What they are doing to monitor their actions. This should be much closer management than when processes are being followed as the risks are far greater.
● What they are doing to restore alignment with the approved approach as quickly as possible.
Even with this level of documentation and the implied management that is occurring, this should be seen as an approach of last resort. Organizational processes exist for a reason, and if too many PMs are bypassing them too often, it is more likely to be a problem with the approach than with one or two people (or groups).
This approach is extremely stressful for project managers, so while I haven’t focused on it here, they must attempt to solve the underlying problem by educating and managing the stakeholders rather than compromising the integrity of the process. That may require support from other areas of the organization—the PMO, training and development, etc. Those groups should be included wherever possible.
Beyond that, however, the PM also needs to find a colleague who can support them while they are “walking the tightrope” of this situation. That colleague should be experienced enough to be able to provide practical advice, helping the PM to manage through the situation—but also someone trusted enough to be able to confide in, and help to relieve the stress created by potentially being at odds with both stakeholders and the organization’s defined project approach.
Conclusions
There’s a degree of risk in writing an article like this. It’s not a best practices piece that tries to improve the quality of project execution for all readers; and with a harsh interpretation, it could be perceived as advocating behaviour that is unethical and in breach of your employer’s policies.
I’ll accept that interpretation if that’s what comes out in the comments, but this month’s theme is around HR in project management—and this is a real people-related issue that a PM I know deals with every day. I have also had many conversations over the years on similarly themed issues of having to do things slightly differently than instructed because of the reality of the situation.
Processes and methodologies are designed to deal with 99% of situations, and they generally do so very well. However, there will always be that 1% that can’t be effectively managed with standard approaches—and those are the situations where effective management is likely to be even more critical for project success.
