What value do project managers provide a software development team?

Question

What value does a project manager bring? How do they benefit the technical members of the team who do the work (e.g., the software developers)? Why should software developers prefer to have a project manager as part of their team? What are some reasons that might make them lobby to hire or recruit a project manager to join their team, if they don't already have one? How does a project manager make their life better?

Please pretend you are explaining this to a software developer (or other technical team member), and explain in language that they would appreciate.

Answer 1

Value is Not Automatic

What value do project managers provide a software development team?

In practice, project managers may or may not provide any value to the development team. Just like any other role in an organization, the PM role is just as much a victim of organizational hiring practices and the bell curve as any other role (such as "software developer"), and has exactly the same chances of being filled with mediocre performers or incompetent time-servers.

Project managers can and should add value to any project. It just isn't automatic just because someone is wearing the PM hat.

How Project Management Can Add Value to Software Teams

Project management is, from one point of view, the management of process and expectations. Even though Scrum doesn't use the title of Project Manager, it is definitely all about project management, and provides an illustrative example of the value that such management provides to software developers on the team when done correctly.

In Scrum, the Scrum Master provides the following value to the team and to the organization:

1. Communicates the Scrum framework requirements and associated processes throughout the organization.
2. Acts as a process referee.
3. In cooperation with the Product Owner, the Scrum Master protects the team from outside interference and scope creep.
4. Facilitates communication between the team and stakeholders.
5. In cooperation with the Scrum Team, the Scrum Master ensures that Sprint and project status are both transparent to the rest of the organization.
6. Coaches the development team towards self-organizing behavior.
7. Ensures that all work is made visible to the team and to the rest of the organization.
8. When the team identifies process impediments, the Scrum Master uses all available organizational tools to communicate the impediments to the organization, and mitigates them whenever possible.
9. In practice, the Scrum Master is often the repository of various framework artifacts such as the Sprint Backlog, as well as metrics such as burn-down charts. (Whether this is ideal is debatable, but it's usually the case.)
10. The Scrum Master coordinates essential framework activities such as the daily stand-up, the Sprint Review, and the Sprint Retrospective.

In short, the Scrum Master role is an enabling role. Whether your framework is agile or traditional, project management provides structure to the project.

Identify Why Project Management is a Hard Sell

If project management (as a framework) or a project manager (as a role) is a hard sell within your organization, then you need to unearth the reasons why this may be so. Has your team had bad experiences with particular individuals or frameworks in the past? Has your organization found project management more of a hindrance than an asset?

Whatever the reason, until you fully understand the context, evangelizing a framework or role will be an exercise in futility. Project management is designed to solve various business problems; make sure you know what those business problems actually are (for both the organization and the software development team) before you try to solve them prescriptively.

Answer 2

I've served as a project manager on several software development teams, and the analogies I like best are these:

• I'm the sweeper on the curling team.
• Or: I'm downriver from the team, clearing the big logs that are going to slow down progress.

Think about it this way: Software developers bring a set of very specialized skills to the table, and when they spend their time tracking down other team members to find out about the status of an upcoming handoff, they're not applying any of those skills. When they have to go ask for more people, an additional server, or more funding, they're usually not the best person for those jobs. Simply put, from the software developer's perspective, a project manager should let you focus on your true work.

Answer 3

Regardless of the industry or project type, someone has to watch the budget, the schedule, the status of upcoming components, deal with change requests, verify requirements are being met, referee disagreements of misunderstandings, stand up for the team, make progress is as promised, report to both management and client, etc.

It's both easier, and more sensible to have one person doing that rather than having 'the team' handle it. Not only is it disorganized, but it adds another level of decision-making to the project - "who's going to handle this, or that"?

No matter the project, eventually someone has to act as coordinator for all the parts that aren't project specific or technical. Best to let someone focus only on those, so the team can focus on the work.

Answer 4

Apart from Brian Leach's answer, I haven't read the other ones as I'd like mine to be unbiased as possible. But on a software dev team, the PM is vital because someone has to keep a track of the basics:

a) Time
b) Milestones
c) Deliverables
d) Communication (by far, the most important)

I've worked both as a developer and a PM. PMs loved working with me because I, as a developer, placed a huge emphasis on d) (however, this is not the typical behaviour of a dev as their job is to address the requirements. I just went above and beyond explaining other scenarios and challenges).

Devs, on the other hand, loved my work as a PM because of that exact same emphasis on Communication - specifically, I'd deal with clients and would drill down into the details and provide them requirements that were as specific as possible.

The point is this: without a team member who possesses BOTH the ability to communicate clearly and understand requirements, developers need to realize that the onus of these tasks will fall on them. From my experience, I can guarantee that they would be more than happy to have a PM handle these aspects for them.

Answer 5

I believe that @Brian Leach has hit the key "Let you focus on your true work", but since @DW asked for language to help explain to a team member, let me offer a couple of other observations.

1) It is always better to work on a successful project than an unsuccessful project. Looks better on your resume, less draining to the soul. The PM's role is to make sure that the project is successful (and there is some statistical evidence to support that they are successful; unfortunately I can't call any to mind right now. Perhaps someone will edit this?)

2) PM should act as an umbrella - keeping "that which rolls downhill" off your head. The PM should be aware of anything that obstructs your work, and should be exerting maximum effort to remove the impediments and add lubricants. That includes managing status requests from outside, stopping scope creep/change, ensuring that managers/stakeholders/sponsors are aware of the value of the project and continue to sponsor/support the project, etc. If they're asking you to code in an obscure dialect of Cobol on a dual floppy PC with a monochrome amber monitor to develop a multi-platform game system, it is the PM's job to fight for a more reasonable set of requirements, so that the challenges you face are interesting challenges.

Answer 6

Project manager manages the lifecycle of project, where as the development team would manage a lifecycle of the software delivery. The concept of management of projects through ruthless control and planning is PM.

By ruthless control and planning, by no means do I mean dictatorship, it's the people who can make a project a success or failure. I have been a developer, project manager, scrum master and a portfolio manager now. As a developer I used to ask the same question why do we need PMs? as I moved into management I realised that PM is actually a science, it's the art of managing people, expectations, realising goals. End of the day it takes someone to be there an motivate a whole lot - constantly through the journey to achieve results.

If software developers understand this, they can manage, but they would be fulfilling the role of a project manager.