I mentioned in the last post the shift from project management to program management as one of the many important shifts in business-IT maturity that typically take place around the middle of Level 2 (in a simplified 3-level model). I want to explore that in greater detail in this post, and connect it to Portfolio Management which I see as a key discipline in getting to Level 3, and to extracting high, visible business value from IT investments.
A recent post, Programs are More than Just Big Projects, by colleague and friend Roy Yougman in his blog http://www.ryoungman.net/ inspried me to discuss Program Management as a critical link between Project and Portfolio Management. In a simplified sense, project management deals with a single project (be it small or large) with a focus on producing agreed deliverables, to an agreed schedule and budget. Program management deals with multiple projects that collectively produce an agreed business outcome – i.e., they have inter-dependencies (e.g., impact the same group of stakeholders, each contribute to achieving a business outcome, and depend upon each other to do so). It is the management of these inter-dependencies against the delivery of the agreed outcomes that distinguishes program from project management. I have to acknowledge that the terminology here, though well defined in the project management literature and sources such as Wikipedia, is not universal or used consistently. In the aerospace/defense industry, for example, programs have a different connotation more related to funding.
If projects can be thought of as the bottom of a hierarchy, programs sit above them in the middle of the hierarchy and address a related set of projects, then things get to be most interesting at the top of the hierarchy – the portfolio management level.
My favorite source on IT Portfolio Management are Prof. Peter Weill and his co-author, Marianne Broadbent. Their first book that addressed this topic was Leveraging the New Infrastructure: How Market Leaders Capitalize on Information Technology. There are various IT portfolio models around – the reasons I like Weill’s are:
1. It differentiates the IT investment in common, shared infrastructure (broadly defined).
2. Weill has years of benchmark data showing how portfolio allocation varies by industry, and how it reflects business performance.
As I get personally closer to retirement, like many boomers, I give increasing attention to my (meagre!) personal investment portfolio, which makes personal investments and portfolio theory a great analogy for IT investments. My portfolio goals have changed over time as my circumstances have changed (e.g., putting a kid through college, getting closer to retirement). Whatever those circumstances, I’ve had the discipline (thanks to an investment advisor) to annually re-think my portfolio strategy, to be explicit about it, and to monitor the performance of my portfolio against that strategy, and adjust periodically.
In the IT portfolio domain, the same is necessary. How much of our IT spend should be leveraged across the firm? (By the way, a common challenge is the funding mechanisms for common infrastructure are often weak – another Level 2 trap is that funding in Level 1 and early Level 2 tends to be by the project, and for given business units – nobody likes to fund cross-business unit initiatives!) How much should we be spending on “risky” but potentially high value initiatives? How much on informational (business analytics/decision support)?
Another Level 2 trap is that a firm’s earliest entree into IT portfolio management is typically limited to new spend. However, the reality for most enterprises is that new IT spend represents less than 30% of total spend, so there is bigger value in applying IT portfolio management to the steady state services (bringing us back to Service Management mentioned in an earlier post)
My key points through all this are to get through Level 2 to Level 3:
1. You need great project management as a fundamental discipline.
2. You need great program management as a bridge to portfolio management. You can’t easily go from project to portfolio – there are just too many projects, and projects are focused on deliverables, whereas program focus on business outcomes – which is what portfolio management needs to focus on.
3. The biggest impact in terms of advanced IT practices comes from portfolio management (the IT investment strategy), and if you are weak in project or program management, you will never get the full potential of portfolio management.
Filed under: Business-IT Governance, IS Management, IT Management, IT Maturity, Key Frameworks, Portfolio Management, Supply Maturity Tagged: | Portfolio Management, program management, project management, Service Management
[...] At some point in mid to upper Level 2, the business case shifts from an approval/prioritization tool to a value realization tool. Formerly, you put stuff in the business case that you hoped would help get it approved, but you knew nobody would ever look at the case once approval was gained. There really was little to no accountability for the case, or consequence, or even learning that takes place about hte quality of the estimates and assumptions that went into the case. As a value realization tool, on the other hand, the estimates are taken very seriously, and accountability is now placed around achieving the forecast benefits. Of course, the ability to tightly link business benefits to a given project is very tricky in all but the simplest cases. It becomes somewhat more reasonable to link business benefits to programs, rather than to projects, as programs are, by definition, oriented towards business outcomes. (See earlier post on Projects, Programs, and Portfolios.) [...]
[...] Posts Business-IT Maturity – a helpful lens for the future?AboutProject vs. Program vs. Portfolio ManagementCIO vs. CTO – What’s The Difference?Business-IT Maturity Lessons from Capital MarketsWecome Back, [...]
[...] an earlier post, I discussed the differences between and relationships among Project, Program and Portfolio [...]
Very good information! Thanks very helpful.
[...] Posts Project vs. Program vs. Portfolio ManagementIT Service Management vs. IT Product ManagementThe “Unwritten Rules” of Business-IT [...]
Hi, very thanks for your post. I was informative.
I’m doing a reaserch on how do organizations group their projects into programs, please tell me how do they go about doing that. e-mail me as soon as possibel
Siyasanga, thanks for your question. It is an important question, but I won’t answer it by email – I think other readers of this blog may benefit from this discussion, so I will write a new post on this topic.
Hi, im student form UJ and i would like to know about how your organasation group its projects into progarm and i also need to know how do you go on creating your project portfolio.thank you!
Tiyiselani, I had the same question from a reader last week, and created a new post to answer it. Please see my post at http://vaughanmerlyn.com/2009/03/06/the-art-and-science-of-grouping-projects-into-programs/
I hope that helps – thanks for your quesiton!
[...] Posts ITIL: Necessary, but not sufficient!Project vs. Program vs. Portfolio ManagementShadow IT: The Good, The Bad, and the UglyThe Economy, Information Technology and Opportunity [...]
[...] Project vs. Program vs. Portfolio Management « IT Organization Circa 2017 [...]
[...] Posts Project vs. Program vs. Portfolio ManagementThe Accidental Project ManagerExploring an IT Operating Model for Enterprise 2.0 – Part 2CIO vs. CTO [...]
“I have to acknowledge that the terminology here, though well defined in the project management literature and sources such as Wikipedia, is not universal or used consistently.”
I particularly agree with this statement. As the lines between project, program, and portfolio vary so greatly from company to company and are so blurred between industries, it is hard to exactly define them. I’ve also had a difficult time looking through the many software solutions claiming to be specific to the type of management it handles. They say things like, “For all your portfolio needs,” or “Manage your tasks with ease,” or “See how successful your programs can be.” (Rhyme not intended.) Because of all this confusion, I think that is why work management is beginning to be chosen over the strict process and definitions of project management and all its related components and disciplines. Work management encompasses all of it in a more dynamic way. It doesn’t dwell on defining the hierarchical structures of work, and just lets people get to the point. I am not saying that everything about project management is debunked. In fact, all of its processes are still applicable, but they function in a more adaptable way.
You raise a great point re: “work management” Robert. On the one hand, this makes sense given the lack of consistency around the definitions. On the other hand, it is, as they say, a “cop out” and risks further reinforcing a lack of clarity. There are good reasons why scientists are so obsessive about hierarchical structures – atom, electron, nucleus, etc. Rigid hierarchies and the precision they imply are the underpinnings of good science, and good science is the underpinning of good exploration and understanding. If we give those things up in the world of IT we put ourselves at great risk, IMHO.
Well said. Too often, it does become a “cop out” (and a sometimes arrogant) way of disregarding those skills and methodologies that have been researched and refined for decades (or centuries arguably). The successful project manager comes somewhere in between, where he or she can adapt to what needs to be adaptable and stay strict to those places where the project requires it.