IT Portfolio Management Model
– An Introductory Overview –
Overview
The goal of this white paper is to present a conceptual IT Portfolio management model.
IT Portfolio Management is one of the latest trends in Business Intelligence industry. The executive summary of a white paper published by Pacific Edge Software (www.pacificedge.com/solutions/whitepapers.asp) and Meta Group ( www.metagroup.com) states that:
“As the IT organization’s operating, maintenance and capital budgets represent an increasing share of the total corporate operating budget, chief information officers (CIOs) are under progressively more pressure to manage the IT organization as a business investment cent er. In doing so, CIOs and their business peers must rationalize investment choices and be able to manage the ‘portfolio mix’ of IT assets to optimizer the value to the business. This means that the CIO must know, at any time, their:
|
CIOs must adopt a portfolio management methodology and related processes that allow for the effective and efficient categorization of all IT assets (including human capital). The portfolio management process should provide sufficient analytical data to support a means for prioritising and sequencing the development and utilization of IT assets.
Portfolio management should be established on a framework-based toolset that provides the decision-making analysis to balance investment risks and costs with business value.
This toolset is necessary so the CIO can clearly articulate to the business the relevant risk-benefits tradeoffs and ensure the right projects are being funded, at the right time, at the right level of investment. ”
The Portfolio Management Model – Overview
The model provides a CIO with a structured dynamic view of an IT organization, by linking together its resources, assets, and processes.
Various IT solutions that offer portfolio management services tend to either cater to individual aspects of portfolio management, such as project and resource management, or blend them all together into a single reporting system. The problem that the proposed model is trying to solve is providing a convenient and resourceful representation of how all of the components of an IT organization interact and affect each other, rather than providing numerical data. The proposed model works in conjunction with traditional portfolio management techniques, but on a different, higher, level. Rather than being a part of the conventional approach, the model is a non-intrusive consumer and aggregator of its products. The model acts as an umbrella under which the resources and processes are assembled into a dynamic system and then analysed.
The centrepiece of the model is a project; it is through projects that all other objects connect to each other. In other words, projects “glue” the model together. At this point, it seems to be relevant to provide a description of what is considered a “project” in the model:
Definition of Project
The model does not discriminate against the project type, size, duration, or scale. Thus, any IT effort, that can be tracked and linked to any of the other model objects, is considered a project. New development projects, maintenance efforts, investigation tasks, bug fixes, prototype development – all of these activities would be labeled as a “project” in the model, if there is a record of their existence and related resources.
Portfolio Management Model Components
In addition to projects, as the model structure (see the next page) shows, the model operates with the following objects:
- IT Department/Organization composed of individual employees and development teams.
- Business sponsor: an internal or external business user that provides financing or sponsors IT projects
- External Support Unit: any internal or external non-IT organization that provides any kind of support for IT projects
- Hardware infrastructure: any group of hardware devices that supports IT projects
- Software infrastructure: any combination of built and purchased software modules that supports IT projects
Portfolio Management Model Usage
IT Portfolio management is a complex process. It involves:
- Having complete control over resource inventory
- Knowing where the risks and bottlenecks are
- Determining which projects and partnerships are most profitable in the long term
- Being able to define organization strategy based on the record of past achievement.
Inventory management is the most obvious application of the model, since the model provides access to all the resources that were available in the past and are present now. Users of the model are able to run reports on total and per/unit number of hardware units, software modules, employees, and projects.
The model also allows its users to identity high-risk spots, such as critical projects that are in danger of running out of schedule or over budget, overloaded infrastructures, and repeatedly unsatisfied clients. Running historical cumulative reports on which projects and partnerships have resulted in better ROI, makes it possible for CIOs to forge strategic alliances and dynamically reallocate resources to potentially advantageous areas of IT portfolio.
These, and other operations, are made available under the proposed model. Note, however, that the model does not define a concrete implementation approach. It simply offers a framework into which various systems can be plugged in. The underlying systems provide data collection, reporting and analytical tools; the model is what connects them all together.
To summarize, the models gives a CIO a better understanding of how all the parts of the IT portfolio interact and an ability to draw conclusions based on quantitative and qualitative analysis of relationship between the model’s objects.
IT Portfolio Management Model Properties
Four essential properties govern the model. The brief summary of these properties is given in the table below:
Table 1
Property name | Function |
Interconnection | How objects connect to each other |
Multiplicity | Number of objects participating in connections |
Composition | Nested object and multi-level linkage |
Timeline | Tracking historical relationship between objects |
The model graphical structure (Figure 1) is a snapshot outline with just two dimensions and singleton linking. In reality, the model maintains historical relationship between objects, which are linked by many-to-many connections.
A complete understanding of these properties and an ability to apply them is vital to a successful usage of the model. Used individually, or in a combination, these properties make the model flexible and powerful.
The properties are explained in detail and illustrated in the following sections.
Interconnection
Description
Objects in the model are linked to each other through projects to which they have been, or are currently related. Traversal of the path from one object to another is performed in the following step sequence:
a) Build incoming links from the source object to all the projects the object relates to
b) Build outgoing links from the projects identified in the previous step to related objects
c) Connect incoming and outgoing links
Multiplicity
Description
Relationships between objects in the model are plural. An object can be linked to one or more other objects. Combined with the interconnection property, the multiplicity property enables the model to link together all components of an IT portfolio.
Composition
Description
Some of the objects of the model are composite; i.e. smaller objects can be grouped into larger objects. Objects of the model could connect to either (outer or inner) level of a composite object, based what kind of output is expected from the model.
Illustration
Servers and firewalls could be combined into a single hardware infrastructure, while services and applications could be combined into a software infrastructure. A project, or another object through a project, could then link to either an infrastructure, or any of its components.
Timeline
Description
The historical relationships between the model objects are tracked through the history of closed or ongoing projects. A list projects, ordered by project start date and aligned along the time axis, is what advances the model into the dimension of time.
Using multiplicity and interconnection properties together with the model timeline allows running cumulative reports, making observations of and monitoring of the development, and record change history of various aspects of an IT portfolio.
Illustration
This is how a historical relationship between a business sponsor and all the software modules it has ever financed would be depicted:
Portfolio Management – Model Applications
Given below is a conceptual review of how the model can be applied to different aspects of IT portfolio management. The conventional project management disciplines – project risk management, resource (inventory) management, time and information management – are assumed the part of the underlying systems that implement the model.
Historical Relationship Management:
Leveraging partnership and identifying best performers
The model can be used to identify the most profit-generating clients – business users that financed the top ROI projects, sponsored large number of projects, and, overall, proved to be successful partners.
Once identified, these clients would become targets of IT solutions marketing and product solicitation efforts. Relationships with these clients will be cherished and leveraged to create long-term alliances and partnership. A similar strategy applies to external support units. Keeping track of projects, that benefited from the external support the most, allows a CIO or a PM to increase chances of project success and select the best partners and collaborators for the future projects
From the history of completed and failed projects, a CIO can identify the most effective project leaders, development teams and software vendors. When a new, critical project gets in the pipeline, the CIO would be able to assign roles and responsibilities to the best and most reliable performers, based on their achievement record.
Risk Management
One of the key benefits of the model is portfolio risk management, in which those areas of IT portfolio that pose risk to projects can be easily recognized, marked and avoided.
For instance, the model can prevent managers from jeopardizing critical projects by redirecting them to less riskier hardware and software infrastructures and assigning the job to the most reliable development team and the best project managers. In addition, project managers can use the model to:
- Identify over- or highly loaded hardware infrastructures
- Avoid contracting vendors that proved to be somewhat unreliable in the past
- Stay away from technologically immature or complex software components
- Assign critical projects only to resource-sufficient development groups
The timeline property of the model, which is essential in risk management, also provides statistical data that helps validate and justify risk management decisions taken in the past.
Inventory Management
Inventory management is the most obvious application of the model. For each type of a resource, the model can tell how many units of that particular resource are used now and/or how many there have been in a certain period of time in the past.
Multiplicity of model’s components controls granularity of the queries – total number of CPU per a hardware infrastructure, total number of people working on a family of projects, total investment into a software infrastructure and so on.
Data Mining, Decision Making and Control
The most important application of the model is enabling CIOs to take action, based on the data provided by the model. Here are just a few examples of how the model can be used to improve status of an IT portfolio:
- Re-allocating resources to the most critical areas – if a project is in danger of getting over the planned budget or going beyond the planned end date, a CIO can use the model to find available resources, either idle or working on less-critical things, and re-assign them to the failing project.
- Optimizer inventory
- Hardware and software – finding and redeploying, or getting rid of, hardware and software resources that are obsolete, underused or idle
- Human resources – answering such questions as “is the talent pool misused and people with right skills are not applying them to proper tasks? What percentage of a team’s time is spent idling between projects? Is there a pattern of such insufficiency?” Acting on these problems can significantly optimizer labour pool usage and increase project success rate.
- Improve ROI (squeezing) – locate model components that are not being leveraged in the most profitable way (an expensive piece of hardware used for a low-priority project) and improve the situation (make sure that this hardware unit is supporting critical or commercially gainful project).
Implementation Notes
In order for the model to produce practical results, the organization must have some kind of resource monitoring system(s) in place – project management software, enterprise resource planning systems and other IT portfolio management solutions – that currently allow CIOs to run status reports and financial analysis.
The model does not force any restrictions upon the kind of systems that are needed to support it, as long as there is a way to integrate and analyse results produced by those systems.
However, the implementation layer should be able to attach certain attributes to the components of the model. These attributes are needed to support the linking and aggregating mechanisms of the model. One of the examples of using the attributes is linking model components by using “Project ID” attribute. Thus, each project has a unique identifier, and other model components (resources, clients, hardware units and so on) have a list of identifiers of projects in which they have been or are currently involved.
Proposing detailed implementation guideline is out of the scope of this paper. Nonetheless, below are some samples of attributes that can be assigned to an arbitrary selected set of model components.
Table 2
Project |
|
Project ID |
|
Planned start date |
|
Planned end date |
|
Actual start date |
|
Actual end date |
|
Planned budget |
|
Actual budget |
|
Criticality |
Table 3
Hardware unit | |
List of related project IDs | |
One-time fees – purchase | |
Recurring fees – hardware lease, space rent, utilities, vendor support and so on | |
Capacity units – CPU, RAM, number of ports, hard drive parameters and so on | |
Date of purchase | |
Vendor info – stability, credibility |
Table 4
External application/service | |
List of related project IDs | |
One-time fees – purchase | |
Recurring fees – vendor support | |
License fees | |
Number of users and/or client applications (derived) | |
Load (operations [user hits, calculations, updates] per time unit | |
Vendor info – ranking by stability, credibility etc. | |
Technology affiliation (J2EE, .NET, mainframe and so on) |
Table 5
Internal application/service | |
List of related project IDs | |
Number of users and/or client applications (derived) | |
Load (operations [user hits, calculations, updates] per time unit | |
Technology affiliation (J2EE, .NET, mainframe and so on) |
Table 6
Resource | |
List of related project IDs | |
Hourly rate | |
Skill level / type | |
Title | |
Date of hire |
References
META Group/Pacific Edge (2002). “IT Investment Management: Portfolio Management Lessons Learned”. META Group, Inc.
Author
Denis Urusov is an Associate Director of IT Strategic Computing Organization of Bear, Stearns and Co. Inc, which is a leading global investment banking, securities trading and brokerage firm. Denis has over 10 years of software development and management experience. Denis holds an BA degree in Computer Science from New York University. He could be reached at durusov@yahoo.com
Copyright Project Perfect