Project Management Offices in Agile World: Part 1-Traditional PMOs

As someone who has worked in many traditional PMOs (Project Management Offices) until now, I can say that the alarm bells are ringing for them. As the need to be agile increases within companies, the traditional stance of PMOs may be perceived as a threat in the agility journey of companies. In many organizations, we can also see confusion between Agile Coaches and Project Managers, such as responsibility confusion, ignoring each other, or combining two roles.

So how do we avoid all this mess? Do we need to completely eliminate traditional PMOs or can we position them within Agile organizations? If you are wondering the answer to these questions, this series of articles is for you 🙂

Let’s first define traditional PMO. As a working style; At the beginning of the year, they list all the projects in the company that are aligned with the strategy (usually these start in the last quarter of the previous year) and create a master plan. This master plan includes information about the projects and time plans to be implemented within 1 year, the budget allocated for these projects, the resource plan, etc. After the master plan is approved by the senior management, Project Manager is assigned to each project according to its size and according to the need, Program Manager is appointed. The project manager starts the given project with a kick-off meeting. The project is given a budget, time and cost target, and the project manager spends effort in a matrix structured organization to finish the project based on these constraints. In the matrix structure, on the other hand, it constantly tries to attract resources from the X, Y, Z departments that are not directly connected to it, and puts pressure on them. It raises flags such as delay and risk in Project Steering Committee meetings, constantly asks for the support of the management, and regularly reports on project status. The ultimate purpose; is to complete the project within the expected scope, time and cost. During this time, there are delays, budget overruns, scope changes, and the project manager, with the motto of bringing the whole team together with great effort, finally completes the project and publishes the closing document. The PMO announces the closing of the project to the company, celebrations are held, and a project is partially successfully completed.

Then what? After 3-5 months, problems begin to arise in the product/service that emerges at the end of the project, additional requests come, but the project is closed. The next responsibility is on different teams, a new project manager should be appointed, and the project should be prioritized and included in the master plan.

Traditional PMOs are not concerned with the before or after of the project. Here you can pretend to be interested. The control of the compatibility of the project with the strategy still seems to be in the hands of the PMO, but sometimes it also uses this trump card to gain time. To start the project, he asks for all kinds of information, asks for benefits (even though the business does not know the details), requests some measurable data. Even if this is useful information, it is sometimes required to save time and sometimes to keep the PMO safe. After the project; The business unit has already given approval while closing the project, now all responsibility, the value produced after the project is under the responsibility of the business unit.

The existence need of traditional project managers also arises from the existence of traditional PMOs. In such a structure, no matter how agile you force the Project Manager to manage, the positioning of the PMO: if it is to deliver the project to the business unit in the triangle of scope, time, and cost, the project manager cannot change his behavior. This is one of the reasons why many project managers today question their duties, have to stand up for agility or accept the situation. Here, it is necessary to question and correct systems and processes rather than traditional project managers.

Let’s come to the most crucial points of this type of PMO: business unit – IT wars.

The business unit always requests projects beyond the available capacity. He complains that the projects are not implemented in any way. Most of the projects have not even been started for years, let alone implementation. He even questions the quality of the ongoing projects and expresses the lack of business knowledge of the project manager. In short, the business unit will never be happy.

The situation is not much different in IT PMO teams. They also complain that their business units are constantly bringing new projects, changing demands, not understanding them technically and not knowing about project management.

As a result; both IT and business units will be unhappy.

So who is to blame? The established processes and systems that are innocent on both sides and need to be corrected…

In such cases, teams can look for the solution in Agile Transformations. So far, I have witnessed and been involved in many agile transformation stories that both started within the PMO and started independently of the PMO and intersected with the PMO in a positive or negative way.

So how were PMOs positioned here? Where do scaling agile models like SAFe, Disciplined Agile, Scrum@Scale keep PMOs? Is agile portfolio management still the responsibility of the PMO in a structure where portfolio management has gained such importance for agility?

I plan to answer many such questions in my next post. In this article, I wanted to confront you with the situation you are in and push the solution to some thinking and research.

If you have suggestions and suggestions for solutions, I wanted to answer you by reading the comment section with pleasure 🙂

See you in the second and more exciting part of the article…