Project portfolios are often compared to financial portfolios, where investments are balanced – and, if you’re lucky, returns optimized – based upon an established asset mix. Depending on how different markets are performing, your financial portfolio may need to be rebalanced periodically, but overall your portfolio’s asset mix should reflect your values and intentions as an investor. Similarly, in project portfolio management (PPM), the portfolio should ideally be an expression of an organization’s needs and goals, and a target investment mix is required to ensure that each goal – be it strategic or operational – is sufficiently expressed via the organization’s project activity.
In IT, this gets thorny very quickly. Where, at its most simple, the financial portfolio can be thought of as a one-to-one relationship (i.e. an investor and her portfolio, constrained only by market conditions and her access to investment capital), the IT project portfolio is not quite so contained. There’s an organization’s worth of stakeholders constantly vying for some say in what goes into the portfolio, and myriad constraints (e.g. human resources, budget, technology, strategy, etc.) that ultimately limit the portfolio’s composition.
This hasn’t stopped the PPM industry from trying to transpose the notion of an “asset mix” onto the IT project portfolio. Most predominant is the “run-grow-transform” model of project categorizations. This rubric has become the new normal in IT, but the categories haven’t changed the fact that most portfolios – especially those in industries like construction, where IT implementations are often focused on servicing the needs of a much larger implementation – are primarily driven by a project category that is best characterized as “appease”: somebody in the organization wants it and, as order taker, IT is doing it. Indeed, in the quest for a well-balanced portfolio, organizational politics and pet projects continue to be the not so invisible forces that skews the scale again and again, making the notion of an “ideal mix” a potential white whale for portfolio managers.
Run-Grow-Transform (so common now that they’re often referenced simply as “R-G-T” in literature on the topic) originates with Gartner’s approach to IT budgeting. The model is intended to help IT leaders inject a good investment mix into their budgets and resourcing spend in order to help them maintain legacy systems as well as drive business growth and innovation. “Run” tends to be the majority of what we think of as “a day in the life of IT” (e.g. systems support and maintenance, firefighting, etc.) and encompass what are typically nondiscretionary, run-the-business costs. “Grow,” on the other hand, tends to be more discretionary in nature –investments made around developing and enhancing systems in support of business goals and growth. “Transform” investments are those made in the service of change and breaking new ground for the organization, i.e. taking the business from one level to the next in terms of revenue, market share, and expansion.
From an IT budgeting standpoint it makes sense and is a good model. Indeed, Info-Tech’s own spreadsheet-based PPM tool, Portfolio Manager 2017, comes with R-G-T in the sample test data on the set-up tab. However, while the categorizations make sense, not a lot of organizations are able to sustain what Gartner identifies as a “target investment mix.” Gartner identifies an ideal mix of 50:25:25 R-G-T, but also acknowledges that the current average for organizations is 70:19:11. What’s more, to be honest, I don’t see a lot of my PMO and portfolio management clients categorizing their projects and portfolios across these categories with any great regularity or conviction. It’s a nice idea, but not a lot of people are able to plan and prioritize their portfolios around it.
As stated above, attempts to transpose the financial portfolio’s “ideal asset mix” onto the project portfolio is built upon a faulty parallel. There’s simply too many stakeholders influencing the project portfolio, and a complexity of constraints pushing and pulling the portfolio on a daily basis, that striving for an ideal mix like 50:25:25 is a bit of a lark – at least in the early stages of your PPM maturity. Most organization’s portfolios are more like a slapdash collection of stakeholder wants and desires, rather than a strategic expression of the organization’s goals. To try to superficially impose an ideal mix on to that is a recipe for failure, especially when fires are constantly erupting, project priorities are not firmly established by the portfolio owners, and visibility into capacity is opaque.
Rather than starting with a consulting company’s project categories and an arbitrary target mix, you’ll likely get more value by taking a more organic approach in the near term. COBIT APO05 (Manage the Portfolio) provides some insight here, even for smaller IT departments that may at present have little-to-no COBIT alignment. The process mapped out in APO05 can help transform PPM from a random and overwhelming guessing game to an organized and manageable collection of projects that are contained within the organization’s actual capacity and aligned to the organization’s goals.
The first step is to establish portfolio criteria and constraints that will help organize and inform the decision-making process on what gets into the portfolio and what does not. The criteria are typically defined by asking “What should IT be providing to the business?” and your answer to this question should be informed by such things as mission statements and strategic and operational goals. The constraints are best defined by asking “What is the business giving IT to work with?” and your answer to this will typically parse such things as your budget for project, your human resource capacity, technology capabilities, and risk guidelines.
Once you have your initial criteria and constraints identified, you can move forward to assess the current state of the portfolio and set a near-term target mix based upon your current mix. Some things to consider when reviewing your current mix could include such things as goals not represented, too much or too little risk, the inclusion of non-viable projects, and so on.
With strengths and weaknesses in your current mix identified, you can move forward to better define an ideal target state mix, defining the criteria that should be used to determine what kind of projects should be admitted into the portfolio, and that should be used to determine how projects and resources will be distributed across the various goals (strategic and operational) and the various business units across the organization. Based on these criteria, consider how projects and resources should be distributed across the various strategic and operational initiatives and across the various business units. The proportion of projects and resources allocated should reflect the priority of the goals and the ability of each business unit to advance those goals through projects.
At the end of the day, the main takeaway should be that there is no archetypal “asset mix” that all project portfolios must strive towards. Rather, a target portfolio mix should be the product of some self-reflection from portfolio managers and portfolio owners alike about what goals and outcomes the organization values most. In this way, a mix can be established that is the product of stakeholder consensus and buy-in, which is key as portfolio managers must also ensure that they have clear guidance as to how the projects and resources available to the portfolio are to be distributed across the various goals and across the various business units. In other words, for any target mix to be sustainable portfolio managers must also have a clear mandate to carry out and enforce it. Otherwise, “appease” will continue to be the project type that skews the scales of portfolio balance.
Don’t set your portfolio up for failure by adopting an unachievable target mix. A realistic and sustainable project portfolio mix should be informed by organizationally specific goals, and well-defined and well-managed portfolio criteria and constraints.