The Forum - 05/08/2008  (Plain Text Version)

Return to Graphical Version

 

In this issue:
Lead
•  President’s Corner – An Industry, A Profession and a Responsibility
Featured Columns
•  From the Editor’s Desk….
•  For Our Members
•  Focus on Three
•  Organizational Gatekeeping: itSMF USA Governance
•  Interest Group (IG) Services Update
•  San Francisco, Here We Come!
ITIL®/ITSM Related Articles
•  Service Strategy – The Intended Outcome
•  How to Justify Getting Started with ITIL® by Thinking Outside of the IT Box
•  Thinking Strategically about Services
•  IT Service Management: Where do we begin?
•  An old friend called Project Management: Bringing Project Management into ITIL® v3
•  ITIL® Strategy Needs to be Strategically Planned
•  Do’s and Don’ts - Business Service Management
•  Six Sigma and IT Service Management: Don’t recreate the wheel…just spin it a little faster and better!
LIG News
•  Practitioner Discussions Bring Wisconsin LIG Interests Into Focus
•  Speakers Needed for Ohio Valley LIG Professional Day on June 5
•  Growing Strong: National Capital LIG and ITIL®
•  itSMF New England LIG and Harvard University Host "Improving Process in Higher Education"

 

Focus on Three

By Majid Iqbal, Senior Director, Gartner Consulting, and the Forum Committee
For the May issue of The Forum, our focus on ITIL® v3 leads to a discussion with Service Strategy co-author Majid Iqbal, answering the seven most frequently asked questions (so far), as shared by The Forum Committee.

For the May issue of The Forum, our focus on ITIL® v3 leads to a discussion with Service Strategy co-author Majid Iqbal, answering the seven most frequently asked questions (so far), as shared by The Forum Committee.

1.    How should the Service Strategy process relate to existing Enterprise Architecture and Governance?

What you refer to as the “Service Strategy process” involves four major areas of actions by any service provider including IT organizations:

Define the market
Develop the offerings
Develop strategic assets
Prepare for execution

Success in these areas requires IT organizations to truly think and act like the business units or enterprises they aim to serve. An IT organization’s enterprise architecture and governance capabilities can be useful in each of these areas.

First the tool kit of enterprise architects would be instrumental in the systematic analysis of the customer’s business processes, organization, and operations; not just the structural relationships but also the underlying dynamics. That’s something enterprise architects are good at. They’d help answer questions like, what is the relationship between business outcomes, business processes and various constraints on performance. That helps identify the potential for services and the opportunities and challenges associated with them. In short, it helps you define the market for services within your customer’s business environment or network.

Similarly, developing the offerings in the form of a Service Portfolio requires both modeling and representation of the Service Portfolio in terms of the customer’s business outcomes and business assets. Instead of describing services in traditional terms such as application development, help desk, desktop and infrastructure, you must describe services entirely in terms of what value they present in the context of business outcomes for customers. This again requires systematic analysis and decomposition of value into specific components each supported by one or more services or service level packages in the catalog or pipeline within the portfolio.

There is also the need for a decision-making and policy framework that will appropriately allocate roles and responsibilities related to the service lifecycle, service portfolio and contracts or agreements. This is to ensure the IT organization’s capabilities and resources are deployed towards developing and maintaining offerings that best serve the present and future interests of the internal market defined earlier. For example, the resulting governance will also ensure that the decisions and objectives of Product Management (ownership of the Service Portfolio) are not directly in conflict with those of relationship managers (ownership of customer needs). 

There is use for enterprise architecture and governance in the remaining two areas to the extent that the development of strategic assets and preparing for execution involves sets of analyses, models, decisions and policies that could benefit from both disciplines. However, one must be careful not to reinvent the wheel for what is plain and simple business development, planning and execution within an IT services context, as you’ll hear from CIOs and their deputies who come from a business management background.

2.    When should organizations start with Service Strategy (typically they start off with Service Operation)?

Organizations should consider Service Strategy when they are ready to question the basis of their long-term relationship with customers. 

According to Michael Porter, “operational effectiveness is necessary but not sufficient.” Improvements in operations takes an IT organization incrementally closer towards certain performance frontiers at which they are forced make trade-offs such as quality versus cost, innovation versus reliability, and flexibility versus control. There is always a risk of being caught in a cycle of improvements where value is measured in relative terms; success in terms of short-term gains or simply the avoidance of costs and risks.

Customers meanwhile face challenges and opportunities, new and modified. Risk is not only about possible losses but also possible gains for them. They take for granted operational effectiveness, efficiency, reliability and control. They expect more of IT organizations already “maxed out” at the performance frontier. When they do not perceive any new form of value, all that remain visible to them are costs. Funnily enough, IT managers are frustrated about customers being “cost-conscious.” There is bitter irony in the effectiveness of the IT chargeback system. Time to open the Book of Leaves: “ITIL® Service Strategy.”

To break through frontiers CIOs require their organizations to scrutinize the fundamentals or “ways and means” of their customer’s business and those of their own. It is time to do that when two or more of the following conditions are valid:

  • Performance meets or exceeds expectations; customers still question value of IT
  • CIO is anxious about meeting expectations; IT budget cut by 10%
  • CIO is worried about meeting expectations; IT budget increased by 20%
  • Customers are not happy at all; the “seafood buffet” is losing money
  • Customers are very happy; the “seafood buffet” is still losing money
  • CIO reports to the CFO; vice-president of HR reports to the CEO
  • CFO questions increased spending on heating, water, electricity and IT 
  • Meeting with CEO concludes with “Perhaps IT should provide services instead”
  • Customer adopts a service-based business model and strategy
  • Shared services model for Finance, HR and IT; must offer market-based pricing
  • CIO reports to the CEO; vice-president of HR reports to the CIO
  • New business leadership is a strong advocate of outsourcing
  • “Zero-incident days”; no longer win trips to the Bahamas
  • A permanent state of surprise with respect to demand; type and quantity
  • When the business sneezes, IT catches a cold 
  • Customers refuse to be “ITIL®-certified”; they think CMDB is a growth hormone
  • Customer inexplicably mumbles “Service Management as a strategic asset”

That it is logical for organizations to start with Service Operation is the prevailing notion. The word "operation" suggests a certain immediacy and a "roll up your sleeves and get down to it" sentiment. Otherwise one may start with the guidance provided in the Service Transition book, for example, and be just as successful in securing some immediate gains or improvement. From a broader perspective the need is for an integrated approach to Service Management as required by the ISO/IEC 20000 standard. For such an approach the Service Strategy book provides the business context, justification and long-term objectives for service management to be developed as a strategic asset of the IT organization (not just the starting point for the Service Lifecycle).
 
In summary, a 100-year old family business, a multi-national corporation, a start-up enterprise, or even a government agency would not think of operations without already having considered a value proposition, a business model and a strategy. Operations are then about planning, execution and control to take advantage of the opportunities that customers provide, while managing associated costs and risks. As IT organizations increasingly behave like business units you’ll find they view themselves in much broader terms than operations. 

3.    What is the distinction between Service Portfolios and Product Management?

Service Portfolios and Service Portfolio Management are the primary concern of Product Management. Product Managers own the Service Portfolio and by definition the Service Catalog and the Service Pipeline. This is one area where ITIL® and ITSM have caught up with broader industry practice.

With the lifecycle approach to Service Management there is a need for single ownership of a service throughout its lifecycle and economic life. From the conceptualization to retirement, Product Managers coordinate with various groups within the IT “business unit” to ensure the right services are being offered, with options or service level packages suitable to various user profiles within the customer’s business. 

It is also important to distinguish between a Service Portfolio and its Service Catalogs. Portfolios represent all the investments made by an IT organization (or service provider) across the Service Lifecycle; various streams of present and future cash flows from customers and contracts. The Service Portfolio also signifies the capabilities and resources under the command and control of the CIO. Service Catalogs on the other hand are views or windows customers look through to find and procure available services and choose options. With a few exceptions, such as services under transition (in or out), the Service Catalog presents services in the Operation phase of the Service Lifecycle. There may be multiple views or presentations of a single Service Portfolio, and therefore multiple Service Catalogs organized by customer, contract or market space.  Product Managers have to carefully consider the design of the Service Catalog based on the target.  However, they all have one element in common: they are meant to attract and capture demand.

Product Managers have a strong influence over design and engineering of services just as they are instrumental in defining the internal market for services. This also means they have the primary responsibility for estimating lifecycle costs and projected revenue or income for the services through market-based pricing or simple chargeback. So the decision to introduce an item into the Service Portfolio or remove from it from the pipeline is primarily based on the analysis made by Product Managers.

Product Managers do not simply own a service; they also have responsibility for analyzing, forecasting, and influencing demand for it. Product Managers work very closely with operations on decisions concerning the capabilities and resources underpinning a service (i.e. service assets and configuration items). The unit of analysis for Service Portfolio Management is not a single service but a balanced set of services with long-term goals and metrics.

4.    For organizations that do traditional Financial Management and plan to move to Financial Management based on services, what are some of the pitfalls and gotchas?

ITIL® Financial Management is now as much about analysis, valuation and optimization as it is about accounting, charging and budgeting.  And then, as you’ve pointed out, the focus is on services. In other words, the service is the primary unit of analysis and discussion. Now that Demand Management and Service Portfolio Management are key capability areas, there are additional requirements for Financial Management in terms of evaluation, modeling, reporting and approvals. This should not be surprising since ITIL® is supporting the trend where both CIOs and their direct reports engage fully with managers in business units and strategic planning. So Financial Management is expected to support a more rigorous analysis of investments in the Service Portfolio, provide more visibility into cost structures, and provide a higher level of planning confidence across the Service Lifecycle. This includes ensuring proper funding of the Service Pipeline and Service Catalog and assignment of appropriate cost recovery or return on investment objectives. Financial analysis is extended to the design and configuration of services for the purpose of service provisioning optimization and variable cost dynamics (e.g., sensitivity analysis).

The single most significant change in Financial Management is asking the question “What’s this service worth to the customer?” instead of only asking “How much will it cost to deliver the service?” Value-based pricing is harder to effectively implement than cost-plus. However, it truly aligns the objectives of a service provider with the outcomes of the customer.  So even when implemented with limitations it represents an advancement in the relationship between business and IT. Besides, if financial policies allow, service valuation can drive better portfolio management decisions and prepares IT organizations for competition with commercial service providers.

5.    What are (or should be) the necessary CSFs and KPIs to help ensure that the Service Strategy aligns to the organization’s Business Requirements (this would include any Governance, Standards and Management details)?

First it is important to clarify what we mean by alignment. IT organizations will implement decisions and policies that will position them to be in support of the business needs of their customers through a portfolio of services. This implies the interests of the IT organization could be misaligned, possibly even in conflict, with those of customers being served. This provides us a broader perspective on critical success factors by examining not only the factors driving alignment but also those that constrain. Organizations after all are social networks of groups and individuals acting in their own self-interests. Curiously enough, internal IT organizations can be more misaligned with their business units compared to commercial service providers governed by explicit terms and conditions in contracts. With that in mind the following are a few critical success factors for alignment:

  • Business Relationship Manager (BRM) with focus on business outcomes and associated demand for services, and sufficient independence to have the confidence of customers.
  • Service Catalog is defined in terms of business outcomes for customers or associated performance drivers. Customers understand how the services and options they select can have an impact on performance and outcomes.
  • Business outcomes are mapped to items in the Service Catalog linking business needs (demand for services) and solutions (capacity to fulfill demand). 
  • Demand Management to identify and qualify business needs for fulfillment while minimizing delivery costs and risks. 
  • Service Portfolio Management and Financial Management with authority and responsibility to respond quickly to close gaps in fulfillment of business needs. 
  • Risk management policies and controls to ensure commitments to customers and compliance with regulations and standards are not jeopardized.

Given the above critical success factors for alignment, key performance indicators (KPI) such as the following should offer visibility and control over service delivery outcomes:

  • On an index that tracks customer dissatisfaction due to un-served or under-served business needs, there is a significant reduction in the index score.
  • On an index that visualizes the extent to which the Service Catalog presently supports demand from customers, there is high coverage. 
  • On an index that tracks demand for services, there is an increase in the scale or scope of demand for more than X% of services over Y consecutive periods. 
  • On an index that tracks the cost of Changes to services in the Catalog, there is a reduction in the unrecoverable costs of accommodating business needs.

6.    What are the main components that would make up any “packet” of information that would/should be passed from the Service Strategy to Service Design to help ensure that these are in alignment and that Service Design is maximized for success?

At the highest level of abstraction, the aim of Service Design should be to codify strategic intent into the Service Portfolio. In other words, when Service Design is effective it will encode the strategy of the IT organization into the Service Catalog and the Service Pipeline, so that every service is designed to meet specific objectives.

In more concrete terms, Service Strategy defines the internal market, the service offerings and the service assets that will be deployed through the Service Portfolio. It also defines policies and guidelines for each line of service or market space covered by the Portfolio and expectations in terms of finance and operations. Service Strategy also provides high-level guidelines for the design and development of services, including but not limited to technology, architecture, automation, packaging, chargeback/pricing, delivery models, support models, and infrastructure.  These inputs from Service Strategy define the skeleton or frame for the Service Design Package which when fully elaborated in the Service Design phase.

7. What were your biggest learning experiences in writing this book?
As an author my biggest learning experience was that if you don't explicitly label something a "process" it will not register in the minds of many people. They will skip entire chapters of the book if you don't at least include sections titled "objectives," "inputs" and "outputs." I am being cheeky of course, but there is lot more in the Service Strategy book than just Demand Management, Financial Management, Portfolio Management and "Strategy Generation." There is valuable guidance in the Service Strategy book crucial for an IT organization to transform itself into a "business unit." There is guidance on how to implement strategy across the Service Lifecycle, particularly through Design, Transition and Operation. There is good guidance on Risk Management, organization development, automation, analytics, and design principles for services. However most descriptions or models suggest simply the book has four processes that link IT strategy to business strategy. That's partly because my co-author, Mike Nieves, and I were stubborn about not labeling all those sections as "processes." If I could do it again, I’d probably use the process label more liberally just to make the book more "accessible."  I'm sure Mike would agree.

 

About the Author
Majid Iqbal
works for Gartner. He is a consultant and subject matter expert on Service Management, organization and strategy.  He is co-author of ITIL® Service Strategy with Michael Nieves of Accenture. At Gartner, Majid advises IT organizations in industry and government on how to develop and improve their capabilities in Service Management; on organization design and development; and on developing service-based business models and strategies. Majid was instrumental in infusing ITIL® with business fundamentals and practices such as outcome-based service definitions, service assets, service potential, utility, warranty, product management, demand management, business activity patterns, and service level packages. Majid is visiting faculty at Carnegie Mellon University and presently serves as Senior Examiner for the ITIL® Qualification Scheme. He previously served on the ITIL® Advisory Group (IAG) and the ISO/IEC Study Group (JTC1/SC7) on ISO/IEC 20000.