You might have noticed it: there is no “Project Manager” role in Scrum, nor in SAFe. Is that it then – end of Project Management?
The aim for this post is to have a nuanced discussion on the fate of the Project Manager.
Spoiler alert: the Project Manager role is alive … mostly … but new tricks are needed.
Context and competence
Let’s take a big step back, asking “what is the purpose of Project Management, Scrum, SAFe etc.?“. The simple answer is, that they are all means to achieve a given set of objectives. The principle is of course to chose the means best suited for the objectives at hand.
These objectives are given by the context. Before even starting the discussion on the means, the context and thus the objectives need to be understood. As mentioner earlier e.g., here, the top-level context can be visualized as the matrix to the right.
The home for the classic project and thus the classic project manager is on the predictability-end of the optimization scale. Here you’ll typically find these characteristics:
- High initial certainty on what the customer really needs at the end of the project
- Scope is fixed and a detailed requirement specification is agreed
- You’ll typically use a Requirements Management [REQM] tool enabling a bi-directional link between requirements, Verification & Validation [V&V] and the developed solution
- A formal and structured Change Request process is agreed … because the reality is, that changes will happen
- The approach strategy is often based on a sequential stage-gate model
At the adaptability-end of the optimization scale we find “Agile” practices. According to the various “Agile text-books”, the classic project manager role has lost its relevance. Here you’ll typically find these characteristics:
- Low initial certainty on what the customer really needs at the end of the project
- Scope is variable and the initial agreement is based on an initial set of (high- level) requirements and a vision for the to-come product / service
- The “Agile Project” is based on ad-hoc Agile teams whereas in “Product Innovation” you’ll typically find stable, cross-functional and highly empowered product teams
- High-frequency customer / user alignment
- The approach strategy is often based on iterative learning / insight processes (using e.g., disciplined experiments) and incremental solution building in a way enabling frequent customer / user feedback loops
When confronted with the question “do you really not need the project manager?“, you’ll often hear answers like this from the Agile community :
“We do need a lot – not all – of the project manager competences … but we’ve mapped these competences in new agile roles thus no longer having a separate project manager role“
The three roles in Scrum thus need to cover the relevant competences in the project management toolbox.
The developers decide how to accomplish the work set forth by the product owner. Teams are structured and empowered to organize and manage their own work. The resulting synergy optimizes overall efficiency and effectiveness. Developers include anyone on the team that is contributing to the sprint goal.
The scrum master helps the scrum team perform at their highest level. They also protect the team from both internal and external distractions. Scrum Masters hold the scrum team accountable to their working agreements, scrum values, and to the scrum framework itself.
In SAFe you’ll find a lot more roles between which to map relevant project management competences.
The key SAFe roles and main responsibilities at team level are:
- Agile Team – responsible for delivery and quality of the work undertaken.
- Scrum Master – responsible for ensuring the team works well and follows the processes.
- Product Owner – responsible for prioritizing stories and ensuring they are well described and understood.
The key SAFe roles and main responsibilities at programme level are:
- Product Manager – responsible for prioritizing features and ensuring they are well described and understood.
- Release Train Engineer – responsible for ensuring the agile release train (the team of agile teams) work well together and follow the processes.
- Customer – consumes the output from the agile release train. Could be external customers or people within the organization. The customers are the people who will have the final view on whether the output was valuable.
- Business Owner – key stakeholders who are ultimately responsible for the business outcome.
- Architect/Engineer – responsible for designing and sharing the architectural vision across the agile release
The key SAFe roles and responsibilities at the solution level are:
- Solution Manager – responsible for prioritizing capabilities and ensuring they are well defined and understood.
- Solution Architect/Engineer – responsible for designing and sharing the architectural vision across multiple agile release trains, which means the solutions delivered will be fit for purpose.
- Solution Train Engineer – responsible for facilitating and guiding the work done by all of the agile release trains delivering the solution.
The key SAFe roles at portfolio level are:
- Epic Owners – responsible for defining an epic, articulating its benefits and facilitating its implementation.
- Enterprise Architect – drives architectural initiatives for the portfolio.
Other key roles include:
- SAFe Programme Consultant (SPC) – use their technical knowledge of SAFe to advance the organisation’s systems, and processes for developing systems. They are key to successfully implementing SAFe and often come from an internal centre of excellence or from an external consultancy. Agility in Mind has qualified SPCs as members of its consulting team.
I’m not at this point entering the heated debate on SAFe, but you might want to find a short discussion here.
The future of Project Management
We’ll still se a lot of customer / user pains / desires most effectively being handled as a project with a project manager and an ad-hoc project team.
The reality is also that the business environment and the enabling technologies are changing at a speed often making the idea of a big-upfront-specification, void. Is the experienced project manager with a solid toolbox not able to handle such a dynamic context? Of course he/she is!
The Agile community wanted (my interpretation) clearly and strongly to divorce itself from the classic way of doing (software) projects. The project manager role represented the “old way of working” to an extend that it was not welcome in the Agile role definitions – not even as a variant.
The project manager in an Agile context will thus not find a 1-1 mapping between the classic project manager role definition and one of the new Agile roles. Many of his/hers competences remain highly relevant – but dispersed among a number of Agile roles.
Strategies for the Project Manager in an increasingly Agile world
Get used to the fact that more and more “projects” will not ask for a “Project Manager” in the classic definition. You need to educate yourself in ways making your competences match the needs in the Agile context. Need some inspiration? Check-out some of my inspirational sources.
From being identified by a role-definition as Project Manager …
These tasks typically include:
- planning what work needs to be done, when and who’s going to do it;
- looking at the risks involved in a particular project and managing these risks;
- making sure the work is done to the right standard;
- motivating the team of people involved in the project;
- co-ordinating work done by different people;
- making sure the project is running on time and to budget;
- dealing with changes to the project as and when necessary;
- making sure the project delivers the expected outcomes and benefits;
… you need to identify yourself with your versatile competence toolbox enabling you to meet the Agile context on its premises.
The role as Project Manager is not dead, but more and more business / customer problems / desires are best handled in ways not needing the stand-alone Project Manager role.