Project Management
The modern PMO
Is it agile? Can you do that? Do you need this at all?
What does it look like, the “right” program management in a “VUCA” world?
„Companies that successfully scale up agile see major changes in their business. Scaling up shifts the mix of work so that the business is doing more innovation relative to routine operations. The business is better able to read changing conditions and priorities, develop adaptive solutions, and avoid the constant crises that so frequently hit traditional hierarchies.“ — Jeff Sutherland, co-developer of the SCRUM framework
Everywhere we look, we see projects. More and more, simultaneously, interlocked, interdependent. Especially in large companies, professional project management is of immense importance. And so it is precisely these large companies that have to reorganize their project management — not with self-learning algorithms, but with intrinsically motivated, self-learning project managers. Today, it’s no longer just a matter of delivering on time and within budget. Project managers become change agents, ambassadors of a new mindset — multipliers within the company in a constantly changing world.
VUCA, which stands for Volatility — Uncertainty — Complexity — Ambiguity. Everything is volatile. We live in a world that is constantly changing — in ever shorter cycles. Events occur unexpectedly and their course cannot always be explained by classical cause-and-effect principles. This increasingly poor predictability also increases uncertainty. Technology is developing virtually exponentially and is constantly creating new possibilities, which in turn give rise to new expectations.
The future is becoming much more complex — and less predictable. Globalization and digitization are creating a network of social, political and economic dependencies that is almost impossible to penetrate, especially when short-term decisions are required. If you shift your own perspective by just a few degrees, you often have to evaluate a situation in context completely differently. “The truth” is only the subjective perception of reality. Most of the time you have to realize that there are several truths, everything becomes ambiguous.
These general conditions increasingly face projects with new challenges and require us to act faster and more flexibly.
Are there still waterfalls in a VUCA world?
The classic project management method is the Waterfall model, a linear, sequential process model. This sequential logic of the Waterfall model is best understood in the context of construction or IT projects. Business conception, technical conception, design, implementation, test, roll-out and operations are carried out one after the other. The previously planned phases are consistently run through, released after completion and transferred to the next process step.
Already when reading, a feeling of disturbance quickly arises, right? Does this model still fit into the world described above? The focus here is very clearly on absolute planning reliability — at the expense of any necessary adaptability and flexibility. This means that even complex projects can be planned precisely and carried out reliably. Since all phases are carried out one after the other, decisions from earlier phases can no longer be revised — or only with immense effort and time delays. If the world around us changes in an unpredictable way, Waterfall projects are sometimes stopped, but often continued as planned, because all stakeholders had committed themselves to this approach and too much budget has already been invested in the project — one of the classic cognitive errors beautifully described by the philosopher Rolf Dobelli.
Often the need for necessary adaptations only becomes apparent when the project already is completed, as the business department usually withdraws from the project upon completion and handover of the business concept, devotes itself to its business again and waits for the project to be finalized. During implementation, the IT department is neither aware nor unaware that the business requirements have to change.
In contrast, the agile project management of a young generation, the typical method hammer that makes every project look like a nail at first. Agile projects are driven by business throughout, are iterative, fast, flexible and adaptable, always delivered on time and always in-budget. Really?
So, from now on, all projects are only agile?
Not at all. The agile methods originate from software development, the core of digitalization, and have their origins back in 2001. Even then, the focus was on speed and customer proximity. The product must be delivered to the customer. Period.
THE FOUR AGILE VALUES:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
And this is where you have to differentiate. Product and customer, two focal points of agile development. The more a project is a product to be developed and the closer it is developed to the end customer, the greater the benefits of agile development often become.
On the other hand, the closer a project is aimed at industrial production or industrial processes, the more constant requirements and no short-term correction loops are expected, the more participants need to be involved, the more the advantages of the Waterfall model often outweigh the disadvantages. If a Waterfall approach were to throw the developer of a mobile app out of the race for quick success today, an iterative pretense of building a house would probably lead to a catastrophe in terms of time and money. Unfortunately, mistakes in planning or implementation usually only become apparent at the end of the project. Correcting these errors at this late stage is correspondingly costly — the dark side of Waterfall projects.
Today, we can see that agile methods such as Scrum have found their way out of pure software development, but they are not always and everywhere the right answer to the question of management methods.
So it would also be a huge mistake to prescribe a complete, agile transformation to an existing company, just to achieve a faster reaction time as well as a higher adaptability. There are many ways to support a company become more agile with the help of a modern PMO, but there is no one-size-fits-all solution.
Linear or agile — black or white?
The two process models differ in terms of their static and variable project parameters: costs, time and scope. If costs and time are the variables in the Waterfall model, in the agile approach it is the to be delivered scope. A product can also be delivered with some features less or with higher but still calculable risks, as long as it fulfils its core function and reaches the customer quickly. The implementation of, for example, construction projects or the creation of production facilities, on the other hand, usually does not allow for any concessions in the scope of functions or quality and must be adjusted with regard to the completion date and budget.
On the one hand, the established top management often sees a “red rag” when they hear, a project is to be implemented in an agile manner. Too often agile is combined with uncertainty and chaos. They insist on control or steering committees, on comprehensive PowerPoint project reports and traffic light charts.
At the same time, however, for the same stakeholders it often does not happen fast enough, the project progress is not visible enough and in the end, when both the budget and the deadline have been exceeded, the result is far too often not appreciated by the customer. It is not uncommon for the project to develop beyond market expectations or to fail to take account of changes in the market in the meantime.
The classic Waterfall method often robs many project participants of their actual motivation, their pleasure to make progress. Partial successes are hardly to be achieved or not really visible in the first phases — who celebrates the completion of a business or technical concept? — and the project participants often feel overwhelmed by the project bureaucracy.
If Clayton M. Christensen, author of the 1997 fundamental book “The innovator’s dilemma”, accuses large companies of only being able to innovate incrementally, not disruptively, because they do not (cannot) question their traditional core business and do not (cannot) leave their evolutionary path, this can very well be transferred — beyond the question of disruption — to the topic of project management.
Agile projects work empirically, in small steps and with hypotheses to be proven. If a Waterfall project is based on one big hypothesis whose core can only be proven or disproved after completion, this is already possible after every sprint in agile projects. However, precisely this procedure often leads to the assumption that the project is only being developed at sight. This is a mistake. Every project, whether managed linearly or iteratively, has a clear goal.
„Agile’s test-and-learn approach is often described as incremental and iterative, but no one should mistake incremental development processes for incremental thinking.“ — Jeff Sutherland
The task of a modern Program Management Office is to meet management expectations with regard to the achievement of goals, adherence to schedules and budgets, to always have transparency about all projects currently running and yet to be able to reassess and prioritize partial scopes at certain points in time.
The contemporary PMO — an often underestimated function with many facets
In the past, a Program or Project Management Office was often seen as a mainly administrative function — the team behind the project manager, which prepares reports and presentations, coordinates appointments and books premises. Even then, the responsibilities of a PMO were actually much more extensive and today — whether it is in relation to waterfall or agile projects — the importance of a professional PMO is even greater.
A PMO today has many roles to play:
· PMO as connector
Besides the provision of project managers and Scrum masters, the PMO also has the additional task of “collecting” ongoing projects, networking the respective product owners on the business side and thus forming and moderating an interest group. If a PMO tries to simply impose new models, structures and standards on existing projects and organizational units, success will be hard and a long time coming. A very central difference between linear and agile project management is the integration with the business. In a traditional Waterfall project, if the business was the client, who — if he conscientiously fulfilled his obligations — wrote a well thought-out and fully comprehensive business concept and then handed over accountability. The new, more agile set-up means that the responsibility for the success of the project until its completion lies with the product owner, usually a business representative. This makes close networking and coordination with regard to corporate goals and project portfolio all the more important.
· PMO as coach
In order to combine the best of both worlds — linear and agile — and thus be able to maximize the value for your own company, you first need to deeply know both worlds. Here it is not enough to have searched the Internet for SCRUM or PRINCE2 and scrolled through a few pages. A central task of the PMO is to support, develop and accompany employees and project managers. At best, they get the opportunity to attend appropriate training courses and also to get certified. This not only emphatically increases the quality of project management within the company, but also the motivation of the respective project managers. Not only do they get the chance to learn, to develop further and to increase their own value. The company benefits most from a trained and constantly developing team. Only if you know the standards and have really learned the methods will you be able to develop a hybrid process model tailored to your own company and to apply it in your project and daily business.
We all know the cartoons of social media sites in which the CFO rejects further training measures with the words “Imagine we invest in the further training of our employees and then they leave us”, to which the CHRO counters “Imagine we don’t do it and they stay!”
· PMO as structuring agent
In order to take away the fear of top management that they shall decide in favor of agile management because the team does not know exactly what they want and thus demand carte blanche for everything, defined processes, structures and tools are required also in agile corporate settings. The art — and this is the PMO’s job — is to provide Scrum masters, product owners, project managers and teams with appropriate, company-wide governance structures, standards and documents. These include stakeholder maps, process descriptions or materials for onboarding, communication and reporting as well as the belonging tools.
· PMO as perpetual quality assurance
As in classic linear projects, where the quality or scope of the service usually remains unchanged and is checked at corresponding “gates”, the PMO in hybrid or purely agile projects has the task of ensuring iterative quality management. At the beginning of the sprints, quality criteria are defined, which are monitored after the sprints and over the entire duration of the project and, if necessary, adjusted to the changed project goals.
· PMO as central hub
A weak point of many historically grown companies are the so-called silos. Over the years, decentralized principalities have often been created, which over time have also established their own project landscape. While this model usually reduces the time-to-market significantly, it also leads to multiple redundant developments, often without adherence to the corresponding guidelines and policies. If the project is an IT-related or even a full IT project, this approach additionally often leads to bottlenecks, a complex, hardly controllable IT landscape and high operating costs.
With a modern PMO as a central cross-sectional function, whose task is to avoid conflicts of objectives, prioritize projects, improve and accelerate according to the agile principle “Inspect & Adapt”, silo structures can be broken down. The PMO helps to better distribute tasks, plan and use resources more efficiently, avoid redundancies, achieve scalable projects across the group and overall higher productivity.
· PMO as communicator
Projects serve to promote progress and progress motivates. Far too often, however, a well-structured, objective project manager is not at the same time a gifted communicator. Too often, the project team simply lacks the time to deal with seemingly unimportant issues such as an update on the intranet. Not only does the company want to know what is going on in the company, dynamism also leads to new dynamism. The PMO has its ear to the organization and knows what progress is best communicated in what media at what time. It should use this opportunity to take the business forward and demonstrate progress.
· PMO as network headquarters and change agent
Hardly any other function in a company has broader stakeholder contact than the PMO. Project managers are responsible for projects in all areas of the company, from purchasing to personnel management and from product development to sales. And since projects are transitory, project managers are constantly expanding their own network. The PMO networks top with bottom, left with right. It views projects as value-driven and mediates between business units and individual stakeholders. The lynchpin is the mindset of the actors involved. In addition to methodological knowledge and the ability to apply it, a lot is at stake in empathy and the capability to motivate and inspire others. The PMO team has to drive excitement and lead by example.
Let’s look at the PMO as a sales organization whose task it is to sell a new mindset. The PMO’s activities create more self-organisation in projects with distributed responsibility, empowerment of the individual project participants and a stronger ‘we’-feeling, an essential building block for cultural development. Visible results are achieved through knowledge of experts distributed throughout the company, networking among each other, cooperation across silos and flatter hierarchies within the project teams. Real outcomes are convincing of the new model, results that take away the uncertainty even of those who are still firmly attached to the Waterfall model today. Project managers become ambassadors of this ONE Team thought.
Conclusion: agile PMO as a pioneer in a rocky environment
Even in times of ‘agile’, the Program Management Office is by no means a discontinued model. But it is important to develop the PMO from its administratively supporting, KPI-controlling role to a driver of change. Whereas the old PMO focused its control function primarily on budgetary and scheduling aspects, a modern, more contemporary PMO focuses more on the customer or business value that can be increased through the measures taken.
Linear projects according to the Waterfall method and agile projects managed with the help of the agile frameworks such as Scrum are not mutually exclusive. Both models have their justification and often a customizing leads to a hybrid set-up tailored to the own project best fitting for own corporate environment. Agile sub-projects, embedded in a structured Waterfall framework, are becoming increasingly important. So, in a Prince2 compliant project, sub-modules within phases and even entire phases can very well be managed in an agile manner.
A PMO is certainly not the center of the entrepreneurial universe, but it is ideally placed to provide significant support for a planned or ongoing change process. It serves as a catalyst for a culture of cooperation and innovation, a more open mindset that sees change as an opportunity and standstill as a threat.
„That’s agile in practice: big ambitions and step-by-step progress. It shows the way to proceed even when, as is so often the case, the future is murky.“ — Jeff Sutherland
For many companies, this represents a major change and often also a major challenge. Traditionally, hierarchically grown companies have to give up part of their hierarchical concept for more agility. The business moves away from the role of a mere requester and, with increasing agility, becomes more of an implementer with responsibility for the success of the full project. It is also about the path from control to more trust, because control costs time, money and motivation.
Even if the change from Waterfall to agile would be neither possible nor does it make sense for most companies in the short term, the change to a hybrid model adapted to the needs of one’s own company will also require a lot of commitment and time.
Regardless of the methodology used, the PMO no longer has the role of an administrator, but rather the very central role of a designer and enabler.
Further interesting sources on this topic
- https://hbr.org/2018/05/agile-at-scale
- https://www.romanpichler.com/blog/big-product-owner-small-product-owner/
- https://medium.com/@Apiumhub/benefits-of-agile-project-management-108fa890389e
- https://medium.com/@ElifTech/project-managment-101-the-tasks-the-functions-the-responsibilities-28a381f9c100
- http://scaledagileframework.com
- https://www.scrumalliance.org
- https://agilemanifesto.org
