Shannon Kirchhoff has always worked at the intersection of technology and business. With stints in project management, business analysis, and operations, it made sense that she would be called upon to set up a project management office - a PMO - when she joined Fireman's Fund Insurance Company three-plus years ago as senior director over IT portfolio management, governance, and standards. Owned by Munich-based Allianz SE, Fireman's Fund has 3,900 employees and 50 offices in the United States.
"The CIO felt that there were too many surprises with projects," she recalls. "There were project change requests. Dates were being missed. Internal customers were not happy with the progress or the surprises, or they didn't understand where we were headed." The PMO enabled IT to gain consistency and control over projects and to become the "one source of truth for how projects were being executed."
About a year ago Kirchhoff expanded those efforts when she became the assistant vice president at Fireman's Fund in charge of a corporate-wide PMO. In this interview, she examines how to evolve a PMO company-wide, shares what she would have done differently, and offers advice to other organizations for setting up their PMOs.
Pcubed: You introduced the PMO in the IT organization in a staged manner. How was the PMO received?
Shannon Kirchhoff: We first set up a funding gate process - an approval process. You didn't get funding [for your project] until you went through that process. So we started with things that would help [IT people]. The first thing out of the gate was super simple: "Start doing status reports, and here's the template." Every sponsor, every manager had a different way of doing it. So that was actually a benefit to IT to get a consistent approach provided to them. I facilitated dialogue to get everyone to agree that that's what they would accept from their projects and not require additional work. Over time, the PMO also introduced criteria for how projects would be measured and how frequently project teams would meet.
That's a critical point. The value of a PMO is not just to help your senior leaders. It's to help your project managers execute more effectively.
From an IT perspective, while it was accepted pretty well most of the time, it still took organizational change management. But within that particular department at the time, the CIO was adamant. There was incredible leader support. That helps.
Then you moved out of IT and became the assistant vice president at Fireman's Fund in charge of a corporate-wide PMO. How did the PMO evolve?
Keep in mind that you have IT, which is the vast majority of projects in probably any company. Then you've got non-IT. The things IT struggles with are, of course, the business being involved enough, the business understanding the complexity of IT's work and how challenging it really is. That link between business and IT is a challenge in any company.
When the business is working on non-technology projects, they generally don't have people trained in this discipline. So they spend time without structure, or they spend time creating structure where they don't need to, because the PMO has already created it.
What about on the senior executive side?
Sometimes they're totally on board, and sometimes they're not. I say that because getting up and running, they're on board because they want to know what's going on: "What are the projects? How are they doing? What can I expect from them and by when?" They want all of those things. With any senior executive team, when you're in build-up mode, they're seeing value because they know they need it. When you start to get past that curve, they think, well, you've already built up. Can you go do something else? The need to maintain is sometimes lost on people.
Any time or money spent in any company towards generating income is always offset by the time and money in that company spent controlling that activity. That includes finance, project management, process work - that is a direct offset to profit. You need to reduce that as much as possible in order to maximize profit.
For example, we might say, "You need value management." Earned value proactively allows you to see whether or not you're tracking appropriately to what you planned and to extrapolate that across your entire project - to decide where your project will end up if you continue at this pace. If you aren't in the business of project management, it can be a little foreign. "We're not in the project management business. I just need to deliver. I don't want to support all that. That's complicated."" Then you need to explain that you don't want to end up in meetings where we didn't deliver, that you don't want to answer the question: "Shouldn't we have known that this wasn't going to deliver?" That's where earned value can help you predict potential issues.
It's a constant balancing act, to make sure you only have the amount of control you need to execute.
How does the PMO operate within the organization?
We do strategic alignment and governance. Anytime somebody wants to do a discretionary project, they come to us, and there's a template they need to fill out to make sure it's aligned to strategy: What's your scope and what are your objectives? I facilitate a steering group committee that meets monthly to look at all the project requests and the current portfolio and to make decisions around that.
We interact throughout the lifecycle of the project. At certain points, they have documents that we sign off on. Then at end of particular phases, we give them "gate clearance."
We also receive all the reporting and rollup reporting at the portfolio level. We participate in steering committees on the project - though only for the strategic projects - those $500,000 and above. We help guide and mentor them. Currently, for example, we have a very large portfolio of projects that kicked off simultaneously and significantly depend on each other. There was a lack of skills to handle such a large number of interdependencies - so we built a dependency model to address that.
What's that look like?
We have a Microsoft Project Server environment. From the complexity perspective, we have maybe 30 or 40 schedules, so it's hard to link projects together when you have that many. That's incredibly disruptive in overhead. We built coding into the schedules to be able to do that via reporting as opposed to built-in links. Bi-weekly, we go through dependencies with them and talk through what's coming up: "Are you on track? Do you realize that this person moved their date and that impacts you?" So we work through those issues with them as a group.
We hold weekly portfolio-level working groups to discuss people, process, and technology impacts across the portfolio.
If you had the chance to do anything different with the PMO, what would it be?
I would have really pushed for more time to do grassroots education and buy-in. I'd have probably done subject matter expertise sessions to facilitate the solutions collectively with larger groups. We had to be a light model, we had to go super fast, and we had very limited resources. It was always, you have to implement [the processes] and teach them what you've decided as opposed to working collectively in a collaborative setting to decide together.
Some probably would have asked, "Why would I want to spend two months collectively coming up with an idea that would have been 90 percent the same as what we did ourselves?" To me, that's short-term thinking. To get [people] to adopt it and use it is actually faster overall if you take the two months to begin with. When it's their idea, they do it. I tried, but you can't win 'em all.
What do you advise to others in setting up their PMO?
First and foremost, understand your culture and manage the organizational change as your top priority. Any change in a company is predicated upon your culture. You can give people process and technology. The only thing that matters is the people. The one piece of those three that can derail you without a doubt is the people. You might call it a three-legged stool, but one leg is far more important than the other two.
Take a staged approach, instead of a big bang. Focus on the value that you offer to the people who actually do the work as opposed to the value you offer to senior leaders. No offense to your senior people, but the reality is, what they care about is execution. Stay focused on enabling execution.