Application Portfolio Management (APM) Best Practices

APM developed in the late 1990s when organizations began creating inventories of applications, primarily as a response to the Y2K problem. Over time, companies added cost data, categorization, and business process linkage information to the inventories, providing new insight into how applications support business operations.

As the use of technology in business increased, the application “inventory” process emerged as a more focused discipline, with dedicated people and tools to manage it. Applications were now key resources in implementing strategy, and represented a significant cost and potential risk area.

In addition, applications were more interconnected, adding more complexity. This drove a requirement for increased visibility and analysis beyond what could be provided in spreadsheets. To respond to these trends, purpose-built application portfolio management software started to appear a few years after Y2K and have continued to mature.

Application portfolio management software was deployed to help:

• Identify and eliminate redundant and unused applications
• Consolidate similar applications into a single new application
• Retire older and more expensive-to-maintain applications
• Determine which data flows through which applications to optimize security controls

The early drivers for application portfolio management frameworks were to lower costs and risks. Mitigating costs and risks are still important, but today’s organizations are also using APM to drive growth and revenue.

With an increased number of mergers and acquisitions as well as pressure to create new, interconnected products and services, companies are constantly reassessing their business capabilities and striving to embed technology into everything. To support these initiatives, IT leaders and specifically enterprise architects must identify and fill capability gaps, which requires making better decisions about application and technology portfolios.

This job is more challenging than ever, considering the state of applications today. Applications are getting simpler but more numerous, with vendors using cloud services to create and release new ones faster than ever. Companies must evaluate these technologies quickly to respond to customer demands, or else risk getting behind the competition.

In addition, businesses are moving more and more applications to the cloud. Rather than running applications, they can spend more time and money delivering continuous innovation and change. Meanwhile, enterprises are still running lots of legacy systems along with cloud, and the integration between applications in these hybrid IT infrastructures is complex and critical to understand.

Today, application portfolio management is more important yet more complex than ever. Companies are under pressure to drive growth and revenue with digital transformation initiatives, requiring an optimized application portfolio.

Increasingly, enterprise architects must work with multi-disciplinary teams consisting of executives, line of business managers, planning professionals, and those involved in execution. Only by collaborating with these different roles across an organization can one understand the capability gaps and requirements, and then deliver the right outputs.

Here are the ten best practices for success with APM, which Planview has gleaned from working with its customers over the past 15 years.

1. Get to Know Your Internal Customers

The top key to success with application portfolio management is to develop relationships with your colleagues who are making decisions involving applications and technology. These are your primary customers. They are working on the most important initiatives in various digital transformation roles. To start, target:

• All executives sponsoring large change programs or initiatives, especially those who are delivering against corporate strategy
• Roles involved in technology planning such as Portfolio Managers, Program Managers, Resource Managers, and Finance
• The Project Management Office, Project Managers, Solution Architects, and any others involved in the execution of projects and initiatives
• Application Architects, especially as applications and their configurations are continuously moved through a DevOps pipeline

These individuals can derive the most value from APM, but only if you can help them make better decisions. You can only get what you need by talking to them. Get used to it, since you will be spending a lot of time with them. If you are not already, something is wrong.

2. Discover What Questions Your Customers Are Asking

Your answers to your customers’ essential questions will help them execute on their transformation projects faster and with less risk. Find out:

• What their questions are
• The scope of the questions
• What form the answers should take
• How often to provide status updates
• What the priority is

You may need to translate each question by abstracting it further or making it more concrete. Often, you must dig for the question behind the question. For example: A decision maker may say, “Why is our branding so varied across our web site, mobile app, and retail store kiosks?” What he or she may really be asking is, “How can we achieve a single view for the customer across all touch points?”

Beyond understanding these questions, you must determine what decisions your customers will make with the answers. This information is necessary to ensure you deliver outputs that allow for streamlined decision-making processes.

In the graphic below, you can see that different roles will make different decisions based on the same question. You need to change the scope and level of detail of your answers accordingly.

3. Create and Share a Target Output List

When inquiring about what decision makers want, you will often get this answer:

“I can’t describe what I need, but I will know it when I see it.”

So, let them see it! To answer your customers’ questions, document the set of outputs you propose:

• Produce outputs from your application portfolio management software, such as graphics, drawings, visualizations, reports, and dashboards.
• Save time by choosing out-of-the-box, well-tested outputs that can be produced quickly.

• Create visual mockups showing what the finished result will look like. This will make it easier to get buy-in. Top tip: When a mockup contains recognizable items by name, it is easier for your internal customer to see the value. For example, if the visualization is displaying business units, use your company’s actual business unit names.

The target output list becomes the milestones for delivery. Depending on the size of your organization and degree of transformation occurring, the total target output list can take from six months to a few years to deliver. Successful APM programs regularly re-prioritize this list and deliver a small set of the highest priority outputs in regular, short, 30-60 day intervals.

4. Create a Target Data List

The most effective APM programs deliver value with the smallest set of data possible. Your internal customer determines what the value is by telling you what questions need to be answered, and what outputs will answer those questions.

What data should be managed in an APM solution? Only what is essential to generate your target output list (see #3 above).

Thus, it is critical to maintain a list of the data items required for chosen outputs. This will help you limit the scope of work associated with maintaining your APM solution. Avoid this step at your peril.

It takes resources and dedication to identify data sources, cleanse the data, and keep it up to date. Don’t use these resources to capture and manage data that might be valuable. You only want to collect what is needed for outputs that you know will be valuable. How do you know? See best practices one and two!

5. Determine Data Owners

Data ownership is important for a successful APM program. If your users do not trust the data, they will stop using it for decision making.

A data owner has the responsibility to manage a subset of data items from the Target Data List. The data owner identifies the source, method of collection, and processes to follow that ensure the captured data follows the three Cs:

• Completeness: Do we have the scope of data needed to answer the question without missing important aspects?
• Correctness: Is the data correct and accurate?
• Consistency: Is the data consistent with itself? For example, do all data items that describe a capacity use the same units? If multiple fields on multiple objects refer to the same concept, is the concept spelled the same? Are there multiple components representing the same entity?

The data owner is not necessarily responsible for doing these tasks himself, though more often than not it is the same person.

There are three primary methods of collecting needed data for APM:

• Automatic collection through an integration with a separate data source
• Manual collection using the APM software data entry capabilities
• Manual collection through modeling

6. Define Your Terms

To obtain the necessary data, you must explain exactly what you want. However, people sometimes get stuck on crafting definitions. As an example, enterprise architects have been arguing for years about the exact definition of an “application,” but the understanding of the definition is more important than the definition itself.

For instance, if you need to ask folks to provide you with all the “applications” they use, be very specific about what you mean by application. Provide examples from your environment of what is and is not an application.

Whatever your definition, don’t seek a consensus agreement on the definition of a particular term. You aren’t putting together a dictionary! Instead, seek to gain complete understanding of what you mean by that term.

7. Load Data in Distinct Phases

APM failures often occur due to data management. Two common problems are:

• Loading data until something useful comes out of it: Most application portfolio management tools have built-in data models. Some are very robust, containing objects to represent virtually any kind of technology and business concept. To derive value quickly, some organizations attempt to load every data item they can find. This approach lacks a plan (and ownership). APM best practices two, three, and four address this issue.
• Treating all data loads as the same: There is a difference between the initial (from empty) loading of data in an APM solution and the ongoing management of that information. The former involves more bulk loading of readily available information and typically takes a concentrated effort over a short period of time. The latter is a steady state, process-driven activity. This problem is addressed by identifying distinct phases of data management. The best results occur when people use the following phases:
  • Initial Data Load Phase: One-time bulk loading of readily available data
  • Transitory Phase: One-time phase for cleaning data and training of “steady state” data providers, and configuring automated data source integrations
  • Steady State Phase: Ongoing maintenance of data

8. Conduct “Pilot” Training for Data Suppliers

Another challenge in APM is that you will require effort from folks outside of your own team to supply data and to maintain it on a regular basis. Even though most APM software provides built-in workflow systems to help manage your data suppliers, it is important to train this team. Since this is not their “day” job, you must make it as simple as possible for them. The best practices for this include:

1. Train a small, friendly “pilot” set of data suppliers and have them work through the process while you observe;
2. Incorporate their feedback and the lessons learned into the training plan; and
3. Then train the remaining data suppliers.

9. Develop a Communication Plan

Organizations with excellent communication have the best APM programs:

• They develop a communication plan for all stakeholders, including:
  • Decision Makers: Internal customers
  • Data Owners and Data Suppliers
• Communication plan deliverables include key messages for all phases of the project

10. Broadcast Your Success

If you follow these best practices, you will deliver your program as a series of small successes. Every stakeholder should know about these. Make an announcement for each one, letting all involved know:

• What kinds of questions were answered and with what kinds of outputs
• For what decision makers
• What kinds of decisions it helped them make
• What data was required to make that output possible

An Application Portfolio Management Template for Success

As IT and the business become more intertwined to achieve revenue targets, enterprise architects have an opportunity to be key facilitators of digital transformation programs. These best practices provide a tested application portfolio management template to follow.

Start by understanding what you want to get out of your application portfolio management program first. Data is critical, but it comes from people who don’t work for you. Make it easier for them to help you by answering their questions and helping them execute on their initiatives. Target short 30- to 60-day time frames for delivering value. Then, communicate continuously as you work with your colleagues to deliver the products and services that meet strategic business objectives.

The Planview solution for Capability and Technology Management enables enterprise organizations to advance business capabilities by connecting technology with business outcomes. By engaging cross-functionally with stakeholders, EAs can create enterprise architecture plans and roadmaps that achieve strategic objectives.

Application Portfolio Management is a part of Planview’s Capability and Technology Management solution, first released in 2003 as a core feature of the legacy Troux product line. APM best practices are supported through 15 years in partnership with over 300 deployed customers. The Planview solution for Capability and Technology Management helps you understand the dependencies between your organization’s program and application portfolios, the underlying technology stack, and business capabilities, projects, and products.