Click here to read this article in french
As Project Management Office (PMO) has gained its popularity in today’s business world, I would like to talk, from my own experience, about this supporting role which has been proved to be helpful for projects to ascertain project values, strengthen team’s performance, process excellence and strategic project alignment for organizations. People often view the role of PMO as a heavily administrative role that entails daily documentation, such as, project reports, budgets, and document standards to maintain project governance. This understanding is, unfortunately, correct because the role of PMO was initially invented through traditional methodologies such as PMBOK which shaped the image of PMO.
In the past, we only saw highly experienced people working as “directive PMO,” as the objectives include supervising not only projects but also programs and portfolio. Today, however, as the needs of firms have changed, the need for more junior positions to assist with administrative tasks without making major decisions increases, the so-called “supportive PMO.” Out of this reason, many companies nowadays usually assign either highly experienced, or inexperienced one as a PMO, or both, depending on how demanding the responsibilities are in a given project.
My starting point as PMO in an agile style :
The perception of the traditional PMO, however, could be discouraging for some people in an agile organization to accept the job. As in an agile company, managers always promote an adaptive environment with various best practices that cultivate flexibility and change. Since PMO is perceived as a bureaucratic and “non-agile” role, it seems to contradict the “agile” mindset. As one of those practicing Agile professionally, I did not see myself working in a PMO in a project in the first place. I was assigned to be one, eventually, to support my projects.
Therefore, I took this chance to analyze the role in understanding it better and adjusting some processes whenever it is suitable to match both my professional goals as an agile consultant and the mission’s objectives. I then asked myself is it possible to integrate this “non-agile” function in an agile project and make it an “agile PMO”? What must be considered is how to find the right balance between the environment of the organization and the benefits that this role should bring, so that you can position yourself and fit in. I started by breaking down the normal responsibilities as a PMO and how I could implement agile techniques to replace the classic ones to improve the same added values for the team and projects.
My primary PMO functions are as followed:
• Creating a structure to organize workflows and following up deliverables to deliver them as planned
• Taking care of scheduling of all necessary events of project stakeholders and team
• Documenting reports to be used as references, such as presentations for steering committees, meeting notes, action plan, etc.
• Giving the visibility of the project tasks and deadlines to team members
• Ensuring good communication, team performance, and work processes throughout the project
Instead of focusing on the procedure, I questioned ‘why’ to all these tasks to know precisely their purposes and started changing some techniques to respond to the same needs.
Working style and approach :
One crucial point that I want to address is about the rationale of implementing any work technique because what matters is the goal of making the project successful in achieving its values. This objective is the commonality between both traditional and agile approaches. In other words, we must focus on the ending point of the game and not the process.
What we often hear is that being agile is not only about changing the methodologies and applying non-traditional techniques; it is about being open to change and flexible. It is about setting mindset and perspective that aim for delivering real values quickly to the team, project, and clients. What I like in the agile principles is “never compromise the quality of work” and “improving continuously.” These are the golden rules that should be implanted in the team, regardless of roles or management approaches that you are using or facing. Even if your organization, role, or working environment is not agile, you can still implement the Agile style anyway.
Where to start :
For example, to plan the project tasks and workflow or Work Breakdown Structure (WBS) and Product Breakdown Structure (PBS) in the traditional method, we use Product Backlog and Sprint Backlog.
• Product backlog allows project managers to list and prioritize all expected work in the form of User Story and deliverables in the form of Feature, containing the acceptance criteria as well as task complexity.
• Sprint backlog enables us to answer better to how to deliver work and make their value attainable in the shortest period. Since the project life cycle in agile is shorter than the classic approach, a sprint or iteration of 2 to 4 weeks is used, allowing us to check on the work progress regularly. This technique reduces the risks of overlooking some tasks, especially in big projects where there is a multitude of complex components leading to higher risks compared to the smaller ones.
To promote the visibility of the project and effective communication about the work status in the team, we use Scrum board and Kanban board to project the planned, on-going and finished work during the sprints. We also implemented the concept of visual management, meaning that we created all the boards and other information in the project room. Following up the work can be done quickly through 15-30 minute Daily stand-up meeting where each person of the team will communicate precisely on what he/she did since last standup meeting, what he/she will do, the problems encountered, and the task progress. The daily stand-up meeting doesn’t only help with the monitoring work but also helps remind the team of the planned schedules and deadlines of the work so that everyone is aware of delivering values to the project. With these tools and techniques, the majority of PMO responsibilities are covered and accomplished in a much more agile way.
Scrum master vs. PMO :
At this point, some people might wonder why a Scrum Master does not seem to be very different from a PMO because some of their tasks are similar. This is another fun fact that is also worth discovering.
• The Scrum Master is a facilitator of Agile ceremonies included the sprint planning, sprint retrospective, sprint review, and the daily standup meeting. He/she ensures that the team well respects the application of the Scrum framework and help it reach the consensus via collaboration, various feedbacks as well as enough engagement with other stakeholders.
• PMO, on the other hand, is responsible for the project strategic governance by reinforcing project management principles, methodologies, tools, and techniques that the team should follow to align with the business objectives.
Furthermore, one of the most common tasks they are often asked to do is reporting. Either “traditional” or “Agile” teams need to produce and keep project documents since they are essential for tracking on what has been going and what is left to complete. However, some of them can be eliminated in agile if the team or stakeholders do not require them. In a nutshell, both are accountable for monitoring the work process and progress of their teams to ensure a successful product delivery at the end of an iteration with the use of project management standards. Therefore, if the organization or PMO promotes the agile mindsets, both roles are almost identical because the agile principles are implemented in the projects and teams.
The benefits of the agile methodologies of keeping up with the speed of change in clients’ demands are necessary for all industries, and several agile techniques evolve around the principle of delivering qualified work quickly and frequently to respond to customer needs. Hence, to maintain business competitiveness, the project values must be attained regularly through a proper execution to inevitable change. We should always keep in mind that our ultimate goal is to increase flexibility in a way that it equips us to handle the market turbulence on time. Therefore, the question about which process we should be following should no longer be a concern, but rather how we can reap the most benefits from the application of the Agile methods to best cultivate agility in the project. I decided then to implement the best practices of the project management approaches that I know – traditional or agile – to reach the “finale” of realizing the project success. I then came to understand that a combination of agility and traditionality is possible if we go beyond the method pitfalls, through the role of PMO.
“Do not lose sight of the real meaning of the WHY and stick with the old stereotype of PMO and let it demotivate you even if you are an agile expert because PMO tasks can be done in an agile way as well.”