In the project management discipline, a dividing line between projects, programs, and portfolios is emerging, and beginning to be codified. It's recognized by the UK Office of Government Commerce (OGC), and documented in that influential body's P3M3 Maturity Model, which formally differentiates between these three levels of project management. According to the OGC, which has become a de facto standards body in the PM world, here's how the difference between portfolios, programs, and projects is defined:
- An organization's portfolio is "the totality of investment in the changes required to achieve the organization's strategic objectives."
- A program is "a temporary structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes related to the organization's strategic objectives."
- A project is "a temporary organization created for the purpose of delivering one or more business products according to an agreed business case."
Why should project managers (PMs) care about these formal and academic-sounding definitions? Are they going to assist us when we run into the typical problems of project delivery, such as resistance, conflict, overburdened staff, and unclear scopes and objectives? Although these differentiations may seem remote from the daily challenges of the working PM, I submit that understanding them, and, more importantly, ensuring that our clients (internal and external) understand them as well, can go a long way towards setting our projects up for success.
Although the IT world has been talking about portfolio management for years, and many firms have invested in portfolio management tools and have begun to apply governance to their project investments similar to the portfolio discipline that investment managers apply to their financial decisions, my experience is that these are still by far the minority.
Many more companies that I encounter in my consulting work, rather than applying a disciplined risk vs. reward or return-on-investment model to their project decisions, apply what I'd call a "wish list" approach. In a typical wish list scenario, executives or IT teams gather for a strategic planning session, and then proceed to go around the room department by department, listing on a whiteboard all of the IT initiatives they wish they could deliver in the coming year. Some prioritization may be applied, but it's more in the vein of "I like this idea better than that idea" rather than "here's a disciplined business case that describes why it makes more sense to invest in A over B."
The use of the word program is, in my experience, often seen as a way to enhance the gravitas and significance of an effort, rather than as a clear dividing line that describes a manner of managing and measuring results. Many senior project managers find themselves promoted to Program Managers, as if the mere use of the title somehow conveys added authority and expertise. Other organizations use the language of "Programs" to lump together any set of remotely related projects, but then proceeds to run each project separately, with its own team, PM, and deliverables, and the "program" element doesn't influence the measurement or integration of the results in any way.
Projects are well defined, and any of us who have taken the PMI exams or sat through any project management training is quite familiar with constraints, risks, knowledge and process areas, and all the other accoutrements of formal project management. It's rare, in my experience, for trainers who test in this area to clearly and decisively paint a picture of the interrelationships between the portfolio, program, and project levels, and to prepare PMs to add value not only at the tactical level of managing the actual doing of the thing, but also at the strategic level of adding value for their customers on the factors, determinations, and metrics that ought to drive their decision process at all three levels of the achievement pyramid.
I use this language very consciously because I want to emphasize that what we're talking about here is the mechanism by which companies achieve their goals. Whether it's Amazon rolling out a new line of products, or Facebook changing its interface to incorporate a timeline, or General Mills emphasizing the whole-grain content of its cereals, each of these strategic ideas must make its way through the pyramid from a strategic concept to a program or series of programs (such as a marketing program, an operations program, a customer support program, and a supply-chain program), and each of these programs will be composed of multiple projects.
So, what exactly am I suggesting that practicing PMs do with this information?
- Think through the pyramid: Too many PMs, in my experience, are so focused on the granular tasks and constraints of the project in front of them that they never stop to consider the broader context of the work they're managing. Don't be afraid to probe a bit and ask about the strategic direction that's driving your particular effort. Sure, you'll sometimes encounter customers or managers who may respond with "just worry about your piece and leave the strategy to us!", but many more will be impressed and gratified that you actually care about the business results that your efforts are driving towards.
- Build a hierarchy in your mind: Even if you're managing a very tactical effort at the granular level of a project, create a mental map of the interconnections between your project and the others in the program, and help your team see that map as well. In fact, some of the best PMs I've known will build a mindmap, or a Visio diagram to explicitly illustrate the interplay between efforts.
- Build relationships across projects and programs: It's not enough to understand how the pieces fit into a corporate strategy — the next level of added value emerges when mature PMs use their understanding of the interconnections to seek out and build collaborative relationships with the teams that are working on other parts of the program. Project management is a human discipline, and the interconnections made in the pursuit of achievement will enhance results for all.
We've only scratched the surface of the ideas that this achievement pyramid has stirred up. We'll talk about many more aspects of this method for grasping the totality of meaning associated with our project efforts in future posts.
Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile practices and migrate successfully.