What's Next? Executing on Your Decisions
posted by Peter Mollins at 1:50 PM
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.
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.
Labels: apm, application portfolio management
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home