Project manage THIS
July 22, 2011 8:39 PM Subscribe
Considering making a switch to becoming a project manager. Please tell me about your best and worst project managers!
In my current role I do a lot of project management in addition to a whole slew of other job responsibilities. I am currently considering either staying in something similar to what I do now or going in a direction that is closer to pure project management. I'd like to collect some anecdotal data from people who have WORKED with project managers- what was it your best project managers did that made them effective for you, and what did your worst project managers do that got in your way? Hopefully this will provide me of a list of practical do's and don'ts if I decide to make the switch.
In my current role I do a lot of project management in addition to a whole slew of other job responsibilities. I am currently considering either staying in something similar to what I do now or going in a direction that is closer to pure project management. I'd like to collect some anecdotal data from people who have WORKED with project managers- what was it your best project managers did that made them effective for you, and what did your worst project managers do that got in your way? Hopefully this will provide me of a list of practical do's and don'ts if I decide to make the switch.
Best answer: I was a production person, then a PM, and then the Director of PM for my company, so if you'd like my 2 cents, here it is.
A good project manager is very similar in many ways to a good waitress/waiter.
You have to:
Know enough about what the back of the house (kitchen) does to be able to explain it to the front of the house (clients and senior mgmt.)
Have excellent personal skills; diplomacy, patience, a little enthusiasm, the ability to keep cool under pressure.
Be able to keep multiple trains of thought in your head for different projects (that table just sat down, that table wants their check, that table needs to order, etc.) without getting flustered or confused or forgetful.
Meet the needs of the front of the house and the needs of the back of the house in mind (bring them tea, smile, help prioritize the work flow, help if needed, etc.)
Less kitcheny, but still true:
Protect the back of the house from unreasonable demands from the front of the house (keep the flow of info going both ways (we can't do that in that time frame, we'll need to outsource that, etc.)
Protect the front of the house (no, it won't take you eight hours to edit fifteen minutes' worth of video.) Keep costs/time down for the benefit of the client and your company.
DO NOT attempt to jump in and do the programming/cooking yourself if you know how. Your time is better spent doing your own job.
Be sure that the front of the house understands this triangle: FAST/CHEAP/GOOD -- pick two.
You must be in charge of at least one corner of this triangle to do your job effectively.
Last but not least: be sure you have talked with your Accounting department/senior management to understand exactly the ways that time-tracking by your team may affect the billing for the client. Work comes in trickles or gushes sometimes. If a programmer enters in eight hours of R&D programming time but enters it against a client's name (during a slow period) your project will run over budget very, very quickly without much work being done.
Good luck.
posted by jfwlucy at 9:08 PM on July 22, 2011 [16 favorites]
A good project manager is very similar in many ways to a good waitress/waiter.
You have to:
Know enough about what the back of the house (kitchen) does to be able to explain it to the front of the house (clients and senior mgmt.)
Have excellent personal skills; diplomacy, patience, a little enthusiasm, the ability to keep cool under pressure.
Be able to keep multiple trains of thought in your head for different projects (that table just sat down, that table wants their check, that table needs to order, etc.) without getting flustered or confused or forgetful.
Meet the needs of the front of the house and the needs of the back of the house in mind (bring them tea, smile, help prioritize the work flow, help if needed, etc.)
Less kitcheny, but still true:
Protect the back of the house from unreasonable demands from the front of the house (keep the flow of info going both ways (we can't do that in that time frame, we'll need to outsource that, etc.)
Protect the front of the house (no, it won't take you eight hours to edit fifteen minutes' worth of video.) Keep costs/time down for the benefit of the client and your company.
DO NOT attempt to jump in and do the programming/cooking yourself if you know how. Your time is better spent doing your own job.
Be sure that the front of the house understands this triangle: FAST/CHEAP/GOOD -- pick two.
You must be in charge of at least one corner of this triangle to do your job effectively.
Last but not least: be sure you have talked with your Accounting department/senior management to understand exactly the ways that time-tracking by your team may affect the billing for the client. Work comes in trickles or gushes sometimes. If a programmer enters in eight hours of R&D programming time but enters it against a client's name (during a slow period) your project will run over budget very, very quickly without much work being done.
Good luck.
posted by jfwlucy at 9:08 PM on July 22, 2011 [16 favorites]
Response by poster: clarification: I'm not asking people how their PMs can get out of their way, but rather how they've been impacted by PMs not effectively clearing roadblocks for them or impeding process
posted by raw sugar at 9:23 PM on July 22, 2011
posted by raw sugar at 9:23 PM on July 22, 2011
Response by poster: also: I've had the chance to talk to a lot of PMs and Senior PMs for their do's and don'ts. The piece of the puzzle I'm missing more of is the point of view from a team or the people working with a PM
posted by raw sugar at 9:24 PM on July 22, 2011
posted by raw sugar at 9:24 PM on July 22, 2011
Best answer: I work in software, so this is probably applicable to most creative groups.
One thing I think a good PM does is make sure everyone knows that managing the project is really the group's responsibility and getting them to really buy into it. Beyond that, they are there to provide structure when there is none, to keep the conversation going when every one has stopped talking and to lead by example. If you are going to require people to keep rigorous track of their accomplishments and schedules, you have to do the same and you need let the group give you feed back on your progress. The idea of management for a PM is not in the old school sense of "being" the manager but more of an enabler or facilitator, someone who keeps an eye on the plumbing and makes sure things are flowing, or building new plumbing if that's required. Always keep the conversation pointed forward towards an understood goal but don't be rigid, have a sense of humor but don't be the class clown. Avoid drama.
posted by doctor_negative at 9:25 PM on July 22, 2011 [6 favorites]
One thing I think a good PM does is make sure everyone knows that managing the project is really the group's responsibility and getting them to really buy into it. Beyond that, they are there to provide structure when there is none, to keep the conversation going when every one has stopped talking and to lead by example. If you are going to require people to keep rigorous track of their accomplishments and schedules, you have to do the same and you need let the group give you feed back on your progress. The idea of management for a PM is not in the old school sense of "being" the manager but more of an enabler or facilitator, someone who keeps an eye on the plumbing and makes sure things are flowing, or building new plumbing if that's required. Always keep the conversation pointed forward towards an understood goal but don't be rigid, have a sense of humor but don't be the class clown. Avoid drama.
posted by doctor_negative at 9:25 PM on July 22, 2011 [6 favorites]
The magic weakness of the two worst project managers I've worked with is unquestionably their habit and remarkable ability to multiply pressure from the "front of house" to the point where doing the job correctly became difficult. Hiding pressure can be a problem too; in one case I missed a deadline that I straight up didn't know about.
posted by mkb at 10:19 PM on July 22, 2011 [1 favorite]
posted by mkb at 10:19 PM on July 22, 2011 [1 favorite]
I'm a game designer (technical and creative mix of industries) and I've worked with a handful of PMs on medium to large projects (20-90 people). I would like to second doctor_negative's description of PMs being "facilitators".
One thing I absolutely love is that I can bring a problem that I don't understand to a PM and he'll help me find out who can solve or clarify it. Say I have a bug and no idea how to fix it - I can talk to my PM about it and he's on the case connecting me with the right department or person, sometimes taking the bug out of my hands and giving me an update once he's obtained more info. Even if the PM has no prior experience as a developer, a good one will still be able to understand and describe the context of a problem (why it's a problem, whose work is getting slowed by it, able to figure out what priority it is).
Good ones also keep their eyes on stuff that falls under the radar. If a specific system or problem is multidisciplinary, then sometimes that means it's everyone's responsibility and no one's, and it ends up going ignored or passed around between different people forever. A good PM will be able to identify these issues and make sure they get resolved.
I do think the most important thing is being approachable and friendly, and then the rest can follow. Focus on getting people to share their problems with you - because they trust you to help them solve it by allocating resources or cutting features, not judge them or challenge them or take sides - and you'll be on your way.
The one bad PM I've experience with had many flaws, but they all added up to being disliked and unapproachable. He was an impediment to development because he was unpleasant to work with, inflexible with the schedule, didn't trust us, challenged our competency, etc. So, we didn't work with him - instead, we'd lie about the schedule, obfuscate our workflow, and suffered from miscommunication because any real communication had to be done secretively lest he catch us doing Y instead of X. I recall attending a really important meeting for a day he was on vacation just so we didn't have to deal with him. I'm sure that's a good PM's worst nightmare right there.
posted by subject_verb_remainder at 11:39 PM on July 22, 2011 [2 favorites]
One thing I absolutely love is that I can bring a problem that I don't understand to a PM and he'll help me find out who can solve or clarify it. Say I have a bug and no idea how to fix it - I can talk to my PM about it and he's on the case connecting me with the right department or person, sometimes taking the bug out of my hands and giving me an update once he's obtained more info. Even if the PM has no prior experience as a developer, a good one will still be able to understand and describe the context of a problem (why it's a problem, whose work is getting slowed by it, able to figure out what priority it is).
Good ones also keep their eyes on stuff that falls under the radar. If a specific system or problem is multidisciplinary, then sometimes that means it's everyone's responsibility and no one's, and it ends up going ignored or passed around between different people forever. A good PM will be able to identify these issues and make sure they get resolved.
I do think the most important thing is being approachable and friendly, and then the rest can follow. Focus on getting people to share their problems with you - because they trust you to help them solve it by allocating resources or cutting features, not judge them or challenge them or take sides - and you'll be on your way.
The one bad PM I've experience with had many flaws, but they all added up to being disliked and unapproachable. He was an impediment to development because he was unpleasant to work with, inflexible with the schedule, didn't trust us, challenged our competency, etc. So, we didn't work with him - instead, we'd lie about the schedule, obfuscate our workflow, and suffered from miscommunication because any real communication had to be done secretively lest he catch us doing Y instead of X. I recall attending a really important meeting for a day he was on vacation just so we didn't have to deal with him. I'm sure that's a good PM's worst nightmare right there.
posted by subject_verb_remainder at 11:39 PM on July 22, 2011 [2 favorites]
I'm a technical writer/Quality Engineer in manufacturing, and I update/write (but not devise) SOPs, specs, work instructions, etc, investigate non-conformances, assign CAPAs, stuff like that. Everything I do needs, at a minimum, multiple manager approvals, and sometimes more extensive buy-in from various departments. I have worked without a PM as such, with a PM, and with a terrific PM.
I think I generally have been more productive without a PM -- fewer unnecessary meetings, less to break my flow when the limiting factor is only how fast I can type, less perceived micro-management to make me feel prickly. But one time I had this terrific PM, and I understood how truly useful a PM can be.
This guy talked to me extensively about my work flow, how long the turnaround is in each step, where the bottlenecks are, and how I track all this for my various documents. For me, the bottleneck is chasing down approvals -- all I do is generate documents, but the guys who approve them do many other things, and just going through and approving stuff gets back-burnered. I was spending maybe 20-40% of my time chasing dudes and asking them repeatedly to please approve my documents. Well, this PM talked to all of them, made them all agree what the approval time-frame should be, held a signing party, and followed up with all of them when anybody was lagging. And freed up *so* much of my time to just write more documents. I learned a lot about accountability from that guy.
posted by pH Indicating Socks at 12:21 AM on July 23, 2011 [4 favorites]
I think I generally have been more productive without a PM -- fewer unnecessary meetings, less to break my flow when the limiting factor is only how fast I can type, less perceived micro-management to make me feel prickly. But one time I had this terrific PM, and I understood how truly useful a PM can be.
This guy talked to me extensively about my work flow, how long the turnaround is in each step, where the bottlenecks are, and how I track all this for my various documents. For me, the bottleneck is chasing down approvals -- all I do is generate documents, but the guys who approve them do many other things, and just going through and approving stuff gets back-burnered. I was spending maybe 20-40% of my time chasing dudes and asking them repeatedly to please approve my documents. Well, this PM talked to all of them, made them all agree what the approval time-frame should be, held a signing party, and followed up with all of them when anybody was lagging. And freed up *so* much of my time to just write more documents. I learned a lot about accountability from that guy.
posted by pH Indicating Socks at 12:21 AM on July 23, 2011 [4 favorites]
This opens the floodgates:
1. Watch a few episodes of the UK "Office". To me it feels like watching a lot of my previous mangers/PMs rolled into one. Painful, but instructive.
2. A few thoughts from one of the organisations I worked for most recently. This was a budding NGO, which kept budding for the 3 years I worked for them, a few years before that, and I know for a fact that no "flowering" has happened to this day. Captured on film, it would look like an over-the-top caricature. Here are some of the issues:
- whilst there was extensive use of slogans of the type "further better cross-cultural communication and understanding by highlighting bla bla bla", NOBODY in the upper echelons had a clear idea of what the final product and its components was going to be, and what it was supposed to look like. We spent a lot of time in meetings in which top PM would rehash the same motivational material over and over, with the same metaphors, all the same rhethorical devices, visuals etc. Nothing else changed either.
- due to the above, we all repeatedly worked on sub-projects which were boring and time-consuming, and which were abandoned at some point before finishing. In 3 years, we worked and then stopped on cca 15 projects, each of which required extensive research. Some of these projects resulted in information/data which could have been useful enough to become a company's sole product, had any of them been finished - they're all languishing on someone's desktop somewhere. I shudder to think of the huge amounts of money squandered in this way.
- for quite a few people in my team, it became abvious fairly early on that some of the projects had design flaws, regardless of the final objective, and after a while it became obvious that the projects were designed with no clear objective in mind. We started getting together to figure out how to make recommendations, and ended up writing regular documents where we signaled problems, made suggestions, etc. Most of these went unacknowledged, a couple of times PM paid lip-service to the idea of taking our ideas in, and a couple of times our suggestions were met with aggression and hostility (PM threatened one colleague that he would fire her if she is not happy working there - which is the only conclusion if she keeps putting forward ideas which suggest changes). Needless to say, none of us still work for that company, despite the fabulous pay, and all of us have taken pay-cuts to escape, in one case more than one third of the pay there.
- our ideas did not go quite as unnoticed as the above suggests: in every case, after a period of time, one or the other suggestions would be dramatically announced by someone in management, usually PM, as this incredible insight they had just had, which would markedly improve the product we were working on. Not once was any of us acknowledged. Imagine the gasps and raised eyebrows around the meeting room... This, however, never led to any positive results, since they never took on board the whole concept of many little steps, integrating many elements and actions in order to work towards an objective.
- there was no clear hierarchy of responsibilities, of who reports to whom and for what, etc. You just managed to figure out who your pm was for any given sub-project, when woops! everything changed, and you suddenly found yourself told off by someone you hardly knew worked for the company and the first person sort of faded away. We were 25 people all told, and, by the time I left, about ten or more of those had variously been presented as bosses with no clear idea why, or had a go at one of us for no apparent reason other than to establish dominance, etc. To this day none of us has an idea as to who was responsible for what.
- pervasive nepotism and favouritism.
- favouring form over substance: this company was completely enamoured with the outer trappings of seriousness and tried to appear business-like much in the same way that a kid tries to play adult. Never in my life have I heard so many empty phrases, and I've worked for several multi-thousand employees corporations.
Anyway, this list could go on and on and on. To sum up: know what you are doing and why, if someone has a good idea which furthers the project acknowledge it and reward it, be sure at every step that everyone nows what their role and the role of others is, respect your team, don't rely on money alone as motivator, cut down on the business-speak in favour of clarity and normal human communication, don't use jargon unnecessarily just to puff your feathers, don't threaten or manipulate people into submission, make sure that communiation flows between all contributors to a project, and that everyone knows the final objective, the problems arising etc. Hope this helps.
posted by miorita at 3:33 AM on July 23, 2011
1. Watch a few episodes of the UK "Office". To me it feels like watching a lot of my previous mangers/PMs rolled into one. Painful, but instructive.
2. A few thoughts from one of the organisations I worked for most recently. This was a budding NGO, which kept budding for the 3 years I worked for them, a few years before that, and I know for a fact that no "flowering" has happened to this day. Captured on film, it would look like an over-the-top caricature. Here are some of the issues:
- whilst there was extensive use of slogans of the type "further better cross-cultural communication and understanding by highlighting bla bla bla", NOBODY in the upper echelons had a clear idea of what the final product and its components was going to be, and what it was supposed to look like. We spent a lot of time in meetings in which top PM would rehash the same motivational material over and over, with the same metaphors, all the same rhethorical devices, visuals etc. Nothing else changed either.
- due to the above, we all repeatedly worked on sub-projects which were boring and time-consuming, and which were abandoned at some point before finishing. In 3 years, we worked and then stopped on cca 15 projects, each of which required extensive research. Some of these projects resulted in information/data which could have been useful enough to become a company's sole product, had any of them been finished - they're all languishing on someone's desktop somewhere. I shudder to think of the huge amounts of money squandered in this way.
- for quite a few people in my team, it became abvious fairly early on that some of the projects had design flaws, regardless of the final objective, and after a while it became obvious that the projects were designed with no clear objective in mind. We started getting together to figure out how to make recommendations, and ended up writing regular documents where we signaled problems, made suggestions, etc. Most of these went unacknowledged, a couple of times PM paid lip-service to the idea of taking our ideas in, and a couple of times our suggestions were met with aggression and hostility (PM threatened one colleague that he would fire her if she is not happy working there - which is the only conclusion if she keeps putting forward ideas which suggest changes). Needless to say, none of us still work for that company, despite the fabulous pay, and all of us have taken pay-cuts to escape, in one case more than one third of the pay there.
- our ideas did not go quite as unnoticed as the above suggests: in every case, after a period of time, one or the other suggestions would be dramatically announced by someone in management, usually PM, as this incredible insight they had just had, which would markedly improve the product we were working on. Not once was any of us acknowledged. Imagine the gasps and raised eyebrows around the meeting room... This, however, never led to any positive results, since they never took on board the whole concept of many little steps, integrating many elements and actions in order to work towards an objective.
- there was no clear hierarchy of responsibilities, of who reports to whom and for what, etc. You just managed to figure out who your pm was for any given sub-project, when woops! everything changed, and you suddenly found yourself told off by someone you hardly knew worked for the company and the first person sort of faded away. We were 25 people all told, and, by the time I left, about ten or more of those had variously been presented as bosses with no clear idea why, or had a go at one of us for no apparent reason other than to establish dominance, etc. To this day none of us has an idea as to who was responsible for what.
- pervasive nepotism and favouritism.
- favouring form over substance: this company was completely enamoured with the outer trappings of seriousness and tried to appear business-like much in the same way that a kid tries to play adult. Never in my life have I heard so many empty phrases, and I've worked for several multi-thousand employees corporations.
Anyway, this list could go on and on and on. To sum up: know what you are doing and why, if someone has a good idea which furthers the project acknowledge it and reward it, be sure at every step that everyone nows what their role and the role of others is, respect your team, don't rely on money alone as motivator, cut down on the business-speak in favour of clarity and normal human communication, don't use jargon unnecessarily just to puff your feathers, don't threaten or manipulate people into submission, make sure that communiation flows between all contributors to a project, and that everyone knows the final objective, the problems arising etc. Hope this helps.
posted by miorita at 3:33 AM on July 23, 2011
Just re-read what I wrote, and realised that my frustration shines through too much - I didn't want for a second to suggest that you are anywhere near making such mistakes, and want to apologize for the tone there.
The way my ex-company is useful is precisely because they lay it on so thick that they are a caricature of mistakes which are normally made in a much less obvious manner.
posted by miorita at 3:41 AM on July 23, 2011
The way my ex-company is useful is precisely because they lay it on so thick that they are a caricature of mistakes which are normally made in a much less obvious manner.
posted by miorita at 3:41 AM on July 23, 2011
Best answer: Spent years working for PMs on software development projects, now have a couple of PMs working for me on software dev and IT operations projects. Our PMs are contractors that roll on and off, so I've had a chance to work with a bunch.
The Best PMs:
- Make sure every team member knows exactly what they need to be doing, so no one is idle or seeking out the PM or team lead to ask what they should be doing next
- Are flexible about recognizing that something fundamental has changed and the project baseline may have to change
- Are fearless communicators, especially up. If the project is going into the ditch, they aren't afraid to say it is going there and explain what they are trying to do to pull it out
- Clear hurdles for the team, whether it is lack of resources, work outside the project intruding, or personality conflicts
- Understand that task estimation is an art at best and coax good estimates out of the team without getting some artificial level of precision
- Defend the scope of the project from getting mid-stream requirements or scope changes. They won't always win, but can at least filter out the BS stuff.
The Worst PMs:
- Don't trust the team and second guess them on approach and duration. Challenging people is OK, but the PM isn't the architect or the team lead.
- Don't build in contingency (budget or schedule) because they think they can "manage through"
- Don't clearly communicate project challenges to sponsors, making for 11th hour surprises about schedule slips
- Build project plans with too many of the wrong kinds of milestones, e.g. paper based deliverables rather than concrete milestones like running code or racked servers.
- Insist on an artificial level of precision in the project plan that leaves the team spending too much time trying to estimate
- Pulls the team into the minutiae of project management instead of insulating them from it. Symptoms are team members are spending a lot of time writing statuses (instead of just telling the PM) or needing Microsoft Project installed on their desktop.
- Think an escalation is sending an email at 7pm on Friday, vs. calling someone or going to their office to discuss in person.
posted by kovacs at 5:01 AM on July 23, 2011 [11 favorites]
The Best PMs:
- Make sure every team member knows exactly what they need to be doing, so no one is idle or seeking out the PM or team lead to ask what they should be doing next
- Are flexible about recognizing that something fundamental has changed and the project baseline may have to change
- Are fearless communicators, especially up. If the project is going into the ditch, they aren't afraid to say it is going there and explain what they are trying to do to pull it out
- Clear hurdles for the team, whether it is lack of resources, work outside the project intruding, or personality conflicts
- Understand that task estimation is an art at best and coax good estimates out of the team without getting some artificial level of precision
- Defend the scope of the project from getting mid-stream requirements or scope changes. They won't always win, but can at least filter out the BS stuff.
The Worst PMs:
- Don't trust the team and second guess them on approach and duration. Challenging people is OK, but the PM isn't the architect or the team lead.
- Don't build in contingency (budget or schedule) because they think they can "manage through"
- Don't clearly communicate project challenges to sponsors, making for 11th hour surprises about schedule slips
- Build project plans with too many of the wrong kinds of milestones, e.g. paper based deliverables rather than concrete milestones like running code or racked servers.
- Insist on an artificial level of precision in the project plan that leaves the team spending too much time trying to estimate
- Pulls the team into the minutiae of project management instead of insulating them from it. Symptoms are team members are spending a lot of time writing statuses (instead of just telling the PM) or needing Microsoft Project installed on their desktop.
- Think an escalation is sending an email at 7pm on Friday, vs. calling someone or going to their office to discuss in person.
posted by kovacs at 5:01 AM on July 23, 2011 [11 favorites]
kovacs, I'm not a PM per se, but I work on project teams and the line between my role and the PM role sometimes blurs. Just wanted to let you know that your comment is spot-on. I'll be printing it and posting it above my monitor
posted by FreelanceBureaucrat at 2:03 PM on January 15, 2012
posted by FreelanceBureaucrat at 2:03 PM on January 15, 2012
This thread is closed to new comments.
posted by sweetkid at 8:43 PM on July 22, 2011 [1 favorite]