5 Strategy to Portfolio (S2P) Value Stream

This chapter provides an overview of the Strategy to Portfolio (S2P) Value Stream – one of four IT Value Streams that comprise the IT Value Chain. It describes the business context, objectives, and details behind the S2P Value Stream.

5.1 Objectives

The S2P Value Stream allows IT to contribute to business strategy and planning enabling IT alignment with business plans. Traditional IT planning and portfolio activities put emphasis on evaluation, approval, and delivery tracking of project proposals. Discussion with business often becomes minimizing costs for IT initiatives or assets rather than the value of services provided to business from IT. The goal of the S2P Value Stream is to create an IT portfolio framework that allows IT organizations to optimize services provided to business by bringing together multiple functional areas. For example, traditional project proposal or investment Portfolio Management driven by an IT PMO needs to work in conjunction with Service (or Application) Portfolio Management driven by Enterprise Architects or Service Portfolio Managers.

The S2P Value Stream aims to provide holistic views of IT portfolio activities through data integrations within multiple areas of the IT portfolio. These views provide better understanding of the inter-relationships among IT's many sub-domains, including the IT PMO, Enterprise Architecture, Application Management, IT Operations Management, and Information Security Management. Today's IT needs accurate and point-in-time information to understand the inter-relationships and inter-dependencies required to truly orchestrate all the moving parts of IT in ways that can help the IT department support business objectives and goals.

Most IT organizations already have IT portfolio processes and solutions in place, but suffer from the following limitations:

Poor data consistency and quality
No holistic IT portfolio view across the IT PMO and the Enterprise Architecture and Service Portfolio functional components
Inconsistent Service and IT Portfolio Management processes
Poor tracking and correlation of service lifecycle across conceptual, logical, and physical domains

The S2P Value Stream provides a blueprint for optimizing service and investment IT Portfolio Management. The end-to-end IT portfolio view provided by the S2P Value Stream raises the visibility of key data objects often overlooked during IT portfolio planning activities. Defining key data objects and relationships between data objects is easier with a proper framework.

5.2 Business Value Proposition

The S2P Value Stream enables IT organizations with the proper framework for interconnecting different functions supporting IT Portfolio Management. Functions such as the Portfolio Demand, Enterprise Architecture, Service Portfolio, and Proposal functional components need data consistency and proper data object hand-offs in order to optimize the organization’s IT Portfolio Management.

The key value propositions for adopting the S2P Value Stream are:

Holistic IT portfolio view across the IT PMO and the Enterprise Architecture and Service Portfolio functional components
IT portfolio decisions based on business priorities
Accurate visibility of business and IT demand
IT portfolio data consistency
Service lifecycle tracking through conceptual, logical, and physical domains
Prioritized IT investment based on all IT portfolio facets including cost/value analysis, impacts on architecture, service roadmap, business priorities, etc.
Re-balance IT investments between strategic and operational demand
Solid communication with business stakeholders through roadmaps

5.3 Key Performance Indicators

The S2P Value Stream critical success factors and Key Performance Indicators (KPIs) are as follows:

Critical Success Factors	Key Performance Indicators (KPIs)
Business and IT Alignment	Ratio of new versus maintenance service.
Accurate Visibility into Overall Demands from Business	Demand requests, types, and delivery per service % of overall IT budget that can be traced to formalized demand requests. Structured and rationalized Demand Management with ongoing efforts to minimize the number of demand queues that staff must respond to.
Service Portfolio Rationalization	A formal Service Portfolio functional component process exists under the ownership of the Service Portfolio Management process owner. Taxonomies for understanding functional and technical redundancy and business value of the IT service are implemented. Processes for consistently evaluating and tagging portfolio entries are implemented. Service portfolio is subject to ongoing rationalization using the taxonomies, implemented as continuous improvement. Service and IT Portfolio Management are themselves rationalized with clear scoping and relationship established.
Service Portfolio Financial Analysis	Accounting records are produced on a regular basis to show the ongoing “investment & spend” in each service/application. These are compared with business outcomes and financial objectives that have been achieved.
Service Portfolio Reporting and Analysis	A service portfolio exists and is used as the basis for deciding which services to offer.
Service Investment Tracking	The investment in each service is quantified in the service portfolio. Investment in each service is reported, starting with the initial investment, and followed by monthly, quarterly, or annual reporting of the ongoing budget spend (TCO).
Improve Customer Satisfaction	Satisfied customers per service/application.
Stewardship of IT Investment	CapEx versus OpEx. Software license percentage in use. Planned versus actual service costs. Average cost of IT delivery (per service/application) per customer.
Enterprise Security Alignment	Frequency of security assessments against latest standards and guidelines. Noted deficiencies against security standards and policies.

5.4 Value Stream Definition

The Strategy to Portfolio (S2P) Value Stream contains both key and auxiliary functional components. Key functional components are the core and drive key activities within a value stream. Auxiliary functional components are not dedicated to a single value stream and provide relevant data objects to key functional components. The S2P Value Stream includes the following key functional components that provide the technology necessary to support IT portfolio activities:

Enterprise Architecture
Policy
Proposal
Portfolio Demand
Service Portfolio

A functional component utilizes an input data object to conduct key activities and may also provide output data objects to another functional component that requires that data.

The S2P Value Stream functional components are often owned and managed by different IT groups. For example, Enterprise Architects’ primary tools and solutions are different than IT PMOs’, but they must work together to optimize IT Portfolio Management. The S2P Value Stream provides a framework that ensures functional components used by IT groups can work together efficiently, through well-defined control points and data objects, to govern and model IT Portfolio Management.

Figure 39: Strategy to Portfolio Level 2 Value Stream Diagram

5.4.1 Enterprise Architecture Functional Component

Purpose

Create and manage long-term IT investment and execution plan-of-action that are critical to business strategic objectives.

Key Data Objects

Enterprise Architecture (data object): A data object within the S2P Value Stream managed by the Enterprise Architecture functional component. It includes references to collateral in the target state architecture landscape representing planned and deployed IT services.

Key Attributes

The Enterprise Architecture data object shall have the following key data attributes:

Id: Unique identifier of the service.
Component: Architectural building blocks required to enable the desired service (e.g., application, technology, etc.).
Diagram: As-is business, data, application, and technology domain architectures from the viewpoint of IT service owners.

Key Data Object Relationships

The Enterprise Architecture data object shall maintain the following relationships:

Enterprise Architecture to Conceptual Service (n:m): This relationship helps track which service components and service diagrams are allocated to which service(s).

Functional Criteria

The Enterprise Architecture functional component:

Shall create and manage long-term IT investment and execution plan-of-action.
Shall identify strategic IT architectural components based on current business vision, strategy, goals, and requirements.
Shall develop target state business, information, application, technology, and security blueprints based on strategies, principles, and policies.

Model

Figure 40: Enterprise Architecture Functional Component Level 2 Model

5.4.2 Policy Functional Component

Purpose

Manage creation, review, approval, and audit of all IT policies.

Key Data Objects

Policy (data object): It is a central repository for storing and organizing all types of IT policies based on various templates and classification criteria.

Key Attributes

The Policy data object shall have the following key data attributes:

Id: Unique identifier; e.g., number of the Policy.
Description: Description/details of the Policy.
ApplicableGeography: Which geographies does the Policy apply to; e.g., certain policies could be country-specific or may have country-specific customizations.

Key Data Object Relationships

The Policy data object shall maintain the following relationships:

Policy to Conceptual Service (n:m): Multiple policies might be applicable for a single service or a single policy may be applicable for multiple services.
Policy to Requirement (n:m): Requirements may be sourced from policies or may reference policies in order to remain in compliance with previously agreed policies for an organization.

Functional Criteria

The Policy functional component:

Shall align and map IT Policies to Enterprise Architectures.
Shall enable review and approval of IT policies based on roles and responsibilities. It shall manage Policy distribution and acceptance based on predefined templates and schedules for designated IT stakeholders.
Shall provide visibility into IT Policy attributes such as types, status, non-compliance, audit history, and issues.
Shall manage overall IT governance Policies, and Policies applied to or associated with the particular services that may be managed downstream during service design.
Shall manage IT security and regulatory Policies by incorporating external and internal security and regulatory compliances.
Shall define pricing/costing Policies and capture information related to Service Contracts.
Should maintain complete Policy revision history, and review period or obsolescence rules set for all Policies.
May log and track IT Policy exceptions through an issue management mechanism. It may provide a consistent tracking feature for exception identification, evaluation, and status report leading to corrective action.

Data Architecture Criteria

The Policy functional component:

Shall associate one or more policies to one or more Conceptual Services if a Service Portfolio functional component exists.

Model

Figure 41: Policy Functional Component Level 2 Model

5.4.3 Proposal Functional Component

Purpose

Manage the portfolio of IT proposals that are proposed, approved, active, deferred, or rejected. The Scope Agreement is the authoritative source for the list of all IT proposals requested over a given time period.

Key Data Objects

Scope Agreement (data object): Proposals are created from rationalized Portfolio Backlog Items. Scope Agreements reflect budget, cost/benefit projections, scope, status, and other key attributes of proposed work. Views can be created for specific functions, such as line of business, or holistically, such as company-wide. Used for building the IT investment plan of record for the company or a specific line of business or function.

Key Attributes

The Scope Agreement data object shall have the following key data attributes:

Id: Unique identifier of the Scope Agreement.
Description: Details of the Scope Agreement.
BusinessEntity: Business or geographic unit.
ProposedBudget: Requested budget of the Scope Agreement.
ApprovedBudget: Approved budget of the Scope Agreement.
Status: Scope Agreement status (e.g., proposed, approved, rejected).

Key Data Object Relationships

The Scope Agreement data object shall maintain the following relationships:

Scope Agreement to Portfolio Backlog Item (n:m): One Scope Agreement can be associated to one or more demand data objects.
Scope Agreement to IT Budget Item (n:1): This relationship helps track budget allocated to which Scope Agreement.
Scope Agreement to IT Initiative (1:n): This relationship helps track IT Initiative(s) to which Scope Agreement.

Functional Criteria

The Proposal functional component:

Shall create a Scope Agreement from rationalized Portfolio Backlog Items in the data object repository.
A Scope Agreement may follow an expedited analysis and approval for high priority urgent items or agile development proposals.
A Scope Agreement may follow a structured analysis and approval via IT annual planning activities.
A Scope Agreement following an expedited analysis and approval:

— Shall create a proposal from a rationalized backlog item where the item requires high urgency due to business impact on an existing service.

— Shall allow quick evaluation of the proposal and a decision on its approval. If rejected, then notify the Portfolio Demand functional component.

— Shall create an updated Scope Agreement and update the corresponding in-flight IT Initiative data object in the R2D Value Stream for all activities associated with a newly approved proposal. (In the context of the IT4IT Reference Architecture, an IT Initiative is any one of the class of temporary endeavors such as projects or programs with a defined beginning and end, undertaken to achieve an objective or outcome, at a specified cost.)

— Shall create a new IT Initiative data object.

Scope Agreements following a structured analysis and approval:

— Shall create proposals from rationalized Portfolio Backlog Items in the Portfolio Backlog Item data object repository. Rationalized items are grouped based on priority and themes for a proposal creation purpose. Not all rationalized items will be grouped within proposals as priority and cut-off must be decided.

— May periodically produce proposals throughout the year or once per planning period.

— Shall create a high-level labor consumption model for a proposal (for example, one project manager, five developers, and two QAs for the proposal) based on labor estimates. If a Resource Management offer exists, then the Proposal functional component shall receive the resource price from the mentioned offer. Validate the labor consumption model against available internal and external labor pools.

— Shall create a high-level asset (non-labor) consumption model for a proposal based on asset estimates. If an Asset Management offer exists, then the Proposal functional component shall receive the asset price from the mentioned offer.

— Should validate the asset consumption model against available internal and external assets (for example, traditional/private cloud/managed cloud/public cloud).

— Should model the ongoing labor and non-labor budget for annual and future operations.

— Shall define tangible and intangible benefits for each proposal. Tangible benefit may be cost savings or revenue growth, whereas intangible benefit may be strategic initiative support, competitive advantage, or compliance achieved. Work with a finance organization to validate tangible benefits. This can involve utilizing industry-specific methods of measuring the value of business processes and estimating the impact of the proposal on performance metrics.

— Shall ensure proposal meets the technology policies.

— Should rank proposals based on benefits and risks, labor and non-labor consumption models, and ROI or other defined evaluation criteria.

— May build proposal portfolio scenarios using proposals, conduct “what if” analysis on the proposal scenarios, and approve the optimal proposal scenario and its proposals.

— Shall send proposed IT investments to the IT Investment Portfolio functional component for scoping and investment decisions.

— Shall update Scope Agreement(s) to compare approved baseline and actual resulting benefits derived from completing the IT Initiatives.

Shall review the Scope Agreement change request from the R2D Value Stream. The IT Initiative team working to deliver on the approved Scope Agreement may ask for change requests related to budget, resource, or timeline. Evaluate the change request and take action to update the existing Scope Agreement.
Shall consider the R2D Value Stream project portfolio as the authoritative source for the list of IT deliverables or services that will be rendered during a project lifecycle.
May create project portfolio views for specific organizations like line of business portfolio or functions like financial views. The project portfolio is used for rationalizing and tracking resources across projects to best deliver on all projects.
Should actuate the project portfolio entries through a Project Management system.
The project portfolio shall report back to the investment portfolio in order to accurately track progress and outcomes for a given Scope Agreement.
Shall identify security controls necessary for protecting the various classifications of data.

Model

Figure 42: Proposal Functional Component Level 2 Model

5.4.4 Portfolio Demand Functional Component

Purpose

Log, maintain, and evaluate all demands (new service, enhancements, defects) coming into IT through a single funnel. Correlate incoming demand to similar existing demand or create new demand. The “single funnel” may be a virtual concept encompassing project ideation, service request management, incident management, continuous improvement, and other well-known demand channels.

Key Data Objects

Portfolio Backlog Item (data object): Portfolio Backlog Items represent the repository of all incoming demands including but not limited to new requests, enhancement requests, and defect fix requests.

Key Attributes

The Portfolio Backlog Item data object shall have the following key data attributes:

Id: Unique identifier of the Portfolio Backlog Item (demand request).
Description: Description/details of the Portfolio Backlog Item (demand request).
Source: Where did the demand originate from (e.g., person/department)?
ScopeAgreementId: Unique identifier of the related Scope Agreement.
EstimatedBudget: May store budget (as estimated during creation of the Scope Agreement) of the Portfolio Backlog Item.
ExpectedCompletionDate: May store expected completion date (as estimated during creation of the Scope Agreement) of the Portfolio Backlog Item.
ITServiceId: The conceptual service ID. Is demand related to a live service (e.g., enhancement requests)?
FulfillmentStatus: Status information.
DecisionMaker: Information on who took the decisions related to the demand.

Key Data Object Relationships

The Portfolio Backlog Item data object shall maintain the following relationships:

Portfolio Backlog Item to Conceptual Service (n:1): One Conceptual Service may be related to one or more Portfolio Backlog Items.
Portfolio Backlog Item to Requirement (1:n): A Portfolio Backlog Item is mapped to one or more Requirements which will need to be delivered to successfully fulfill the demand.
Portfolio Backlog Item to Scope Agreement (n:1): One or more Portfolio Backlog Items may be included in a Scope Agreement.

Functional Criteria

The Portfolio Demand functional component:

Shall capture Portfolio Backlog Items from business.
Shall capture Portfolio Backlog Items from Problem Management activities.
Shall capture Portfolio Backlog Items from the Service Portfolio functional component activities.
May capture Portfolio Backlog Items for defect fix requests which exceed the operations budget or require high urgency due to business impact on existing service.
May support backlog item data object backlog ranking, trending, and analysis based on requested services, timeline, business unit origination, etc.
Shall categorize and group the demands and push demands to the Proposal functional component if a Proposal functional component exists.
Shall receive scoping and investment decisions from the Proposal functional component if a Proposal functional component exists.
Shall associate one or more Requirements (user stories, use-cases, business rules, etc.) to a Portfolio Backlog Item if a Requirement functional component exists.

Model

Figure 43: Portfolio Demand Functional Component Level 2 Model

5.4.5 Service Portfolio Functional Component

Purpose

Manage the portfolio of services in plan, transition, production, and retirement. The authoritative source for the list of services that IT delivers, has delivered in the past, or brokers to itself and business. Any IT service within the Service Portfolio functional component often corresponds to one or more entries in the Offer Catalog.

Key Data Objects

Conceptual Service (data object): The Conceptual Service represents the business perspective of the service and is the service interaction or the business capability of the service. It is the level suitable for discussing aspects that characterize the service as the product of IT activity including business value, investment history and outlook, value earned, and return on investment. It is abstracted from any technical detail and described in terms that are understood by CxO-level persons who decide on the assignment of budget and resources in order to build and maintain the service.

Auxiliary Data Objects

Conceptual Service Blueprint (data object): The conceptual service model contains the various delivery options for a given Conceptual Service. (Each conceptual service model has a comprehensive view of the touchpoints of the multiple systems.)

A service blueprint is a set of service endpoints that support business processes. A service blueprint provides service process and delivery visualization from the customer’s point of view. A service blueprint also maintains traceability of Logical and Physical (realized) Service Models.

Key Attributes

The Conceptual Service data object shall have the following key data attributes:

Id: Unique identifier of the Conceptual Service.
Details: Details of the Conceptual Service.
Owner: Owner of the Conceptual Service.
Status: Status of the Conceptual Service; e.g., planned, retired, etc.
BusinessUnit/Portfolio: The business unit or portfolio to which the service belongs.
BudgetedSpend: Approved budget for service development and maintenance.
TCO: Total cost of ownership of a Conceptual Service (includes development, run, enhancement, and overhead charges for a service).
Recovery: Return on investment against the Conceptual Service.

The Conceptual Service Blueprint data object shall have the following key data attributes:

Id: Unique identifier of the Conceptual Service Blueprint.
Details: Details of the Conceptual Service Blueprint.
ConceptualServiceId: Unique identifier of the Conceptual Service to which the Blueprint is associated.

Key Data Object Relationships

The Conceptual Service data object shall maintain the following relationships:

Conceptual Service to Logical Service (1:n): Traceability is maintained between one Conceptual Service and one or more Logical Services.
Enterprise Architecture to Conceptual Service (n:m): Traceability is maintained between one or more Conceptual Services and the Enterprise Architecture drawings, diagrams, and other documents that describe those services.
Conceptual Service to Portfolio Backlog Item (1:n): One Conceptual Service may be related to one or more Portfolio Backlog Items.
Conceptual Service to IT Budget Item (1:n): Budget for one Conceptual Service may be spread across multiple budget items and one budget item should hold budget for a single Conceptual Service.
Conceptual Service to Policy (n:m): Multiple Policies might be applicable for a single service or a single Policy may be applicable for multiple services.

The Conceptual Service Blueprint data object shall maintain the following relationships:

Conceptual Service to Conceptual Service Blueprint (1:n): One Conceptual Service may have multiple Conceptual Service Blueprints.
IT Cost Model to Conceptual Service Blueprint (1:n): One IT cost model (rule engine) can be applicable for multiple Conceptual Service Blueprints.
Conceptual Service Blueprint to Logical Service Blueprint (1:n): One Conceptual Service Blueprint could have one or more Logical Service Blueprints.

Functional Criteria

The Service Portfolio functional component:

Shall assess the effectiveness and efficiency of current services delivered to business.
Shall manage all inventory information about services or applications; including business benefits, risk, quality, fit to purpose, etc.
Shall compare similar services or applications to identify rationalization opportunities.
Shall evaluate the portfolio with regard to value/cost performance and risk/criticality. These methods are used to maximize portfolio value, align and prioritize resource allocations, and balance supply and demand.
Shall review proposed portfolio changes; decide whether to keep, retire, or modernize services or applications.
Shall create, review, and update service roadmaps.
Shall determine and track the TCO of a service and associated return on investment.
Shall determine and track operations spend.
Shall create and maintain service blueprints and endpoints.
Should comply with one or more applicable Policies if a Policy exists.
Shall receive the subscribed service charge from the Chargeback/Showback functional component if a Chargeback/Showback functional component exists.
May send the operation charge acceptance to the Chargeback/Showback functional component if a Chargeback/Showback functional component exists.

Data Architecture Criteria

The Service Portfolio functional component:

Shall associate a Conceptual Service to one or more Portfolio Backlog Items if a Portfolio Backlog Item exists.

Model

Figure 44: Service Portfolio Functional Component Level 2 Model

5.4.6 IT Investment Portfolio – Auxiliary Functional Component

Purpose

Auxiliary to the S2P Value Stream and primary in the IT Financial Management guidance document. Its main purpose is to manage the portfolio of all authorized IT investments.

Key Data Objects

IT Budget Item (data object):IT Budget Item is an authoritative list of approved IT investment pertaining to a service. This set of records will help to identify approved budget over different time periods; e.g., by financial year, by Conceptual Service.

Key Attributes

The IT Budget Item data object shall have the following key data attributes:

FinancialPeriod: Financial period for which the IT Budget Item is recorded.
InvestmentId: Unique identifier of the service or investment (e.g., overhead) for which the IT Budget Item is recorded.
InvestmentType: Nature of investment (e.g., run, development, overhead).
ApprovedBudget: Approved budget.
Spend: Actual spend.

Key Data Object Relationships

The IT Budget Item data object shall maintain the following relationships:

IT Budget Item to Conceptual Service (n:1): One IT Budget Item shall hold budget for a single Conceptual Service and budget for one Conceptual Service may be spread across multiple IT Budget Items.
IT Budget Item to Scope Agreement (1:n): This relationship helps track how much IT budget is allocated to which Scope Agreement(s).

Functional Criteria

The IT Investment Portfolio functional component:

Shall be the authoritative source for all IT investments requested over a given time period.
Shall manage the entire IT investment lifecycle.
Shall receive proposed IT investments for development from the Proposal functional component.
May receive proposed IT investments for run and maintain and non-service investments from investment owners.
Shall assess proposal feasibility for cost, value, etc. and obtain required approval from finance.
Shall communicate the status of the final scoping and investment decisions back to the respective stakeholders.

Model

Figure 45: IT Investment Portfolio – Auxiliary Functional Component Level 2 Model