When people claim they don’t need project managers and say that project managers are overpaid, useless and not needed on a software project team, this is because of poor experiences those people have had in the past with technical project managers. Here are the red flags alerting you to a situation where you need to talk to your PM, mentor her, or fire her.

1. The Tech PM doesn’t seem to understand general software engineering terms or principles, or even technology. She should at least have a general understanding of the following: database, CMS, OS, versioning system, MVC, front-end vs back-end work, html, css, js….and she doesn’t have to code anything but know the basic definitions and concepts.

2. Your PM seems to take notes in the meeting and is not really facilitating the conversation or actively curbing sidetracked conversations (put extraneous items on the parking lot!), and all the meetings seem to run over time without any perceivable action items. This is known as the secretary PM who is just happy to help set up meetings for others, book conference rooms and sit and take notes but isn’t really setting agendas, leading and driving the conversations and follow-ups.

3. Your PM calls for a lot of meetings but the project seems to move at a snail’s pace…and oh, your team is complaining to you about spending over 50% of their days sitting in pointless meetings without agendas or action items.

4. Your PM is fairly silent and doesn’t attend or run meetings, doesn’t talk to the team members much and just asks the team what they are doing every week so she can pull together a status report.

5. Your PM gets flustered easily and can’t seem to do more than one task at a time. She is constantly behind on e-mails and gets annoyed when you show up at her cube with a question. PMs are THE multi-taskers. If she can’t do at least 5 tasks at once, she’s toast. PMs usually can run a conference call, while reading and filing emails as they come in, checking IMs, silently mouthing to a person who just popped up at her cube and also take notes for the conf call she is currently on. (Probably not good for the short-term memory business but that’s part of the job!)

6. The PM repeats what other people said in order to sound like she knows what is going on. She will repeat the tech guy’s words to design and repeat the designer’s words to the editor and so on. In the end, she is just playing telephone and probably mushing up the message and in the end, the various team members can just meet with one another and cut her out of the loop. This kind of thing gives PMs a bad name because real PMs do not do this.

7. The PM is too rigid and mired into the tools and not about how to use the tools to help the team and keep the project on track. “Well, I haven’t talked to the team yet because I’ve been busy working on this MS Project plan. It’s almost done. I’ve got about 500 lines of tasks…” when in fact, your project is only 3 months long and is scheduled to be released in two-week sprints and she is staring at a project plan and gantt chart 50 pages long. Remember that project management is very fluid and organic and in the end, it is about working with people to get things done: the how and the when. You can’t be married to a process and instead you should constantly be checking w/ the team to make sure the tools aren’t adding extra overhead to their work — tools should be useful, not cumbersome and being used just for the sake of being used.

8.The PM seems to not involve the right people in the meetings and things keep revealing themselves in the 11th hour, with everyone running around in a panic. The PM has to manage scope-creep and if you have a PM that is saying yes to every and anything that is coming in from the client, upper management or just any person who opens their mouths, then you have got a project that will not be done on time (or it may be done on time with a burnt out team ready to quit): “When did that become a requirement? But we are code freeze in 24 hrs! Are the designs even updated to reflect this requirement?”

9. The PM isn’t asking questions often, and early, which leads to #8.  The PM should always be asking “Why” as in why is this important, why do you need this, why is so and so involved; “When” as in when is this needed by, who is driving each requirement, what are the priorities or core requirements that need to go out first; “who” as in who can I talk to about XYZ, who is the subject matter expert for this system or that product, who is the key decision maker and approval giver; “what” as in what are we doing? what are the business objectives and requirements from the product team? what are the technical or resource or time constraints? what are the risks and issues? what are the measurements for success?; and “how” as in how can we get this done in three months with our current resource pool? how should we approach this to be most cost-efficient yet delivering clean code? how do test the system and how do we deploy this?

10. You can usually tell — just ask your team and ask the stakeholders and sniff around. If a PM isn’t really doing the job, you will see the signs.

1. The developers and editors and designers don’t want to schedule and set up meetings.  This involves a lot of back and forth between calendar shuffling and conference room re-booking, running meetings, assigning and following up on action items, nagging people and sending out brief but useful meeting notes. They just don’t want to deal with all that. Great PMs do all this effortlessly so that team members can just show up to the meeting, participate and leave and get it all summarized in a nice wiki page or email or basecamp message.

2. No one wants to handle the interpersonal conflicts and confrontations.  Conversations are often needed regarding team members not performing, vendors not doing their work, stakeholders who ignore multiple requests for design approvals or attendance for prototype demos, or clients who refuse to play by the established project process, etc.

3. Your PM is the glue that keeps every project team member on the same page and keeps them on schedule with their particular task. The PM is also the oil that keeps the machine moving, keeping an eye out on dev tasks being worked on, while making sure work is staggered and assigned correctly so the QA team also has work to do by established QA dates, and that the designers and the tech writers and so forth are getting the necessary input and sign-offs from the right people to get their work done. Your PM is the supreme juggler who knows what to toss first and what to toss last – the balls, flaming torches, knives and live rabbits never fall and that is why the project comes in on-time.

4. The PM is used to doing all kinds of grunt work. Any work that any team member deems, “That’s not my job,” the PM almost always will simply, quietly do it for the team. The only exception is WHEN it is actually someone’s work that they are just not doing out of laziness! I’ve met PMs who have done everything from running meetings, to creating customized reporting for various upper management and clients, to photocopying to on-boarding new hires to coding and testing and writing copy to buying and delivering food and drinks to a team working late.

5. The Tech PM has the added advantage of having been a developer before and hence knows, generally, how long certain dev tasks take and it is less likely the tech team can pull one over her. “No dude, I KNOW it does not take a month to build a 3-page static site. Seriously. I can do it right now in 3 hours. Want to revise that estimate for me?”

6. Your PM is the face of the project and will deal with all the prickly and bossy and curious people no one else on the team wants to talk to: marketing folks, senior management, other non-project team folks on other projects who are just nosy.

7. Your PM can summarize the project into interesting bits that are targeted to the right audience. If the PM is talking to Operations about setting up a midnight release, she will use the right words to make sure Operations knows why it is important for them to get the coverage for that night. If the PM is talking to editorial, or advertising sales or customer service, she will deal in the right lingo, tasty nuggets, and enticing descriptions to get those parties on board in just the right way.

8. Your PM religiously looks at calendars months ahead and can tell you the dates of every monday of this month or who is on vacation three weeks from now, and how many resources will be free or busy in any time frame. Two of the PM’s responsibilities is resource management and time management — do you want your other team members splitting up these tasks?  Your PM has both an aerial and on-the-ground view of the project at any given moment.

9. The PM’s door/cube is always open. Sure, she may have just returned to her desk for the first time today after having had 5 back-to-back meetings and no lunch yet but if you show up with a question about a bug ticket or a work breakdown task, she will greet you with a smile, say “Sure, I’ve got time to talk,” pull up a chair and dig up that item for you on the wiki, all ready to answer your questions. You are her priority and she is never too busy for you…even if this is the fifth time she has answered your questions about the same issue.

10. The PM gets people together. Things do not languish in email threads or unanswered IM messages or voice mails. She will grab the offending parties, bring them together in a meeting, a conference call, the office pantry, or for after work drinks and work this out once and for all. Because nothing is more painful for her than people on the same team who can’t seem to understand what “working together productively” means.