Application Portfolio Management Knowledge – The Short Story on Software Entitlement Management

By (Chris) Krysztof Baczkiewicz, Eracent

In the process of entitlement utilization optimization, the core information that needs to be collected is the actual requirements for the software and the status of the software entitlements owned. This kind of knowledge is gathered in the process of Application Portfolio Management (APM).

Let’s discuss then what we learn from APM that is useful in the Software Entitlement Management.

What Functionalities We Need

The art of collecting actual needs from the business units is primarily a communication and education effort. Everybody wants it all. The biggest problem here is the language. Often, when we ask what the business units need, we get the answer that they need system X, when in fact they need just some functionalities from the system X. This is why this process requires multiple iterations.

In the first iteration, the users or business unit heads get a survey. The results of the survey are then processed to create a big picture of what users think they have. In the second iteration, we need to go back to the same people or just to their representatives and interview them to get more detailed information. If we have a common language, good understanding and a lot of luck, we get the information we need. Unfortunately, usually we need to step back and redesign our questions and provide some more information to the people that answer the question. It can be provided in the form of training or some kind of internal marketing. Then we repeat the survey and the interview.

The result we expect to get is the list of functionalities that the business actually needs and is possible to be expressed in the form of software requirements. The scope of information we collect includes the functionalities that are already in place as we need to prepare for the second step.

What Functionalities We Have

The first step provides us a self-learning experience and if we did a good job, we have a language to define software functionalities. We will use it now to describe what we have. Before we get to the actual analysis, we need to collect the information about the software titles we have in our organization. This is the standard part of the SAM work and nothing new, but it must be done to get further. Once we have it, we open a manual or other high level documentation and list the functionalities that are available in these products in the language we used to list the functionalities needed.

The goal is to check how many of the functionalities needed are already in the products. Therefore, we need to check the previous list (functionalities needed) and see what is covered and what is not. If step one was done we can ignore the detailed functionalities that are not on the list. Too much information does not help. We can collect this information for future use when we optimize the process itself, which is an additional investment. However, at this point, we have to collect the high level information about the functionalities that are not used for the disposition process.

Finally, we get the report on how much we need and how much we already have. It is important to remember that in case of entitlements, we also have to include the information about software volumes, types of licenses and potential limits of time, geography and other. For example, if we have a license that we can use only in the US, it will not cover needs in Europe. Also, if the contract is close to terminating it has to be included in the report.

What Functionalities We Use

Examining the functionalities we use can be a part of the needs analysis, but it is easier to perform when we have the list of functionalities available in the organization. We have to check how close the perception of the users is to the actual needs. The simplest test is to check if the software is actually used or not. This test is usually done automatically. The software that is not used should be reconsidered.

Be careful. The usage report should not be the final indicator. Reconsidering does not have to mean removing. It is better to treat the software not used as potential software to be acquired starting its lifecycle. A business case should be required for every product that is not used. This kind of approach verifies if the software is not used because it is not needed, or because of other reasons, like lack of training, or bad process. Still, the software that is detected as not used should be then monitored to check if there is any future change.

What We Do Not Need

It is important to have a working disposition process. The software that is not needed generates costs if it is owned or installed. The list of functionalities not used provides us the potential to reduce the volume of owned software and the additional, related costs like maintenance and support.

What is Available on the Market

Once we collected the information about the functionality gaps we have to fill, we can start the acquisition planning. The next step is to check if there are vendors that provide the functionalities we need and don’t have. We also have to check if there are vendors that provide better options for the functionalities we already have. It would be good to start from the assumption that we don’t have anything and then tune the choice to the current readiness of our infrastructure, including the state of ownership.

We are Ready

The change may be more expensive then the difference in cost between the currently owned product and the newly offered, cheaper one. Sometimes, the cost of maintaining the old software gets so high that it is better to remove it and introduce a new solution. Many factors have to be considered at this point including, but not limited to; infrastructure capacity, relationships and compatibility with other software, state of ownership, relationships with vendors, and the very important human factor. People may not be able to switch to a new product and maintain productivity.

What Licensing Options We Have

Once we decide what we want to have, we may go to the best of entitlements management, which is finding the best licensing option. This puzzle provides the most fun, but is the most difficult and risky. However, it is much easier to choose the right option if we have used the process and know exactly what we want.


This is not the end of how we can utilize knowledge from Application Portfolio Management. We can use the information about the trends and forecasting, we can calculate the value of the owned (or should I say licensed) software, and many more. Although there isn’t a great deal of detailed APM information on the internet, we can look into other portfolio management disciplines. This knowledge has been out there for a long time. It is particularly easy to get if the ITAM program is part of a general organization Asset Management program. The main thing to remember is that the more we know about the software needs and its value, the better entitlements we can choose.