Posted by
timothy
on from the don't-be-a-jerk dept.
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?"
Use goals, not deadlines...
by
LostCluster
·
· Score: 3, Insightful
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.
Re:Use goals, not deadlines...
by
shufler
·
· Score: 4, Insightful
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.
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...:)
-- Trolling is a art,
Re:My advice?
by
egarland
·
· Score: 3, Insightful
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.
-- set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
Great list:) Here's a couple of skills and tasks I consider essential:
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.
Understand quality, productivity and risk: these are core operations concepts that managers need to grok. They afford the world view you need to do things right, and to do the right thing, so that what you actually deliver is valuable to the customer. Take a look at my essay, The Quality Gap.
Enhance communications: as a manager once of your functions is to facilitate. Do this by improving communications. Be a conduit for dialog, but also put people (inside and outside the team or company) in touch with each other, and encourage them to talk directly and to communicate this information back to you and to other team members.
Protect your team: another of your functions is to be an interface. You should be involved in all communication, and people shouldn't be communicating without your knowledge. As an interface you establish the lines of communication, and ensure you are getting feedback on them, and spreading that information where it needs to go. At the same time you need to protect your team from unreasonable demands from customers and from managers outside the team. Know when to step in and say "this is my team, hands off". Most programmers don't like dealing with "business people" -- they will appreciate your intervention.
Know how to plan: get the tools and knowledge to create and monitor a project schedule. All estimates must come from the technical persons who will actually do the work! Be sure to include time in the plan for planning (!), requirements documentation, design, implementation, testing, configuration management and packaging, customer acceptance test, and maintenance. Understand the dependencies! Never forget that all this time your team is likely to be taking support calls, asked to provide a quick estimate on some other project you're quoting on, fix a few bugs on other products, talking on Slashdot;) In my experience you can only count on about 6 hours of project work per day!
Delegate and defer: you don't have all the technical or management knowledge to do everything. Don't be afraid to delegate, to defer decisions, or to accept the advise of those above, beside and below you. Everyone has a wealth of personal knowledge and can contribute to any problem you are facing. Welcome their advise, even if you don't follow it -- they will appreciate it, and it can benefit you.
Insist on sign-off: requirements must be signed off. Changes to requirements must be signed off. Customer acceptance tests must be signed off. Sign-off is a basic risk management techique that protects the company, the team, and your butt.
-- i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Plan to debug, you'll have to anyway.
by
LostCluster
·
· Score: 4, Insightful
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.
"I don't know" is not a crime.
by
Doc+Ruby
·
· Score: 2, Insightful
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.
--
--
make install -not war
Learn how to say "No"
by
GoofyBoy
·
· Score: 4, Insightful
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.
-- The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
Re:Learn how to say "No"
by
j3110
·
· Score: 4, Insightful
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.
-- Karma Clown
Re:Learn how to say "No"
by
dutky
·
· Score: 3, Insightful
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 and Peopleware by Tom DeMarco and Timothy Lister.
Communicate, and use good tools
by
revans
·
· Score: 4, Insightful
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
by
McMuffin+Man
·
· Score: 2, Insightful
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 do differently, "stick with the first plan" was a frequent answer. Once I was in the hot seat it became clear to me why we frequently had to make certain changes. Since I couldn't just stop the change, instead I started explaining to people why I was asking them to do things.
This frequently takes a lot of time, and frequently involves a lot of discussion while they go over the same ground that led me to the decision. They come with a reason to change my mind much less frequently than they probably would have supposed. The upshot of this, however, is that now they see why we need to make these decisions, they have a chance to change the decision when it was really as dumb as it looked at first glance, and so they feel a little less like it is something that is done to them by unreasoning powers.
The point here, again, is that I didn't change what I was doing all that much, but I changed how I was doing it a lot.
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 being turned down, but tell me why! Giving me a better understanding of why my proposal was turned down will save me frustration and probably time the next time I do up a proposal. No matter what I did, I couldnt' get a reason for it. After that, I hardly proposed anything any more. Some ideas I just went ahead and did, others I just dropped as soon as I thought of them.
I know in the long run my productivity dropped as did my morale. Its was the major factor in me looking (and finding) a new position.
Re:A caution
by
bitingduck
·
· Score: 2, Insightful
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 that level. Things that look silly or futile from down at the bottom can make a lot more sense in the context of the larger project, (or at least the bigger picture can expose that the silliness and futility are caused at a level beyond the project manager's control.)
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 forms. If you're seeing that the schedule is falling behind, don't wait until the last minute to alert the rest of the team to it. Put together a plan (we lost a lot of time because feature X was much more complex than we planned. We can either cut feature Y and hit our date, or add feature Y as planned on slip the date by a month) and present to the other decision makers in a concise fashion. Don't be argumentative...just logical.
Remember again that development does not take place in a vacuum; chances are your manager along with other executives made date and revenue commitments based on the development schedule. If it slips, or features change, they need to know ASAP. They have customers to sell to who need to know what's going to be in the product. They have marketing collateral and website updates that need to get in place. They have sales and tech support people that need to be trained. Your job is to make sure that all of these things can happen. The number 1 goal of any for-profit company is to make money. You need to give both your programmers and the other key stakeholders you work with the ability to do that.
-- It's "no one," not "noone." Who the hell is noone anyway?
A couple of things
by
rjshields
·
· Score: 2, Insightful
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 is no fun working with them at all (that's an understatement).
-- In this world nothing is certain but death, taxes and flawed car analogies.
Re:Project management 101
by
jeif1k
·
· Score: 3, Insightful
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.
Kicking a dead whale down the beach
by
peter+hoffman
·
· Score: 1, Insightful
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 moving forward and being overbearing but you have to find it.
How I do it.
by
TomTraynor
·
· Score: 2, Insightful
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 meeting
Project Status update
Upcoming deliverables
Other
Executive summary report template for sending to the client and your bosses. Keep everyone up-to-date at a high level, they probably don't want the gory details.
My meetings usually lasted 15 to 30 minutes each week. If they are on time and no problems I don't want to hear the gory details, they can send me a note on that. The only thing I want to hear is if there is a problem and what they have done to solve it and if they need me to help. On the 'Other' I poll each team member to see if they have anything to contribute.
If the client has praise I make sure that the team and their bosses know this. If there are problems I don't make them public, but, I discuss privately with the person to see how we can resolve the issue. Never ever put a team member down in front of the others or publically criticize the member.
At the end of the project hold a team meeting to review the project and the lessons learned. I usually bring in munchies and drinks.
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.
Learn to treat your staff as equals
by
Anonymous Coward
·
· Score: 1, Insightful
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, as manager, should be to ensure that your programmer has all the resources he needs; hardware, software, and most importantly, accurate information. Otherwise, you may end up with the perfect solution to a problem you don't actually have, and no solution for the problems you do.
Be aware that programming is closer to R&D than to manufacturing. It's the art and science of specifying, in very precise way, exactly what your business requirements are, in terms simple enough for a machine to understand.
So, always be as precise as you can. Remember, programmers can only create what you ask for, not some idea hiding in your head.
Respect your people. Learn as much as you can about what they do, can do, and can't do. Specialists spend their lives learning things in an attempt to do useful work; you'll get along better if you at least try, too.
Try not to do your expert's job for them. Don't tell your IT specialist: "I need a database" when you really just want a report. Ask for what you really want.
Understand that staring at a screen, trying to make a system work can be very frustrating. Be patient.
Programmers have to be precise, like an accountant, and at the same time, creative, like an author. They have to write code that is fast, efficient, and at the same time as clear and understandable as possible. They balance a lot of intangibles on a daily basis, with little or no external recognition. They're often under a lot of stress.
Think of an author who has to finish a book by a given deadline. Now, add in the requirement that all the punctuation in his hand-typed novel must be perfect, or the book will not be published, and you've got about the right level of stress for a programmer a week before a serious deadline.
So, to sum up, respect your people, stay out of their way, give them the resources they need, and understand the stress you're putting them under.
Oh, and don't be evil. Everyone hates evil people.:-)
-- AC
Re:Project management 101
by
jeif1k
·
· Score: 2, Insightful
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.
Re:Work Breakdown Structure
by
Bill+Dog
·
· Score: 2, Insightful
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 frequently recurs, such as periods of not being able to get into email or connect to a resource, or where the connection is so ridiculously slow that you read a book in between mouse clicks (try vss over vpn cross-country!). So assign me 20 tasks Mon morn that I've estimated each at "a couple of hours", but despite MS Project showing everything adding up neatly, don't expect them all done by Fri evening.
-- Attention zealots and haters: 00100 00100
Information
by
the_womble
·
· Score: 2, Insightful
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.
Slashdot Mirror
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.
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...
Trolling is a art,
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.
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.
--
make install -not war
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.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
- 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?
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 do differently, "stick with the first plan" was a frequent answer. Once I was in the hot seat it became clear to me why we frequently had to make certain changes. Since I couldn't just stop the change, instead I started explaining to people why I was asking them to do things.
This frequently takes a lot of time, and frequently involves a lot of discussion while they go over the same ground that led me to the decision. They come with a reason to change my mind much less frequently than they probably would have supposed. The upshot of this, however, is that now they see why we need to make these decisions, they have a chance to change the decision when it was really as dumb as it looked at first glance, and so they feel a little less like it is something that is done to them by unreasoning powers.
The point here, again, is that I didn't change what I was doing all that much, but I changed how I was doing it a lot.
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 forms. If you're seeing that the schedule is falling behind, don't wait until the last minute to alert the rest of the team to it. Put together a plan (we lost a lot of time because feature X was much more complex than we planned. We can either cut feature Y and hit our date, or add feature Y as planned on slip the date by a month) and present to the other decision makers in a concise fashion. Don't be argumentative...just logical.
Remember again that development does not take place in a vacuum; chances are your manager along with other executives made date and revenue commitments based on the development schedule. If it slips, or features change, they need to know ASAP. They have customers to sell to who need to know what's going to be in the product. They have marketing collateral and website updates that need to get in place. They have sales and tech support people that need to be trained. Your job is to make sure that all of these things can happen. The number 1 goal of any for-profit company is to make money. You need to give both your programmers and the other key stakeholders you work with the ability to do that.
It's "no one," not "noone." Who the hell is noone anyway?
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 is no fun working with them at all (that's an understatement).
In this world nothing is certain but death, taxes and flawed car analogies.
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.
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 moving forward and being overbearing but you have to find it.
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 meeting
Project Status update
Upcoming deliverables
Other
Executive summary report template for sending to the client and your bosses. Keep everyone up-to-date at a high level, they probably don't want the gory details.
My meetings usually lasted 15 to 30 minutes each week. If they are on time and no problems I don't want to hear the gory details, they can send me a note on that. The only thing I want to hear is if there is a problem and what they have done to solve it and if they need me to help. On the 'Other' I poll each team member to see if they have anything to contribute.
If the client has praise I make sure that the team and their bosses know this. If there are problems I don't make them public, but, I discuss privately with the person to see how we can resolve the issue. Never ever put a team member down in front of the others or publically criticize the member.
At the end of the project hold a team meeting to review the project and the lessons learned. I usually bring in munchies and drinks.
Panic now, beat the rush!
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.
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, as manager, should be to ensure that your programmer has all the resources he needs; hardware, software, and most importantly, accurate information. Otherwise, you may end up with the perfect solution to a problem you don't actually have, and no solution for the problems you do.
Be aware that programming is closer to R&D than to manufacturing. It's the art and science of specifying, in very precise way, exactly what your business requirements are, in terms simple enough for a machine to understand.
So, always be as precise as you can. Remember, programmers can only create what you ask for, not some idea hiding in your head.
Respect your people. Learn as much as you can about what they do, can do, and can't do. Specialists spend their lives learning things in an attempt to do useful work; you'll get along better if you at least try, too.
Try not to do your expert's job for them. Don't tell your IT specialist: "I need a database" when you really just want a report. Ask for what you really want.
Understand that staring at a screen, trying to make a system work can be very frustrating. Be patient.
Programmers have to be precise, like an accountant, and at the same time, creative, like an author. They have to write code that is fast, efficient, and at the same time as clear and understandable as possible. They balance a lot of intangibles on a daily basis, with little or no external recognition. They're often under a lot of stress.
Think of an author who has to finish a book by a given deadline. Now, add in the requirement that all the punctuation in his hand-typed novel must be perfect, or the book will not be published, and you've got about the right level of stress for a programmer a week before a serious deadline.
So, to sum up, respect your people, stay out of their way, give them the resources they need, and understand the stress you're putting them under.
Oh, and don't be evil. Everyone hates evil people.
--
AC
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.
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 frequently recurs, such as periods of not being able to get into email or connect to a resource, or where the connection is so ridiculously slow that you read a book in between mouse clicks (try vss over vpn cross-country!). So assign me 20 tasks Mon morn that I've estimated each at "a couple of hours", but despite MS Project showing everything adding up neatly, don't expect them all done by Fri evening.
Attention zealots and haters: 00100 00100
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.