A Project Manager so obsessed with process, they forget their job is to help the project be successful.
- Can mutate into: “The Tyrant” Project Manager
- Dangerous when coupled with: “The Dictator” Product Manager
- Likelihood of fixing: High
- Danger to project: Low
Problem
Any project manager, if sent to a training course on project management or finishes reading a book on project management, runs the risk of becoming The Process Obsessed. This can happen to the best of people, so it’s important to be patient with them.
There are two broad categories of processes obsessed project managers:
- Waterfall Obsessed
- Agile Obsessed
While their training course/book may have called them different things, you can put them into the proper bucket easily by applying the following test:
- Waterfall Obsessed believe all problems can be solve through more documentation e.g. “From now on, we are going to write systems requirements document for every business requirements document.”
- Agile Obsessed believe all problems can be solved through frequent short meetings e.g. “From now on, we’re going to have daily morning stand up meetings that last no more than 15 minutes.”
The goal of any project manager is the delivery of the project on time, and on budget. The process we use facilitates that end. When a project manager becomes obsessed with following a process, they can ignore this fact and instead fixate on the question of, “Are we following the process properly?” at the detriment of their other job responsibilities.
Solution
Whatever you do, do not attempt to take their process from them, or argue against the process. What you are dealing with is more of a religious zealot than a rational person, and they have convinced themselves of a truth: Their process will “fix” the project. If they perceive that the project is “broken”, and you try to say, “That won’t help us”, they will simply consider you a part of the reason why the project is broken.
The solution to a The Process Obsessed Project Manager is simple: agree to whatever they say you should do, but gently remind them that “It takes time to turn a big ship” and “Rome wasn’t built in a day”. What you’re trying to do is get them to agree to implement their new process through a series of small changes, rather than a big-bang change. This will allow them to learn through experience which techniques are effective and which are not. As they gain this experience, they will learn to adapt their process to the situation on the ground and will hopefully realize process is a means to an end, not a means unto itself.
My issue with agreeing with someone only on paper, when in reality you disagree is that it is inherently dishonest. I would encourage dialog:
– Take time to understand their position (empathy) – why is it that they are obsessed with process? Is it a personal limitation, is it experience…? Many incompetent PMs hide behind process.
– Openly talk about evaluating processes in terms of their VALUE. Do these processes serve a purpose? Do they bring value to the project?
– Frame the conversation positively: instead of “let’s get rid of stupid processes”, the idea of “let’s sit together and find ways to improve out modus operandi” can be more effective.
The approach I suggest is not to be dishonest, but to not meet force-with-force (as you indicate in your last bullet point). When you have someone firmly dug-into the position of, “I know the right way to do things and if you’re not doing it the way I tell you then you’re doing it wrong”, I believe the *most* empathetic thing you can do take a slow, deliberate approach to persuading them there there are better ways to tackle a project. The main phenomenon we are trying to avoid is called “The Backfire Effect”, in which the person only held a loose belief in their process until you challenged them (i.e. “Your process is stupid”), which then causes them to *deepen* their belief. By instead saying, “Your process is valid, but there are opportunities for improvement” you open a door and encourage them to walk through it. Pure deception (e.g., you agree with their process to their face, but subvert their efforts behind their back) is inefficient, and leads to unnecessary conflict. A steady, patient, persuasive process can coach “The Process Obsessed” into their full potential: a great project manager.
Miswording: “their process with “fix” the project”
Should perhaps be “their process will fix”
Fixed!
Often manifests in so-called Agile contexts as “We need a Jira for that” / Nothing happens without a Jira. It is ironic (and 100% correct) that this is in fact “Waterfall Obsessed”
I disagree with dishonestly agreeing. Bluntly: If your only fix is “more process”, then you will eventually have remaining problems caused by too much process, and “more process” cannot fix those.
It would be like asking “what food can I add to my intake to help me lose weight?” The question itself illustrates the missing of the point.
I have never worked with a truly processed obsessed person who wasn’t absolutely certain that they were a genius for implementing their process, and I was the idiot for disagreeing them them. Further, they believed that their divine purpose on this earth was to lead me down the path of process enlightenment – all while their process was directly responsible for causing the project to fail.
So far, the only approach that seems to yield fruit is to not attack their process, but to work to modify it within their process framework. For example, if they want to eliminate person-to-person discussions and instead have everything in Jira, instead of saying, “That’s utterly insane and the antithesis of collaboration,” agree to use Jira, and begin a negotiation on what precisely must always go in Jira, what is preferable to go in Jira, and what does no have to go into Jira.
In all honesty, it’s not clear to me that they can be fixed at all, and firing them might actually be in everyone’s best interest. However, if my arm is twisted and I have to find a non-firing solution, this is the only approach I have found that works. I’m always open to better suggestions, but these types of people are hard nuts to crack.