PM-Clinic Week 3 Summary
Topic: Mistakes project managers make
Compiled: 10/15/2004
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 kind.
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 document.
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 helpsthem 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 of expertise.
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 impatient Devs.
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 wasexpected 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 of work.
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, toadd 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 the brownnoser).
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 stickto 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 his.
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…" or "When
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), partners
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 earlyon, 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 stillappreciated.
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 the
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 teamto feel comfortable communicating.
Contributors
Neil Enns, Sarah Ocker, Eric Voetberg, Faisal Jawdat, Myk O’Leary, Gareth Howell, Scott Berkun (thanks all!)
PM Clinic discussion group