Note: I use the term Enterprise IT to include traditional Enterprise IT and the Digital. Product and Engineering departments where they exist outside IT.
One of the key functions of Project Portfolio Management (PPM) in IT is that of allocating finite funds to a subset of projects that vie for funding. When it works well, PPM becomes an effective agent of capital allocation within enterprise IT by funding promising projects and terminating underperforming ones. In principle at least, this is not very different to how a venture capitalist might manage their portfolio by investing in promising ventures and freezing funding or writing off investments in ventures that don’t show promise. In practice, it generally works somewhat differently.
Reforming PPM in Traditional Enterprise IT
How do IT portfolio managers know if a project X deserves to be funded over project Y? Traditionally, they have relied on the projections made in project business cases. Those that promise the greatest benefit (or threaten the gravest consequences of not being funded) usually win after a round of scrutiny. Of course, every once in a while, a project is automatically deemed eligible for funding because someone powerful thinks so.How often are these funding decisions made? At the highest level, they are usually made once a year along with the budgeting cycle. Or they are made as and when projects come up for approval. Additionally, top-up funding decisions are made when a project runs of funds earlier than planned. However, unlike the case of venture-capital, funding decisions in enterprise IT are rarely made on the basis of actual performance of projects. Instead, they are either based on projected benefits (at the start) or based on progress of scope-delivery (in the middle). Thus, even after the first round, funding isn’t based on how well projects are delivering the benefits promised in the project business case. By and large, traditional enterprise IT has been more worried about delivering to plan and less about validating benefits.
Deliver Benefits, Not Scope
As long as the IT development organization is seen as a delivery organization, the responsibility of defining what to deliver rests solely with the business or with the product management organization. This separation of solution-definition from delivery hurts the cause of true iterative development and undermines the ability to tweak or steer the product based on learnings from development and production. As a result, we have the situation depicted below. Features often miss the mark and business/product responds by coming up with more hopeful ideas. In turn, this bloats the project portfolio and budget requirements.
In this scheme of things, IT can’t help but resign itself to attempting to deliver scope on plan. We can talk about benefits validation only when we move to a mode where IT solves problems jointly with business/product rather than just deliver scope. Benefits are realized when problems are verifiably solved.
However, the transition from delivering scope to solving problems requires structural change. Typically, IT program and project management organizations worry about delivering scope on plan while product management (or business) worries about solving problems. These two competencies need to work closer together for the transition to happen. Similar to the merger of development and operations advocated by DevOps we need a merger of product and delivery/engineering (ProDel/ProEngg?). Once we have cross-functional teams consisting of empowered product and delivery people, we can turn our attention to the question of how to validate benefits now that we are set up to deliver benefits.
How to Validate Benefits
Nothing validates benefits like sales, one may assert. However, not everything we build is market-facing. Even market-facing products may have back-end projects. Besides, sales is also a function of marketing effectiveness, market conditions, competitors etc. and so it can be misleading to rely exclusively on it. But perhaps the biggest drawback of having to rely on sales feedback is that it is often too late in the day. Iterative product development calls for benefits validation prior to the product/enhancement being generally available for sale.
On the other hand, usage analytics provide a better and generic way of measuring the increase or decrease in uptake after each release. Each release has to be as small as possible in order to get close to the conditions required for a controlled experiment. Frequent, small releases are only possible with Continuous Delivery and so it becomes a prerequisite for institutionalizing the habit of benefits validation.
Analytics are needed to validate benefits whether the product is internal or market-facing. They need to be factored into development efforts just like how performance and other operational requirements are taken into consideration. Most enterprise IT is lacking in this regard and it may take a while to institutionalize analytics. In the meantime, user surveys may serve as a stop-gap technique of data-driven, benefits validation.
On the other hand, we could use alignment maps as a qualitative mechanism for validating benefits. Please check the linked article for details.
Avoid Single-Stage Funding
Benefits validation is meant to inform subsequent rounds of funding. If benefits aren’t accruing as expected, it may be better to cut losses and divert funds to other projects. However, business cases are sometimes funded at one go. Even if execution is planned as a number of releases, the funds for all releases (meant to realize a business case) is sanctioned at one go. Thus, single-stage funding fails to take advantage of benefits validation.
Single-stage funding is sometimes a side-effect of a tedious approval process. Business cases are commonly written to secure 100% funding at one go to avoid cycling through the approval process multiple times. Why are approval processes so tedious? Perhaps because of big project failures in the past or because of the conviction that a strong approval process would increase the chance of success. It has the makings of a vicious cycle.
Portfolio Management in Product-Centric IT
The discussion so far has focused on how benefits validation can drive portfolio management in traditional enterprise IT. It called for some changes:- Bring product and delivery people to work closer together so as to deliver benefits rather than just deliver scope.
- Institutionalize the use of production analytics to obtain data for benefits validation.
- Adopt Continuous Delivery to be able to make frequent, small releases that allow for granular benefits validation.
- Avoid single-stage funding. While these changes allow benefits validation-based portfolio management, they don’t reform the basic project-centric execution model of traditional enterprise IT.
Highlights of Product-Centric IT
In addition to the above changes, product-centric IT differs from project-centric IT in the following ways:
- We maintain stable teams aligned along business capabilities—no ramp up and down based on projects. These teams own a set of related applications/APIs/services and are responsible for the complete lifecycle (iterative think-it, build-it & run-it). This may require a greater headcount than project-centric IT where we only have teams attending to the most important items in the portfolio backlog. Nevertheless, this increase is more than compensated by increase in team knowledge, responsiveness and effectiveness. Long term custody of a small set of systems also results in lower architectural debt as compared to project-centric mode.
- Each business capability area is headed by a capability owner who has a team of product owners each heading a 10 to 15 member product team. For example, an e-commerce platform may include capabilities such as buying and merchandizing, catalogue, marketing, customer service, order management, and fulfillment. An insurance business has capabilities such as policy administration, claims administration, and new business. A telecom business has capabilities such as network management, service provisioning and assurance, billing, and revenue management. Each capability area is too big to be served by a single team and is therefore organized as a set of sub-capabilities headed by product owners.
- Funding for teams rather than projects. More funds allow for bigger teams (or multiple small teams) in a given area of business capability. Funding is changed during annual budgeting cycle based on strategic needs.
- Funding is against objectives rather than plans. Capability owners and product owners are accountable for the objectives and have the autonomy to use the funds to prioritize different items on their roadmaps at their discretion. These aspects of product-centric IT effectively turn the funding part of portfolio management on its head. For the most part, there is no portfolio of projects in product-centric IT. Instead, there is a portfolio of business-aligned capabilities and each such capability is funded once a year in terms of a team capacity budget. The next level of fund allocation is within a capability and is delegated to empowered (and accountable) capability owners and product owners. You don’t need a separate portfolio management function unless we wish to rejig allocations in the middle of the year or fund new capabilities. This degree of churn is only warranted in the experimental portion of an organization’s portfolio. This is the part that benefits from Lean Startup techniques of rapid experimentation and pivoting.
Portfolio Management Across Three Horizons
The three horizons framework offers a way of classifying an organization’s portfolio as stable (H1), emerging (H2) or experimental (H3). Note that this classification is orthogonal to the notions of strategic and business-as-usual (BAU). In most big businesses (even those that are alerted to the prospect of being disrupted), the experimental part of the portfolio is rarely more than 20% of the pie. This third horizon, being experimental, could do with a separate portfolio management function as the business will want to make more smaller, more frequent, and sometimes opportunistic bets.The lion’s share of the pie (H1 and H2), on the other hand, when recast as product-centric IT, simply absorbs portfolio management into autonomous line functions (capability owner, product owner). Here is where rubber meets the road when we speak of arriving at an operating model that allows for autonomy, mastery and purpose on the one hand while balancing for accountability and alignment on the other. In the absence of a separate portfolio management office, capability and product owners have the autonomy to use funds to meet the objectives they are accountable for.
Note that funding controls are still in place. Annual team capacity decisions are strategic allocations made by senior leadership. Capability and product owners have to demonstrate progress (every month or quarter) towards the objectives for which they have been provided with a team. However, since the objectives are now business aligned (rather than being of the nature of delivery to plan), they can be tracked directly by line managers. Traditionally, we have only tracked delivery and so it was okay to have a staff function like portfolio management office look after it.
Not having a separate portfolio management office for H1 and H2 portfolios also makes sense from the point of view of maximizing business-aligned, outcome-oriented teams and minimizing function-aligned, activity-oriented teams. Product-centric IT represents a scaled, outcome-oriented configuration whereas portfolio management is an activity. A separate portfolio management office is a shared service just like how a separate testing team or a separate deployment team is a shared service. Shared services are prone to local optimization and therefore best kept to a minimum.
Conclusion
As described above, the habit of benefits validation based portfolio management can be introduced into traditional, project-centric IT. Product-centric IT provides further opportunities to seamlessly embed portfolio management into line management. Institutionalizing benefits validation reforms the funding function of project portfolio management in traditional project-centric IT whereas the move to product-centric IT disrupts (to good effect) the function altogether.Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
