Matt Light on the PMO and Agile

3 key challenges of IT PMOs today Challenge #1: Developing expertise in IT vendor management (0:05 to 02:20) Perhaps, I'll start with one that you don't hear as much about, but in which, I think, PMOs are involved, and that's what I'll call the "Project Supply Chain", if you will. Maybe, the paradigm has shifted, and maybe there's been a tectonic earthquake in some organizations from one where our internal IT organization would largely deliver the necessary projects, as well as ongoing support of the IT infrastructure, with some help from an external service provider. Every now and then, we'd hire out a project to a contractor: it's a big project, and we didn't have the capacity, or something like that. More and more, I think PMOs find themselves in the position of vendor management and procurement management, where they're managing networks of subcontractors underneath a contractor and trying to blend their internal staff, who may be less and less project-oriented and more just kind of keeping the lights on. So, what's the right balance between that? Are internal project managers working with the service provider's project managers? There's so many issues that come into play. We might have a vendor management or a procurement management office already in place, but they don't have the expertise to deal with IT project contracts. They really can't evaluate them, they can't monitor and control them, and ride herd on them, as we say in the Old West. So, this is a big issue that doesn't get as much attention, I think, as it should, 'cause a lot of PMOs are not good at it because it's kind of new on their radar, and they don't have that vendor management skill set, so perhaps working on the collaboration with the vendor management or procurement people, working on building up what they can do, and working on recognizing that this issue is a growing one. It's not going away. It's kind of the newer paradigm. Challenge #2: Learning to balance Agile and classic phase-gated Project Management (02:21 to 3:43) Of course, you've got to mention Agile, but not just Agile. If you haven't seen sparks fly between Agile practitioners and advocates, and traditional project managers and PMOs, then you haven't been paying attention. Either that, or you're late to Agile. PMOs have to become conversant with and indeed expert at Agile project management and balancing Agile projects and methods with what sometimes are the better fit. More traditionally phase-gated projects are often the fit. If you're not exploring into completely unknown territory, if a project will yield to analysis and you can come up with a good reliable schedule, then why wouldn't you do that? Why go through a bunch of iterations where you don't really know what's coming next, and what resources you'll need, and that sort of thing? So, different methods will fit different projects best, and so there's going to be, I think, a hybrid middle. There will be the pure Agile innovation-driven types of projects, and then there will be some more traditionally phase-gated types of projects, and balancing those and winning credibility instead of enmity from the Agile practitioners will be an important challenge for the PMO. Challenge #3: Making the transition to Enterprise Portfolio Management Office (EPMO – 3:44 to 5:08) Perhaps, most exciting for some PMOs is the switch, the evolution or transformation of an IT Project Management Office. Often, with some success, people start to turn to that IT PMO to do more, and they're often pushed to evolve into an Enterprise Portfolio Management Office. And, there's some real challenges in making that transition. If you focus too much on the new EPMO responsibilities, then you drop the ball with what you were successful at previously. If you don't try to develop and acquire the right skills, and add the right staff to become effective as an Enterprise Portfolio Management Office, then you will disappoint that expectation that you can grow your value proposition from just the IT projects to the whole enterprise portfolio, the support for strategic execution. And, I think that that is an important challenge for successful IT PMOs. Be careful about being successful because then they want you to do more. There's the old saying, "If you want something done ask a busy person." And, I think many successful IT PMOs are that busy organization. PMOs should be Centers of Excellence The PMO – in addition to providing project management training, and that can include Agile training – can and often should be the source of the best project and program managers. This increases its value to the rest of the organization and puts it in high regard. When you've got a big risky project, who you gonna call? You call the PMO because we need the best project and program managers that there are. This means that the PMO is a career destination for project managers who may spend their apprenticeships and their junior years in other business units or different parts of IT, but rather than their careers going in some other direction, and we're always losing our best project managers 'cause they been doing it for 10 years and they want a promotion, they've got a promotion into the PMO. And now they will be the tool jockey, they will be the analyst, they will be the strategic balancing the portfolio at the front end or the metrics guy at the back end. And so, I think that that's an important dimension that's often lost in the discussion of today's PMOs. Overseeing the project intake mechanism (0:50 to 1:22) On the incoming side, a good PMO will have some staff who are focused on reviewing the projects for their alignment with a strategy, and connecting with other stakeholders, perhaps there's an architecture review board and we want to make sure that new projects are in keeping with our architectural direction. So there's this kind of front-end intake side of things that a PMO provides. A single source of truth for project and portfolio data (1:23 to 1:47) Then of course the main thing that we tend to think of is the reports and how you get the data into the tool, so you've got a tool jockey, you've got analysts, cost analysts, schedulers... Depending on the size and the complexity of the organization and the projects, there could be a number of staff in the PMO that are focused on those kinds of functions. Drawing the lessons from past projects (1:48 to 2:59) And some of those people, or even some of the front-end people I mentioned before, can also come in toward the end of projects to perform another important role: the post-project review. So we're gathering data, we're making sure that we understand how much time and effort went into the projects, how many interventions, whether they were successful, defects, variances, all kinds of things from which we can learn. So to come back to Lean Management, you've got the whole Plan / Do / Check / Act cycle, and although many, again, give lip service to this, we Plan our projects, we Do our projects, sometimes we even Check our projects, that is study the results, that's important, nobody else does that, and the PMO I think can take an important role in that, and to try to make sure that you then Act on that information so the next time a project comes in, just as a simple example, you don't underestimate it by an order of magnitude because you learned from the last 10 projects how long this thing is really going to take. Will Agile take over the world? Well Agile is already taking over the world. The Agile principles of trying to be dynamic, to be able to adjust to changes, to try to avoid overhead and inefficiency and get value to customers as quickly as possible. Many of the principles of Lean Management there were incorporated into Agile methods for application development organizations are at least given lip service across most enterprises. So, a lot of the values of Agile will get acknowledgment and head-nodding. They won't always be able to transcend some of the management structures that are in place in many of our enterprises. I do think that the way forward to the Agile enterprise, is not through the Scaled Agile Framework. This might sound like a contrarian view, but SAFe is very explicitly about complex system development. It's for the software guys. It's not for small Agile teams. This is "Scaled". The whole idea is we've got hundreds of developers working on big complex software programs, that contribute to major long-term value streams and it really is, I shouldn't say all about the software, because software's embedded in so many of our products, everything from cars, to what we were joking about toasters last night. One customer's saying, "It's a toaster. It's already a minimum viable product. What am I gonna do with software in my toaster?" Well you'd be surprised with what you can do with software in your toaster to innovate. So, I do think though, that many of the underlying principles that drove Agile into software development, are still in place and as I say, those Lean Management types of principles have gained broad acceptance. What I think we have yet to see is the real implementation of those Lean Management practices in many of our larger enterprises.