"Experience, Empiricism, Excellence"
HSD is free, please donate to help support us
or

A Requirement is a condition or capability that must be met by a system or component to satisfy a contract, standard, specification, or other form of request.

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.

Collectively a set of Portfolio Requests form the "Portfolio", the collection of projects, programmes and other work considered by the business for investment and execution. This collection of Portfolio Requests is essentially a Backlog (as used in lower level requirement collections such as the Programme Backlog or Product Backlog) defined by the Portfolio Selection practice and managed by Continuous Investment Review.

A Portfolio Request articulates a request to invest in either a change to the business or sustained funding for a business function and is typically an elaboration of a Business Case option to deliver Business Value. The Return on Investment (ROI) analysis is normally made in the Business Case but can be included in a Portfolio Request if an organization chooses not to use separate Business Cases.

 

 

The Business Case represents the justification for purchase or construction of the product. The Business Case describes the problem which will be addressed and the desired outcomes of a solution including how the product will solve the problem or exploit/maximize an opportunity with cost benefits to justify spend/investment.
 
A Business Case qualifies the expected Business Value of significant investment.
 

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.

 

"Business As Usual" vs. New Investment

In many organizations the term "Business As Usual" or BAU is used to describe work that is considered necessary for the business to function, including maintenance of legacy systems, infrastructure (see Operations). We recommend qualifying the business value of these BAU items on an annual basis to ensure that continued funding is producing Business Value as part of Continuous Governance. BAU can sometimes become part of the fixed cost base of an organization which means there is less funding for creating new Business Value and research/innovation. In turn this means less profit for commercial organizations and less delivery capability for non-commercial organizations.

We recommend tracking the investment on Business As Usual vs. New Investment at a portfolio level and trying to reduce BAU spend where possible. Establishing Pull from Strategic Direction helps to ensure that BAU activities have current Business Value.

Work on existing systems should only be considered as "maintenance", and especially "Business As Usual" if it has a very low risk impact and is therefore not architecturally significant. Any significant work that needs scope elaboration, architectural effort and, tellingly, a number of Releases is not maintenance or BAU, it is New Investment on an existing Product or Product Family and will benefit from the Risk-Driven lifecycle being followed.

In line with Lean principles, new investments will take the form of changes to the business, either in terms of its external services or its internal operation. In either case Portfolio Requests are best framed in terms of their achievement of a Strategic Goal and the creation of Business Value to the end customer.

 

How to write a Portfolio Request

A Portfolio Request can be described as an interaction between a Business Customer (internal or external) that results in some Business Value or progress towards a Strategic Goal. Portfolio Requests are very high-level items, and so hide a lot of detail. The most effective form of communicating an individual request is the right one to use, rather than sticking to a template. We recommend describing portfolio requests in terms of “what” they will deliver directly linked to Business Value using the POFL model mentioned earlier.

POFL Business Value Model

<Business Customer Type> needs <a service/system from the business>

that has the following features:

  • <top feature 1>
  • <top feature 2>
  • <top feature n>

resulting in Business value by:

<solving a problem>
and/or <seize an opportunity>
and/or <feel good>
and/or <look good>



 

Other elements typical of a Portfolio Request will be high level estimates for some or all of the following:

  • A Build or Buy decision
  • Required human effort
    • Internal effort are bound by capacity
    • External effort bound by supplier relationships, availability and budget
    • Potential recruitment is normally quite slow so workforce shape is best considered as early as possible
  • Financial cost, in terms of
    • Tangible and intangible assets (physical assets such as hardware products vs. non-physical such as rights, trademarks etc.)
    • Capital vs. Investment costs (usually has a tax impact)
  • Potential Risks
    • Strategic and Tactical Business risks
    • Reputational Risks
  • Other Potential Benefits/Opportunities
    • Again in terms of tangible and intangible assets
    • In terms of "Soft Assets" (reputation, mindshare etc.)

 

Recommendations

Estimating at this level is extremely difficult, due to the number of unknowns involved before investigation work has even started. Estimates in Portfolio Requests will be significantly inaccurate and should be treated as such. Establishing tolerances for a business based on its risk appetite (and external compliance requirements for regulated or public sector organizations) enables controlled refinement of actual expenditure and risk exposure across a portfolio's lifetime and multiple decision points to validate continued funding.

To support these estimates, for new investments especially, Portfolio Requests must be grounded in architectural reality, this means that they will either be based on established Enterprise Architecture or be a proposal to change the Enterprise Architecture in line with Strategic Direction.

When risk is high, we recommend funding investigatory/experimental work (sometimes called “Spiking”) to improve understanding and mitigate risks through actually building a small part of the proposed solution. Portfolio Requests can then be refined and reconsidered as part of Continuous Investment review. This feedback loop is a more honest way of doing business than attempting estimate accuracy for speculative work at the beginning of the year.

Avoid false accuracy, implication of certainty and comparison against hypotheticals wherever possible.

Portfolio Requests are essentially arguments for funding. In some organizations 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.



 

 

Please share this page

Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TwitterSubmit to LinkedIn