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 and Service Models 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 (total cost of ownership).
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.

s2p

Figure 38: 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

• Service Architecture (data object): A data object within the S2P Value Stream managed by the Enterprise Architecture functional component. It includes service blueprints, enterprise guiding principles, and technology roadmaps.

Key Attributes

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

• ServiceID: Unique identifier of the IT service.

• ServiceComponent: Architectural components required to enable the desired IT service (e.g., application, infrastructure, etc.).

• ServiceDiagram: As-is builds of service diagram that may vary by location or service lifecycle stage.

Key Data Object Relationships

The Service Architecture data object shall maintain the following relationships:

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

Main Functions

The Enterprise Architecture functional component:

• 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.

• Shall develop IT roadmaps based on business roadmap and input.

• Shall develop and maintain enterprise guiding principles.

• Shall manage IT architecture guideline and standards.

Model

Figure 39: 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:

• PolicyID: Unique identifier; e.g., number of the Policy.

• PolicyDescription: 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 Functional Component (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.

Main Functions

The Policy functional component:

• Shall align and map IT Policies to Service Architectures.

• Shall review and approve IT policies based on roles and responsibilities. It shall manage Policy distribution and acceptance based on predefined templates and schedules for designated IT stakeholders.

• 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.

• 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.

If a Service Portfolio functional component exists, the Policy functional component:

• Shall associate one or more policies to one or more Conceptual Services.

Model

Figure 40: 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. This is the authoritative source for the list of IT proposals requested over a given time period that may result in the creation of Scope Agreements for projects.

Key Data Objects

• Scope Agreement (data object): Proposals are created from rationalized Portfolio Backlog Items and, upon approval, Scope Agreements are created. Scope Agreements reflect budget, cost/benefit projections, scope, 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:

• ScopeAgreementID: Unique identifier of the Scope Agreement.

• ScopeAgreementDescription: Details of the Scope Agreement.

• BusinessEntity: Business or geographic unit.

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 (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.

Main Functions

The Proposal functional component:

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

• Activities for Scope Agreements requiring an expedited analysis and approval:

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

— Quickly evaluate the proposal and decide on the approval. If rejected, then notify the Portfolio Demand functional component.

— Is there an existing IT Initiative that can be associated with the approved proposal? If yes, then create an updated Scope Agreement and update corresponding in-flight IT Initiative data object in the R2D Value Stream. 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.

— Create a new Scope Agreement. A new IT Initiative data object is created in the R2D Value Stream.

• Activities for proposals requiring structured analysis and approval:

— Proposals are created 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.

— Proposals are created periodically throughout the year or once a year during annual planning activities.

— Create a high-level labor consumption model for a proposal (for example, one project manager, five developers, and two QAs for the proposal). Validate labor consumption model against available internal and external labor pools.

— Create a high-level asset (non-labor) consumption model for a proposal. Validate asset consumption model against available internal and external assets (for example, traditional/private cloud/managed cloud/public cloud).

— Model ongoing labor and non-labor budget for annual and future operations.

— 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.

— Ensure proposal meets the technology policies.

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

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

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

The Proposal functional component:

• 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.

• The R2D Value Stream project portfolio is the authoritative source for the list of IT deliverables or services that will be rendered during a project lifecycle. The project portfolio views can be created 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. The project portfolio entries are actuated through a Project Management system. The project portfolio reports 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 41: 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:

• DemandID: Unique identifier of the Portfolio Backlog Item (demand request).

• DemandDescription: Description/details of the Portfolio Backlog Item (demand request).

• Source: Where did the demand originate from (e.g., person/department)?

• ITServiceID: Is demand related to a live service (e.g., enhancement requests)?

• DemandFulfillmentStatus: 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.

Main Functions

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.

If a Proposal functional component exists, then the Portfolio Demand functional component:

• Shall categorize and group the demands and push demands to the Proposal functional component.

If a Requirement functional component exists, the Portfolio Demand functional component:

• Shall associate one or more Requirements (user stories, use-cases, business rules, etc.) to a Portfolio Backlog Item.

The Portfolio Demand functional component may support backlog item data object backlog ranking, trending, and analysis based on requested services, timeline, business unit origination, etc.

Model

Figure 42: 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. 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 Service Model is an authoritative source for the list of services that the enterprise consumes. It represents services planned, in transition, in production, or retired.

• Conceptual Service Blueprint (data object): The Conceptual Service Blueprint contains the list of all service blueprints associated with a given Conceptual Service. (Each Conceptual Service Blueprint has a comprehensive view of the service that depicts endpoints and interfaces that can be understood by Architects and BRMs).

Key Attributes

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

• ServiceID: Unique identifier of the Conceptual Service.

• ConceptualServiceDetails: Details of the Conceptual Service.

• ServiceOwner: Owner of the Conceptual Service.

• ServiceStatus: Status; e.g., planned, retired, etc.

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

• ConceptualServiceBlueprintID: Unique identifier of the Conceptual Service Blueprint.

• ConceptualServiceBlueprint: Details of the Conceptual Service Blueprint.

• ServiceID: Unique identifier of the Conceptual Service to which Blueprint is associated.

Key Data Object Relationships

The Conceptual Service data object shall maintain the following relationships:

• Service 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 (n:m): Budget for one Conceptual Service may be spread across multiple budget items and one budget item could hold budget for multiple Conceptual Services.

• 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.

Main Functions

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 service budgets/actuals information.

• Shall create and maintain service blueprints and endpoints. 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.

If a Portfolio Backlog Item exists, the Service Portfolio functional component:

• Shall associate a Conceptual Service to one or more Portfolio Backlog Items.

If a Policy exists, the Service Portfolio functional component:

• Should comply with one or more applicable Policies.

Model

Figure 43: Service Portfolio Functional Component Level 2 Model

5.4.6 IT Investment Portfolio Auxiliary Functional Component

Purpose

This functional component is auxiliary to the S2P Value Stream and is primary in the IT Financial Management guidance document.

Its main purpose includes:

• Manage the authoritative list of all IT investments.

• Facilitate all activities required to effectively carry out forecasting and budgeting.

• Facilitate proposal managers with guidelines and information (e.g., unit costs) to be followed while estimating costs of proposed IT Initiatives.

• Establish a common governance and control mechanism for approval/rejections of any proposed IT Initiatives.

Key Data Objects

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

Key Attributes

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

• FinancialPeriod : Period expressed in MM-YYYY.

• ServiceID: Unique identifier of IT service.

• ScopeAgreementID: Unique identifier of the Scope Agreement.

• BudgetType : CapEx or OpEx.

• RequestedBudget: Budget that was originally requested.

• ApprovedBudget: Budget that was approved.

• Spend: Actual spend that was accounted.

Key Data Object Relationships

The IT Budget data object shall maintain the following relationships:

• IT Budget to Conceptual Service (n:m): This relationship helps track how much IT Budget is allocated to which IT service(s).

• IT Budget to Scope Agreement (1:n): This relationship helps track how much IT Budget is allocated to which Scope Agreement(s).

Main Functions

The IT Investment Portfolio functional component:

• Shall be the system of records for all IT investments.

• Shall manage the entire IT investment lifecycle.

• Shall provide labor & non-labor cost estimates and other guidelines to the Proposal functional component. This should be used by proposal managers to estimate the cost of proposed IT Initiatives.

Various proposal managers working on their respective proposals should send the information on proposed IT investments to the IT Investment Portfolio functional component.

• Shall accept inputs from the Service Portfolio functional component to include OpEx budget requests for keeping live services operational.

• Shall take these proposals/budget requests for necessary approvals with the respective governing committee.

• Shall communicate the status of the final investment decisions back to the respective stakeholders.

Model

Figure 44: IT Investment Portfolio Auxiliary Functional Component Level 2 Model