Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Businesses Programming IT Technology

Tips For A Budding Project Manager? 98

TrippTDF writes "I just took a new job at a small software company as an assistant project manager. While I have a little management experience, none of it is related to software. What advice can you guys give me on not becoming a PHB? What are qualities that you wish your manager(s) had?"
This discussion has been archived. No new comments can be posted.

Tips For A Budding Project Manager?

Comments Filter:
  • by LostCluster ( 625375 ) * on Wednesday November 24, 2004 @12:15PM (#10909560)
    Programming is an activity based upon trial and error. As a result, it's very hard to predict how long writing any given piece of code is going to take. It's good to have a schedule of targets for the progress of a program, but you can't turn those target dates into deadlines without the risk that your programmers will rush through the task and deliver buggy code.
    • by shufler ( 262955 ) on Wednesday November 24, 2004 @12:30PM (#10909679) Homepage
      In an ideal world, this is how all programming projects would operate.

      However, we live in a world where deadlines are very real, very important beasts which will gladly destroy us if we ignore them.

      Upper management, shareholders, customers, or whoever expects the product by a certain time, not because they are fucking inconsiderate pricks, but because without the program, they cannot do whatever it actually is, that they do.

      For the sake of humanity, don't pull a DNF.
      • Try to stay ahead of the people's needs, and predict what they will find useful in the future. My department has done this successfully. I would have to say that my boss lets me have quite a bit of autonomy, and I produce good stuff for him. Very few items have real deadlines, and those things are usually menial tasks like scanning & editing & converting things, or programming projects for less responsive and less responsibile organizations.

        Provide the required amount of support, but always keep

    • "it's very hard to predict how long writing any given piece of code is going to take"

      Not true. You just need to learn how to estimate. The best method is to simply repeat your question as often as needed, in a more urgent tone of voice. Do this enough, and you'll be able to precisely estimate any project, no matter how vague or how far in the future, long before the customers have decided what the project will consist of.

      Sometimes this method gives you bad estimates, which you'll be able to spot, becau
  • My advice? (Score:5, Insightful)

    by grub ( 11606 ) <slashdot@grub.net> on Wednesday November 24, 2004 @12:15PM (#10909564) Homepage Journal

    What advice can you guys give me on not becoming a PHB? What are qualities that you wish your manager(s) had

    Speaking as someone who has been on both sides:

    Don't be a fake, your people will pick up on it.

    Don't pick sides. You aren't there to make friends, you're there to get a job done.

    Don't be afraid to say "I don't know" and defer to one of your people. It boosts their morale.

    Ensure you can back up your decisions with facts and data. Bad decisions will cost you respect and potential promotions. They may even get you demoted or unemployed.

    Don't talk shop with your people outside of work on a social level. Those that don't go out socially could perceive your decisions as biased. Ideally you'll minimize social interaction with small groups of your people.

    You can't demand respect from your people, it must be earned.

    A good manager should be though of as firm yet fair. Not a friend, not a drinkin' buddy, not someone easily influenced.

    Basically: you're a Grown-Up now. Your options are quite simple: take the ball and run with it or fail and go back to where you were. Heh, I re-read that and I thought "Man, you sound old." and I'm only 38... :)

    • by fiftyLou ( 472705 ) on Wednesday November 24, 2004 @12:19PM (#10909589)

      Heh, I re-read that and I thought "Man, you sound old." and I'm only 38... :)

      38? Dude, you are old!
    • All great points. One additional point, reflected from current experience:

      • Respect people's time. Understand that people have other priorities and that they can't be spending all their time working on yours. Obviously this varies with each project.

        • - B
      • And one that goes with this is:

        Pay attention to what people are actually producing and how it's advancing the project-- some of your best workers will quietly go about doing a great job, and often go unrecognized as a result. People who pull off heroic efforts to recover from near distaster often get rewarded even when the disaster was essentially of their own making. The people who plan well and do things on time and correctly prevent disasters, too, but they do it so well that nobody even notices. Ma
    • Re:My advice? (Score:4, Insightful)

      by egarland ( 120202 ) on Wednesday November 24, 2004 @02:11PM (#10910712)
      I agree with everything in the parent post.
      I'd add some more:

      • Remember, you're job is important. Doing it well will make everyone's lives easier.
      • Work hard but don't get buried. If you are too busy you can't do your job right.

      You're a coordinator. Just like in a real-time device, things break if they get overloaded. Managers are often ridiculed for not doing real work but this is actually important. All my good bosses had free time in their day. All my bad ones have seemed overworked. It's ok to get involved in doing actual work but it's best to say away from the deep projects (ones that require a lot of time to wrap your head around and pick back up if you get interrupted) and remember to keep a little time in your day to sit around and just let whatever's going on stew in your mind. Part of a project manager's job is to see obstacles that will show up in the future. It's hard to do that when you are head down working.
    • I agreee with a lot of this. I've never been a manager, but I've been under the best manager I could ever imagine for the past 11 months... that comes to an end next week due to a buyout and me transfering departments... joy. Anyway, I agree with all of these points except for the "not a friend, not a drinkin' buddy". I've become great friends with my manager, and it hasn't hurt our professional relationship in the least. It motivates me that much more to do a good job, because I know that my work reflects
    • I agree that one must keep some social distance. You may be forced to crack down on team members at some point or disappoint them in some manner, and its going to be much harder to do if you are drinking buddies.

      It pains me to say it, but polite but distant seems to be the safest mask to wear in the office.

    • Re:My advice? (Score:3, Insightful)

      by Twylite ( 234238 )

      Great list :) Here's a couple of skills and tasks I consider essential:

      1. Know management: get yourself a good introductory book (not a 21 day guide to being an MBA). The areas you need to understand are general management, marketing (seriously!), and operations. Project management is part of the operations function. You need to understand basic management concepts like planning, leading, organizing and controlling.
      2. Understand quality, productivity and risk: these are core operations concepts that m
  • ... that should be a good start.
  • by LostCluster ( 625375 ) * on Wednesday November 24, 2004 @12:18PM (#10909580)
    A good rule of thumb is that you should allocate the same length of time to debugging as writing the original code, because a program that works under pristine conditions might look finished to the untrained eye, but it isn't. Every possible "exception case" such as when the user gives an out-of-bounds valus needs to have a specific error trap written to handle the error before it crashes the program.
  • by Doc Ruby ( 173196 ) on Wednesday November 24, 2004 @12:20PM (#10909598) Homepage Journal
    When you don't know the answer to a question, say "I don't know". Listen to the reaction of the questioner. If possible, provisionally accept any answer they give, provided it checks out, then check it out. Either yourself, or by assigning that task to someone. Always follow up as briefly as possible with confirmation or correction. Once you've been the conduit for an answer you learned, you should remember it, so you don't have to say "I don't know" again, when you should know after the first round.

    If you do this well, you can say "I don't know" quite often, keeping your manager status and respect based on your validation and info distribution alone. Of course, you should also be learning the answers to questions, even anticipating the questions as much as possible. The key to keeping your dignity is not to pretend to know what you don't, and to enforce the scope on questions you're responsible for answering.
    • I agree; people who can't say "I don't know" are not management material. The kind of people that can't say "I don't know" are usually the programmers, in my experience, who all too often put way too much weight on what they know and not enough (or any) on whether they can work well in a community, which is far more important. There's nothing I hate more than a analytical personality putting others down for asking questions or misunderstanding something. That is the worst possible quality to have in managem
    • My daddy always used to say:

      "I don't know," is never a good answer, but it is often the right answer.

      Time and time again, I've seen management make weird ass technical decisions which every techinical person disagreed with. It's a bad thing. If the majority of your programmers say that Ruby is the right language for teh job, they may be right. Sometimes you do have to steam-roll over people with legit ideas in order to get anything done, but don't do it arbitrarily, just because you have the power to.
      • My daddy always used to say:

        "I don't know," is never a good answer, but it is often the right answer.

        Reminds me of my asm instructor in college -- on exams he would actually subtract points for wrong answers (and do nothing on questions left blank). He told us guessing is a bad habit to get into, and he didn't want anyone writing, say, auto-pilot software, just guessing when they weren't really sure.

      • Sometimes you do have to steam-roll over people with legit ideas in order to get anything done, but don't do it arbitrarily, just because you have the power to

        In my experience it's better not to steamroll, but to actually get the relevant people together (everyone affected by the decision) and be very explicit about the fact that you don't know whether it's the best decision (and that it probably isn't), but that some decision has to be made in order for the project to move forward, and there isn't enough
  • by GoofyBoy ( 44399 ) on Wednesday November 24, 2004 @12:24PM (#10909618) Journal
    Actually, learn how to say "Go to hell and leave me and my programmers alone.".

    Note: I'm not saying to not listen to your end-users/customers and understand them. Just don't become this mindless "Yes-man" and sacrifice your team.
    • Especially as your customers (internal and external) will notice really soon that you are a Yes-man (if they are not completely braindead, but in that respect most of them aren't) and you will be that "Yeah, he always promises the sky but never delivers" guy everyone really hates and that finally noone even belives the time of day from.

      What everyone wants is to get the job done, but no empty promises you cannot live up to.
    • My boss is doing exactly this right now.

      Last week, one of the VP's was chewing my ass because some code that was moved into production 3 hours after its creation wasn't 100% correct. I stuck up for myself and said, "this is the very first initial version, it's not going to be perfect".

      After the VP left, my boss assured me that the VP "is on our side". Oh, and he called me to come into work although I had Strepp throat.

      Project Managers, support your people. You don't have to risk your jobs, but try to
    • by j3110 ( 193209 ) <samterrellNO@SPAMgmail.com> on Wednesday November 24, 2004 @01:43PM (#10910383) Homepage
      Well... It's the managers job to be more tactful. Get the priorities of the end user and have them rank the issues in terms of importance. A lot of times, you'll find that the end user is just saying "Wouldn't it be cool?" instead of "I would be willing to go over budget and wait a week for that!" They tend to get irrate when you go over budget and pass deadlines, especially when it's because of something they requested. No one wants to hear "I didn't know it would cost me that much!".

      The best thing to do is try to weed out the genuine concerns of the end user and present them to the dev team before making any estimates. Nothing angers a developer more than telling him that he has to stay up all night trying to meet an impossible deadline; and nothing angers an end user more than not having what they asked for for the price you give them or when you promised it. Always overestimate to the end user, and underestimate to the developers... it will all come out somewhere in the middle, and everyone will be happier. You won't have to slave drive your employees if something comes up (there is always something), and you won't have to apologize to the client.

      When doing your job, a manager must maintain respect and integrity. If you aren't given enough freedom to do that, I would resign and go to development or look for another job. Don't let them corner you into failure quietly! Let them try to find someone else who thinks they can do the job.
    • by dutky ( 20510 ) on Wednesday November 24, 2004 @04:25PM (#10912094) Homepage Journal
      GoofyBoy [slashdot.org] wrote:
      Actually, learn how to say "Go to hell and leave me and my programmers alone.".

      I'll second this, but it is only half the story: A good project manager has to be able to say "no" to everyone. You have to say "no" to unreasonable requests from clients/superiors in order to keep your team-member's plates clear to work on the important stuff. You also need to say "no" to your team-members when they either want to go off the reservation for whatever reason.

      A good manager, of any kind, acts as a wall between their people and the rest of the organization. They take care of conflicts and keep the team from getting distracted. They get the team what it needs to do it's job, and keep everything else out as much as possible.

      Read Slack [amazon.com] and Peopleware [amazon.com] by Tom DeMarco and Timothy Lister.

      • Saying no is a lousy thing for any project manager to say, and is one of the traits that would get them fired from any successful company. Project managers should be acutely aware that their competition is never saying "No" to your customers. A project manager's proper response is: "Sure no problem, but ..." For example:

        Employee wants time off: "Sure, but either get your work done or find someone to cover for you."

        Client wants you to do something that your company doesn't do: "Sure but I'll have t
        • I think you misread the submission - it says "What advice can you guys give me on not becoming a PHB?" (my emphasis)
          • Understood. No-one wants to be a dick, especially someone who just came up from the trenches. Double-especially if you happen to now be supervising the people you've been working with. Every tech person in the world has all kinds of good ideas about how to run projects, but very few get the opportunity to demonstrate it. Kudos to you for wanting to maintain yourself as a "B" while not becoming a "PHB".

            However, being a manager is hard. Whereas a tech person is required to go to work, do a competent j
    • Also, consult your programmers to see if something is possible before just telling the customers "sure, we can do that". I've had to make a hack job program to "trick" our main product into doing something it was not meant to do because of this. As you can imagine, it's no fun supporting crapware like this that I was embarrassed to make in the first place.
  • most 'managers' are people managers, not resource managers (esp not human resources!).

    Project managers do that - they act as the interface between the 'project' and the people doing the project. They are different to people managers, but still require people manager skills..
  • by DavidNWelton ( 142216 ) on Wednesday November 24, 2004 @12:27PM (#10909641) Homepage
    Have a look here:

    http://c2.com/cgi/wiki?ProjectManagement [c2.com]
  • by revans ( 253178 ) * on Wednesday November 24, 2004 @12:32PM (#10909694) Homepage
    The Project Managers job is not to:
    • design the product
    • code the product
    • build the product
    • QA the product
    • release the product
    • sell the product
    • nor fix the product.
    Your job is to try to get all the people who do these jobs to communicate with one another, and to try to be aware of and consider solutionS for ALL the issues involved with the product.
    To that extent you need good tools to make all the issues as plainly visible to all the constiuents as possible. Which leads to the question: what is the best toolset to do this?
  • A caution (Score:2, Insightful)

    by McMuffin Man ( 21896 )
    Asking employees what they want from their manager is something any good manager should do. But it is important to remember that what they're telling you is what it looks like from their side. Listen for what frustrates them more than for what they think you should do, because frequently it's as much about how you do something as what you do.

    For example, my team was frequently frustrated by sudden changes of plans from their previous manager. When I was on the team, so was I. When I asked what I should
    • Re:A caution (Score:2, Insightful)

      by Nos. ( 179609 )
      Can I work for you?
      The thing that has frustrated me the most with managers is being given a decision without any of the logic behind it. I remember submitting proposals for things we should be doing that if they gave me a few weeks of time (and an insignificant amount of budget) I figured I could save our team serveral hours of work a week. I put in the proposal (well researched). They asked for some clarification and to add a few things. I did so. At the end they said no. I can handle a proposal bein
    • Re:A caution (Score:3, Insightful)

      by bitingduck ( 810730 )
      that's a great point-- I even saw a similar thing in a presentation by Colin Powell that my boss a couple levels up had put on our section web site-- "Informed troops fight better"

      Everyone involved in a project should have a picture of the overall goal of the project (who the end customer is and why they want it), as well as be given insight into why their boss is making the decisions they're making, and as much as possible some insight into why the boss's boss is making whatever decisions are going on at
  • When you give a requirement (for a piece of functionality, for a coworker, for a supplier, ...) make sure that what you ask for is what you really want.

    For example,
    - Don't require team members to work 8am to 5pm each day. Instead require what you really want: that they execute on their part of the project within the specified timeframe and allocated resources. For some team members, this will necessesitate that they work during the so called "normal business hours", but for others, it won't
    - Don't requi
  • MS Project is your main tool - learn it - live it.

    As someone else mentioned, your main purpose is to be the glue that hold the various groups working on a project together. This is done through meetings, and schedules.

    You need to communicate, and clear up other's mis-communications. Keep asking questions - get the people to explain to you why something is going wrong. You'll eventually become an old hand at doing project estimates!
    • Any equivalents in OSS?
      • GanttProject [sourceforge.net] is nice. It's written in Java, so it's especially useful if you're not only using Windows. Works on Linux, works on OSX. It's the one I use. Of course it doesn't have all the features that MS Project does, but it's pretty useful for making initial drafts or working with relatively simple projects.

        There's also MrProject [codefactory.se] for Linux, I don't know if there's a binary for Windows. I compiled this on Linux once and it was nice but it broke pgAdmin, I think it was some version incompatibility with GTK

    • by jeif1k ( 809151 ) on Wednesday November 24, 2004 @01:37PM (#10910299)
      MS Project is your main tool - learn it - live it.

      Maybe it's your main tool.

      You'll eventually become an old hand at doing project estimates!

      That's nice. But projects aren't about delivering estimates, they are about delivering products.
      • Well - many people have to do project time estimates to when the contract.

        You are right about the job being - deliver the product, but if you don't have the contract in the first place, you're on the bread line!

        So - my point to the guy was that he needs to ask questions to learn HOW the work is done. This makes him better at his job in the future - and less of a pain to the people he has to bug all the time to get their progress reports!

        Also- like it or not - MSProject is the standard schedule package in
        • For goodness sake - That should be "WIN" the project.
        • Also, MSProject is a reasonable product. It does get the job done. Even though it comes from the Evil Empire -it still is a decent tool.

          I don't think MSProject (or its clones) gets the job done: it forces you to represent far too much detail and complexity far too early, and it will discourage you from exploring alternatives or making necessary changes.

          I think good project planning, like good design in general, is still best accomplished with paper, pencils, index cards, and tape.
  • Have a clue (Score:2, Interesting)

    by Tozog ( 599414 )
    Make a real effort to understand the projects you manage. Nothing is more frustrating than telling your manager what the project does, how it works, and what your role is, every single week. Not knowing all the details about feature a and b is ok, but at least know about feature a and b.

    Have as few meetings as possible. Managers seem to love meetings, underlings hate them. I do recommend one-on-one meetings with all your direct reports, but don't make them weekly. That's just overkill. Once a month, or twi
  • by Godeke ( 32895 ) * on Wednesday November 24, 2004 @01:16PM (#10910007)
    As the project manager, you will be responsible for the time the project takes to actually build, and reconciling the differences between what the team can actually do and management's desires for instant turnaround.

    The only way to resolve these two conflicting forces is with good hard data to back up any timetables you are presenting. The only way to achieve *that* is to break the work to be done down into the smallest chunks you can pallet. I personally refuse any time estimate larger than three days and look skeptically at those of one or two days.

    The reason for that is that any estimate of "oh, that will take a week" implies that the task has not yet been broken down far enough to actually understand the task. It is perfectly acceptable to say: "yes, but what is that week going to be used doing". Usually you will get "well, I need to revise A, B and C". At that point you can say "give me an estimate of A, B and C separately".

    Don't be surprised when the response is "but A B and C all require revising D". You have now achived forward progress understanding your work breakdown structure. D is a prerequisate for A, B and C, and yet your original estimate of one week may not have even considered that. Once you have tasks of "a couple of hours" and "half a day" you can be fairly sure that you have a handle on the tasks. But more importantly, if a task takes longer than it should, at the end of the day you can say "hey, I notice task D isn't done: what's up with that". It may turn out that D is an iceberg task... and you would have found that out a week later under the original estimate, now you have only spent a day learning that you have an iceberg and need to revise the schedule even more.

    The truth of the matter is that all programmers are optimists when confronted with a simply stated task and they will give overly optimistic time estimates until you actually start analysis of the problem. Creating a work breakdown structure that is fine grained (don't go completely overboard: "a couple of hours" is a good target point) will help you create your broad schedule with more realistic targets.

    Management will appreciate being able to back up your schedules with a fine grain detail (even if they ignore the detail itself) and your programmers will appreciate not being hit with iceberg tasks that kill the apparent productivity. Don't be suprised if the total of the fine grain schedule exceeds the initial WAG (wildly accurate guess) by a factor of 2 or more. Front loading the analysis usually uncovers many things that were ignored.
    • by Anonymous Coward
      Excellent guidelines!

      Make sure that the estimates include time for clarifying requirements and for the various forms of testing. I've worked with developers who will leave that out thinking that developing and coding are the same thing.

      The other thing to do is follow up and make sure that the estimates are being met. Once they begin to slip reanalyze the estimates and give your customer a heads up.

    • Front loading the analysis usually uncovers many things that were ignored.

      Which should include, depending on the developer's situation, time for interruptions, such as customers calling, and having to suddenly run off and put out a fire somewhere in already installed/was-supposed-to-be-working code. Also include time for mandatory corporate "training" that comes due every now and then, filling out forms/dealing with corporate bureaucracy for travel reimbursement et al. Also include any system downtime that

      • I'll take it that your work situation isn't very good. If you are being assigned to work at 100% workload you have a poor project manager. Actual working time varies from company to company: we have very few meetings, but we have overhead like anyone else and therefore don't expect 40 hours of assigned work to be completed in 40 working hours.

        Unless someone is totally unaware of reality, they should be using the "Working Time" defaults in the scheduling software to exclude meetings and other known overhead
  • Listen (Score:2, Insightful)

    by jskiff ( 746548 )
    Listening is probably the most important skill you can develop. You'll be bombarded on all sides: executives, programmers, sales people, marketing, etc. You're going to have to be able to listen to all of them and make decisions. Don't let any one group override and other particular group; you'll be tempted to let your programmers make all of the decisions, but remember that the reason you are there is to develop a product to sell for $$$.

    Learn how to communicate effectively in both written and verbal
  • Treat people with respect and listen to what they have to say. Being a bully or demanding 60 hour work weeks is not productive and results in a bad product.

    If you haven't done so take some courses in Conflict Resolution techniques or Interest Based Problem solving.

    Relish your role as the middle man - your role is twofold:

    When the staff need to protect themselves from some unreasonable demand they can refer it to you. They can then rely on you to carry their concerns upstairs in a neutral fashion.

  • by jeif1k ( 809151 ) on Wednesday November 24, 2004 @01:32PM (#10910221)
    What advice can you guys give me on not becoming a PHB?

    It's hard to be a PHB without having hair. You'll still make stupid decisions, but you'll look cooler doing it.
  • A couple of things (Score:2, Insightful)

    by rjshields ( 719665 )
    Admit it when you make a mistake or get things wrong, and learn to say sorry. People will find it easier to forgive you.

    Remember that there's no "I" in team. Do what's best for the team at all times and never let things get personal.

    Expect software projects to take longer than people initially think. Dilbert once said that to come up with a realistic estimate, you take your initial estimate and multiply it by eight. He has a point there.

    I have worked with PMs who can do none of these things and it
    • You don't say your sorry, that wouldn't be good. People don't forgive their co workers and project leaders if they say they are sorry. But they do forgive project leaders if they do own up to their mistakes.

      Right or wrong, you make decisions that affect and direct the entire team. The best way to do that is through accountability.

      If you make a wrong decision, its YOUR fault. Its not the teams fault or its not a specific team members fault.

      if as a whole, the team makes a wrong decision, its not THEIR mist
      • You don't say your sorry, that wouldn't be good. People don't forgive their co workers and project leaders if they say they are sorry. But they do forgive project leaders if they do own up to their mistakes.

        You wouldn't say sorry if you screwed up a project? Maybe this is a cultural difference, but I find that people will generally forgive you more easily if you aplogise. Apologising in itself is paramount to admitting responsibility.

        I would agree that it's very important to be able to own up to one'
    • I disagree, there is certainly an "I" in team, and there will be as long as the team has a human being in it.

      The important thing to do as a manager, is to be aware of all the different "I"'s throughout the team and to keep them well fed. Then the "I" doesn't get in the way.

      Also, be prepared to leave the project and move on to new ones. Software development always needs new talent and new brooms and that means developing the programmers to set up new projects and help you manage them, and bringing in new t
  • Don't expect people to do what they volunteered to do or have been asked/told to do. If you don't keep checking on them they will begin to screw off.

    The biggest mistake I made when starting out was to assume everyone was as interested in the success of the project as I was. Many times you will be the only person interested in the success of the project. Not even your boss or customers will be really interested. I have found this to be true on dozens of projects.

    It's a fine line between keeping people

    • Talk to everyone in your team, every day. It will give you a far better idea of how things are going than progress reports and formal meetings ever will. The conversation doesn't have to be about the project, complain about the weather, whatever.
    • Believe time estimates, if you start trying to trim them to meet artificial dates your team will start multiplying the number they first thought of by a fudge factor and you still won't meet the date.
    • Nobody outside the team gets to talk to people inside without c
    • The point about outside the team gets to talk to people inside without clearing it with you every single time is an excellent one, but I'd be careful about being quite so strict. Talk to your team and get them to understand that the main thing is to never make commitments to people outside of the team without clearing it with you.

      Beware the senior manager or exec who goes straight to developers and asks "how long do you think X will take"!

  • Surround yourself with the best people you can hire, beg, borrow, or steal. Your team should include a few "old hands" who have been through a number of projects before. Listen to what your people say, try to get them what they need, and try to insulate them from extraneous demands on their time.
  • How I do it. (Score:2, Insightful)

    by TomTraynor ( 82129 )
    If you use project management software (and it is a good idea to use it if you have it) I use the following metrics for % completed:

    0 - Not started (obvious)

    25 - Activity started

    50 - Work in progress

    80 - Ready for team review

    90 - Team review done and ready for client review

    100 - Completed and signoffs completed.

    When holding meetings try to set a standard number of days in advance for a notice. Also set a short and simple agenda. One that I usually use has the following items:

    Minutes from last me

    • "If you use project management software (and it is a good idea to use it if you have it) I use the following metrics for % completed:"
      • 0 - Not started (obvious)
      • 10 - At least one person available to work on the project
      • 20 - Have some sort of requirements
      • 50 - All software has been written
      • 75 - Software has been tested and shipped
      • 90 - Customer is using the product, isn't moaning as much anymore
      • 100 - Customers have stopped phoning you with annoying questions
      • "If you use project management software (and it is a good idea to use it if you have it) I use the following metrics for % completed:"
        • 0 - Not started (obvious)
        • 10 - At least one person available to work on the project
        • 20 - Have some sort of requirements
        • 50 - All software has been written
        • 75 - Software has been tested and shipped
        • 90 - Customer is using the product, isn't moaning as much anymore
        • 100 - Customers have stopped phoning you with annoying questions

        Yes, I agree with this list.

    • metrics for % completed:

      • 0 - Not started (obvious)
      • 25 - Activity started
      • 50 - Work in progress
      • 80 - Ready for team review
      • 90 - Team review done and ready for client review
      • 100 - Completed and signoffs completed.

      Let's be a bit more realistic:

      • 25 - Not started (getting it listed is half the work half the time)
      • 30 - Activity started
      • 35 - Work in progress
      • 40 - Ready for team review
      • 55 - Team review done and ready for client review
      • 85 - Completed and signoffs completed.

      And that last 85% optimistically assume

      • I actually have separate entries for team reviews, client reviews and signoffs. I try to keep each line to a specific task. Makes for a large Work Breakdown structure, but, you see at a glance who the bottleneck is for a project. For a simple one person project I usually have about 150+ items. Top line items are for project management. Followed by Pre-Analysis tasks, then Analysis, Design, Development, Testing, with Implementation being the last.
    • > Never ever put a team member down in front of the others or publically criticize the member.

      I just quit a job where I was constantly criticised in private and then the higher bosses were told how great I was in front of me, often within the space of a few minutes. This was extremely discomforting (especially since I was usually criticised for doing precisely what I was asked to do - or for not pointing out a problem when I had previously been glared at for pointing out future problems - even in meetin
      • I never pretend if I don't like someone. I try my best to keep my feelings to myself and work as a professional with the person. When I have a problem I try to work with the person privately on what the problem is and what we can do.

        At the end of the project where I am the team lead I must do an evaluation on each team member and that is a bitch of a job. My last project took me a day to do for the six members of my team.
  • I suggest that you have a look at Extreme Programming (read the book, not someone's web site!), which contains several useful ideas for sw of good quality on a predictable timetable. Although personally I found the more notorious features such as pair programming to be worthwhile, you will probably want to avoid these at first. This is ok - you don't have to adopt the whole thing.

    One useful idea is the concept of "project velocity": get your team to estimate the time for activities in ideal days, i.e. wi

  • ...if you want to piss off your underlings.

    Like everyone else, I've had to put up with a couple of real hardcore asinine bosses over the years. They were annoying, but after a while you get used to their rants and having to explain things to then three times before it sinks in. It's okay, I can deal with that.

    The ones I can't stand are managers on ant-depressants. They are just ass-kissing zombies who do not accept any feedback from anyone except their supervisor. It's like they're toddlers again and
  • Required reading?

    The Mythical Man-Month [amazon.com]

    Dynamics of Software Development [amazon.com]

    Death March [amazon.com]

    Understand the unique challenges that come with developing software. For instance, developers are by nature generally optimistic about technology, since they are in the business of finding creative ways to make the impossible possible. Listen to them carefully: if they're getting ground down, the project is probably in danger.

    Understand the relationship between Quality, Schedule, and Cost. The developers must have

  • Never hurts to educate yourself with some techie business books. I like Crossing the Chasm [amazon.com] by Geoffrey A. Moore, especially the way he talks about the "whole product" customer proposition. The Innovator's Dilemma [amazon.com] by Clayton M. Christensen was also a fun read, though it's not directly related to your problem per se.


  • by Embedded Geek ( 532893 ) on Wednesday November 24, 2004 @03:30PM (#10911474) Homepage
    What advice can you guys give me on not becoming a PHB?

    Always wear a crucifix. It should keep you safe but if it were to somehow fail and you begin to turn, the smoke from your roasting flesh will be noticed by your subordinates. Assuming you've been good to them before your fall, they will drive a stake through your heart as an act of mercy.

  • You might as a matter of course want to go over to http://www.pmi.org (Project Management Institute) and look into joining. That is the definative place to learn about project management itself. Suggest you think about joining and possibly signing up with PMI (there are likely to be local chapters around whom you can interact with). There is also a little book published by the American Society of Mechanical Engineers called "The Unwritten Laws of Engineering" by W.J. King (ISBN 0-7918-0641-3). It has a
  • by Anonymous Coward
    Managing programmers and other well trained specialists is not like managing unskilled workers. Don't try to order them around; just, direct their expertise towards your business needs.

    Unlike an unskilled worker, a specialist is valuable because of his special knowledge and skills. He knows more about his area of expertise than you do, by definition. Don't try to tell him how to do his job. Instead, tell him what needs doing: let him figure out how. That's exactly what he's trained to figure out.

    Your role
  • Project management is about managing the trade-offs among finite resources (time, people, money) to reach some defined goals in the context of an organization. Yes, you need (1) good skills in working with people and (2) domain-specific skills (IT operations, development, etc). In addition you need to develop specific skills and knowledge in project management.

    The project management profession has grown out of the experiece of failures and successes across many industries, organizations, and types of pr

  • I'm going to provide the same management advise I once gave to a relative. This may have already been said in this thread but I'll give it a go.

    1. A manager's job doesn't involve "Knowing" anything; it involves knowing who knows it and connecting them to the people with the questions.

    2. A manager doesn't solve or identify problems; a manager brings what could be problems to the people with the knowledge to solve them,
    and then LISTENS to their advice before making a decision.

    3. A manager is not an empl
  • Starting PM (Score:2, Interesting)

    1. Get Rapid Development: Taming Wild Software Schedules by Steve McConnell.
    2. Read it cover to cover twice. (Most PM's will do step one but never read the book)
    3. Find Top 10 Risk List in the Best Practices and do it.
    4. Profit!
    5. Start doing the other best practices in the book
    6. More Profit!
    7. The book is a great summary of information. Your primary job is a communications agent between everyone on the project, not as a coder, designer, etc.

      While you may asked to plan, you'll need to get the estimates from peopl

    • Get Rapid Development: Taming Wild Software Schedules by Steve McConnell

      And when you've read that, get Software Project Survival Guide by the same author and read it once - a year.

  • Keep the consultants out - and stick to those who are primarily techie service providers. The job of the consultant is to stir stuff up and replace you and your team with one firendly to their company.
  • As a manager, you are going to be responsible for coordinating the activities of developers, business people, testers, and system administrators. You're first rule is: I don't know nothing about nothing.

    Your experts are going to be your business people, developers, testers, and sysadmins. Listen to what they have to say. Don't poo-poo anybody because they are not good communicators.

    Once you have mastered the art of listening and understanding what people want and need, then you get to start trying to wres
  • by gristlebud ( 638970 ) on Wednesday November 24, 2004 @09:51PM (#10914987)
    As a Project Manager, you are responsible for interfacing between your clients and the team that reports to you. You are the face of the company. Dress nicer. Tighten up the e-mail etiquette. Use capital letters, punctuation, and spell check. Every time. Always assume that someone will forward your emails to your team, your client, and your boss.

    You are the leader of your project. You need to set an example for the attitude and morale of the teams that report to you. Always show up on time, and leave late. Never, never bitch about the customers or senior management. Never appear frazzled or irritated, as that attitude invariable trickles down to your team.

    You are responsible for everything that happens on the project. Not just the technical execution of the work, but also the accounting, invoicing, reporting, vendors, and subcontractors. Follow up on everything, because if it doesn't happen, it's always your fault.

    Always take opportunities to sell yourself and your company. Take every opportunity to call, or preferably visit your clients. I'm serious about this. Find out what your marketing budget is, and spend every nickel on visiting your clients. Eventually, they'll give you more work just to get rid of you. When dealing with a client, always keep your game face on. Know that you represent the best damn (whatever) company out there, and don't be afraid to take risks. Ask your clients often for more work. This can be a little uncomfortable, but rest assured that your competition is chasing the same work you are.

    Expect excellence from your teams. If you don't know enough about the subjects to judge whether the people are producing what they should be, find a trusted advisor who does know, and get their opinion. After clearing it with senior management, quietly solicit some bids from other companies (even overseas companies) on a task-by-task basis to make sure that you are getting the most out of your teams. However, don't be an ogre. Find out the difference between regular, everyday complaining that technical people do all the time and the honest-to-gosh complaining that signals something's really wrong.

    Limit senior management involvement. Always ask for help when you need it, but always propose a solution or a set of alternatives. You should try and schedule project reviews monthly or quarterly between senior management, QA, yourself and the task leads to make sure the project is on schedule and meeting performance objectives. Don't cc: half the damn company on every e-mail, and never when you chew someone's butt.

    Try and grow scope whenever possible. This ties into face time with the customer, but also knowing what other services your company can provide, and also knowing the specific scope of your project, so that you know when the client requests are going out of bounds. When you do win more work, make sure everyone knows it. This will be one of the things that your boss will be evaluating your performance on.

    Clients will always try and get more than what they are paying for, but limit the amount of freebies you give them, and ham it up a little when you give them one. ("You know, I could get fired for this, but since you're one of my best customers, I can make this happen.") Also, don't ever be afraid follow up on an invoice that is getting late. This might be a little embarrassing to the client, so this is probably best done over an e-mail.

    As much as possible, define what your requirements are to the teams that report to you. Not just "I need XYZ done," but "I need XYZ done by 21 December. You have 64 hours to do it in, and use charge code ABC123.QQ." If the teams have problems delivering, find out whether it's a problem with your schedule, the team's resources, or if you have unreasonable production estimates.

    Celebrate your teams' performance. Even if you're managing the project from hell, find something they're doing right, and send out a quick e-mail to your boss an
  • You haven't said if it is a small or large team. Since you are an assistant, I'll assume it is a large team.

    Make a small schedule and identify the milestones.
    "Socialize" the milestones.
    Find out if there are any objections to the milestone! Dig!
    Identify and remove objections: If someone is late or can't do something, find out why. Dig, cross reference. Remove the objection. If the objector objects too much, flag the person.
    Have no opinion on anything: you are pure communication.
    You don't know about
  • by angel'o'sphere ( 80593 ) on Thursday November 25, 2004 @06:15AM (#10917045) Journal
    As project manager you have 3 prime goals:

    Problem solving: figure what is the biggest obstacle preventing your team from making progress, remove that obstacle

    Staffing: figure who is he best guy for a job, hire the best people available with your budget, prefer one less or a few people less if needed in favour for better quallified staff

    Environment: keep optimizing tools and process! If a goal was not reached, why? Why? WHY? What can we do next time to prevent the same mistake? Different approach? Different tool? Different Process? For that you need to get a clue about "what does a software developer do in his dayly work?" You do not need to understand HOW he does his work, but WHAT and WHY ... e.g. he uses a version control system. Why does he do that, what is your benefit? Why is it a deep shit when the server running the version control software is down (Thats a BIG Problem -> solve it -> fix the server or get a new one)

    The last thing, Environment, is the most complex. E.g. while I suggest to allways have the BEST tools available, you won't go shopping on your first day and buy a set of 25 different new tools, because then the developers will learn/play the tools instead of developing.

    To become a good project manager, you finally only have two choices: shift your career towards medium sized teams, 20 to 30 developers or towards big projects with over 50 to some hundret developers.

    If you focus on small and medium sized teames, you have no chance. YOU MUST LEARN SOFTWARE DEVELOPMENT BASICS. You will allways be to close to the matter. A team of _good_ developpers, below 20 developers, simply does not need a project manager. If you want to feel respected and you want to provide value to the team, you need to dig into their work.

    OTOH, if you focus on bigger teams you will likely be farer away from developement and the first two points above, problem solving and staffing, basicaly all resource plannings, are more important.

    Finally, read something about SCRUM. (google for it) A modern project development approach mainly used in software development. A so called agile process and managment approach.

    Regardless where you work, SCRUM will revolutionize your habits.

  • I got linked to this site from /. some time, and I've since read a lot of the articles. There are lots of good ideas in here for making productive development teams. http://www.joelonsoftware.com/index.html/ [joelonsoftware.com]
  • Information (Score:3, Insightful)

    by the_womble ( 580291 ) on Thursday November 25, 2004 @10:08AM (#10917702) Homepage Journal
    Keep people informed, not jsut your management, but anyone on the project. When i had a job where I was basically a domiain expert, the biggest difference I noticed between the most experienced (and best) of the project managers I worked with and the least experienced was that the former kept me (and everyone else) in the loop. No surprises, especially no nasty surprises. Most importantly no problems with the client that I did not know about.
  • I ended up doing project management for the first time a couple of years ago and I've picked up some items that can help.
    1. Study up on your people skills. I know a couple of people who don't have a strong technical background but they have great people skills. They also seem to do the best job. Look for project management classes in your area for more info on this topic.
    2. Don't be afraid to cut scope or features. Sure, the users would like the upper right corner to turn pink when they hover over it on even

The trouble with the rat-race is that even if you win, you're still a rat. -- Lily Tomlin