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

Monthly Archives: September 2015

From CIO to CEO: Shaping Your ITaaS Transformation Approach

Jason StevensonBy Jason A. Stevenson

In this CIO to CEO series we’ve discussed how to run, organize, and finance an ITaaS provider. In this blog, we will discuss how to approach the ITaaS transformation to gain the most value.

Barriers to Success

Transforming a traditional IT organization to be a private cloud provider and/or public cloud broker using ITaaS contradicts many basic human behaviors. To undergo a transformation we must convince ourselves to:

  • Put other people first; specifically customers paying for the service and users receiving the service.
  • Place ourselves in a service role from the very top of the IT organization to the very bottom and allow ourselves to be subservient to others.
  • Give up the notion of self-importance and recognize each and every person plays an equal role in the chain when delivering an end-to-end service and accept a fair amount of automation of what we do on a regular basis.
  • Redistribute control from individuals to processes that leverage group intelligence and center authority within service ownership and lifecycle.
  • Become truly accountable for our role in service delivery and support where all involved can clearly see what we have done or not done.
  • Approach problems and continual service improvement in a blameless environment that shines light on issues rather than covering or avoiding them.

In other words, we must be: humble, honest, relaxed, and trusting. Not the kind of words you often hear in a technology blog but nonetheless accurate. In essence, we must change. That is different from he must change, she must change, or they must change; and that is very different from it must change. In the IT industry, we tend to abstract change by focusing on “it” which is often hardware and software and then deflect change to “they” which is often users or another department.

Are You Ready for Change?

The first two questions an ITaaS CEO (CIO) needs to ask are:

  1. “Do I really want change?”
  2. “Are we really willing to change?”

Initially the answer seems obvious “Of course I do, we have to.” In that subtle nuance of “I” and then “we” lies our challenge. As we wade in we realize the level of resistance that’s out there and the effort it will take to overcome it. We begin to realize the long term commitment needed. For the faint of heart, change dies then and there. But for those who take on challenge the journey is just beginning.

Many IT organizations are focused on service/technology design and operation and therefore do not have the necessary level of in-house expertise to guide their own organization through a complete people, process, and technology transformation. To ensure the greatest return on their investment, many organizations look to a partner that is:

  • Specifically experienced in transformation to instill confidence within their organization.
  • External to their organization and somewhat removed from internal politics to increase effectiveness.

Assuming a partnership is right for your organization for these or other reasons the question becomes “How do I pick the right partner?

Personal Trainer vs. Plastic Surgeon

You’ve heard the saying “Be careful what you ask for you might just get it.” This is very true of an ITaaS CEO looking for a partner to relieve some of the effort and commitment associated with change. Becoming a cloud provider/broker is hard work. The analogy of personal trainer was specifically chosen because of its implication that the hard work cannot be delegated. Though counterintuitive, the more an ITaaS CEO or his/her team attempts to push the “hard work” to a partner the more the partner becomes a plastic surgeon, “delivering” a pretty package with no guarantee that your organization won’t slip into old habits and lose all value gained.

A personal trainer doesn’t exercise or eat for their client, but coaches them along every step of the way. A personal trainer does not usually deliver exercise equipment, assemble the equipment, or even necessarily write a manual on how to use the equipment. What personal trainer does is show up at regular intervals to work side by side with an individual, bringing the knowledge they have honed by going through this themselves and assisting others.

For an IT organization that is looking to become a cloud provider/broker, reduce cost, or just be more consistent or agile, a partner can help more by providing consultation than deliverables. This isn’t to say that a partner shouldn’t develop comprehensive plans or assets, but your organization will get more value out of developing plans and assets as a team, coached by your partner, to ensure a perfect fit. Though the partner may recommend technology and then implement it, this is just one piece of the puzzle. Establishing a trusted relationship between the partner and the IT organization takes regular workouts/interaction.

My Approach to “Personal Training”

We all wish we didn’t have day jobs or family responsibilities when we want to spend time at the gym but reality mandates we spend short but regular amounts of time with our personal trainer. This is also true of the IT department and their partner. Though 100% of the organization must be involved in change at some point these workshops equate to approximately 10% of the time of 10% of the organization. When I am engaged in large-scale transformation with my customers, I find the optimal cadence for hands-on consultation is every two or three weeks, with three days (usually in the middle of the week) that feature half-day workshops consisting of a 2-hour morning session and a 2-hour afternoon session. These workshops are both timed and structured using principles that build goodwill with all stakeholders involved whether they are proponents or opponents to change.

A simplified version of my approach to overcoming resistance and obtaining commitment is to:

  1. Start by sharing a common vision, how the vision has value, and how we all contribute to producing that value.
  2. Raise awareness and understanding through orientation to allow as many people as possible to reach their own conclusion instead of trying to tell them what their conclusion should be.
  3. Establish trust with all involved by involving them in an assessment. Not an assessment of technology or the environment; rather an assessment that draws people out and engages them by asking what is working and shouldn’t be changed, what isn’t working and needs to be changed, and what challenges do we foresee in making a change.
  4. Openly and interactively draft a service model that includes features, benefits, and commitments and a management model that includes roles, responsibilities, policies, processes.
  5. Automate and enforce the service model and the management model through tool requirements.
  6. Review and revise after group workshops and through great finesse. Over time the group will progressively elaborate on these models and tools, going broader and deeper just as a personal trainer would by adding more exercises, more weight, and repetitions.

Avoiding Burnout

At the gym, we may overcome the initial challenge of understanding health and exercise only to discover how painful our aching muscles can be. This stresses the importance of rest and cross training. Much like a personal trainer, our IT partner must not push an organization to gorge on change or focus on one particular component of change for too long. This can sometimes seem sporadic to our team so the approach must be clearly communicated as part of the vision.

You may have noticed the use of the word “team” and wondered who is it? We can consider team in this context as the service’s stakeholders. That is everyone involved in delivery of service and yes that does include customer and user representatives.

An ITaaS CEO that involves his or herself… and not only chooses change and discipline, but also a partner focused on promoting team change and self-discipline over short-cut deliverables, will find their organization in a much better position to transform to a cloud provider/broker using ITaaS.

===============

Jason Stevenson is a Transformation Consultant with VMware.

ROI Analysis: 4 Steps to Set the Scope

Everything and the Kitchen Sink

Lisa SmithBy Lisa Smith

As I discussed in “Introduction to ROI”, determining what to include or exclude in your ROI analysis can be tricky.  What if you leave off a metric that ends up being materially very significant and eats up all of your savings when you begin to implement?  Shouldn’t you just include ALL of your related costs, just to be sure?  Sometimes it feels much more comfortable spending many hours in “analysis paralysis”, just to be safe.

But I am jumping ahead of myself.  Let’s start with the mechanics of how to figure out the scope of your ROI Analysis.

Setting the Scope for ROI Analysis

The guiding principle is pretty simple:  Model the stuff your solution is going to impact.   

Step 1 – Create a Capabilities List

Create a list of all the capabilities your project is going to deliver in a single column (I like to use Excel, even for a text exercise like this).

Step 2 – Create a Benefits List

In a second column next to this list of capabilities, draft the benefits that are going to be delivered by these capabilities.  To do this you need to answer the question, “So what?” with regard to every capability you are delivering.  The lens for these benefits should be focused on what the company is going to achieve from the successful implementation of the project you are requesting funding for.  Don’t get caught up in how you are going to measure these benefits just yet.  Don’t judge what will be considered big savings or small savings.  Just free flow – write them down.

If this exercise is really hard then it might mean that you need to get a better handle on your desired future state.  If you have a great vision of where you are trying to get to with your project, a list of high level benefits should flow easily.

Step 3 – Refine Your Value Drivers

After you have your list of capabilities and benefits (I will refer to these items as “value drivers”), share that list with your peers who are familiar with your “as is” state and your “to be” state.   You might be given a few more value drivers to consider, or you might decide to drop a few value drivers.  If your project includes benefits or services consumed by other teams or end customers then you need to spread your wings, leave your nest and start talking to other people.  The conversation would sound like, “If we could provide, ABC Service, what would the benefits to your team be?”  This “voice of the customer” data provides a great insight into how well adopted your project or service would be; evidence that wider spread gains would be achieved beyond just your team.

“If you build it, they will come” may work in the movies, but the success of any technology project hinges on internal adoption.  Many internal cloud projects failed to get the adoption levels they were expecting from other lines of business.  They built it, but no one is coming.  Quite often these missteps could have been avoided if they had a greater understanding of their consumers’ needs and desires, and used those to fuel the short list of the cloud services provided.

Step 4 – Create a Value Model

Let’s create a value model using an example from VMware’s product vROPs, Capacity Management benefit statement:

“Capacity management helps identify idle 1 or overprovisioned2 VMs to reclaim excess capacity and increase VM density3 without impacting performance.  “

Reclaiming excess capacity is our “So what?”, or benefit statement.    We need to draft a model to calculate the financial impact of reclaiming excess capacity.  The model should include the before and after depiction from our three new capabilities:

  1. Removing idle workloads
  2. Reducing assets provisioned per workload
  3. Increasing VM density or consolidation ratio

ROI AnalysisThe net effect of reclaiming excess capacity refers to expenses associated with server and storage infrastructure capacity.   If that was the scope of your analysis, the capital expense associated with the server and storage savings would be all you needed.  You might also consider expanding the scope, to include the operating expenses also tied to that hardware.  Those operating expenses would cover the power and cooling of the hardware, the data center space overhead, the administrator labor needed to install, maintain, support and refresh that gear.  This technique is often referred to creating a “total cost of ownership” view, considering the acquisition cost as well as the ongoing operating cost of an asset.

Try grouping the value drivers into themes such as reducing computer hardware infrastructure, reducing incident management processes, or reducing time to market for application development.  For a single theme it is best to create a single value model for all of those value drivers.  This is most helpful in providing a single depiction of the “as is” costs or process effort of today compared to a view of the future “to be” state – comparing apples to apples.

So where do we draw the line on scope?

If your value drivers are a pretty short list, feel free to model every aspect of those benefits.  If your value benefits list is lengthy and your “so what” list has over 10 items, please consider scoping to only key and material items.

While I am going to be applying a bit of circular logic here for a minute – if any one line item in your TCO analysis is less than 10% of your total savings, you might consider dumping it from your model.  The savings does not support the effort to QA your math or the effort to socialize the savings.  Secondly, if your savings is considered “soft savings” you might want to consider dropping it also.  Especially if you have plenty of hard dollar saving to justify the investment.  Don’t gild the lily.  If you are not familiar with “hard and soft dollars” concept, I will be covering that in a future article.

==========

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

Don’t Let Stakeholder Management & Communications Be Your Transformation’s Goop Mélange

John Worthington By John Worthington

What is “Goop Mélange”?

In an episode of TV’s “The Odd Couple” Oscar took on making his own dinner.  He mixed in potato chips, sardines, pickles, and whipped cream.  It was then garnished with ketchup.  When Felix asked what he called this mélange, Oscar answered, “Goop.”

So what does this have to do with stakeholder management?

The importance of stakeholder management is referenced in almost all best practice guidance including ITIL, COBIT, PMBOK, TOGAF and many more. In addition, the number of channels available for engaging stakeholders is growing to include social media, smartphones and other enabling technologies.

Unchecked, your stakeholder management plan can quickly become a very confusing mix of uncoordinated communication. Mixing up a little bit of everything can wind up being the goop mélange of your transformation program.

One way to assure a desirable mix of communication channels is to establish a Service Management Office (SMO), which can begin to develop marketing and communication expertise within the IT organization based on a well defined stakeholder management strategy.

The stakeholder management plan can take a look at the organizational landscape based on the current and future needs of a transformation path, identify key stakeholders and provide the analysis and guidance needed for others (such as project managers, architects, etc.) to effectively do so as well within the transformation context.

From a service management perspective, the stakeholder management plan and the SMO can set in motion the improvements needed to establish cross-functional communication. An example might be Service Owners driving dialog about end-to-end IT services across technical domains.

The stakeholder management plan, supported by a well-sponsored SMO, can also ensure that top-to-bottom communication channels are matured. This is enables communication between Process Ownership, Process Management and Process Practitioners as another example.

stakeholder managment

Sticking to these basics of stakeholder management and communications as you begin your transformation can make sure your stay focused on building a solid foundation for more sophisticated communication channels when the organization is ready, and avoid making a goop mélange out of your transformation communications.

=====================

John Worthington is a VMware transformation consultant and is based in New Jersey. Follow @jMarcusWorthy and@VMwareCloudOps on Twitter.

Commodity IT – It’s a good thing for everyone!

les2By Les Viszlai

Traditionally, IT commodity services and products have the highest percentage of being outsourced in our industry. There is a belief among a majority of people in our industry that IT commoditization is a very bad thing.

In its simplest form, a company’s success is measured by its capability to produce a product or service efficiently and to meet the market demand for that product or service.  Running IT as a business implies that we need to also do the same for our internal customers by providing products and services cost effectively with repeat-ability and predictability at an agreed cost.  IT organizations are viewed as a business enabler and trusted advisor by getting out of the business of building and running commodity IT products and services and focusing on providing the business with resources that provide new product capabilities and business differentiators in their market.

We need to understand what a commodity is in order to change how IT is run and provide that business focus.

commodity starts as any thing that has a perceived value by a consumer. A more common understanding of a commodity is a product that is generic in nature and has the same basic value as all similar items. (a simplified example is a Server)

For example, virtualized hardware, in the IT data center context, is a device or device component that is relatively inexpensive, widely available and more or less interchangeable with other hardware of its type.

By definition, a commodity product lacks a unique selling point. In an IT context, the term usually differentiates typical IT products from specialized or high-performance products. A commodity, when looked at this way, is a low-end but functional product without distinctive features.  Generally, as hardware moves along the technology cycle, that hardware becomes a commodity as the technologically matures in that marketplace. That implies that most hardware products, like network switches, that have been around for a long time are now available in commodity versions, although they aren’t generally marketed as such.  In the past, physical networking infrastructure was viewed as specialized until the maturity of virtualization of this layer of technology became available and more widely spread.

Example IT Transformation Journey - Commodity Services

Example IT Transformation Journey

Lets look at a more traditional commodity example, the local gas station.  The gas at your pump is the same as the gas at any of the other pumps. It’s also the same as the gas at the station across the street or across town.  There may be a very slight change in price, but the products essentially sell for the same basic price and are the same regardless where they are purchased.  Can your consumers of IT products and services get this same consistency? Are we trying to refine our own gas before providing it to our consumers?

When we compare this scenario to a traditional IT organization we need to ask ourselves, what commodity areas are we focusing on reinventing and providing. From the IT standpoint, can we virtualize our hardware environment and reap some of the benefits like “FASTER TIME TO MARKET”, “COST EFFECTIVENESS” and “IMPROVED QUALITY”.  Are we already doing this and can we drive further up the technology curve build and/or broker services and products such as IaaS, PaaS or SaaS to drive faster business value?

Our common fear is that “Commodity IT” implies low quality and cost or that our roles will be outsourced.  In comparison, a commodity product or service is not sold cheaper that it takes to produce or run it.  Like wise a commodity IT product or service should have affordability, repeat-ability and predictability in delivery and as brokers not builders,  IT organizations can provide this service to the business.

In summary, studies have shown that IT organizations focus a lot of effort and resources on building and running products and services at the back end of the transformation curve.  This is the area with the least amount of business value but consumes a majority of IT time & resources.  IT organizations need to shift focus to the front of the technology cycle and help the business create and engineer new products and services that drive revenue.

IT best practices exist to help IT organizations move to the front of the technology cycle by reorganizing people, process and technology to use the building blocks of various commodity products and services to provide affordable, repeatable and predictable services. This allows IT organizations to focus on the front of the curve.  Now that’s a lot more valuable and fun.

Commodity IT – It’s a great thing for everyone!

=========

Les Viszlai is a principal strategist with VMware Advisory Services based in Atlanta, GA.