How to communicate with the “dreaded Head of PMO” during an Agile Transformation

I’ve been through and led a number of organizational “Agile Transformations,” a phrase which I know is a necessary evil; however, it rubs me the wrong way because organizations always need to look for ways to appropriately adapt to meet their goals. In technology, it’s usually boiled down to leaving the Waterfall methodology behind and going “Agile,” i.e. the “Transformation.”

Countless articles, webinars and classes teach that the core of “being Agile” is the mindset change, not the transformation itself because a transformation is not 1) a point in time event or 2) a defined end point. It’s good to have goals and milestones for activities to use as guides and checkpoints along the way to see if the activities are having their intended effects.

Think about weight loss transformations stories – the person losing the weight didn’t wake up one morning with the weight gone. No, it was many, many tiny steps along the way.

In the spirit of helping enable the mindset change, and recognizing the transformation language, one blocker to the Agile transformation I hear sometimes is the “dreaded PMO Head.”

I’d like to share my journey in this post and give some strategies and tips for how to communicate with PMO Heads using language where they won’t just shut the conversation down because you’re “one of those hippy, Agile crazies.”

My Story

The first ten years of my career in project management, I worked for organizations that worked in a Waterfall methodology at various levels, project manager, portfolio director, etc. My goals were all tied to the project being 1) on-time, 2) on-budget and 3) with high quality. Also, it was extremely important that the “process” was followed – I remember I would do all my paperwork catch-up work in the evenings to make sure I was following the process.

No one cared that the projects were taking 6-8 months to get out the door (these were consumer-facing web features) or if we were building the right thing for our consumers and our business. We were just happily following the process and following our own pace; keeping status-quo.

Well, as launching tech became more accessible and cheaper, the company where I worked started to get disrupted by smaller companies that could move quickly and adjust to what the market needed – releasing new features frequently.

We needed to do something, so we started finding ways to be able to deliver value to our consumers faster, and to enable that, I had to take a hard look at what I was doing as a Portfolio Director in the PMO. Note that these learnings are in technology organizations with 150+ team members.

What Scared Me (and What Reassured Me Over Time)

Below are some of the things I can articulate now on what scared me. We, as humans, fear change, usually because of a perceived loss of control and identity.

To a traditional PMO Head, the words “going Agile” can imply that all management is thrown out the door – teams are self-organizing and self-managing. This activity directly attacks a Head of PMO’s role, and the level of identity that they associate with it – no wonder they’re usually resistant to the change. Who’s going to oversee the budget, have visibility into what everyone is working, ensure that communications were appropriately relayed in a timely fashion?

1. “Am I going to get fired?” – this was a real fear because I thought that my role was becoming irrelevant. I quickly realized there were a number of ways I could leverage my skills that made me a great project manager and portfolio director to help enable the organization. I realized I was part of the leadership team that was defining the new ways that we were working (which helped re-establish an element of control and identity).
2. “Am I going to have to fire my team of project managers?” – Fortunately, the answer was no because once I realized that I could help shape how the organization operated, I could define how the role of project management fit into it. I was also tremendously lucky that my team also wanted to learn how to work in new ways and approached the change with an open mind. In your organization, you can define what this means and what title you give the role – Scrum Master, Agile Project Manager, Agile Coach, Project Manager, Cat Herder, etc. If you need help, feel free to reach out to me, I have a lot of thoughts on the role definitions depending on the type and level of product development maturity of the organization.
   1. Side Note: Years ago, I heard the argument that “Spotify doesn’t have project managers.” Well, they decided to add the role into their model, they call them Road Managers. 
3. “Does this mean that teams can do whatever they want with no planning?” – after working in such a planned/managed way of working, it was hard for me to let go of the fake level of certainty that we had. This initially sounded like chaos to me because I couldn’t see another way to development without a formal plan. We found a way to have balance.
   1. Side Note 1: Never, ever, ever use the words, “it’ll be done when it’s done” to a traditional project manager. Their minds will shut down like there’s no tomorrow.
   2. Side Note 2: I highly recommend Johanna Rothman‘s books Predicting the Unpredictable and Agile and Lean Program Management for new ways to look at project, program and portfolio estimation and management.
4. “How the heck do I estimate and manage the annual budget?”
   1. The usual process was in October the year before, we and the Executive Team would get together to set the annual plan of projects (we were arrogant enough to think we knew what the market wanted 15 months out). We’d figure out high-level schedules and the number of resources we’d need for each, understand the cost and then we’d have a plan to work from and a budget to manage.
   2. In Agile, if team members are just working on whatever they want for however long they wanted, how was I going to ensure that there were not over-runs to the budget? Once I realized the power of investing in teams with time guide rails vs. investing in projects, I quickly realized that I could manage the budget because I knew who was assigned to which team and how long we wanted to make the initial investment.
   3. We would revisit the team’s progress at certain points and make any investment adjustments – we also did this when we learned of market needs that were deemed higher priority than the items that were in progress.
   4. Also, if we needed to spin up another team, and all team members were booked on valuable investments, we knew that we needed additional budget for another team, if the team was temporary, we could also look into consultants.
5. “What about compliance?” – In one organization, I needed to worry about HIPAA, PCI and SOX compliance. There was a fear triggered when I heard that going “Agile” meant zero documentation. Fortunately, the other leaders also had respect for meeting these compliances, so we were able to design a process that still had documentation to cover our needs.

What Early Learnings Resonated With Me

We had a number of extremely talented thought leaders engaged with us as we learned how to improve how the organization operated, and below are the learnings that resonated with me:

1. Organizing team members by product vs. project.
   1. In traditional days, the annual plan would be set, and project management was responsible for assembling the project team, kicking off the project and seeing it through to completion. The team would then disassemble and individuals would be assigned to (usually different) next projects.
   2. In product based teams, we aligned cross-functional, full-stack team members around core areas of our product made them as durable as possible. We assigned them goals and KPIs, for example, for the team that had ownership of the Sign-Up funnel had a KPI of increasing the conversion rate. The other benefit of having teams whose members stuck together was that teams learned each other strengths and weaknesses and could compensate accordingly – there were also great team norms established.
   3. Teams could also focus on achieving outcomes vs. just delivering features that were decided months ago by the Exec Team sitting in a room. Teams are able to learn and iterate as they release code/features and adapt based on consumer response. Really strong teams were able to do upfront testing with consumers to validate or invalidate their ideas. Teams got to know their consumers directly.
2. Looking at the portfolio as a mix of investments vs. managing a budget. 
   1. This changed the language that I used when talking about the budget. Gone was the language of it a project was on budget; instead, I talked as if I was talking about an investment portfolio, e.g. here’s our current investment mix, here’s any correlation to the return that we’re seeing, we might be a little off-balance here, and Team X is making great strides, but they’ve used up 80% of the time that we allocated to them, should we continue investing or turn our investment to another area and reassign team members or change what they’re working on?
   2. This approach also allowed us to “kill off projects” that weren’t going to be valuable without it feeling like a failure (aka the Project Death March).
3. The need to constantly re-evaluate processes and procedures, and to see them for what they are meant to be – enablers for the work.
   1. There was such comfort in following the process – we were praised for it. Look at her – she’s awesome because her project had all the paperwork done and the MS Project schedule is fantastic! A memory stuck in my mind is Marty Cagan holding up two reams (yes, two reams) of paper I printed out for a project of mine for him to use a prop in one of his working sessions with us. What good did all the time that we spent writing that documentation get us? At the time, it was critical to all the hand-offs we had between departments as the work progressed so that nothing got lost in the communication. When we changed to working in cross-functional teams, there was no need for that high amount of documentation at the ridicously high fidelity at which we created it.
   2. Now, Scrum, which is sometimes called the “training wheels” of Agile, is getting scrutiny because some of the same symptoms are cropping up – Look at the team, they’re holding Stand-Ups, they’re having Retros AND using JIRA! Great job! If a person finds themselves doing something just for the sake of doing it (process for process sake) vs. finding new processes and procedures to help the team deliver, that could be a warning sign. Of course, once you get into larger organizations, there is a need to standardize ways of working. Again, if you’d like to swap ideas on what’s worked or not worked when scaling, feel free to reach out.

What I Had To Let Go Of

1. Project Managers are the ONLY leaders on the team. Fortunately, this was not hard for me because my project management style is more in a facilitative vs. directive approach. Everyone working on the team can be a leader.
2. Protecting the teams from making mistakes. Teams are going to make mistakes, and there is tremendous learning power there. We as leaders need to install safety nets to ensure that a team is never in a place where they are only one defense away from failure.
3. The arrogance that a plan means success because we had a fake level of certainty to what we were building – that’s why we were okay with delivery timelines of 6-8 months. We assumed that people would wait and still want it when it was launched and that no one else would beat us to market.
4. Process for Process Sake – success means consistently delivering value at the appropriate pace; gold stars shouldn’t be given out for following the process. If the process is no longer enabling (or even more so, getting in the way), figure out ways to change it.
5. A Directive, Command and Control Style of Leadership – while this wasn’t too challenging for me, this was extremely tough for some leaders in the organization because for some functional roles, if the Manager is not directing (telling the employee what to do to get the work done), then what are they supposed to do? We as leaders needed to move to more of a facilitative, coaching and mentoring role to our direct reports and give team members space to figure out the how on their own. We were also needed to constantly be on the lookout to find ways to evolve the organization to further support and enable the teams.

Hopefully, this gives insight into what was going through my mind as I shifted my mindset and worldview. The other piece of advice is that this takes time – candidly, it probably took me at least a year and a half to fully let go of my past tendencies and habits. When I look back over the last five years, I can see how much I’ve learned and how my mindset has evolved, and I look forward to what I learn in the next five years.

So, please be patient and understanding. Most likely any person in the PMO is just unclear about how their role fits into the new style of working and how they’re going to do their jobs (meet/exceed expectations of their boss), and they’re feeling threatened. In agile environments, there is still a high value in having project management because its core tenets of organization, budgeting and communication are still strong enablers.

If you’d like to talk through any of the challenges that you’re running into, feel free to reach out. If you are in a PMO and have a fear I haven’t mentioned here, reach out because I probably had it and figured out how to deal with it. Happy to help!

Header image courtesy of http://huff.to/2i6ze9S