As I teach and coach
project managers, I'm struck by how many are stuck in command-and-control thinking: I must monitor all the work. I must check in with people to see that they are doing their jobs. I must know all the technical details and make technical decisions about the project. I'm sure there's more.
But that's not the role of the project manager. Nope. The project manager exists to create the path for the project team members to succeed. The way a project manager does that is:
- Select a lifecycle that manages the project's primary risks
- Help the sponsors define what success means
- Help everyone define release criteria
- To be aware of and manage all kinds of risks. If those risks are technical and the pm has the capability to manage those risks, then the PM can make those decisions. But it's more likely the PM has to make sure someone on the team can make those technical decisions.
- Protect the team's process from outside influence. If the team wants to improve or change their process, great. If someone from the outside wants to impose something on the team, the PM has to protect the team.
- Allow the team to do the technical work and the pm does the rest-of-the-organization interfacing work
- Help the team see when they are making progress and when they are stuck.
Now, there are plenty of things the project the PM needs to do around progress:
- I like helping people define their inch-pebbles. In the case of an agile team, making sure the stories are sufficiently small. I often discover the team members don't know how to make their work units small enough to see progress.
- Notice when the team's process is not helping them make progress. For example, a long build time or lack of continuous integration can impede a team's progress. If you're the one enmeshed in the situation ("I have to wait for the build to finish" or "I have to wait for John to check in his changes") you may not realize you are not making progress. In that case, the pm needs to put a structure in place to make those problems obvious. On a non-agile project, I do this with one-on-ones. In an agile project, I do this standup meetings.
- Make sure everyone knows what is most important to work on now and next. I like ranked backlogs, no matter what kind of lifecycle you use on a project.
So, a PM doesn't need to be the center of the project and control everything. The PM can let the team be the center, and facilitate the team's work.
