Defining Your Role as the Project Manager

Me: “So, what are the 5-7 milestones you need to hit in order to do XYZ?”
Team member: “I thought that’s what you were here to tell me.”

More than once, I have sat down with project or workstream leaders, ready to talk about what they need to do to get the project from start to finish, and the team member stares at me blankly and expects me to know all of the answers. 

The role of a project manager can be defined in many different ways, and can actually be different depending on the project. In an earlier post, I wrote about how a project manager is responsible for everything, but also responsible for nothing. Now if that is not confusing, then I am not sure what is!

  Image courtesy of Vlado at FreeDigitalPhotos.net

Image courtesy of Vlado at FreeDigitalPhotos.net

So it is not surprising that some people are confused by what your role is as the project manager. They expect you to have all the answers, when in reality, you help facilitate conversations to help get to the answers. You ask questions, solve problems, play the devil’s advocate, and raise risks at the right times to make sure the team is thinking through each step. You also bring in past experiences and learnings from other projects so that you and the team do not make the same mistake twice.

But you are not the subject matter expert, and you must be clear with you project leads, workstream leads, and sponsors about that fact or else you will find yourself taking on work that someone else should be doing - not only because they own it, but because they can do it better!

So when people ask you to act as the subject matter expert, politely point out that they are the SMEs, and then clarify what you can do…

You can help them kick off the project, recommending the project charter as a good place to start outlining the high-level business case, project scope, and success criteria. Then you can use that document to rally and align your stakeholders.

You can help the team identify the project sponsor, project team, and project stakeholders at the start of the project. You may even have a list of stakeholders in your back pocket from lessons learned sessions you facilitated - stakeholders the team may not have thought of otherwise.

You can facilitate project planning – both high-level timelines and detailed project plans based on inputs from the subject matter experts that build in the right approvals, testing, and other typical project plan checkpoints.

You can suggest that change management planning begins in the early stages of the project, and advise the team to adjust the stakeholder engagement plan along the way as the team learns new information and continues to develop the solution.

You can ask the right questions so the team understands all of the upstream and downstream implications of the changes you plan to make, as well as the interdependencies with other projects or normal business activities that need to be considered. 

You can reinforce the fact that “red is good” and encourage the team to raise risks early and often so that the team can plan for and mitigate them, rather than hide them until it is too late to resolve them.

You can lead project governance – the meetings, team updates, status reports, and other activities to keep everyone informed in the most efficient way possible. And of course, you will always have an agenda for each meeting.

Wow, that’s a lot! And while there are more items you can add to this list, there is also an entire list of things you are NOT responsible for. Rather, your project sponsor, project team members, subject matter experts, workstream leads, etc. need to drive them.

So be clear with you stakeholders what your role is and what their roles are, and hold your team accountable to deliver on expectations.