Portfolio Build/Selection

Portfolio Selection (sometimes called Portfolio Build) is the process of selecting the Portfolio Requests that will be included in scope for execution through a series of leadership investment decisions. Leads directly to the “Portfolio Scoped” Milestone, and is refined through Continuous Investment Review.

Portfolio Build/Selection involves examining the collection of Portfolio Requests and associated Business Cases to ensure that the Portfolio accurately reflects the Business Strategic Direction. Portfolio Build/Selection can occur annually, quarterly or continuously.

Portfolio Requests are simple expressions of a business requirement related to a Business Case. Portfolio requests elaborate a specific Business Case option with an indication of required funding and technical direction for Solution Architecture within the context of Enterprise Architecture. Sometimes Portfolio Requests will be to change the Enterprise Architecture.

Business Cases and Portfolio Requests are overlapping concepts. Both are essentially arguments for funding. In some organisations these are done via the creation of a Business Case. For very large/complex investments a Business Case may cover a number of Portfolio Requests, or spawn a number of investment options. In simpler cases Portfolio Requests and Business Cases may be the same thing.

Portfolio Selection is a set of critical business decisions that provides, sustains or removes funding from pieces of work. There is a fine balance to be struck between stopping failing work early (a positive thing) and changing business priorities so often that programmes, projects and other delivery methods have no stability which inhibits their forward planning, diminishes the ability of teams to settle in to a delivery cadence and in turn reduces morale.
For this reason, we recommend Portfolio Selection is done quarterly with Continuous Investment Review happening all the time, considering critical Portfolio Requests (in response to disruption) when needed. Making Continuous Investment Review, and Portfolio Selection, transparent means that while changes in funding decisions may be disappointing, they’re never a surprise to people.
When managing very large portfolios a common practice is to commit to more delivery than the budget allows for, since the uncertainty in early planning means that spending is unlikely to follow plans. Some programmes, projects and other deliveries are unlikely to succeed and so starting more work early on gives more flexibility later in the year. This is a traditionally accepted practice which acknowledged the inherent unpredictability of software work.
In HSD we differentiate between requests which “must” be done since they are critical enablers for strategic goals, requests which “should” be done because they will support strategic goals but represent over-commitment and requests which “won’t” be done because they are prioritized below the previous two groups.

Portfolio Selection in action

A number of decisions are made during Portfolio Selection by Business Leaders, Business Customers and key organizational stakeholders. We recommend making open and transparent evidence based portfolio decisions based on understanding and comparing key information across Portfolio Requests:

  • Strategic Case
    • Does the request map clearly to Strategic Goals?
    • What Business Value will be created or sustained?
    • Is there a valid Build or Buy decision?
  • Tactical Impacts
    • Which Business As Usual systems or functions will be affected and how?
  • Political, Legal and Reputational Case
    • Is the solution impacted by regulatory or compliance requirements?
    • Are commitments to partners impacted?
  • Cost/Benefit Analysis
    • What are the projected resource needs?
    • What are the projected tangible and intangible costs and opportunities?
    • Is the Request worth doing?
  • Risk Assessment
    • Is the Request risky?
    • Does the solution introduce or mitigate organizational risks?

All of this information comes from the Portfolio Requests and associated Business Cases. We recommend prioritizing Portfolio Requests from a Strategic perspective initially, and then comparing this set of information (often in table form) to create a rough set of must, should and won’t decisions. Each Portfolio Request can then be examined in more detail to verify the initial selection decision.

Portfolio Selection is an opportunity to optimize the Portfolio, by choosing options which reinforce each other, align well in terms of dependencies, and collectively move the organization forward. New Investments will typically replace or combine previous Business As Usual solutions. These “convergence” solutions must be carefully managed to ensure that the projected savings are actually worth the cost of a new solution.

Many organisations fall into the trap of repeatedly reinventing their internal systems rather than creating new business value.

Build or Buy

As Shown above Portfolio Selection includes a review of Build or Buy decisions for both Business As Usual and New Investment Portfolio Requests.

A Build or Buy decision informs an organization if a proposed solution (normally in the form of a Portfolio Request) should be built “in house”, provided by a supplier or otherwise acquired “off the shelf”.

Organizations with significant internal development capabilities are sometimes tempted to build everything they need – not just the strategically important. This can waste expensive development capability, and intellectual capital, on building something that is readily (and often cheaply) available externally. Similarly, organizations with supply chains, especially embedded suppliers are sometimes tempted to out-source (or near-source) all of their Solutions to suppliers putting high risk requests that provide core business value in the hands of suppliers poorly equipped (in terms of knowledge, resources and contract models) to deliver them.

Several factors affect Build or Buy decisions:

  • Risk
  • Strategic Positioning
  • Cost/Benefit

Continuous Investment Review

An important part of the Governance function is “Continuous Investment Review”. Continuous Investment Review is the process of checking work progress (projects, programmes and other delivery methods) against forecast budgets and extrapolated costs to decide if the business should continue to fund a project.

This continue, change or stop decision is a chance to apply feedback to work based on actual output, spend so far and projected spend.

Benefit (ROI) = Business Value – Cost of Implementation

Waiting until the end of a piece of work to judge whether it was worth it or not places value at the end of the lifecycle. Business Value is the most important thing, so checking it regularly can prevent organizations from making significant mistakes.

One of the most valuable decisions a software business can make is to stop a failing project.
Failing projects are a learning experience for everyone involved and can happen even to the most perfect development team. Estimates are only guesses, and software development is hard, and frequently complex. Early failure is success. Late failure is to be prevented.
Although early failure should be encouraged, and even incentivized it must not be more attractive than project success otherwise the organization is tuned to perpetual failure. Incentives for delivering Business Value must out-weigh early failure incentives. The number of projects stopped early should be considered a positive measure. The amount of variance from forecasts that triggers exception reporting should be calibrated according to the organizations’ financial risk appetite. Note that project estimates are expected to vary significantly at the early stages of work until the portfolio, programme or project has been de-risked – even then some variance is normal.
Continuous Investment Review should be transparent and public. By using a common Business Value model (POFL) decision-making around stopping a piece of work, or changing its funding, or moving it in terms of the Commoditization Scale (and therefore the Hybrid Dynamic Model for ways of working and organization) becomes relatively easy.

Return on Investment (ROI) is based on a simple formula:

Return on Investment = Business Value – Cost of Implementation

Where business value is qualified in terms of the POFL tests and cost of implementation is the cost of the product (and/or maintenance agreements) as well as the internal Delivery cost of deployment and support (as well as and configuration/customization costs). HSD helps organizations determine cost of implmentation by illuminating all of the work related to a Portfolio Request.

Where business value is not defined financially (e.g. in non-commercial organizations) we end up with a simple “Business Value vs. Cost of Implementation” equation which offers a simple decision to Business Leaders: Is the benefit worth the cost? We recommend that a wide stakeholder group is used to answer that question rather than just the Business Leaders so that decisions have wide support as they are made, rather than trying to gain support afterwards, especially when those decisions relate to tools, environments or COTS selection.

Similar to relegation tables in sporting leagues we recommend transparently publishing Benefit (ROI) data, cost, forecast and current funding decisions for each piece of work. We recommend literally publishing a league table of pieces of work and their value – cost – progress. The top performers are safe, the lowest performs can be considered at risk in the “relegation zone”. When “relegation” comes, in the form of stopping or reducing funding, no one will be surprised even if the news is disappointing. This process also has the added benefit of gamifying project performance, adding a competitive pressure for teams to regularly demonstrate progress towards new/improved business value.
The following is an example Continuous Investment Review “Relegation table”. Note that this table shows the Business Value indicators and answers the Big 4 governance questions. In terms of financials, we track how much has been spent, how much more needs to be spent and so the total estimated cost. We’ve included the traditional initialisms for these in the table below but only recommend using them if you’re already familiar with them.
Using this example table (based on real information from an anonymized client) below we can make decisions regarding each investment. We include the narrative explaining the table below:
Proj 1” is a bit of work aimed at feeling good and looking good. We know it’s a marketing led piece of work that will improve our reputation with partners and make the workforce happier. It’s overspending a little but not significantly (63% budget for 60% scope) and is pretty healthy. It’s not focused on problems or opportunities but it’s something we want to do – Continue.
Big Programme” is doing some good work against solving the problem it’s aimed at, but isn’t hitting it’s “feeling good” value indicators. We may need to look into that. It’s overspending again, a bit more significantly this time, and it’s a pretty expensive project. Talking to people we know that this is because it’s a high complexity programme. It’s healthy – Continue.
Quick Hack 5” is about seizing a new opportunity. It’s cheap and cheerful and the team are doing a great job, this experiment looks like it’s working. It’s even over-delivering in terms of scope for budget but it’s so speculative we always knew scope was pretty variable. The team need to celebrate their success a bit more, and tighten up a little on their self-improvement. It’s a no-brainer – Continue.
Experiment 2” is not doing too well against its problem although it’s getting some good progress against new opportunities. It’s overspending slightly, but not significantly. Because it’s working practices aren’t looking too healthy and the progress against the problem isn’t great it’s at risk due to being relatively expensive. This might not work – At Risk.
Complex Prog 2” – This was always going to be difficult, it’s very complex. This is a big expensive programme, and it’s spent quite a lot already (20% budget – 6!), but not achieved much in terms of scope delivery (15%) and isn’t doing well at solving its problem, or new opportunity. It’s not hitting the feel good and look good elements very well either. Recent investigation shows a lot of cross-team problems, probably due to the difficulty and lack of progress. This has been a really valuable piece of work, that’s allowed us to fail fast and learn some important lessons. Thanks to everyone involved, the time has now come to sop this Prog. We’ll look to reinvent another solution to problem, ideas are welcome at the Fast Fail party – Stop.
Can you be so honest about your projects and programmes? If not, why not? Good governance is based on honesty.
During development there is sometimes a lag between early releases and meaningful business value – this situation requires business leaders to make subjective judgements and should not be avoided. Unconfirmed business value is more likely in speculative inventive work on the Commoditization scale. Leaders are empowered to make investment decisions, doing so publicly means their personal credibility will be based on their decision making incentivizing them to make good, well communicated, decisions. If your Leaders are too scared to make public investment decisions, then you have the wrong leaders.
The input to Continuous Investment Review is initially Portfolio Requests and/or Business Cases. Once pieces of work are in execution then they will need to interface to this process by providing the data on a continuous basis. We recommend a monthly report to the entire organization as above, perhaps on internal social media platforms.
Continuous Investment Review is especially important in governing Software Engineering Contracts.

In a software context a contract is a written or spoken agreement that is intended to be enforceable by law between a customer and a supplier on how a product or part of the software development process will be delivered.