Get Instant Access
to This Blueprint

Applications icon

Application Portfolio Management Foundations

Ensure your application portfolio delivers the best possible return on investment.

Organizations consider application oversight a low priority and app portfolio knowledge is poor:

  • No dedicated or centralized effort to manage the app portfolio means no single source of truth is available to support informed decision making.
  • Organizations acquire more applications over time, creating redundancy, waste, and the need for additional support.
  • Organizations are more vulnerable to changing markets. Flexibility and growth are compromised when applications are unadaptable or cannot scale.

Our Advice

Critical Insight

  • You cannot outsource application strategy.
  • Modern software options have lessened the need for organizations to have robust in-house application management capabilities. But your applications’ future and governance of the portfolio still require centralized oversight to ensure the best overall return on investment.
  • Application portfolio management is the mechanism to ensure that the applications in your enterprise are delivering value and support for your value streams and business capabilities. Understanding value, satisfaction, technical health, and total cost of ownership are critical to digital transformation, modernization, and roadmaps.

Impact and Result

Build an APM program that is actionable and fit for size:

  • Understand your current state, needs, and goals for your application portfolio management.
  • Create an application and platform inventory that is built for better decision making.
  • Rationalize your apps with business priorities and communicate risk in operational terms.
  • Create a roadmap that improves communication between those who own, manage, and support your applications.

Application Portfolio Management Foundations Research & Tools

Start here – read the Executive Brief

Read our concise Executive Brief to find out why APM is a necessity for your organization and how to right-size it to your needs.

1. Lay your foundations

Work with key stakeholders to define the motivations, goals, and scope of your rationalization effort.

2. Improve your inventory

Inventory your applications and define their business capabilities based on your current understanding.

3. Rationalize your applications

Work with application subject matter experts to quickly rationalize your applications.

4. Populate your roadmap

Review, determine, and prioritize application initiatives, and initiate an application portfolio roadmap to showcase your rationalization decisions to key stakeholders.


Member Testimonials

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve. See our top member experiences for this blueprint and what our clients have to say.

9.3/10


Overall Impact

$31,749


Average $ Saved

19


Average Days Saved

Client

Experience

Impact

$ Saved

Days Saved

Anne Arundel Community College

Guided Implementation

10/10

$61,999

20

Bloomfield Hills Schools

Guided Implementation

10/10

N/A

N/A

VCU Health System Authority

Guided Implementation

9/10

N/A

35

Strathcona County

Guided Implementation

8/10

$1,500

3

Braeston Proprietary Limited

Guided Implementation

7/10

N/A

N/A

Toronto and Region Conservation Authority

Guided Implementation

10/10

$10,000

5

Greenheck Fan Corporation

Guided Implementation

6/10

$6,197

1

Lane Council of Governments

Guided Implementation

10/10

$61,999

105

CLO-OCOL

Workshop

9/10

N/A

N/A

Clark Pacific

Guided Implementation

10/10

N/A

N/A

Western Forest Products Inc.

Guided Implementation

7/10

N/A

N/A

Natural Resources Canada

Guided Implementation

10/10

N/A

N/A

MicroPort Orthopedics Inc.

Workshop

4/10

N/A

N/A

Westconsin Credit Union

Workshop

10/10

$12,399

20

Twin Disc

Guided Implementation

9/10

N/A

2

One Call Care Management

Workshop

9/10

N/A

20

State of Ohio - Ohio Department of Developmental Disabilities

Guided Implementation

10/10

$10,000

5

Apega

Guided Implementation

8/10

N/A

N/A

University of Exeter

Guided Implementation

10/10

N/A

N/A

University of Western States

Guided Implementation

10/10

N/A

10

Natural Resources Canada

Workshop

8/10

$14,500

16

Montgomery County Board of County Commissioners

Guided Implementation

10/10

$6,366

35

Tokyo Electron US Holdings, Inc.

Guided Implementation

8/10

N/A

N/A

City Colleges of Chicago

Guided Implementation

4/10

N/A

N/A

MUFG Bank Mexico Sociedad Anonima Institucion de Banca Multiple Filial

Guided Implementation

10/10

N/A

N/A


Workshop: Application Portfolio Management Foundations

Workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.

Module 1: Lay Your Foundations

The Purpose

  • Work with key corporate stakeholders to come to a shared understanding of the benefits and aspects of application portfolio management.

Key Benefits Achieved

  • Establish the goals of APM.
  • Set the scope of APM responsibilities.
  • Establish business priorities for the application portfolio.

Activities

Outputs

1.1

Define goals and metrics.

  • Set short- and long-term goals and metrics.
1.2

Define application categories.

  • Set the scope for applications.
1.3

Determine steps and roles.

  • Set the scope for the APM process.
1.4

Weight value drivers.

  • Defined business value drivers.

Module 2: Improve Your Inventory

The Purpose

  • Gather information on your applications to build a detailed inventory and identify areas of redundancy.

Key Benefits Achieved

  • Populated inventory based on your and your team’s current knowledge.
  • Understanding of outstanding data and a plan to collect it.

Activities

Outputs

2.1

Populate inventory.

  • Initial application inventory
2.2

Assign business capabilities.

  • List of areas of redundancy
2.3

Review outstanding data.

  • Plan to collect outstanding data

Module 3: Gather Application Information

The Purpose

Work with the application subject matter experts to collect and compile data points and determine the appropriate disposition for your apps.

Key Benefits Achieved

  • Dispositions for individual applications
  • Application rationalization framework

Activities

Outputs

3.1

Assess business value.

  • Business value score for individual applications
3.2

Assess end-user perspective.

  • End-user satisfaction scores for individual applications
3.3

Assess TCO.

  • TCO score for individual applications
3.4

Assess technical health.

  • Technical health scores for individual applications
3.5

Assess redundancies.

  • Feature-level assessment of redundant applications
3.6

Determine dispositions.

  • Assigned dispositions for individual applications

Module 4: Gather, Assess, and Select Dispositions

The Purpose

  • Work with application delivery specialists to determine the strategic plans for your apps and place these in your portfolio roadmap.

Key Benefits Achieved

  • Prioritized initiatives
  • Initial application portfolio roadmap
  • Ongoing structure of APM

Activities

Outputs

4.1

Prioritize initiatives

  • Prioritized new potential initiatives.
4.2

Populate roadmap.

  • Built an initial portfolio roadmap.
4.3

Determine ongoing APM cadence.

  • Established an ongoing cadence of APM activities.
4.4

Build APM action plan.

  • Built an action plan to complete APM activities.

Application Portfolio Management Foundations

Ensure your application portfolio delivers the best possible return on investment.

Analyst Perspective

You can’t outsource accountability.

Many enterprises place little to no emphasis on managing their application portfolio, often due to a perceived need to focus on solely on operations and at the cost of strategic efforts.

Inevitably, application sprawl puts any organization in a position where they have more applications than they need, can afford, or can adequately support. Abandoning strategic competencies only adds to the high demands of keeping the lights on.

Others believe business managed or purchased applications do not warrant the same demand for governance or strategic oversight.

You can outsource development, you can even outsource maintenance, but you cannot outsource accountability for the portfolio. Someone needs to capture the holistic picture to determine if an application’s value is worth its cost and if the application does not have overt risk.

Ben Mackle

Senior Research Analyst, Small Enterprises

Info-Tech Research Group

Build your APM journey map

The image is a graphic depicting 3 nested blue semi-circles, with arrows pointing vertically and horizontally on the outside of the graphic. The vertical line is labelled Value to the Business, and the horizontal line is labelled Rigor of APM Practice. The smallest section is labelled 1 - Discover, and includes the note: APM Snapshot - Assess your app portfolio. The middle section is labelled 2 - Rationalize, and includes the note: Enterprise APM - Scape APM to your enterprise. The largest section is labelled 3- Modernize. A note at the top of the graphic reads: APM Foundations helps you discover, rationalize, and modernize your key applications in three easy-to-follow steps.

APM Foundations

  • Step 0: APM Snapshot (optional)
    • Application Portfolio Snapshot: Determine where APM is most needed (capabilities, business areas or functions, customer groups) and build a case for your APM program.
  • Steps 1-3: Application Portfolio Management Foundations
    • APM Foundations: Ensure your application portfolio delivers the best possible return on investment.

Enterprise APM

  • Step 1: Complete APM Foundations Above
    • Consider starting with APM Snapshot to build your case or determine where application rationalization can provide the most immediate value.
    • Use APM Foundations to start rationalization and modernization for your most important applications or highest need areas before expanding to enterprise APM.
  • Step 2: Rationalize Your Applications
  • Step 3: Modernize Your Applications
    • Modernize Your Applications: Modernize your application portfolio using business and technical perspectives. Build your communication strategy and presentation.

Is this research right for you?

Research Navigation

Managing your application portfolio is essential regardless of its size or whether your software is purchased or developed in house. Each organization must have some degree of application portfolio management to ensure that applications deliver value efficiently and that their risk or gradual decline in technical health is appropriately limited.

Your APM Goals If this describes your primary goal(s)
  • We are building a business case to determine where and if APM is needed now.
  • We want to understand how well supported are our business capabilities, departments, or core functions by our current applications.
  • We want to start our APM program with our core or critical applications.
  • We want to build our APM inventory for less than 150 applications (division, department, operating unit, government, small enterprise, etc.).
  • We want to start simple with a quick win for our 150 most important applications.
  • We want to start with an APM pilot before committing to an enterprise APM program.
  • We need to rationalize potentially redundant and underperforming applications to determine which to keep, replace, or retire.
  • We want to start enterprise APM, with up to 150 critical applications.
  • We want to collect and analyze detailed information about our applications.
  • We need tools to help us calculate TCO and value.
  • We want to customize our APM journey and rationalization.
  • We want to build a formal communication strategy for our APM program

Executive Summary

Your Challenge

  • Organizations consider application oversight a low priority and app portfolio knowledge is poor.
  • No dedicated or centralized effort to manage the app portfolio means no single source of truth is available to support informed decision making.
  • Organizations acquire more applications over time, creating redundancy, waste, and the need for additional support.
  • Organizations are more vulnerable to changing markets. Flexibility and growth is compromised when applications are unadaptable or cannot scale.

Common Obstacles

  • APM implies a holistic approach and compiling multiple priorities and perspectives.
  • Organizations have limited time to act strategically or proactively and need to be succinct.
  • Uncertainties on business value prevent IT from successfully advising software decision making.
  • IT knows its technical debt but struggles to get the business to act on technical risks.
  • Attempts at exposing these problems rarely gain buy-in and discourage the push for improvement.

Info-Tech's Approach

  • Think low priority over no priority.
  • Integrate these tasks into your mixed workload.
  • Create an inventory built for better decision making.
  • Rationalize your apps in accordance with business priorities and communicate risks on their terms.
  • Create a roadmap that improves communication between those who own, manage, and support an application.
  • Build your APM process fit for size.

Info-Tech Insight: You can’t outsource strategy.

Modern software options have decreased the need for organizations to have robust in-house application management capabilities. Your applications’ future and governance of the portfolio still requires a centralized IT oversight to ensure the best return on investment.

Every organization experiences some degree of application sprawl

Application Sprawl:

Inefficiencies within your application portfolio are created by the gradual and non-strategic accumulation of applications.

“You have more apps than you need.”

Only 34% of software is rated as both important and effective by users. (Info-Tech’s CIO Business Vision)

Causes of Sprawl

Poor Lifecycle Management

Turnover & a Lack of Knowledge Transfer

Siloed Business Units & Decentralized IT

Business Managed IT (Shadow IT)

Mergers & Acquisitions

Problems With Sprawl

Redundancy and Inefficient Spending

Disparate Apps & Data

Obsolescence

Difficulties in Prioritizing Support

Barriers to Change & Growth

The top IT challenges for SE come from app management

Having more applications than an organization needs means unnecessarily high costs and additional burden on the teams who support the applications. Especially in the case of small enterprises, this is added pressure the IT team cannot afford.

A poorly maintained portfolio will eventually hurt the business more than it hurts IT.

Legacy systems, complex environments, or anything that leads to a portfolio that can’t adapt to changing business needs will eventually become a barrier to business growth and accomplishing objectives. Often that blame is put on the IT department.

56% of small businesses cited inflexible technology as a barrier for growth (Salesforce as quoted by Tech Republic, 2019)

#1 challenge small enterprise owners face in their use of technology:
Taking appropriate security precautions 24%
The costs of needed upgrades to technology 17%
Time it takes to fix problems 17%
The cost of maintaining technology 14%
Lack of expertise 9%
Breaks in service 7%

(National Small Business Association, 2019)

The hidden and inefficient application portfolio is the root cause of so many pains experienced by both IT and the business.

  • Demand/Capacity Imbalance
  • Overspending
  • Security and Business Continuity Risk
  • Delays in Delivery
  • Barriers to Growth

APM allows you to better understand and set the direction of your portfolio

Application Portfolio Management (APM):

The ongoing practice of:

  • Providing visibility into applications across the organization.
  • Recommending corrections or enhancements to decision makers.
  • Aligning delivery teams on priority.
  • Showcasing the direction of applications to stakeholders.

Application Alignment

The process of revealing application information through interviewing stakeholders and aligning to business capabilities.

Application Rationalization

The process of collecting information and assessing your applications to determine recommended dispositions.

Application Inventory

The artifact that documents and informs the business of your application portfolio.

Application Roadmap

The artifact that showcases the strategic directions for your applications over a given timeline.

Build your APM maturity by taking the right steps at the right time

Info-Tech’s Build an Application Rationalization Framework provides additional TCO and value tools to help build out your portfolio strategy.

The image is a graphic showing 3 nested semi-circles in light blue, yellow, and dark blue. On the outside of the graphic are a vertical arrow pointing upwards labelled Value to the Business and a horizontal arrow pointing right labelled APM Maturity. Cutting through the semi-circle sections is an orange diagonal line, with the text Application Alignment in the smallest section, and Rationalization and Roadmapping in the middle and largest sections. The smallest section is labelled Discover, the middle section labelled Improve, and the largest section labelled Transform.

The core activity of APM is application rationalization

The image is a graphic with the following text at the top left: Directionless portfolio of application. Underneath that text are a large collection of randomly placed squares with the word App written in them. In the middle of the graphic is the text Info-Tech's Five Lens Model, and underneath that five circles, with the following text from left to right: Application Alignment; Business Value, TCO, End-user Perspective, Technical Health. On the right hand of the image is the text Assigned dispositions for individual apps. Underneath that text are 4 squares with the word app in them, arranged in a list format, under the categories Maintain, Modernize, Consolidate, and Retire.

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.

APM comes at a justified cost

The benefits of APM

Return on investment (ROI) is experienced by the reduction in the number of applications and operational costs. But other benefits can include:

  • Reduce redundancies
  • Reduce risk
  • Reduce complexity
  • Improve processes
  • Enable flexibility
  • Enable scalability

The image is a bar graph, with Cost on the Y-axis and Time on the X-axis. There are two bars: Before Rationalization and After Rationalization. The bars are split into sections. The Before Rationalization bar is in two sections: the largest is Cost of Existing Portfolio and a smaller section New Initiatives. The After Rationalization bar is split into 3 categories: a large section labelled Cost of Future Portfolio; a medium-sized section labelled New Initiatives; and a smaller section labelled Cost of APM. The After Rationalization bar is overall smaller than Before Rationalization. At the bottom right of the graph is the text: Adapted from LeanIX, 2017.

Executive Brief Case Study

INDUSTRY - Retail

SOURCE - Deloitte

Supermarket Company

The grocer was a smaller organization for the supermarket industry with a relatively low IT budget. While its portfolio consisted of a dozen applications, the organization still found it difficult to react to an evolving industry due to inflexible and overly complex legacy systems.

The IT manager found himself in a scenario where he knew the applications well but had little awareness of the business processes they supported. Application maintenance was purely in keeping things operational, with little consideration for a future business strategy.

As the business demanded more responsiveness to changes, the IT team needed to be able to react more efficiently and effectively while still securing continuity of the business.

The IT manager found success by introducing APM and gaining a better understanding of the business use and future needs for the applications. The organization started small but then increased the scope over time to produce and develop techniques to aid the business in meeting strategic goals with applications.

Results

The IT manager gained credibility and trust within the organization. The organization was able to build a plan to move away from the legacy systems and create a portfolio more responsive to the dynamic needs of an evolving marketplace.

The Application Portfolio Management Initiative included the following components:

Train teams and stakeholders on APM

Model the core business processes

Collect application inventory

Assign APM responsibilities

Start small, then grow

Info-Tech’s methodology for Small Enterprise APM

1. Lay Your Foundations 2. Improve Your Inventory 3. Rationalize Your Apps 4. Populate Your Roadmap
Phase Activities

1.1 Assess Your Portfolio

1.2 Define Goals and Metrics

1.3 Define Application Categories

1.4 Determine Steps and Roles

1.5 Weight Value Drivers

2.1 Populate Inventory

2.2 Assign to Business Capabilities

2.3 Review Outstanding Data

3.1 Assess Business Value

3.2 Assess End-User Perspective

3.3 Assess TCO

3.4 Assess Technical Health

3.5 Assess Redundancies

3.6 Determine Dispositions

4.1 Prioritize Initiatives

4.2 Populate Roadmap

4.3 Determine Ongoing APM Cadence

Phase Outcomes

Work with the appropriate management stakeholders to:

  • Extract key business priorities
  • Set your goals
  • Agree on key terms and set the scope for your APM effort
Gather information on your own understanding of your applications to build a detailed inventory and identify areas of redundancy. Work with application subject matter experts to collect and compile data points and determine the appropriate disposition for your apps. Work with application delivery specialists to determine the strategic plans for your apps and place these in your portfolio roadmap.

Blueprint deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals.

Key deliverable:

Blueprint Storyboard

This is the PowerPoint document you are viewing now. Follow this guide to understand APM and how to use the tools, and build a repeatable APM process captured in your playbook.

Application Portfolio Management Foundations Playbook

This template allows you to capture your APM roles and responsibilities and build a repeatable process.

Application Portfolio Management Foundations Tool

This tool stores all relevant application information and allows you to execute rationalization and build a portfolio roadmap.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

"Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track."

Workshop

"We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place."

Consulting

"Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project."

Diagnostics and consistent frameworks are used throughout all four options.

Guided Implementation

What does a typical GI for on this topic look like?

Phase 1

Call #1: Establish goals and foundations for your APM practice.

Phase 2

Call #2: Initiate inventory and determine data requirements.

Phase 3

Call #3: Initiate rationalization with group of applications.

Call #4: Review result of first iteration and perform retrospective.

Phase 4

Call #5: Initiate your roadmap and determine your ongoing APM practice.

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our right-sized best practices in your organization.

A typical GI, using our materials, is between 4 to 6 calls over the course of 2 to 3 months.

Workshop Overview

Contact your account representative for more information.

workshops@infotech.com 1-888-670-8889

Day 1Day 2Day 3Day 4Day 5
Activities

1. Lay Your Foundations

1.2 Define Goals and Metrics

1.3 Define Application Categories

1.4 Determine Steps and Roles

1.5 Weight Value Driers

2. Improve Your Inventory

2.1 Populate Inventory

2.2 Assign to Business Capabilities

2.3 Review Outstanding Data

3. Rationalize Your Applications

3.1 Assess Business Value

3.2 Assess End-User Perspective

3.3 Assess TCO

3.4 Assess Technical Health

3.5 Assess Redundancies

3.6 Determine Dispositions

4. Populate Your Roadmap

4.1 Prioritize Initiatives

4.2 Populate Roadmap

4.3 Determine Ongoing APM Cadence

4.4 Build APM Action Plan

Next Steps and Wrap-Up (offsite)

5.1 Complete in-progress deliverables from previous four days.

5.2 Set up review time for workshop deliverables and to discuss next steps.

Outcomes

Work with the appropriate management stakeholders to:

  1. Extract key business priorities
  2. Set your goals
  3. Agree on key terms and set the scope for your APM effort

Work with your applications team to:

  1. Build a detailed inventory
  2. Identify areas of redundancy
  3. Understand outstanding data points needed for your inventory

Work with the SMEs for a subset of applications to:

  1. Collect and compile data points for different rationalization criteria
  2. Determine the appropriate disposition for your apps

Work with application delivery specialists to:

  1. Prioritize new potential initiatives
  2. Build an initial portfolio roadmap
  3. Build an action plan to complete APM activities
  4. Establish an ongoing cadence of APM activities

Info-Tech analysts complete:

  1. Workshop report
  2. APM Snapshot and Foundations Toolset
  3. Action plan

Blueprint Pre-Step: Get the right stakeholders to the right exercises

  1. Lay Your Foundations

  2. Improve Your Inventory

  3. Rationalize Your Apps

  4. Populate Your Roadmap

Recommended APM Lead

  • Applications Lead or the individual responsible for application portfolio management, along with any applications team members if available

Key Corporate Stakeholders

Depending on size and structure, participants could include:

  • Head of IT (CIO, CTO, IT Director, or IT Manager)
  • Head of shared services (CFO, COO, VP HR, etc.)
  • Compliance Officer, Steering Committee
  • Company owner or CEO

Application Subject Matter Experts

Individuals who have familiarity with a specific subset of applications.

  • Business owners (product owners, Head of Business Function, power users)
  • Support owners (Operations Manager, IT Technician)

Delivery Leads

  • Development Managers
  • Solution Architects
  • Project Managers

Phase 1

Lay Your Foundations

Phase Participants

  • Applications Lead
  • Key Corporate Stakeholders

Additional Supporting Resources

Review the different motivations of APM

What has instigated the need for an improved APM initiative?

Portfolio Governance

Improves:

  • Spending efficiency
  • Risk
  • Retirement of aged and low-value applications
  • Business enablement

Impact on your rationalization framework:

  • Less urgent
  • As rigorous as appropriate
  • Apply in-depth analysis as needed

Transformative Initiatives

Enables:

  • Data migration or harmonization
  • Legacy modernization
  • Infrastructure/cloud migration
  • Standardizing platforms

Impact on your rationalization framework:

  • Time sensitive
  • Scope on impacted areas
  • Need to determine specific dispositions
  • Outcomes need to include detailed and actionable steps

Event-Driven Rationalization

Responds to:

  • Mergers and acquisitions
  • Regulatory and compliance change

Impact on your rationalization framework:

  • Time constrained
  • Lots of discovery work
  • Primary focus on duplication

Different motivations will influence the appropriate approach and urgency of APM, or specifically, rationalizing the portfolio. When rationalizing is directly related to enabling or in response to a broader initiative, you will need to create a more structured approach with a formal budget and resources.

APM supports many goals

Building an APM process requires a proper understanding of the underlying business goals and objectives of your organization’s strategy. Effectively identifying these drivers is paramount to gaining buy-in and the approval for any changes you plan to make to your application portfolio.

After identifying these goals, you will need to ensure that they are built into the foundations of your APM process.

What is most critical?” but also “What must come first?

Discover

  • Collect Inventory
  • Uncover Shadow IT
  • Uncover Redundancies
  • Anticipate Upgrades
  • Predict Retirement

Improve

  • Reduce Cost
  • Increase Efficiency
  • Reduce Applications
  • Eliminate Redundancy
  • Limit Risk

Transform

  • Improve Architecture
  • Modernize
  • Enable Scalability
  • Drive Business Growth
  • Improve UX

1.1 Assess your current application portfolio with Info-Tech’s diagnostic tool

Input

  • Current APM program
  • Application landscape

Output

  • APM current state assessment

Materials

  • Application Portfolio Management Diagnostic Tool

Participants

  • Applications Lead

Estimated Time: 1 Hour

  1. This tool provides visibility into your application portfolio and APM practices.
  2. Based on your assessment, you should gain a better understanding of whether the appropriate next steps are in application discovery, rationalization, or roadmapping.
  3. Complete the “Data Entry” worksheet in the Application Portfolio Management Diagnostic Tool (Excel).
  4. Review the “Results” worksheet to help inform and guide your next steps.

Download the Application Portfolio Management Diagnostic Tool

1.1 Assess your current application portfolio with Info-Tech’s diagnostic tool

The image is 4 separate graphics, showing an examples of Info-Tech's diagnostic tool.

Portfolio Visibility - Estimate the extent of your shadow IT problem

Application Sprawl Factors - Identify the contributing factors to application sprawl

Application Information - Identify what information you are lacking

Application Portfolio Management State - Determine the current state of your APM practice

1.2 Define goals and metrics

Input

  • Overarching organizational strategy
  • IT strategy

Output

  • Defined goals and metrics for APM

Materials

  • Whiteboard
  • Markers
  • APM Snapshot and Foundations Tool

Participants

  • Applications Lead
  • Key Corporate Stakeholders

Estimated Time: 1 Hour

  1. Determine the motivations behind APM. You may want to collect and review any of the organization’s strategic documents that provide additional context on previously established goals.
  2. With the appropriate stakeholders, discuss the goals of APM. Try to label your goals as either:
    1. Short term: In this context, refers to more immediate goals used to represent the progress of APM activities. Likely these goals are more IT oriented.
    2. Long term: In this context, refers to broader and more distant goals more related to the impact of APM. These goals tend to be more business oriented.
  3. To help clearly define your goals, discuss appropriate metrics for each goal. Often these metrics can be expressed as:
    1. Leading indicators: Metrics used to gauge the success of your short-term goals and the progress of APM activities.
    2. Lagging indicators: Metrics used to gauge the success of your long-term goals.

Record the results in the APM Snapshot and Foundations Tool

1.2 Define goals and metrics: Example

Goals Metric Target
Short Term Improve ability to inform the business Leading Indicators
  • Application inventory with all data fields completed
  • Applications with recommended dispositions
  • 80% of portfolio
Improve ownership of applications
  • Applications with an assigned business and technical owner
  • 80% of portfolio
Reduce costs of portfolio
  • TCO of full application portfolio
  • The number of recovered/avoided software licenses from retired apps
  • Reduce by 5%
  • $50,000

Long Term

Migrate platform Lagging Indicators
  • Migrate all applications
  • Total value change in on-premises apps switched to SaaS
  • 100% of applications
  • Increase 50%
Improve overall satisfaction with portfolio
  • End-user satisfaction rating
  • Increase 25%
Become more “customer-centric”
  • Increased sales
  • Increased customer experience
  • Increase 35%

“Application” doesn’t have the same meaning to everyone

APM focuses on business applications

Software used by business users to perform a business function.” (ServiceNow, 2020)

Unfortunately, that definition is still quite vague.

Essentially applications are social constructions.” (Martin Fowler)

Code

A body of code that's seen by developers as a single unit.

Functionality

A group of functionality that business customers see as a single unit.

Funding

An initiative that those with the money see as a single budget.

What else?

You must set boundaries and scope for “application”

1. Many individual items can be considered an application on their own or a component within or associated with an application.

Apps can be categorized by aspects of your architecture or tech stack

  • Interface
  • Presentation Layer
  • UI
  • Software Component
  • Middleware
  • API
  • Supporting Software
  • Micro Service
  • Data Access/Transfer/Load
  • Platform
  • Database
  • Operating System

Apps can be categorized by the application family

  • Parent Application
  • Package
  • Suite
  • Child Application
  • Module
  • Component (Functional)

2. Different categories of applications may be out of scope or handled differently within the activities and artifacts of APM.

Apps can be categorized by generic categories

  • Enterprise Applications
  • Productivity Tools
  • Customer-Facing Applications
  • Mobile Applications
  • Unique Function-Specific Applications

Apps can be categorized by bought vs. built or install types

  • Custom
  • Off the Shelf
  • Hybrid
  • On-Prem
  • SaaS
  • End-User-Built Tools

Apps can be categorized by management group

  • IT Managed Applications
  • Business Managed Applications (Shadow IT)
  • Partner/External Applications

Apps can be categorized by tiers

  • Mission Critical
  • Tier 2
  • Tier 3

Set boundaries on what is an application or the individual unit that you’re making business decisions on. Also, determine which categories of applications are in scope and how they will be included in the activities and artifacts of APM.

1.3 Define application categories

Input

  • Working list of applications

Output

  • Definitions and guidelines for which application categories are in scope for APM

Materials

  • Whiteboard and markers
  • APM Snapshot and Foundations Tool

Participants

  • Applications Lead
  • Key Corporate Stakeholders

Estimated Time: 1 Hour

  1. Define a business application. Reviewing the items listed on the previous slide, consider what systems should not be considered a “business application” on their own and may deserve their own category.
  2. Identify the additional categories you need to manage in your application portfolio.
  3. For each category, establish or modify a description or definition and provide examples that exist in your current portfolio.
  4. For each category, answer:
    1. Will these be documented in the application inventory?
    2. Will these be included in application rationalization? Think about if this item will be assigned a TCO, value score, and ultimately, a disposition.
    3. Will these be listed in the application portfolio roadmap?

Include any additional notes to further clarify scope and guidelines.

If you completed Deliver Digital Products at Scale, use your product families to help define your application categories.

1.3 Define application categories: Example

Category Definition/Description Examples Documented in your application inventory? Included in application rationalization? Listed in your application portfolio roadmap?
Business Application End-user facing applications that directly enable specific business functions. This includes enterprise-wide and business-function-specific applications. Separate modules will be considered a business application when appropriate. ERP system, CRM software, accounting software Yes Yes. Unless currently in dev. TCO of the parent application will be divided amongst child apps. Yes
Software Components Back-end solutions are self-contained units that support business functions. ETL, middleware, operating systems No. Documentation in CMDB. These will be listed as a dependency in the application inventory. No. These will be linked to a business app and included in TCO estimates and Tech Health assessments. No
Productivity Tools End-user-facing applications that enable standard communication of general document creation. MS Word, MS Excel, corporate email Yes No Yes
End-User- Built Microsoft Tools Single instances of an MS tool that the business has grown dependent on. Payroll Excel tool, Access databases No. Documentation in Business Tool Glossary. No No
Partner Applications Partners or third-party applications that the business has grown dependent on, but internally owned or managed. Supplier’s ERP portal, government portal No No Yes
Shadow IT Business-managed applications. Downloaded tools Yes Yes. However, just from a redundancy perspective. Yes

The roles in APM rarely exist; you need to adapt

Application Portfolio Manager

  • Responsible for the health and evolution of the application portfolio.
  • Facilitates the rationalization process.
  • Compiles and assesses application information and recommends and supports key decisions regarding the direction of the applications.
  • This is rarely a dedicated role even in large enterprises. For small enterprises, this should be an IT employee at a manager level – an IT manager or operations manager.

Support Owner

  • Responsible for the maintenance and management of individual applications.
  • Provides technical information subject matter expertise for the assessment of an application.
  • For small enterprises, this would be those responsible for maintaining the application and those responsible for its initial implementation. Often support responsibilities are external, and this role will be more of a vendor manager.

Business Owner

  • Responsible for managing individual applications on a functional level and approves and prioritizes projects.
  • Provides business process or functional subject mater expertise for the assessment of applications.
  • For small enterprises, this role is rarely defined, but the responsibility should exist. Consider the head of a business unit or a process owner as the owner of the application.

Project Portfolio Manager

  • Responsible for intake, planning, and coordinating the resources that deliver any changes.
  • The body that consumes the results of rationalization and begins planning any required action or project.
  • For small enterprises, the approval process can come from a steering committee but is often less formal. Often a smaller group of project managers facilitates planning and coordination and works closely with the delivery leads.

Corner-of-the-Desk Approach

  • No one is explicitly dedicated to building a strategy or APM practices.
  • Information is collected whenever the application team has time available.
  • Benefits are pushed out and the value is lost.

Dedicated Approach

  • The initiative is given a budget and formal agenda.
  • Roles and responsibilities are assigned to team members.

The high-level steps of APM present some questions you need to answer

Build Inventory

Create the full list of applications and capture all necessary attributes.

  • Who will build the inventory?
  • Do you know all your applications (Shadow IT)?
  • Do you know your applications’ functionality?
  • Do you know where your applications overlap?
  • Who do you need to consult with to fill in the gaps?
  • Who will provide specific application information?

Collect & Compile

Engage with appropriate SMEs and collect necessary data points for rationalization.

  • Who will collect and compile the necessary data points for rationalization?
  • What are the specific data points?
  • Are some of the data points currently documented?
  • Who will provide specific data points on technical health, cost, performance, and business value?
  • Who will determine what business value is?

Assess & Recommend

Apply rationalization framework and toolset to determine dispositions.

  • Who will apply a rationalization tool or decision-making framework to generate dispositions for the applications?
  • Who will modify the tool or framework to ensure results align to the goals of the organization?
  • Who will define any actions or projects that result from the rationalization?
  • And who needs to be consulted to assess the feasibility of any potential project?

Validate & Roadmap

Present dispositions for validation and communicate any decisions or direction for applications.

  • Who will present the recommended disposition, corrective action, or new project to the appropriate decision maker?
  • Who is the appropriate decision maker for application changes or project approval?
  • What format is recommended (idea, proposal, business case) and what extra analysis is required?
  • Who needs to be consulted regarding the potential changes?

1.4 Determine steps and roles (SIPOC)

Input

  • Existing function and roles regarding application delivery, management, and ownership

Output

  • Scope of APM
  • Responsibilities assigned to your roles

Materials

  • Whiteboard and markers
  • APM Snapshot and Foundations Tool

Participants

  • Applications Lead
  • Key Corporate Stakeholders

Estimated Time: 1 Hour

  1. Begin by comparing Info-Tech’s common roles of APM to the roles that exist in your organization with respect to application management and ownership.
  2. There are four high-level steps for APM: build inventory, collect & compile, assess & recommend, and validate & roadmap. Apply the SIPOC (Supplier, Input, Process, Output, Customer) model by completing the following for each step:
    1. In the Process column, modify the description, if necessary. Identify who is responsible for performing the step.
    2. In the Inputs column, modify the list of inputs (materials, knowledge, etc.).
    3. In the Suppliers column, identify who must be included to provide the inputs.
    4. In the Outputs column, modify the list of outputs (materials, artifacts, results, outcomes, etc.).
    5. In the Customers column, identify who must be included to provide the inputs.
  3. (Optional) Add one last step outlining how the results of APM will be consumed. For example, project intake or execution, data or platform migration, application or product management, or whichever is appropriate.

1.4 Determine steps and roles

Suppliers Inputs Process Outputs Customers
  • Applications Manager
  • Operations Manager
  • Business Owners
  • IT Team
  • List of applications
  • Application attributes
  • Business capabilities

Build Inventory

Create the full list of applications and capture all necessary attributes.

Resp: Applications Manager & IT team member

  • Application inventory
  • Identified redundancies
  • Whole organization
  • Applications SMEs
  • Business Owners
  • Support Owners & Team
  • End Users
  • Application inventory
  • Existing documentation
  • Additional collection methods
  • Knowledge of business value, cost, and performance for each application

Collect & Compile

Engage with appropriate SMEs and collect necessary data points for rationalization.

Resp: IT team member

  • Data points of business value, cost, and performance for each application
  • Applications Manager
  • Applications Manager
  • Defined application rationalization framework and toolset
  • Data points of business value, cost, and performance for each application

Assess & Recommend

Apply rationalization framework and toolset to determine dispositions.

Resp: Applications Manager

  • Assigned disposition for each application
  • New project ideas for applications
  • Business Owners
  • Steering Committee
  • Business Owners
  • Steering Committee
  • Assigned deposition for each application
  • New project ideas for applications
  • Awareness of goals and priorities
  • Awareness of existing projects and resources capacity

Validate & Roadmap

Present dispositions for validation and communicate any decisions or direction for applications.

Resp: Applications Manager

  • Application portfolio roadmap
  • Confirmed disposition for each application
  • Project request submission
  • Whole organization
  • Applications Manager
  • Solutions Engineer
  • Business Owner
  • Project request submission
  • Estimated cost
  • Estimated value or ROI

Project Intake

Build business case for project request.

Resp: Project Manger

  • Approved project
  • Steering Committee

Assessing application business value

In this context… business value is the value of the business outcome that the application produces. Additionally, how effective the application is at producing that outcome.

Business value IS NOT the user’s experience or satisfaction with the application.

Business Value of Applications

  • The Business
    • Keepers of the organization’s mission, vision, and value statements that define IT success. The business maintains the overall ownership and evaluation of the applications.
  • IT
    • Technical subject matter experts of the applications they deliver and maintain. Each IT function works together to ensure quality applications are delivered to stakeholder expectations.

First, the authorities on business value need to define and weigh their value drivers that describe the priorities of the organization.

This will then allow the applications team to apply a consistent, objective, and strategically aligned evaluation of applications across the organization.

Review the value drivers of your applications

Business Value Matrix

The business value matrix indicates that increasing revenue or delivering value is an outward financial benefit, while reducing costs is an inward financial benefit. Reaching customers is an outward human benefit, while enhancing services is an inward human benefit.

Financial vs. Human Benefits

Financial benefits refer to the degree to which the value source can be measured through monetary metrics and are often quite tangible.

Human benefits refer to how an application can deliver value through a user’s experience.

Inward vs. Outward Orientation

Inward refers to value sources that have an internal impact and improve your organization’s effectiveness and efficiency in performing its operations.

Outward refers to value sources that come from your interaction with external factors, such as the market or your customers.

Perceived business benefits from using digital tools

  1. Increase Sales and Revenue (38%)
  2. Promote Brand Awareness (31%)
  3. Access New Customers (30%)
  4. Connect with Customers (30%)
  5. Improve External Communication (29%)
  6. Improve Internal Communication (20%)
  7. Target Market Segments (20%)
  8. Improve Business Flexibility (18%)
  9. Compete With Larger Businesses (17%)
  10. Streamline Sales and Lead Generation (13%)
  11. Lower Business Costs (12%)
  12. Support Innovation (9%)

Increased Revenue

Application functions that are specifically related to the impact on your organization’s ability to generate revenue and deliver value to your customers.

Reduced Costs

Reduction of overhead. The ways in which an application limits the operational costs of business functions.

Enhanced Services

Functions that enable business capabilities that improve the organization’s ability to perform its internal operations.

Reach Customers

Application functions that enable and improve the interaction with customers or produce market information and insights.

1.5 Weigh value drivers

Input

  • Knowledge of organizational priorities
  • (Optional) Existing mission, vision, and value statements

Output

  • Scoring scheme for assessing business value

Materials

  • Whiteboard and markers
  • APM Snapshot and Foundations Tool

Participants

  • Applications Lead
  • Key Corporate Stakeholders

Estimated Time: 1 Hour

  1. Review Info-Tech’s four quadrants of business value: increase revenue, reduce costs, enhance services, and reach customers. If appropriate, adapt this language to meet your organization’s orientation. For example, government organizations often use obtain funding or reach public.
  2. (Optional) Add an additional value driver if your organization has distinct value drivers. For example, compliance, sustainability, innovation, and growth.
  3. For each value driver, provide some examples of key indictors specific to your organization’s priorities.
  4. For each value driver, weigh it on a scale of 1 to 5 based on its relative importance to the organization. Aim to have some variance in the weighting of the value drivers.

Download the APM Snapshot and Foundations Tool

1.5 Weigh value drivers: Example

Example:

Value Driver Weight

Generate Revenue

  • Financial results
  • Higher profit margins
  • Improve cash flow
5

Reduce Costs

  • Improve operational efficiency
  • Minimize problems or stoppages
  • Minimize overhead
3

Enhance Services

  • Develop skills and knowledge
  • Increase collaboration
  • Increase innovation
2

Reach Customers

  • Provide direct value to customer
  • Improve customer experience
  • Provide customer insights
4

Abide Compliance

  • Align to regulations
  • Build trust and reputation
  • Mitigate risk of audit
2

How it gets applied via the balanced scorecard:

ERP Impact (Established by applications lead and consultations with business owners) Weight (Set by key corporate stakeholder) Weighted scores
Generate Revenue Very High – 5 5 25
Reduce Costs Very High – 5 3 15
Enhance Services Medium – 3 2 6
Reach Customers Medium – 1 4 4
Abide Compliance Very Low – 1 2 2
Balanced Score: 52
CRM Impact Weight Weighted scores
Generate Revenue Medium – 3 5 15
Reduce Costs Very Low – 1 3 3
Enhance Services Low – 2 2 4
Reach Customers Very High – 5 4 20
Abide Compliance Very High – 5 2 4
Balanced Score: 46

For additional support building and implementing a balanced value framework, download Build a Value Measurement Framework.

Phase 2

Improve Your Inventory

Phase Participants

  • Applications Lead
  • Applications Team

Additional Resources

Phase pre-step: Collect your applications

  1. Consult with your IT team and leverage any existing documentation to gather an initial list of your applications.
  2. Build an initial working list of applications. This is just meant to be a starting point. Aim to include any new applications in procurement, implementation, or development.
  3. Phases 3 and 4 (rationalization and road mapping) are best completed when iteratively focusing on manageable groups of applications. Group your applications into subsets based on shared subject matter experts. Likely this will mean grouping applications by business units.
  4. Select a subset to be the first group of applications that will undergo the activities of phases 3 and 4.

If you completed Deliver Digital Products at Scale, use your product families and products to help define your applications.

What information do you need to make available?

Foundational

  • Application name
  • Description
  • Criticality
  • Ownership
  • SMEs
  • Application specs
  • # of users
  • Vendor information
  • Capabilities

More examples in Appendix

Intended to inform stakeholders

Mostly captured though basic data collection methods or interviewing owners and SMEs.

Advanced

  • Redundancies
  • Total cost of ownership (TCO)
  • Business value
  • Performance
  • Risk
  • Dependencies

Intended to drive strategic decision making

Captured though deeper analysis and may require additional tools outside of an inventory.

Strategic

  • Lifecycle stage
  • Scheduled updates
  • Disposition/strategic direction
  • Planned of in-flight projects
  • Business case info

Intended to showcase application strategies

Captured and presented though planning activities; will require additional tools.

Info-Tech Best Practice

The more information you plan to capture, the larger the time and effort, especially as you move along toward advanced and strategic items. Capture the information most aligned to your objectives to make the most of your investment.

2.1 Populate your inventory

Input

  • Working list of applications

Output

  • Determined attributes for inventory
  • Populated inventory

Materials

  • APM Snapshot and Foundations Tool

Participants

  • Applications Lead
  • Any Applications Team Members
  1. Review Info-Tech’s list of application inventory attributes.
  2. Open the Application Inventory Details tab of the APM Snapshot and Foundations Tool. Modify, add, or omit attributes as appropriate in row 8.
  3. Add your working list of applications to column C.
  4. For each application, populate data fields in columns D-V (excluding business capability for now). Complete this as best as you can based on your, or your team’s, familiarity with or any readily available documentation related to these applications.

Why is the business capability so important?

For the purposes of an inventory, business capabilities help all stakeholders gain a sense of the functionality the application provides.

However, the true value of business capability comes with rationalization. Upon linking all the organization’s applications to a standardized and consistent set of business capabilities, you can then group your applications based on similar, complementary, or overlapping functionality. In other words, find your redundancies and consolidation opportunities.

Important Consideration

Defining business capabilities and determining the full extent of redundancy is a challenging undertaking and often is a larger effort than APM all together.

Business capabilities should be defined according to the unique functions and language of your organization, at varying levels of granularity, and ideally including target-state capabilities that identify gaps in the future strategy.

This blueprint provides a simplified and generic list for the purpose of categorizing similar functionality. We strongly encourage exploring Document Your Business Architecture to help in the business capability defining process, especially when visibility into your portfolio and knowledge of redundancies is poor.

Marketing (Business Unit)

  • Market Assessment (Business Capability)
    • Application A (Enabling Application)
  • Competitive Intelligence
    • Application A
  • Campaign Mgmt.
    • Application B
  • Collaboration
    • Application C
  • Customer Segmentation
    • Application D
  • Customer Experience Mgmt.
    • Application D

In this scenario, applications C and E and applications D and F have similar or overlapping functionality and should be made candidates for consolation.

Customer Mgmt.

  • Account Mgmt.
    • Application E
  • Analysis and Reporting
    • Application F
  • Customer Experience Mgmt.
    • Application F
  • Collaboration
    • Application E
    For a more detailed capability mapping, use the Application Portfolio Snapshot and the worksheets in your current workbook.

Why perform a high-level application alignment before rationalization?

Having to address redundancy complicates the application rationalization process. There is no doubt that assessing applications in isolation is much easier and allows you to arrive at dispositions for your applications in a timelier manner.

Rationalization has two basic steps: first, collect and compile information, and second, analyze that information and determine a disposition for each application. When you don’t have redundancy, you can analyze an application and determine a disposition in isolation. When you do have redundancies, you need to collect information for multiple applications, likely across departments or lines of business, then perform a comparative analysis.

Most likely your approach will fall somewhere between the examples below and require a hybrid approach.

Benefits of a high-level application alignment:

  • Review the degree of redundancy across your portfolio.
  • Understand the priority areas for rationalization and the sequence of information collection.

The image shows two lines, titled Portfolio without redundancies, and Portfolio with multiple redundancies. To the right of the titles, are multiple horizontal bars, in blue and orange. A legend indicates that the blue sections signify Collect Information, and the orange indicate Assign Disposition. In the Without Redundancies section, each horizontal bar has a large blue section and a smaller orange section. In the Multiple Redundancies section, there are 4 horizontal bars coloured completed in blue, and then a 5th coloured completely in orange. At the bottom of the graphic is an arrow pointing to the right, with the label Timeline of Rationalization Effort.

2.2 Align to business capabilities

Input

  • Application inventory
  • Any existing list of business capabilities or an Info-Tech Reference Architecture

Output

  • Assigned business capabilities to applications
  • Areas of redundancy

Materials

  • Whiteboard and markers
  • APM Snapshot and Foundations Tool

Participants

  • Applications Lead
  • Any Applications Team Members

1 hour

  1. If your organization has already defined a high-level set of capabilities, collect this information and use these for the following exercise.
  2. Review Info-Tech’s Industry Reference Architectures for example lists of business capabilities.
  3. Modify the language or adapt business capabilities as appropriate. Add a definition to the business capability to provide clarity. Create an initial list of business capabilities in your playbook, updating as you go.
  4. Open the APM Snapshot and Foundations Tool to the Application Inventory tab. For each application, align it to the high-level business capabilities that apply and document in column G. Complete this as best as you can based on your, or your team’s, familiarity with or any readily available documentation related to these applications.
  5. Note all instances of multiple applications supporting one business capability. These are potential redundancies and will be important information for phase 3.

2.2 Align to business capabilities example

Application Business Capability
CRM Customer Relationship Management
ERP

Warehouse Management

Distribution Management

Supply Chain Management

Finance Management

Microsoft Suite Productivity
HRIS Human Resources Management
Jabber Collaboration
Legacy

Workflow Management

Distribution Management

Excel Custom-Built App Finance Management
Adobe Product Design
Custom Data Tracker Operations Management
CRM 2 Customer Relationship Management
CRM 3 Customer Relationship Management

Area of redundancy #1

Customer Relationship Management
CRM 1
CRM 2
CRM 3

Area of redundancy #2

Distribution Management
ERP
Legacy

2.3 Review outstanding data

Input

  • Application inventory

Output

  • List of outstanding data points
  • Collection methods for outstanding data points

Materials

  • Whiteboard and markers
  • APM Snapshot and Foundations Tool

Participants

  • Applications Lead
  • Any Applications Team Members

30 minutes

  1. Upon an initial attempt at aligning your application to business capabilities and populating your application inventory, evaluate your, or your team's ability, to provide this information on your applications. For each attribute consider:
    1. Were you able to provide necessary data or information?
    2. Is that data up to date and accurate?
    3. If the answer for either 1) or 2) is no, determine what collection method or additional action will be applied to capture the data or information. This can include:
      • Basic validation with appropriate SMEs
      • Structured interviews with business owners (often integrated with the collection of application rationalization data points)
      • Surveys with owners, key users, or full user base
      • Structured interviews with technical SMEs
      • Consultation with vendors
      • Auto-discovery or system scanning tools
      • Business capability or process mapping initiative

2.3 Review outstanding data

Application Attribute Have you captured the data or information? Is the data or information up to date and accurate? Additional Steps or Collection Methods
Description Partially Partially Validate with business owners or vendors

Business Units

Yes Yes Validate with heads of business units
Business Capabilities No n/a Modify capabilities list with executive team, and interview business owners
Criticality Partially Uncertain Review BCP and validate with business owners
Ownership No n/a Assign “business owner” role to appropriate individuals
Application SMEs Informally Yes Inform SMEs of their role
Vendor Information Yes Yes Review contracts
Type Yes Yes No action necessary
Active Status Yes Yes No action necessary
Number of Users No n/a Interview business owners and consult with vendors
Software Dependencies No n/a Complete process mapping initiative
Hardware Dependencies Partially Interview solutions architect
Platform Yes Yes No action necessary

Phase 3

Rationalize Your Applications

Phase Participants

  • Applications Lead
  • Application SMEs

Additional Resources

Phase pre-step: Sequence rationalization assessments appropriately

Application rationalization requires an iterative approach.

  1. Review your application subsets from the Phase 2 pre-step. Review the areas of redundancies from exercise 2.2.
  2. Sequence the activities of phase 3 based on whether you have a:
    1. Highly Redundant Portfolio
      1. For each subset of applications iteratively complete exercises 3.1-3.5.
      2. Complete exercise 3.6.
      3. Complete exercise 3.7.
    2. Non-Redundant Portfolio
      1. For each subset of applications iteratively complete exercises 3.1-3.4 and 3.7.
    3. Moderately Redundant Portfolio
      1. Complete assessment of your application subsets that feature redundant apps first following “a)” instructions.
      2. Complete assessment of your application subsets that do not feature redundant apps second, following “b)” instructions.
The image shows two lines, titled Portfolio without redundancies, and Highly redundant portfolio. To the right of the titles, are multiple horizontal bars, in blue and orange. A legend indicates that the blue sections signify Collect Information, and the orange indicate Assign Disposition. In the Without Redundancies section, each horizontal bar has a large blue section and a smaller orange section. In the Multiple Redundancies section, there are 3 horizontal bars coloured completed in blue, and then a 4th coloured completely in orange. At the bottom of the graphic is an arrow pointing to the right, with the label Timeline of Rationalization Effort.

Phase pre-step: Are the right stakeholders present?

Application rationalization requires specific stakeholders to provide specific data points.

  1. Ensure your application subsets are grouped by shared subject matter experts. Ideally these are grouped by business units.
  2. For each subset, identify the appropriate SMEs for the five areas of rationalization criteria.
  3. Communicate and schedule interviews with groups of stakeholders. Inform them of additional information sources to have readily available.
  4. (Optional) This phase’s activities follow the clockwise sequence of the diagram to the right. Reorder the sequence of activities based on overlaps of availability in subject matter expertise.
  • Application Rationalization
    • Additional Information Sources:
      • KPIs
        • Ideal Stakeholders:
          • Business Value
          • Business Application/Product Owners
          • Business Unit/ Process Owners
      • Survey Results
        • Ideal Stakeholders:
          • End User
          • Business Application/Product Owners
          • Key/Power Users
          • End Users
      • General Ledger
      • Service Desk
      • Vendor Contracts
        • Ideal Stakeholders
          • TCO
          • Operations/Maintenance Manager
          • Vendor Managers
          • Finance & Acct.
      • Service Desk
      • ALM Tools
        • Ideal Stakeholders
          • Technical Health
          • Operations/ Maintenance Manager
          • Solution Architect
          • Security Manager Dev. Manager
      • Capability Maps
      • Process Maps
        • Ideal Stakeholders
          • Application Alignment
          • Business Unit/ Process Owners

The core outcome of rationalization is dispositions

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

On the left of the image is the title Directionless portfolio of applications, and beneath it, a collection of squares with the word app in them, arranged randomly, overlapping. On the right is the title Assigned Dispositions for individual apps, and the apps that were randomly arranged on the left and now sorted under 4 categories: Maintain, Modernize, Consolidate, and Retire.

Determine your dispositions using five key criteria

There are many lenses, or perspectives, to view your applications through. Rationalize your applications using a holistic understanding to determine the most beneficial direction or course of action.

Application Portfolio Manager

Business Value

  • Is the application producing sufficient business outcomes?
  • Does it impact profitability, enable capabilities, or add any critical factor that fulfills the mission and vision?
  • CEO Perspective

End User

  • How does the end user perceive the application?
  • What is the user experience?
  • Do the features adequately support the intended functions?
  • User Perspective

TCO

  • What is the overall cost of the application?
  • What is the projected cost as your organization grows?
  • What is the cost to maintain the application?
  • CFO Perspective

Technical Health

  • What is the state of the backend of the application?
  • Has the application maintained its quality?
  • Is the application reliable and secure?
  • How does it fit into your application architecture?
  • IT Perspective

Application Alignment

  • How well does the entire portfolio align to your business capabilities?
  • Are there overlaps or redundancies in your application features?
  • Covered in Application Portfolio Snapshot.
  • Architect Perspective

Application Portfolio

Apply Info-Tech’s 7 R’s Rationalization Disposition Model

The image shows a cube with 3 sides visible. Each side is segmented into 4 squares, each labelled one of: Retain; Reward; Retire; Remediate. On the front face of the cube, there are arrows running vertically and horizontally: the vertical line is labelled Technical Health, and the Horizontal Line is labelled Business Value. On the right face of the sphere, the horizontal arrow is labelled End-User Perspective. The arrangement of the squares differs on each visible face of the cube, and each face is colored differently.

Disposition Description Call to Action (Priority)

Reward

High Value High Health High Satisfaction

Prioritize new features or enhancement requests and openly welcome the expansion of these applications as new requests are presented. Process Initiative (Moderate)

Remediate

High Value Low Health High Satisfaction

Address the poor technical health or risk with a prioritized project. Further consult with development and technical teams to determine if migration or refactoring is suited to address the technical issue. Application Initiative (Very High)

Retain

Low Value High Health High Satisfaction

Potentially cancel or lower priority of new features and enhancement requests. Aim to "keep the lights on" and delay decommission if the app doesn’t present risk or high operational costs. Process Initiative (Very Low)

Retire

Low Value, Low Health. High or Low Satisfaction

Cancel any requested features and enhancements. Schedule proper decommission and transfer end users onto new or alterative system if necessary. Decommission (Low)

Refresh

High Value High Health Low Satisfaction

Address the poor end-user satisfaction with a prioritized project. Further consult with business owners to determine if UX issues require refactoring or retraining. Application Initiative (High)

Replace

High Value Low Health Low Satisfaction

Replace High Value Low Health Low Satisfaction Decommission & App Initiative (Very High)

Review

High Value High Health Low Satisfaction

Explore if the user issues are impacting the value. Potential App Initiative (Very low)

TCO, compared relatively to business value, helps 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.

Reduce subjectivity, increase consistency, and measure multiple kinds of value

Application’s Balanced Value Score

  • Increase Revenue (5)
    • Moderate (3)
      • Creates new accounts
      • Provides some revenue
  • Reduce Costs (2)
    • Low (1)
      • Automates account management
  • Enhance Services (2)
    • N/A (0)
      • No internal learning or growth
  • Reach Customer (3)
    • Very High (5)
      • Provides customer interaction Houses customer data

Business value can be ambiguous but is essential in making the right decisions for your apps.

The purpose of applying a balanced scorecard is to measure value using an approach that is:

  • Consistent
  • Less subjective
  • Aligned to business priorities

With the “authorities on business value” setting the weight and definition of your value drivers, you can now assess the value of individual applications.

3.1 Assess business value

Input

  • Weight of value drivers
  • Familiarity of business value for applications within this subset
  • KPIs

Output

  • Balanced value scores for each application

Materials

  • APM Snapshot and Foundations Tool

Participants

  • Business Owners
  • Applications Lead
  • Any Applications Team Members

30-60 minutes

  1. Open the Rationalization Inputs tab in the APM Snapshot and Foundations Tool. Carry over the value driver weights from exercise 1.4 into row 9, columns E-I.
  2. For each application, score on a scale of 0 to 5 how impactful the application is for each value driver. Use the indicators set in phase 1 to guide your scoring.
  3. Review outstanding application attributes from exercise 2.3. Use this opportunity to validate or collect specific data points from the business owners of the applications.

End users provide valuable perspective

The image is a pie chart, divided into 3 equal sections: Feel; Look; Usability.

Your end users are your best means of determining front-end issues.

SATISFACTION

Satisfaction refers to the sentiment your end users have with the features and functionality of the application. Do the features of the application function as intended? Does the application align to the business process it aims to support?

USABILITY

Usability refers to the level of ease and intuitiveness your end users have with the application’s user experience. Does the design of the application allow end users to perform their tasks with relative ease or minimal disruption?

Info-Tech Best Practice

When facing large user groups, do not make assumptions or use lengthy methods of collecting information. Use Info-Tech’s Application Portfolio Assessment to collect data by surveying your end users’ perspectives.

3.2 Assess end-user perspective

Input

  • Familiarity of end user’s perspective for applications within this subset

Output

  • User satisfaction scores for each application

Materials

  • APM Snapshot and Foundations Tool

Participants

  • Business Owners, Key Users
  • Applications Lead
  • Any Applications Team Members

30-60 minutes

  1. For each application, score on a scale of 1 to 5 how impactful the application is for:
    1. Satisfaction: How satisfied are end users with the features of this application?
    2. Usability: How satisfied are end users that this application is easy to use and reliable?
  2. Review outstanding application attributes from exercise 2.3. Use this opportunity to validate or collect specific data points from the key users of the applications.

Consider the spectrum of application cost

$

  • License
  • Fixes
  • Enhancements
  • Education
  • Peripherals

An app’s cost extends past a vendor’s fee and even the app itself.

LICENSING AND SUBSCRIPTIONS: Your recurring payments to a vendor. Many COTS applications require a license on a per-user basis. Review contracts and determine costs by looking at per-user or fixed rates charged by the vendor. Often these fees include support.

MAINTENANCE COSTS: Your internal spend to maintain an app. These stem from internal maintenance. Estimate these costs with past spend (salaries, wages, person hours worked) for your individual apps.

INDIRECT COSTS: Miscellaneous expenses necessary for an app’s continued use. Expenses like end-user training, developer education, and admin are often neglected, but they are very real costs organizations pay regularly.

The TCO assessment is one area where what you are considering the ”application” matters quite a bit. An application’s peripherals or software components need to be considered in your estimates.

3.3 Assess TCO

Input

  • Familiarity of the TCO for applications within this subset
  • Vendor contracts, maintenance history

Output

  • TCO scores for each application

Materials

  • APM Snapshot and Foundations Tool

Participants

  • Business Owners, Vendor Managers, Operations Managers
  • Applications Lead
  • Any Applications Team Members

30-60 minutes

  1. For each application, score on a scale of 0 to 5 how large the application’s cost is for:
    1. License: Recurring payments to a vendor. If available, use vendor contracts or license documentation to guide your scoring.
    2. Maintenance: Internal spend to maintain an app. If available, use data from service desk or ALM tools to guide scoring.
    3. Indirect: Miscellaneous expenses necessary for an application's continued use.
  2. Review outstanding application attributes from exercise 2.3. Use this opportunity to validate or collect specific data points from the financial SMEs of the applications.

Understand the back end and technical health of your applications

The image depicts an iceberg, with a small portion of the iceberg above the water line, and the majority of the iceberg below the water line. In the top section, there is the text: Unfortunately, the business only cares about what they can see or experience. In the bottom section, there is the text: Rationalization is your opportunity to get risk on the business’ radar and gain buy-in for the necessary action.

Technical health is where IT presents the extent of technology risk the organization faces.

MAINTAINABILITY (RAS)

RAS refers to an app’s reliability, availability, and serviceability. How often, how long, and how difficult is it for your resources to keep an app afloat, and what are the resulting continuity risks? This can include root causes (e.g. technical debt, poor source code management).

SECURITY

Are there vulnerabilities with the application or a history of security incidents? Are there risks or threats that cannot be sufficiently mitigated? Remember that threats are often internal and non-malicious. Does the app allow for illegitimate use?

ADAPTABILITY

How easily can the app be enhanced or scale to changes in business needs? If an application is or has the potential to be a barrier to growth it needs to be dealt with. Does the app fit within the business strategy?

INTEROPERABILITY

The degree to which an app is integrated with current systems. Apps require comprehensive technical planning and oversight to ensure they connect within the greater application architecture. Does the app fit within the technology strategy?

3.4 Assess technical health

Input

  • Familiarity of technical health perspective for applications within this subset
  • Maintenance history, architectural models

Output

  • Technical health scores for each application

Materials

  • APM Snapshot and Foundations Tool

Participants

  • Technical SMEs
  • Applications Lead
  • Any Applications Team Members

30-60 minutes

  1. For each application, score on a scale of 1 to 5 the application’s health for:
    1. Maintainability. To what degree is the application reliable, available, and serviceable?
    2. Security. To what degree is the application secure and meets security/compliance regulations?
    3. Adaptability. To what degree can the application handle changes in features or scale?
    4. Interoperability. To what degree is the application compatible with current or future-state software components and infrastructure?
  2. Review outstanding application attributes from exercise 2.3. Use this opportunity to validate or collect specific data points from support owners or technical SMEs of the applications.

Redundancies require a different analysis and set of dispositions

Solving application redundancy is a lot more complicated than simply keeping one application and eliminating the others.

First, you need to understand the extent of the redundancy. The applications may support the same capability, but do they offer the same functions? Determine which apps offer which functions within a capability. This means you cannot accurately arrive at a disposition until you have evaluated all applications.

Next, you need to isolate the preferred system. This is completed by comparing the same data points collected for rationalization and the application alignment analysis. Cost and coverage of all necessary functions become the more important factors in this decision-making process.

Lastly, for the non-preferred redundant applications you need to determine, what will you do with the users? What will you do with the data? And what can you do with the functionality (can the actual coding be merged onto a common platform)?

Disposition Description & Additional Analysis Call to Action (Priority)

Keep & Absorb

Higher value, health satisfaction, and cost than alternatives

These are the preferred apps to be kept. However, additional efforts are still required to migrate new users and data and potentially configure the app to new processes. Application or Process Initiative (Moderate)

Shift & Retire

Lower value, health satisfaction, and cost than alternatives

These apps will be decommissioned alongside efforts to migrate users and data to the preferred system.

*Confirm there are no unique and necessary features.

Process Initiative & Decommission (Moderate)

Merge

Lower value, health satisfaction, and cost than alternatives but still has some necessary unique features

These apps will be merged with the preferred system onto a common platform.

*Determine the unique and necessary features. *Determine if the multiple applications are compatible for consolidation.

Application Initiative (Moderate)

3.5 (Optional) Assess redundancies

Input

  • Areas of redundancy
  • Familiarity of features for applications within this subset

Output

  • Feature-level review of application redundancy

Materials

  • Whiteboard and markers
  • APM Snapshot and Foundations Tool

Participants

  • Business Owners
  • Applications Lead
  • Any Applications Team Members

1 hour

Reminder: This exercise is best performed after aligning business capabilities to applications across the portfolio and identifying your areas of redundancy in exercise 2.2. At this stage, this is still an information collection exercise and it will not yield a consolidation-based disposition until applied to all relevant applications. Lastly, this exercise may still be at too high a level to outline the full details of redundancy, but it is still vital information to collect and a starting point to determine which areas require more concentrated analysis.

  1. Determine which areas of redundancy have applications included in this subset.
  2. For each area of redundancy, identify the high-level features. Aim to limit the features to ten, grouping smaller features if necessary. SoftwareReviews can be a source of to identify common features.
  3. Label features using the MoSCoW model: must have, should have, should have, would have.
  4. For each application, document which features they provide.

3.5 (Optional) Assess redundancies

Account Management Call Management Order/ Transaction Processing Contract Management Lead/Opportunity Management Forecasting/ Planning Customer Surveying Email Synchronization
M M M M S S C W
CRM 1
CRM 2
CRM 3

3.6 (Optional) Determine dispositions for redundant applications

Input

  • Feature-level review of application redundancy
  • Redundancy comparison

Output

  • Assigned dispositions for redundant applications

Materials

  • APM Snapshot and Foundations Tool

Participants

  • Business Owners
  • Applications Lead
  • Any Applications Team Members

30 minutes

Reminder: This activity is intended to be applied after you have performed exercises 3.1-3.5 for all applications related to an area of redundancy. Perform these steps for each area of redundancy.

  1. Review the results of 3.5 for your areas of redundancy. Based on the feature-level assessment, determine if you can omit applications if they don’t truly overlap with other applications.
  2. Open the Redundancy Comparison tab in the APM Snapshot and Foundations Tool. Add the relevant applications from the drop-down menu in column C.
  3. Determine the preferred application. Use the diagram to influence this decision. This may be the application closest the top right (strong health and value). However, less expensive options or any options that provide a more complete set of features may be preferable.
  4. Open the Rationalization Results tab. Assign a disposition to each application in column D.
  5. Some dispositions may imply a call to action, new project, or initiative. Ideate and/or discuss with the team any potential initiatives.

3.6 Determine dispositions

Input

  • Rationalization results

Output

  • Assigned dispositions for applications

Materials

  • APM Snapshot and Foundations Tool

Participants

  • Business Owners
  • Applications Lead
  • Any Applications Team Members

1 hour

  1. Open Rationalization Results tab in the APM Snapshot and Foundations Tool.
  2. Review the recommended disposition based on the application’s position and color on the 2x2 matrix.
  3. Question if that disposition is appropriate. Be sure to consider:
    • TCO. Cost should come into play for any decisions. Review the implications in column AA to see specifically where cost should be taken into consideration.
    • Alignment to strategic goals set for the overarching organizational, IT, technology (infrastructure), or application portfolio.
  4. Select a disposition for each application and enter in column D.
  5. Some dispositions may imply a call to action, new project, or initiative. Ideate and/or discuss with the team any potential initiatives.

Note: Modify the list of dispositions on the Disposition Options worksheet as appropriate for your rationalization initiative. Any modifications to the Disposition column will be automatically updated in the App Rationalization Results and Roadmap worksheets.

Phase 4

Populate Your Roadmap

Phase Participants

  • Applications Lead
  • Delivery Leads

Additional Resources

Roadmaps are used for different purposes

Roadmaps are used for different communication purposes and at varying points in your application delivery practice. Some use it to showcase strategy and act as a feedback mechanism that allows stakeholders to validate any changes (process 1). Others may use it to illustrate and communicate approved and granular elements of a change to an application to inform appropriate stakeholders of what to anticipate (process 2).

Select Dispositions & Identify New Initiatives →Add to Roadmap →Validate Direction →Plan Project →Execute Project

Select Dispositions & Identify New Initiatives →Project Proposal; Feasibility/ Estimation; Impact Assessment; Business Case; Initial Design →Approve Project →Add to Roadmap →Execute Project

The steps between selecting a disposition and executing on any resulting project will vary based on the organization’s project intake standards (or lack there of).

This blueprint focuses on building a strategic portfolio roadmap prior to any in-depth assessments related to initiative/project intake, approval, and prioritization. For in-depth support related to intake, approval, prioritization, or planning, review the following resources.

Determine what makes it onto the roadmap

A roadmap should not be limited to what is approved or committed to. A roadmap should be used to present the items that need to happen and begin the discussion of how or if this can be put into place. However, not every idea should make the cut and end up in front of key stakeholders.

Valuable

  • The initiative will add value, reduce risk, or align with strategic goals.

Feasible

  • The initiative is compatible and realistic given capacity, budget, or limitations.

Usable

  • The initiative matches the end user’s needs and skill sets.

(Adapted from Product Coalition, 2017)

Don’t Add & Reconsider Disposition - When no discernable value can be identified, do not add.

Cautiously Add to Roadmap - When value exists, but the feasibility is questionable, add with the intention of further evaluation.

Accelerate Disposition - When valuable, feasible, and usable, add and prioritize the item.

4.1 Prioritize initiatives

Input

  • Assigned dispositions
  • Rationalization results

Output

  • Prioritized initiatives

Materials

  • Whiteboard and markers
  • APM Snapshot and Foundations Tool

Participants

  • Delivery Leads
  • Applications Lead
  • Any Applications Team Members

1 hour

Reminder: This is just a high-level assessment to provide a sense of feasibility, practicality, and priority and an estimated timeline of a given initiative. Do not get lost in granular estimations.

  1. Collect any new initiative ideas that result from rationalization. Group them into:
    1. Process Initiative: Any project or effort focused on process improvements without technical modification to an app (e.g. user migration, change in SLA, new training program). Write the application and initiative name on a blue sticky note.
    2. App Initiative: Any project or effort involving technical modification to an app (e.g. refactoring, platform migration, feature addition or upgrade). Write the application and initiative name on a yellow sticky note.
    3. Decommission Initiative: Any project and related efforts of removing an app (e.g. migrating data, removal from server). Write the application and initiative name on a red sticky note.
  2. Rate each initiative on a high, medium, and low scale based on its high-level estimated relative cost and effort. Be sure to consider initial and ongoing costs that the initiative would require.

4.1 Prioritize initiatives continued

  1. Rate each initiative on a high, medium, and low scale based on its potential benefit. Be sure to consider:
    1. Disposition: Review disposition matrix for which types are higher priority.
    2. Risk: Discuss high-risk applications and the initiative’s ability to limit risk.
    3. Current Cost: Large cost-saving opportunities should be higher priority.
    4. Strategic Alignment: How well does this initiative align to strategic goals?
  2. Plot each initiative on a diagram as seen on this slide. Use the top-right to bottom-left direction to determine priority. Determine which initiatives should not even be included on the portfolio roadmap.

The image is a plot with the X-axis labelled Low Benefit on the left-hand side, and High Benefit on the right-hand side, the Y-axis labelled Low Effort/Cost at the top and High Effort/Cost at the bottom, and a diagonal line crossing through the centre point with Low Priority at the left bottom point, and High Priority at the right high point. There are post-it note squares arranged around the plot, each labelled with an initiative. One of circled, and expanded upon, showing a second, connect post-it note that reads: Application Name; Initiative Name; Benefit (L/M/H); Cost (L/M/H).

4.2 Populate roadmap

Input

  • Prioritized projects for applications
  • Familiarity of resource capacity

Output

  • Initial portfolio roadmap

Materials

  • APM Snapshot and Foundations Tool

Participants

  • Delivery Leads
  • Applications Lead
  • Any Applications Team Members

1 hour

Reminder, this is just a starting point and is meant be high level and strategic. Do not get lost in granular estimations.

  1. Open the Roadmap tab of APM Snapshot and Foundations Tool. Review the color scheme for different initiative types.
  2. For any applications that did not undergo rationalization, such as new or birth applications (in procurement, implementation, or development), add their timeline for their delivery and initial release or any other relevant milestones.
  3. Add any planned or in-flight initiatives associated with your existing applications. Add the timeline for the initiatives.
  4. Indicate any currently scheduled updates for your applications.
  5. Add new initiatives resulting from rationalization, starting with your top priorities. When estimating the time required for each initiative, be sure to consider.
    1. Effort (define assumptions related to unit of measure and elapsed time vs. actuals)
    2. Capacity
    3. Dependencies

4.2 Populate roadmap example

The image is a screenshot of the Application Portfolio Roadmap, filled in with sample data, as an example. A box points to the Disposition column, with the text: Identify your application’s disposition. A box points to the Initiative Details column with the text: List initiatives related to your applications. A box point to the Q4 column, with text that reads: Showcase the timeline of your initiatives.

Create a recurring update plan

  • Application inventories become stale before you know it. Build steps in your procurement process to capture the appropriate information on new applications. Also, build in check points to revisit your inventory on a regular basis to assess the accuracy of inventory data.
  • Rationalization is not one and done; it must occur with an appropriate cadence.
    • Business priorities change, which will impact the current and future value of your apps.
    • Now more than ever, user expectations evolve rapidly.
    • Application sprawl likely won’t stop, so neither will shadow IT and redundancies.
    • Obsolescence, growing technical debt, changing security threats, or shifting technology strategies are all inevitable, as is the gradual decline of an app’s health or technical fit.
    • An application’s disposition changes quicker than you think, and rationalization requires a structured cadence. You need to plan to minimize the need for repeated efforts. Conversely, many use proceeding iterations to increase the analysis (e.g. more thorough TCO projections or more granular capability-application alignment).
  • Portfolio roadmaps require a cadence for both updates and presentations to stakeholders. Updates are often completed semi-annually or quarterly to gauge the business adjustments that affect the timeline of the domain-specific applications. The presentation of a roadmap should be competed alongside meetings or gatherings of key decision makers.
  • M&A or other restructuring events will prompt the need to address all the above.
How frequently should you rationalize the portfolio and update your roadmap?
Small Portfolio

Rationalize every 2 years

Roadmap quarterly

Rationalize every 2-3 years

Roadmap every 2 years

Large Portfolio

Rationalize biannually

Roadmap monthly

Rationalize annually

Roadmap annually

Dynamic Strategy Stable Strategy

4.3 Ongoing APM cadence

Input

  • Initial experience with APM
  • Strategic meetings schedule

Output

  • Ongoing cadence for APM activities

Materials

  • Whiteboard and markers
  • APM Snapshot and Foundations Tool

Participants

  • Applications Lead
  • Any Applications Team Members

1 hour

  1. Review the necessary frequency you will update or present the artifacts of your APM practice: Application Inventory, Application Rationalization Tool, and Application Roadmap.
  2. For each artifact, determine the:
    1. Owner: Who is accountable for the artifact and the data or information within the artifact and will be responsible for or delegate the responsibility of updating or presenting the artifact to the appropriate audience?
    2. Update Cadence: How frequently will you update the artifact? Include what regularly scheduled meetings this activity will be within.
    3. Update Scope: Describe what activities will be performed to keep the artifact up to date. The goal here is to minimize the need for a full set of activities laid out within the blueprint. (Optional) How will you expand the thoroughness of your analysis?
    4. Audience: Who is the audience for the artifact or assessment results?
    5. Presentation Cadence: How frequently will you present the artifact to the audience? Include what regularly scheduled meetings this activity will be within.

4.3 Ongoing APM cadence

ArtifactOwnerUpdate CadenceUpdate ScopeAudiencePresentation Cadence
InventoryGreg Dawson
  • As new applications are acquired
  • Annual Review
  • Add new application data points (This is added to implementation standards)
  • Review inventory and perform a data health check
  • Validate with app’s SME
  • Whole organization
  • Always available on team site
Rationalization ToolJudy Ng
  • Annual Update
  • Revisit value driver weights
  • Survey end users
  • Interview support owners
  • Interview business owners
  • Update TCO based on change in operational costs; expand thoroughness of cost estimates
  • Rescore applications
  • Business owners of applications
  • IT leaders
  • Annually alongside yearly strategy meeting
Portfolio RoadmapJudy Ng
  • Monthly update alongside project updates
  • Shift the timeline of the roadmap to current day 1
  • Carry over project updates and timeline changes
  • Validate with PMs and business owners
  • Steering Committee
  • Business owners of applications
  • IT leaders
  • Quarterly alongside Steering Committee meetings
  • Upon request

Common application inventory attributes

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

Common application inventory attributes

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

Bibliography

”2019 Technology & Small Business Survey.” National Small Business Association (NSBA). Accessed 1 April 2020.

“Application Rationalization – Essential Part of the Process for Modernization and Operational Efficiency.” Flexera, 2015. Web.

“Applications Rationalization during M&A: Standardize, Streamline, Simplify.” Deloitte Consulting LLP, 2016. Web.

Bowling, Alan. “Clearer Visibility of Product Roadmaps Improves IT Planning.” ComputerWeekly.com, 1 Nov. 2010. Web.

Brown, Alex. “Calculating Business Value.” Agile 2014 Orlando, 13 July 2014. Scrum Inc. 2014. Web.

Brown, Roger. “Defining Business Value.” Scrum Gathering San Diego 2017. Agile Coach Journal. Web.

“Business Application Definition.” Microsoft Docs, 18 July 2012. Web.

“Connecting Small Businesses in the US.” Deloitte Consulting LLP, 2017. Accessed 1 April. 2020.

Craveiro, João. “Marty meets Martin: connecting the two triads of Product Management.” Product Coalition, 18 Nov. 2017. Web.

Curtis, Bill. “The Business Value of Application Internal Quality.” CAST, 6 April 2009. Web.

Fleet, Neville, Joan Lasselle, and Paul Zimmerman. “Using a Balance Scorecard to Measure the Productivity and Value of Technical Documentation Organizations.” CIDM, April 2008. Web.

Fowler, Martin. “Application Boundary.” MartinFowler.com, 11 Sept. 2003. Web.

Harris, Michael. “Measuring the Business Value of IT.” David Consulting Group, 2007. Web.

“How Application Rationalization Contributes to the Bottom Line.” LeanIX, 2017. Web.

Jayanthi, Aruna. “Application Landscape Report 2014.” Capgemini, 4 March 2014. Web.

Lankhorst, Marc., et al. “Architecture-Based IT Valuation.” Via Nova Architectura, 31 March 2010. Web.

“Management of business application.” ServiceNow, January 2020. Accessed 1 April 2020.

Mauboussin, Michael J. “The True Measures of Success.” HBR, Oct. 2012. Web.

Neogi, Sombit., et al. “Next Generation Application Portfolio Rationalization.” TATA, 2011. Web.

Riverbed. “Measuring the Business Impact of IT Through Application Performance.” CIO Summits, 2015. Web.

Rouse, Margaret. “Application Rationalization.” TechTarget, March 2016. Web.

Van Ramshorst, E.A. “Application Portfolio Management from an Enterprise Architecture Perspective.” Universiteit Utrecht, July 2013.

“What is a Balanced Scorecard?” Intrafocus. Web.

Whitney, Lance. “SMBs share their biggest constraints and great challenges.” Tech Republic, 6 May 2019. Web.

About Info-Tech

Info-Tech Research Group is the world’s fastest-growing information technology research and advisory company, proudly serving over 30,000 IT professionals.

We produce unbiased and highly relevant research to help CIOs and IT leaders make strategic, timely, and well-informed decisions. We partner closely with IT teams to provide everything they need, from actionable tools to analyst guidance, ensuring they deliver measurable results for their organizations.

Member Rating

9.3/10
Overall Impact

$31,749
Average $ Saved

19
Average Days Saved

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve.

Read what our members are saying

What Is a Blueprint?

A blueprint is designed to be a roadmap, containing a methodology and the tools and templates you need to solve your IT problems.

Each blueprint can be accompanied by a Guided Implementation that provides you access to our world-class analysts to help you get through the project.

Need Extra Help?
Speak With An Analyst

Get the help you need in this 4-phase advisory process. You'll receive 5 touchpoints with our researchers, all included in your membership.

Guided Implementation #1 - Lay your foundations
  • Call #1 - Establish goals and foundations for your APM practice.

Guided Implementation #2 - Improve your inventory
  • Call #1 - Initiate inventory and determine data requirements.

Guided Implementation #3 - Rationalize your applications
  • Call #1 - Initiate rationalization with group of applications.
  • Call #2 - Review result of first iteration and perform retrospective.

Guided Implementation #4 - Populate your roadmap
  • Call #1 - Initiate your roadmap and determine your ongoing APM practice.

Author

Ben Mackle

Visit our COVID-19 Resource Center and our Cost Management Center
Over 100 analysts waiting to take your call right now: 1-519-432-3550 x2019