In today's post, I am sharing a post from a good friend of mine, Mike Hannan. You will recall in my last posting that Mike was one of the 3 co--authors of a wonderful new project management book entitled, The CIO's Guide to Breakthrough Project Portfolio Performance: Applying the Best of Critical Chain, Agile and Lean. In the coming months I will be sharing some of Mike's own blog postings with you and this is the first one. Because Mike is an excellent writer, I think you'll enjoy this posting very much....especially if you're in a project management environment.Bob Sproull
Why IT PMOs Fail to Improve The Only 2 Things That Really Matter: Throughput and Reliability
It’s a good bet that your IT PMO places lots of emphasis on reusable templates, on adherence to established standards such as the PMI’s PMBOK or SEI’s CMMI, and on how best to govern project investment decisions. Seems reasonable and appropriate, right? After all, we’ve all seen what a mess things can be when there are no standards, no templates, and no real governance.
But what if it were your money being used to fund the IT portfolio? What would your primary metrics for success be? Would they be “# of templates in use” or “# of PMP-certified PMs on staff?” Of course not. Like any rational investor, you’d want to measure the results achieved, and how reliably those results are achieved. In project terms, this means how many projects get completed (throughput), and how well projects meet schedule and cost expectations (reliability). So if maximizing throughput and reliability are the primary objectives of any project portfolio, why do so many IT PMOs seem to focus on other, far less important metrics? Perhaps even more critically, why do so few IT PMOs adopt disciplined methods and approaches designed to maximize throughput and reliability?
The short answer is that most IT PMO leaders simply aren’t aware of such methods and approaches. For example, if we consult industry standard-bearer PMI for advice on the subject, its website says this about how portfolio management contributes to organizational goals: “Aligns with organizational strategies by selecting the right programs or projects, prioritizing the work, and providing the needed resources.” All important contributions, to be sure, but no mention of throughput or reliability. Again, if it were your money funding the portfolio, wouldn’t you want to see some emphasis on performance and results?
But wait, what about Agile? Won’t Agile help us improve throughput and reliability? Quite possibly! There are now many examples in which Agile is credited with improving both speed and reliability at the project level. And if Agile can help us improve a single project’s speed and reliability, then by simply adopting Agile on all projects, we should be able to improve throughput and reliability across the portfolio, right?
Yes and no. Some notable attempts at “scaling” Agile across an entire project portfolio have certainly shown improvements in both throughput and reliability, while other such initiatives have failed to achieve any improvement at all. Why the hit-or-miss record? Many observers point to culprits such as “lack of executive commitment,” “resistance to change” among staff, “poor training” in Agile/Scrum techniques, and so on. While these may in fact be contributing causes of failure, they are also convenient scapegoats.
I believe the real answer is this: Some Agile techniques work for some projects, while others don’t—and in any case, Agile wasn’t designed to maximize portfolio-level throughput and reliability.
If true, this assertion leaves us with two tasks:
1) Find out which Agile techniques work, and for what types of projects—and then apply those techniques accordingly at the project level (and discard those that don’t work).
2) Find an approach that is designed to maximize portfolio-level throughput and reliability, and adopt it.
I will address both of these in future posts, and for those in the DC area, offer in-depth insights and experiential simulations in my full-day class on Taking Agile to the Enterprise on May 2, 2014.