What do project managers do?
March 31, 2015 8:41 AM Subscribe
Oh, right -- they manage projects. So, um... how do they do that?
I am a scientist in a Scientific Affairs department at a big company. Yesterday it was announced that we would be creating thirteen clinical studies to test variations on one of our products for various clinical endpoints, with very tight timelines -- they want to have publishable results in December. During the kickoff meeting, we were informed that I would be the project manager for all of these projects. I choked on my coffee.
I have no project managment experience. I have barely even encountered a project manager in the wild, and have no idea what they do. I will be talking to my boss today (it is her boss who tapped me for this gig) but if I cannot talk myself off this team, what next?
I'm not a whip-cracking kind of person. (You need to be, right?) My own children walk all over me. At work, though I am currently responsible for tracking some group tasks, my approach is simply to communicate what is needed, and people either do it or they don't. If they don't, I communicate some more. My department happens to be very high-performing on those tasks I track -- maybe that's why they picked me? Beats the hell out of me. I am the SharePoint admin for my department, and make InfoPath forms -- will that help me?
Please hope me. I would love to hear about any resources you have found useful, and especially, your personal stories about being a project manager or working with a great (or a lousy) project manager. I saw this question, but it didn't get many responses.
Thanks for any help you can give me!
I am a scientist in a Scientific Affairs department at a big company. Yesterday it was announced that we would be creating thirteen clinical studies to test variations on one of our products for various clinical endpoints, with very tight timelines -- they want to have publishable results in December. During the kickoff meeting, we were informed that I would be the project manager for all of these projects. I choked on my coffee.
I have no project managment experience. I have barely even encountered a project manager in the wild, and have no idea what they do. I will be talking to my boss today (it is her boss who tapped me for this gig) but if I cannot talk myself off this team, what next?
I'm not a whip-cracking kind of person. (You need to be, right?) My own children walk all over me. At work, though I am currently responsible for tracking some group tasks, my approach is simply to communicate what is needed, and people either do it or they don't. If they don't, I communicate some more. My department happens to be very high-performing on those tasks I track -- maybe that's why they picked me? Beats the hell out of me. I am the SharePoint admin for my department, and make InfoPath forms -- will that help me?
Please hope me. I would love to hear about any resources you have found useful, and especially, your personal stories about being a project manager or working with a great (or a lousy) project manager. I saw this question, but it didn't get many responses.
Thanks for any help you can give me!
Really great Project Managers in my experience are good listeners, and work to bridge knowledge across a diverse group of people. You don't need to crack the whip, but you do need to enable communication across diverse groups, and let the people in leadership know what everybody needs, and make sure everybody has the same understanding about what is going on. Whatever media or documents need to get made, translated, or cleaned up, you can help it work. Make sure all sides get heard and are happy.
A bad PM is just a toady for someone in power (or themselves), or hoards information and meters it out in small amounts.
posted by nickggully at 8:50 AM on March 31, 2015 [8 favorites]
A bad PM is just a toady for someone in power (or themselves), or hoards information and meters it out in small amounts.
posted by nickggully at 8:50 AM on March 31, 2015 [8 favorites]
You are, as a project manager, responsible for keeping the timelines of whatever project is happening. It's not you who "cracks the whip," so much as you who keeps everyone informed of what is going on, what is on-time, what is blocking things from being on-time, and what is happening as a result of these issues.
Mostly, a project manager gives transparency to a process. If Widget A has to be built in a week, and it's made up of three parts, built by three teams, and Team 3 cannot do any work until Teams 1 and 2 are done, you put that into the project plan. When Team 1 tells you that they can't get their work done because of missing flubber, you have to arrange the project plan to see how that affects your deadlines. Perhaps you can get flubber from somewhere else. Perhaps Team 2 can complete their part more quickly if Team 1 uses their people to help while the flubber shipment is on its way, and then they can all work together to crank out Team 1's part of the Widget once that shipment arrives. Maybe you have to change the timeline, and report up the chain exactly why this is happening.
Keeping everyone informed of all moving parts of a project is what you need to do. It can be a thankless, stressful job, but a good project manager is worth his or her weight in gold.
posted by xingcat at 8:52 AM on March 31, 2015 [11 favorites]
Mostly, a project manager gives transparency to a process. If Widget A has to be built in a week, and it's made up of three parts, built by three teams, and Team 3 cannot do any work until Teams 1 and 2 are done, you put that into the project plan. When Team 1 tells you that they can't get their work done because of missing flubber, you have to arrange the project plan to see how that affects your deadlines. Perhaps you can get flubber from somewhere else. Perhaps Team 2 can complete their part more quickly if Team 1 uses their people to help while the flubber shipment is on its way, and then they can all work together to crank out Team 1's part of the Widget once that shipment arrives. Maybe you have to change the timeline, and report up the chain exactly why this is happening.
Keeping everyone informed of all moving parts of a project is what you need to do. It can be a thankless, stressful job, but a good project manager is worth his or her weight in gold.
posted by xingcat at 8:52 AM on March 31, 2015 [11 favorites]
It's easy to dump on PMs because they seem sort of superfluous at first, especially if they don't have any deep technical domain knowledge in the problem at hand, but what I've seen in the best ones I've known are the following skills:
- keeping things moving along according to a timeline
- identifying in advance those things that might delay delivery by asking lots of questions throughout the process
- quickly identifying chains of dependencies or critical paths
- assigning (or at least identifying) responsibilities then holding folks accountable
- communicating to the various constituencies and stakeholders, across different levels in the org
They take a lot of crap, but the reality I've seen and experienced is that few folks have the wherewithal (or frankly, the time) to ride herd over folks representing a dozen siloed departments or business units and bring things to completion. It's a craft like anything else, with its own training and certification standards. As xingcat as above, a good one is priceless. The best ones I've known are nomadic - moving from place to place every year or two and helping right totally hosed organizations.
posted by jquinby at 8:55 AM on March 31, 2015 [7 favorites]
- keeping things moving along according to a timeline
- identifying in advance those things that might delay delivery by asking lots of questions throughout the process
- quickly identifying chains of dependencies or critical paths
- assigning (or at least identifying) responsibilities then holding folks accountable
- communicating to the various constituencies and stakeholders, across different levels in the org
They take a lot of crap, but the reality I've seen and experienced is that few folks have the wherewithal (or frankly, the time) to ride herd over folks representing a dozen siloed departments or business units and bring things to completion. It's a craft like anything else, with its own training and certification standards. As xingcat as above, a good one is priceless. The best ones I've known are nomadic - moving from place to place every year or two and helping right totally hosed organizations.
posted by jquinby at 8:55 AM on March 31, 2015 [7 favorites]
You might check out Scott Berkun's book on project management -- he was a program manager at Microsoft for some of their largest programs.
I've been in engineering management for 20+ years and managed several projects. My simple-minded approach to project management goes as follows:
- Build a plan with 10-12 evenly spaced apart (as much as possible) clear, unambiguous deliverables. If today is April 1 and you have to deliver in December, you might try looking at monthly deliverables. Do this working backwards. So, if you have to be done in December, what has to be done by the end of November to make that happen? What has to be done by end of October? Etc...
- Assign people to tasks, keeping in mind that there are meetings, interruptions, vacations, sick time, etc...
- Track progress regularly -- I would suggest weekly.
- When reality does not match the plan (it never does), re-plan.
Get clear about priorities -- what is "must do" versus "nice to do". If you have 13 projects, which are the most important (the answer is not "all of them" :)).
Hope this is somewhat helpful -- I have to go manage a project now :)...
posted by elmay at 8:59 AM on March 31, 2015 [3 favorites]
I've been in engineering management for 20+ years and managed several projects. My simple-minded approach to project management goes as follows:
- Build a plan with 10-12 evenly spaced apart (as much as possible) clear, unambiguous deliverables. If today is April 1 and you have to deliver in December, you might try looking at monthly deliverables. Do this working backwards. So, if you have to be done in December, what has to be done by the end of November to make that happen? What has to be done by end of October? Etc...
- Assign people to tasks, keeping in mind that there are meetings, interruptions, vacations, sick time, etc...
- Track progress regularly -- I would suggest weekly.
- When reality does not match the plan (it never does), re-plan.
Get clear about priorities -- what is "must do" versus "nice to do". If you have 13 projects, which are the most important (the answer is not "all of them" :)).
Hope this is somewhat helpful -- I have to go manage a project now :)...
posted by elmay at 8:59 AM on March 31, 2015 [3 favorites]
Project manager is not the same as supervisor - there should be no whip-cracking involved. That's what the higher-ups [who might be designated a "sponsor" or "champion" depending on the terminology your office uses] are for. (You will have their ear.) You are an information nexus or facilitator; your goals are to
posted by psoas at 9:02 AM on March 31, 2015 [9 favorites]
- outline what resources (labor, time, materials) are necessary to get the job done [this will take up a bigger chunk of your efforts than you initially expect],
- figure out (with the subject-matter experts) what has to happen before what else and map out the relations between different events,
- keep track of milestones and communicate progress or lack thereof to the relevant people (the workers and their managers),
- adjust schedules as necessary when problems are first apparent, and
- report out completed products.
posted by psoas at 9:02 AM on March 31, 2015 [9 favorites]
The major takeaway from project management classes is take the time estimate the worker gives you and multiply it by two.
The other major truism is that a project can be done fast, or well, or cheaply, but FFS not all three at the same time, no matter how much optimism opium upper management is smoking.
A buzzword you might find valuable is Work Breakdown Structure, kind of a flowchart showing what inputs are needed for a task and who is dependent on what. (This may be very old school, as I haven't been in the workforce for a long time, but it's how I think about dependencies. Keeping one persons slippage from slamming someone else's project is really what project managers are supposed to watch out for.)
You need to be able to tell if people are actually making progress and are on track with the early stages of their work. There is no way to put in 30 hour a day work days on the last three weeks of the project, even though most people seem to allocate their time that way. I assume that the people who need to write the papers are very busy and the risk of slippage is great, but I'm guessing.
The work you are doing can either be scutwork or pre-management work.
posted by puddledork at 9:02 AM on March 31, 2015
The other major truism is that a project can be done fast, or well, or cheaply, but FFS not all three at the same time, no matter how much optimism opium upper management is smoking.
A buzzword you might find valuable is Work Breakdown Structure, kind of a flowchart showing what inputs are needed for a task and who is dependent on what. (This may be very old school, as I haven't been in the workforce for a long time, but it's how I think about dependencies. Keeping one persons slippage from slamming someone else's project is really what project managers are supposed to watch out for.)
You need to be able to tell if people are actually making progress and are on track with the early stages of their work. There is no way to put in 30 hour a day work days on the last three weeks of the project, even though most people seem to allocate their time that way. I assume that the people who need to write the papers are very busy and the risk of slippage is great, but I'm guessing.
The work you are doing can either be scutwork or pre-management work.
posted by puddledork at 9:02 AM on March 31, 2015
There are many flavors of project management approaches. Scrum, PMP cert, PRINCE2, etc. There's even a great work of fiction that's intended to teach project and operational management.
But here's my take on project management: Project managers confront. That's not a pejorative. PMs are not "confrontational."
But PMs must always confront situations. You have no plan for how something will work? Confront that -- make a plan. Something isn't working? It's gotta be confronted because it won't fix itself. Something is working? That's gotta be confronted, too -- you must ensure it never stops working, and this thing that is working? Can it be a positive example for other things? That's gotta be confronted, too.
If someone stands up and says, "We're going to Vegas," the PM is the one that confronts that challenge. How are we going to get to Vegas? Driving? Fantastic. Whose car? Does it have enough seats for everyone? Does it have gas in the tank? Is there air in the tires? When was the last time you had the oil changed? Confront, confront, confront.
posted by Cool Papa Bell at 9:05 AM on March 31, 2015 [34 favorites]
But here's my take on project management: Project managers confront. That's not a pejorative. PMs are not "confrontational."
But PMs must always confront situations. You have no plan for how something will work? Confront that -- make a plan. Something isn't working? It's gotta be confronted because it won't fix itself. Something is working? That's gotta be confronted, too -- you must ensure it never stops working, and this thing that is working? Can it be a positive example for other things? That's gotta be confronted, too.
If someone stands up and says, "We're going to Vegas," the PM is the one that confronts that challenge. How are we going to get to Vegas? Driving? Fantastic. Whose car? Does it have enough seats for everyone? Does it have gas in the tank? Is there air in the tires? When was the last time you had the oil changed? Confront, confront, confront.
posted by Cool Papa Bell at 9:05 AM on March 31, 2015 [34 favorites]
I'm not sure what kind of research this is, but JPSM runs a two day course on project management in research. I found it gave me a much better understanding of what project managers do. A lot of it seems to be coordinating people, timelines and money.
For example, you have various things that need to get done to get this research done: manufacture products, manufacture placebos, train the researchers who will interact with subjects, record data, analalyse data, keep track of consent, follow up with subjects, administer drug, etc. So the project manager figures out:
1. How long each thing takes: Ok, the data analsis needs to be done by June 2016. Manufacturing the drug will take 3 months. Manufacturing placebo 3 months. Collecting data six months. Following up with no-show subjects to get their data 2 months. Entering data 6 months. Analyzing data 6 months, etc.
2. What sequence things need to happen in: Training researchers and both manufacturing processes can all take place at the same time. Administering the drug can't start until after manufacturing and training are done. Some data entry can take place simultaenous with data collection, but some will be after. Data analysis can't start until after the follow-up is done. etc.
3. Who needs to do what The same people can do data collection and entry, but then that means time spent collecting is time spent not entering. Data analysis is a whole other team. Coordinating the manufacturing requries someone else all togheter.
4. Work out all the implication of this: "If we're going to finish this on time, the latest we can start follow-up is Feburary 2016." "Given the things we have to do first, the soonest we might start data analysis is November 2015" "If we want to collect the data within 6 months, we need X researcher hours. If each researcher works Y hours, we need Z researchers. Since some researchers will drop out/quit/ get sick, etc. we need to train Z+W researchers." etc.
5. Keep of track of all this stuff and adapt #4 over the course of the project "Since there was a delay in manufacture, the soonest we might start data analysis is now January 2015." or "We have 35% of the project done, measured in expected cost, but we've spent 40% of our budget, which means we are 14% over budget." etc.
posted by If only I had a penguin... at 9:11 AM on March 31, 2015 [7 favorites]
For example, you have various things that need to get done to get this research done: manufacture products, manufacture placebos, train the researchers who will interact with subjects, record data, analalyse data, keep track of consent, follow up with subjects, administer drug, etc. So the project manager figures out:
1. How long each thing takes: Ok, the data analsis needs to be done by June 2016. Manufacturing the drug will take 3 months. Manufacturing placebo 3 months. Collecting data six months. Following up with no-show subjects to get their data 2 months. Entering data 6 months. Analyzing data 6 months, etc.
2. What sequence things need to happen in: Training researchers and both manufacturing processes can all take place at the same time. Administering the drug can't start until after manufacturing and training are done. Some data entry can take place simultaenous with data collection, but some will be after. Data analysis can't start until after the follow-up is done. etc.
3. Who needs to do what The same people can do data collection and entry, but then that means time spent collecting is time spent not entering. Data analysis is a whole other team. Coordinating the manufacturing requries someone else all togheter.
4. Work out all the implication of this: "If we're going to finish this on time, the latest we can start follow-up is Feburary 2016." "Given the things we have to do first, the soonest we might start data analysis is November 2015" "If we want to collect the data within 6 months, we need X researcher hours. If each researcher works Y hours, we need Z researchers. Since some researchers will drop out/quit/ get sick, etc. we need to train Z+W researchers." etc.
5. Keep of track of all this stuff and adapt #4 over the course of the project "Since there was a delay in manufacture, the soonest we might start data analysis is now January 2015." or "We have 35% of the project done, measured in expected cost, but we've spent 40% of our budget, which means we are 14% over budget." etc.
posted by If only I had a penguin... at 9:11 AM on March 31, 2015 [7 favorites]
I work in construction, and deal with project managers often. On a large project, a good project manager makes a huge difference.
Project managers:
1. Coordinate work schedules. Different contractors need to work on the project at different times. You don't want new light fixtures being hung before the painter paints the room (or he will get paint on the lights). The project manager lets the electricians, and everyone else, know when they are expected to be there.
2. Makes sure materials are at the job site. The electrician is installing the lights, but the interior decorate picked out the lights and purchased them with the customer. You don't want the electrician on the job site, and the light fixtures not be there.
3. Determines responsibility of each trade. Installing the dishwasher could be done by the electrician or the plumber. Installing the bathroom fart fan could be done by the electrician or the HVAC contractor. Project coordinator makes sure that every base is covered, and people are not duplicating work.
4. Project manager keeps the customer and suppliers informed. You do not want each individual tradesman talking to the customer. Smoother to have one point of contact.
The project manager needs to have a good understanding of every step in the total project. Needs to have good communication skills. Needs to be organized. Does NOT need to be a whip-cracking jerk. If your team is good, they should all want to do their part, you should not have to crack a whip, the team just needs coordination.
posted by Flood at 9:18 AM on March 31, 2015 [3 favorites]
Project managers:
1. Coordinate work schedules. Different contractors need to work on the project at different times. You don't want new light fixtures being hung before the painter paints the room (or he will get paint on the lights). The project manager lets the electricians, and everyone else, know when they are expected to be there.
2. Makes sure materials are at the job site. The electrician is installing the lights, but the interior decorate picked out the lights and purchased them with the customer. You don't want the electrician on the job site, and the light fixtures not be there.
3. Determines responsibility of each trade. Installing the dishwasher could be done by the electrician or the plumber. Installing the bathroom fart fan could be done by the electrician or the HVAC contractor. Project coordinator makes sure that every base is covered, and people are not duplicating work.
4. Project manager keeps the customer and suppliers informed. You do not want each individual tradesman talking to the customer. Smoother to have one point of contact.
The project manager needs to have a good understanding of every step in the total project. Needs to have good communication skills. Needs to be organized. Does NOT need to be a whip-cracking jerk. If your team is good, they should all want to do their part, you should not have to crack a whip, the team just needs coordination.
posted by Flood at 9:18 AM on March 31, 2015 [3 favorites]
At work, though I am currently responsible for tracking some group tasks, my approach is simply to communicate what is needed, and people either do it or they don't. If they don't, I communicate some more. My department happens to be very high-performing on those tasks I track -- maybe that's why they picked me?
This is basically what project managers do, so you already have some experience!
I'm a project manager in a technical/consulting field.
In my opinion, cracking the whip is actually a bad thing. If your team members are scared to come tell you something's not going right, you'll always be behind in identifying potential bottlenecks. You want your team to respect you, and also be willing to come to you with crises before they burst into full bloom.
Beyond that, it's all about planning. Money, people, materials, and time. I generally start at the deliverable and work backwards from there -- OK, I need Product X by Date Y. Who needs to review Product X? Book their time, confirm the dates with that person to get their buy-in. If Product X needs to be ready for their review by Date Y minus review time, when does that mean the draft is ready? And so on.
Build in interim goals/deadlines. Always factor in more time/money than you think you'll need.
I find that giving team members a sense of overall project progress and their role in it is very helpful for motivation. This could be team emails when a goal is met, or just telling people about the progress when you call them to check in.
I also want to note that your management did you no favors by naming you the PM at a meeting instead of telling you in advance. (Quite apart from anything else -- if it's your project, then that was your kickoff meeting and you should have been the one running it.) I'd suggest keeping a close eye on management as another potential source of problems during this process.
posted by pie ninja at 10:08 AM on March 31, 2015 [3 favorites]
This is basically what project managers do, so you already have some experience!
I'm a project manager in a technical/consulting field.
In my opinion, cracking the whip is actually a bad thing. If your team members are scared to come tell you something's not going right, you'll always be behind in identifying potential bottlenecks. You want your team to respect you, and also be willing to come to you with crises before they burst into full bloom.
Beyond that, it's all about planning. Money, people, materials, and time. I generally start at the deliverable and work backwards from there -- OK, I need Product X by Date Y. Who needs to review Product X? Book their time, confirm the dates with that person to get their buy-in. If Product X needs to be ready for their review by Date Y minus review time, when does that mean the draft is ready? And so on.
Build in interim goals/deadlines. Always factor in more time/money than you think you'll need.
I find that giving team members a sense of overall project progress and their role in it is very helpful for motivation. This could be team emails when a goal is met, or just telling people about the progress when you call them to check in.
I also want to note that your management did you no favors by naming you the PM at a meeting instead of telling you in advance. (Quite apart from anything else -- if it's your project, then that was your kickoff meeting and you should have been the one running it.) I'd suggest keeping a close eye on management as another potential source of problems during this process.
posted by pie ninja at 10:08 AM on March 31, 2015 [3 favorites]
Cool Papa Bell has it. I am running my second software implementation as project manager, and he has described my role perfectly.
posted by natasha_k at 10:16 AM on March 31, 2015
posted by natasha_k at 10:16 AM on March 31, 2015
There are many great answers here, so I'll just add a couple things I didn't see here that I learned managing big research projects.
1. Overcommunicate. If there is silence, people panic, forget what they were supposed to do, duplicate effort, etc. So, make an easy-to-follow project update and send it to everyone every week. It should be no more than a page and should show at a glance whether major deliverables are on track. You will likely be the only person who really understands all the components with a birds eye view, so to speak, and that is your super power.
2. Build in tolerance for delays. Plan to send the grant in before the deadline, plan to have extra help on call if needed, etc.
3. Celebrate success and thank people for their contributions, publicly, throughout the project.
4. Your most sacred duty is to guard the scope. GUARD THE SCOPE! People will try to expand the scope at every turn. Your job is to constantly remind them of all the implications every scope change will have.
Good luck. I ultimately found it to be a really fun and rewarding role.
posted by Ausamor at 10:51 AM on March 31, 2015 [9 favorites]
1. Overcommunicate. If there is silence, people panic, forget what they were supposed to do, duplicate effort, etc. So, make an easy-to-follow project update and send it to everyone every week. It should be no more than a page and should show at a glance whether major deliverables are on track. You will likely be the only person who really understands all the components with a birds eye view, so to speak, and that is your super power.
2. Build in tolerance for delays. Plan to send the grant in before the deadline, plan to have extra help on call if needed, etc.
3. Celebrate success and thank people for their contributions, publicly, throughout the project.
4. Your most sacred duty is to guard the scope. GUARD THE SCOPE! People will try to expand the scope at every turn. Your job is to constantly remind them of all the implications every scope change will have.
Good luck. I ultimately found it to be a really fun and rewarding role.
posted by Ausamor at 10:51 AM on March 31, 2015 [9 favorites]
I'm not a project manager, but I am a project scheduler. I deal with quite a few project managers, and, like anything else, some are better than others.
I work for the U.S. federal government for the Department of the Interior. My group (the Bureau of Reclamation) oversees maintenance and construction related to water resources: dams, recreation areas, roads, bridges, power plants, and all the bits and pieces that make these things work. The project time lines range from a few months to many years, and the costs run from a few thousand dollars to a hundred million or more.
I use MS Project software to track each project, and anticipate the dates for important milestones. Although I have zero actual authority to tell people when to get things done, I can tell them the results of their current or anticipated progress.
Being at least familiar with scheduling software like MS Project would be a necessity in my opinion, since most project managers don't have a dedicated person overseeing the schedules. Scheduling software lets you run "what if" scenarios, and shows you what needs to be done now in order to meet future deadlines.
The best project managers I deal with have a few traits in common:
-They know the schedule, and take deadlines seriously. If missing a milestone deadline looks inevitable, they make efforts to look for ways to make up the time by accelerating work in other areas, or running some tasks concurrently.
-They communicate well, both in telling and listening. In other words, they set clear goals and methods to reach them, and also proactively reach out to team members for status updates. This includes contacting me to see where important milestones fall based on current progress.
-They are proactive in gathering information and data. I meet each month with the project leaders. The good ones come to the meeting prepared with completion dates, projected dates, and slipped dates, and let me know which person or group is responsible for the tasks.
-They take their job seriously, realizing that other people rely on them for results. In the case of our department, missing deadlines can mean customers don't have power, recreation areas aren't ready for use by the public, environmental concerns are not addressed, safety issues are left uncorrected, or water is not available for irrigation. (60% of the nation's vegetables are produced using water managed by our bureau.)
You can just flip that list for the ones that aren't as good. The don't communicate well, they react to things rather than being proactive, and they don't seem to care if the project is on track or not until it's falling apart.
From my perspective as the scheduler, the main thing that seems to define the, uh, not-as-good project managers is lack of information. They just don't know what's going on with the project, and every question is answered with "I'll have to get that information to you..."
Good luck.
posted by The Deej at 1:09 PM on March 31, 2015 [2 favorites]
I work for the U.S. federal government for the Department of the Interior. My group (the Bureau of Reclamation) oversees maintenance and construction related to water resources: dams, recreation areas, roads, bridges, power plants, and all the bits and pieces that make these things work. The project time lines range from a few months to many years, and the costs run from a few thousand dollars to a hundred million or more.
I use MS Project software to track each project, and anticipate the dates for important milestones. Although I have zero actual authority to tell people when to get things done, I can tell them the results of their current or anticipated progress.
Being at least familiar with scheduling software like MS Project would be a necessity in my opinion, since most project managers don't have a dedicated person overseeing the schedules. Scheduling software lets you run "what if" scenarios, and shows you what needs to be done now in order to meet future deadlines.
The best project managers I deal with have a few traits in common:
-They know the schedule, and take deadlines seriously. If missing a milestone deadline looks inevitable, they make efforts to look for ways to make up the time by accelerating work in other areas, or running some tasks concurrently.
-They communicate well, both in telling and listening. In other words, they set clear goals and methods to reach them, and also proactively reach out to team members for status updates. This includes contacting me to see where important milestones fall based on current progress.
-They are proactive in gathering information and data. I meet each month with the project leaders. The good ones come to the meeting prepared with completion dates, projected dates, and slipped dates, and let me know which person or group is responsible for the tasks.
-They take their job seriously, realizing that other people rely on them for results. In the case of our department, missing deadlines can mean customers don't have power, recreation areas aren't ready for use by the public, environmental concerns are not addressed, safety issues are left uncorrected, or water is not available for irrigation. (60% of the nation's vegetables are produced using water managed by our bureau.)
You can just flip that list for the ones that aren't as good. The don't communicate well, they react to things rather than being proactive, and they don't seem to care if the project is on track or not until it's falling apart.
From my perspective as the scheduler, the main thing that seems to define the, uh, not-as-good project managers is lack of information. They just don't know what's going on with the project, and every question is answered with "I'll have to get that information to you..."
Good luck.
posted by The Deej at 1:09 PM on March 31, 2015 [2 favorites]
You have a lot of good answers here. One more version:
1. Build a team - which is a shorthand for saying that there is a group of people who all share the same objective, look out for each other and understand what role they have to play in helping the whole group achieve the goal.
2. Make a plan - come up with a story together about how you'll get it done. Keep adding detail to the story as you can. Make sure everyone on the team is telling the same story (document, discuss)
3. Track the plan, aka navigating - (listen and observe) Oops! Things didn't happen like your optimistic story. Time to work out a new story about how you are going to get back on track.
You are right to observe this is absolutely a skill. Good PMs ask lots of questions, never assume they have the answers without verifying, and make it their job to identify and remove obstacles to the team's success. Spot the hurdles on the project path and find ways to remove them, leap them or just plain go around them.
PMs get a lot of crap because it is a job that is nearly invisible when done well and really really obvious when done poorly. Like a mechanic, when the engine is running well a good PM just gets out of the way and monitors the gauges. In the PM role your job isn't to perform the work, but to make sure every team member's efforts are synchronized and effective.
I've found the best way to be a good PM is with curiosity, respect and a willingness to admit my own blind spots and point out the blind spots in others. You do need to hold people accountable to their promises, but that should lean on their professionalism, not you cracking the whip.
posted by meinvt at 1:12 PM on March 31, 2015
1. Build a team - which is a shorthand for saying that there is a group of people who all share the same objective, look out for each other and understand what role they have to play in helping the whole group achieve the goal.
2. Make a plan - come up with a story together about how you'll get it done. Keep adding detail to the story as you can. Make sure everyone on the team is telling the same story (document, discuss)
3. Track the plan, aka navigating - (listen and observe) Oops! Things didn't happen like your optimistic story. Time to work out a new story about how you are going to get back on track.
You are right to observe this is absolutely a skill. Good PMs ask lots of questions, never assume they have the answers without verifying, and make it their job to identify and remove obstacles to the team's success. Spot the hurdles on the project path and find ways to remove them, leap them or just plain go around them.
PMs get a lot of crap because it is a job that is nearly invisible when done well and really really obvious when done poorly. Like a mechanic, when the engine is running well a good PM just gets out of the way and monitors the gauges. In the PM role your job isn't to perform the work, but to make sure every team member's efforts are synchronized and effective.
I've found the best way to be a good PM is with curiosity, respect and a willingness to admit my own blind spots and point out the blind spots in others. You do need to hold people accountable to their promises, but that should lean on their professionalism, not you cracking the whip.
posted by meinvt at 1:12 PM on March 31, 2015
I'm a software manager but I have had to coordinate some projects because a proper PM was not available. Here is my one piece of advice:
No matter how many times you have restated obvious, major things about the project, say them again. Every meeting, every communication - state your understanding of the current status of important things out loud and see what reaction you get. People don't read emails and status reports. They just ... don't. Use stand-ups and other vocal communication for really critical stuff. Personally I prefer short stand-up meetings EVERY DAY. Not noticing problems for even a week can kill a timeline.
Also giant dependency charts (MS Project etc.) are fine, but don't get stuck in the weeds so much that you miss bigger things: A whole team is not delivering quality stuff. You're building the wrong product. A competitor just did something game-changing. Etc. The longer the project, the greater chance that at least one major re-alignment is going to have to happen.
Ok, oops, that was two pieces of advice. May as well go for #3:
Demand a single accountable point person from each team or functional group. They must have some decision-making power (or fast access to the decision makers) and be available to the project EVERY DAY when called upon. Put those names in the project summary. Don't have meetings if any of those people are missing. A big killer is "Phil is the rep from Sales, but actually Phil has no decision-making power. Sue is his boss and pulls the strings, but she's never around." Instant project fail. This is wayyyyy harder to achieve than it sounds. It takes a lot of (whatever genitalia) to cancel a meeting when people don't show up, but it sends a firm message.
posted by freecellwizard at 1:39 PM on March 31, 2015 [2 favorites]
No matter how many times you have restated obvious, major things about the project, say them again. Every meeting, every communication - state your understanding of the current status of important things out loud and see what reaction you get. People don't read emails and status reports. They just ... don't. Use stand-ups and other vocal communication for really critical stuff. Personally I prefer short stand-up meetings EVERY DAY. Not noticing problems for even a week can kill a timeline.
Also giant dependency charts (MS Project etc.) are fine, but don't get stuck in the weeds so much that you miss bigger things: A whole team is not delivering quality stuff. You're building the wrong product. A competitor just did something game-changing. Etc. The longer the project, the greater chance that at least one major re-alignment is going to have to happen.
Ok, oops, that was two pieces of advice. May as well go for #3:
Demand a single accountable point person from each team or functional group. They must have some decision-making power (or fast access to the decision makers) and be available to the project EVERY DAY when called upon. Put those names in the project summary. Don't have meetings if any of those people are missing. A big killer is "Phil is the rep from Sales, but actually Phil has no decision-making power. Sue is his boss and pulls the strings, but she's never around." Instant project fail. This is wayyyyy harder to achieve than it sounds. It takes a lot of (whatever genitalia) to cancel a meeting when people don't show up, but it sends a firm message.
posted by freecellwizard at 1:39 PM on March 31, 2015 [2 favorites]
I'm program manager in tech and just wanted to add that what Cool Papa Bell, Ausamor and freecellwizard said is true and excellent advice, especially the bits about communication; do it early, do it often.
One thing I try to focus on when confronting problems/blockers is not who the problem is, but what is is and how to solve it. If you finger-point people get defensive but if you look at the circumstances that created the issue people are much more likely to want to help you fix it.
posted by dolface at 3:22 PM on March 31, 2015
One thing I try to focus on when confronting problems/blockers is not who the problem is, but what is is and how to solve it. If you finger-point people get defensive but if you look at the circumstances that created the issue people are much more likely to want to help you fix it.
posted by dolface at 3:22 PM on March 31, 2015
This is from Scott Berkun ( mentioned above )....... your job is to "increase the probability of good things happening". He advocates that you do this by any means necessary within ethical limits. Need to get coffee for people? Do it. Need to ask hard questions? Do it. Need to ambush someone who isn't answering your emails. Do it.
One more thing. Don't confuse project management with producing charts and spreadsheets. Scott Berkun talks about this as well. A lot of weak PM's will fall back on their schedule / WBS / risk register to create the illusion of control. These tools are great but they should only be used to help you know where to put your energy. Your job is to move the ball down the field one day at a time. A lot of times you won't have time to create meeting minutes. Guess what, it doesn't matter. What is important is that you have people focused on those things that will move the ball. Be a prioritization machine. Everything else is noise that makes people feel better about themselves. Get off your computer, walk around, find the truth and take the necessary actions to resolve / accelerate things. Sending status updates to everyone is not project management. Knowing what is red and getting the right people to the table is. You should always ask yourself "Have I explored all my options to solve this problem?". Again, sending an email is not exploring all your options.
Some of the best advice I ever got came straight from Making Things Happen. I can't recommend it enough for any project manager in any industry.
posted by jasondigitized at 4:44 PM on March 31, 2015 [2 favorites]
One more thing. Don't confuse project management with producing charts and spreadsheets. Scott Berkun talks about this as well. A lot of weak PM's will fall back on their schedule / WBS / risk register to create the illusion of control. These tools are great but they should only be used to help you know where to put your energy. Your job is to move the ball down the field one day at a time. A lot of times you won't have time to create meeting minutes. Guess what, it doesn't matter. What is important is that you have people focused on those things that will move the ball. Be a prioritization machine. Everything else is noise that makes people feel better about themselves. Get off your computer, walk around, find the truth and take the necessary actions to resolve / accelerate things. Sending status updates to everyone is not project management. Knowing what is red and getting the right people to the table is. You should always ask yourself "Have I explored all my options to solve this problem?". Again, sending an email is not exploring all your options.
Some of the best advice I ever got came straight from Making Things Happen. I can't recommend it enough for any project manager in any industry.
posted by jasondigitized at 4:44 PM on March 31, 2015 [2 favorites]
Cool Papa Bell describes the good ones I know, too. When I do it (with some success), I try not to do very much telling, but a whole lot of asking. A lot more than I think is reasonable.
If A agrees to do thing 1 by date 1, B agrees to do thing 2 by date 2, and C needs thing 1 and thing 2 to do thing 3, no problem, right?
WRONG. A will forget to mention that their dates are moving unless someone is asking them every day. B will get other work from someone else that will have to either take a back seat or push your project. Nobody will have told C any of this, but C will have forgotten about their thing anyway and won't be ready to start on time.
UNLESS, you are going around checking on status constantly and asking the uncomfortable questions. People will tell you all kinds of interesting oh-by-the-way facts and never have the guts to say they might not make their commitment unless you ask them directly. People don't realize what taking one extra day or a week for their little thing does to the project overall. You have to make them talk to each other and to you.
posted by ctmf at 6:02 PM on March 31, 2015
If A agrees to do thing 1 by date 1, B agrees to do thing 2 by date 2, and C needs thing 1 and thing 2 to do thing 3, no problem, right?
WRONG. A will forget to mention that their dates are moving unless someone is asking them every day. B will get other work from someone else that will have to either take a back seat or push your project. Nobody will have told C any of this, but C will have forgotten about their thing anyway and won't be ready to start on time.
UNLESS, you are going around checking on status constantly and asking the uncomfortable questions. People will tell you all kinds of interesting oh-by-the-way facts and never have the guts to say they might not make their commitment unless you ask them directly. People don't realize what taking one extra day or a week for their little thing does to the project overall. You have to make them talk to each other and to you.
posted by ctmf at 6:02 PM on March 31, 2015
Hiya. I'm a fulltime program manager, which is essentially a level up; I manage several projects, albeit I halfass some of them to get wider coverage.
A project manager puts certainty around a project. They might or might not put success around it, but if it's going to fail, they can tell you roughly when.
You figure out who the stakeholders are.
1. Who knows what needs to happen?
2. Who can tell you how it's going?
3. Who's going to do it? Who's their backup if they quit or win a cruise or something?
4. Who's your project sponsor? You don't ever hold a whip; the sponsor might.
You talk to the people who know what need to happen. You get them to break the work into tasks.
For each task, there are dependencies; tasks that have to come before it, or external things you don't control that you'll need to have before that task can start.
For each task, you'll also have "who will do this", "how long will it take once it starts", "does it have any risks", and whatnot.
You chain tasks together and make the schedule. The shortest, most optimal way through all the tasks (including dependencies) is called the critical path; if those start and finish back to back to back, that's the shortest time to finish this project.
You leave some time between tasks, or at the end, and that time is called slack. If you run out slack, the project is late. At that point (or before it!) discuss options for triage. Almost all projects run late, unless you aggressively plan to hit it ahead of time.
Anyways, again. Meet with people. Figure out tasks, times, and dependencies. Write it down someplace public. Let people know the schedule is there. On some regular repeating time, update the schedule, and let people know it's updated; maybe once a week.
If people need to know when to start, let them know their dependencies are done and they should get going. If something's behind and you don't know why, try to find out. If things are fucked and over your head, escalate sooner instead of later; failures are worse if they're swept under the rug, as later, it's clear you could have escalated sooner, and should have.
Also: you don't manage people, and that worry is someone else's job. You manage projects. Find a project sponsor, which is likely someone senior to you who's also managing people; someone with hire/fire/promote powers. You may want their help once or twice. You may want their advice half a dozen times. You ideally never need to use their help, but often use their advice. If something's stuck, and you can't budge it? You call them for advice and/or for help.
This person is often the person who can reward you if this job goes alright, and this person is *always* CC:ed when you update your schedule or whatnot; they follow your work at a distance pretty much continually, and are your backup. The trade is that *you're* doing some of the work that would have fallen to them, so it's in their best interest to help you succeed.
Also, overall? Don't get lost in the schedule or spreadsheets. It's largely about the people and personal contacts, and the communications you have. You described my job pretty damn accurately: "my approach is simply to communicate what is needed, and people either do it or they don't. If they don't, I communicate some more."
I'm terrible at spreadsheets, but I'm pretty tenacious and don't give up when it comes to having a chat. It's much more important to not burn a bridge than to get the spreadsheet/tracking doc/post-it-notes just right; my goal is to get my team behind the project, and to get myself behind the team. Sometimes too far behind, but that's a different rant.
posted by talldean at 8:29 PM on March 31, 2015 [1 favorite]
A project manager puts certainty around a project. They might or might not put success around it, but if it's going to fail, they can tell you roughly when.
You figure out who the stakeholders are.
1. Who knows what needs to happen?
2. Who can tell you how it's going?
3. Who's going to do it? Who's their backup if they quit or win a cruise or something?
4. Who's your project sponsor? You don't ever hold a whip; the sponsor might.
You talk to the people who know what need to happen. You get them to break the work into tasks.
For each task, there are dependencies; tasks that have to come before it, or external things you don't control that you'll need to have before that task can start.
For each task, you'll also have "who will do this", "how long will it take once it starts", "does it have any risks", and whatnot.
You chain tasks together and make the schedule. The shortest, most optimal way through all the tasks (including dependencies) is called the critical path; if those start and finish back to back to back, that's the shortest time to finish this project.
You leave some time between tasks, or at the end, and that time is called slack. If you run out slack, the project is late. At that point (or before it!) discuss options for triage. Almost all projects run late, unless you aggressively plan to hit it ahead of time.
Anyways, again. Meet with people. Figure out tasks, times, and dependencies. Write it down someplace public. Let people know the schedule is there. On some regular repeating time, update the schedule, and let people know it's updated; maybe once a week.
If people need to know when to start, let them know their dependencies are done and they should get going. If something's behind and you don't know why, try to find out. If things are fucked and over your head, escalate sooner instead of later; failures are worse if they're swept under the rug, as later, it's clear you could have escalated sooner, and should have.
Also: you don't manage people, and that worry is someone else's job. You manage projects. Find a project sponsor, which is likely someone senior to you who's also managing people; someone with hire/fire/promote powers. You may want their help once or twice. You may want their advice half a dozen times. You ideally never need to use their help, but often use their advice. If something's stuck, and you can't budge it? You call them for advice and/or for help.
This person is often the person who can reward you if this job goes alright, and this person is *always* CC:ed when you update your schedule or whatnot; they follow your work at a distance pretty much continually, and are your backup. The trade is that *you're* doing some of the work that would have fallen to them, so it's in their best interest to help you succeed.
Also, overall? Don't get lost in the schedule or spreadsheets. It's largely about the people and personal contacts, and the communications you have. You described my job pretty damn accurately: "my approach is simply to communicate what is needed, and people either do it or they don't. If they don't, I communicate some more."
I'm terrible at spreadsheets, but I'm pretty tenacious and don't give up when it comes to having a chat. It's much more important to not burn a bridge than to get the spreadsheet/tracking doc/post-it-notes just right; my goal is to get my team behind the project, and to get myself behind the team. Sometimes too far behind, but that's a different rant.
posted by talldean at 8:29 PM on March 31, 2015 [1 favorite]
Response by poster: Thanks so much, everyone, for your responses. Thanks to you, I am feeling slightly less panicked than I was this morning. Confront!
posted by pH Indicating Socks at 9:19 PM on March 31, 2015 [1 favorite]
posted by pH Indicating Socks at 9:19 PM on March 31, 2015 [1 favorite]
Excellent points above, from my experience of being project managed, rather than being a project manager, I'd only add recommending you read up on The Planning Fallacy on Wikipedia, it's useful to know when you're estimating timeframes, and when you're considering other people's estimations.
posted by DancingYear at 1:56 AM on April 1, 2015
posted by DancingYear at 1:56 AM on April 1, 2015
Great points above. You are lucky that you are not inheriting the project. How you set it up will be how it works. Your sponsor is key and they may fill you in on information that may not widely be known. That can be very important stuff. Keep note.
Tasks, dependencies, timeline. In my past life as a project manager, I was told to buy a boatload of national media for my project (TASK). The problem was that the funder had not submitted their check of support for my program (DEPENDENCY). I lost a full quarter of media exposure because of underestimating this dependency (TIMELINE). That hurt.
Gantt charts can be very helpful and there are some online planners out there (if you prefer a webtool rather than an Excel Sheet).
Good luck.
posted by zerobyproxy at 12:51 PM on April 1, 2015
Tasks, dependencies, timeline. In my past life as a project manager, I was told to buy a boatload of national media for my project (TASK). The problem was that the funder had not submitted their check of support for my program (DEPENDENCY). I lost a full quarter of media exposure because of underestimating this dependency (TIMELINE). That hurt.
Gantt charts can be very helpful and there are some online planners out there (if you prefer a webtool rather than an Excel Sheet).
Good luck.
posted by zerobyproxy at 12:51 PM on April 1, 2015
You shouldn't be worried about the project management aspect of this, but the fact that that is a HUGE amount of work for 1 person. So lets get started!
Count backwards from the publishable dates to see when you need reach all the critical milestones for each study. Find out who the team will be working on each study (or if it's the same team for all of them?). If you've never done this before, sit down with your manager or someone who has done this, and find out the expectations of each team member, and find out what other people need to be informed of these studies, even if they are not actively working on them (program leads? regulatory people?). Set up regular meetings on everyone's calendar, send out clear agendas before every meeting so people can see if they will need to attend. Give everyone the timelines for the milestones and get everyone's OK with regard to their portion of the work. Have regular status updates at each meeting, and if there are any recurring issues to getting certain tasks done, set time aside with that person and decide on what needs to be done to hurry that step up. If the regular meetings go on and some things don't get resolved, see if you can get more resources and escalate early if needed.
That's all the boring, logistical details. Aside from that, be excited about this, thank your team(s) genuinely, let them know you are available. Find someone who's done this before who can mentor you through this if this is your first time.
You got this!
posted by never.was.and.never.will.be. at 1:27 PM on April 1, 2015 [2 favorites]
Count backwards from the publishable dates to see when you need reach all the critical milestones for each study. Find out who the team will be working on each study (or if it's the same team for all of them?). If you've never done this before, sit down with your manager or someone who has done this, and find out the expectations of each team member, and find out what other people need to be informed of these studies, even if they are not actively working on them (program leads? regulatory people?). Set up regular meetings on everyone's calendar, send out clear agendas before every meeting so people can see if they will need to attend. Give everyone the timelines for the milestones and get everyone's OK with regard to their portion of the work. Have regular status updates at each meeting, and if there are any recurring issues to getting certain tasks done, set time aside with that person and decide on what needs to be done to hurry that step up. If the regular meetings go on and some things don't get resolved, see if you can get more resources and escalate early if needed.
That's all the boring, logistical details. Aside from that, be excited about this, thank your team(s) genuinely, let them know you are available. Find someone who's done this before who can mentor you through this if this is your first time.
You got this!
posted by never.was.and.never.will.be. at 1:27 PM on April 1, 2015 [2 favorites]
« Older Just get it out of my garage, please. | How do I keep iphone call records for longer? Newer »
This thread is closed to new comments.
posted by Lescha at 8:49 AM on March 31, 2015 [8 favorites]