PM-Clinic Week 3 Summary
Topic: Mistakes project managers make
This summary will stay open. If you come up with other ones, send them my way and I'll
update this list now and again.
Mistake #1: Not paying attention to reality.
Description: This is a general form of dysfunction where the PM lives in their own
cushy universe. Specs are written, but the PM doesn't notice that no one is reading
them. Meetings are run, but no one pays attention. Programmers and testers are unhappy
or unproductive, but the PM keeps going through the motions as if everything is ok.
Remedy: This is a management action. Someone has to smack the PM on
the nose (not too hard) and point out how what's falling apart, and reminding the PM
it's entirely within his realm of responsibility to involve himself in issues of this
Mistake #2: The Napoleon complex.
Description: Another general issue. General project management or lead roles have degrees
of authority, and are not expected model their authority posture on Genghis Khan or
Julius Caesar. The PM may behave as if the universe is centered on his ass, and that
all others should be moving in orbit around wherever he is sitting. He pays little or
no attention to the suggestions or needs of others, and can't separate the areas he's
responsible and his own identity (they've been fused together by his ego).
Remedy: ? (Management action again? Mutiny? A programmer that exercises
some of their authority?)
Mistake #3: Not involving your dev team
Description: This is somewhat related to Scott's #2 below, but is less about suggestions
and is more about sharing. Nothing torpedoes a design faster than whipping it out at
the last minute for dev and test approval. Even worse is locking yourself in your office
to design your feature from scratch, only emerging when it's time to present the final
Remedy: From initial sketches through usability studies and final
spec work share your ideas early, and share them often. I've been bitten several times
because I didn't take the time to show my thinking to my dev team. It helps
them feel involved in the process, and does not necessarily mean you are designing by
committee. You're just keeping them informed. What are the benefits? Dev, test, ue,
etc. will be your advocates when you present your designs to management. Instead of
it being you against the world, it's your entire team backing you up and helping make
the point that the design is sound and beneficial to the problem at hand.
Plus, you gain credibility with your feature team, and they'll start to involve you
in *their* decisions. Devs will start talking to you about code design. Test will start
sharing test planning with you. UE will talk about doc plans.
Mistake #4 (friend of #3) Not actively managing transition of information
This applies most specifically to when things go from being "single gatekeeper"
to "distributed". This is sort of a personal variant of the common problem
of not making everyone go to the designated delegate when one delegates.
Remedy: track all the relevant players and be aware of who is and
isn't on board. It's sometimes useful to concentrate on specific people one-at-a-time
so as to make sure at least some people are on board, rather than letting everyone be
a laggard ("what the other people are doing" promoting momentum).
Mistake #5: Not reviewing e-mails before sending them
Description: You're planning on writing a broad communication mail to the team and
you're confident in your literary skills. You work for hours to craft the perfect "let's
drive to ZBB" or "congrats on hitting ZBB" or "here 's why our dates
are moving" mail, and then press send. But you don't seek review first.
Remedy: Get someone, ANYONE, to read the mail before you send it.
Testers are great at this, but anyone will do. Grab someone from the hall and say "read
this, does it look good to send?". They'll find typos, forgotten words, broken
links, and the ever-embarrassing forgotten subject line.
Mistake #6: PM as Gatekeeper (somewhat related to #2)
Description: PM filters all communications through himself, slowing the process and
"guessing" on answers rather than putting the developers/designers/business
owners in direct contact with one another for discussion related to their specific areas
Remedy: Include PM on communications to ensure he can accurately track
project status and issues, but let the rest of the team interact with each other directly.
This direction usually has to come from management, especially when the PM has that
nasty Napoleon Complex.
Mistake #7: Not following up
Description: PM wants to be main point of contact, but makes promises to team members
that she can't deliver on and generally over-commits herself. Lack of PM follow-up leaves
team members hanging with unanswered questions
that quickly snowball into huge delays and project issues.
Remedy: Get rid of her! I haven't been able to find a better solution
for this issue, as it speaks more to a person's inability to prioritize and manage her
schedule. This type of person should not be a PM - yet I'm surprised at how many PMs
I come across with this issue!
Mistake #8: Not properly estimating PM and Test work load before the start of a Milestone.
So often we are completely focused on how much dev time we can spend in a period and
don't consider the other disciplines (especially our own). Typically, we see this accompanied
by saying yes to every odd/last minute
request before the start of development and results in late specs, worn-out PMs and
Remedy: Account for the PM staff's time. Get solid estimates from
Test leads. Include daily overhead costs and real estimates of what it will take to
complete feature specs and drive the project to completion.
Mistake #9 :Forgetting to check final feature list with management and business owners.
Nothing is a bigger waste of time than to have a nearly completed project get slammed
at a business review because you forgot to do regular check-ins with management. Maybe
the project evolved differently than what was
expected or maybe there really was any real buy-in.
Remedy: Don't just send full specs up the ladder to management (they
won't read them), write short email summaries that can be easily read and understood.
Ask for feedback
Mistake #10: Taking estimates at face value
Description: It is very easy to fall into the trap of outright believing the estimate
provided by your team. "It'll take 5 days, it's really hard" is a common response
from dev. Or test will say "Oh, man, that'll take at least two weeks to verify".
Remedy: Ask questions. Find out what makes it 5 days instead of 3,
or two weeks instead of 5 days. Trust your instincts. If the estimate seems wrong it
probably is, or at least it should be assumed wrong until explained. Many times the
issue is that dev or test went for the more complex and complete solution when you spec'ed
a quick and simple way of doing it. Make sure everyone agrees on what the solution you
want is, and then make sure the estimates match. Also, estimates bigger than a couple
of days should ALWAYS be suspect, and generally should be broken down into smaller units
Mistake #11: Feature creep
I'm surprised no one has mentioned the dreaded Feature Creep. That nasty ugly soul
who trashes schedules as well as spirits near and far. Some PMs let anyone and everyone
change features to be more complex than need be, to
add features that didn't exist, and to re-deliver goods ad nauseum.Remedy: Use and adhere
to a change management system on all levels and across all departments. Legal wants
to change that EULA AGAIN after providing 4 different copies? Make them fill out a change
request and adjust the schedule accordingly so that people are kept in the loop.
Mistake #12: The Wuss.
Description: The PM as wuss always backs down. If the VP says jump, he says how high.
If the programmer says don't want to do this work item, he says lets cut it. The wuss
believes that to succeed everyone else should get everything they want, even if this
results in the team changing directions every few days. (btw: The Wuss is cousin to
Remedy: You can't manage if you never say no. Managing anything requires
defending a set of principles, goals, or ideas - if no one defends them, the project
becomes a lowest common denominator project. Deciding when to stick
to your guns and when to yield is a judgment call: and your judgment should be based
on logic that serves the goals of the project.
Mistake # 12: The credit taker.
Description: The credit taker uses the word "my" all the time, as in "My
feature", "In my design", "in my area". He forgets that no
matter how much responsibility he has, the work is not his alone. He did not write the
code,did not test it, didn't create the business plan for it, and may not have even
made the hardest decisions that contributed to it. The fact that his job title has the
word "manager" in it, doesn't mean that the credit for the work is primarily
Remedy: Give credit away. Use "we" and "our" frequently.
If given the chance to demo to large groups, us those opportunities to give the team
visibility as well, even if it's just of the form "When we designed this..."
we built this..."
PM Mistake #13: Believing their own marketing
It's marketing's job to tell the world how great the product is, how it's so much better
than everything out there, and how it will solve the world's problems. Good marketing
folks are sensitive to whether they are speaking to an internal or external audience,
and send the message to the product groups that is more like "Your products ROCKS
because of xyz. Competitor A is doing abc, deficiencies in your product are ... and
so on." Don't become complacent if your marketing team believes you're the best
thing since sliced bread.
Remedy: Open and maintain multiple channels of feedback, with internal
resources (planning, usability, business development etc.), customers (in multiple forums),
PM mistake #14: Not calling it like it is and solving the tough problems
If the schedule is slipping, and PM is constantly asserting that everything is fine
it's just issue xyz that will be resolved soon, then start to worry. The problem likely
isn't the issue at hand, but rather a pattern that needs to be corrected. This can happen
in individual features teams (dev, test, PM, UE), but can also happen with dependencies,
partners and customers.
Remedy: This is a tough one, since the cause could come from multiple
places (PMs relationship with key players, ability to communicate changes effectively,
PMs unwillingness to push back). I think that most often it boils down to the PM trying
to keep the peace, and being afraid of having those tough conversations with the key
players. Noticing this early
on, and coaching the PM is the most effective way - waiting until it becomes a crisis
is a sure formula for mistrust, stress and failure.
PM mistake #15: Not dreaming.
Actually, I've been caught doing this before. When the daily realities around you (bug
counts, dependencies, schedule, scope of project, etc.) seem so insurmountable that
you shun new innovation. PM stops dreaming. The end result could be that you miss important
market shifts and release the wrong product, you miss opportunities to add great value
at low cost, and you go into your next product cycle without a storehouse of great ideas.
Remedy: Someone needs to pull the PM out of the short term, and get
them to take a long-term view. Focusing on high priority tasks in the short term may
be the right thing to do, but shunning new ideas and innovation will poison the culture
of the team. At the very least capturing ideas for review later will make participants
feel like innovation is still
PM Mistake #16: Failing and blaming someone else
Yeah, maybe test didn't do their job, or your partner is not coming through. It's PMs
job to make this apparent to everyone as early as possible, and to actively work on
issues to resolve them. Sitting back and pointing a finger at the other person/team
does not produce results and destroys trust and morale.
Remedy: The team needs to create a culture that rewards communication,
and to never take a "shoot the messenger" approach. Great PMs will rise above
the culture and communicate anyway, but managers need every PM on their team
to feel comfortable communicating.
Neil Enns, Sarah Ocker, Eric Voetberg, Faisal Jawdat, Myk O'Leary, Gareth Howell, Scott
Berkun (thanks all!)