When polarizing, powerful ideas collide they ignite grand scale conflict. This is the cause of revolutions, the kindling for coups, the fodder for enlightenment. Polarizing ideas in a small group of family or friends can be ignored over dinner or avoided on vacation, but the larger the group, such as in a business, the harder it is to maintain the peace. As a group grows in size, the pyre of conflict is built ever larger waiting for a single match to turn the pile into a blazing inferno. That little spark has the potential to illuminate the divide that has been established between two entrenched belief systems, and once the battleground is lit there seems to be no other choice than to rush upon the opposing force and thrust your principles upon those persuaded of the contrary. Thus is the nature of project management methodologies it seems. Especially when it comes to the Project Management Office, known as the PMO, at large organizations.

It may seem as though we are talking more about war than business, but is business not by its very nature a conflict between trained forces, with a winner and a loser? The former gaining power and wealth while the latter surrendering something of value such as organizational authority, or market share? In this article I want to knock on the door of the established beliefs large organizations hold by questioning the validity of traditional PMO’s in the age of digital transformation. I want to present a compromise as a way to resolve the misalignment in hopes of easing the tensions of opposing views. The goal of this article is to explain how to keep the structure of a traditional PMO in place, while adapting its practices and renaming it the Agile PMO.

In our last post, “What is a PMO?”, we discussed the different types of traditional Project Management Offices. In larger companies, these organizations are responsible for dictating standards, standardizing processes, and in some cases resource allocation and direct project oversight. This begs the question, if a PMO is by definition a command and control structure put in place to dictate and direct, then what happens to it when the organization undergoes digital transformation and realigns around Agile principles that teach decentralized control?

Let’s take a moment and look at five key differentiators that your organization needs to understand to implement or transition to an Agile PMO.

Manage Teams NOT People

This is first on my list for a reason because this is where a lot of the apparent magic of Agile comes from. Agile principle #11 states:

“The best architectures, requirements, and designs emerge from self-organizing teams.” 

The premise behind Agile is that a small, cross functional group of people can own the entire project process and in so doing, build things faster and with better quality. The team of course gets its high level marching orders in the form of goals, or intent statements from leadership. Then they are empowered to work as a team to figure out the best way to accomplish this. As a team works together, they build trust and figure out how to leverage the strengths of everyone on the team. This is why long lived teams are so important. 

For sake of an example, let’s take a musical rock band. The band is greater than the sum of its parts because they practice together, perform together, and essentially live together for long periods of time while on the road. Because of this their instruments are tuned to fit into the overall sound the team has crafted and they are able to play as if they are a cohesive unit. A good band knows when the drummer is about to go off on a solo or when the singer is going to start one of his on stage rants. Since they can read each other so well, they are able to compensate for the ebbs and flows of the set and the audience ends up with a fluid concert experience. But take any one of those musicians as an individual and throw them into another band and their apparent magic will disappear. They may have a great ear for music and be able to follow along, but they won’t be able to create an amazing experience with the new group until they spend a significant amount of time integrating their sound and learning their new band mate’s strengths and weaknesses.

The same is true for teams in business. When a team is allowed to stick together, working alongside each other as a long lived unit, they are able to create their own type of magic and produce work that exceeds the ability of a newly formed team. This of course is not infinitely scalable and teams will have to be restructured from time to time to align with organizational objectives. The goal however is to minimize this in order to leverage the synergy the group has generated. 

This translates past the organization of teams as well into the way work is passed into the team. A common antipattern is to create a team, but then to break them into smaller working groups to make sure everyone has enough work to do and to insure the department gets as many projects done simultaneously as possible. This is a terrible practice that uses the facade of a team to appear organizationally aligned while covertly sabotaging the biggest benefits from the Agile concept. Agile principle #5 states:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

The best way to make sure a team has enough to do is to ask the team if they are able to take more on as a cohesive unit. If they decide to subdivide inside the team they are more than welcome to, but project management must stop looking at teams as a collection of people that can be reassigned, and instead start treating them like a singular unit. This is how we leverage the power of the team and of community to get better work done faster. 

This is the first thing an Agile PMO must recognize. They should no longer own a collective of project managers that can be assigned and re-assigned as interchangeable captains among a vast array of troops. Instead the project managers need to be embedded as team members on long lived teams and the Agile PMO must look at each team as a unit that can define, design, and deliver projects. Having a project manager or someone with this skill set on a team is critical regardless of their title, but they must be looked at as a member of a team rather than a layer of management. 

Decentralize Decisions

Once the Agile PMO has adopted the understanding that project managers are embedded in teams and teams are the units to be managed rather than the individual. The next major shift is to let go of control and hand the decision making power to the team. This of course does not mean the PMO should let go of organizational oversight, but they must give the front line troops as much authority as possible to make decisions.

In the software industry around the turn of the century we mostly built desktop applications in giant monolithic code bases. As the cloud computing revolution happened, most software companies took this same, monolithic tactic when building new architectures in the cloud. But as the scalable potential of cloud computing was recognized a new concept emerged known as the service-oriented architecture which allows platforms to scale easier through a network of small, easily changeable parts. As this happened the companies that continued the monolithic codebase strategy saw their development processes grind to a halt under the weight of upkeep and maintenance for each subsequent change. Alternatively the companies with service based architectures remained nimble and were able to outpace the competition because the relatively low cost of continued development. It is interesting to note that the companies who held to strict top down organizational command and control structures were far more likely to build monolithic codebases compared to their Agile counterparts. This reality is resembled in an adage known as Conway’s Law which states:

“Organizations design systems that mirror their own communication structure”

You see, in Agile organizations teams are empowered to make their own decisions on how to build things. Their decisions must align with organizational strategy, but as much autonomy as possible is given to the teams to do what they think is best. This creates organizational adaptability and helps the company avoid the pull of bureaucratic systems and processes that slow organizations to a grinding halt over time.

As an Agile PMO, pushing authority to the teams is paramount. The traditional PMO wields a lot of authority as does the Agile PMO, the difference is that the Agile PMO chooses to pass that authority along with their trust, down the hierarchy whenever possible. This not only empowers teams to move faster, but also motivates employees which in turn increases speed.

Realign Responsibility

Many people with a traditional project management background, especially those who have worked in a traditional PMO, struggle with the idea of decentralizing decision making and managing the team over the individual. They feel that it removes their ability to hold individuals accountable. These people have worked for years in a CYA (cover your a$$) culture that is always looking for a single wringable neck to hold accountable for each outcome, and the idea of losing this puts them in the hot seat for senior management when things go wrong. 

Though the Agile PMO needs to relinquish control and push as many decisions as possible down to the team level, they should not relinquish the idea of accountability, and they should not be placed in the hot seat when things go sideways. Instead they should shift accountability from the individual to the team and then clearly outline what success looks like through goals and statements of intent. Once this happens there are only two versions of failure. Either a team does not meet the defined goals, or they hit the goals, but fail to achieve the impact the goals were intended to create. In either case the team should be held responsible.

Now some might say that’s not fair. That if a team accomplishes the goals set out in front of them but those goals do not achieve the organizational outcome the company was looking for, then it’s the organizations fault not the teams. This however is flawed thinking. This is where an Agile organization really shines. By shifting the responsibility of organizational success to the team, they are held accountable for organizational impact NOT project implementation. This in turn pushes them to have an ownership mentality rather than an employee mentality. Some books refer to this as the missionary mentality rather than the mercenary mentality. You see a mercenary gets paid for the job and moves on, a missionary is a true believer who commits their life to the success of their organization, and as such focuses on success over completion. 

What would your company look like if your teams were so bought into your vision that they focused on achieving outcomes over completing projects? The way to get there is by realigning the responsibility to the team. To do this well, the PMO must focus on distilling organizational vision into strategy and then further into statements of intent that embody organizational outcomes. Instead of telling a team to implement a new authentication system they need to be challenged to decrease time to login by 90%. Instead of being told to create a new widget with X,Y,& Z features they need to be empowered to build a widget that competes with competitor A and satisfies the needs of customer B. Once this pivot in project assignments happens, only then can the responsibility and accountability be transitioned to the team.

I mentioned this the other day to someone at my company and they asked me, “so what happens when a team doesn’t meet their goals, how do you hold them responsible.” The answer is simple. If you have a team that continually fails to deliver impactful business outcomes in alignment with stated intent and goals, the entire team is put under review and coached to improve. This is where the PMO can play a critical role, by embedding a coach in a struggling team, the PMO can help identify the issues causing the bad performance. If these issues can be corrected, great. If not, the embedded coach can help craft a plan of action to disband the team and embed the productive members on other teams, while advising the managers of the problematic employee to help that person exit the company.

This is a last resort of course, and most self organized teams will expel the troublemakers organically before a coach is needed. The motivated and driven team members will quickly identify and get tired of picking up the slack for someone not willing to pull their weight. This type of self governance is a natural benefit of managing a team and holding the team accountable as a unit rather than as individuals. 

Create a Coaching Culture

The job of a traditional PMO has always involved training to some degree. This is still true in the Agile PMO but is actually an area of expanded control. Whereas the traditional PMO is responsible for training project managers, the Agile PMO training purview has expanded to include team education and training. In some organizations this means training everyone in the organization on agile principles, but at the very least this should include training teams. Both newly formed and those that simply need a refresher.

This should be done by full time trainers, on staff or contracted, that report to the PMO. These trainers double as embedded coaches when a team is starting off or when a team is struggling. These coaching positions provide a career ladder opportunity for project managers who have a solid grasp on process with a background in project implementation.

A buzz word these days that organizations are working towards embracing is “The Learning Organization”. This is being touted by many as the next major wave in the Agile movement. To break this down for you it means two things. First, that training and thus learning should be at the core of all departments, second and more importantly, it means that the organization needs to get in a rhythm of creating measurable hypothesis on how to improve. Designing experiments to test the hypothesis. Then, if successful, adopting the new behavior while working on the next hypothesis. In this way the organization as a whole learns what works and what does not in a scientific way. This follows the PDSA cycle taught by the lean startup movement of “Plan, Do, Study, Act”. 

This organizational PDSA concept should be owned at an operational level by the Agile PMO. This effort can be handled by the staff of consultants and coaches when they are not embedded directly in a team or in a busy training season. 

One more thing to note on this point. In an Agile organization the traditional managers are supposed to transition from task masters and facilitators to lean thinking coaches & mentors. As the Agile PMO is working to instill the concept of team, special emphasis needs to be taken to teach middle management how to coach and mentor individuals without interfering with projects and teams. Without clear direction, managers often fall into the trap of doing what they were taught in school or through years of traditional managerial structures. They will manage whatever they can get their hands on. This includes projects, people, & processes. For an Agile PMO to be successful they cannot forgo the need to train the managers on their new focus.

Morph Measurements

Last but far from least, the Agile PMO is responsible for measuring progress and delivering distilled reports and dashboards to senior leadership to inform strategic planning. This is a core competency of the traditional PMO as well, but whereas the traditional PMO measured projects and people, the Agile PMO must pivot to measure teams and the value each creates. This is a broad topic that will be detailed out in future articles. For now let us suffice it to say that the Agile PMO is focused on supporting and elevating the creation of value for the company. This is done through building, training, and supporting self-organized teams that are held responsible for the business impact of their work. 

So, if you are looking to start an Agile PMO, or transition a traditional PMO into its modern version, you need to start by defining what value looks like in your organization and then craft processes and dashboards to measure and report the amount of impact each team is having on the overall organization.

Summary

Agile in general is a powerful concept, but many have relegated it to a lower level function that improves the moral of the troops. Limiting the idea in this way though cripples the true potential these concepts can have across an organization. If understood and adopted at a higher level Agile has the power to transform any organization into a more productive and successful version of its bureaucratic and antiquated rivals. The reality is that Agile organizations move faster because they are built by motivated individuals leading self-organized and semi autonomous teams that are focused on value creation over project execution. The Agile PMO is one option for how to help a larger organization embody these concepts for better alignment and organizational wide adoption. 

Shout out to freepik for the awesome header vector art!