Prove your worth (CM in a can series 10 of 10)

If you are implementing a Capacity Management process of your own then a useful tip is to initially go for some ‘quick wins’ as these establish traction and credibility, even among the skeptics in your company.

If you’ve been following my series then you’ll know that I’ve been outlining a successful Capacity Management project that I led within a telecommunication company.

At the conclusion of the project the company were able to move forward confidently on our recommendations.

Moving forward…

·         The company expanded the rollout of the tool to include other applications and technologies. 

·         Training was provided to train the staff in using the tool and completing studies such as the ones covered in this engagement.  Other facets of the ITIL CM process were put in place, although some still have room for improvement.

·         Other facets of the ITIL Capacity Management process were put in place and have led them to be more proactive and less reactive

Moving from short term to long term

•          Most of the data required is in place

•          More focus can be placed on the iterative activities

•          More focus needs to be put on maintaining the CMIS and completing the Capacity Plan

•          As more M&A activities are planned, CM must be out in front gathering information and providing decision support information

The iterative activities are an extremely important part of the successful Capacity Management process. 

Ongoing monitoring and analysis leads to tuning recommendations and continued improvement of applications and services. 

Maintaining a CDB/CMIS is also important and currently all detailed data is being kept, resulting in the database getting quite big.  Figuring out how to summarize and aggregate and when to delete old data is an important step, especially when continuing to add targets and other objects to the CDB/CMIS.

There will be other opportunities within this Company to study Merger and Acquisition activity and fortunately, those projects will now be easier for their own Capacity Management team.  They will get a much earlier start on new projects in the future and now have the tools and skills in place to complete the work.

I’ll conclude the way I started.

When 2 mature companies (in the area of IT) come together each has its own ideas of what “best practices” actually are.  IT Service Management processes are probably in place in each of the companies and it’s likely that the resulting teams will not simply be a combination of the existing teams.

Technology, tools, applications, services – there will be a lot of redundancy and overlap in all of these areas and decisions will need to be made on which of these will survive.

Having effective Capacity Management in place, or buying in independent expertise, helps to make this process so much easier. 

Rich Fronheiser

Chief Marketing Officer

A collection of our thoughts and expertise, from a capacity planning perspective, in the form of published white papers, performance tips and on-demand webinars on a variety of cutting edge topics  are available free to download. http://www.metron-athene.com/_downloads/index.html

Challenges - “Political factions” exist in most companies(CM in a Can series 9 of 10)

In a Merger and Acquisition environment, political factions are almost certain to exist as legacy employees and new (acquired) employees jockey for position and, potentially, their jobs.

In this project, there were quite a few heated words spoken (and in one strange case, screamed).

At times, we had to ask our sponsor to find people that could provide us with some much needed data (especially historical data, where available).  It’s only because of the connections and the persistence of the sponsor that we received the data we needed to be successful.

Choose your wording carefully.  I had to ensure that our observations and recommendations were presented in such a way as to achieve ‘buy in’, we didn’t want either legacy or acquired employees to be defensive or dismissive. 

Likewise, we had to be very accurate and find some quick wins, as there was much skepticism from the legacy teams about the accuracy of the information and recommendations we were making.  This issue quickly went away when we were able to identify some likely bottlenecks that were not on the radar of any of their teams.

Each phase of the project uncovered likely bottlenecks and opportunities for improvement for the applications.  While we had to work quickly to get to the finish of the first phase of the project, once we had the report templates and the CIO presentation format in place, it provided a template to complete the second and third phase of the project.

The second and third phase consisted of applying any changes in hardware and replacing the captured data with more recent data.

Success in the first phase will always make the second and third phases easier and we certainly spent considerably less time trying to establish and prove our credibility.

I’ll conclude next time

Rich Fronheiser

Chief Marketing Officer

Summarizing the results (CM in a can series 8 of 10)

The reports that came out of this process were over 100 pages in length and the first thing I did was break the applications into meaningful groups, based on the potential pain should the infrastructure not be upgraded.  These groupings allowed us to quickly summarize the results and put the appropriate amount of focus on the applications that really needed attention.

Technical reports need to be translated for the business units.  It’s important to show the impact on applications in business terms so that the recipients of the information and recommendations from the business units understand the impact to the business.  Likewise, long reports need to be summarized in to something more meaningful. 

Yes, it’s useful to have reports that give background and show the techniques used, but the business recipients and the senior IT managers are looking for an executive summary and if this summary can be reduced to a sentence or two, all the better.

A key deliverable for this project was a presentation to the CIO.  Given 30 minutes on a calendar (which means a 20 minute presentation, at most) it was vital to present the information in a graphically appealing, yet informative way.  The next few slides demonstrate this

The first slide shown to the CIO (after a couple of introductory slides) consisted of some graphical ways to show that these applications were predicted to be in good shape through the four required prediction points provided by the business units (three consisted of customer conversions and the fourth represented the additional work expected due to another acquisition).

As you can see, the comments show the potential breaking point of the application in business terms, where possible.  However, these applications are not expected to have performance or capacity problems throughout the time period of this project (it could be argued that these systems/applications were over configured, but that was not part of the scope of this project) and can therefore be mentioned quickly and then “forgotten.”

These are the applications that were predicted to have potential issues in the third period (yellow face) and first two periods (red face).  Some of these applications had new hardware on order, while others needed further investigation of the applications and the components that comprised them.  A few applications were already not meeting SLAs and many of these had hardware purchases pending.  In some cases, those were the correct decisions and in others we determined that the bottlenecks would not be removed by adding additional hardware.

So, apologies to ITIL

•          A process should not be tailored to a specific tool – this time it was

•          Data should be captured for an entire business cycle

•          Ideally, the implementation of the process should be a long-term project

The key is to know when it’s appropriate to ‘bend’ or ‘break’ ITIL guidelines to meet the business requirements.

We identified the tools that were in place and supplemented them with what was needed in order to complete the project successfully. 

We recognized that we wouldn’t be able to capture more than a month’s worth of data, requiring us to get additional information from the business units and alter our tolerance for error accordingly.

Quite a few challenges existed in the project, so we’ll look at those next…..

In the meantime you might want some more tips on reporting to management take a look at Andy Mardos’ what do they really want know blog series http://capacitymanagement-metron.blogspot.com/2011_07_01_archive.html

Rich Fronheiser

Chief Marketing Officer

Questions you should be asking (CM in a can series 7/10)

Normally, a capacity manager would expect to capture a “business cycle” worth of data in order to determine the peak periods and the proper modeling intervals.  Without that, the capacity manager would need to gather information about the application via interviews from the business side and would need to rely on that information.

I needed to use the data in combination with the information from the subsequent interviews – I had data for about a month – and in some cases, I and my team, had to model the annual peaks based on the data we had captured in combination with the information we got from the interviews.

Sample interview questions to ask are:

•          What are the current business volumes?

•          What are the predicted business volumes?

•          What is the application architecture?

•          Are there any predicted changes to the business, the business volumes, the architecture or anything that will change the nature of the application or the infrastructure?

Most of the time in the interview process was spent getting to know how the applications worked.  These applications were very complex and many of them spanned 3-4 tiers and included the mainframe or a large data warehouse backend.

It was important to understand how the web servers, for instance, interacted with the middleware or the application servers and how workloads here affected traffic to the database servers or to the mainframe. 

This process was incredibly useful in getting enough background to make a month’s worth of data adequate (if not ideal) for us to make decision support recommendations.  However, this process was not without pain, which we’ll investigate shortly…

Moving forward….

As part of the scoping exercise done prior to the start of the formal project, applications were prioritized by the Capacity Manager.  This allowed me to group the applications in a meaningful way and assign them to consultants who then took on primary responsibility for completing the work.

Once the consultants received their assignments, they poured through the data and the application architecture diagrams and, as would be expected, found some gaps in the information or some clarification that needed to be made.  Additional meetings were held and more information gathered.

Remote access was provided to the CDB/CMIS so the consultants could work remotely on the project and have the most recent data from the systems.

Other data was gathered from existing sources, including data from the SAN as well as network statistics and some native virtualization statistics.

Modeling was completed for each of the applications – for some applications trending was used, for others analytic modeling was used. 

A standard report template was used to provide a common look-and-feel for each of the applications.  These reports were delivered, as early as possible, to the Capacity Manager and the staff in order for the reports to have a sanity check applied.  One common feeling by the consultants was that it would’ve been preferable for those doing the work to capture the information.  I certainly agree, but this is one of the ways I tried to minimize the project preparation time. 

Once the drafts were approved or additional information was provided, final reports were written and delivered for management (mainly the CM and the mid-level managers).

I’ll be dealing with how we summarized the results on Monday.

Rich Fronheiser

Chief Marketing Officer

Gap Analysis (CM in a can series 6/10)

Normally, the first step in a project is to complete a Gap Analysis and for this you need to interview and interact with a company’s IT staff and management.

You need to use a variety of interview questions and assessment checklists and I’ve developed these over time to identify the good and bad in current practice.  From there, I interview management to determine a profile of good practice for Capacity Management that the organization would like to achieve.  At this point, I would take the two views – current and desired – and then compare this with my understanding of good practice and determine which pieces of this would be a good fit for the organization.

While this normally happens as part of the project itself, I quickly identified that I would need to conduct a good portion of my Gap Analysis prior to the formal beginning of this project(see my blog,  ‘Sometimes in the real world you can’t do things by the book’, if you haven’t been keeping up)

Setting and executing a plan

I needed to do this for two reasons:

·         I knew that we would need to deliver results in 3 months from the formal start of the project.  This is not enough time to commit to delivering results, and THEN do a detailed Gap Analysis. 

·         Further, I was uncertain that we would be able to meet the required timeframes – a Gap Analysis and a commitment to change takes time – and what if I didn’t think we could fill the gaps quickly enough?  Also, any recommended changes we needed to be successful would need to be written into the agreement – without those changes we would not be successful and I needed to ensure we were putting ourselves in the best position to succeed.

So, I broke the Gap Analysis into two parts.  I was most interested in whether Capacity Management tools would need to be installed and whether there were existing tools in place that we could leverage to help with the decisions and recommendations that we’d have to make in less than 90 days.  So, with apologies to ITIL, I decided to worry about the tools and data first and the process itself later.

Hint: The apology to ITIL is mainly because the tools should not (usually) drive the process – however, with only 3 months to complete the project, it’s impossible to do a proper analysis and rollout if you have no historical data to base your facts on.

Sometimes practical considerations have to override the usual notion of good practice.

As I was bringing our own tool to the project (which isn’t always the case) and installing it into the company’s production environment, we had to prove that the tool didn’t consume excess resources and worked as advertised.  The group that did this testing work wasn’t the group that was my immediate consumer and it took weeks for the tool to be tested.  By the time we had the go-ahead to install the software (and the capture agents) in the production environment our 3 months had whittled down to 2.

While the install of our capture agents and the software took place, necessary in order to capture component level detail in the production environment, another consultant and I interviewed over 20 teams and captured as much information about the applications as we could.  More on this soon…

Consultants were deployed to work with the company’s staff in order to get capture agents installed on about 100 targets which included mainframe, Unix, Linux, Windows, and VMware targets. 

Part of the challenge is always to have the cooperation of the administration staff in order to minimize the time spent installing and configuring the capture of data.  We had full cooperation because of the sponsor/champion and much of the work was done before we got on site.  Installation and configuration was completed in about 3-4 days.

In the meantime, we spent time interviewing the business units, development and IT staff using checklists developed prior to the visit. 

For an idea of the type of questions you need to be asking catch up with me again on Wednesday....in the meantime join our Community for access to white papers, webinars on-demand and more http://www.metron-athene.com/_downloads/index.html

Rich Fronheiser

Chief Marketing Officer

Implementing Capacity Management, or any Service Management process, is not something that is done without proper planning (CM in a can series 5/10)

It’s a project and project management discipline and resources are required to be successful.  Having someone in place as a project manager who is familiar with PMP or Prince2 will increase the potential for success in the project.

It’s necessary to have a sponsor – a champion – someone who will push others to cooperate and someone who has enough pull in the organization (either by org chart or by the ability to get things done – or both) to get the required changes put in place.

A project team will likely consist of the Capacity Manager and a team of people who will implement the process.  This could be the eventual Capacity Management team or could be a team who are skilled in implementing ITSM processes.

What is certain is that someone must own the Capacity Management process.  Likely that is the Capacity Manager, but at this stage it could be anyone who is responsible for getting the process implemented.

Implementing a process is not something that can be done for free.  Project cost, the cost of tools, people, accommodation, etc. are all non-trivial costs and what’s the scope of the process?  Will it cover everything in the organization or just a subset (mainframe, Unix, Windows, virtualization, storage, etc.)?

Implementing a process that will yield results is a “selling job” for the organization and for IT.  A clear mission and vision statement allows for clear communication.  One recommendation I always make is that everyone working within this process should be able to quickly describe what Capacity Management does – an elevator pitch – something that can be communicated in less than a trip up or down the elevator.

Any project should have SMART objectives – specific, measureable, achievable, realistic, time-based.  Implementing a Capacity Management process is no different. 

What is the specific outcome of the project?  How will you measure success?  Is it an achievable objective?  Is it realistic?  When will it be completed?

A formal communication and awareness campaign should run as the process is being implemented – this will keep the process in everyone’s mind and will allow the Capacity Manager to communicate progress (which is especially important, considering the implementation of a process is not a short term project and it’s easy for people to forget there’s an active project in place unless progress is regularly communicated.

Normally, the first step in a project is to complete a Gap Analysis and I’ll be talking you through this on Monday.

Sign up for our webinar on August 20 'Using systems capacity data for business intelligence'
http://www.metron-athene.com/services/training/webinars/index.html

Rich Fronheiser
Chief Marketing Officer

Sometimes in the real world you can’t do things by the book (CM in a can series 4/10)

As mentioned I was recently asked to manage a project where a telecommunications company would be converting customers from a previous company to combined existing applications and dealing with anticipated growth and further acquisitions. 

The goal, short term, was to ensure that these conversions would happen while still meeting existing service level agreements.  The longer term goal was to put a capacity management process in place in order to be better prepared for the organization to handle these challenges going forward

A key part of this project was to ensure that key applications would have enough capacity to handle the conversion of acquired customers.  As part of the negotiation process, about two dozen applications/services were identified and prioritized.  These applications were complex, multi-tiered, customer-facing applications, many of them web based.

We had only 3 months from the beginning of the project to the first set of main deliverables with little formal Capacity Management process in place.

Before agreeing to the timescales, it was necessary for us to figure out how much work (prep, scoping, actual modeling and predictions, delivery of results etc.) needed to be done for each application.  While part of the goal was to implement a Capacity Management process, it quickly became obvious as time grew shorter and shorter that complete implementation of a capacity management process was impossible and that the main goal was to deliver results for the identified applications.

Which leads me to a question:

Which of the following is NOT an appropriate short-term objective for Capacity Management?

•          Develop and document a functional spec

•          Implement an integrated set of CM tools

•          Discuss roles and interfaces with other SM processes

•          Document the scope, objectives, and terms of reference for CM

This question is from a sample examination used in the v2 ITIL Capacity Management Practitioner course.

As a believer in aligning a Capacity Management process to ITIL and as someone who has taught the Practitioner course and delivered training and consulting designed to help companies develop their SM processes and align their practices to ITIL, I knew that implementing an integrated set of Capacity Management tools is not considered a short-term objective. 

And yet the first task required in this project, as identified by a Gap Analysis performed before the project was agreed to, was the implementation of a Capacity Management tool, as nothing existed in the environment to capture historical component data. 

Before I discuss this piece of the project, let’s back up and talk about implementing Capacity Management.  Normally, the process itself should be built and that process should lead to the purchase of tools, etc. 

It just goes to show that sometimes in the real world parts of ITIL have to go out of the window, this wasn’t a typical process – it was driven by specific need and the timescales were very compressed.

Implementing Capacity Management, or any Service Management process, is not something that is done without proper planning and that’s what I’ll be looking at next…

Rich Fronheiser

Chief Marketing Officer

What activities should be included in the Capacity Management process? (CM in a can 3/10)

I mentioned last week that it’s crucial, even in a compressed timescale, that a company consider all three levels of Capacity Management when implementing the process but what activities should be included?

Activities that should be undertaken as part of the Capacity Management process include:

Iterative Activities: Monitoring, Analysis, Tuning, and Implementation (under Change Management).  These are ongoing activities that occur in the production environment in a cyclical nature in order to ensure services are meeting service level requirements and are constantly improved. 

Demand management : (elevated to process status in ITILv3) is really a business activity – increase capacity or manage user demand. 

Application sizing:

Modeling: consists of a group of techniques used to predict future performance based on predicted workload change or hardware configuration change.

Data: stored in a Capacity Database (ITILv2) or Capacity Management Information System (ITILv3). 

Capacity Plan: The key deliverable in the process, a document (or series of documents) that communicates the observations and recommendations of the Capacity Management process

On Wednesday I’ll be sharing my real experiences running a project where a telecommunications company needed to convert customers from a previous company to combined existing applications and deal with anticipated growth and further acquisitions.

Rich Fronheiser

Chief Marketing Officer

The Capacity Management process (CM in a can 2/10)

I was talking about mergers and acquisitions and the important role that capacity management plays in this and it would seem relevant to take a step back first and look at what the goal of the Capacity Management process is.

The ITIL (v3) Capacity Management process as defined in the ITIL Service Design book states:

The Capacity Management process should ensure that cost-justifiable IT capacity in all areas of IT always exists and is matched to the current and future agreed needs of the business, in a timely manner.

The purpose of Capacity Management is to provide a point of focus and management for all capacity and performance-related issues, relating to both services and resources.

The objectives are to:

(1)  Produce and maintain the Capacity Plan

(2)  Provide advice and guidance to IT

(3)  Ensure that SLAs are met by managing performance and capacity

(4)  Assist with diagnosis of incidents and problems (related to capacity)

(5)  Assess impact of all changes on the Capacity Plan and on all services and resources

(6)  Ensure proactive measures to improve the performance of services are implemented wherever it is cost-justifiable to do so

Scope: All areas of technology (hardware and software), space planning, environmental planning and certain aspects of human resource planning

There are three levels of Capacity Management – Business, Service, and Component.

Business Capacity Management translates business needs into requirements for service and IT infrastructure.  These requirements include new services, new users, changes/improvements, and growth in the existing services.

Service Capacity Management deals with capacity requirements and performance of live, operational services.  The key is to ensure that capacity and performance are such that SLAs are met – and also that service levels are monitored and measured.

Component Capacity Management is the sub-process that deals with the management, control, and prediction of the performance, utilization, and capacity of individual IT technology components

Even in a compressed timescale, it’s crucial that a company consider all three levels of Capacity Management when implementing the process.

Join me again on Monday when I’ll be looking at what activities should be included in the Capacity Management process.

Rich Fronheiser

VP, Strategic Marketing

Capacity Management in a Can - (Open, Heat, Serve, and Succeed) 1 of 10

My first position out of graduate school was as a Unix Capacity Planner.  Over the course of my career, I’ve worked in varied industries, including an electric utility, an overnight shipping company, and an insurance company.  Each presented significant challenges, technical and otherwise, but all of those companies had reasonably mature Capacity Management processes.

As I moved into consulting and also spent time working for a software vendor, I found out rather quickly that process maturity is NOT the norm.  Most companies I dealt with, and deal with, do not have a mature Capacity Management process.  Many do not have basic tools in place to do effective Component Capacity Management.

If you, like me, have been around the work world for a period of time, it’s almost certain you’ve been through at least one of these events. 

•          Layoffs

•          Reorganization / New Management

•          Mergers

      •          Acquisitions

Many of us have been through more than one and some of us have been through all of them.

They all have one thing in common – a lot of uncertainty. 

First off, most people from senior management down wonder if their positions will be eliminated.  While this is obvious, what’s less obvious is how such uncertainty will affect how people work and how new initiatives (such as a new Capacity Management process or the acquisition of tools) will be received.  It’s quite possible in a merger and acquisition scenario that funding for upcoming or existing projects will be frozen while management figure out the direction the “new” or changed company will take.

Having been through a few mergers and acquisitions, it’s clear to me that they are rarely a combination of equals, especially in the area of IT.

The direction of IT is usually set by the remaining management and those who came onboard from the “other” company have to figure out how to stay relevant in the new company. 

Two mature companies (in the area of IT) means that each has its own ideas of what “best practices” actually are.  IT Service Management processes are probably in place in each of the companies and it’s likely that the resulting teams will not simply be a combination of the existing teams.

Technology, tools, applications, services – there will be a lot of redundancy and overlap in all of these areas and decisions will need to be made on which of these will survive the merger/acquisition

Follow my series where I’ll be looking at setting up good capacity management processes,  where ITIL fits in to the process and what challenges Capacity Managers face during mergers and acquisitions,.

Rich Fronheiser

Chief Marketing Officer