Some very good answers here and whilst realising that chances of a serious non-superficial response posted rather late being up voted are fairly low I will still give it a try. If you really interested in what actual responsibilities of a software project manager are please read on.

You already know that a project is usually an attempt to accomplish a unique goal. It has a beginning and an end, constraints of time, budget and quality. The projects nature by definition is very much temporary as opposed to the process that keeps going all the time. Unfortunately, it is unusual for a bunch of people with very different agendas and from different backgrounds just to come together, get hold of resources, and achieve a pre-set goal within time constraints, on budget, and of an acceptable quality. Not within the business environment anyway and not without some co-ordination, negotiation, not when things constantly go wrong and the goal is not something each one of them will personally benefit from. And the job of a project manager is to make this effort happen in a safe, predictable and efficient manner and as the result hit the initial goal, solve the original problem or, when the goal changes in due course, to make sure it does not change just randomly or unreasonably or does not have any correlation with the original goal. The ultimate job of a project manager is to make sure that all this effort and resources are not wasted.

There is a framework to it, pretty much as we developers have our own frameworks we apply to all sorts of problems. For ease of understanding any project can be divided into five phases: definition, planning, organising, execution and closure. In real life they heavily overlap and any software development project goes through them more than once. Here are the things a software project manager is supposed to make sure happen as part of each of the stages:

Definition: what are we going to build?

• What software or feature are we going to build, what worry do we need to address or what opportunity to exploit?

• Is it financially viable?

• Technically feasible?

• How does it fit into larger context such as competition, long term strategic horizon, other opportunities and worries, legal issues or standards etc, social impact, political impact, political forces involved, environment?

• Who are the people and organisations who will get affected? Who is going to support us and who is likely to oppose?

• Are there any dependencies on other projects or important deadlines to meet?

Planning: how are we going to achieve the goal?

• What is exactly that we need to deliver (software, documentation etc) and when? When do we need to deliver each of these things?

• How are we going to get the funding? How much money and when should flow in and out?

• Who, when and for how long is going to be needed on the team? How are we going to get hold of them?

• What platform to use? What tools to use? How are we going to set up the development and test environments?

• How are we going to make sure that as we proceed the thingy we are building is actually what users want and it is reasonably defect free?

• What can go wrong and how likely? What is going to be the impact on what we do? How can we make sure we know about it coming as early as possible? How are we going to address if it happens (design round this issue altogether, outsource responsibility for this piece to someone external staight in the beginning and let them handle it, buy insurance, buy COTS, plan enough time or resource to address the issue if it happens, have a plan B, just accept the probability and hope it doesn’t happen)?

• How are we going to communicate? Within the team and to the external people? How often? How are we going to turn foes into friends or at least get them out of the way? Who is a friend? How we going to help them to help us? What is about John, he often works from home?

• We know that things are going to keep changing as we go along and discover new problems and possibilities. Hell, the whole thing is likely to take that long to build that the outside world is inevitably going to change, that’s for sure. How are we going to handle it? How are we going to make sure we stay on course and the course is relevant to the environment?

• And by the way, as a result we need 15 variants of that bloody product, all slightly different. How are we going to make sure that each one is working and consistent and keep the entire effort reasonable, how are we going to manage configurations?

• How are we going to get certification for the product to go on the market and make sure “Mums for Justice” approve of it?

• And we need to keep record of any expenditure, since the VC wants to know that we are spending reasonably.

• What development process to use? Would it make sense to specify as much up front as possible since we’ve got to forward some requirements for the hardware team, or do many small iterations to make sure we build that kids really love or chunk all the risky and uncertain technology stuff straight into the beginning of the schedule and create a little proof of the concept first?

Organising: making sure everything planned so far can happen.

• Agreeing with Bill that he will assign John and Cathy to the project

• Getting the development environment up and running

• Signing agreements that need to be signed

• Setting up online forum and the issue tracking database

• Getting these kids over for some user tests

• Making sure that right people attend right meeting

• Making infrastructure team order a new computer for Katie in time for the start of the project, following up endlessly

• Giving a call to certification committee: please send us the materials.

• Writing to the lawyers to draft up a user agreement

• Etc.

Executing: are we on track, what do we need to do next?

• Following up

• Monitoring: are we on schedule, within budget? Is quality ok? Are we confident the goal is achievable? Did everything we planned to happen up till now have actually happened? Didn’t? What would be the remedy? Who should I inform?

• Making sure information flows.

• Tackling deviations from the original plan: re-negotiating features, resource, deadlines, cost, and quality with everyone concerned.

• Deciding what to do if something we were afraid could happen has actually happened and what if happened something we didn’t anticipate?

• Help John and Cathy reach some decision on that important technical issue without harming furniture or each other or compromising on the product quality.

• Telling Bill that no, he can’t have John for couple of days to repair installation of MS Windows on his home PC.

• Co-ordinating

• Expediting, it seems that Katie needs a little help to start herself going in the mornings

• Cathy seems to be concerned by something and that really affects her performance, could that be the argument with John? Is it a home related issue? May be she needs some time off work, how is it going to affect the schedule?

• John is a great lad, but no, it is not acceptable to take that shortcut and we need to redo the entire piece. Need to mentor him, so he has some firmer inner guidance on these issues in the future.

• Reacting on the most recent “Mums for Justice” stance.

• Keeping the team spirits up.

• Asking VC to tell Bill, that it is really not ok to grab John for couple of days to repair installation of MS Windows on his home PC.

• Asking VC for extra money and justifying the cause.

• Getting an external consultant to help with the important issue that John and Cathy was talking about since it actually outside of our area of competence.

Closure: making sure we’ve reached a clean end.

• Archiving the documentation.

• Making sure deliverables are signed off and taken over by the customer.

• That the knowledge is transferred to the support team and all known issues go into maintenance.

• Making sure everyone got paid.

• What have we done really well, what do we need to improve next time?

• Dispose of any resources not longer needed.

• Good news need to go into press or company blog.

• Hey, we having a party!

• Generally tying up any loose ends, including signing a peace treaty with Bill; at least till the next time.

So it looks as if a project manager’s job mostly consists of answering everyone’s questions and making sure the right things do happen and wrong things don’t. And since the stages always overlap and often mix, and many project managers run several projects (that are at different phases) and additionally many software development project managers wear several hats at a time (i.e. BA or QA etc) the actual list of tasks is anything but boring.

By the way, many thanks, if you got to this point reading my reply. Means that it was really worth writting it.

Ask him. You may be surprised at what he says.

And don't be surprised if he asks you the same question back. After all you are busy posting here during the working day :-)

From the podcast discussion of this question ^[1]:

Spolsky: Here's my feeling about project managers:

One of the things that is interesting is that project managers, traditionally, are brought on because you have a team of yahoos - and this is just as true in construction, or in building an oil rig, or in any kind of project as it is in the making of anything - making a new car at general motors, or designing the new Boeing 787 dream liner - as it is in the software industry. Project managers are brought in because management says: "Hey, you yahoos! You're just working and working and working and never get the thing done and nobody knows how long it's going to take." If you don't know how long something's going to take and you can't control that a little bit then this really sucks from a business perspective. I mean; if you think of a typical business project - you invest some money and then you make some money back. The money you make back - the return on investment - might be double the amount of money you invest and then it's a good investment. But if the investment doubles because it took you twice as long to do this thing as you thought it would then you've lost all your profit on the thing. So this is bad for businesses to make decisions in the face of poor information about how long the project is going to take and so keeping a project on track and on schedule is really important.

It's so important that they started hiring people to do this and they said: "OK, you're the project manager - make sure that we're on track." These project managers were just bright college kids with spreadsheets and Microsoft project and clipboards. They pretty much had to go around with no authority what so ever and walk around the project and talk to the people and find out where things were up to and they spent all their time creating and maintaining these gigantic gantt charts - which everybody else ignored. So the gantt charts, and the Microsoft project, and all those project schedules, and all that kind of stuff, was an artifact created by a kind of low level person. Although it might be accurate depending on how good that low level person was, but it was still an output only thing from the current project: Where are we up to? What have we done? How much time have we spent? What's left? Who is working on what?

Then, for some reason, these relatively low level people, who were not actually domain experts, (if they were at Boeing they don't know anything about designing planes, if they were on the software team they're not programmers - they're project managers, and they don't know anything about writing code) they start getting blame when things went wrong and they started clamoring for more responsibility, more authority to actually make changes and to actually influence things and say: "Hey, Joe's taking too long here - we should get Mary to do this task, she's not busy." The truth is that they started getting frustrated because they were low level secretarial-like members of their teams and they wanted to move their profession up the scale so they created the project management institute - or whatever it's called - and they created this thing called... ah, I don't even know! But they created a whole professional way to learn to be a professional project manager and they decided to try to make it something a little bit fancier than just the kid with the clipboard that has to maintain these gantt charts all day long. You can tell this is what happened because the first thing project managers will tell you about their profession is that the most important thing is that they have the authority to actually change things and that they are the ones that actually have all the skills that can get a project back on track, or to keep a project on track, and therefore they need to have the authority to exercise these skills otherwise they'll never get anything done, they'll never be able to keep the project on track, they don't just want to be stenographers writing things down.

The trouble is, they don't actually have the domain skills - that's why they are project managers. If you are working on a software project you know how to bring it in on time and you've got to cut features, and you know which features to cut, becuase you understand software intrinsically and you know what things are slow and what things are fast and where you might be able to combine two features into one feature, where you might be able to take a shortcut. That's the stuff a good developer knows, that's not the stuff a project manager knows. In a construction project it's the architects and the head contractors who know where shortcuts can be taken and how to bring a project in on time not the project manager. The project managers don't have any of the right skills to affect the project and so they inevitably get really frustrated and everybody treats them like secretaries, or treats them like 'annoying boy with clipboard', when they really don't have a leadership role in the project - and they're not going to be able to because they don't have the domain expertise. No matter how much they learn about project management, no matter how many books they read, or how many certificates they get, no matter how long they've been doing project management: if they don't know about software, and software development, if they don't have that experience, they are always going to be second class citizens and they're never going to be able to fix a broken project.

Atwood: That's a great summary! Certainly I've had that experience and I think that, as a programmer, we value technical skills and it really is hard to take people seriously who don't even know enough to know if you are telling them complete BS. That's the danger. If you want somebody in that role, that's fine, it has to be someone who has a programming background or can tell when you are telling them crap, or lying to them, or not being straight with them. You just have to have some technical expertise is the key.

Spolsky: That's the most important thing: Every developer figures this out on day number five. All you've got to do if there's a feature that you don't want to do is you have to say that's going to take six years. And if there's a feature you really want to do you have to tell everybody it's going to take two weeks.

Good project managers are like umbrellas.

They keep the hot sun off you when too many nice new projects/task arrive which would distract your priorities.

They keep the cold rain off you when too many conflicting requirements and problems overwhelm you.

They fold up and get out of the way when you're doing fine and seem to be invisible. Secretly, though, they are attending meetings and managing expectations and simply protecting you.

They are always there in case you need them.

Yes, I know this is flippant to some degree, but so is the question.

It really depends on the situation, on the size of the team, on the company, on the product customer and on 100% different factors.

As a developer you might not be aware of what your PM is actually doing all day as he's shielding you from different things which you don't have to worry about: meetings with the customers, stakeholders reviews, auditors etc etc.

On a big projects in our company we have situation where are couple of PMs are involved and they both add value.

On some smaller projects I was involved into the team leader was able to effectively do most of organisation and that project shared the PM with another project in the same situation.

I know about one project which almost failed when the customer attempted to do so to save some expenses.

As with most jobs, there are some good and bad. If you are interested to know what project managers 'should' do doing all day. I'd suggest giving Scott Burkun's Making things happen ^[1] formerly the art of project management a read. Scott's a great writer, I wish more of the project manager's i knew had read this before starting.

FYI - The way I've approached project management in the past is to be the best buffer i can between the dev team and the business. I try to give the team enough space to get things done, only by interuppting enough to be able to report project status to the business.

Not text book project management but it's worked for me and the project's i've run.

A great project manager understands/does:

• the top level goals of the project (bird's eye view)
• manages the timeline of the project and its components
• understands some/most of the details in various technologies and project components
• reports to higher levels of management and the user base
• protects the uninterrupted time of the workers

More:

The hardest thing to do as a project manager is to say "no" to more features.

The next hardest thing is to balance the time spent on new features/bug fixes with their importance to the project.

The short answer is communicate.

The longer answer is:
Your PM acts as a filter between you (the grunt) and the project sponsor and the other stake holders. A good PM will never let you know about the politics and hassles that they are getting from upper management (kind of a sh*t shield).

Lots of that monitoring is actually so he (or she) can report back to the sponsors about where you area at in the project (and it's more than a simple we 25% done). At the same time the PM is busy making sure resources are available and preparing for that day when you walk into their office and say "We've got a big problem". A good PM should be able to say, "That's OK, I have a contingency plan for this". It everything works, most of their job is easy. However, as you know, everything doesn't always work.

They interrupt my flow by asking me for my TPS report..

Odds are, if (s)he is any good at what they do, you'll never see it. Same as if you are any good, the resulting code is indistinguishable from magic (to a lay-person anyway)

Of course, you'll not have to deal with the "customer", or answer stupid questions from senior managers wondering where their money is going, and why it's taking 3 extra months to do the project now, or extactly how to juggle your backlog so the thing that will generate $1000's is at the top, even tho it's not the bit that you lot WANT to work on.

You'll never see the budget meetings, resource meetings and negotiation, boring excel report production for managers who's attention span can't last more than 2 pages on their blackberry. Trust me, you never want to.

I suggest, strongly, you read " Managing Humans ^[1]", by Michael Lopp, aka Rands in Repose. ( amazon link ^[2]). He blogs ^[3], too. Worth it's weight in gold, and an easy read, too, 'cos his style is rather funny. PM's, Dev Managers and ESPECIALLY developers should read it.

Failing that, read what @Rahul said.

PM daily activity:

Ask each developer: "Is it done yet?" Then go back to hitting refresh on Lotus Notes and CNN while listening in on a few conference calls.

Rinse and repeat all day, everyday.

Your standard introduction to a new team member will probably start with...

Many, many years ago, I used to be a techie and used to code.... I got my MBA at...

Translation: I couldn't code to save my life. My management realized that I could not code. I talked a good game. I pushed to "manage" that which I didn't understand. So here I am today talking with you. Oh, and I have a MBA to "prove" I understand managing software development. When I get my bonus at the end of the year, you'll be the last thing that is on my mind when I spend it.

Project Managers monitor the health of the project and identify potential risk areas that need to be addressed. They ensure that the project is on-track and that the rest of the team has all the necessary resources to carry out their work. They act as an interface between the team and other stake holders like senior management, customers etc. All this so that people who do the real work (read developers) can work in peace without worrying about all these issues.

Managers, in this sense, act as enablers for the project team.

The ideal project manager runs around doing lots of things so that the developers have a clean run at the project. I like to think of curling ^[1] sweepers - the curling rock is slid along the ice, and the sweepers run along making sure the rock has a smooth ride.

That is the ideal I aim for when I have had to take on the project manager role - @ Totophil ^[2] covers the details of what is involved well.

I can also see merit in the umbrella analogy used by @ IDisposable ^[3].

And yet I have also known the bad examples mentioned by others when I have been the coder. I've been left to do all the communication with the client, dealing with other issues etc, while the project manager constantly bothered me for progress updates and the like. Not helpful.

So hope you get a good one :)

If you've watched The IT Crowd or Dilbert you get two examples of what Managers can do with their day:

1. Act as liaison for the team, providing them with the means to do their job. On top of that, assist the Project by enforcing methodologies, monitoring progress during different stages of the project, delegating tasks around the office and ensuring overall project morale.
2. SFA - If you don't know what that means, S stands for Sweet and A stands for All. Work the rest out yourself.

Believe it or not, being a Project Manager can be difficult, and it is often their heads that roll if a project fails. If you're interested in learning Project Management pick up a guide on the PRINCE2 examination and see what some PM's have to learn. Admittedly, very few PM's will use PRINCE2, but it just goes to show how they control a group and the art behind motivation in an IT/Office setting.

The best way I can sum it up is the PM is a liason / communication gateway btw the development and business teams. The PM sits between the two as a translation layer. Everything else they do is to support this goal.

Here are some links that you may find helpful.

http://en.wikipedia.org/wiki/Project_Management_Professional

http://en.wikipedia.org/wiki/ITIL

http://www.pmi.org

http://en.wikipedia.org/wiki/Project_manager

They spend a lot of time in meetings (at bigger companies)

1. Budget meetings, they are involved in setting up budget/manpower estimates for projects and presenting to upper management and changing the project plan based on money cuts or "throwing money at the problem".

2. Meetings with the project team to say where are we, when will this be done, etc...

3. Meetings with the business on long term plans to lay down future projects and to adjust that schedule.

4. They often develop the overall scope of a project on a high level working with the business analysts.

5. They often meet with the customer, lead any demos, negotiate on features, decide which features to drop/etc..

6. When a normal employee (developer) hits a stumbling block they help the developer to overcome it (dropping a feature, getting a new technology, having the business analyst clarify the requirements, encouraging discussions with others on other approaches, etc...).

Basically the project manager is accountable for the project and the client/upper managements' expectations on the project. They are often in charge of the scope and for deciding what does and does not get delivered. They also are in charge of the red tape when necessary and controlling resources on the project. Typically they are included in long term plans constantly giving estimated resources/time for projects to help the business people (not that the project manager is not often a business person himself/herself) plan.

Often one project manager gets many projects. If you add up all the time spent in meetings between the project team, stakeholders, and upper management there really isn't that much time left in a project manager's day. If a project manager is only in charge of a single project then I agree what do they do all day? But at my last company that had a ton of projects there were 2 managing all the projects going on in the department so they were pretty overloaded.

Delegate!!

They:

• Read email
• Delegate work
• Filter client's silliness out of the requirements
• Read more email

The PM is there to listen to and balance needs, requests and wishes from below and above his position.
Some days he is a liaison , others a firefighter.

To summarize:

1. Have a clear understanding of the "ultimate goal" of the project.
2. Effectively manage the resources and constraints both instrumental and detrimental to the project success.
3. Establish milestones throughout the project progression.
4. Keep the project team on task.
5. Circumnavigate the unforeseen issues which will arise throughout the course of the project.
6. Keep upper management up-to-date on project status.

You could go on for a while... the links that have been posted cover all of those finer points. I just highlighted some of the things I've seen/experienced in my career thus far.

Manage and Communicate.

There is that saying that an good developer can be 10x as productive as an average one, to which I usually add: "on a good day".

In that context, your job is to make sure your developers have many good days.

For the developers, make sure they know each day exactly what they should work on, and get any obstacles to that out of the way. Don't be that obstacle. Show enough technical understanding that they are willing to talk to you, and be open about what you don't understand so they trust you.

Towards management, be the interface to the developers, translate the wishes of the management into change requests and release schedules, translate the developers concerns and estimates into required ressources and delivery dates.

I'm coming in late, but here is my overview of a PM's responsibilities:

• Manages risk.
• Manages schedule.
• Manages scope.
• Manages budget.
• Manages project people and stakeholders.
• Decides on trade-offs between all of the above.
• Keeps the overall heading towards the project's strategic goals.
• Facilitates communication and collaboration.
• Anticipates and removes obstacles from the team's path.
• Takes responsibility for the team's successes and failures.
• The art of doing with one dollar what any damn fool can do with two.

This is what they do: Who Shall Watch The Watchers Themselves? ^[1]

It seems that is the same everywhere: nobody likes their bosses or at least always has something similar to say about them:"He doesn't do a thing!" or "He doesn't understand about the work"...
In some cases it is true... I had more than 10 bosses already (my own boss now) and I can guarantee you that at least 50% of them were bad at their work.
But we don't really know their work, do we? Sure, we see somethings he/she does but we don't see it all.
And until you are in their shoes for sometime you will never know...

The most important role they play is, to shield the team from grumpy clients and face the bone heads themselves.

Delegating tasks, planning and the rest can be learnt; communicating properly - is innate

90% of project manager work is communication-related.

On any project someone needs to be thinking about

1) What is the complete list of things that need to be done?

2) At any point in the project: Roughly when will all the tasks be done?

On a small team of top-class developers this work can be informally spread amongst the team. As the size of the team or project grows (or the quality of the people goes down) there really needs to be a single person staying on top of this stuff or the project just won't get done in any reasonable time.

I think the mistake made on a lot of small/medium sized projects is to appoint a non-technical PM to do these tasks when the technical lead could be doing it more accurately and with less friction.

Do you mean this question ^[1]?

Determine where the greatest project risks are and focus on those. This could take the form of following up on deliverables, ensuring the developers have the tools they need, gathering additional details on the requirements, setting expectations with the client and /or sponsors, ensuring everyone is effectively communicating.

A well run, well organized group does not really need a project manager. A PM is there to ensure the greatest probability of delivering the product at the least cost.

If someone uninstall the MS excel, MS word and outlook from their systems, certainly they do not have any work.

Take all opportunity to say : "That's what she said !" (Michael Scott)

Better late then never ;-)

Just like you could ask what do programmers do all day, the same goes for project managers, product managers, secretaries, cleaners, UI designers... I think a serious developer should play other roles some time in their career, at least for a couple of months to appreciate what effort that goes into that work.

I know we developers may sometimes give off on project management if things go wrong. Its easy to blame the other although in fact you are part of the same team and you yourself could have dome something about it. (provided the PM built team in the first place instead of just throwing a bunch of programmers in a room.)

On the other hand we could ask what the bleep he is doing all day, when everything seems to go just perfect (we don't seem to need him). Maybe that is just the situation he created, a perfectly workable atmosphere without constant interruptions from other teams.

I think you mean to ask "what are they supposed to do."

I would say the answer is they are supposed to be the alpha ape: smartest, strongest, fastest, whatever. Looked up to, deferred to, the one who gets to eat first, etc. This is just basic human primate instincts -- you're never going to get away from this unless you go live on a desert island by yourself. There will always be someone who bosses you around and most of the time there will be someone else you can boss around (even if it's just your little brother or dog).

you say what do they do "aside from monitoring" but that's the whole point. The alpha ape is watching you and will come over and beat on you if you don't stay in line. Chimpanzees really do this. We're really not that different. And yes, they get paid more for the same reason the alpha chimp gets the largest portion of the meal.

the fact that you're asking this question probably means you're starting to wonder if your boss does enough to earn his position as alpha ape. This is equivalent to one of the beta apes noticing that the alpha might be getting old, or weak, or maybe sick. Well, that's when it's time to challenge him -- go over to his cubical and try to beat him up (metaphorically of course). Challenge his decisions. Show initiative. Get involved in office politics. If you win, you get to be the alpha ape -- maybe taking over his job, making moving into another position. Then you get to be the fat cat, and do less physical work, and instead order people around. But you'll still have a boss -- another alpha above you.

Hmm, you don't want to challenge him? Instead you just want to post messages like this to stackoverflow? Maybe he's not as old or weak or sick as you thought.

Is it really that simple? Well, humans like to make everything very complex of course, but -- deep down, that's what's really happening, isn't it?

Or is it?

Over the course of their daily work, Project Managers try to solve the packing problem - with tribbles.