Stakeholder management becomes even more important with a focus on empathy, negotiations and persuasiveness. where in the traditional way of working the focus was on project results using a formal mandate we now see a shift to business results realized by using influence without power. The competences of these project and programme managers have to change. To support this way of working we see frameworks on project level (PRINCE2 Agile, DSDM AgilePM and PMI APM) and at programme level (MSP and DSDM AgilePgM). If you want to transform your organization, open new product/market combinations, integrate departments, or merge different organizations I expect that most of the organizations will not have permanent teams in place to handle this. This is typically a task for a project or programme manager. If there is a need for a piece of specialist work we must select the right people and bring them together to deliver. And these teams can of course make use of agile ways of working or just choose the for them most appropriate delivery method. In those cases, where we need more than the already existing permanent teams we have to build these non-existing teams. If you have implemented one of these frameworks the need for a project or programme manager will decline but on the other hand they can take new roles like roadmap manager, integration manager, release train engineer, value stream engineer.ĭoes this mean we don’t need any more project or programme managers? I think for the coming years we definitely need project and programme managers. To mention a few: Nexus developed by Ken Schwaber, Scrum at Scale developed by Jeff Sutherland, SAFe developed by Dean Leffingwell, the Spotify model copied by several organizations, Less developed by Craig Larman and Bas Vodde and there are many more. You now see that several frameworks to support this level are being developed and used by many different organizations. Probable you could ask yourself, why do I want to make use of a temporary project manager? Is it not possible to have a permanent, maybe virtual, structure to take care of stakeholder management, dependency management and integration and have as a result a more or less continuous flow or at least short delivery cycles of changes bringing into production without ramping up and down project governance structures and teams. They still run projects and project managers will make use of these permanent agile delivery teams. In practice this works well for just a few teams, but what do you need if you have to make use of several component and feature teams to deliver one integrated solution? Scrum of scrums is not enough, you need a project manager to manage all stakeholders, all dependencies, the complexity and to deliver one integrated solution. The Scrum guide (developed by Ken Schwaber and Jeff Sutherland) gives some directions to use the scrum of scrums to align the teams and to make integration into one solution possible. We need to scale up from a single agile team to many agile teams. But in many occasions you need more than one agile team to implement the requested change. So for those changes that can be managed by a single agile team there is no need for a project manager.
The members are already together, are self-organizing and can be seen as part of the ‘run the business’ side of the organization. For these teams we don’t need a project manager to bring people together and structure and control the work. It is the product owner who prioritizes the work to be done by maintaining a backlog with potential features and user stories. What these teams are delivering is managed by a product owner. These small focussed agile teams are self-organizing and are continuously learning to deliver more with the same people and within the same time-boxes. These teams are able to deliver changes much faster by using Scrum, Kanban etc. This agile manifesto is embraced by many organizations and these organizations started to keep the people together who delivered e.g. As a reaction on these unsuccessful projects a group of people created the agile manifesto, and based on that several agile delivery frameworks were designed to help to deliver more successful projects.
But in many cases we are confronted with budget overruns, delays and unhappy customers because what is delivered is not what they really need.
We see project and programme managers bringing people together for a definite period of time to make this happen. Projects and programs are managed via ‘change the business’. Many frameworks use the model ‘run the business’ (permanent teams doing the work) versus ‘change the business’ (work will be done by temporary groups of people).
0 kommentar(er)
