Home > Blogs > VMware Accelerate Advisory Services > Monthly Archives: July 2015

Monthly Archives: July 2015

From CIO to CEO: 5 Steps to Organize an IT as a Service Provider

Jason StevensonBy Jason Stevenson

In my last CIO to CEO blog, we discussed How to Run an IT as a Service (ITaaS) Provider by providing services to meet customer needs using a commodity as an example. In this blog, we will discuss how to organize governance and personnel within an ITaaS Provider.

IT as a Service ProviderTo provide business/mission-value and remain relevant, many IT organizations are positioning themselves as a Hybrid Cloud Broker; providing both public and private cloud services to their customers and users. To be successful, these organizations must adopt ITaaS; a model in which IT is a commodity, providing services on demand to meet business needs through a scalable and measurable pool of resources using integrated and automated processes. This is accomplished through a blend of:

  • Cloud computing standards
  • Service management best practices
  • Leading cloud and virtualization technologies

The following provides five steps to reorganizing IT to become and ITaaS Provider.

Step #1: Service Owners and Managers

Misconception #1:
Service owners and managers are lower-level resources that: a) do not have financial responsibility, b) are not fully accountable for their service, and c) report into functional/project directors.

Organize an IT as a Service ProviderAs part of service portfolio and catalog management, IT assigns owners for each service.

  • Service Owners (SO) are accountable for service strategy including fiscal responsibility and understanding customer demand for their services. Service Owners solid-line report to the CIO.
  • Service Managers (SM) may also need to be identified for each organizational sub-unit such as lines of business, cost centers, geographies, etc. If used, service managers are accountable for service operation and potentially service transition. Service Managers dotted-line report to service owners.
    • In larger organizations, service owners and managers may use a one or more Business Relationship Managers (BRM) as a conduit to customers paying for the service. BRMs solid-line report to the CIO but are embedded with their customers. The CIO may also have an IT Financial Manager (ITFM) to coordinate ITaaS provider budget allocations to service owners and consolidated service chargeback to customers.

Step #2: Service Life Cycle

Misconception #2:
Service strategy, service design, service transition, service operation, and continual service improvement are just names of service management books.

Organize an IT as a Service ProviderThough many organizations claim to be service oriented, their organizational structures remain functionally and/or project oriented. The following diagram illustrates an organizational pyramid providing service orientation through a service-life-cycle-based organization.

  • Directors are assigned for each service life cycle step including service design, service transition, service operation, and continual service improvement. The CIO also acts as the service strategy director and also performs demand management. Directors solid-line report to the CIO but dotted-line report to the service owners/managers. These directors’ budgets are an aggregate allocated by the service owner.

Step #3: Process Owners and Managers

Misconception #3
Process managers can be an afterthought and “peppered” throughout the organization.

Organize an IT as a Service ProviderTo be successful, an ITaaS Provider must have mature processes under the control of process managers and owners.

  • Process Managers maintain unit procedure documentation. Monitor process reporting. Reviews process records for compliance. Provide ongoing process and system training to unit. Contribute to continual process improvement. Ensure compliance with policies, processes, and procedures. Facilitate regular process meetings and communication channels. Coordinate interface with other service management processes. Take corrective action if needed.

For organizations with intensely “siloed” or “stovepiped” cultures, process owners many need to be introduced. This is not preferred but a common reality.

  • Process Owners champion policies, process, roles and responsibilities. Provides ongoing process and system orientation. Facilitates quarterly reviews. Facilitates annual audits. Enables continuous improvement.

The Service Portfolio Manager (SPM) also fulfills the role leading a service/project management office. The office may including control, technical writing, quality assurance, etc.

Step #4. Technical-Facing Service and Configuration Item Owners and Managers

Misconception #4:
Technical resources for service design and operation do not need to work together in abstracted technical-facing services.

Organize an IT as a Service ProviderThe business-facing services discussed above are supported by functions each with its own owner.

  • Infrastructure Function Owner (IFO)
  • Application Function Owner (AFO)
  • Data Function Owners (DFO)
  • Service Desk Function Owners often fulfilled by the Incident Manager (IM)
  • Operation Center Function Owners often fulfilled by the Event Manager (EM)

These functions may be further decomposed into technical-facing services. Common technical-facing services for ITaaS include network, compute, and storage and each must have an owner.

  • Network Service Owner (NSO)
  • Compute Service Owner (CSO)
  • Storage Service Owner (SSO)

To be a successful ITaaS Provider, technical services are not “siloed” or “stovepiped” and therefore do not require managers in addition to owners as they are shared services. However, the components supporting technical-facing services often have:

  • Configuration Item Owners fiscally responsible for the component
  • Configuration Item Managers operationally responsible for the component.

Life Cycle Gravitation

Configuration Item Managers are often referred to as DevOps in an ITaaS environment; especially for configuration items supporting the application function. Depending on an organization’s culture, DevOps may dotted-line or solid-line report to the Service Design Director or the Service Operation Director. As the organization matures, resources naturally gravitate from operations to earlier phases within the life cycle.

Step #5. Users and Assignment Groups

Misconception #5:
ITaaS is just jargon. IT departments are about IT personnel delivery IT.

Organize an IT as a Service ProviderIn a mature organization, classification of events, incidents, requests, etc. are aligned to the business-facing and technical-facing services within the catalog rather than legacy Category/Type/Item classifications. In this respect, the Technical-Facing Service Owners and Configuration Item Managers discussed above may also be referred to as Assignment Group Managers. The remaining technical employees within the ITaaS provider report to these Assignment Group Managers.

Every individual employee of an ITaaS Provider must move from technology to process, to service, to customer, to mission, and then ultimately to a value focus. Because these individual employees are the first, second, and third line of support for the users receiving the service it is critical for these IT employees’ tools and training to encourage user value focus.

Though impractical from a presentation standpoint, the entire ITaaS Provider must conceptualize their role as an inverted organization chart with the users at the top of the organization, then IT employees supporting the users, and then IT management supporting IT employees.

Organize an IT as a Service Provider

Move from CIO to CEO by leveraging a Strategist from VMware to address the people, process, and technology elements necessary to transform your organization to an ITaaS Provider.


Jason Stevenson is a Transformation Consultant based in Michigan.

ROI Best Practices Series — Part 1: Introduction and Goal of an ROI Analysis

Lisa SmithBy Lisa Smith

When we are considering any large investment either in our personal or work life, it is natural to question how fiscally sound that investment decision is to make.  Whether a company is considering the impact of rolling out a new product to market, acquire a company to gain market share or opening a new factory, using a Return on Investment (ROI) analysis will help define in hard numbers just how much that investment will return to us and over what period will we see our investment paid back.

What constitutes “good” ROI analysis?

Many companies have been using ROI analysis in their demand management programs to evaluative which proposed projects should funded and those which are not.  In a manner, projects are competing for both the company’s focus (labor) and limited capital dollars.

What is ROI?But a good ROI analysis does not tell the whole story a demand management program needs to determine the merit of each project proposal.  Demand management teams are also requesting project teams to include a business case to accompany an ROI analysis.  A company is not just investing their capital dollars in these projects, they are also investing their people time and focus.  We need to ensure that the project focus and execution is supportive of corporate and or business unit’s strategy – we need to have all of our oars pushing the boat in the same direction.

ROI Analysis

As Gartner espouses in their “Total Value of an Opportunity” (TVO) framework, a good business case needs to include analysis of how an investment has strategic alignment and the overall business impact of the project.  Those projects which are ultimately funded should be best aligned to the strategic goals of the company.  While a project many be financially a great decision, if the project’s goals are not in line with where the company is headed, the financial gains should be disqualified.

The goal of the ROI analysis should be to cleanly portray the financial state of “as-is” and the “to-be” future state after making the investment.  Those financial states should include all elements which are going to vary between the optional states.  When considering what metrics should be included in the analysis, it can be confusing where to draw the line – what to include and what to exclude.  What makes a “good” ROI analysis is not that we analyzing every possible cost metric but only those relevant costs which make a material impact in the savings.  The other key element to consider when building your ROI master piece is how consumable is the analysis by your project’s key stake holders.  If your ROI analysis reminds people of something out of the movie “A Beautiful Mind”, you need to step back and re-evaluate your approach.  A clean view of your assumptions, inputs, formulas and a simple side by side financial comparison of “as-is” vs “to-be” is the best to socialize your ROI study and results.

Socializing Your ROI Study

Buy in and blessing of your ROI study is the final hurdle which you need to have a truly successful ROI analysis.  Set up one on one time with various project stakeholders, walk them through your business case and ROI analysis.  A clean set of eyes is a valuable exercise to see where how your analysis holds water, what elements of your Business case needs to be fleshed out and you will immediately see how “consumable” your analysis is by another person.  If everyone asks the same question, perhaps you should that address that question in your presentation?  Let’s face it, with all the time you have been spending on building out your business case, you probably have a lot of key assumptions in your head which might not be obvious to your audience.  Lastly, during those 1:1 sessions with your stakeholders, it is a great time to feel out their support of your project and your quest for funding.

In summary, when building a business case presentation for your project consider the following factors:

  • Explain “How does this project support my corporation’s strategic direction?”
  • Outline “How will the business be impacted by my project’s success?”
  • Summarize results of ROI Analysis including side by side comparison of “as-is” and “to-be” costs.
  • Cover key assumptions, inputs and formals supporting your ROI calculation.
  • Perform key stakeholder reviews to build internal support of your work

What’s next?

This is the first blog in a series that will explore end to end ROI best practices.  Stay tuned for blogs on:

  1. Introduction and Goal of ROI Analysis
  2. Scope of ROI Analysis
  3. Structure of ROI Framework
  4. Different type of Value
  5. Infrastructure Analysis
  6. Process Analysis – Labor
  7. Process Analysis – Time to Market
  8. Process Analysis – Service Impact
  9. Risk Mitigation
  10. Tying it all to together – telling the story
  11. Benefits Realization

Lisa Smith is a Business Value Consultant in the VMware Accelerate Advisory Services team and is based in New York, NY.

From CIO to CEO: How to run an IT as a Service Provider

Jason StevensonBy Jason Stevenson

A service involves two parties: 1) a customer and 2) a service provider.

A service fulfills a customer’s need. Though there may be many components to a service, those technology, process, and people components are combined to form a single service. The customer should not need to understand all the subcomponents of the service to benefit from the service. Nor should any service-specific knowledge be required for the customer to solicit the service. In other words, the service should be expressed in cohesive layman’s terms.

Water Service Example

  • Customer Needs:  Water services fulfill multiple needs: life/thirst, personal/environmental sanitation, etc. If you put in a well, you have your own water and there’s no need for water service. However, if you do not have a well, you will need to engage the county water service provider.
  • Service Provider:  To engage water services, you expect simple contract language and simple commodity pricing. The customer should not need to be a plumber or hydro-engineer to engage the service.
  • Customer Expectations:  Once engaged, the customer doesn’t care how the water gets to them, what must be maintained, or who maintains it. After procuring the water service, they never want to talk to the water service provider again unless their needs change. If water service is interrupted, it’s the service provider’s problem. Customers don’t care what service provider people, tools, or expenses are needed to fix the problem, they just expect it to be rapidly resolved by any means.

How does this example relate to IT services?

First, let’s lay out the key players:

  • CEO, CFO, and stakeholders = Mom and Dad paying for the water service
  • IT Users = the family drinking the water and bathing in it
  • IT department = water service provider
  • IT services = water
  • Data, applications, networks, servers, storage = water treatment plants, water towers, mainlines, pipes, trucks, wrenches
  • IT staff = plumbers and hydro-engineers

Every time a customer experiences interruptions and contacts a water service center, the support call is not considered a “service” but is ancillary to the water service they are already payed for. The customer would rather not engage the service center at all. This is the same with an IT service desk.

Though a water plant monitors water flow and quality, it is not a service. The customer assumes the water is available with adequate water pressure when they purchase the service. This is the same with an IT operations center.

Though hydro-engineers and plumbers may be needed, for example in a large mall complex, they’re assistance would not be a service, rather a project to support the delivery of water services to the tenants and patrons of the mall. This is the same with IT engineers, developers, and project teams.

We assume the water is safe, maintained, and appropriate precautions are taken to ensure ongoing water quality and availability. This is the same with IT security, IT service management, and disaster recovery.

How do CIOs apply this to running as an IT as a Service Provider?

Think of what a water provider service catalog website looks like. It’s pretty simple… Water. Everything needed to supply the water is moot. You may be thinking “Sure this is true of a water commodity but IT is not a commodity.” No it is not… not yet.

So let’s take it up a notch and talk about utilities like telephone and energy services. Their service catalog websites contain utility services. Telephone companies for example list things like local and long-distance, Internet, call waiting, caller ID, conferencing, etc. on their service catalog website. They may also segregate their services by enterprise, small business, and individual customers.

Cable companies are even more similar to IT in some respects. They list things like VoIP communications, Internet, television/entertainment packages, etc. You can draw a parallel between each station offered by a cable company to each application offered by IT.

Regardless of commodities or utilities, service providers of water, power, telephone, cable, etc. have very simple service catalogs considering their extremely complex infrastructure and organizations. This is because the service provider has matured their services to focus on the customer/users and highly refined their services to meet specific customer/user needs, to remain relevant, competitive, and accessible.

To become a true service-provider, IT must take a similar approach to interaction with customers and users. To be successful, CIOs become CEOs by defining a usable service catalog with:

  • A clear business-focus addressing specific needs
  • Inclusive pricing and options
  • Seamless delivery
  • Transparent fulfillment

Jason Stevenson is a Transformation Consultant based in Michigan.

We’re going to the Cloud. Do I Still Need ITSM?

Greg LinkBy Greg Link

As of this writing, Boeing Aircraft Company is demonstrating its 787 Dreamliner at the Paris Air show. After a normal takeoff roll, the aircraft jumps off the runway into what appears to be a near vertical climb to the clouds! That is impressive. Recently a different form of cloud; cloud computing – has appeared on the horizon and appears to be here to stay. Forrester expects cloud computing will increase from approximately $41 billion this year, and rise to more than $240 billion in 2020. A 600% increase in 5-years is impressive indeed. Traditional IT shops have embraced IT Service Management (ITSM) frameworks, such as the Information Technology Infrastructure Library (ITIL®), to help them respond to dynamic business requirements. But is this framework still needed as more and more companies turn to the cloud?

What is the purpose of ITSM?

ITSM and ITIL are often used interchangeably. They are synonymous because ITIL has become the de facto or gold standard for the design, delivery and operation of quality IT services that meet the needs of customers and users. Its approach focuses on 3 major areas:

  • Using a process approach to
  • Deliver IT services rather than IT systems or applications, while
  • Stressing continual service improvement.

With the success of ITSM initiatives all across the globe there is little reason to abandon these critical practices simply due to a shift in the way storage and computing are being performed. The cloud is merely providing companies with powerful utility to meet business requirements and demand.

5 reasons why ITSM is still needed in the cloud

Your transformation to the cloud can take several paths. You can go the route of the Private Cloud where you have total control over the infrastructure and applications that will be used to do business. Another option is the Public Cloud where you contract with a provider that will host storage and computing resources. The final option is the Hybrid Cloud – combination of the two – that allows companies to meet seasonal or growing demand. Any path chosen will still require the basics covered in ITIL.

1) Service Strategy

Service strategy helps in understanding the market and customer needs to create a vision of the services needed to meet business objectives. In this phase we look at things like Financial Management. The cloud is best served when costs and fees are known and predictable. This segment also looks at Demand Management. This discipline proactively manages the dynamics of how the service will be governed from a resource perspective. Both of these are critical to success in the cloud.

5) Service Design

Service Design is the practice of taking a holistic approach to end-to-end service design while considering such things as people, process, technology and vendor relationships. Processes within this phase that are critical with the cloud are:

  • Service Level Management – setting and keeping service targets
  • Supplier Management – this is essential if you are considering going into the Public Cloud as the vendor you choose will be responsible for the delivery of your services.
  • Service Continuity Management – what is the backup plan and if needed, the recovery plan to resume business services should there be a disruption?
  • Capacity and Availability Management – will resources be available and in quantities needed to meet the business requirements in a cost effective manner?

3) Service Transition

Service Transition assists in getting a service into production with processes such as:

  • Transition Planning and Support – planning and coordination of resources in ensure your IT service is market ready.
  • Evaluation – does the service perform and do what it is supposed to do (warranty and utility)?
  • Knowledge Management – make sure that people have the information they need, in whatever capacity, to support the service.
  • Change Management – Private cloud users will follow existing process, however a well coordinated change management process will be needed for Public and Hybrid cloud users. Your vendor’s changes may affect your application in unwanted ways. Additionally, if the cloud is to be used for provisioning servers and environments, the Change Management should be optimized for agility and repeatability.

4) Service Operation

Service Operation manages how a company balances areas in consistency and responsiveness. Processes important when considering deployment to a cloud environment are:

  • Incident Management – where do cloud users turn to when things don’t go as they should and how is that managed?
  • Access Management – the method by which only authorized users are allowed access to use the application and other resources used in the delivery of services.

5) Continual Service Improvement 

  • Now that you’ve deployed to the cloud, how are customers reacting to your service? Is the service meeting their needs? Is it fast enough clear enough, secure enough…?

IT Service Management principles will help guide you into a successful cloud experience with ease and confidence.  Luckily, you’re not alone.  VMware professional services are not only experts in cloud innovation, we have ITIL Experts on staff who can help you ensure ITSM best practices are applied throughout your operating model.

Greg Link is a Transformation Consultant based in Las Vegas, NV