ITIL for sale?


As is Prince – the competitor (if you will) to PMI (the PMP certification). 


You can find the tender here:


What will it mean for ITIL? I’m not sure. 

Bigger question is – what will it mean for ITSM?


Ideas how Release and Change Management work together and versioning…

How far in advance are you putting in a Change Request?

Most of my personal experience with Change Management has seen that Change Requests come to the Change Advisory Board about 14 days to a few hours before the requested date for production. This seems to be the “norm” per discussions on LinkedIn and with other practitioners.

So, where and how then would you engage with Release Management? Certainly it is not possible to work on designs, unit testing, functional testing, user acceptance testing, load testing, deployment planning, and all of that work in just 10 days or so for any project of significance?!?

Also, I can’t see how a CAB could approve a “schedule” for changes to production for a project that will run months, perhaps even over a year. What happens when the date slips? Do you go through the CAB again? A project that is 8 or 9 months long will probably move the exact deployment date more than few times. It doesn’t seem practical to clog up the CAB with these requests.

Demand Management Board? Release Management Board?

So, let’s say you have an idea (or request) for a project. We already know it is much too early to open a Change Request to have it reviewed by the CAB. So, in what vehicle do you open a “request” up and when?

Perhaps having a Demand Management Board would make sense. This is where the idea can be vetted, perhaps some high level (or initial) budget can be allocated, a tentative schedule, and maybe the “green light” to do conduct a “Proof of Concept”

But what happens after the POC? Now you start getting firmer requirements, clearer designs, and maybe even a tighter budget and schedule. What “release vehicle” should you use and who will have oversight of all the “release” work (resource scheduling and so on)?

A Release Management Board seems like it would be beneficial here. Here you will determine what steps will be required for this “project” (will it require a full design document (such as for a new service) or only an update to an existing one, what level(s) of testing, what checkpoints for quality will be required, how involved will operations need to be, etc), the overall schedule for the effort, balance resources for release management, and perhaps look to consolidate efforts or avoid conflict/collision of releases.

Could these two boards be combined? I think so. But that would be for each organization to determine.

Could these boards be the same as the CAB? I don’t think so. The CAB seems to be more focused on the upcoming “operational” impact of changes – not necessarily the approval of concepts, the development model chosen, project scheduling/resource allocation, and transition planning (in detail anyway). Again, the CAB is more about – what is happening to Production next week and are we ready?

Change Management linking to Release Management

Instead of having just a Change ticket then, I think you should have a Release ticket.

The Change ticket will be to approve the release product (as defined/detailed in the release ticket). Perhaps the CAB will feel the need to move the release date (so an update to the transition plan will have to be made) or perhaps the CAB will feel that Operations is not ready at all and have the effort go back through all/parts of  Release Management.

Once the CAB approves the request – Release Management will have the defined plans of what/how the transition will happen – Change Management will confirm the when (start/finish) and results.

Release Management tickets will be opened for weeks (patches? Other small efforts) to months, perhaps over a year. A Change Management ticket will be opened for maybe 1 month – probably just 2 weeks or sometimes even less.

Thoughts on Versioning

In my past, projects I’ve worked on, had versioning levels for applications that included any functionality provided by that application.

For instance, Remedy 7.2 and then Remedy 7.3 – included in that was Incident, Change, Catalog, Asset Tracking and so on. We may update Incident with new workflow and that might be – internally Remedy 7.3.1 or something like that.

A concept I just heard about was actually to separate the “tool” or “technology” or “application” from the “functionality” or “service” being consumed. This would mean you would have Remedy 7.3 but if you did something to Incident it would become Incident 1.0 or 1.1.

Incident 1.1 would then “sit” on or be provided from Remedy 7.3 but not necessarily linked.

In a way, it is like separating Remedy 7.3 from your Windows Server Image. And then separating your Windows Server Image from your Hardware Configuration. So, you actually start “stacking” these “releases” on top of each other.


  • Incident 1.3 – Details the requirements – features/functions of Incident
  • Remedy  App 7.5 – Essentially the COTS product from the vendor – Vendor patches are applied here…
  • Remedy Application Server Configuration 1.2 — Specific configurations that need to be done to the Server so the Remedy App can work
  • Windows Server Image 3.4 — the Company’s base Windows Server Image
  • Hardware Configuration 6.5 — The Company’s base HW configuration

So, what if you wanted to add more memory? You would update the Remedy Application Server Configuration.

What if you replaced the server? That would be an update to Hardware Configuration.

Now for the really fun part – what if you replaced Remedy with CA Service Desk?

Then that would be this:

  • Incident 1.3 – Details the requirements – features/functions of Incident
  • CA Service Desk 12.5 – Essentially the COTS product from the vendor – Vendor patches are applied here…
  • CA SD Application Server Configuration 1.0 — Specific configurations that need to be done to the Server so the CASD App can work
  • Windows Server Image 3.4 — the Company’s base Windows Server Image
  • Hardware Configuration 6.5 — The Company’s base HW configuration

If you did, as part of this “technology” change update anything to do with Incident – then its version would change accordingly.

I believe this allows for clarity on requirements documents, testing, and release planning. You work on whatever release component you want but the requirements are very specific to that release component.

Instead of having a single project cover each of these release items – you essentially have 5 projects (interrelated) with very specific release models/focus that could be managed under a larger project (or program?).

The Change would really then be a collection of Releases – and not just CA Service Desk with all these specific releases sort of lost in the shuffle.


I’ve been doing quite a bit of work lately on metric collection and reporting.

It has been interesting and, as usual with these types of projects, enlightening. I’ve learned a few new things, learned that some of things I thought I knew I didn’t, and reinforced some other thoughts.

I suppose I can break this down into several observations and thoughts….

1. People are scared of metrics

If I really sat down and thought back through the years I could say I’ve seen this particular movie before. Something about this new project though really brought this out to the forefront though. People are nervous and scared about metrics, what they will “say”, who will “use” them and why.

I tend to to see metrics as part of a Evidence Based Management approach. How on earth can you fully understand where you have been, where you are going, and if your decisions are leading you to the right place if you don’t measure anything at all?

Imagine trying to drive a car without a speedometer, odometer, gas gauge, or…I don’t know something basic like…sight. Imagine just driving by “feeling” like you are some kind of Jedi or something.

The fear though is real enough. As discussed at great length on this other blog. Bad managers will probably misuse the information and this makes people nervous.

2. There is not a secret, magical, list of ITSM metrics out there for you to use

Management wants reports. They want them now. They want you to produce the reports yesterday actually. They truly believe that somewhere on the internet, there is in fact, a list of metrics that will work for every organization.

If we can use the car analogy again…what metrics are there for you in every car?

Speedometer, Odometer, Fuel gauge, Tachometer, some other things to tell you if your headlights are on or if you are signalling to turn left…maybe a few other things but not too much more. So, we have basically like…15 things or so that are “common.”

For IT, here are 17 common metrics (as good as any other list):

  1. How many Incidents do you have over X time
  2. What is the mean/median/min/max time to resolve an Incident
  3. What is your “1st call resolution” rate
  4. What is the mean/median/min/max time to resolve an Incident that has been escalated (meaning, excluding all those that count as “1st call resolution”)
  5. What is the Incident breakdown by “Service” (failing that, by “Application”)
  6. How many Changes do you have over X time
  7. What is the mean/median/min/max time to implement a Change
  8. What is the Change breakdown by “Service” (failing that, by “Application”)
  9. What is the driver of each Change (break/fix, maintenance, enhancement, transformation) – what % of all changes of each?
  10. What is your “up time” over X time
  11. What is your “mean time between failure”
  12. What is the uptime/mtbf breakdown by “Service” (or App…)
  13. What is the mean/median/min/max number of documented requirements per project (this is “scope”)
  14. What is the mean/median/min/max number of “changes” to scope per project
  15. What is the mean/median/min/max % of defects (regardless of “priority”) allowed/accepted per project. (meaning, how many go into production)
  16. What is the mean/median/min/max amount of time each project takes to complete
  17. What is the mean/median/min/max amount of cost each for each project

And this list doesn’t cover anything about Requests, or Problems or How pissed off your customers are (commonly known as Customer Satisfaction).

But still, even using that list isn’t a good idea without first trying to understand “why” you need them…

3. Don’t start with the metrics even if you have a nice list of them…

What is the story you are trying to tell? What is the problem you are trying to solve? Why do you need these metrics in the first place?

The GQM method seems like a good approach to me. Of course that isn’t “easy” either. You still need to work (think) on what your goals actually are and if they are appropriate/useful.

Then you have to figure out what the “right” questions are and then figure out what your metrics are.

4. Balance is still required…

“Be careful what you measure…it may be the only thing getting done.” No idea who said this first. I’ll take credit if it can’t be found anywhere else on the internet.

Going back to the first observation/thought – the concern that the metrics will be used for bad purposes or by bad managers – we have to be careful on what we report on.

I believe all metrics can be broken down into at least 3 different categories:

  • Performance (Something over time – like # of Incidents resolved over the past 30 days)
  • Compliance (SLA, or target/expectation — like # of Incidents resolved within 1 day)
  • Quality (examples could be: Customer Sat or % of defects put in production or Mean Time Between Failure or # of Repeat Incidents or # of Incidents after a Change Implementation)

You can also use “Value” as a category if you can determine benefit/cost in some manner. I think it is possible to use something like # of times the service is used as an indication of value (for example – The number of hamburgers sold is an indication (not saying THE ONLY, but an indication) of the value your consumers  place on that product).

When producing a report, it speak to a Goal, answer a question, and not be shown in isolation. I think it is important to show the combination of the 3 (or 4) categories of metrics in any report/presentation.

If you focus too much on 1 type of category it will probably be at the cost of one (or more of the others).

5. Stuff I’ve read/found that might be helpful…

Lead Users, Agile Development, and ITSM

Lead Users

You know the main point of this blog is really so I don’t forget things I come across or ideas I have. I am sure, that if I didn’t right this one down, I’d forget about it and then “rediscover” it about a year from now.

Anyway, what is a Lead User? And how did I find out about it?

I did some reading on Professor Von Hippel’s site (and of course Wikipedia).

The ‘lead user’ is the person who is using your product/service in a way that the majority of people are not yet. They are trying to solve a problem that the rest of the world doesn’t know it has, yet.

The idea is that you can get innovation breakthrough’s by working with ‘lead users’ of your products/services and see what problems they are facing and how they are working on solving them. You can then perhaps also work with related (but different) area’s to see how they are working to solve similar problems.

If all goes well, you will be ahead of the competition and just as importantly have a better product/service.

Lead Users and ITSM

Are there ‘lead users’ of ITSM? Are there people in  your organization that are trying to use your processes (or technologies built to support those processes) to solve problems that you (and the rest of the organization) are not really aware of or paying attention to…yet?

I know, in my last place, I heard of a Project Manager wanting to link a Change Request to a Project. I didn’t hear this from 10 or 20 PM’s or really from anyone working on projects or anyone in leadership – just the one PM.

But what I did was take that idea to the development team and asked them to include in the Change Request a place where you can put in the Project ID Number.

Boom! Now, you can track changes associated to projects. A few weeks after that, at lunch with the CIO, I bring it up to her that she can now have a report that would link Projects to Change Requests. Instantly she saw value in that and instantly it became a need for the majority.

Lesson: Find “lead users” in your organization. Listen to them. Bring their ideas forward. See how you can test them or, put them in practice quickly without spending too much time trying to make it ‘perfect’.

Agile Development

I’m not going to spend anytime explaining this concept. I’m not a SCRUM Master (what a title…) but I do believe Agile is better than classic/traditional/waterfall.

Now, previously, I described the simple way in which you can track projects to change requests. Is this the ‘best’ way to do it?

No. Clearly not. Anyone can forget to associate the two. They can “fat finger” the number. It isn’t the best method. Is it better than nothing. Yes.

And with an Agile approach to process you can start and in the next ‘release’ (maybe 30, 45 days, whatever) you update it. Maybe it wasn’t a mandatory field at first now it is. Maybe even better, there is a question “Is this Change Request related to a Project?” – if they say “Yes” then you make it mandatory. Oh, even better, why not ask the question, make it mandatory, but it is a drop down pulled from the Project Management technology?

You can make it better and better with iterations.


I heard about using SERVQUAL as a method to do a ‘gap analysis’ as opposed to CMMI in a comment from ITSkeptic. I can’t actually find the original place I heard it, so, it is possible I ‘mis-remember’ exactly the context. Either way I heard about it again from here. From there, I went ‘exploring’ ITSkeptic’s site and found this entry: here. Which then lead to CoreITSM and a blog post: here.

The net of all that and this ,  thisthis, and this, is…I think I’m really starting to actually understand Ian Clayton when he says ITIL is “inside out” thinking and we (ITSM practitioners) need to be more “outside in” thinkers.

Customer versus Consumer 

The first thing we need to understand is the difference between who the ‘customer’ is and who and/or what the ‘consumer’ is.

The quick answer to this is that the ‘customer’ is the person (entity, but I’ll use ‘person’ here) who is paying for the service. They may or may not (often times will not ‘always’) be the same as the ‘consumer.’

The ‘consumer’ is the person who is using the service but may or may not (often times will not) be the same as the ‘customer.’

One analogy is that a dad goes to the pizza place and orders a pizza, pays for it, and brings it home to the family. He is the customer (of the pizza place).

His kids eat (consume) the pizza. They are the consumers. Now, the dad is also eating the pizza, so he is also, at that moment a consumer.  The kids however, were at no time, ever the customer.

Who has greater influence over what the customer spends: the consumer or the service provider?

Knowing the difference between the customer and the consumer is a big deal for ITSM. This concept becomes important when we think of things like: “Who is our SLA with?” the customer or the consumer? Or “Who is primarily calling into the Service Desk?” the customer or the consumer?

What does the customer care about? What does the consumer care about? What if they are not the same thing? They probably are not, although overlap – think of a Venn diagram.

What does that mean for IT and the services being delivered? Perhaps IT will disappoint the consumer, who often times has greater influence over the customer than IT does. It could be that this in turn leads to the customer being unhappy with the IT even if IT is doing everything the customer asked for. But what about the consumer?

Think about that dad and the pizza. The dad maybe wants:

  1. Something fast
  2. Something cheap
  3. Something with mushrooms

The kids might have wanted:

  1. Something tasty
  2. Something with sausage

Maybe some of those items overlap. Maybe the pizza is fast, cheap and has sausage and mushrooms. But it may not all that tasty (to the kids) and therefore they don’t like it and don’t want it and complain. Who has a greater influence over future purchases (spend) – the consumer (the kids) or the service provider (the pizza place)? Clearly, the consumer does.

It won’t much matter how satisfied the customer is if the consumer rejects the service.

SLA reports aren’t written with the consumer though. They are with the customer. So you can’t just produce reports that say “We’ve met our SLA for the past 9 months straight – what do you mean you’re not happy!?”

Friction Points

In SERVQUAL there is a diagram that shows 5 gaps or 5 points of friction between expectations and reality. At HazyITSM they modified the traditional SERVQUAL diagram to include an additional 2 points, for a total of 7.

Here is the diagram from

The First Point of Friction

The first gap or point of friction between expectations and reality is between the customer (the paying party) and the service provider (IT). In more detail it is between what the service provider’s leadership believes it is providing and what the customer believes he is receiving.

Back to our dad and pizza place.

  • The service provider leadership (owner of the pizza place) believes he is providing “world class fine Italian dinning at affordable prices that the entire family will enjoy!”
  • The customer (dad) believes he is getting “pizza: cheap, fast and conveniently located near my house.”

These are not necessarily the same thing – nor are they mutually exclusive. There is however a difference in approach and focus.

In ITSM, we typically have SLA’s to help bridge the gap between customer expectations/goals and what the service provider believes they are providing.

The Second Point of Friction

The second gap or friction point is internal to the service provider. It is between the service provider’s executive leadership (the pizza place owner) and managing leadership (the pizza place manager).

  • The pizza place owner may think again he is in the business of providing “world class fine Italian dinning at affordable prices that the entire family will enjoy!”
  • But the manager may believe she just needs to  “provide pizza’s and sub sandwiches quickly and at a profit with as little waste to resources as possible.”

What ITSM can use here to help smooth this point out are detailed Service Design Packages to include costing  information. If the executive leadership and the managing leadership are on the same page as to not only what to provide but how to provide at what cost there will be less confusion between what the executive leadership believes it is supplying (and what it actually is supplying) to the customer (see friction point 1).

The Third Friction Point

This friction point is between the customer and the consumer.  This is outside of the service provider, but has direct impact on the perception of quality the service provider delivers.

The customer has purchased something (in our case, a pizza) for a certain price and with certain expectations. The consumer (the kids) however have different expectations that may or may not be met with what is being provided (by the service provider).

Do the kids blame dad (maybe) or does everyone (dad and the kids) blame the pizza place? I think you know what happens…

What can ITSM do about this? I’m not really sure but one way is to reach to the ‘consumer’ and find out what their needs are. Perhaps the ‘customer’ is not even aware of the needs of the ‘consumer.’ If we have the opportunity to find out how our ‘consumers’ feel about the service or what they want from the service I believe it is in our best interest to discover what those are.

If there is a difference, and there probably is, beyond discovering it what can the IT service provider do? Perhaps a service catalog similar to this here (link provided by Charles Betz) that shows not only what is being delivered but what is not being delivered.

I am not sure that is enough, but the data must certainly be discovered and some type of discussion and strategy by the service provider must be generated to help provide the customer and the consumer what they need so they can remain (or become) happy (or satisfied).

The Fourth Friction Point

The fourth friction point is between the consumer and the managing leadership of the service provider. This is between what the consumer expects to receive and what the managing leadership believes it needs to do.

Previously we’ve stated the consumer (the kids) want:

  1. Something tasty
  2. Something with sausage

And managing leadership believes

  •  she just needs to  “provide pizza’s and sub sandwiches quickly and at a profit with as little waste to resources as possible.”

What the managing leadership is doing may match up to internal service provider goals/objectives/budgets but not really meet what the consumer’s expectations/desires.

In the IT world, this may be the caller (consumer) to the Service Desk being dissatisfied but the Service Desk is meeting “hold time” and “1st time resolution” metrics. Which really means what to the consumer? Probably not much.

What can ITSM do about this? If points 1 – 3 are being taken care of they will have direct impact on this. Gathering data about this friction point (or gap) will help illuminate issues in point 3.

Is this even a friction point that can be solved directly?

The Fifth Friction Point

This friction point is internal to the service provider. This deals with the difference between what the managing leadership wants to do and what is actually being done.

At our pizza place, the managing leadership may want (and specify) that x amount of sausage is used on a pizza and that the pizza is cooked at x degrees for x amount of time. However, what is really being done is x-y or even x+y.

This seems to be the most focused on area from what I’ve seen in ITSM blogs and discussions. It also seems to be the most ‘guilty’ of the ‘inside out’ thinking.

It seems to me this area is mostly around Change, Release, Evaluation, Configuration, Event, and Problem management. All very important things and certainly can drive up quality – but if this is all you focus on, are you really focusing on the right things? Are you getting the most out of your ITSM dollar?

The Sixth Friction Point

Again, this is internal to the service provider. This is between what is being marketed/communicated about what the service provider can do and what it can actually do. This communication is going to the customer and the consumer.

This could be ‘false advertising’ or misleading information or just plain failure between either the communication effort to understand what is actually being delivered or the delivery team to actually do what it is supposed to (see point 5).

If this is horribly wrong (or missing) this can negatively impact customer and consumer perception.

For ITSM – the simple service catalog (as shown earlier) is an example of communications – we presume however that it matches what is actually being delivered.

What happens though if you don’t communicate at all? Then I suppose your customer and consumer will have no ‘boundaries’ set as to what you actually provide. That is probably not a good thing.

The Seventh Friction Point

This is internal to the consumer. So, like the 3rd point, this is outside of the service provider (but that point dealt with the customer and consumer, this one deals only with the consumer).

According to this paper (A Conceptual Model of Service Quality and its Implications for Future Research) “consumers typically rely on experience properties when evaluating service quality.”

What are “experience properties”? They are: “attributes that can only be discerned after or during consumption.”

So, what was the transaction experience like for the consumer? This means the consumer is not typically evaluating service quality on how costly or inexpensive it is, or long term ROI or VOI (these may all be concerns of the ‘customer‘ though) but how their immediate transaction with the service provider was.

For the kids it was “how did this pizza taste?” or “was there sausage on the pizza?” – they don’t care or take in to consideration “This is the only pizza place within 15 miles of the house” or “This pizza is very affordable.” That is for the customer to care about.

The expectation is for “tasty pizza” the perceived perception is “this pizza is/is not tasty.”

According to the previously mentioned paper “When expected perception is greater than perceived perception then the perceived quality is less than satisfactory and will tend towards totally unacceptable.”

Or to put it another way, when you perceive to get less than you expected, you are not happy. It doesn’t matter what ‘reality’ may be – what matters is what you thought you should get and what you thought you actually received.

What can ITSM do about this? I believe that focus on points 1 and 3 can really help with this more than say focus on point 5.

Soft skills and helping IT people understand that the transaction during the delivery of the service is as important (and maybe more?) to overall service quality than meeting SLA’s such as “Avg talk time” or “Mean time to repair.”

Remember, the consumer has more influence over the customer than the service provider does.

ITSM and Service Quality

If ITSM (or ITIL processes) is being fully done ‘right’ then it is quite helpful. This is everything from defining what should we provide (a pizza), how we should provide it (with these specifications), at what costs (using x items at x usage rate with x skill sets at x bill rate)  – the Service Strategy/Service Design – to building the pizza using these documented procedures, cooking the pizza, verifying the pizza meets specifications then packaging the pizza – Service Transition, to actually delivering the pizza to the customer (or consumer), and responding to any issues (Incidents/Problems) – Service Operations. 

But none of that really focusing in on an important area and that is the difference between the customer and the consumer and trying to understand the consumer and their perceived service quality.

It would seem that you could make the pizza to exacting customer standards but still end up with an unhappy customer, if ultimately, the consumers reject the pizza.

The point here then is – figure out who your customer is, who your consumer is, and the differences between what your customer wants (is paying for) and what your consumer believes she should get (expectation). Then you need to help the customer and consumer get closer together (sure, you may think this isn’t your job, but hopefully I’ve pointed out to you that you won’t have a job if the consumer and customer are not aligned) and then manage those expectations. You need to carefully track the delta between the delivered service perception and the delivered service expectation of the consumer.

If you are doing all these things, you will be more successful than if you forget all of that and instead implement a CMDB and make wonderful reports on Incidents and Problems and Change records.

Some technical notes…

I recently wanted (needed?) to find out the delta between ‘actual’ start times and ‘requested’ or ‘scheduled’ start times of Change orders.

We use CA Service Desk 12.5 where I am right now. The output of the data looked liked such:

Scheduled Start Date

12/2/2011  6:15:00 PM

Actual Start date

12/2/2011  6:21:58 PM

Let’s say that was cell A2 and cell B2.

The first thing I did was: =(B2-A2*86400). This produces the raw number of seconds. In this case 418 seconds.

I called this “Total Seconds”

In the next cell I did this: =ROUNDDOWN(C2/60,0)

This will produce the number “6” which is the “Total Minutes”

In the next cell I used this: =ABS(D2)

This will produce the number “6” which is the “Absolute Minutes” – this is important if/when we deal with negative numbers which can happen when people start changes before their scheduled start time.

The next cell I used was this: =ROUNDDOWN(D2/60,0)

This produced the number “0” in this case. This captures “Total Hours” – this will produce a number if the delta is greater than 60 minutes or 3600 seconds.

The next cell I used was this: =ABS(F2)

Which will show the “Absolute Hours”

The next cell I use was: =ABS(C2)

Which will show the “Absolute Seconds”

Now we basically have all the raw numbers and converted absolute numbers we need to produce values that will show negative or positive time deltas with only 1 negative sign showing up in the final number.

Now the more ‘complicated’ calculations begin.

In the next cell I use this formula: =IF((H2>3600),(H2-(3600*G2)), IF((H2<3600),H2, H2))

This will produce the total number of ‘seconds’ that are left over after all ‘hours’ have been accounted for. In this case it is just 418 seconds. However, if our initial times were say..8001 seconds apart, then we would have over 2 hours of delta and this formula will have produced “801” seconds.

In the next cell I use this formula: =IF((E2>60),(E2-(60*G2)), IF((D2<60),D2, D2))

Similar to the previous cell, this one calculates all minutes left over after all hours have been accounted for. This will also place the negative sign at the minute mark if appropriate.

In the next cell I use this formula: =IF((I2>60),(MOD(I2,60)), IF((C2<0),C2,I2))

Again, this determines the total left over seconds after all the minutes have been accounted for. It will also put the negative sign at the second mark if appropriate.

Next I use this formula: =F2&”:”&J2&”:”&INT(K2)

Which will produce the “Math Time” or “Raw Time” and in our case it should look like this:


Finally, I use this formula: =TEXT(L2, “h:mm:ss”)

Which will display the “Display Time” and that will look like this:


If we had -418 instead of 418 the final two sets of numbers would look like this:



So, not ‘perfect’, but it will put the negative sign at the appropriate level.

I have run many tests against this and it seems to work for any reasonable number I can think of or have seen in the reports.

There may be a more straightforward way of doing this. I must admit I became tired at some point and may have overlooked an easier path. I tried many different approaches but this is the only one I have found that deals well with negative as well as positive numbers and both large and small numbers.

Alerts, Events, and Data Collection

Over at IT Skeptic there is some question over the ITIL use of the terms “Event” and “Alert” . I thought this was fairly amusing because I’ve been having this discussion with my customers (and my team) for years.

I have designed, implemented and managed HP OM (OVO or Openview), NNM, OVIS,  Netview, T/EC, Concord SystemEdge, Topaz/BAC/BSM (including BPM/RUM), Freshwater SiteScope/Mercury SiteScope/HP SiteScope, and AlarmPoint/xMatters over the past 10 plus years.

When trying to set this ‘stuff’ up we have to know what is important to capture, what is of some importance to know (informational perhaps), and what you need to know right now to take immediate action on.

Over the years I’ve come to think of it in these terms

Data Collection = anything we’ve (either the customer, or us based on our ‘expertise’) determined important enough to capture and record. The primary source for reporting.


  • Disk space utilization every 5 minutes (we don’t care what it is, only that we capture/record it)
  • CPU
  • Security Log entries,
  • End user emulation transaction times

Events = Any data collected that either has value for immediate action (either automated or manual) or contains information of a ‘proactive’ nature. Provides additional insight into Incident/Problem Management. Can be used by Problem to trend “events” over time.


  • Disk space has exceeded a certain threshold (over a period of time (my preference), or occurred once) – Perhaps 50%, or 65%, or 95%
  • A security log entry of a particular type
  • End user emulation transactions have failed – from one location or maybe all locations (over a period of time (my preference), or occurred once)

Alerts = Any event that meets or exceeds defined thresholds that require immediate attention/action by ‘service providers’ (sys admins, DBAs, network engineers, product managers, service managers, service desk). Indicators of Incidents and/or Problems.

  • Disk space has exceeded a certain threshold – usually something high like 95% and most always over a period of time (to avoid the “false positive”)
  • A security log entry of a particular type
  • End user emulation transactions have failed – usually from more than 1 location and for a period of time.

So, I think of it like this: Alert must first be an Event which must first be Data that is collected.

  • Data collection > Events > Alerts
  • Lots of things > Some things > Few things

Not all Data collected is worthy to be an Event – I just want to log CPU over time so I can graph it later

Not all Events are worthy to be an Alert – CPU spiked once on one web server (although if it happens every day, perhaps Prob Mgmt using reports on Events can see this an investigate)
All Alerts should create Incidents and/or Problem tickets. Something is really messed up (or is soon to be) requiring immediate (or near immediate) action/work.

Works for me anyway .