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