Please Don’t Stand So Close to Me

Straight Talk for the Micro-Manager

NOTE: This article originally appeared in the April 2009 issue of Flawless Compliance, under the "Hello Rubber, Meet the Road" section. The link to the actual issue is at the bottom of this article.

There’s no argument from me that the uninvolved project manager is a disaster. This is the person that never talks to his team, and never knows what’s really going on. This is a project manager that “manages up,” and cares more about how he looks to upper management than figuring out what’s really going on with their project. Their projects always end up in the same place—dead in the water. Because of this, they’ve mastered the art of spin control so they don’t look bad when the project fails. I’ve seen people make a whole career of failing on projects. It’s unbelievable that the organization doesn’t catch on, but that’s another story.

But then there’s the micro-manager. We all know this project manager as well. It seems like they don’t have anything else to do but constantly bug you for information. Then once they find out what you’re doing, they always have a “better” way of doing it and insist you do it their way. Of course if it works out it was their idea and if it flops you did something wrong. Their projects actually come in sometimes because of all the focus the project manager is paying to the project. However, it’s not a true win even if the stakeholders get what they want, when it’s at the expense of your team morale.

For me though, there’s nothing wrong with the micro-manager’s level of involvement. It’s their style of involvement that’s the problem. A micro-manager becomes a bad manager when they cross the line on what their role and responsibility is. So let’s review what a project manager should and should not do:

A project manager should:

• Setup project plans, and collect data on how tasks are tracking to plan
• Collect information on issues and risks, and help support the team by mitigating risk
• Constantly adjust scope, time, and cost to bring the project in balance with reality
• Share and communicate effectively with everybody involved in the project
• Assign resources to tasks based on resource availability
• Protect the team from outside influences and interferences
• Inspire the team, and keep morale up

A project manager should not:

• Tell team resources how to do their job
• Probe team resources for information on how their doing their job
• Demand or negotiate estimates of work to be completed
• Argue with business analysts or users on what the requirements are
• Redo other peoples work

In general everybody has a role on the team. Users provide requirements to business analysts and they collectively own the requirement. Developers (or other implementation resources) do the work and estimate how long it will take. Project managers communicate what’s going on, support the team, and generally facilitate the project through to completion. When roles get crossed, as what happens with the typical micro-manager, things get confusing and frustrating.

So if you get the sense that you’re a micro-manager, my advice to you is this. Maintain the high level of involvement; it’s the only way you’ll be able to efficiently balance the project with reality. However remember that your engagement with your implementation resources (e.g. developers) is that of them telling you how much longer things are going to take, and what’s stopping them from doing their job. That’s all you need to know. Also, your engagement with your business analysts is them explaining to you what the requirements are to a level where you can explain it to everyone else.

Trust your team to do what they do best, and support them at every crossing. In the end, they’ll support you back by bringing in successful projects: not because they have to, but because they want to.