Application Portfolio Management

Application Portfolio Management#_37817 Página 1 de 22
This research note is restricted to the personal use of Vladimir Morozowski de Sousa ([email protected]).
Application Portfolio Management

21 May 2007 G00203293
Analyst(s): Lyn Robison
Summary
Information technology (IT) planning often follows a linear path of deploying software applications and then operating them forever,
without a clear idea of when any of the applications will be retired. This linear thinking is not sustainable and will eventually cripple the IT
group's ability to respond to new business requirements. Application portfolio management (APM) turns this straight-line IT planning into
a closed loop that feeds metrics for application retirement back into the software acquisition process. In this Application Platform
Strategies overview, Analyst Lyn Robison provides guidance on instituting APM.
GARTNER FOUNDATIONAL
This research is reviewed periodically for accuracy. It was last reviewed
on 10 June 2013.
Synopsis
Application portfolio management (APM) is a set of processes for managing
software applications and software projects as assets. APM encompasses
application rationalization and also includes processes for controlling the
acquisition of software applications, managing the portfolio of projects that
information technology (IT) undertakes, and handling the demand for IT services.
Without APM, fewer IT

projects are successful, successful IT projects are less relevant, and legacy IT
systems are rarely retired and so become permanent, costly boat anchors that
restrain business and IT innovation. APM improves the management of in-flight IT
projects as well as legacy software applications by treating both as business
assets. A company can gain value by using these assets properly and can smartly
divest itself of the assets if their value ceases to exceed their costs, thereby
freeing up the IT budget for more innovation.
APM is a proven and well-accepted methodology that has become

the leading framework used by private- and public-sector entities for effective
management of IT investments, IT projects, and legacy software applications.
IT portfolio management
provides an analysis and decision-making framework for managing IT demand,
projects, and applications. The demand portfolio is made up of requests for IT
services and assets. These feed the project portfolio. The project portfolio is
made up of IT projects that are intended to fill the demand for IT assets and
services. These projects create IT applications, which feed the application
portfolio. The application portfolio is made up of existing IT applications,
which must be managed throughout their lifecycle.
Making these portfolios greater than the sum of their parts

involves using the Stage-Gate process. The items in each of the demand, project,
and application portfolios move through specific stages in their lifecycles.
Before each stage, managers can insert a gate to evaluate whether an item should
be discontinued or whether the item in question is worthy to proceed on to its
next stage. The idea is for proposals, projects, and applications that are
liabilities to “fail early” so that the precious resources they might consume
are not wasted.
Two
types of metrics can measure the effectiveness of an APM initiative: maturity
and value delivery. A maturity model can guide an enterprise in adopting APM,
while value delivery metrics for APM can clearly demonstrate the benefits that
the APM effort is providing for the business.
http://www.gartner.com/document/1405106?ref=TypeAheadSearch 19/11/2013
Analysis
Linear
thinking in IT planning, whereby applications are deployed and then run forever,
leads to an endless proliferation of IT systems that is not sustainable. The
practice of adding new software applications without retiring old ones will
eventually cause the entire IT budget to be consumed by the maintenance and
operations burden of legacy applications.
Application portfolio management is a proven methodology for

managing IT applications as assets that are retired at the end of their useful
lives. Application portfolio management provides a feedback mechanism that
mitigates linear IT planning by turning it into a closed loop that feeds metrics
for application retirement back into the software acquisition process.
To be effective, application
portfolio management must become an integral part of the IT demand management,
project approval, and application lifecycle management processes.
What Is Application Portfolio Management?

Application portfolio management (APM) is a set of processes
for managing software applications and projects as assets. Using APM, these
assets move through lifecycles during which they are consistently evaluated to
assess the value they provide for the business.
Application rationalization is a subset of APM and specializes

in assessing the lifecycle of software applications. For guidance on application
rationalization, see the
Application Platform Strategies
overview, “
Application Rationalization: Burning Fat
and Building Muscle (http://www.gartner.com/document/code/203228?ref=ddisp&latest=true) .”
APM encompasses
application rationalization and also includes processes for controlling the
acquisition of software applications, managing the portfolio of projects that IT
undertakes, and handling the demand for IT services.
In IT
Portfolio Management Step-by-Step
, the authors Bryan Maizlish and Robert Handler offer a comprehensive,
accessible guide for both business managers and IT professionals to implement
APM. Because of this particular book's relevance and usefulness, material from
it is quoted or paraphrased in several places in this overview, and is indicated
with a superscripted “1.”
The Need for APM

In today's enterprises, misalignment
between business goals and IT delivery is a common problem, but is not usually
due to a lack of financial investment in IT. In many companies, IT spending
represents greater than 70% of total capital spending. IT spending is often the
single largest capital investment that businesses make.
Despite its magnitude, business and IT

managers often treat the IT budget less like an investment and more like an
unmanaged operating expense.
In IT Portfolio Management
Step-by-Step , Maizlish
and Handler make the following observation:
There are no other

investments in the business world that occupy such a large and growing
expenditure, yet lack disciplined management, processes, and performance
measurements.
1 (#_37822)
APM can provide the discipline that a sizable IT investment deserves.
Many companies that have not

instituted APM are squandering a significant portion of their IT spending with:
An overabundance of pet projects
A reluctance to kill projects or retire assets
A myopic focus on
cool technologies
Inconsistent criteria and processes for assessing IT investments
Inadequate governance
Ad hoc
program management 1 (#_37822)
When it comes to IT investments, companies without APM are

flying blind. Business and IT managers are generally unaware of:
How
much software the company owns
Who is using which applications and for what
The licensing,
support, and operations costs for the software that employees use
Actual spending
against allocated budget (also known as “fund and forget”)
How many IT projects are in

development
The degree of each project's alignment with overall strategy
The amount
of resources allocated to each IT project
The reasons why the IT projects were

initiated
The criteria used to approve them in the first place
The results of a company's lack of

awareness about its IT investments are:
IT investments are
improperly prioritized
Key projects are not undertaken or are underfunded
Redundant IT
projects are undertaken
Project risks are not properly considered
Inconsistent business cases

make it impossible to compare IT investments
IT projects do not meet expectations
IT
project costs exceed budgets
IT project deadlines slip
Flexibility to quickly reprioritize IT

spending is lost
Governance committees are powerless and lose the trust of senior managers
1
(#_37822)
Most companies, even those that do not use APM, have processes in place to
evaluate proposals for new IT projects. Yet in these companies, only the portion
of the budget for new IT projects is scrutinized. Business and IT managers
generally assume that the maintenance and operations (M&O) budget will
remain untouched in perpetuity. As a result, the M&O portion of the budget
is rarely examined. The practice of never overhauling the M&O budget, which
is 70% to 80% of the total IT budget at many companies, prevents effective
management of the IT budget and the applications it pays for.
This entitlement mentality in

enterprises that have not instituted APM allows M&O costs to consume the
bulk of the IT budget, leaving little money for the innovations that help the
application portfolio meet the changing needs of the business.
An unchanging application portfolio means

that:
The business suffers with IT systems that do not provide the

functionality or information it needs.
A lack of interoperability causes IT systems to fossilize

over time as apps are added.
Solutions won't scale properly.
Weak links abound in the technical

infrastructure.
Redundant systems increase errors and stifle flexibility and agility.
In short, without
APM, legacy IT systems become permanent, costly boat anchors that restrain
business and IT innovation. In today's fast-changing business world, innovation
is an imperative for long-term survival.
APM treats new IT projects and legacy applications as business

assets—assets that are discontinued or retired when their costs exceed their
value, thereby ensuring that an appropriate portion of the IT budget is spent on
innovation.
A Proven Methodology
APM is a proven and well-accepted methodology. IT portfolio
management has become the leading framework used by private- and public-sector
entities for effective management of IT investment. In the private sector, a
survey of 100 top IT executives published by CIO Magazine
ranked portfolio management as the most effective project prioritization
practice.
2 (#_37822) Within the public
sector, both the U.S. General Accounting Office (GAO) and the Office of
Management and Budget (OMB) advocate IT portfolio management as a central tenet
of sound IT investment management. Research consistently reveals that when
companies institute a portfolio approach, IT expenditures decline by 15% to 20%
without significant negative impact. 1 (#_37822)
One of the ways that APM enables IT expenditures to decline is by providing a

feedback loop on the value of legacy applications so that a company can
proactively and correctly scrutinize its M&O budget. In addition, APM
enables proposed and in-flight IT projects to be consistently evaluated and
rejected or shut down when it makes business sense to do so.
The Macro View of IT Portfolio Management

Portfolio management provides an analysis and decision-making
framework for managing IT demand, projects, and applications. To manage all
three of these, the overall IT portfolio is divided into three subportfolios:
Demand portfolio , made up of demands for IT services and assets. The demands
are a combination of requests for new applications and for modernization of
old applications. These demands feed into the project portfolio.
Project
portfolio , made
up of IT projects that are intended to fill the demand for IT assets and
services. These projects create IT applications, which feed into the
application portfolio.
Application portfolio , made up of existing IT assets, which must be managed

throughout their lifecycles. Assets are retired when their costs exceed their
value and they are replaced by projects coming out of the project portfolio.
The three
portfolios—demand, project, and application—might also be referred to as the
“plan,” “build,” and “run” portfolios. IT groups that are organized around these
three portfolios are in a position to retire old applications and introduce new
ones without making painful organizational changes within the IT groups
themselves. This is in stark contrast to IT groups that are organized around
major applications. In these organizations, each major application has its own
IT operations staff, support staff, and development staff. The applications are
rarely retired because doing so results in organizational upheaval within the IT
group. The ability to retire old applications and introduce new ones without
this upheaval is a prerequisite for effective IT portfolio management.
The roles of the demand,

project, and application portfolios are complementary. They depend on and feed
into one another. Making these portfolios greater than the sum of their parts
involves using the Stage-Gate process.
The Stage-Gate Process

Created by Dr. Robert
G. Cooper, Stage-Gate is a multidisciplinary, cross-functional iterative process
with defined concurrent processes and activities at each stage and decision
points at each gate (
www.stage-gate.com (http://www.stage-gate.com) ). The Stage-Gate process has traditionally
been applied to new product development. However, it can be easily adapted to
APM.
The items in the

demand, project, and application portfolios move through specific stages in
their lifecycles.
The
stages of the demand portfolio are:
capture
Ideation
Feasibility assessment
Concept
maturation
The stages of the project portfolio are:
Scoping
and preliminary analysis
Business case creation
Development
Validation
Launch and deployment to operations
The stages of the application

portfolio are:
Successful launch
Post-launch review
Lifecycle management
Before each stage, decision makers can insert a gate to

evaluate if an item should be discontinued or if it is worthy to proceed on to
its next stage. The people who will fill those decision-making roles will vary
in each enterprise. The “ APM Maturity Model (#_37817)
” section of this overview provides a Responsible, Accountable, Consulted, and
Informed (RACI) matrix that can serve as a starting point for identifying the
proper decision makers.
The idea is for proposals, projects, and applications that are

liabilities to “fail early” so that the precious resources they might consume
are not wasted. At the strategic planning level, APM enables an IT group to
iterate its planning and execution quickly, analyze constantly, and make
adaptations before it is too late. The process of avoiding and being divested of
liabilities frees up resources for productive IT assets. Additional information
on the use of this process is provided in the “ Understanding the Stage-Gate Process
(#_37811) ” section of this overview.
The Stage-Gate process can be

used to institute standard procedures for managing the three portfolios. This
requires that the many important pieces of information about IT investments that
are scattered among different locations and organizations within the enterprise
be standardized and stored in a centralized repository. Once the information
about IT assets has been standardized and collected, it becomes the basis for
accurate communications and decision making regarding those assets.
APM Metrics
Two
fundamental types of metrics are used to measure the effectiveness of an APM
initiative: APM maturity and APM value delivery.
A maturity model can be used descriptively to ascertain an

enterprise's progress in instituting APM and prescriptively to get a rough idea
of the next steps that an enterprise should take. An APM maturity model is
provided in the “
APM Maturity Model (#_37817) ”
section of this overview.
The value delivery of APM can be measured by assessing its positive effect on a
company's IT investments. Below are several examples of measurable improvements
that APM can bring to an enterprise.
Better support of business

goals by investing a higher percentage of the IT budget on new initiatives and
a lower percentage on M&O
Better distribution of IT investments among strategic,

mandated, and routine IT projects
Greater IT investment in strategic, high-value, and

transformative projects
Cost avoidance through more efficient software licensing
Cost
reductions in the IT project budget by eliminating nonessential or
unprofitable IT projects
Cost reductions for IT project management by instituting a

project portfolio and a project management office (PMO)
Improved visibility into

project status and progress
A reduced number of IT projects, which fixes the common

problem of the IT organization working on more projects than the available
resources can support
More consistent completion of projects
Cost avoidance by earlier

identification of doomed IT projects
Requests for new IT services and assets handled more adeptly

by managing the demand portfolio
Reduced-decibel decision making by providing an organized

way for business stakeholders to communicate their needs and wants
Reduction in
shadow IT by helping the enterprise IT group better fulfill the needs of the
business
Reduction in the number of applications that are created by shadow IT but not
supported by enterprise IT
Reduction in the number of redundant data sources throughout

the enterprise
Reduction in outages when deploying new applications to production
Reduction in the
number of disjointed applications that businesspeople must use to do their
jobs
Reduction in the amount of swivel-chair, sneaker-net, or rip-and-read

integration
Reduction in the average age of the software versions of applications in the

portfolio
Reduction in the number of IT support incidents
Reduction in overall IT spending
Although
a few of these ideas are perhaps more qualitative than quantitative, almost all
of them can be used in some way to measure the success and effectiveness of an
APM effort.
Recommendations
An APM effort is usually initiated within the IT department,
and although the people or groups involved will vary, the enterprise
architecture (EA) group is often included. For an APM effort to ultimately be
successful, however, the chief information officer (CIO) must become personally
and actively involved in order to do the following
1 (#_37822) :
Assess the readiness of the company for APM (see the “

APM
Maturity Model (#_37817) ” section
of this overview for guidance on assessing an organization's APM readiness).
Assess
the current maturity of the APM process within the enterprise.
Assess the
capabilities of the team responsible for spearheading the APM effort.
Bound the scope

of the APM effort by setting reasonable, attainable, and measurable
objectives.
Create a charter for the APM effort that establishes what the effort will
accomplish and by when.
Create a detailed task list with milestones and assignments

of responsibilities for individual team members.
Create a communication plan to set

and manage expectations.
Select the tools that will be used in the current iteration

of the APM effort.
Validate the plans for the APM effort with the appropriate stakeholders.
To improve
overall project management in the enterprise, and as part of the APM effort, the
CIO should establish a PMO. The PMO should include certified project managers,
business analysts, and financial analysts. See the “
Establishing a Project Management Office
(#_37816) ” section of this overview
for guidance.
The CIO
should create an APM committee to drive the process. This committee could
include enterprise architects and members of the PMO. Initially, this APM
committee should be small and its work should start small, by carefully building
on successes along the way. To begin with, the APM committee will be responsible
for identifying the data sources and standardizing the data that the APM effort
is going to require. It should also determine the current APM maturity level and
identify the enterprise's specific APM pain points.
The work of the APM committee—the APM effort itself—should be

evaluated, measured, monitored, and improved on a continuous basis. The CIO
should change the makeup of the APM committee over time, to expand its work and
build on its successes. The “ APM Maturity Model (#_37817)
” section of this overview provides a RACI matrix that can serve as a starting
point for identifying and filling the proper roles within an APM effort.
The IT department will be

heavily involved in driving APM, but the effort will never reach its potential
if it is executed solely by that department. It is vital to the success of the
APM effort that senior business management buys into the ideas of both APM and
aligning the project portfolio to the business drivers. This means approaching
the business executives, gaining their support by identifying the potential
financial benefits of APM (and the costs of not adopting it), and leveraging all
of their experience and perspectives to drive the actual management work of APM.
For APM to flourish,

the organizational environment must be right. The “
APM Maturity Model (#_37817) ” section of this overview provides guidance
on the governance foundation that must be in place for an organization to
successfully adopt APM.
If any of those governance processes are not in place, it is best to provide

lightweight implementations initially. The idea is to create a wireframe of what
IT governance should be, by including the most critical functions and
experimenting with the governance processes before institutionalizing them too
rigidly. The goal is to make IT governance a partner instead of a roadblock to
development and to the business. The governance board should meet at least
monthly. These meetings are forums for assessing the APM effort, presenting new
project justifications, setting portfolio priorities, settling resource
disputes, discussing project status, and rescuing projects that have gone off
track.
If IT
governance processes are in place in some form in an enterprise, it is best to
integrate APM with those existing processes. The existing decision-making
processes for IT budgets and project funding can be easily and fundamentally
improved with the addition of APM practices.
One way to ease into an APM effort is to begin with an

application rationalization initiative. Application rationalization is a
smaller-scale effort than APM and can make an excellent primer for the larger
APM effort. For guidance on application rationalization, see the
overview, “
Application Rationalization: Burning
Fat and Building Muscle (http://www.gartner.com/document/code/203228?ref=ddisp&latest=true) .”
When it comes to
decisions about rationalizing or retiring software applications, make it a
matter of policy that software applications are retired based on established
retirement thresholds. (See the “ Thresholds for Application Retirement (#_37815) ” section of this overview for some examples.) Retiring
an
application may require the commitment of resources that are difficult to
justify. It may also require that a line of business be willing to suspend
functional releases during migration to a new application. Consequently, each
application's retirement tends to be delayed indefinitely. However, if an
application falls below a certain threshold for value, reliability, usability,
or technical fitness, its retirement can be designated as a simple matter of
policy and the resources required to decommission it can be much easier to
justify.
Likewise,
for decisions regarding in-flight IT projects, set thresholds for project
termination and then pull the plug when a project falls below the thresholds.
Effective management of the project portfolio means being willing and able to
kill projects that are not delivering promised value or that no longer fit the
company's strategic direction.
IT groups that are organized around major applications should transition to an

organization that centers on the demand, project, and application portfolios.
This will enable nonperforming projects and obsolete applications to be retired
without any significant organizational upheaval.
It is natural for people to resist the changes that APM

requires. One of the most effective ways to bring about changes is to reinforce
them with clear metrics and incentives based on desired behavior. Thus, it is
vital to establish key performance measures and track the metrics that drive
them.
It is important
too to continually demonstrate the success of the APM effort by publicizing the
APM maturity level that the enterprise has achieved and the value that the APM
effort has delivered for the business. Set the stage for this by selecting
appropriate metrics for your enterprise (see the “
APM Metrics (#_37800) ” section of this overview for some examples) and researching
carefully the “before APM” numbers for each of those metrics. Track those
metrics throughout your APM effort and publish them to keep stakeholders on
board and motivated.
Several software products on the market purport to address the needs of APM.
However, it is vital to understand that selecting an APM tool is not the first
step to effectively implementing APM. An APM tool will only be helpful after an
organization has a clear understanding of its own current APM maturity level and
pain points.
The Details
This section
explains application portfolio management (APM) in more detail and offers a
maturity model that can be used to assess and guide an enterprise's efforts to
implement APM. Also provided are some sources for further reading on topics
related to APM.
Overview of APM
This section provides an explanation of the three portfolios
that are involved in APM, a description of how the Stage-Gate process can be
applied to APM, examples of thresholds for application retirement, and guidance
on establishing a project management office.
Three Portfolios
Three portfolios have
direct bearing on the software applications in a modern enterprise: the demand,
project, and application portfolios.
Demand Portfolio
The demand portfolio is the newest
concept among the three portfolios. As a result, best practices have not yet
completely emerged around demand management.
The purpose of the demand portfolio is to improve satisfaction

among the customers of information technology (IT). The demand portfolio does
this by providing a consistent evaluation and fulfillment framework for IT
requests.
The demand
portfolio provides visibility for business stakeholders as well as IT managers
into all of the requests that are made of the IT group.
For a request to enter the demand portfolio,

it would need to be of a certain size or value. Minor requests for IT services
could be handled through some pre-established means and thus would not need to
clutter the demand portfolio. In fact, for a request to enter the demand
portfolio, it is usually necessary for a standardized IT project request form of
some sort to be filled out and submitted. In practice, great care should go into
creating this form. If the form is cumbersome, people will figure out how to
avoid using it. The schema of the form should reflect both the infrastructure
reality and development needs and should ask for no more information than is
absolutely necessary.
Demands for IT services can be driven by a wide variety of sources, including

top-down business strategies, needs for internal IT infrastructure, functional
requirements for lines of business (LOBs), software problem reports and trouble
tickets, and regulatory requirements.
In the demand portfolio, requests for IT services are

categorized into buckets according to their imperatives. These buckets have
names such as Strategic
, for top-down business

strategies, Mandated
, for regulatory
requirements, Operational
, for LOB requirements,
Maintenance
, for routine maintenance fixes, and
Infrastructure
, for IT infrastructure
requirements. The specific categories vary from company to company, based on the
way the company wants to track the demands being placed on IT.
Requests for IT services are broadly

categorized based on their potential value to the enterprise. They are also
broadly categorized according to risks inherent in the technology and
sophistication required for their implementation. The amount and type of IT
resources required to fill the requests are also categorized.
The categories for value, risk,

imperatives, and required resources can be correlated in various ways to
illustrate things such as the most valuable requests, the most easily fulfilled
requests, the most productive requests, the least risky requests, complementary
requests, overlapping requests, and so forth.
The people who have authority over the allocation of funds for
IT manage the demand portfolio. However, they do not wade through piles of IT
requests themselves. Instead, they establish the broad limits for the categories
for value, risk, imperatives, and required resources that a request must meet to
advance from stage to stage within the demand portfolio. In other words, the
managers of the demand portfolio set the gates for each stage. The “ Understanding the
Stage-Gate Process (#_37811) ”
section of this overview provides further information on the stages and gates in
the demand portfolio. The “ APM Maturity Model (#_37817)
” section of this overview provides a Responsible, Accountable, Consulted, and
Informed (RACI) matrix that illustrates who might fill the roles of setting the
gates and evaluating them.
Demand Management When IT's Shadow

Weighs 42 Pounds
The
term “shadow IT” refers to groups that provide IT solutions outside of the
formal IT organization. The existence of shadow IT is due in part to local
groups believing that they can do things cheaper or better than the enterprise
IT organization. Also, the enterprise IT organization may not be able to readily
meet the service requirements for a local LOB, or perhaps the formal IT
organization is forced to develop generic applications in an attempt to meet the
needs of everyone and is having trouble providing customized applications that
meet the needs of individual business units.
Whatever the reasons are for the existence of shadow IT in the

LOBs, it is a symptom of inadequacies in the enterprise IT group's delivery of
services.
The problem
with shadow IT is that its costs are under the budgetary control of the LOBs
rather than the chief information officer (CIO) and chief financial officer
(CFO). In such a case, IT costs are hidden and pet projects and political power
plays often override an enterprise's strategic objectives.
The traditional approach to reducing

shadow IT is to identify and eliminate the positions for shadow IT staff.
However, to deal effectively with the problem, an organization needs to
understand the reasons why the shadow staff exists.
Shadow IT staff is the leading indicator of inadequacies in

services provided by the enterprise IT group. If enterprise IT is not meeting
the particular needs of business units, managers will fill the gap by hiring
their own personnel.
Creating a specific group within enterprise IT to manage the demand portfolio

often helps eliminate shadow IT efforts. This demand management group can
evaluate each IT service request and look for commonalities among the different
requests in determining if there is a business case for an IT project. The
demand management group can also identify technology solutions that shadow IT
projects have created and that IT decision makers might consider when searching
for ways to supply IT services. By effectively managing the requests for IT
services, the need for shadow IT is eliminated.
Project Portfolio
IT projects are
evaluated based on the input and assumptions made in the business case for the
project.
Making Business Cases

Business cases can help provide rigor for managing the
financial risks of IT projects and are central to the process of undertaking the
right projects. A business case spells out the reasons for a project and defines
the metrics by which a project's value to the business will be judged.
A business case for a project

is created to convince those who control the enterprise's financial resources
that the project not only supports the enterprise's business goals and
strategies, but that it is also the very best place to invest scarce resources.
A business case
answers the following questions: Will this project result in improvements that
will save us money, defer costs, increase productivity, speed development,
and/or improve quality? If so, by how much, compared to the current state or
compared to industry averages? What are the alternatives? Why pursue this
option?
A business
case also includes quantifiable metrics for measuring the value of the proposed
software after it is implemented. Those may include metrics for measuring the
quality of the data that the software produces as well as the degree of
improvement that the software makes to the business processes it automates.
Detailed guidance on
creating business cases is beyond the scope of this overview, but the “
Related Research
and Recommended Reading (#_37823) ”
section of this overview lists some references that may be helpful.
A Portfolio View of Projects
In IT Portfolio
Management Step-by-Step ,
the authors Bryan Maizlish and Robert Handler explain that the project portfolio
“focuses on all the projects in development across a company and consolidates
one view of the overall value and risks.” Maizlish and Handler also state that
“the project portfolio serves as a gating mechanism for assuring projects are in
alignment with the strategic intent, assumptions in the business case are
adhered to, and decisions are based on accurate and timely data.” 1
(#_37822)
The “
Understanding the Stage-Gate Process
(#_37811) ” section of this
overview provides information on the stages and gates in the project portfolio.
The project portfolio

is fed by the demand portfolio and takes direction from the strategic business
plan and the strategic IT plan. The project portfolio feeds the application
portfolio.
Application Portfolio
The application portfolio provides a framework to catalog and

continuously monitor the business alignment, value, and costs of the company's
software applications. See the
overview, “
Application Rationalization: Burning
Fat and Building Muscle (http://www.gartner.com/document/code/203228?ref=ddisp&latest=true)
,” for guidance assessing the business alignment, value, and costs of software
applications.
Understanding the Stage-Gate Process

The Stage-Gate process can be used to
institute standard procedures for managing the portfolios.
The items in the demand, project, and

application portfolios move through specific stages in their lifecycles. The
stages and gates of each portfolio and their relationships are illustrated in
Figure 1.
Figure
1. Application Software
Lifecycle (Adapted from Maizlish and Handler's Graphic)1
In
Figure 1, the four numbered arrows represent:
1. Approved concepts moving from the demand

portfolio to the project portfolio
2. New applications moving from the project portfolio to the

application portfolio
3. The regular status reviews of software applications within

the application portfolio
4. Ideas for software application upgrades moving from the

application portfolio to the demand portfolio
The people who perform the evaluations of

items at each of the gates are going to vary in every enterprise. IT portfolio
management is a dynamic process, and people with varying functional perspectives
and abilities will need to buy into the process and work to help it succeed.
Finding the right people or group to perform the gate evaluations will require a
combination of pragmatism and experimentation. The “
APM Maturity Model (#_37817) ” section of this overview provides a RACI
matrix that can serve as a point of departure for deciding who might best
perform them. As that RACI matrix suggests, the people who currently make the IT
funding decisions will probably be many of the same people who perform the gate
evaluations in the project portfolio and the application portfolio. The IT
architecture group, working in conjunction with a strategic business planning
group, can perhaps best perform the gate evaluations in the demand portfolio.
In their book,
IT Portfolio Management
Step-by-Step , Maizlish
and Handler provide a useful explanation of each gate and stage in the
lifecycle.
1 (#_37822) The following is
a paraphrased version of their explanation.
Stage-Gate Process
for the Demand Portfolio
Gate 1:
Takes input and provides direction
to Stage 1.
Stage 1:
Opportunities for innovation are generated and captured, based on ideas,
needs, and gaps.
Gate 2:
Opportunities are captured in a centralized repository. Inputs from the
opportunity capture stage are analyzed, ranked, and prioritized according to
the categories for value, risk, imperatives, and required resources. Gate 2
concludes with a go, cancel, hold, or transfer decision reached by the
governing body.
Stage 2: Ideation,
where IT requests and opportunities for innovation are translated into ideas
for potential software applications.
Gate 3:
Concludes with a go, cancel, hold, or transfer decision reached by the
governing body.
Stage 3: Ideas are

assessed for feasibility. The assessment is broad at this point, because
detailed financial and technical data are not yet available. Preliminary
business case is started.
Gate 4: Governing
body assesses and prioritizes investments in the demand portfolio and makes a
go, cancel, hold, or transfer decision.
Stage 4:
Ideas are matured and refined so that the best ones emerge and the business
case can be developed further.
Gate 5:
Governing body assesses and prioritizes investments in the demand portfolio
and makes a go, cancel, hold, or transfer decision.
Stage 5: Concept is as mature as it can be without detailed analysis.

A standardized project request form that contains the relevant information is
filled out.
Gate 6 : Governing
body assesses and prioritizes investments in the demand portfolio and makes a
go, cancel, hold, or transfer decision. The ideas that receive a “go” decision
move on to Gate 1 of the project portfolio.
Stage-Gate Process
for the Project Portfolio
Gate 1:
Concepts receive their initial
screening into the project portfolio. Concepts are evaluated based on the IT
project request form. Governing body makes a go, cancel, or hold decision.
Stage 1:
Scoping and
preliminary analysis is performed.
Gate 2:
Governing body makes a go, cancel, hold, or recycle decision.
Stage 2
: Business case is created that
defines the solution.
Gate 3: Heavy
spending happens beyond this gate, so the business case is carefully
scrutinized. Governing body makes a go, cancel, hold, or recycle decision
based on the business case and available IT resources to carry out the
project.
Stage
3: Development
work creates the solution as a software application. The solution may be
composed of custom-developed software, commercial off-the-shelf (COTS)
software or components, open source software, or a software as a service
(SaaS) application and will likely include integration and data-loading work.
(For guidance on choosing the appropriate software form factors, see the
Application Platform
Strategies overview, “
Build, Buy, or Borrow: Choosing Custom Development Software,
Open Source Software, Commercial Off-the-Shelf Software, or Software as a
Service (http://www.gartner.com/document/code/203291?ref=ddisp&latest=true) .”)
Gate 4:
Monitors actual versus projected
costs, schedule, milestones, etc.
Stage 4:
Validation that verifies the application is ready to be moved to operations.
Gate 5:
Governing body
makes a go, cancel, hold, or recycle decision.
Stage 5:
Application moves to operations.
Gate 6:
Post-implementation review is conducted, which provides lessons learned to
appropriate personnel.
The project portfolio might appear here to depend on a

waterfall-type method of development and project management, but that is not the
case. Iterative and agile development methodologies can fit quite successfully
within Stage 3, and the other gates and stages in project portfolio can be
adapted as necessary to fit an enterprise's preferred project management
methodology.
Stage-Gate Process for the Application Portfolio
Gate 1:
Applications receive their initial screening into the application portfolio.
The metrics for measuring the business value of the application, as defined in
the business case, are verified. Governing body makes a go, cancel, hold, or
recycle decision based on the application's readiness to be moved into
operations.
Stage
1: The work of
initially deploying the application to operations is accomplished.
Gate 2:
Application is monitored for
early indications of trouble. Governing body makes a go, cancel, hold, or
recycle decision.
Stage 2: A review
of operational characteristics, requirements, and documentation is performed.
Gate 3:
Governing body
makes a go, cancel, hold, or recycle decision regarding the transition of the
application to standard operating mode.
Stage 3:
The application is monitored in terms of its operation and its business value.
Metrics for business value that were defined in the business case are
monitored, collected, stored, and reported.
Gate 4:
The business value that the application provides is regularly reviewed to
ensure that the application does not fall below any of the thresholds for
retirement. Ideas for improving the business value that the application
provides are fed into the demand portfolio.
Thresholds for
Application Retirement
When an application falls below one of the thresholds that an enterprise sets
for mandatory retirement, its retirement should be a matter of policy. Following
are some examples of possible retirement thresholds:
Inadequate technical
architecture, which makes it difficult for IT to provide the application
services such as business continuity, disaster recovery, security,
accessibility, quality of service, etc.
Labor or monetary costs to maintain the application that are

disproportionate with the business value the application provides
Lack of vendor support

for critical components of the application
Lack of ability for the software to

support requirements for service levels, regulations, or security
Lack of IT people who

are knowledgeable enough about the application to support it adequately
Overlapping or incomplete functionality, which makes it difficult for IT to

automate the business processes
Redundancy of or limited access to data sources, which makes

it difficult for IT to provide the information that the businesspeople need to
do their jobs
Incorrect software form factor (custom developed vs. COTS vs. open source vs.
SaaS) for the needs of the enterprise (for guidance on software form factors,
see the Application
Platform Strategies
overview, “
Build, Buy, or Borrow: Choosing
Custom Development Software, Open Source Software, Commercial Off-the-Shelf
Software, or Software as a Service (http://www.gartner.com/document/code/203291?ref=ddisp&latest=true)
”)
Establishing a Project Management Office

Project management
focuses on executing a single project, usually in support of a particular
objective, and is concerned with timelines, budgets, tasks, and deliverables.
A project management
office (PMO) is concerned with encouraging consistent project management
practices among all projects. This consistency not only improves the management
of individual projects, it also enables all the projects throughout the
enterprise to be managed in a holistic way within the project portfolio.
A PMO can be established with

very tactical objectives, such as upgrading the processes surrounding project
management in the enterprise and providing project mentoring.
It is vital that a PMO remain connected

to actual project work. The guidance from the PMO must reflect actual practice,
and that guidance itself must be subject to iterative evaluation processes for
constant improvement.
In terms of tactical objectives, the PMO might provide 3

(#_37822) :
An inventory of the
in-flight projects (new product development, information technology, business
enhancements, etc.)
Deployment of a project management methodology
Summary reports and metrics
project reviews
Brown bag
training lunches
Support for new projects and projects in need
project planning or project control

workshops
Identification and deployment of one or more pilot project initiatives
Templates
Later, the PMO

can grow to provide long-term solutions such as:
Process/methodology tailoring
and continuing development
Development of a training curriculum
Detailed reports/metrics
development
Resource management
Tool deployment
project manager career progression and certification
project portfolio management
Organizational change and transition planning
The PMO directly supports and enables the

project portfolio.
The
project portfolio may not enable a company to attain a project success rate of
100%, but it improves the successful track record of project investments and
helps companies learn how to “fail” projects properly and faster. 1
(#_37822)
APM Maturity Model

Achieving higher levels of APM maturity requires that both the
IT organization and the APM effort be assessed and improved.
Organizational Readiness for APM
Assessing the organizational readiness of an enterprise

involves looking at critical factors to determine how readily it can adopt APM.
These factors can be both descriptive and prescriptive, indicating the current
level of readiness of an organization and what can be done to improve it
1
(#_37822) :
IT plan and IT
principles documents
: Do these documents exist? Are they frequently evaluated and updated? Do
these documents explain how IT delivers value within the organization?
IT
governance committee : Does the company have an existing IT governance committee
that can be leveraged?
IT demand
: Is there a tie between the demands that business managers place on IT and
the strategic business plan?
Project prioritization process : Is this process in place? If so, is it resistant to

change?
Project management competencies

: Do these exist? If so, what level of maturity?
architecture
: Has a clear vision of the
enterprise's future been articulated through an enterprise architecture or
similar mechanism?
IT measurement program : Do metrics exist within the IT organization? Are they

reliable? Are they accurate? Are they precise?
Application catalog
: Is there an accurate
listing of IT assets, particularly software applications?
Leadership/sponsorship
: Is there strong leadership within the business and IT to support decisions
made with a portfolio approach?
Organizational culture : Does the organization's culture promote clear ownership

for IT decisions? What is the organization's tolerance for risk?
Operational
processes : Are
these processes stable enough to provide reliable data for portfolio
decisions?
Resources : Do
adequate resources exist to institute portfolio management (e.g., people,
funding, and time)?
Technology and support : Is there an adequate infrastructure and support mechanism

in place (helpdesk, networked services, integrated systems and solutions,
etc.)?
Management Roles
The various roles that must be filled
for APM to be successful can be illustrated in a RACI matrix in which:
R stands for the

person responsible—the person who has to do it
A
stands for the person accountable—the person who makes the final decision and
has ultimate ownership
C stands for the

person consulted—the person who must be consulted before a decision or action
is taken
I
stands for the
person informed—the person who must be informed that a decision or action has
been taken
A simple RACI matrix for APM is shown in Table 1. This matrix is meant to be a
point of departure only and will need to be expanded and customized for the
unique needs of each enterprise.
Table 1. RACI Matrix for APM-Related Activities
Senior business LOB IT investment IT architecture APM

leadership leadership CIO governing group committee
body
Business goals R/A C C I I I
R C I I
Business strategic plans A C
IT strategic plans C A R C C I
C C A R C I
Define the gate conditions
for the portfolios
Perform gate assessments C R C I

for IT application portfolio I A
Perform gate I C A R C I
assessments for IT project
portfolio
Perform gate C C R I
assessments for IT demand A
portfolio
Gather the data needed I C C R

to do portfolio assessments A
Following is a brief explanation of the organizational structure shown in Table

1. The people who decide the size of the IT budget and the ways in which it will
be invested are the “IT investment governing body.” Every modern enterprise has
people who perform these functions already. The “APM committee” is the committee
that the CIO creates to drive the APM process. The RACI matrix in Table 1
assumes that the IT investment governing body performs the evaluations of the
gates in the project and application portfolios to decide if projects and
applications should be discontinued or retired or if they are worthy to proceed
on to their next stage. The IT architecture group performs the evaluations of
the gates in the demand portfolio. The APM committee gathers the data that
supports all of these gate evaluations.
The structure illustrated in Table 1 should be tailored to fit

the unique needs and organizational structure of each enterprise.
Five Levels of APM Maturity
In their book IT
Portfolio Management Step-by-Step
, Maizlish and Handler offer an IT portfolio maturity model, a portion of which
is shown in Table 2. Their maturity model starts at level 0, because, they say,
most organizations start from nothing. 1 (#_37822)
Table 2.
Project and APM Maturity Model
Projects Applications
Level 0: Admitting The focus is on determining what projects are active and The focus is on determining which applications exist,
in the pipeline. This focus is on data collection. their purposes, and their owners. The focus is on basic data
collection.
Level 1: The focus of the project portfolio For the application portfolio to be at Level 1, a
Communicating is aggregating and interrelating the projects based on listing of all applications, replete with attributes that
available enable
information. A standard for obtaining project high-level decision making, is required. Candidate
information exists, but the attributes include
project management processes are not standardized. business value, technical condition, business processes
Initiative requests are supported, and
included as well. A basic yet consistent business case or affected data entities.
initiative
request form exists to support clear communication.
Project and Applications

Level 2: Governing program managers provide consistent information to are assigned owners. Processes exist to manage application
the portfolio manager. lifecycles, and
Processes with defined frequency exist to provide policies exist to provide business rules over application
consistency. Policy lifecycles. A
exists around providing project information to the defined process with named individuals and business rules
project portfolio. periodically
Policy also exists to support active portfolio reviews the application portfolio. An executive steering
management. An executive committee meets
steering committee meets regularly to provide strategic regularly to provide strategic information and decision
information and support.
decision support.
Level 3: Managing Metrics for governing processes Metrics for governing processes and key supporting
and key supporting processes are identified and processes are identified and captured, preparing for Level
captured, preparing for 4, where these
Level 4, where these metrics can be used to analyze and metrics can be used to analyze and optimize the APM
optimize the process. Applications
project portfolio management process. are treated as assets, with costs and benefits captured
against these
assets, much the way plant machinery is managed through
a maintenance,
repair, operations (MRO) system.
Level 4: Optimizing Project/program operations provide reliable

information Application performance and lifecycle information affect
supported by excellence in project management and the application
execution. The project portfolio; information from the demand and the project
portfolio reflects and is balanced against near-real-time portfolios is used
project to balance the application portfolio as well. Information
information. The project portfolio is tightly integrated from the
with the demand applications feeds into business process
portfolio and the applications portfolio. management/improvement
initiatives.
Conclusion
Linear
information technology (IT) planning, where applications are simply deployed and
then run forever, is not sustainable. Application portfolio management (APM)
offers a proven methodology for closing the feedback loop for legacy
applications in order to enable effective IT planning. APM can increase business
leaders' commitment to and ownership of IT projects and will help focus more IT
resources on high-value projects. APM not only enables the tracking of

technology as an investment instead of an expense but also promises greater IT
project success rates and greater positive impact of IT projects on the
business.
Notes
1 Bryan Maizlish, Robert Handler. IT Portfolio Management Step-by-Step: Unlocking the Business
Value of Technology .
Hoboken, New Jersey: John Wiley & Sons, 2005. 10, 16, 21, 23, 24, 29, 40,
43, 59, 126.
Richard Pastore, Lorraine

Cosgrove Ware. “Findings: The Best Best Practices.” CIO Magazine
. 1 May 2005.
http://www.cio.com/archive/050104/best.html (http://www.cio.com/archive/050104/best.html) .
3 Dianne Bridges, Kent

Crawford. “How to Start up and Roll out a project Office.” PM Solutions . 2000.
http://www.pmsolutions.com/articles/pdfs/project_office/startup.pdf
(http://www.pmsolutions.com/articles/pdfs/project_office/startup.pdf)
.
Related Research and Recommended Reading

Robert J. Benson, Thomas L. Bugnitz, William B. Walton.
From Business Strategy to
IT Action . Hoboken, New
Jersey: John Wiley & Sons, 2004.
Bryan Maizlish, Robert Handler. IT Portfolio Management Step-by-Step: Unlocking the Business
Value of Technology .
Hoboken, New Jersey: John Wiley & Sons, 2005.
Donald J. Reifer.
Making the Software Business Case
. Upper Saddle River, New Jersey: Addison-Wesley, 2002.
Lyn Robison. “Application Rationalization:

Burning Fat and Building Muscle.”
Burton Group . 7 Aug 2006.
http://www.burtongroup.com/content/doc.aspx?cid=942
(http://www.gartner.com/document/code/203228?ref=ddisp&latest=true) .
Lyn Robison. “Build, Buy, or Borrow: Choosing Custom

Development Software, Open Source Software, Commercial Off-the-Shelf Software,
or Software as a Service.”
Burton Group . 23 Apr
2007.
http://www.burtongroup.com/Client/Research/Document.aspx?cid=1056 (http://www.gartner.com/document/code/203291?
ref=ddisp&latest=true)
.
© 2007 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This publication may
not be reproduced or distributed in any form without Gartner's prior written permission. If you are authorized to access this publication, your use of
it is subject to the Usage Guidelines for Gartner Services (http://www.gartner.com/technology/about/policies/usage_guidelines.jsp) posted
on gartner.com. The information contained in this publication has been obtained from sources believed to be reliable. Gartner disclaims all
warranties as to the accuracy, completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such
information. This publication consists of the opinions of Gartner's research organization and should not be construed as statements of fact. The
opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner
does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders
may include firms and funds that have financial interests in entities covered in Gartner research. Gartner's Board of Directors may include senior
managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these
firms, funds or their managers. For further information on the independence and integrity of Gartner research, see "Guiding Principles on
Independence and Objectivity. (http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp) "

Application Portfolio Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Portfolio Management

Uploaded by

Copyright:

Available Formats

Application Portfolio Management#_37817 Página 1 de 22

Application Portfolio Management

Without APM, fewer IT

APM is a proven and well-accepted methodology that has become

Making these portfolios greater than the sum of their parts

Application portfolio management is a proven methodology for

What Is Application Portfolio Management?

Application rationalization is a subset of APM and specializes

The Need for APM

Despite its magnitude, business and IT

There are no other

APM can provide the discipline that a sizable IT investment deserves.

Many companies that have not

An overabundance of pet projects

A reluctance to kill projects or retire assets

Inconsistent criteria and processes for assessing IT investments

When it comes to IT investments, companies without APM are

Who is using which applications and for what

How many IT projects are in

The degree of each project's alignment with overall strategy

The reasons why the IT projects were

The criteria used to approve them in the first place

The results of a company's lack of

Key projects are not undertaken or are underfunded

Project risks are not properly considered

Inconsistent business cases

IT projects do not meet expectations

IT project deadlines slip

Flexibility to quickly reprioritize IT

This entitlement mentality in

An unchanging application portfolio means

The business suffers with IT systems that do not provide the

A lack of interoperability causes IT systems to fossilize

Solutions won't scale properly.

Weak links abound in the technical

Redundant systems increase errors and stifle flexibility and agility.

APM treats new IT projects and legacy applications as business

One of the ways that APM enables IT expenditures to decline is by providing a

The Macro View of IT Portfolio Management

Application portfolio , made up of existing IT assets, which must be managed

The roles of the demand,

The Stage-Gate Process

The items in the

The stages of the project portfolio are:

Business case creation

Launch and deployment to operations

The stages of the application

Before each stage, decision makers can insert a gate to

The idea is for proposals, projects, and applications that are

The Stage-Gate process can be

A maturity model can be used descriptively to ascertain an

Better support of business

Better distribution of IT investments among strategic,

Greater IT investment in strategic, high-value, and

Cost avoidance through more efficient software licensing

Cost reductions for IT project management by instituting a

Improved visibility into

A reduced number of IT projects, which fixes the common

More consistent completion of projects

Cost avoidance by earlier

Requests for new IT services and assets handled more adeptly

Reduced-decibel decision making by providing an organized

Reduction in the number of redundant data sources throughout