This ITM covers many, but not all, aspects of IT Portfolio Management.  Its focus is upon getting the applications and/or technologies within an initiative, or across an enterprise, off on the right foot. Accordingly, rather than taking a Project Portfolio approach, the ITM takes more of a Solution Portfolio approach.
To be sure, the approach covers a rather large portion of the Portfolio Management function. Moreover, it addresses a significant portion of Solution-related governance. As a result, the actions in this Section apply equally to a single implementation, a multi-Solution initiative, or to an entire IT Portfolio.
This first part of Portfolio Management provides both an overview as well as reference materials which support other parts and topics in this Section. In an effort to keep too much detail off other Portfolio Management pages, many will include references back to this more detailed source material.
Indeed, the ITM's Portfolio Management guidance draws upon many of the tasks, and objects, initially designed for Solution Delivery. Moreover, while PPM can operate without many of the iterative aspects borrowed from Solution Delivery, applying similar, iterative aspects:
- Aligns work at the Portfolio Level, with work at the Solution(s) level; and
- Provides many metrics, measures, and benefits available from a Plan > Do > Check > Adjust (PDCA)Â cycle.
After reviewing this page, look to the following for additional detail on each subject area.
Herding Cats 101: Managing Requests for Change
Requests for Change are ongoing. That is one of the reasons to recommend organizing for iterative transformation. For one thing, it prepares a firm to support change on an ongoing basis. Comparatively, this approach is better than tackling change on a spin-up / wind-down basis, or an ad-hoc basis.
For instance, one way to prepare is to put consistent, systematic, and improvable, processes in place. Of course, these processes must receive, assess, and prepare to act upon Requests for Change (or simply, Requests). Fortunately, this Solution Portfolio approach provides that systematic approach.
The prior section on How to Organize for Iterative Transformation introduced the means to segment change into manageable components, by Content, by Solution, and by Time. Within the ITM's context, Portfolio Management is about identifying the proper response to any Request, by selecting the appropriate components which can best address the desired change.
Portfolio Objectives
To begin, it is important to understand Portfolio Management's objectives. For instance, these include a strategic focus on goals such as revenue growth, cost reduction, regulatory mandates, and business continuity. Moreover, Portfolio Management seeks to rationalize an organization's suite of IT applications to meet business needs. Conversely, Portfolio Management is not about operational objectives such as project cost, timescales, and deliverables.
The difference between the former and latter objectives underpins the ITM's segmentation between Solution Definition and Solution Delivery. On one hand, Solution Definition, which Portfolio Management drives, is about doing the right things. On the other hand, Solution Delivery is about doing things right. Accordingly, the ITM's Solution Portfolio Approach is not about establishing a project, or a program. Although, these can, and do, occur within Portfolio Management. Instead, Portfolio Management defines boundaries between what to do, and what not to do.
Conduits for Change
For instance, change occurs via conduits suitable to managing such change. The ITM defines those conduits, or channels, as Solutions, Epics, Capabilities, Features and Stories. No channel is larger than a Solution. Accordingly, Portfolio Management establishes the highest-level conduits - Epics and Solutions. Afterwards, Solution Delivery establishes the remaining conduits within defined Epic and Solutions. As a result, these conduits allow organizations to define strategic objectives, and align them to specific initiatives. Furthermore, they clearly define and communicate where any type of change should occur.
In general, objectives exist at three (3) levels: strategic objectives at the Epic level; operations objectives at the Feature level; and tactical objectives at the Story level. After establishing the channels for change, the question then becomes how best to organize their management. Basically, management of most change occurs with each Solution. Although, during periods of large change, Solution Delivery may benefit from additional Project Management oversight. Likewise, a Program helps to orchestrate change across two or more Solutions. Whether dealing with program, project or delivery, Solutions and Epics are always the initial conduits by which to segment and organize change.
To summarize, Portfolio Management sets long-term scope of individual Solutions. Of course, there is no expectation to define a Solution's full lifecycle. Rather, it is to set objectives a Solution should achieve over the coming quarters. In other words, to define a Solution over a coming Phase. Additionally, it helps ensure the right resources are available at the right time. Further, Portfolio Management seeks to eliminate redundant efforts, which increase costs without value, and gaps in effort, which prevent realization of expected value. All in all, it enables alignment of an organization's objectives, improvements, and outcomes. Thereafter, the planning and implementation of change occurs within Solution Delivery.
4 Concurrent Portfolio Tasks
Four (4) concurrent Portfolio Tasks support the continuous processing of Customer requests. To illustrate, the sequence of those work efforts should be as follows:
PT1 - Ideate Feature (Request)
First, working from left to right on the Portfolio Roadmap, and in order of Customer priority, Features (Requests for Change) proceed through an Intake & Ideate task. For the most part, this will make Requests "Ready" for a subsequent Elaborate task. Accordingly, Portfolio Task 1 (PT1): Ideate Feature manages this work. Of the 4 Portfolio Tasks, this one should be the TMO's first priority. That is, the TMO should focus upon new requests, until up to two (2) Releases' worth of "Ready" Features (Requests) are in the Portfolio Backlog. Doing so ensures timely attention to requests and provides an appropriate number of inputs into a Release Planning Event. However, continued work on new Requests beyond 2 Releases worth, means other Portfolio Tasks are not getting the attention they need.
PT2 - Ideate Stories
Second, Ideate Stories manages the artifacts which progress a Feature (Request) through Intake & Ideate. Appropriately, Portfolio Task 2 (PT2): Ideate Stories manages this work. Correspondingly, this task should be the TMO's 2nd priority, after PT1: Ideate Feature task. Completing the designated artifacts weeds out Requests which, for a variety of reasons, should not progress at this time. Those Requests which remain, are added to the Portfolio Backlog. In the Solution Portfolio approach, this backlog maintains the evaluated, and prioritized, list of Requests for which further work is warranted. Again, this ensures that the substantive Elaborate work is always able to focus on the highest priority, highest impact requests.
PT3 - Elaborate Feature (Request)
Third, in Portfolio Management, a 'Release' represents a set of Requests targeted for transition on to Solution Delivery. In other words, it identifies Requests for which the TMO plans to complete their immediate responsibilities. To begin, each Release starts with a Release Planning Event. At that time, the TMO will select some number of "Ready" Features (Requests), the outputs of PT1: Ideate Feature, from the Portfolio Backlog. Afterwards, those selected progress through Elaboration. Of course, each event creates a new Release Backlog. In effect, the new backlog sets the scope of both Features (Requests), and related Elaborate Stories. Accordingly, Portfolio Task 3 (PT3): Elaborate Feature manages the work which takes the selected Features (Requests) from "Ready" to "Done".
PT4 - Elaborate Stories
Finally, Elaborate Stories manages the artifacts which progress a Feature (Request) through Elaborate. Elaborate Stories are added to the Release Backlog during each Release Planning Event. To clarify, for each Feature (Request) selected into the Release, a set of related Elaborate Stories are added to the backlog as well. Now, each Sprint begins with a Sprint Planning Event. At that time, some number of Elaborate Stories are selected from the Release Backlog to complete. Of course, each event creates a new Sprint Backlog. Likewise, each new backlog sets the scope of Stories to complete during the upcoming Sprint. Accordingly, Portfolio Task 4 (PT4): Elaborate Stories manages the work which takes the selected Stories from "Ready" to "Done".
Portfolio Task Boards
To illustrate, the diagram below depicts a management board for each of the four (4) Portfolio Tasks introduced above. Combined, these enable the Solution Portfolio approach that facilitates the ongoing processing of Customer requests for change.  The graphic depicts the following:
Each quadrant in the diagram shows the:
- Title of the Portfolio Task (PT1 - PT4);
- Name of the WMS Board which manages each task; and
- States which a Portfolio Feature or Story can have throughout its lifecycle.
Detailed information about each of these is provided throughout this section.
Columns:
- In the left column, Requests are received, and work begins to determine whether or not a given request is worth pursuing. When it is worth pursuing, then additional work continues to make the Request "Ready" for Elaboration.
- In the right column, prioritized and selected Requests undergo the work to segment, and align them, to the Solution(s) that best satisfy the request. Significantly, this also involves the work needed to set up a new Solution, and to place it on the proper path for success.
Rows:
- In the top row, Features represent Requests for Change (Requests). Generally, Features are the means by which Requests advance through the Intake & Ideate and, when appropriate, Elaborate. Ideally, one or more of these Features (Requests) will transition on to Solution Delivery during each Release. Hence, each Feature must be sized such that its completion can occur within a single Release.
- In the bottom row, Stories represent each, individual, artifact which supports the parent Feature's progress. The appropriate artifacts vary by both type of Request and by the procedures dictated for each organization. Such procedures may involve the firm's budgeting process, or risk analysis approach. In other words, Ideate Stories represent the artifacts to create in order to complete the Feature's progress through Intake & Ideate. Similarly, Elaborate Stories represent the artifacts to complete for the Feature's progress through Elaborate. Analogous to Features above, each Story must be sized such that someone can complete the artifact (or portion thereof) within a single Sprint. Once all Ideate Stories related to a Feature are "Ready", so too the parent Feature (Request) becomes "Ready". Similarly, once all related Elaborate Stories are "Done", so too the parent Feature itself becomes "Done".
Portfolio Approach
Generally, execution of these 4 Portfolio Tasks occur in parallel. Although, when a Solution Portfolio approach is initially setup, the TMO will spend relatively more time on PT1: Ideate Feature and PT2: Ideate Stories. This will populate the original Portfolio Backlog. After establishing a proper backlog, the TMO will then shift some of their Intake & Ideate time towards Elaborate activities. Over time, a balance amongst these 4 Portfolio Tasks will soon emerge.
Time Management Guidelines
Ideally, it would be nice to be able to forecast that each week X amount of time would be spent on PT1: Ideate Feature, and Y amount of time on PT4: Elaborate Stories. In reality, the balance of time needed for each Portfolio Task will always be shifting. This is a result of the nature of business - priorities will shift; change will occur; 'stuff' happens.
And that is as it should be. In fact, it is part of the management role Transformation Management plays in the Solution Portfolio approach. However, in working towards the balance of time, it is important to allocate work time in the proper order. To enumerate, prioritize time towards these 4 Portfolio Tasks in this order:
- PT1: Ideate Feature - is the highest priority until there are:
a) Two (2) Releases of "Ready" Features (Requests).
b) Personnel reach WIP constraints of prioritized Requests; or
c) There are no pending Requests to process. - PT2: Ideate Stories - is the 2nd highest priority, until there are two (2) Releases of "Ready" Features (Requests) or no pending Requests to process.
- PT3: Elaborate Feature - is the 3rd highest priority, until Features (Requests) selected into a Release transition on to appropriate Solution Delivery teams; and
- PT4: Elaborate Stories - is the lowest priority. Spend what time is left after fulfilling the other 3 Portfolio Tasks.
Avoid the "Agile" Pitfall
Beware, too many organizations get fixated on the work involved in PT4: Elaborate Stories. By and large, they believe this to be their highest priority. In this case, a misconception forms, whereby a TMO feels that if they could just get stuff off their plate, and on to someone else's, things would improve. In truth, when this is the case, the TMO does tend to get busy working stuff. Unfortunately, it's just not always the right stuff.
In fact, it is too easy to get lost in the weeds when Elaborate Stories-related work becomes the only frame of reference. The other 3 Portfolio Tasks help ensure that the time spent defining Solutions, Epics and Capabilities is productive. Similarly, they help ensure completion of the right Requests, in the right order. Most importantly, they identify opportunities to consolidate many small Requests into fewer larger Requests.
In effect, these other 3 Portfolio Tasks reduce the amount of work and deliverables a TMO needs to produce. Hence, time frees up, and work on fewer, more important, Requests can progress.
Feature & Story Lifecycles - State Progression Summary
The reason for the multiple Portfolio Tasks, and the various States within each, is to effectively manage overall Solution Portfolio approach activities. The tasks provide the levers, and indicators, to address incoming Requests for Change in a timely and productive manner.
To clarify, each Portfolio Task achieves specific outcomes required for this aspect of Solution Portfolio approach to be successful. Comparatively, having just one overall process would be overly complex and difficult to manage. Alternatively, each Portfolio Task focuses on achieving one important milestone of overall Portfolio Management. Further, each task is independent, meaning its execution can occur in isolation of the other tasks (excluding output / input hand-offs). Moreover, the task's priority ensures the TMO's focus is on what is most important at any given time.
Each State through which a Feature or Story passes during its lifecycle indicates a change in ownership, or hand-off in responsibility. Importantly, this allows those responsible to focus upon what the TMO needs them to do. That is, States enable participants to identify, and act upon, that which is most important. Of course, States also allows management to identify over- or under-utilized resources. Similarly, they also help identify and resolve bottlenecks, impediments, and other problem areas. Finally, States also permit everyone to have much more granular insight into the Work-in-Progress (WIP), as well as overall progress being made.
The table below summarizes the States in which any Portfolio Feature or Story can have during its lifecycle. Additionally, it aligns the States into each of the 4 Portfolio Tasks.
Three (3) States are Not Enough
Upon initial review of the States depicted above, some will argue for a more simplistic workflow. It's not uncommon to see as few as 3 States - "To Do", "In Progress" and "Done" - recommended to manage work. Undoubtedly, that may work for a very small team, with highly standardized work, and a very limited scope.  However, accomplishing something as large and complex as Portfolio Management requires much more granular control.
Moreover, while 3 States may suffice for a single Team, they are not conducive to aligning the work of multiple Teams, groups, and organizations. Certainly, 3 States are not at all suitable for aligning work across multiple, concurrent, Requests. As the adage goes 'What gets measured gets managed'. If there is nothing to measure, then there is not much to manage. And therein lies the root cause of why many organizations fail to effectively manage Requests for Change.
Managing Portfolio Progress
As the prior graphic implies, the Portfolio Tasks and States correspond to Workflow. Behind the scenes, Workflow permits, and constrains, the transition of work from one state to another within the Solution Portfolio approach.
Managing Feature Progress
Every Feature (Request) may progress through PT1: Ideate Feature and PT3: Elaborate Feature. These two Portfolio Tasks correspond to the top row of the Portfolio Management diagram. To illustrate, the graphic depicts the states which a Feature (Request) may have during its lifecycle, as well as the transitions permitted from one state to another. Additional information on these tasks, and states, is provided in the pages throughout this section.
Managing Story Progress
Likewise, every Ideate Story will progress through PT2: Ideate Stories and every Elaborate Story will progress through PT4: Elaborate Stories. These Portfolio Tasks correspond to the bottom row of the Portfolio Management diagram.  Importantly, the Stories themselves do not progress from Intake & Ideate on to Elaborate. Rather, the artifacts produced during the former become inputs into the latter. To illustrate, the graphic depicts the states a Story may have during its lifecycle. Additionally, it depicts the transitions permitted from state to state. Again, the pages which follow explore these in more detail.
Summary of these 4 Portfolio Tasks (PT)
The ITM-related aspects of the Solution Portfolio approach occur over four (4) separate Portfolio Tasks (PT), each with its own actions and artifacts.
- Portfolio Task 1 (PT1): Ideate Feature - Defines what the Business, or Customer, is requesting. Furthermore, this produces an initial assessment of whether or not such a Request warrants further Elaboration.
- Portfolio Task 2 (PT2): Ideate Stories - Itemize, and track, the production of individual artifacts needed to determine whether a related Request should proceed beyond Intake & Ideate, and into Elaborate.
- Portfolio Task 3 (PT3): Elaborate Feature - Takes "Ready" Features (Requests), selected during a Release Planning Event, through Elaborate. In summary, doing so will identify, and/or establish, the Solution(s), Epic(s) or Capability(ies), best suited to fulfilling the Request. Further, it will then transition subsequent work on to the identified targets, in order for them to affect the requested change as part of Solution Delivery.
- Portfolio Task 4 (PT4): Elaborate Stories - Itemize, and track, the production of individual artifacts needed to determine whether there is a need for one, or more, new Solutions, Epics, and/or Capabilities, to fulfill a given Request. And, if so, to set up these new conduits, and to direct further work to the appropriate Solution Delivery group(s).
Portfolio Task Summary
After reviewing the pages listed above, move on to the first of the four (1 of 4) Portfolio Processes - PT1: Ideate Feature (Request).