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 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:
- Strategic Positioning
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.
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.
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.