Portfolio Management is Top Priority for 2009
posted by Peter Mollins at 12:14 PM
This week Baseline published its top IT trends for 2009. Among the usual contenders for top spot (such as virtualization and Software as a Service) was Project and Portfolio Management. The reason cited for its selection was the need to oversee IT activities and allocate resources toward high-priority tasks – which stands to reason in these challenging economic times.
The linkage between Project Portfolio Management (PPM) and Application Portfolio Management is an interesting one. PPM focuses on helping development managers to monitor and control in-flight development projects. Application Portfolio Management concentrates on the allocation of development and related infrastructure resources toward business priorities.
As discussed previously, Application Portfolio Management is at its most effective when measurements are placed into their appropriate business context. This could include managing applications by the business process they automate or by the geography that manages the applications, or other contexts or combinations of contexts. So, we could uncover complexities within a high-value business system managed in India, and decide to allocate resources to correct the issues.
We can think of PPM’s project entities as being another grouping through which we want to manage APM. This isn’t to say that APM should replicate PPM functionality, but rather that the technologies can effectively collaborate by sharing metadata. Much the same way that APM doesn’t replicate BPM functionality simply because it reuses business process models as a way to structure metrics reports.
Let’s look at how this can be deployed. A CIO of a bank is under pressure to improve responsiveness. Using APM, he looks at change request backlogs as organized by business process and spots an outlier in the customer management business process. He decides to investigate further. He looks at metrics for this process and sees that complexity levels are especially troublesome in the portion that is managed in Brazil. He decides to reallocate resources to attack complexity levels and whittle down the change request backlog.
This is clearly when PPM would become involved. Managers can use PPM to monitor deliverables, outcomes, and other elements that are part of a development project. But in parallel, APM continues to play a critical role. We could now overlay a new grouping onto our software; in this case the grouping would be by project. So, we are now tagging the portion of our application portfolio that is encompassed by the newly introduced project. Then, as we proceed we can collect metrics associated with the grouping of our project. This means that we can use APM to monitor the trend of value, cost, and risk of the software that is being enhanced by our project.
We can even start to combine business contexts, for instance by collecting metrics from software within Project A that is managed by Team A versus software managed by Team B. We start to see within APM very interesting metrics about adherence to SLAs as a result.
The linkage between Project Portfolio Management (PPM) and Application Portfolio Management is an interesting one. PPM focuses on helping development managers to monitor and control in-flight development projects. Application Portfolio Management concentrates on the allocation of development and related infrastructure resources toward business priorities.
As discussed previously, Application Portfolio Management is at its most effective when measurements are placed into their appropriate business context. This could include managing applications by the business process they automate or by the geography that manages the applications, or other contexts or combinations of contexts. So, we could uncover complexities within a high-value business system managed in India, and decide to allocate resources to correct the issues.
We can think of PPM’s project entities as being another grouping through which we want to manage APM. This isn’t to say that APM should replicate PPM functionality, but rather that the technologies can effectively collaborate by sharing metadata. Much the same way that APM doesn’t replicate BPM functionality simply because it reuses business process models as a way to structure metrics reports.
Let’s look at how this can be deployed. A CIO of a bank is under pressure to improve responsiveness. Using APM, he looks at change request backlogs as organized by business process and spots an outlier in the customer management business process. He decides to investigate further. He looks at metrics for this process and sees that complexity levels are especially troublesome in the portion that is managed in Brazil. He decides to reallocate resources to attack complexity levels and whittle down the change request backlog.
This is clearly when PPM would become involved. Managers can use PPM to monitor deliverables, outcomes, and other elements that are part of a development project. But in parallel, APM continues to play a critical role. We could now overlay a new grouping onto our software; in this case the grouping would be by project. So, we are now tagging the portion of our application portfolio that is encompassed by the newly introduced project. Then, as we proceed we can collect metrics associated with the grouping of our project. This means that we can use APM to monitor the trend of value, cost, and risk of the software that is being enhanced by our project.
We can even start to combine business contexts, for instance by collecting metrics from software within Project A that is managed by Team A versus software managed by Team B. We start to see within APM very interesting metrics about adherence to SLAs as a result.
Labels: analysts, apm, application portfolio management
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home