What's Next? Executing on Your Decisions

We’ve explored how application portfolio management helps IT leaders determine development priorities. But deciding what to do is only half of the equation. There must be follow-on actions that turn decisions into results. Let’s take a look.

Identifying the Problem

At this stage in the application portfolio management lifecycle, we’ve identified goals, questions, and metrics. We have also collected the data to generate the metrics, and perhaps we’ve trended our data. Different users in the organization were then able to spot service level agreement violations. Then priorities can be passed to different team members to isolate and correct issues.

Let’s take an example. An insurance company’s CIO looks at her dashboard and notes that business user satisfaction has degraded for the Claims Processing system. She passes this issue to her direct reports to determine if there is an underlying IT problem. Here the violated service level agreement could relate to percentage of satisfied users, or level of stakeholder dissatisfaction, for example.

Focus Attention

The manager then receives the issue from the CIO. He decides to investigate the Claims Processing system to determine if issues do exist. He looks at his own dashboards for the system. His goals concentrate less on cost and satisfaction issues and more on technical topics like throughput of change requests and application performance.

As he investigates, he discovers that there has been an increased backlog of change requests. Further, the application has been frequently down and non-performant at critical times. He drills down still further within his dashboards and discovers that the system is inefficiently architected. Tight coupling between programs means that any change to a given sub-system affects dozens of others, slowing the implementation of changes requested by the Claims Processing line of business owners.

He sees metrics that show that experienced developers are being redirected away from implementing change requests. Instead they are focused on maintaining their aging and un-strategic Account Management system. As a result, the development team is unable to work on what matters most to the business. Now, the manager understands the scope of his problems.

Prioritize Actions

Once the manager has determined the root causes of the issue, he may compare the various issues with other key metrics like resource availability and importance to the business. Using project management tooling in conjunction with application portfolio management metrics supports this sequencing.

Now, our manager has decided to take a two-pronged approach to resolving the issue. First, he plans to launch a renovation project to re-architect the Claims Processing code. The purpose of which is to lower its complexity and facilitate faster responses to business needs. Second, he plans to improve the effectiveness of the team working on the Account Management system so that senior developers can concentrate on the higher-value Claims Processing system.

Execute Tasks

While this discussion won’t focus on how to execute modernization tasks like those described above, it is important to note one aspect. Regardless of the kind of modernization project that is undertaken, there is one common factor. Each requires detailed insight into the reality of the application portfolio.

This returns to a key best practice, which is that each member of the IT organization requires insight into their applications to facilitate their job. A CIO needs highly-abstracted views and measures of the application; a developer needs highly detailed insights into the technical reality of the application portfolio.

So, to enable the renovation activity, we need “bottom up” insight into where complexities and inefficiencies lie within the application code. To enable the reallocation of senior resources, we need “bottom up” insight into applications to help junior team members to become “instant experts” on their applications and hence more productive. Keeping this bottom-up info in the same repository as the top-down data improves collaboration.

Monitor Activities

Now we have identified, prioritized, and executed modernization activities that correct our service level issues. We should treat these modernization activities as monitorable events themselves. For instance, the manager could track the change in architectural complexity as the renovation project proceeds and the throughput on change requests. The CIO similarly could re-survey stakeholders to determine changes in perceived value of the system.

Lastly, we can maintain a “continuous improvement” program where we look to find the next issue that threatens our service level agreements.

Conclusion

As we’ve seen over the course of this series, application portfolio management is a powerful way to regain control over the systems that run your business. It helps to identify, prioritize, and correct issues in your applications before they become business issues.

A critical aspect to recall is that application portfolio management applies at different levels of abstraction. So, it applies equally to CIOs as to developers. It is beneficial for organizations with sophisticated planning and those with limited structures. It helps business analysts and technical architects. It does that because it provides the kind of information users need to make smarter decisions for IT and for the business. As such, it is a keystone for effective IT management.

How Maturity Affects Portfolio Management

Application Portfolio Management helps you to identify where systems aren’t achieving technical and business goals. In previous posts I took a look at how to define those goals. We then investigated how to collect metrics that spot where goals aren’t met. We also looked at how goals and metrics are influenced by your role and level in an organization.

In this section, we’ll take a look at how portfolio management best practices are influenced by timing and the maturity of your organization’s decision-making processes.

How maturity affects goal definition

IT’s goals change based on the maturity of its planning. An architect may decide to boost the flexibility of several applications. This goal may come from his personal knowledge of a developer’s struggles with modifying a system. Goals at this level of maturity may be worthy and can generate results, but they are not necessarily aligned with corporate strategies.

In contrast, organizations with more mature planning will take a “top-down” approach to goal generation. They will start with general corporate principles and ensure that divisional and team goals support the overarching needs. For instance, a corporate goal may be to ensure that new product launches can be supported by IT within 2 weeks from submission.

Such a top-level goal would inspire subsidiary goals for different teams and roles. The architect may define his goal as reducing dependency levels and improving layering of applications. Development teams may set as their goals a specified turnaround time for change requests. Both goals are set in order to conform to the overarching strategy of boosting business flexibility.

The result of the more mature approach is that goals are aligned with higher priorities, lowering the likelihood of sub-optimal priorities. But also, it permits a more granular approach to managing goals. A CIO can spot where strategic goals are not being met, divisional heads can determine where these issues lie, and managers can locate root causes.

How maturity affects metrics collection

New goals are added or organized as your decision-making matures. This means that new and different metrics will need to be collected. In general, this simply means the same process as discussed previously where you follow a goal / question / metric approach. Though, now you may be doing it for more goals – or at least more coordinated goals.

There is another aspect to how maturity affects metrics collection. This relates to the quantity, timing, and kind of metrics that are collected. Let’s take a look:

• Quantity: An organization’s goal may be to reduce infrastructure costs for an application portfolio. In that case, a mature organization that wants exact results – or has already plucked the low-hanging fruit – will ask many questions to achieve the goal. “Which applications are duplicates?”, “Where is dead code?”, “Which applications cost the most to operate?”, “Which applications are most valuable?”. But for an organization that is just beginning the portfolio management process, a simpler set of questions can get you fast returns without the need for refinement. In that case, simply asking “which applications are duplicates?” may be sufficient.

• Timing: An organization with mature decision-making will likely investigate trends over time. For instance, monitoring the turnaround time on change requests for multiple development teams. A less mature organization will likely (often out of necessity) make decisions based on snapshot measures. Trending supports better decision-making, but again some decisions can be made based on less rich data sets. It will depend on the degree of accuracy required and risk-tolerance.

• Kinds of Metrics: Let’s look back at the three kinds of metrics sources for application portfolio management. They are surveys of stakeholders, data from related tooling, like ALM tools, and lastly data from the applications themselves, like complexity measures. To support a snap decision about which applications you should retire, you may rely on surveyed opinions only. Or, to determine where to re-factor an application you may harvest only code complexity data. To support a complex decision about which outsourcer to standardize on, you may need richer datasets that come from all three data types.

As your application portfolio management process develops you will see increased returns. Better decisions lead to lower waste and bigger business results. But critically, this doesn’t mean that value is low when you are starting your journey. In fact, it is the opposite. Returns generated by early decisions can be turned into reinvestment in improved business intelligence.

As your process matures you are always going to balance the projected returns versus the cost to collect the data. Taking an incremental approach and focusing on high-value goals early will help this process.