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 the CMMI Institute’s maturity models, 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.
These two tasks serve as the basis for many upcoming blog posts, and for our upcoming book: The CIO’s Guide to Breakthrough Project Portfolio Performance…stay tuned for details, and let us know if there are specific relevant topics you’d like us to address!
The book is now out, in Kindle eBook format, with print versions to follow in a few weeks—check it out here!