View Profile
Application Portfolio Management as part of Application Transformation
In one of my earlier posts I talked about the 70/30 ratio and how IT leaders want to free up the 70% of vital IT budget which is currently being spent on maintenance of applications and infrastructure so that it can be used on innovation. In order to enable that I proposed three phases that the organization must go through: assess, modernize and manage. In this post I will zoom in on the assess component and talk about one of the key enablers of this phase -- Application Portfolio Management (APM).
Application Portfolio Management can mean many things to many people. To some people APM represents a project management approach – i.e. how do I effectively manage the projects or initiatives which are focused on delivering and/or changing my applications? Others may take a financial spin to this, looking at APM as a way to leverage financial management techniques to justify and measure the efficiency and value that each application provides to the organization in terms of cost and risk. Other disciplines may look at APM as a way to assess the complexity of the applications from a code or integration perspective. The bottom line is that APM can be all these things, and actually it is most effective when parts or all of these components are used and assessed in conjunction with one another.
I don’t normally blog about products (even though I work for HP). However, earlier this week HP made an interesting announcement– launching a combination of products and services in the Application Portfolio Management space. The reason I liked the announcement is because it highlighted/reinforced a few things we have been discussing here:
- 1. Many organizations today feel like they are bloated in terms of the number and type of applications they currently have to support.
- 2. If organizations don’t have a clear strategy around APM and the right tools to execute this strategy their ability to respond to change will be significantly reduced.
- 3. Rationalization of the application portfolio is key to agility and the secret to freeing up the current investment in maintenance (70/30 split). This may mean a renewed focus on retiring “unused” applications to free up valuable and costly infrastructure.
- 4. In order to make decisions about which applications are business critical we need tools and best practices to help guide us in our decisions so that we are not making “decisions in the dark.” Some of my colleagues within HP suggest using frameworks like APQC and the newly launched HP APM Tool because it has many decision making criteria included.
- 5. Decisions on which applications to keep should not be one-dimensional and should involve a variety of criteria such as business criticality (is this part of the core value delivery chain), functional complexity of the application (is this based on legacy code/infrastructure), risk of not supporting the application and but, certainly not last, financial cost of the application’s maintenance. (There are many more but I did not want to list them all here).
However, one thing that really came across to me from speaking to businesses who have successfully implemented an Application Portfolio Management approach is the importance of two simple but crucial items:
- 1. The value of automation as a key enabler of APM – from collecting the right data from within the application to making the business decisions, to the communication of decisions back to the business.
- 2. The importance of making APM a continual process – APM implemented as a one-off event will only bring so much value to the organization and will likely mean that they will get to a stage of “portfolio bloat” again in the next 3-5 years. Instead if APM is a continual process you can start to make progress towards making your organization lean and start leveraging the assets you own in an effective and cost effective manner.
It would be great to hear from the forum members on this topic, do you agree that automation and a continual approach to APM are success factors of an organizations application transformation?
Genefa I recently consulted with an organization that had undergone a rationalization of their application portfolio and a number of complaints became clear that I would appreciate your feedback on. One complaint was they were not clear what criteria had been used to pick one application over another as the corporate standard. There was a feeling the decision had more to do with politics than objective measurements. Second, as an organization with many shared service groups internally, that actually charge business units for their services, they believed that the application group that won the rationalization political war, had essentially been given a virtual monopoly and could charge whatever they wanted. Third, there were groups that were resentful at the very idea of corporate standards and didn't want anyone dictating to them what they should use, especially if they could find cheaper solutions. They also had problems with the schedule that the standard group dictated to them that didn't meet their own deadlines.
Do any of these items sound familiar or do you think I was dealing with a one off situation. If they are common complaints what would you recommend to avoid them, while rationalizing the portfolio at the same time, assuming there are rational reasons for doing so?
A lot of these points make sense and I have seen many customers struggle with these issues as a result of a transformation project. I’ll approach each issue in turn:
- 1.Organization Politics: this is probably one of the harder issues to resolve as it involves people and their emotions. A good recommendation in this area is to try and leverage some industry standard frameworks for making application retirement and retention decisions – frameworks such as APQC (http://www.apqc.org/). In addition to this it is essential to come up with scoring criteria for which applications to keep – weightings could include: cost of maintenance, business criticality, quality of the application (is this is a legacy app which will lead to more costs down the line i.e. it cannot be deployed on virtualized infrastructures etc). This way you can show that decisions were made objectively.
- 2. Charge Back: I have seen less of this model in organizations today as it requires quite a large shift in the organization’s operational model. However, that’s not to say this isn’t the goal for many transformational initiatives. I think in order to make this a success the “charge back” team needs to engage with the stakeholders on agreed pricing and packaging of the services and have consistency across the board.
- 3.Corporate Standards: this is an area which always receives push back, in particular with subject matter experts. The key here is to involve the stakeholders in the decision, to show them tangible reasons for why certain tools or methodologies were selected, and allow the teams some degree of freedom. For example, in the case of software development if you have a team that wants to work with new open source technologies vs enterprise software solution, you could allow this for certain projects. However, you have to then saw for any project which touches a business critical application or means other pre-defined criteria the “corporate standard” tools must be used. That way there is a degree of flexibility, but there is also logic to what could become chaotic. Essentially, the root cause of this problem is that organizations are still very soiled and they need to learn how to operate as single units vs competing entities who are singing the “I know better” tune.
One of the factors I get asked about when looking at Application Portfolio Decisions is "layer 8" - ie: the people factor
How much of a role does the people factor play in the decision making process in your experience?
One client I met with recently was keen to move forward with a rationalization project but it turned out that the training and change costs made it prohibitive.
What would you recommend to them?
People play a huge part in any sort of initiative or project as they act as the drivers behind the decision. Implementing a “Management of Change” initiative can be costly and time consuming in particular if it involves a lot of formal training etc. When it comes to training on new processes, systems etc implementing approaches such as “train the trainer” where a core group of people are trained and then they go back to the business and train subsequent others in more informal training sessions such as workshops, brown bag lunches etc can have a great impact and can reduce costs; also setting up a “self-service” SharePoint where stakeholders can go to find more information is a useful way of disseminating information or can act as a tool to distribute web based training (record something once and have it used many times over). These types of approaches can help keeps costs down and more importantly make people feel like they are part of an initiative, rather than having it forced on them. The bottom line is that a transformational project probably can’t be implemented at zero cost but costs can be kept down especially if you get the buy in of the team.
