0% found this document useful (0 votes)
200 views11 pages

Application Portfolio Management Playbook

Uploaded by

Richard Whipp
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
200 views11 pages

Application Portfolio Management Playbook

Uploaded by

Richard Whipp
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

Rationalize Your Application Portfolio Playbook

Getting Started
This guide provides a framework for getting started in defining your playbook’s language and tone and tying
together the concepts you will find in more detail within the Rationalize your Application Portfolio storyboard.
While this playbook will not dive deep into the execution of specific processes and practices, you will want to
reference additional resources to find more context and advice.

Who Should Use This Playbook?


This playbook was primarily written for smaller IT departments unlikely to have a dedicated role for APM. This
playbook should be used by any personnel responsible for maintaining the application inventory, application
rationalization tool, and application portfolio roadmap. All three can be found in the Application Portfolio
Management Snapshot and Foundations Tool.

Table of Contents
APPLICATION PORTFOLIO MANAGEMENT PLAYBOOK ....................................................... 1
GETTING STARTED ...................................................................................................................... 1
WHO SHOULD USE THIS PLAYBOOK? ........................................................................................... 1
TABLE OF CONTENTS .................................................................................................................. 1
INTRODUCTION .......................................................................................................................... 2
WHAT IS APPLICATION PORTFOLIO MANAGEMENT? ...................................................................... 2
WHY APM? ................................................................................................................................ 3
INFO-TECH’S FIVE-LENS MODEL FOR APPLICATION RATIONALIZATION ........................................... 4
INFO-TECH’S 6 R’S DISPOSITION MODEL ...................................................................................... 5
APM SCOPE ................................................................................................................................ 6
APM GOALS AND METRICS .......................................................................................................... 6
APM CORE STEPS AND ROLES .................................................................................................... 7
APPLICATION INVENTORY ATTRIBUTES ......................................................................................... 8
APM DISCOVERY AND RATIONALIZATION ITERATIONS ................................................................. 10
APM ONGOING CADENCE ....................................................................................................... 11

1
Info-Tech Research Group
Introduction
What Is Application Portfolio Management?

Application portfolio management (APM) is an ongoing governance process that ensures applications across the
organization continue to deliver value, limit risk, and justify their cost. This process also includes:
• Providing information and visibility into applications across the organization.
• Recommending application initiatives (enhancements, corrections, retirement) to decision makers.
• Aligning delivery teams on how to prioritize applications and their support needs or enhancement.
• Showcasing the strategic direction of applications to various stakeholders.

APM Activities and Artifacts

2
Info-Tech Research Group
Why APM?
Common Challenges
1. Application sprawl is inevitable.
• All organizations evolve in some way as their application needs change and grow. New
applications are constantly added to the portfolio.
• Modern applications are easier for organizations to implement and manage on their own without
consulting or informing IT.
• Technology ages and becomes obsolete or exposed to new threats, or versions simply become
out of date and present business continuity risk.
• Most organizations acquire more applications than they need, and this is an unnecessary cost
and burden small enterprises cannot afford.
2. Sprawl is rarely handled strategically.
• The addition of new applications often lacks confirmation of overlapping functionality with current
applications or if the applications fit the underlying technology strategy of the organization.
• No centralized function documents applications.
• Decommissioning current applications often falls by the wayside, as it is an investment many
organizations struggle to align to added value.
• No dedicated or centralized effort to manage the application portfolio means no single source of
truth is available to support informed decision-making.
3. IT departments struggle to manage sprawl or the excess of software to support needs.
• IT teams do not always know all the organization’s assets; therefore, they cannot know the extent
of costs and risks.
• Teams are overburdened by a higher support demand with low capacity.
• Teams are unsure which requests to prioritize to maintain and enhance.
• Teams are uncertain if problematic applications should be remediated or retired.

Resolution
Build an APM practice fit for the size that focuses on priority activities.
1. Integrate these tasks into your mixed workload.
2. Create an inventory built for better decision making.
3. Rationalize your apps by business priorities and communicate risk in their terms.
4. Create a roadmap that improves communication between those who own, manage, and support an
application.

Benefits
The benefits of APM extend past ROI and are experienced by both IT and the organization as a whole.
• Improve relationships by informing stakeholders about application assets and opportunities to add value
to their capabilities.
• Reduce the number and operational cost of applications. Essentially, create a more efficient portfolio that
delivers higher value and lowers costs.
• Reduce the risk applications present to business capabilities.
• Reduce the complexity of the portfolio and decrease the likelihood that your technology environment is a
barrier to growth.

3
Info-Tech Research Group
Info-Tech’s Five-Lens Model for Application Rationalization

Application rationalization requires the collection of several data points that represent these perspectives and act
as the criteria for determining a disposition for each of your applications.

Disposition: The intended strategic direction or implied course of action for an application.

Application rationalization, the central activity of APM, is where you assess your applications to determine their
disposition, strategic direction, or a specific call to action. Application rationalization requires multiple perspectives
from various stakeholders across the organization to ensure you are arriving at a holistic and well-informed
decision. Each lens in the model above requires the collection of several data points that represent each
perspective and act as the criteria for determining a disposition for each of your applications. Further descriptions
of the rationalization factors are found in the Application Rationalization Factors section of this playbook.

4
Info-Tech Research Group
Info-Tech’s 6 R’s Disposition Model
Many approaches to application rationalization feature a matrix, where the data points from the various
rationalization factors plot an application in a quadrant or area of the matrix suggesting a recommended
disposition. This particular model applies a three-dimensional matrix, where technical health, organizational value
and fit, and end-user perspective are the three factors that suggest a disposition. This is the primary framework
for rationalization in this playbook. Further description of these dispositions is found later in the “Target
Dispositions” section.

High

TCO, compared relatively to


organizational value and fit, helps
Technical Health

determine the practicality of a


disposition and the urgency of any
call to action. Application alignment
is factored in when assessing
redundancies and has a separate set
of dispositions.
Low
Low

High

Disposition Description
Prioritize new features or enhancement requests and openly welcome the expansion of
Reward
these applications as new requests are presented.
Address the poor end-user satisfaction with a prioritized project. Consult with users to
Refresh
determine if UX issues require improvement to address satisfaction.
Determine the root cause of the low value. Refocus, retrain, or refresh the UX to improve
Refocus value. If there is no value found, aim to "keep the lights on" until the app can be
decommissioned.
Replace or rebuild the application as technical and user issues are putting important
Replace
business capabilities at risk. Decommission application alongside replacement.
Address the poor technical health or risk with a prioritized project. Further consult with
Remediate development and technical teams to determine if migration or refactoring is suited to address
the technical issue.
Cancel any requested features and enhancements. Decommission the application and
Retire
transfer end users onto an alternative system.

5
Info-Tech Research Group
APM Scope
This section explains the scope of the APM process in terms of key steps, roles and their involvement, and the
different types of applications that will be included in the various assessments and artifacts.

APM Goals and Metrics


The table below illustrates the goals, metrics, and targets of the APM process. The objectives of setting these
goals are to:
• Align those performing the execution of the APM process with what they are driving toward.
• Determine how or if the APM process needs to be specifically modified to accomplish these goals.
• Keep stakeholders and those responsible informed about the progress and success of the APM process.
• Communicate the intention of APM and create a sense of mutual benefits to encourage buy-in and the
willingness of required application subject matter experts to participate in specified activities.

Goals Metric Targets

Improve ability to • Application inventory with all data fields


inform the completed • 80% of the portfolio
business • Applications with an assigned disposition

Improve
• Applications with an assigned business and
ownership of • 80% of the portfolio
technical owner
applications

• TCO of full application portfolio


Reduce costs of • Reduce by 5%
• The number of recovered/avoided software
portfolio • $50,000
licenses from retired apps

• Migrate all applications


• 100% of applications
Migrate platform • Total value change in on-premises apps switched
• Increase by 50%
to SaaS

Improve overall
satisfaction with • End-user satisfaction rating • Increase by 25%
portfolio

Become more • Increased sales


• Increase by 35%
customer-centric • Increased customer experience

6
Info-Tech Research Group
APM Core Steps and Roles
An APM process spans several traditional roles, which will range depending on existing processes and process
maturity. Ideally APM is integrated with other common IT processes such as project management. The table
below is intended to describe the APM process and how it fits within existing processes and roles, specifically
illustrating:
• The core steps of the APM process
• The necessary inputs and outputs for each step
• The roles involved with each step, in terms of who executes the step, who provides information, and who
ultimately consumes the outputs

Suppliers Inputs Process Outputs Customers


• Build inventory
• Applications
• Create the full list of
manager • Application
• List of applications applications capturing
• Operations inventory • Whole
• Application attributes all necessary attributes
manager • Identified organization
• Business capabilities • Resp: Applications
• Business owners manager & IT team
redundancies
• IT team member
• Application inventory
• Applications • Existing documentation • Collect & compile
• Data points of
SMEs • Additional collection • Engage with
business value,
• Business owners methods appropriate SMEs and • Applications
cost, and
• Support owners & • Knowledge of business collect necessary data
performance for
manager
team value, cost, and points for rationalization
each application
• End users performance for each • Resp: IT team member
application
• Defined application • Assess & recommend
rationalization • Apply rationalization • Assigned
• Business
framework and toolset framework and toolset disposition for each
• Applications • Data points of business to determine application
owners
manager • Steering
value, cost, and dispositions • New projects ideas
committee
performance for each • Resp: Applications for applications
application manager
• Assigned disposition for
• Validate & roadmap
each application • Application portfolio
• Present dispositions for
• New project ideas for roadmap
validation and
• Business owners applications • Confirmed
communicate any • Whole
• Steering • Awareness of goals and disposition for each
decisions or directions organization
committee priorities application
for applications
• Awareness of existing • Project request
• Resp: Applications
projects and resources submission
manager
capacity
• Applications • Project request • Project intake
manager submission • Build a business case • Steering
• Solutions • Approved project
• Estimated cost for project requests committee
engineer
• Estimated value or ROI • Resp: Project manager
• Business owner

7
Info-Tech Research Group
Application Inventory Attributes
The table below outlines the information or data points that will need to be captured as new applications are
introduced and updated regularly. This table includes a description and the intended method to collect and update
the information.

Attribute Description Collection Method


Auto-discovery tools will reveal the name of the
applications found. However, this may not be the
Terminology the organization uses for organizational nomenclature. You may adapt the
Name
the application. names by leveraging preexisting documentation
and internal knowledge or by consulting business
users.
Unique identifiers assigned to the Typically, an identification system is developed by
ID
application (e.g. app number). the application portfolio manager.
Typically completed by leveraging preexisting
A brief description of the application,
Description documentation and internal knowledge or by
often referencing core capabilities.
consulting business users.
Consultation, surveys, or interviews with business
unit representatives. However, this does not always
A list of all business units,
Business Units expose hidden applications. Application capability
departments, or user groups.
mapping is the most effective way to determine all
the business units/user groups of an app.
Application capability mapping is completed
Business A list of business capabilities the
through interviews with business unit
Capabilities application is intended to enable.
representatives.
A high-level grading of the
importance of the application to the
Typically, the criticality rating is determined by a
Criticality business, typically used for support
committee representing IT and business leaders.
prioritization purposes (e.g. critical,
high, medium, low).
The individual accountable for various If application ownership is established
aspects of the application (e.g. accountability in your organization, typically
product owner, product manager, consulting appropriate business stakeholders will
Ownership
application support, data owner); reveal this information. Otherwise, application
typically includes contact information capability mapping can be an effective means of
and alternatives. identifying who that owner should be.
Any relevant subject matter experts
Technical SMEs should be known within an IT
who can speak to various aspects of
department, but shadow IT apps may require
Application the application (e.g. business process
interviews with the business unit. Application
SMEs owners, development managers, data
capability mapping will determine the identity of
architects, data stewards, application
those key users/business process SMEs.
architects, enterprise architects).
An indication of whether the
application was developed in-house, Consultation, surveys, or interviews with product
Type
commercial off-the-shelf, or a hybrid owners or development managers.
option.
An indication of whether the
Consultation, surveys, or interviews with product
Active Status application is currently active, out of
owners or operation managers.
commission, in repair, etc.
Identification of the vendor from
Consultation with business SMEs, end users, or
Vendor whom the software was procured.
procurement teams or review vendor contracts or
Information May include additional items such as
license agreements.
the vendor’s contact information.

8
Info-Tech Research Group
Attribute Description Collection Method
Pertinent information regarding the
other relevant documentation of the
Consultation with product owners, service
Links to Other application (e.g. SLA, vendor
providers, or SMEs or review of vendor contracts or
Documentation contracts, data use policies, disaster
license agreements.
recovery plan). Typically includes
links to documents.
The current number of application
users. This can be based on license
Consultation, surveys, or interviews with product
information but will often require
Number of owners or appropriate business SMEs or review of
some estimation. Can include
Users vendor contracts or license agreements. Auto-
additional items of quantities at
discovery tools can reveal this information.
different levels of access (e.g. admin,
key users, power users).
Consultation with application architects and any
List of other applications or operating
Software architectural tools or documentation. This
components required to run the
Dependencies information can begin to reveal itself through
application.
application capability mapping.
Identification of any hardware or Consultation with infrastructure or enterprise
Hardware infrastructure components required to architects and any architectural tools or
Dependencies run the application (e.g. databases, documentation. This information can begin to reveal
platform). itself through application capability mapping.
Consultation, surveys, or interviews with
Development The coding language used for the
development managers or appropriate technical
Language application.
SMEs.
A framework of services that
Consultation, surveys, or interviews with
Platform application programs rely on for
infrastructure or development managers.
standard operations.
Where an application is within the
Lifecycle Consultation with business owners and technical
birth, growth, maturity, and end-of-life
Stage SMEs.
lifecycle.
Any major or minor updates related to
Scheduled Consultation with business owners and vendor
the application including the release
Updates managers.
date.
Planned or In- Any projects related to the application Consultation with business owners and project
Flight Projects including estimated project timeline. managers.

9
Info-Tech Research Group
APM Discovery and Rationalization Iterations
The table below outlines the grouping of applications for an iterative approach to rationalizing your applications. It
also details which applications overlap with other applications in supporting a business capability and require
additional analysis.

Application Estimated Estimated Estimated Recommended


Priority
Subset Applications Start Duration Participants
Business

Unit 1
Business

Unit 2
Business

Unit 3
Business

Unit 4
Business

Unit 5
Business

Unit 6
Business

Unit 7
Business

Unit 8

10
Info-Tech Research Group
APM Ongoing Cadence
The last section outlines the structure and consistency of the ongoing APM process. The table defines the
ownership of the three primary artifacts or tools of APM, including the information and data within them,
specifically illustrating:
• Who is accountable for the artifact or tool.
• How frequently they should update the artifact or tool.
• What is included in updating the artifact or tool.
• Who the audience is.
• How frequently they should present the artifact or tool to said audience.

Update Presentation
Artifact Owner Update Scope Audience
Cadence Cadence
• Add new application
data points (this is
• As new added to
applications implementation • Always
• Whole
Inventory are acquired standards) available on
organization
• Annual • Review inventory and the team site
review perform a data health
check
• Validate with App SME
• Revisit value driver
weights
• Survey end users
• Interview support
owners • Annually
• Business
• Interview business alongside
Rationalization • Annual owners of
owners yearly
Tool update applications
• Update TCO based on strategy
• IT leaders
the change in meeting
operational costs;
expand thoroughness
of cost estimates
• Rescore applications
• Shift the timeline of the
roadmap to the current • Steering • Quarterly
• Monthly
day 1 Committee alongside
updates
Portfolio • Carry over project • Business steering
alongside
Roadmap updates and timeline owners of committee
project
changes applications meetings
updates
• Validate with PMs and • IT leaders • Upon request
business owners

_____________________________________________________

For acceptable use of this template, refer to Info-Tech's Terms of Use. These documents are intended to supply
general information only, not specific professional or personal advice, and are not intended to be used as a
substitute for any kind of professional advice. Use this document either in whole or in part as a basis and guide for
document creation. To customize this document with corporate marks and titles, simply replace the Info-Tech
information in the Header and Footer fields of this document.

11
Info-Tech Research Group

You might also like