The first of four (1 of 4) tasks in the ITM's Solution Portfolio Approach manages the capture and assessment of Requests for Change. Together, the four (4) tasks drive and manage ongoing Portfolio Management. The name 'Ideate Feature' derives from the fact that every Customer Request for Change begins as a Feature in the Portfolio Backlog.
At this time, the objective is to determine whether there is value in pursuing the request. Moreover, if there is value, then prioritize it against all other requests for change. Organizations can only do so much with the resources available. This task is the first to filter out requests that diminish, rather than enhance, the value of an organization's Solution Portfolio.
PT1 - Capture & Assess Customer Requests
Overview
To begin, Portfolio Task 1: Ideate Feature (Request) captures each Request for Change as an outline of a Feature. At this point, this is no more than a title, brief description, and perhaps an early list of anticipated benefits.
If a change cannot route to an existing Solution, then several steps rationalize the request and assess its value and risk. Afterwards, requests which remain feasible progress through steps which properly define them.
This task ends once the Feature is "Ready" for subsequent Elaborate activities. The Work Management System (WMS) provides the tool to manage this refinement process, through use of the Ideate Feature Board.
Ideate Feature Board
In the graphic, the five (5) columns to the left represent the States that a Feature may progress through during Intake and Ideate. To illustrate, the arrows represent the permissible transitions from one State to another, per the configured Portfolio Feature Workflow.
To be sure, an Ideate Feature Board is a Kanban board. In effect, the Transformation Management Office may have multiple Feature Ideate Boards. In this case, each allows for varying ways to highlight relevant Feature attributes. For instance, to highlight Customer (Business Segment), Theme (Initiative) or Assignee.  However, a better way is to have a single board and to use Quick Filters to highlight desired perspectives.
Regardless of how many boards are in use, understand that the Features displayed all reside in a single, underlying backlog. This is the Portfolio Backlog. Multiple boards, or filters, simply allow for viewing the Portfolio Backlog in multiple ways, to suit multiple audiences.
Indeed, if using multiple Ideate Feature Boards, each may use Column Labels tailored to suit the board's target audience. For example, TMO, Customer* or Status Reporting. However, regardless of the Label on each column, behind it there are specific State values associated with each column.
In fact, it is these State values that determine which Feature appears in which column. Additionally, these State values, along with the WMS Workflow, determine to what State a Feature can change based upon its existing State.
* As an aside, an Ideate Feature Board is not the proper perspective for most Customers. Instead, they should refer to an Epics Board to monitor any Request for Change not routed immediately to an existing Solution. Indeed, the Ideate Feature Board allows the TMO, and other participants, to execute Portfolio Management tasks.
Measuring Request Progress & Priority
To illustrate, the graphic above depicts the five (5) States that a Feature (Request) undergoing Intake & Ideate may have. Seeing that, the following describes each State, and what it means when a Feature (Request) is in that State.
Request Progress
To begin, WMS Boards typically allow for two types of tags. The ITM refers to these as States and Labels. Each contributes differently to monitoring items as they progress through the Portfolio Backlog.
States
To explain, a State is a configuration within the WMS. As a result, it is available for use behind the scenes. For instance, Workflow will use these values. Similarly, these values often appear in WMS Reporting. In effect, States are often reused, across boards, and across Solutions. Hence, they may indicate different things, at different times, on different boards.
Labels
Alternatively, a Label is a name, or title, of a column. That is, Labels provide a context, or other indication, for the contents of a column. Significantly, a column, and hence a Label, may have multiple States associated with it. Similarly, one can associate the same State with different Labels on different boards. In other words, consider a Label an explanation, or clarification, of a State(s) intended use, in the column, within the context of the given board.
| WMS Feature State | Description |
|---|---|
State = Open | Context: 'Open' is the State where all new Features (Requests) begin. It simply means a new idea, or change, is proposed. The Feature representing that change now exists in the Portfolio Backlog. The Feature itself may move up or down in this column, indicating its priority relative to other Features in the same State. As it approaches the top of this column, the following actions take place. The Feature should not progress to the next State until the actions are complete. Actions: The assigned TMO member first categorizes the Feature. That is, they will determine whether the Request can be fulfilled by an existing Project or Solution. If it can, they will route the Request to the corresponding initiative. In other words, they ensure addition of the Feature (Request) to the appropriate Solution Backlog. Then, they remove it from the Portfolio Backlog. If existing initiatives cannot fulfill the Request that should indicate the need for a new Capability, Epic and/or Solution. In that case, the TMO member creates a brief, high-level definition of the Request using a Portfolio Epic template. If the Request is not feasible (time, cost, personnel, etc.), then reject the proposed change. After gaining agreement from the Request's Sponsor, Close the request in the Portfolio Backlog. Owner: In this State, the TMO should assign the Feature (Request) to a TMO member responsible for the Customer making the request, or Business Segment sponsoring the request. |
State = To Do | Context: To prioritize a Feature (Request) for refinement, the assigned TMO member moves it on the Ideate Feature Board from the 'Backlog' column to the 'On Roadmap' column. In doing so, its State progresses from 'Open' to 'To Do'. The 'To Do' State indicates that the Feature is now on the Portfolio Roadmap. In other words, from the list of all Requests for Change not yet acted upon, this one is given priority. Typically, the Portfolio Roadmap shows the priority of Features (Requests) from left to right. Conversely, an Ideate Feature Board depicts priority from top to bottom. That is, a Feature (Request) appearing at the top of the column has higher priority than a Feature (Request) appearing below it. And so on for Features (Requests) further below. All Features (Requests) appearing in the column are force ranked; none are of equal priority. Actions: As their schedule permits, the assigned TMO member prepares the Feature for refinement. To begin, they rationalize the Request with other Requests, looking to remove duplicates, or consolidate related Requests. Afterwards, they assess the Request for Portfolio value and risk. Further, depending upon its impact to the organization, the IT Governance Committee (or designated executive) may need to review the Request. If the Request is no longer feasible, it regresses back to 'Open'. At this point, if a new Capability can fulfill the Request, then the TMO member adds a Capability to the Capability Lifecycle Board. As a result, they move remaining work to new Features in the appropriate Solution(s). In this case, they will map the Portfolio Epic to the target Solution Epic(s). Afterwards, they remove the Portfolio Epic if no new Epic is also required. The number of Features (Requests) in this state should not exceed the TMO's ability to Elaborate such Features (Requests) within foreseeable Releases. To explain, bear in mind that two (2) Releases worth of "Ready" Features (Requests) should already exist in the Portfolio Backlog. Hence, the need to refine additional Features (Requests) need not exceed another Release or two. For example, if a TMO has capacity to elaborate 5 Features (Requests) in each Release, then not more than 5 – 10 Features (Requests) should appear in this state at any given time. Owner: To begin, the Feature remains assigned to the TMO member responsible for the Customer making the request. After completing the actions above, the TMO member assigns the Feature to the individual responsible for refining the Request. That may remain the TMO member themselves or may be a participating Business Analyst or Technology Analyst, as appropriate for the given Feature. |
State = In Analysis | Context: When the assignee is ready to begin refining a Feature (Request), they select the highest one assigned to them from the 'On Roadmap' column of the Ideate Feature Board and drag it to the 'In Analysis' column. In effect, this causes the selected Feature's State to progress from 'To Do' to 'In Analysis'. This State indicates that the Request is being actively worked. This is the period during which most work to make a Feature "Ready" occurs. Actions: Depending upon the TMO's approach, either the TMO member or the Feature's Assignee (if different) begins by adding prescribed Ideate Stories to the Portfolio Backlog. The set of Stories may vary depending upon the type of Request. Building upon the initial Portfolio Epic definition, the objective of the Stories is to produce the appropriate artifacts that make the parent Feature "Ready" for Elaboration. In general, the added Stories manage the production of: Process Definitions (when appropriate); mid-level Business, IT and Other Requirements; initial Epic Hypothesis; and Architectural Review. Individual organizations may adjust the Story set to suit the artifacts they deem relevant. In effect, work then shifts to Portfolio Task 2: Ideate Stories. Work will return here once all Ideate Stories related to the Feature are "Ready". Limit the number of Features being refined at any given time based on the resources who own it. Good management practices help individuals focus on completing a few (2 – 5) Features (Requests) at any given time. It would be bad management to assign someone more than 5 Features (Requests) at any given time. If some impediment is found which prevents progress on refining a Feature (Request), consider returning that Feature (Request) to the 'To Do' state. Owner: While in this state the Feature (Request) is assigned to the TMO member or a supporting Analyst responsible for its refinement. |
State = In Review | Context: Upon completion of all Ideate Stories related to the Feature, its Assignee will move the Feature from 'In Analysis' to 'In Review'. This State indicates that the Ideate Stories related to the Feature (Request) are all "Ready" and now ready for Review & Sign-Off. At the same time, if needed they will return ownership to a TMO member, likely the Feature's original Assignee. Actions: The TMO member will circulate the Story-related artifacts as appropriate. Review of and sign-off of the Feature (Request) is something shared by key Stakeholders. Ideally, the TMO should conduct the review as a group, with relevant stakeholders in attendance. Customer/Request Sponsor, Epic/Business/Process Owners, Architects, Solution Managers and the TMO should each pay particular attention to the anticipated Benefits and Acceptance Criteria. In fact, these form the basis for subsequent Feature (Request) Elaboration. If there is not unanimous agreement that the Feature (Request) is "Ready", it should return to an 'In Analysis' State, while noted concerns or gaps are resolved. Owner: While in this state the Feature is assigned to a TMO member responsible for ensuring stakeholder review and sign-off. |
State = Ready | Context: Features (Requests) receiving sign-off that they are "Ready" progress from 'In Review' to 'Ready'. This State indicates the Ideate stage is now complete. Moreover, it indicates that the Feature (Request) is "Ready" for Elaboration. In other words, it is available for selection during a Release Planning Event. Actions: The Feature (Request) remains in this state until it is selected into a Portfolio Release. To see what happens from then on, see Portfolio Task 3: Elaborate Feature (Request). Owner: While in this state, the TMO member who guided the Request through Ideate remains the Assignee. Alternatively, the TMO may designate a single member as the owner for all Features in this State. |
Request Priority
Significantly, the measurement of a Request's priority occurs in two ways - by its progress towards completion; and by its ranking each step of the way.
In general, the higher priority work should be moving up and right on most boards. Conversely, the lower priority work should remain towards the left, and at the bottom.
Progress
Firstly, progress indicates how far down the path is the Request. On the WMS boards, the movement of the Request from left to right indicates progress through the Portfolio Backlog. Requests which appear to the left, have lower priority than Requests to the right. In other words, work to complete items already underway takes priority over starting something else. Otherwise, an ever-growing number of Requests wind up "in process" and few, if any, ever complete.
Ranking
Secondly, ranking indicates relative importance of one Request, as compared to others, in the same State. On the WMS boards, the placement of Requests within a column, from top to bottom, further indicates priority. In effect, Requests lower in a column have lower priority than those above. Indeed, column placement is always a forced ranking. That is, no two items ever have the same priority within a column. As resources permit, the next item(s) worked should be those at the top of a column.
ITM Artifacts
To conclude the Portfolio Task 1 (PT1) reference information, the following summarize the artifacts which relate to this task.
ITM Artifacts: PT1 - Inputs
No part of the ITM produces the following artifacts. However, each should be something most organizations already produce. If available, these inputs will lead to faster, and better, assessment of Requests for Change.
Idea, Proposal or other Request for Change
A business prioritized request for change, typically related to one or more of the following:
- New Business Opportunity
- Cost Savings
- Market Change
- Merger / Acquisition
- Problem with existing Solution(s)
Each new proposal or request will correspond to a new Portfolio Management Feature.
Business Strategy
In general, the guiding principles to guide organizational decisions. In other words, the organization's clear set of plans, actions and goals which outline how it will compete in its market(s). Ideally, this would include the following components:
- Organizational (Corporate) Strategy.
- Business (Competitive) Strategy.
- Functional Strategy; and
- Operational Strategy.
IT Strategy
Basically, the comprehensive plan that outlines how technology should be used to meet IT and Business goals.
Existing Solution Portfolio
Potentially a portion of the IT Strategy, this is an inventory of existing and planned assets within each of the following:
- Application Portfolio
- Technology Portfolio
- Project Portfolio
Ideally, each Portfolio should include a corresponding map of Epics each Solution supports.
Prior Solution Work / Legacy Artifacts
Any relevant information collected that relates to the Request. Some examples include:
- Current-State Business Process definitions (or flows)
- Vendor proposals or materials
- Legacy System information
ITM Artifacts: PT1 - Outputs
Depending upon the size and type of Request, expect to produce most of the following.
"Ready" Features (Requests)
If the Request appears to warrant new Epic(s) and/or Solution(s), then the work to make Feature "Ready" for Elaboration in the Portfolio Backlog must be complete. Otherwise, much time and effort may be wasted pursuing Requests which are not feasible, or otherwise not the best use of an organization's limited resources.
New Capabilities (when appropriate)
If one or more new Capabilities can fulfill the Request, then take this path. In this case, there will no longer be a need to make the Portfolio Feature "Ready". Instead, each Solution will make its Feature(s) ready as part of their own Analysis & Design.
"As-Is" Process Definitions (if desired)
The ITM does not recommend, nor discourage, producing "As-Is" diagrams. Some organizations find it helps to start with Current-State. Others find it consumes resources they would rather apply elsewhere. While "As-Is" can help identify requirements, for larger initiatives they can also constrain transformative thinking.
"To-Be" Process Definitions (Levels 1 & 2 only)
Tangible, referenceable, and agreed upon definition of a Process' scope and operating objectives are vital to any changes which affect operations. When a Request relates to support of business operations, these are invaluable. Unfortunately, too many organizations skip these Business Process Definition artifacts, only to find they would have saved a tremendous amount of time and money had they began with these. Arguably, these provide the best ROI of any artifacts produced during large-scale initiatives.
Mid-Level Requirements
Lists of requirements relevant to the Request. In most cases, these will involve:
- Business Requirements (from Process Definitions, and elsewhere)
- IT Requirements
- Other Requirements (Security, Financial, etc.)
Try to avoid premature requirements. These can needlessly curtail options. For instance, no Solution has yet been selected (officially). So, there is no need to include things like software, hardware or platform requirements at this time.