PMO Directors Series: My Story

Flashback to early 2013, when the word “selfie” became the Oxford dictionary’s “Word of the Year,” the cronut made its appearance and Candy Crush launched.

I was a PMO Director at a large health and wellness company. We were moving right along with our usual annual planning processes, weekly status reports and never having enough time for QA testing. “Development running long, ah – nevermind, just compress QA time.”

Our Waterfall process was kicking right along and anyone doing “agile” was a hippie – “they” didn’t understand the value of a “real” and “grown-up” process.

Little did I know that my safe, predictable world was about to be rocked and just how much education and learning I was about to receive – fortunately.

Senior leadership began to realize that we weren’t delivering the right value to the consumer in the timely manner that the customer needed, and not only were our numbers showing the impact but we also weren’t fulfilling our mission.

Then came the words “Agile Transformation” – and this is my story.

My Story

For 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 code 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 consumer-facing features out the door or if we were building the right solution for our consumers and our business. We were just happily following the process at our own pace; keeping the status-quo.

As launching tech became more accessible and cheaper, the company I worked for started to be 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)

As humans, we fear change, usually because of a perceived loss of control and identity and to a traditional PMO Head, the words “going Agile” can imply the kind of change where all management is thrown out the door and teams become 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 – so it’s no wonder they’re usually resistant to the change. Who’s going to oversee the budget, have visibility into what everyone is working on or ensure that communications are appropriately relayed in a timely fashion?

Below are some of the things I can articulate now on what scared me.

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 to re-establish an element of 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 would 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, originally calling them Road Managers, and now they call them Project and Program Managers.
   2. Side Note 2: In the PMOs I’ve run and created, I consistently maintain the titles of project, program and portfolio managers because they are generic enough – my preference would be just to call is “work management,” but that would probably just make it even more confusing.
3. “Does this mean that teams can do whatever they want with no planning?” – after working in such a planned/managed way, 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 develop without a formal plan. We found a way to have balance.
   1. Side Note: 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. Our usual process was in October the year before, and together with the Executive Team, we would 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, understood the cost and then we’d have a plan to work from with 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 compliance requirements, 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 their next projects.
   2. In product based teams, we align cross-functional, full-stack team members around core areas of our product and make them as durable as possible. We assigned them goals and Key Performance Indicators (KPIs), for example, for the team that has ownership of the Sign-Up funnel has 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 are 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 if 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 ridiculously 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.

For those of you who work with PMO leaders, 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’ve probably had it and figured out how to deal with it. Happy to help!

Previous: Intro to the PMO Directors Series   Next: Product-Based vs. Project-Based Teams

Shortcut: All PMO Directors Series Posts