Guest Post: Carolyn B. Smith

About the author:

Carolyn Smith has over 20 years of experience managing and leading PMO offices – ranging from large, cross-organizational, multi-year projects to IT Program Offices. She has overseen the delivery of hundreds of projects and has repeated successes in building PMO organizations and transforming processes to accelerate delivery of business value.

Being a PMO leader can be a lonely and scary experience, especially if you are new to the role. You may be asking yourself “how did I get myself into this situation”?  You may have doubts about your capability and worried you’ll disappoint those who selected you.  “What if they find out I’m not totally sure what I’m doing?”, you ask yourself.  Even if you’ve led a PMO for a while, you’re not sure it’s as effective as it should be. There is a lot of energy spent on processes, generating cost estimates, prioritizing too many projects and slogging through releases. And you find yourself caught up in the turmoil, rationalizing that you and your team are just too busy to change. Does any of this sound familiar?

It does to me. I’ve learned many lessons in my career as a PMO leader. I want to share them with you so you can build your confidence and lead your PMO to become the value delivery engine it should be. Much of this is from the perspective of running an IT PMO, but the learnings can be applied to any PMO.

Building and Growing a PMO

• Brand new PMO is established and you’re a team of one. And, executives are expecting to see action and results soon. Where do you start? Ask for help and build a support network. In my case, I went to the Chief of Staff for the business unit. I asked for recommendations on candidates for my team and who else I should be talking to. I had meetings with several stakeholders and established an advisory board. Although they had strong, and sometimes conflicting views on approach, the early inclusion was invaluable. They became invested in the program. I also reached out to subject matter experts from other key groups and ask them for guidance and support. If your program office will be delivering strategic projects (as was the case for me), people will want to be part of the effort (directly and indirectly). Take advantage of this.
• You’re the new leader of a PMO team that’s the result of a merger or combination of PMOs. You’ve inherited a collection of processes and need to come up with a common way of operating. Most importantly, you are dealing with different cultures and it won’t be easily apparent how these teams work and make decisions. Do not underestimate the importance of this! You need to spend time observing, listening and asking questions. Team building, especially with your direct team, is paramount. Meeting with the full team is important too. Ideally, this should be done in small groups where you can get more open discussion. You most likely have a new set of stakeholders. You should be meeting with them to hear their views and expectations of your new PMO which will shape your plans. Leverage your sponsor / supervisor to help you. With your leaders, prioritize the processes that need change or improvement and let them take the lead in determining how. This will help them “own” the new process. All of this sounds very straightforward and practical and, in my case, worked up to a point, but I found hidden resistance from some of my leaders who continued to manage their teams the way they had in the past. This was about a year into the merger and I had seen enough to know we could streamline the organization. I eliminated two of the positions and recombined functions under my stronger leaders. We became a much more efficient organization and had the added effect of energizing the team – who felt their former leaders weren’t listening / supporting them and appreciated that someone was bold enough to make changes.
• Partner PMOs. Another way to strengthen your PMO impact is to build alliances and partnerships with other PMOs in your company. This works especially well if there can be a PMO for IT and one for Business. In my case, I built strong relationships with the Business Operations and Product PMOs. Together, we came up with processes to align priorities for IT projects. This stopped a lot of the work coming in from many separate groups (each with their own list). It also gave these PMO leaders more clout in serving their leaders because they helped ensure the most valuable projects across their business units were being prioritized.
• IT PMO structure. There is no “one size fits all” when it comes to the functions that should be within an IT program office. A key decision is which functions should be in a centralized group vs dispersed through other teams (such as Application Development teams). There is a natural tendency for Application Development leaders to want “their own” architects, project managers, testers and budget managers so they can have ultimate control. This needs to be balanced with the efficiencies to be gained with combining like functions. Over the years, we found it was better to have most of the PMs and system testers reporting organizationally to the development teams, while keeping PMs for only the largest, cross-functional projects in the centralized PMO. We didn’t know it at the time, but this was one of our first steps into being Agile – enabling a unit of PM, Developer and tester to work together and not be in three different organizations. We did keep the end to end (integrated testing) in the PMO. These are the functions we found best to be in the centralized IT PMO that reported to the CIO (Enterprise architecture, budget and resource management, large project PMs, project prioritization, compliance management, integrated testing and communications management for the CIO and across the IT teams). We found that budget reductions (downsizing) were a good opportunity to re-visit whether functions should be combined and accomplished with fewer people. For example: we had a centralized budget group, but also “shadow” budget teams under the Development teams. We convinced them to fully centralize the function, but have a dedicated budget manager (of their choosing) dotted-line report back to them. This eased the transition and maintained trust.

Delivering Change

• Migrating to a new application. Involve the users who will be impacted – early and often – during design (not just when it’s time to train). This is critical if the process they currently use will change. Map out the use cases and how the process will change – in detail. We made the mistake of relying too much on a small group of “super users”. We got too complacent as these users breezed through the new system (as they had become very proficient). This was at a time when I was very new in the IT space and trusted too much (without verifying the extent of testing being done). After the deployment, 90%+ of the general population of users were very frustrated and complaints rampant (up to the Presidential level). Considerable changes were then needed over the next year.
• System enhancements without documenting process first. Often, well-meaning business sponsors pre-determine what system changes are needed without understanding the process they expect. The result? You may end up automating a bad process. After years of living with “requirements over the wall to IT”, we learned that the best approach was to have IT and Business document the “as-is” and “to-be” process flows together. A key element was to document where the data was coming from. Also included was the elapsed time for various steps. This is called Value Stream Mapping and shows you where time (hours/days) is spent “waiting” – typically for a manual process or hand-off to another group. This highlighted where we should focus on process automation. For one of our biggest process/system transformation programs, an entire conference room was dedicated to outlining the processes on paper along the four walls. The visual nature of this was very helpful to explain to Sr Executives why the current complexity needed to be changed. From this, we made much better decisions on process and systems enhancements and had full buy in from the teams and leadership.
• IT driving change without full alignment AND support of Business leaders. After multiple mergers, we had too many systems, operating with unique product catalogs and billing systems. Business processes were manual, often involving redundant data entry from one system to another. Everyone, including Sr Leadership, understood we needed to get to one way of operating. Change was needed throughout the full product life cycle – from sales to billing. We made good, but incremental progress. We (IT) thought we had full support across the business units, but when it came to realization that we would need to migrate customers’ billing and grandfather (stop selling) legacy products, we found there was no appetite from Sales and Product leadership as they feared revenue would be impacted. Never mind that revenue was already being impacted because service delivery was much longer than competitors and system changes took 9+ months. The IT work in this area did not make any further progress until a new Business unit President took charge and with his new leadership team, drove the change that was needed. A key factor was the constant communications from this team. They took the time to dig into details and stayed involved throughout the project. See above comments on the importance of joint IT and Business process mapping which occurred at this stage. Lesson learned: not all details need to be known at the onset of a program like this, but leaders do need to understand how customers will be impacted. This can’t be discovered during the implementation, but rather, during design when teams can see how to minimize customer impact.
• Business buying new applications without IT involvement. The “new shiny tool” that will make everything so much easier! It can be deployed in under three months! Just plug and play! The demo is enticing. This is what gets business leaders sucked in. I’ve lived through this experience several times and have seen where it works and doesn’t. This is not a debate about buy vs build. Either one can work – if the teams work with each other, trust each other and get to the details of how a new system will be integrated. I experienced at least two cases, where Business teams purchased a third party solution and then handed it to IT for implementation. Surprise! It couldn’t be easily implemented. By the way, the Operations team had never been consulted either, so there was no plan on how this would be supported. In both cases, significant additional capital was spent. In one case, the project was subsequently cancelled, triggering a large write-off of the investment.

Value Enablement

• Moving from debates on capital spending to benefits realization. Are your business sponsors behaving as if capital investment exactly correlates to IT resources? In the early days of my IT PMO, Business sponsors held the capital investment. They had a false belief that one could spread capital in numerous ways and the IT resources would magically follow (as if every IT person was completely interchangeable). Sound crazy, right? We had too much focus on spreading capital amongst the many projects in play, with no solid prioritization list. We were often stopping, pausing, re-starting projects which was very disruptive. There were also wild swings in the IT capacity management because we couldn’t plan for any length of time. The new CIO convinced the Finance teams that it was better if IT managed its portion of the budget. He instituted the idea of a Priority Board, comprised of the senior executives and a fixed-capacity model which drove the 1-n prioritization model (based on intended business benefits). Fixed capacity meant that if a new high priority project came in, then some other project needed to come off the list. I managed this process and refined it over the years. Transparency was key to the success of this model. We kept allocation at the program level (each program could contain several potential projects). This was important as we learned we couldn’t be that perfect in predicting what each project would need over the coming months/year. This allowed flexibility and stopped the wasteful process of doing detailed cost estimates. We insisted that business benefits (rev / cost savings) be documented and concurred by Finance. Each Fall, as we set the upcoming year’s budget, we all aligned on the top priorities through the Priority Board meetings. It was important to show what was above the budget line and below (because if capacity allowed, we would bring up more work into the dev teams). An important part of the meeting was to review business benefit results / adoption. We stopped talking and worrying about how much each project was spending and spent more time on what mattered – benefits realization.
• Focus on product enhancements vs customer adoption. In our pre-Agile days, there was a strong dominance from the product team, to keep adding product features. IT teams were only too willing to please and we went through many cycles of adding more. We had a lose-lose environment: infrequent releases and a long sales cycle (would take a long time to generate customer feedback). The emphasis was on getting into a release and not what happened after the release. No one wanted to talk about customer adoption. Once we implemented MVP (minimum viable product) approach, with more frequent releases, we were able to get feedback from the customers and/or pilots before additional investment occurred. The key factor for this turning point? A strong partnership between the IT and Product PMO leaders and their willingness to support each other to drive change. This also resulted in more efficient use of capital because we knew better what the customers wanted or didn’t want. We became more practiced in saying “enough” or “stop”.

Agile Transformation

This is a continual journey. Looking back, these were the three major progressions and learnings our teams went through.

• Too many projects jammed into 2-3 releases a year. Not only did this drive the behavior mentioned above (teams’ singular desire to get their projects into a release), but it was not sustainable from an IT perspective – when you consider as many as 40 systems could be involved. We reached a breaking point when one of our major releases had to be cancelled because we couldn’t get through the testing and had limited ability to back out code. We revamped the process into smaller sets of projects with Major releases (requiring integrated testing) and Minor releases (needing only system testing) alternating every other month. We also instituted a rule that code needed to have an on/off toggle (this was in the 2007 time frame, before Dev Ops was a concept).
• Agile as an IT only program. A couple years later, we took a strong step in becoming Agile. We had had about 40 IT managers trained and certified as Scrum Masters and also hired Agile coaches. We made progress, but only with those projects involving a limited set of systems (small projects). We didn’t have full buy-in from the IT Execs and the CIO was hesitant to push for Business involvement (and, rightfully so, because Agile can’t be a one-sided “push”). The teams who adopted Agile stayed with it, but we plateaued and continued to live in a mostly Waterfall world.
• Agile with Business and IT together. This is where we made our breakthrough with the critical elements in place: Supportive Business Unit President, a new CIO who relentlessly promoted adoption, and our custom developed three day training sessions with IT and Business teams (emphasis on Agile mindset and User stories). We developed new roles akin to Product Owner and Scrum Master. We called this “two in a box” – whereby both the Business and IT leader owned the project together – from inception through iterations through value delivery. We made short u-tube type videos where the IT and Business sponsors talked about how the Agile approach completely changed how work was delivered. This was one of the most effective ways to promote Agile and teams were proud to showcase their work. It took about two years, but we finally got away from large Requirements documents and into 90 day delivery cycles.

How to Get Teams to Embrace and Drive Disruptive Change

• Deliver faster! Cut costs! Protect sensitive data! Go Digital! Do Agile! Do DevOps! Go to the Cloud! Use new technologies! Disrupt yourselves! This is the constant messaging throughout the Technology industry. You can’t just throw technology and training at teams. They have to want to change and not fear the unknown. But, how do you do create this environment?
• Teams can do amazing things when they are empowered. We developed a series of two-day workshops on technology disruption and ways we could change how we work. The IT leadership teams put together a set of short videos, interactive games, brainstorming and skits to create a safe environment to play and experiment. We had three areas of focus: Accountability / Ownership, Collaboration and Leveraging Technology. On the technology side, we were already immersed in a variety of initiatives (Agile and DevOps being the most established). We included Design Thinking to generate customer-centric solutions and the power of Hackathons and Crowdsourcing to solve business problems in a time boxed setting. We used the power of the team to think of better ways to accelerate Cloud Migration and improve data security. Once we had our primary workshop, we then went out to the major field locations and repeated the same workshop with the local managers and key contributors. We shared our approaches with business teams who also wanted to participate, with cross-organization Hackathons being the most popular. We conducted several 48 hour events where teams were allowed to “break the rules” and competed to come up with working solutions to business problems. Our approaches proved once again that the most effective way to engage and energize teams is to involve them and give them the flexibility, tools and encouragement to figure out “how”.

Foundation For Success

Time and again, I’ve found the following traits to be the foundation for success:

• Lead by example. Never ask your teams to do something that you aren’t willing to do with them.
• Plan ahead and give attention to detail. What possible things could go wrong? Often wrong assumptions have been made that could have been easily checked out earlier and mitigated.
• Communicate often: status, results, issues, risks, solutions. Most importantly, communicate how you are bringing value.
• Ask for help and feedback.
• Build and sustain trust-based relationships: start with how you can help the other person/team (vs focused only on your needs).

Good luck in your leading your PMO! Please feel free to comment below for questions, comments or assistance. You can find Carolyn on LinkedIn.

Thanks for taking the time to read this article.

Click here to receive these blog posts right to your inbox.

Fill out our one-minute survey if you have topics you would like read more about.

I welcome your feedback and insights. Please leave a comment below.

See you online!

Warmly,