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
Related Content
Webinars (watch for free now!):
Task Planning using Microsoft Project
What’s the value of Schedule Risk Analysis?
Articles:
Levels of Project Scheduling Proficiency
Are You Using the Team Planner View Feature in Microsoft Project?
Resource Leveling: Scheduling vs. Leveling
SonyaC
In 20+ years, the micromanagers I’ve met have never been willing or able to reform, even when confronted with their behavior by a superior. The root problem is inside the micromanager, not the team. A micromanager means one thing to me – exhausting mind games, undermining, and non-stop meddling. There is no magic status process or report to satisfy this person. It get complicated with a micromanager very quickly. They are a walking, talking distraction.
It won’t get better in time, as their familiarity with you, the team, the work increases. It will probably get worse. You will never perform your way into their trusted inner circle because there isn’t one.
This type of manager works off a flawed set of internal beliefs about people and the world that reinforces the danger of trusting in their mind. If one even trivial incident occurs that justifies these beliefs, they come in with renewed vigor. It’s obnoxious and time consuming (expensive) to deal with a micromanager.
This manager will never function in a healthy way with a real high performance team. Other confident, competent, and qualified people shake this person to their core and they will bring it down. They can’t reward, recognize, or compliment. The ones I’ve experienced are very paranoid and suspicious of anyone who knows more than they do.
The team either quits or develops really strange coping mechanisms and toxic behaviors just to survive until they can quit. Throwing people under the bus, toadying/kissing up, keeping secrets, taking surprise sick time, giving up, becoming jaded, and creating distractions to draw attention away from their own work. Some team members may even start to believe the narrative about being incompetent and untrustworthy.
Most of the ones I’ve run across in 20+years can’t say thank you or admit they’ve made a mistake. Turnover is very high on their teams and morale is a disaster. The only real response to a micromanager is to flee and not waste your time and talent on them.
Erik
Awesome (and fast) responses! Thank you both for the contribution and Controlswoman I’m glad to have helped you out.
Kind regards,
Erik
Eric Uyttewaal
Sonya, I realize, after reading your experiences, that what I was going to say probably does not make much difference. For all it is worth, here it is anyways:
Erik referred to the 1%-10% rule from my book ‘Forecast Scheduling’. I devised the 1%-10% rule to establish the right level of detail for activities in a schedule and it could also help keeping micro-managers out of your office. After all, if you provide too little detail as a project manager, you are inviting micro-managers into your office. If you make sure that all activities in your schedule have a duration less than 10% of the project duration, you have provided enough detail in your schedule and you have done your job of creating enough visibility on your project. Now, micro-managers have no reason to come over to your office and bother you, and you can send them away by referring to your online project schedule (in Project Server or Project Online?) if they want to find out where your/their project is at. Of course, you also need to keep your schedule up-to-date regularly, because otherwise you’re inviting the micro-manager back into your office.
Erik
Hi Eric U. Thanks for contributing to the comments section! And of course thanks for the book as well. Hope more people will contribute.
Kind regards,
Erik v H.
Erik v H.
Interesting to know that there is not a single line going down. But that tere can also be the migromanaging team members 🙂