Common Issues in Project Management #3: Micromanaging the Team

In this article I would like to explore a key issue that many Project managers struggle with. It’s an exploration into the term “Micromanagement”. There is a lot you can find on the subject, and I will end the article with some references to earlier articles on MPUG and other sources for you to enjoy.

What is micromanaging really?
Well, if you ask Microsoft Word for Synonyms you get a nice set of interesting words:

And if you look at various online dictionaries and Wikipedia the subject is quite clear:
“… excessive control …”
“… excessive attention to minor details …”
“… control [of] a person or a situation by paying extreme attention to small details …”
Concluding: micromanaging is nothing good. But also commonly practiced throughout the business world and project management in particular.
Reading through the multiple articles on the Internet I get a distinct feeling that one of the main reasons for people to micromanage is due to a lack of trust of the person doing the work.

Is it really a matter of trust?

Here’s an example where there was clearly a lack of trust (in the tool) I encountered recently:

I created a Power BI dashboard, with a daily refresh of all relevant Project Online data. The Project Managers needed to report their progress on a monthly basis. Project Online itself was always up to date due to the fact that PM’s published the data regularly. But when I showed the BI dashboard they demanded to have it refreshed at least every half hour. Because: “that way they were sure that the right data would show up in the report”, and “they would know how the data would show up in reports”.

How does a refresh rate of a half hour make the data more true than a daily refresh of a monthly reporting cycle? I had no clue, the client clearly didn’t trust the system/users enough. I helped them by showing the manual refresh option for when it was absolutely needed.

Learn more from Erik’s latest article series “Common Issues in Project Management”:
“#1: Over-booked and Mismanaged Resources”
“#2: Managing Project Documentation”
“#3: Micromanaging the Team”
“#4: Don’t set progress in the schedule”

However, I would really like to challenge the notion that micromanagement is practiced only because of a lack of trust in the systems or employees.

Other possible reasons that I could think of for Micromanagement:

Active sabotage of the project

Deep down I believe we all know that Micromanagement is a bad practice and will result in a project that is going to be more costly and less fun than it should have been. So maybe micromanagement is a way to sabotage a project that a Project Manager actually doesn’t like at all. I’ve read a book about these kinds of Project Saboteurs and wrote a short book review about is.

Knowledge on the subject

In my quest to find more reasons to why we micromanage I came to this possible reason. If you are highly knowledgeable about a certain subject (let’s say Project Online). Are you then likely to leave the project for “implementing and configuring Project Online” all up to the team you got assigned? Or will you instead want to be CCed in every mail and would you demand a detailed report of all custom fields and look up tables that were created (and why)?

I think that the more knowledgeable the PM is on the subject the more he/she might be inclined to micromanage. Keep in mind, I have not tested this or found any real data to support this thesis.

So in order to be a PM that is highly knowledge on the subject, you also need to be very keen on your processes and structure in order to not fall in the trap that is Micromanagement.

During my search I was helped by this Wikipedia link: https://en.wikipedia.org/wiki/Micromanagement#Causes

Let’s take a look at Micromanagement in Microsoft Project schedules.

The real question is: How much, is too much?

You obviously don’t want to lose all control over the project, and you clearly need a schedule that has a good WBS and work packages / tasks in place. But where do you stop entering just another task for just that little extra feeling of control?

In his Forecast scheduling books, Eric Uyttewaal mentions that there is a 1% – 10% rule that you should look for, in calculating the duration of any task. Where the percentage is compared to the total duration of the project.

I’ve also heard others say that you should never go smaller than 5% of the total duration of a project. And still others talk about a absolute minimum length for a task: 1 day.

Personally I would say that there are a number of items to keep in mind:

The reporting cycle of your superiors and stakeholders on the project
Your progress cycle with the team
“obvious expert items”

Ad 1: If you need to report on a monthly basis, you might want to keep your tasks within a duration of 2 to 6 weeks. That way you can always report somethings finished or nearing completion at a meeting. And you can always state that you will be able to finish things before next meeting.

Ad 2: If you have weekly progress reports with your team it would be nice to have a action list of the actions that are started, half way done and nearing completion. Just think about the problem if you needed to talk endlessly to 1 person in the room on how he completed 5 to 10 items last week, before moving to the next person in the room.

Ad 3: You can probably break down a (car)engine in hundreds of parts, that are all equally important to the whole. But it is by no means necessary to name them all in a schedule because these are the items the expert knows all about (hence the “expert” title). So instead of focusing on all the little details, just state a general task for the expert, ask him/her for the time that it takes to build the engine, and leave it.

There is an exception to the above 3 points: High risk activity. Most projects have a pressure point where everything seems to come together. That moment can be highly stressful for everyone on the team. That is also the moment that a lot of risk and money is involved. During this time it might be needed to have a day to day, or even hour by hour schedule in place. Including all hands on deck, including the PM. But this is a timeframe that mostly takes no more than 10% of the total duration of the project. So don’t go around telling everyone that 80% of the project is a high risk activity 😉!

Final note and other related articles
I really enjoyed writing this article, but I do believe that there is so much more that can be said about it. Please feel free to share your thoughts in the comments section as well as other useful links or books you can recommend. In researching Micromanagement for this article I came across the following two MPUG articles that I would like to share:

6 Powerful PM Steps for Getting People to Follow You – Sebastian Bos – A great article with advice on establishing trust and support from your team.

Too Much Detail in the Schedule – Erik van Hurck – This is one of my earlier posts I did way in the beginning of my blogging career. It’s closely related to the subject “how much, is too much?”.

Wikipedia was also a huge help with this article: https://en.wikipedia.org/wiki/Micromanagement

And I mentioned the Project Saboteur, a book I reviewed on TPC.

Thanks for reading,

Erik

Articles:
Levels of Project Scheduling Proficiency
Are You Using the Team Planner View Feature in Microsoft Project?
Resource Leveling: Scheduling vs. Leveling