How to prevent well intended project managers from getting too involved in the details?

Question

When working on projects, there are often Project Managers who have transitioned from technical roles.

For better or worse, these project managers often take the lead in defining the technical deliverables often at the risk of alienating the technical teams, missing dependencies, constraints, etc that define technical achievements, etc.

Sometimes a project manager comes along who has had basic exposure to technical solutions and attempts to define technical milestones.

Rather than then tell them that it isn't their place to define these (since it can result is unintended results e.g. conflicts, challenging egos, etc), what would be an appropriate approach or sets of approaches?

Answer 1

There are certainly people who cannot help jumping out of their swim lanes and getting involved where they should not be. When that happens, you hit that head on and let them know they are interfering and jeopardizing success. The PM, however, has license to jump out of the PM swim lane and you cannot tell him/her to leave you alone.

Assuming you do not have a chronic, micro-manager type manager, your PM is jumping out of the PM swim lane because of you and your team. It's not the PM and the solution is not to figure out how to handle the PM. It's you and your team and the solution is to figure out what your team is doing or not doing that is causing the PM to interfere. There is a lack of trust, a lack of performance, growing risks, complaints, something.

If you have that micro-manager type PM, then be happy that projects have an end date, at which point you can find another project and another PM.

Answer 2

Apply the same techniques, the PM should has applied:

As you said (as far as I interpreted it), you don't want to upset someone or raise a conflict.

A nice way is to lead a conversation by asking questions (I didn't find a nice reference):

• What were your assumptions by putting that date?
• Did you know that this team hasn't applied that technology before?
• ...

If you manage to ask in an interested way, your PM will not get upset. In addition the PM should notice the lack of knowledge and put up an expert group in future.

Just for the completeness of the answer:

• Sometimes it's better to fight a conflict than to carry something around a long time
• Are your projects finally successful (w.r.t. budget and follow up contracts)? Maybe it's the (ugly) way to push the developers or to win a contract - than you should argue in a different way (more commercial success).

Answer 3

Well, first it's important to remember that a PM who has dabbled may actually have useful advice or opinions and may not be expressing them in the proper way. It's in the best interest of all parties involved to navigate through the egos in order to ensure that the best possible solution is being created.

That being said, my advice is to work with the PM to tackle what the actual customer requirements are. A good way to do this is to simply ask probing questions around:

1. What the detailed requirements are.
2. What the customer feedback has been.

As they start to give implementation solutions politely remind them that you'd like to focus on the raw requirements and not how you'd solve it.