You hired a new PM – great! Just remember that it doesn’t matter how wonderful your new PM is, you still have to spend some time showing him or her the ropes in your organization.

1. Review general org chart with your new PM
Most organizations these days don’t have a definite org chart because people are moving in and out too quickly or there are too many re-orgs for anyone to lock the hierarchy down. But that doesn’t mean you can’t try.  You should let the PM know the main players in each team and who rolls up to whom — especially those he will be interacting with — and if there are any “special” characters (hey, every office has those brilliant people that you need to treat with kid gloves to get things done). Introduce them to key folks in Product Management, Design, Software development, Marketing/Sales, Editorial, Customer Service and Business Development.

2. Process Walkthrough
The process from project inception (whether through formal project charters or just some higher-up saying “Let’s do this!”) to discovery (requirements gathering) to construction (development) to testing and launch is different from firm to firm (and sometimes even team to team) so it is important to give your PM a run down of the project process and methodologies (agile? waterfall? lean? hybrid?) used at your firm. Diagram and outline the various environments the developers work in, how code is moved from one place to another,  what the project request and requirements gathering process is, and how to work with the creative teams.  If you can, give your PM a list of all the dev, stg, qa, production links and a login for all the systems he will be monitoring and testing, as well as all the ticket request links (if he needs to request a workorder from the design team or the tech support team or file a bug).

3. Don’t expect your PM to jump into running meetings on Day 1
Most PMs are capable of running from the start but you should bring him around the office and introduce him to folks, let him sit in on meetings he will eventually be taking over, and send a fun introduction note to the company so they know a new PM has started, what he will be working on and here are some fun things he likes to do outside of work.

4. Set Expectations with your PM
Explain to your PM why he is in this role. Is this a troubled team or product and you expect him to turn things around? This helps the PM adjust his approach.  Set some 30, 60, 90 day goals before setting the longer term 6-12 month goals. Also make sure you set up weekly one-on-one time with your PM.  It is important that you do all you can to ensure your new PM gets out of the gate in a good light and gains trust and respect among the team and the other teams he will be interacting with.  The moment a PM is tagged as “ineffective,” “useless,” “clueless,” then it becomes hard to overcome that reputation.

5. Provide some insider tips for the PM
No, not the stock buying kind. It may have taken you 5 or 10 years to learn how to maneuver the political battlefield in the office, or how to get around certain corporate systems or gain favors with the operations team but it doesn’t hurt to relay some of these tips to the new guy. Send over some links to useful intranet and wiki sites that he should bookmark. The diligent PMs will ask lots of questions anyway and jump right in but any tips to the fast track are always appreciated. If you want your PM to succeed and be effective, help him out!

We all send and receive a lot of emails. What makes you read one email over another? And how do you increase the chances of your recipients actually reading your emails?

Meaningful Subject Lines
Please do not send any more emails with subject lines of “Re: Re: Re” or “<no subject>” or “Hey” or other meaningless terms and phrases.  The subject line is like the headline of an article — your article — make it lively and relevant!  Put in the essentials:

• Project or Topic or Event email is referring to
• Any action required? Is this a FYI (meeting minutes) or a “Please review” or “Your Approval needed by 5pm”
• Add a few at-a-glance key terms that summarize the gist of the email

Examples:

• DB2 Migration 5/2 Dev Mtg Mins: Action items for Jack and George by 5/8
• FYI- Agile Training Vendor Vetting Session Findings
• PCI Audit Review: We passed audit but 5 major asap items for 8/1 follow up mtg
• Free ice cream at Corner Deli on 49th and 5th from now till 6p – coupon attached

Use Bullet Points
The email is not your great American novel or the draft of your speech. Watch out for long sentences and heavy paragraphs and extraneous words.  Get to the point in under 5 seconds! Try to keep your email above the fold, or at least keep the important details on the top, like the lede in a news story or the thesis in a term paper.  Put the action item assignments in the beginning of the email and leave the minutes and other FYI details lower in the page.

Add Links to your Emails
If your email is referencing an event or a project update or some news topic or vendor findings, and you are asking for feedback and opinions, then please add some links! Don’t write some three paragraph email about a subject and expect your reader to go searching in the intranet or internet for the relevant sites.  Throw in the links to the project wiki, the latest project schedule, the vendor website, the vendor’s API site, the event site, or links to white papers or wikipedia pages about the research topic.   If you don’t, chances are, the reader will not get around to doing this research and you will never get the feedback you requested.

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.