Skip to main content

Portfolio Management & BRM

The purpose of Portfolio Management, when applied to Provider investments (especially, IT investments), is a central mechanism to an overall Value Management approach by making investment allocation explicit against strategic choices such as how much to invest in potentially high value, but usually risky initiatives versus safe but low-value activities.

The Service Portfolio represents the complete set of services that are managed by the service Provider.  It is used to manage the entire lifecycle of all services and is defined by three categories of services.  The service pipeline represents service that is under consideration (purposed) or those that are currently in development but are not yet ready for deployment or consumption by the business partners. The next category is the service catalog which represents all live services or services that are available for deployment to the business partners. The final category is retired services.  This represents the services that are currently in the process of being retired or those that have been retired.

There are many methods to classify a Portfolio for Information Technology.  Choosing and implementing a Portfolio scheme is a way to clarify what is of strategic importance to the business partner and is an important contributor to demand shaping and investment prioritization.   In an earlier blog, I referenced the IT service portfolio as one of the four elements in the Business / Provider alignment model that help to ensure alignment between the Business Partners needs and the Service Providers capabilities.  Here we are going to utilize the Weill/Broadbent Classification Scheme and take a deeper dive into the four elements of the Service Portfolio.
  
Infrastructure:
Peter Weill defines infrastructure as, “The base foundation of budgeted-for IT capability (both technical and human), shared throughout the firm as reliable services, and centrally coordinated.” This is quite different from the common usage of the term infrastructure, but it gets to a powerful and strategic way of thinking about the topic. (1)  Infrastructure investments underpin the services delivered to the business. Their objective is to provide the base foundation of shared IT services.  This base foundation suggests that all other capabilities are built upon and depend upon this base. Organizations try to cost-justify infrastructure. This can be quite difficult.   It’s the things that infrastructure lets you do that create the value. In other words, it is the services that allow you to deliver value, not the infrastructure. Some other important aspects of the infrastructure are what we budget for, that it is shared throughout the entire organization and that it should be centrally coordinated but not necessarily centrally managed.

Transactional:
These represent traditional IT services such as payroll, accounting or sales order processing and represent a major part of the service portfolio.  These services are normally low risk, not usually associated with a significant change to the way the business operates and the main objective of their investment is to reduce the cost of doing business through some type of automation.

Informational:
An increasingly important class of investment today.  They provide the business with better, more accurate and up to date information by synthesizing data generated by the transactional services into information which can be analyzed and create knowledge and wisdom for both the business partner and service provider.

Strategic:
These investments are ones that can provide the business with a competitive advantage in the market space, sometimes by radically changing the way a business can operate and compete. A strategic investment is one that the completion must somehow respond to or face the loss of significant market share or some negative impact to their brand or reputation.  We must remember that these types of investments also come with very high-risk factors.

By looking at the services offered in this light, it allows the Business Relationship Manager (BRM) and the business to be able to better understand how to invest the resources across the portfolio while doing the appropriate risk assessments, yet ensuring an appropriate Return on Investment.

(1)    Leveraging the New Infrastructure: How Markets Leaders Capitalize on IT - By Peter Weill & Marianne Broadbent.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…