Dealing with a micromanaging boss or client

March 30, 2012 — Bruce McGraw

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?

Posted in Best Practice, General Project Management, Leadership, management, pm, Project Management. Tags: , , , , , , , . 5 Comments »

Project Cost Estimating and How Scrum Projects Estimate Cost

March 8, 2012 — Bruce McGraw

If you want to provoke an emotional reaction from a group of software development managers, ask them about their experience doing project cost estimation – WOW. I doubt you will find any of them who look forward to the task. Some of the managers may even become downright hostile. Estimating the cost of a software development for a contract or a proposal can be a punishing experience. And, almost every manager will admit that their estimate — especially for a complex project or one with a long duration — will be wrong (but hopefully not by much).

Why? Because

  • Requirements change during development, which changes the level of effort and therefore the cost
  • The operational environment is not, and cannot be, completely understood before work begins (Unless you have the Johnny Carson “Carnack the magnificent” genie)
  • In order to create a “price to win” in competitive programs, senior management reduces estimated cost and then pushes the team to “work smarter” (HA – can I hear all the groans from project members!).
  • There is a gremlin called “Murphy” who loves to show up on projects and create all kinds of problems*.

The History of Software Project Cost Estimation
In the beginning there was intuition and wishful thinking that drove software cost estimation. A project manager, often not a practitioner or software developer, reviewed high-level requirements and created a cost estimate from that – “I think this should take a couple months.” That approach did not always work well (:-).

In an effort to be more scientific in cost estimating, professionals developed many techniques over the years for performing estimates – historical analogous estimating, parametric estimating, three point estimating (PERT), expert judgment, etc.  In fact, PMI has produced a book called “Practice Standard for Project Estimating”.

The software industry developed one costing method that assessed a cost per line of written code and then estimated how many lines of code would be required to build the software. The success of LOC estimation methods suffered from the reasons listed above as well as the obvious problem that not all lines of code are equal in difficulty. I once asked a senior software engineer, how many lines of code it would take to develop X functionality. He replied, “How many do you want it to take?” He was not being a smart aleck, he was only acknowledging the fact that there are many ways in software development to skin a cat and those options require different amounts of code.

LOC-based cost estimating was followed by function point cost estimation. A function point is an output, inquiry, input, an internal file, or an external interface. In simple terms, you develop a cost estimate by counting the number of function points in a proposed system, assigning a cost per point, and multiplying. More involved function point counting included values for difficulty and importance to the eventual system.
There were many other attempts to develop fast, cheap and simple software cost estimation methods. I could go on for a long time – However, I won’t bore you with the details.  Let’s just say there is no magic book or formula for this critical process!

Cost Estimating in Scrum
Over the last few weeks, I have been writing about using the Scrum framework for software development. Scrum practitioners do not avoid cost estimating challenges, but they have methods to assess project cost that are consistent with Scrum’s approach to project execution. They do not, however, have the magic bullet, either.

All Scrum projects begin with a story (read “high level requirements” for the PMI crowd). What does the product owner want to be able to do when the project is complete? From that vision come the initial requirements. Scrum cost estimating methods use the wisdom of the team to generate estimated effort — acknowledging from the beginning that final cost and duration will vary as uncertainty and changing requirements are reflected in actual development.

When the Scrum team meets for its initial planning, the vision is laid out by the product owner. The team then considers how to create the desired functionality, which are called story points. Each story point is rated for relative difficulty.
Cristopher McSpiritt describes the process this way in “What is Planning Poker?”

The Steps:

  1. The product owner describes a user story/feature the team is estimating. The product owner may provide clarification on the feature in response to questions.
  2. Each team member chooses a development effort card from a deck of values to represent their relative estimate of level of effort. Cards are placed upside down on the table so that they do not influence others.
  3. After all estimates are on the table, the cards are flipped over.
  4. If there is a significant range among estimates, the team members who submitted the high and low values provide a rationale for their estimate.
  5. Once the discussion on the range has been conducted, steps 2 through 4 are repeated until a consensus is reached.

This team process has the advantage of sharing the vision, building the team and gaining buy-in from the Scrum team members who have to actually do the work.

In his book, Agile Estimating and Planning, Michael Cohn reports success using a Fibonacci sequence, such as 1, 2, 3, 5, and 8 … for a relative story point difficulty value scale. The team then considers how many story points it can accomplish during a sprint – called velocity. An experienced team can generate a useful sprint / project estimate from this process. However, an estimate is just that. During actual development (the Sprint), task difficulty and team velocity are routinely reviewed and modified. As (predictable) requirements changes are requested by the product owner through the product backlog, variations in the order of the product backlog (Requirements or features) can be accommodated over the life of the entire project without affecting the current estimates and sprint.

One of the big advantages of this method is that we don’t have to estimate the entire project in excruciating detail or even know the complete set of features at the beginning of the project – this is more real world than the traditional waterfall type of project planning and estimating.
I would love to hear your opinions and thoughts about estimating for projects, both traditional and Scrum.

* Capt. Edward A. Murphy is accepted as the reason for Murphy’s law  http://www.murphys-laws.com/murphy/murphy-true.html

Posted in Agile, Best Practice, Project Management. Tags: , , , , , . 4 Comments »

Scrum Project’s Biggest Risk – Where did the Product Owner go?

March 1, 2012 — Bruce McGraw

Today I continue my series dealing with Scrum.  I mentioned in previous Scrum posts that I appreciated the opportunity to talk in depth with Don McGreal, VP of Training at Improving Enterprise about his lessons learned as a Scrum master. One comment of Don’s that caught my attention because its truth is reflected in my experience as a project manager and project consultant is that the biggest risk to project outcome is the involvement (or lack thereof) of the client or product owner.  (How many PMs have had the “disappearing sponsor/stakeholder” experience before?)

I have had customers who create a product vision and a set of top level requirements and then disappear from interaction with the team (and sight) until the semi-annual review. Don reported on a product owner who did not reappear for a year during development. Scrum success depends on an actively involved product owner. “If the Product Owner is ineffective then the Scrum team will be too,” states the introduction to an Improving Enterprise LLC product owner training class.

10 Tips for getting better customer/product owner involvement

  1. Explain the essential role of the product owner in having a successful development beginning with your first interaction. Use examples that the owner or client can relate to rather than focus on methodology or abstract requirements. All of us have stories of success and failure that can be tied directly to the interaction with the client. Use some of those examples to persuade. Your goal is to help the customer or product owner believe that their active involvement is not a punishment, but an opportunity to make sure the final product meets their needs. The product owner must set the requirements for each sprint. Cast the product owner as a hero.
  2. Train product owners who are new to their role. No one is born knowing how to be an effective product owner. Training and feedback help improve skills and the resulting development. Not to mention that you might actually create a rapport with the product owner that helps improve the overall communications.
  3. Put customer involvement in the contract. This is not a threat to hold over their heads, it is a demonstration of the importance of owner involvement in developing a product that is useful and meets needs.
  4. Get users involved in requirements generation and testing. Because Scrum development is broken down into many sprints, each with a deliverable, product owners or users have many opportunities to interact with the development team. Remember, under the Scrum framework, the product owner “drives or influences” the tasks for each sprint by creating and maintaining the product backlog (which is ordered).
  5. Do prototypes, demonstrations or iterative deliverables. Each Scrum sprint produces a working, bug-free piece of software (Or other demonstrable artifact). Having the users or product owner review and test at the end of each sprint allows developers to confirm that they are creating what is needed or make corrections before there is too much investment in a feature or process.
  6. Tie features to the product vision. Each sprint review should begin by reiterating the final product vision and show how that sprint’s work is part of the whole solution.
  7. Explain decisions and trade-offs. A product owner sets the task priorities for the next sprint. Developers must help the owner in selecting how much can be accomplished during a sprint by explaining technical requirements and challenges.
  8. Communicate. Keep the product owner informed. Make sure they are invited to the daily Scrum “15 minute” status meetings and are participants in the sprint planning and review sessions.
  9. Let the client drive. If product owners do demonstrations of the product developed-to-date during management reviews, for example, their sense of ownership increases as does their feeling of accountability.
  10. Give the product owner credit for their valuable contribution to the project’s success.
Posted in Agile, Best Practice, Project Management, Risk Management. Tags: , , . 1 Comment »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 393 other followers