The Changing Role of the Project Manager

Transcript of The Project Manager’s Changing Role, from the Free Webinar Series to Create an Agile Organisation, on 1st October 2019. Presented by Laura Re Turner, Director, Future Focus Coaching.

Subscribe to our bi-weekly newsletter.

Good afternoon everyone. Thanks so much for joining the webinar today, The Changing Role of the Project Manager.

What I want to cover today on the webinar is understanding how the project manager’s role changes when we’re using an Agile Project Management approach. Working in an agile environment where we’ve chosen to deliver a project in a very complex environment that has lots of business change.

Agile Project Management

I’d like to give a little introduction to Agile Project Management. Why might we use Agile Project Management over a traditional approach? Well, organisations that want to adapt their project planning practices to complex and changing environments will use an Agile approach which has very short planning horizons and allows us just to commit to a small amount of work at a time. Then decide based on what the business needs next in another short planning horizon of usually a month or two months what needs to happen next. By committing to a very small amount of work at a time, it allows the business to change direction without having a difficult conversation about what to do with work that has been started but not finished.

Many organisations that want to use Agile Project management will use the Agile Project Framework. It’s based on Dynamic Systems Development Method (DSDM) and it is owned and maintained by the Agile Business Consortium. Scrum is the most popular for all the Agile frameworks in use today, but it’s only part of the story.

My favourite quote perhaps from the framework is the philosophy.

“The best business value emerges when projects are aligned to clear business goals, deliver frequently, and involve the collaboration of motivated and empowered people.” 

Agile Project Management Handbook V2

And this is different to most project management frameworks that we might have come across, which shall remain nameless today but we all know what they are. Frameworks that tend to be very process driven and heavy on, traceability, and documentation, and delivery of management products and artefacts. In agile projects, we emphasise the motivation and empowerment of the team in order to deliver the right solution for the business in a timely way.

Who is the PM in Scrum?

Now I mentioned Scrum and we’ve seen the polls. Those of you who attended my previous webinars know that Scrum is still, after many years, the most popular of all the agile frameworks in use today. In fact, when I work with my clients, I often hear “we don’t have project managers anymore” and it takes me by surprise because we still have projects. So why shouldn’t we have a project manager to hold the budget, and on-board resources, and manage risks and issues? I think this belief that there is no more project manager is that there is no project manager role in Scrum. Scrum is a product development framework, not a project management framework. Many organisations have successfully adapted their project governance and planning practices to bring in the iterative development, and empirical planning style, which is very popular in scrum and very effective when done well.

Scrum is a product development framework, not a project management framework. Many organisations have successfully adapted their project governance and planning practices to bring in the iterative development, and empirical planning style, which is very popular in Scrum and very effective when done well.

However, I meet people all the time who are looking to get some guidance on how to adapt their project management and the governance around Scrum. This is where Agile Project Management based on DSDM is full of terrific guidance. What we need to do is now start to think about two things; the leadership style of the project manager to be more facilitative than command and control; and use high level outcome-based planning to manage the team.

Motivated and Empowered People

First of all, the leadership style motivated and empowered people, motivated and empowered teams. The motivation of team members comes from allowing them to take responsibility for how they design and deliver products, solutions, and services that the business needs. Empowerment comes from trusting team members to make decisions within their areas of authority.

Agile PM Skills and Behaviours

High-level agile-style leadership for the team uses clear descriptions of the project goals, facilitation and coaching conversations to support the team. The project manager coordinates at a high level and leaves the detailed planning of the actual delivery of the solution at the task level to the team.

Some more details about what an agile project manager does in terms of their skills and behaviours, which is different to what we usually think of when we think of project managers:

  • Agile project managers perform high level project planning but not detailed planning inside sprints or time boxes.
  • Agile project managers still manage risks and issues but in an agile way. They are highly available and visible to the team.
  • Responsive handling problems escalated from the team in a management by exception way.
  • Monitoring progress against the high level plan. For example, a release plan as they’re called in scrum or delivery plans.
  • The project manager also motivates and ensures the impairment of the teams to meet their objectives, manages the working environment, including the physical locations of the teams to ensure they have face-to-face communication as much as possible.
  • Help and guidance to team members where difficult situations arise.
  • Ensuring effective and timely communication and provision of information to the project governance board and stakeholders. So stakeholder management and good communication is a huge part of this person’s role.

Outcome-Based Planning

I’d like to give you an example of what I mean by outcome-based planning. What I’ve done in the slide is I’ve really separated out the project manager’s high level view of the plan versus the team’s detailed view of the work that they deliver in very short planning horizons. So a project manager will typically have this outcome-based view or high-level view of the project and what needs to be delivered. The plan must describe business dates, release dates that are important to the business to meet business goals. Objectives of the plan releases which should be able to be described in one very clear sentence. 

For example, the objective of this release is to announce to the world that we sell books online. Release two the objective of this release is to communicate to the world what types of books are in our catalogue and which market segments we appeal to. Release three, the objective of this release is to provide additional ways for people to order and pay for books online. It’s very, very high level and does not at all get into the detailed work that the team needs to do because team members are the experts on how they can achieve the business goal or the need or the goal of a release.

Below the dotted line on the slide is where I’ve shown the team’s responsibility and the details on each sprint backlog or timebox plan or the team’s detailed plan of what they’re going to deliver in a two or four week period is entirely the team’s responsibility and we’re still seeing a lot of agile project managers assigning work or getting involved in how the team is working at the detailed level. This is one of the behaviours that we’re working hard to change. If we find that there’s some discomfort in project managers moving towards this very hands off kind of view of how they work with the team and allowing the team to decide how they deliver the work well, we have some leadership coaching available for you.

Note that what I’ve not done below the dotted line is fill in or illustrate the details of each and every sprint because in scrum we do empirical planning, meaning we look at the results of each sprint in order to understand what needs to be planned at the detailed level for each subsequent sprint. How does the team know that what they’re planning is the right thing? They always have that high level plan managed by the project manager in order to relate the work that they need to do at the detailed level back to the objective statements at the high level.

Benefits of Agile Leadership

I think it’s fair to say that there are some benefits of this style of leadership and management. For example, one of the project manager’s responsibilities we said was to facilitate meetings and have informal discussions with the team when problems arise. When the team makes decisions themselves about the evolving solution, it allows for them to create more options to solve problems rather than taking direction and executing the decision made by a single person.

Using agile-style leadership for example, coaching conversations rather than telling the team what to do or giving direction, using more open questions than giving solutions encourages the team members to think for themselves leading to greater commitment and buy-in to decisions that the team makes and ultimately leading to greater quality of the work that the team is doing.

When the PM’s high-level plan shows the business goals and drivers and key business dates, then the team understands why it’s being asked to do the work so that the team members can change and adapt the plan at the detailed level from Sprint to Sprint, not just delivering tasks blindly.


So I hope that really what’s your appetite about agile style leadership of the project manager and the new focus of that role. I’d love to hear your questions and I see that some questions are starting to come in, which is wonderful and I would love to just take a moment here and pause and allow you to think of any questions that you have about the benefits of agile style leadership. Perhaps some of the responsibilities that are summarised here. For example, the coaching skills or facilitating meetings or any queries or concerns about high level planning and what might be included in that high level plan or left out.

So some terrific questions coming in. I have a question from Alan. His question is, if you have two agile teams developing a product in parallel, would you expect the product manager to manage dependencies?

There is a manager, who oversees the teams and whether that person is called a product manager or a project manager, if it is a project with a budget that’s been allocated and a business case, there should be someone who can manage the working environment. This is what we mean by managing the working environment; understanding any dependencies between the teams and trying to reduce those dependencies by working with the teams to look for options as much as possible. When we add teams that are dependent on each other for parts of the solution, we increase complexity. Where in agile projects we’re looking to only deliver small pieces at a time in order to reduce the complexity of delivering very difficult solutions. So typically a project manager will also have that 30,000 foot view and be able to see across teams.

Thanks so much for the questions coming in. Virginia says she’s heard the term product owner or scrum master, which is closest to the project manager role? These are fantastic questions and ones that I get all the time. The product owner and scrum master roles come from scrum. And in scrum the product owner is the voice of the customer, the person who knows the most about the business value or business benefits that the team is expected to deliver. And the scrum master is a facilitator, sometimes also a member of the development team and working as a team leader. For example a scrum master or part time.

So which one is closest to the project manager role? Very interesting question. I’m seeing a lot of organisations assigning the scrum master role to the project manager. I guess at first when I started working with Agile Frameworks I didn’t really question it. Then I realised that in projects the project manager knows the most about the value that the project is meant to deliver because the project manager then needs to report on that progress to the project board on how the team is achieving the business benefits that we’re expecting. So to me the product owner role is really the closest to the project manager role and the scrum master role tends to be a trouble-shooter or a person who’s closest to the team, who knows many people in the organisation to help the team unblock issues and solve problems.

There’s some more questions coming in. Phil it’s really great to have you on the webinar today. Phil is a friend of mine, an excellent leadership coach and someone I do a lot of work with. He asks if the PM is working at a higher level, who’s responsible for spotting the interface gaps where the cracks in the woodwork? That’s a terrific question. Well, often there’s someone who has a little bit more experience and is able to help to see some of these issues as they arise and work with the team. That is often the scrum master or an agile project management, that person’s called the team leader.

In fact, Agile Frameworks, DSDM, Scrum, Extreme Programming, all of them have regular touch points for the team to be able to identify these cracks or interface gaps or issues while they’re still small before they become massive problems. For example, in scrum we have a daily scrum, which is a 15 minute meeting held at the same time, in the same place every day for the team to be able to identify these issues. DSDM calls it a daily stand up meeting. So does extreme programming, a daily stand up. These meetings are 14 members to be able to discuss what’s going well, what’s not going well, how can I help you today? How can I show you what I did on another project that was similar that might help you with this? When I’m finished with what I need to do today, I’m happy to sit with you and we can put two heads together.

Sometimes we’re finding that teams in those daily meetings aren’t having those open conversations. I have seen some evidence of different reasons for that and often, it comes down to leadership styles. Often when team members aren’t really trusted and empowered to make decisions to achieve a goal for that short planning horison, that two week or four week sprint, then they feel afraid to step up, and ask questions, and to openly describe problems that they’re having. Things tend to be kept to themselves.

So when the leader demonstrates that issues happen, problems occur and I trust you to find the right solutions to the problems come to me when you’re really stuck, then team members tend to talk about those things more openly. If when there’s a problem, the agile project manager is available to step in, there is nothing else that’s more important to an agile project manager than responding as soon as the guys come out of the daily stand up meeting and say the team down the hall has hijacked our test environments and we’re not going to be able to get our integration testing done by Thursday afternoon, which is the deadline that we had. So in fact, the motivation and the empowerment and the trust helps to spot these small problems quite quickly.

Often when team members aren’t really trusted and empowered to make decisions to achieve a goal for that short planning horison, that two week or four week sprint, then they feel afraid to step up, and ask questions, and to openly describe problems that they’re having.

We have another question from Alan. Thank you so much. We have the same issue, he says, our project manager is the scrum master. For me I don’t think it works. So interesting. It’s, yeah, I’m not sure where the pairing came from. I think I’m seeing a lot of organisations who maybe see this word master or scrum master. Like this is a person who is a task master or someone who’s in charge, and is responsible for orchestrating, the team somehow. I think some of the interpretations of the scrum master role kind of lost focus a little bit. In fact, the project manager as well as the scrum master role are more hands off, more facilitative than command and control. More management by exception, which means give the team some space and allow them to solve their own problems. As soon as there is an issue, we jump into action and we make it the most important thing for us to solve for them.

More questions coming in, brilliant. Thank you very much Virginia. I’m really happy that you found it really interesting about the scrum roles. Virginia says she’s a project manager who likes detail, a business analyst by trade. I like detail as well, I’m with you Virginia. I’m really not sure where she would best sit in the agile framework world, what a terrific question.

Well business analysts have some terrific skills with regard to properly analysing the business need and ensuring that there’s proper communication for everyone to understand the proposed solution and to gain buy-in. So the business analysts really I can see fitting in to either, the team leader or a scrum master role or the product owner role because the product owner often knows the most about the business need and can write very clear requirements to help the team.

So a business analyst in an agile environment needs to really manage change very carefully. We had a lot of traditional business analysts who would appear at the start of a project with a list of 5,000 detailed requirements and hand it over to the team and say, yup, this is exactly what the customer wants and they signed it in blood. Good luck and I’ll see you at the end when it comes time to do testing and I’ll see you then. Well, in fact, it’s more important than ever now for the business analyst to remain engaged because the focus of the team can change from sprint to sprint as they decide how best to achieve the business need that was described in the high-level plan.