Dealing with a micromanaging boss or client

OK – How many of you have had to deal with a boss or client who is what we call a “micromanager”?  There are successful techniques that you can apply to help deal with a boss/client that micromanages your project. First though, it helps to understand where the micromanager is coming from and what problems he or she is trying to avoid.

Behaviors of a micromanager

Micromanagers are into control. Micromanagers are afraid to delegate authority or responsibility. They want to be apprised of even the smallest details about the project. And, they need that information updated constantly (Many would prefer telepathic real time updates!). Micromanagers often want to make ALL project decisions — from the important ones, such as staffing, to the minor ones, like the placement of the white board. Their constant need for data and their tendency to require “all decisions go through them for approval” slows the team’s progress — not to mention driving you, the PM, a bit batty.

During the execution of a project, the micromanager may not limit their interaction to requests for information. They may also try to tell team members how to do their jobs (even if they have never done the job). Be aware that on the rare occassion when the micromanager appears to be delegating authority and responsibility, they are likely to take back control at the first sign of trouble.

Motivations of a micromanager

I am not saying that I agree with micromanagers, but understanding what can motivate or drive them to this behavior is the first step in dealing effectively with them. Here are some of the common motivations:

  • Micromanagement may be the only kind of management they know how to do
  • They may be insecure in their position or in their knowledge
  • They genuinely believe that the project will not succeed without their direct and constant involvement
  • Because they do not feel competent to deal with complex issues, they choose to deal with small, trivial ones where they do feel competent
  • Maybe his or her boss is micromanaging them, and you know the saying about stuff rolling downhill….

Consequences of micromanagement practices

If you have a micromanager then you will have probably experienced or observed the following:

  • Team members stop trying to improve processes and results
  • Project do not succeed as well as they might have if everyone applied more of their knowledge and experience
  • Project managers (and other project members) fail to learn lessons that help them mature as PM professionals
  • Leadership is not developed (see Project Leadership Requires Sharing Responsibility)
  • High rate of employee loss — especially the bright, talented and potential future managers
  • Increase in stress, anxiety and anger for everyone involved

Working effectively with a micromanager

Well I don’t have any magic bullets, but here are some tips you can try.

As justified as your frustration and anger may be when you have to work under a micromanager, you need to take a deep breath and make the best of the situation. Then, you need to take some actions to try to counter the effects of this behavior on the project and the team.

Anticipation of the needs of the micromanager for authority and information should be dealt with preemptively. For example, when given a task, find out as many details as possible about the micromanager’s expectations. Listen carefully and feedback your understanding of the task. Asking detailed questions may limit the number of “bring me a rock” exercises you have to go through.

Keep the lines of communication open with the micromanager – yes I know how painful this can be. You may be able to build a trusting relationship over time that allows you to provide feedback on the deleterious effect of his or her management style. At worst, you will at least be able to talk with them about how it negatively impacts the project.

Provide the level of detail and frequency of project information they ask for, but add information on why and how. You may be helping to train the micromanager at the same time increasing their trust in you. Take the initiative to set up meetings and phone calls before they ask.

Give credit to the micromanager when it is due and reward them verbally when they stop micromanaging for a minute.

Don’t let them “push your buttons”.  Keep your cool and remember that you are doing the job and keep reminding them that you can handle the tasks.

So have you had encounters like this?  What tricks and techniques have you used?

Managing Implementation Projects – Tips and Tricks

Is there a difference in managing a project that is implementing a “Commercial-Off-the-Shelf” (COTS) application, versus managing a new software development project? Many of you would say there is a world of difference. In my opinion, it is not that simple – there are some project elements that are common to both, and some things that are much different.  Here are some best practices from my 20+ years of managing successful projects that I’d like to share with you today.

Software is Software
Technology projects involve that dreaded word “software.” But let’s not panic. First, software has become ubiquitous—with few exceptions, is probably inside of every physical item we buy or use today (cars, TVs, cell phones, etc).  Granted, not all software is the same. Some can be configured, while other software is “locked down.” When organizations
decide to build custom software applications rather than buying a COTS tool it is often because they need to lock down functionality to a specific use or process or because they need some special function that COTS software does not have.  More and more often, organizations are discovering that a COTS application will do 80% of what they need, with 30% of the cost.

Consequently, I have been managing a lot of Microsoft® Project and SharePoint® implementations this year. These software products are very powerful and can be highly tailored to an organization’s business processes without writing new software.  Projects to implement and configure tools such as these tend to ignore some of traditional software lifecycle aspects and I don’t think this is a good thing. Here are some of the steps I think still need to be included when planning and managing an implementation project for a COTS application.

  1. Requirements.  It is the key to successful projects—COTS or not.  Managing a project still requires knowing what the client and user requires and really needs (vs. wants) to produce their job outcomes.  (Listening to Customers)
  2. Planning.  I don’t think I have to elaborate for my tradition PM readers – this is the only way to identify and set expectations, schedule, staff and resources.
  3. Design.  Even though the application may be COTS, I find that the choices for configurations, the level of customization, and the ability of the latest generation of tools
    to change the look and feel of the product – really does require a good design.  Hopefully the design is done by professionals who are experienced in the software and have implemented it before. (Design with Users in mind)
  4. Testing.  I would hope that any project involving software would include this element, but have been amazed at how many times I see something put into production without testing because it is a COTS solution. Be sure your users get a chance to test the new application (UAT). (For more on testing see the post on usability testing.)
  5. Documentation. I can’t say enough about this – and I am NOT talking about the manufacturer’s manuals. Documentation does not have to be volumes of paper. However, there should be something for the support staff that documents the configurations and changes that were made to the system. I find that when outside consultants are used, this activity is more likely to be done. In my experience, when internal staff perform the configurations, documentation to more likely to be “lacking.”
  6. Training. My #1 pet peeve is that too many organizations are now “short changing” training to cut costs. They expect that all their users need is a simple, short one-hour overview and they will become experts in using the system. I fight to include a more robust and comprehensive training as a part of the projects I manage – and yes, I know that this increases the cost of the project.  But in the long run, training that equips people to use these new tools to do their jobs also increases the likelihood of system acceptance and long-term success!  (Making training better and How not to do training)

People are People
Back in 2009, I wrote a post titled “Does anyone listen to the Customer?” which was about how the PM should be the client advocate.  In practice, a project
manager uses customer requirements, resource knowledge and experience to construct a realistic project schedule and budget.  But a good PM knows that on a COTS implementation, the customer does not really know the full limitations or capabilities of the product.

I am currently managing a project where the Business Unit clients were being asked to tell what they needed the system to do.  This was without first giving them either an
expert to guide their input, or showing them what the application could potentially do.  These are people who know their business really well – but do not have a concept of what the new application might do.

Now I believe in focusing on solving business problems for a successful project, but the process for building good requirements should not lie completely with a novice business user.  We will either get requirements that cannot be accommodated or miss opportunities to really leverage the new tool because “they didn’t ask for that function or
capability”. If the user knew all of there was to know about the tool, he or she would probably not be in the business unit but rather in IT.

At the end of the project we want the implementation to actually solve or improve some real business process issues. The best way to insure that is to involve the people who have to use the technology and see what intersections can be made between the application’s functions and the user’s job outcomes.

So how many of your projects are actually “implementation projects” rather than software development ones?
Leave us a comment….

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site