Project Management Tips
August 4, 2008 11:50 AM Subscribe
I am now officially a full time project manager. I have no other responsibilities. I know all about project management methodology. But what I want to know about are the things you can't learn from a book. To the super hero project managers out there, what tools and techniques help you do your job better? How do you stay organized across multiple projects? Moleskines? Laptops? Wikis? How do you reduce administrative overhead and collect and disseminate information? How do you get people to do things when you aren't their direct manager? Turn me into a super hero pm!
This is from the perspective of a programmer who works often with project managers.
1. Great PM's remember all aspects of a project, and will track the results of your communications. E.g. "last week you told me X would take Y hours due to company Z does not have any sort of staging environment set up, how did that go, etc?" In other words, "are you done yet" is totally appropriate if it's apparent they're actually paying attention to what the project entails.
1.a. I've seen some successful PM's use bugtrack/projectflow/ticketing systems like salesforce or projectpier to help accomplish this preternatural attention to details.
2. programmers don't usually get paid for their social skills. Your role as an intermediary between the client and the people paying the programmer is absolutely invaluable.
A programmer is probably pretty practical, and as such expects to you actually "serve your purpose". To a programmer, the purpose is of a PM is to be organized for them so they can focus on producing the product under your more worldly guidance.
posted by judge.mentok.the.mindtaker at 12:23 PM on August 4, 2008 [1 favorite]
1. Great PM's remember all aspects of a project, and will track the results of your communications. E.g. "last week you told me X would take Y hours due to company Z does not have any sort of staging environment set up, how did that go, etc?" In other words, "are you done yet" is totally appropriate if it's apparent they're actually paying attention to what the project entails.
1.a. I've seen some successful PM's use bugtrack/projectflow/ticketing systems like salesforce or projectpier to help accomplish this preternatural attention to details.
2. programmers don't usually get paid for their social skills. Your role as an intermediary between the client and the people paying the programmer is absolutely invaluable.
A programmer is probably pretty practical, and as such expects to you actually "serve your purpose". To a programmer, the purpose is of a PM is to be organized for them so they can focus on producing the product under your more worldly guidance.
posted by judge.mentok.the.mindtaker at 12:23 PM on August 4, 2008 [1 favorite]
We've had great success at the office using WebCollab. One person manages it, all projects are tracked in it - and each employee logs in to record progress on projects/tasks. It automatically time/date-stamps all entries, allows file uploading/versioning, etc. Slick, and free.
posted by jbickers at 12:50 PM on August 4, 2008
posted by jbickers at 12:50 PM on August 4, 2008
Rands in Repose touches upon a lot of what you're asking. Bear with the advise about coffee cups and trips to Vegas and check out the management section specifically.
posted by griphus at 1:54 PM on August 4, 2008 [1 favorite]
posted by griphus at 1:54 PM on August 4, 2008 [1 favorite]
One important piece of advice I can give is to shun the mantra "on time and under budget". I've seen too many projects ultimately fail because the PM avoided making hard descisions when the initial idea/timeline/scope became unrealistic. When they should have had the difficult chat with management, they instead were bullied into delivering a project that ultimately didn't help anyone. But it was delivered on time and within budget, so their technical responsibility was fulfilled. Don't be that guy/girl.
posted by qwip at 2:36 PM on August 4, 2008
posted by qwip at 2:36 PM on August 4, 2008
The quote qwip used is incomplete. It's supposed t be on time, on budget and to spec. If you aren't meeting the specifications, time and budget aren't all that great. The spec is often the most difficult part. While often frustrating, requirements walkthroughs are your friend. On the other hand, if you want to frustrate and annoy your coders, keep coming back with revisions to the requirements.
The old saw is "There's good, fast and cheap - pick two." There are times when you'll trade off one in favor of the others. For instance, you may run over budget so that you can deliver the full scope or you may have a less fully functioned product to speed your time to market. It's okay, but remember your sponsor makes that decision. You make recommendations and execute - sponsor makes that decision.
Sometimes your sponsor will make himself scarce. Do not allow that. When your sponsor won't answer questions, clarify requirements or make decisions you need to stop work. You don't work with sponsor approval. Period. It'll avoid tons of "but I never approved that and it's all the PMs fault" conversations later.
posted by 26.2 at 5:13 PM on August 4, 2008
The old saw is "There's good, fast and cheap - pick two." There are times when you'll trade off one in favor of the others. For instance, you may run over budget so that you can deliver the full scope or you may have a less fully functioned product to speed your time to market. It's okay, but remember your sponsor makes that decision. You make recommendations and execute - sponsor makes that decision.
Sometimes your sponsor will make himself scarce. Do not allow that. When your sponsor won't answer questions, clarify requirements or make decisions you need to stop work. You don't work with sponsor approval. Period. It'll avoid tons of "but I never approved that and it's all the PMs fault" conversations later.
posted by 26.2 at 5:13 PM on August 4, 2008
- Double all time estimates from your team. If software development is involved, triple them. You'll still be wrong by a factor of 2.
- Your project will be 95% complete throughout 80% of it's production time. If your milestones aren't absolutely binary, they are absolutely worthless.
- Adding more people to a late project makes it later.
posted by jenkinsEar at 6:17 PM on August 4, 2008 [2 favorites]
- Your project will be 95% complete throughout 80% of it's production time. If your milestones aren't absolutely binary, they are absolutely worthless.
- Adding more people to a late project makes it later.
posted by jenkinsEar at 6:17 PM on August 4, 2008 [2 favorites]
The one thing the few truly superb PjMs I've worked with have in common -- since they differed in style, tools, approach, personality, and almost everything else -- is a dedication to understanding what was being built (for building-things-type-projects), from as many angles as possible -- technical, design, marketing, users, internal and external politics, etc. They don't tend to know any of it in as much depth as the specialists but they often end up being the only folks who know a little of *all* of the aspects. They also end up being some of the most passionate advocates for the project itself -- I guess thats actually a side effect of the understanding, but it could be the ohr way around, who knows?
Anyway, if you can be that person, everyone will love you and worship you and credit the success of the project to you.
posted by feckless at 7:08 PM on August 4, 2008 [1 favorite]
Anyway, if you can be that person, everyone will love you and worship you and credit the success of the project to you.
posted by feckless at 7:08 PM on August 4, 2008 [1 favorite]
I've just finished working, for the first time, with a project manager on a highly technical, non-programming project (a major divestiture). To my mind, the PM was very good. She kept on top of goals and timelines, prodded without nagging, and above all was willing to step in and help, not just manage, in any way she could. The timeline was very tight, and she took some work off the shoulders of the rest of the team that didn't require training....things like mass emailings. Her motto was "What have you done, and what can I do for you?" Maybe not something you can always do as a PM, but her willingness to be part of the project was a big hit for us.
posted by lhauser at 8:43 PM on August 4, 2008 [2 favorites]
posted by lhauser at 8:43 PM on August 4, 2008 [2 favorites]
Best answer: You need to stand up for the people on your team, as opposed to simply cracking the whip. Most PMs are terrible. They manage deadlines and that's about it.
MAKE a project plan. :-) Get your team's input. Pad the project plan. Plan for everything - reviews, changes, dependencies, etc. Never freak out. In my personal opinion, good PMs are more facilitators than decision-makers. Everyone on your team is an expert at one thing or another - facilitate and report decisions. PMs who think they are "the boss" are usually unpopular.
What tool you use to track the project depends on its complexity. For small projects use Word, for large projects use MS Project. I mean really large though.
I'll let you in on a secret to getting people to do more and do it faster: Ask them what they think is reasonable to produce by when. Asked, people will often come up with a tighter deadline and offer to do more than you would have asked for.
posted by xammerboy at 4:19 PM on August 5, 2008 [1 favorite]
MAKE a project plan. :-) Get your team's input. Pad the project plan. Plan for everything - reviews, changes, dependencies, etc. Never freak out. In my personal opinion, good PMs are more facilitators than decision-makers. Everyone on your team is an expert at one thing or another - facilitate and report decisions. PMs who think they are "the boss" are usually unpopular.
What tool you use to track the project depends on its complexity. For small projects use Word, for large projects use MS Project. I mean really large though.
I'll let you in on a secret to getting people to do more and do it faster: Ask them what they think is reasonable to produce by when. Asked, people will often come up with a tighter deadline and offer to do more than you would have asked for.
posted by xammerboy at 4:19 PM on August 5, 2008 [1 favorite]
This thread is closed to new comments.
Make decisions decisively, but only after you have the facts. Make the decisions yourself, but actively solicit suggestions from your team. Team means everybody gets to play, and everybody (including you) works to crry the load.
Trust the people who work for you, and trust them to do the right thing without your micromanagement. Your role is to provide your team with the tools (time, resources, information) they need to get the project done. Don't get in the way of that. And do it actively. Nothing's more frustrating than not being able to a do a job because of missing resources, and having a manager who just shrugs helplessly.
Different people have different ways of working. Realize that, and realize that means the most effective way to manage one person may fail dismakky with another. Learn to adapt to different people's different styles.
With coders, especially, asking "is it done yet?" isn't going to get you results. Asking non-confrontationally "what's making this difficult?" may however reveal things you can do to move things along. Technical people will be much more willing to go along with your decisions if they understand the rationale for a decision.
Manage your clients as well as your people. Make sure they understand what they want, and that you understand any hidden assumptions they have. Don't hide clients from your team, or vice-versa, but equally don't let either get in the others' minutiae.
posted by orthogonality at 12:11 PM on August 4, 2008