The ITM's Solution Portfolio Approach seeks to organize the applications and technologies IT enables for business operations into standardized objects. Accordingly, those objects are individual Solutions. Undoubtedly, by standardizing many of their characteristics, the ITM allows those working with Solutions to work faster, communicate better, and deliver more value for less cost.
In effect, any set of Solutions fits the definition of a Portfolio. At the small end of the scale, a Portfolio may involve just a single Solution within an initiative. At the large end of the scale, a Portfolio may involve all applications and technologies IT supports. Of course, there is plenty of room between these two. In most cases, Portfolio Management helps any initiative which involves two or more Solutions.
The ITM's Solution Approach provides guidance for the definition and delivery of any individual Solution. Conversely, the ITM's Portfolio Approach provides additional guidance and tasks for the definition, delivery, and orchestration of all Solutions within a Solution Portfolio.
Leveraging Solution Management for Portfolio Management
The ITM's Portfolio Approach does not care how many Solutions are in a portfolio. In fact, it operates the same regardless of portfolio size. Basically, it does so by applying a systematic, and pragmatic, approach to dealing with all Customer Requests for Change. For instance, from small requests to large ones, the approach can route change to existing Solutions, or identify and define new ones. Above all, the Portfolio Approach guides consumers away from overwhelming complexity, and towards smaller, more manageable Solutions.
If an organization, or even an individual initiative, does not have an existing Portfolio Approach, then the ITM offers one for use. Accordingly, the ITM's Portfolio Approach borrows many aspects from Iterative Solution Planning and Iterative Solution Implementation. In effect, borrowed objects and tasks are repackaged, and tailored, to provide Portfolio Management processes. The tables below provide a direct comparison between the Portfolio Approach and the Solution Approach.
Reduce, Reuse, Recycle
Whereas Solutions have a top-down deconstruction, this does not apply to Customer Requests for Change. For instance, an individual request can be relatively small. Alternatively, it could be so large as to impact the entire enterprise. In general, any approved request which an organization cannot immediately route to a suitable, existing Solution will eventually identify such a request as one of three (1 of 3) things:
- A Capability, comprised of Features across multiple Epics or Solutions.
- One or more new Epics; and/or
- One or more new Solutions.
Comparatively, at the onset of Portfolio Management, the Vision > Epic > Feature structure associated with each Solution does not yet exist. In fact, figuring out how to map each Request into a Vision > Epic > Feature structure(s) is a primary objective of the Portfolio Approach.
Fortunately, the ITM's approach to Portfolio Management reuses many Solution Delivery tasks and objects. As a result, this eliminates the need to introduce new, additional objects or tasks. For instance, given that there is no context yet, the Portfolio Approach (re)uses Vision, Epics and Features somewhat differently than the Solution Approach.
The tables below describe the parallels and highlight the differences.  For additional information on any topic, look to the Solution Management column for links to more detail on a given subject. If viewing from the Portfolio Management perspective, then look to the column on the right, and make appropriate adjustments as described.
For the most part, the ITM does not restate (i.e., duplicate) most topics below to provide a Portfolio Management perspective. Rather, Portfolio Management participants should become familiar with the Solution Management subjects. Afterwards, they can apply these subjects to Portfolio Management, along with the modifications indicated below.
Highlighting the Differences
Note that in the Implementation Parallels table there are separate, but complimentary, tasks for managing Solution work as compared to Portfolio work. In other words, the tasks each approach uses are different. Each task is tailored to suit the needs of each approach.
Alternatively, this is not the case in the Planning Parallels or Ceremony Parallels tables. Instead, the actions in these tables, with some minor adjustments, apply to both Solution Management and Portfolio Management.
Planning Parallels
In general, the Planning Approach is equally applicable to Portfolio Management and Solution Management.
Indeed, the only difference is scope. Whereas the scope for Solution Planning is a single Solution, the scope for Portfolio Planning is the entire Solution Portfolio.
Therefore, look for the addition of 'Portfolio' to a planning task's name. In this case, it indicates a variance from the corresponding Solution Approach subject.
| Solution Management | Portfolio Management |
|---|---|
Planning Level 1 - Vision | |
| PL1.1: Solution Vision: Describes the highest-level definition of an individual Solution. | Portfolio Vision: Provides the highest-level definition of the organization's entire Portfolio. References to Customers, their Needs, the Portfolio, and its Goals, should all be from the overall Portfolio perspective. |
| PL1.2: Epic List: Is the highest-level means by which Solutions are broken down for delivery, typically by major Function and/or Business Segment. | Portfolio Epic List: A Portfolio Epic is the initial means by which potential change to the overall Portfolio is identified for stakeholders outside of Portfolio Management. This allows them to track its progress without needing to delve into the details of Portfolio Management. Each Portfolio Epic relates to a Request for Change that, based on the information currently known, cannot be fulfilled by existing Solutions, Epics or Capabilities. By the end of the Portfolio Management process, each Portfolio Epic will transition into one or more Solution Epics, which can then be managed using Solution Management activities. |
Planning Level 2 - Roadmap | |
| PL2.1: Epics to Features: The breakdown of individual Epics into increments of Business Value. | Portfolio Epics to Features: N/A. This does not happen at the Portfolio level. Rather, Features (Requests) drive the creation of temporary Portfolio Epic(s). Amongst other things, Epics allow parties outside of the TMO to track change progress (see Epic Lifecycle Management). |
| PL2.2: Initial Rollout Plan: How the change being delivered during the Solution Phase will be introduced to Customers. | Initial Rollout Plan: N/A. This also does not happen at the Portfolio level. |
| PL2.3: Solution Roadmap: Expresses the Solution's Vision over time. It is a map depicting how the Solution is expected to evolve, as Business Value increments are added. In other words, it depicts the prioritized Solution Features planned for work over periods of time. | Portfolio Roadmap: Expresses the Portfolio's Vision over time. It is a map of how the Portfolio is expected to evolve as Requests for Change are addressed. In other words, it depicts the prioritized Portfolio Features (Requests) planned for future work over periods of time (see next). |
Planning Level 3 - Release Planning | |
| PL3.1: Features into Value Increments: Refine Features as they appear from left to right on the Solution Roadmap. Continue this refinement process until a suitable backlog exists. Ideally, at least two (2) Releases worth of "Ready" Features should exist in the Solution Backlog. IT1: Feature Planning manages this task (see the Implementation Parallels table below). | Features (Request) as Portfolio Increments: Each Customer Request for Change is managed via a Portfolio Feature (Request). Features are used to manage the request's progress through Portfolio Management. A Portfolio Feature will relate to a Portfolio Epic (see Epic List above). Ideate Features as they appear from left to right on the Portfolio Roadmap. Continue the Ideate process until a suitable backlog of "Ready" Features (Requests) exist. Ideally that's at least two (2) Releases worth of "Ready" Features should exist in the Portfolio Backlog. PT1: Ideate Feature manages this task (see the Implementation Parallels table below). |
| PL3.2: Themes: Optional, but can be used to help apply the Solution Roadmap effectively to Release Planning. Typically, Themes are used to group, or organize, related Features, such as those for a large initiative, or those applicable to one Business Unit vs another. | Themes / Initiatives: Can be used to help apply the Portfolio Roadmap effectively to Release Planning. Typically, Themes are used to group, or organize, related Features (Requests) related to a large initiative. Alternatively, they can group those applicable to one Business Segment vs another. Or, for those relating to one Customer segment vs another. |
| PL3.3: Features & Stories Targeted to Release Increments: The initial estimates of when Features, and their related Stories, are expected to be worked. Driven by known Capacity, targeted increments provide an excellent early indicator of when there is an imbalance between the work to be done, the resources to do it. They may also indicate the productivity, or lack thereof, of assigned resources. | Features & Stories Targeted to Release Increments: The initial estimates of when Features (Requests), and their related Stories, are expected to be worked. Driven by known Capacity, targeted increments provide an excellent early indicator of when there is an imbalance between the work to be done, the resources to do it. They may also indicate the productivity, or lack thereof, of assigned resources. |
| PL3.4: Release Plan(s) and Release Backlog(s): A subset of the Solution Backlog, a Release Backlog is the list of Features, Stories and Bugs selected to be delivered over the medium-term. It defines a scope of work to accomplish during a fixed timeframe. Created during the Release Planning Event (see Ceremony Parallels table below). | Release Plan(s) and Release Backlog(s): A subset of the Portfolio Backlog, it is the list of Elaborate Features and Elaborate Stories selected to be completed over the medium-term. In the Portfolio perspective, each "Release" strives to complete the Portfolio Management tasks for one or more Requests. That is, to conclude Solution Definition, and transition the resulting Solution(s), Epic(s) and/or Capability(ies) on to Solution Delivery. Created during the Release Planning Event (see Ceremony Parallels table below) |
| PL3.5: Solution Backlog: The entire list of Features, Stories & Bugs within scope of the Solution. | Portfolio Backlog: The entire list of Features (Requests) and Stories (Artifacts) to be worked as part of Portfolio Management. NOTE: 'Portfolio Backlog' is also a state at which Solution Epics and Capabilities begin, following their transition from Portfolio Epics. This represents their transition from Portfolio Management to Solution Management. Epics & Capabilities remain in this state until included in a Solution Phase. At which point, they progress to 'Implementing'. |
Planning Level 4 - Sprint Planning | |
| PL4.1: Stories into Functional Increments: Refine Stories related to Features in the Release Backlog. IT2: Story Analysis manages this task (see Implementation Parallels table below) | Stories into Functional Increments: Add Ideate Stories appropriate for each Ideate Feature, then work them until each is complete and the parent Feature is ready for review. This activity is managed by PF2: Ideate Stories (see Implementation Parallels table below). |
| PL4.2: Sprint Plan(s) Sprint Backlog(s): A subset of the Release Backlog, it the list of Stories and Bugs selected to be built over the short-term. Created during the Sprint Planning Event (see Ceremony Parallels table below). | Sprint Plan(s) and Sprint Backlog(s): A subset of the Release Backlog, it is the list of Elaborate Stories to be completed over the short-term. Created during the Sprint Planning Event (see Ceremony Parallels table below). |
Planning Level 5 - Daily Planning | |
| PL5.1: Daily Standup: Short check of work-in-progress, offering the Team the ability to update one another, exchange information, and to highlight any impediments which the Scrum Master will then endeavor to address. | Daily Standup: Short check of work-in-progress, offering TMO members the ability to update one another, exchange information, and to highlight any impediments which the Scrum Master will then endeavor to address. |
| PL5.2: Schedule Analysis & Design: Activities which make Features and Stories "Ready" for development, producing a "Healthy Backlog" of work. | Schedule Intake & Ideation: Activities which make Features (Requests) and Ideate Stories "Ready" for Elaboration, producing a "Healthy Backlog" of work. |
| PL5.3: Schedule Build, Test & Deploy: Actions that take "Ready" Features and Stories, selected during Release and Sprint Planning Events, and work them until they are "Done". | Schedule Elaboration: Activities that take "Ready" Features (Requests) and Elaborate Stories selected during Release Planning Events and Sprint Planning Events and work them until they are "Done". |
Implementation Parallels
On the whole, while the subject matter of the actual tasks differ there is still much in common.
For instance, both the Solution Approach and Portfolio Approach rely upon a set of 4 tasks. In both cases, the first two tasks make things "Ready" for change. Similarly, the latter two tasks then get the defined change "Done".
| Solution Management | Portfolio Management |
|---|---|
Task 1 of 4 | |
| IT1 - Feature Planning: The task to manage thorough definition of a Feature - some increment of MVP Business Value - making it "Ready" for delivery. | PT1 - Ideate Feature: The task to manage thorough definition of a Request for Change. Each Request originates as a Feature. It is either routed to an appropriate, existing Solution, or is made "Ready" to Elaborate potential Solutions, Epics and/or Capabilities. |
Task 2 of 4 | |
| IT2 - Story Analysis: The task to manage thorough definition of a Story - some increment of functionality - making it "Ready" for delivery. | PT2 - Ideate Stories: The task to manage completion of individual artifacts - each an Ideate Story - deemed necessary to make the parent Feature "Ready" to Elaborate potential Solutions, Epics or Capabilities. |
Task 3 of 4 | |
| IT3 - Feature Release: The task to manage delivery of a Feature from Build, through Certification, and on to Production. | PT3 - Elaborate Feature: The task to complete the full definition of new Solution(s), Epic(s) and/or Capability(ies), needed to meet the original Feature's (Request's) objectives. Also, to manage the transition from Solution Definition on to Solution Delivery for each resulting Solution, Epic and/or Capability. |
Task 4 of 4 | |
| IT4 - Story Build: The task to manage the development of Stories, creating functionality increments which enable a Feature. | PT4 - Elaborate Stories: The task to manage completion of the individual artifacts - each an Elaborate Story - deemed necessary to enable the parent Feature to progress from being a Request, to becoming actionable effort(s) within one or more Solutions. |
Approach Comparison | |
| In the Solution Approach, most Stories represent increments of functionality which, when combined with other Stories related to their parent Feature, deliver an increment of Business Value. The same Stories progress through Analysis & Design and then Build, Test & Deploy stages. | Conversely, in the Portfolio Approach, Stories represent individual artifacts to complete in order for the Request (Feature) to be processed. These include things like high-level process definitions, mid-level requirements, resource estimates, business cases, and so on. Certain types of Features (Requests) will have a standardized set of associated Stories, allowing for the creation of template Feature & Stories combinations, and for a good amount of reuse. Ideate Stories are different than Elaborate Stories. Ideate Stories represent artifacts used to evaluate feasibility and prioritize change. Conversely, Elaborate Stories represent artifacts used to define a Solution. Each type represents a set of artifacts needed to complete some progress of the parent Feature (Request). Within each task, Intake & Ideate or Elaborate, all Stories related to the Feature are completed. They do not carry over from one task to the next. This is unlike the Solution Approach, where the same Stories progress from Analysis on to Build. |
Ceremony Parallels
Finally, Ceremonies should operate the same manner, and for the same purpose for both the Solution Approach and the Portfolio Approach.
| Solution Management | Portfolio Management |
|---|---|
Release Planning Events | |
| Release Planning Event: A ceremony involving the Solution's Management, Customers, Architects, and Team(s). During the event, they negotiate, and select the Features targeted for delivery during the next Release. Importantly, only "Ready" Features in the Solution Backlog are available for selection. IT1: Feature Planning manages the work which occurs before each RPE, to make Features "Ready". This event marks the beginning of the Release cycle. As a result, it also establishes medium-term scope. IT3: Feature Release manages the work which follows each RPE (see Implementation Parallels table above). | Release Planning Event: A ceremony involving the TMO, Customers and relevant Leadership. During the event, they negotiate, and select the Features (Requests) targeted for completion during the next Portfolio Release. Importantly, only "Ready" Features (Requests) in the Portfolio Backlog are available for solution. PT1: Ideate Feature (Request) manages the work which occurs before the RPE, making Feature "Ready". This event marks the beginning of a Portfolio Release (i.e., Elaborate cycle). As a result, it also sets medium-term scope. PT3: Elaborate Feature (Request) manages the work which follows the RPE (see Implementation Parallels table above). |
Sprint Planning Events | |
| Sprint Planning Event: A ceremony during which the Team selects to be built during the next Sprint. Importantly, only "Ready" Stories in the Release Backlog are available for selection. IT2: Story Analysis manages the work which occurs before an SPE, making Stories "Ready". This event marks the beginning of a Sprint cycle. As a result, it also establishes short-term scope. IT4: Story Build manages the work which follows the SPE to complete the Sprint (see Implementation Parallels table above). | Sprint Planning Event: A ceremony during which the TMO selects from the list of Elaborate Stories in the Release Backlog those which are to be completed during the next Sprint. This event marks the beginning of the Sprint cycle. As a result, it also sets short-term scope. PT4: Elaborate Stories manages the work which follows the SPE to complete the Sprint (see Implementation Parallels table above). |
Sprint Retrospectives | |
| Sprint Retrospective: The opportunity at the end of each Sprint for each Team to identify what worked well during the Sprint (to reinforce repeated use in the future) and what did not (to identify and implement opportunities for improvement). | Sprint Retrospective: The opportunity at the end of each Sprint for the TMO and supporting participants to identify what worked well (to reinforce repeated use in the future) and what did not (to identify and implement opportunities for improvement). |
Release Retrospectives | |
| Release Retrospective: The opportunity for everyone involved with the Solution to identify what worked well during the Release (to reinforce repeated use in the future) and what did not (to identify and implement opportunities for improvement). | Release Retrospective: The opportunity for everyone involved with the Portfolio to identify what worked well during the Release (to reinforce repeated use in the future) and what did not (to identify and implement opportunities for improvement). |