Published Article

I’ve been lucky enough to have an article published over at The ITSM Review.

My article is about Process Owners vs Process Managers vs Process Engineers – what they have in common and what separates them. You can find it here!

Advertisements

Ideas on Categorizing Changes and Problems…

Categorization

Everybody categorizes changes and problems. But what I find is that the categories are typically too narrow and don’t allow for broader understanding of  what is driving your IT shop.

Usually data will show that you do a lot of work in a certain application or service. Or that your changes are only planned 8 days in advance or your emergency changes are 15% of all changes. Or maybe you had 13 problems in Email last year.

But this doesn’t help explain what is driving these numbers

Change Categories

I am a big fan of not just capturing if your Change effort was an Emergency or not but what the real driver for the change was.

In particular, I believe you can “categorize” your change efforts into just a few buckets:

Break/fix – something is broken and you have to fix it.

Planned Maintenance – Maybe this is a planned patch or reboot or even upgrade of your application. This is just to keep things going, maybe to maintain support with a vendor or close a security hole. There is no “additional benefit” to the client  that is driving this effort there might be some, but it isn’t the driver. How do you know if it is the driver? Well, how are you selling the effort? Are you selling it the change effort as something that will change the way the client works (additional features) or will they even notice? Is it more for your IT support staff or for the client? If it is for your IT staff – it is PM (unless it has already broken, then it is B/F).

Enhancement – This one is tricky. Most people in IT will want their work to go here but in reality, it is probably PM. Enhancement is for change efforts that will ‘enhance’ the way the client does work today. It will cause some Business change as a result. If your change doesn’t do this, or doesn’t intend to do this, it isn’t an Enhancement. Some examples:

I have a plain old telephone system. I am switching it all out for IP telephony at some considerable expense. This requires a lot of IT engineering and transition planning. When it is done, the business will be able to make phone calls just like they do today.

So, what kind of change is that?

If you answered Enhancement – you would be wrong. Nothing about how the business functions will be changed because of this effort. They will still make phone calls like they used to. The underlying technology has changed but that did not “enhance” the business did it? No, it did not.

Another example: I am using Exchange 2003 and I’m upgrading to Exchange 2010. There are a lot of new features that we may take advantage of in the future. This change though is just getting us to the new infrastructure. There is a lot riding on this because our company lives and dies with email.

What kind of change is this?

Planned Maintenance. Again, it does not change the way the business works. It is a background change for IT. That doesn’t take away from the hard work, the long hours, or the importance of the work. It just categorizes it for what it is.

One more example: When a new person is hired, the hiring manager (or office manager) can now click a single link from the Companies Home page and fill out a small form. This will kick off all the tickets that need to be created for laptop provisioning, phone provisioning, and account provisioning. The master ticket will then be emailed to you. You no longer have to call the Service Desk and track multiple tickets.

Finally, an Enhancement!  This is taking current service provided and making them better. Crucially, this is going to change the way your client works – not a drastic change, but a change nevertheless.

Transformative – This change is fairly rare. This is really transforming the way the client does business. This isn’t a fairly small step (Enhancement) this is a large step requiring extensive training and probably new/changed business processes.

Example: We are integrating Email, Voice Mail, Instant messaging and creating “soft phones” on your laptops. We are also introducing camera’s for all laptops/desktops so we can do video conferencing. We are calling this Unified Communications.

This can be a fairly dramatic change to an organization requiring a lot of training to your customer base. There are also a lot of new features (voice mail accessible in email, ability to “see” each other) that need to be discussed and explained so we can make the best use of them. One of the biggest might be the “soft phone” on the laptop. Now your work phone travels…so we expect you to pick it up. : – )

Perhaps though, this isn’t a big enough change for you to qualify as “transformative” so you may only call it a “enhancement” – that is fine. The point here is that you have to think about it and you can’t call everything you do “transformative” or an “enhancement” because of the impact it has on IT – the impact has to be on the customer!

Finally, the last type of change I would categorize is:

Legal or M&A – Any type of change that is dictated by legal requirements or because of merger and acquisition activity. Typically there is little lead time for this work – so it is actually “interrupt” work. This is probably coming across as an “Emergency” change – but the reason it is an emergency change is very different than say B/F. You probably need to know that so you can explain why Emergency changes have gone up or why you can’t get them below a certain point. If your business is buying/merging or heavily regulated with lots of rule changes – there is only so much an IT department can “predict” – the rest is reactionary.

Problem Categories

Now with all that in mind, I was thinking of Problems. What are the main categories of Problems?

The list I came up with are:

Hardware – Rather simple one here. A hardware error. I suspect you won’t see many of these but still, they happen from time to time.

Engineering/Configuration – This is an error that was introduced in engineering or configuration of the system, application or service. This could be vendor caused or internal engineering caused. This type of error is typically troublesome, hard to find, and takes awhile to fix. If you are lucky it is something relatively straightforward like a setting was wrong on your Load Balancer so it wasn’t actually distributing the load properly.

Administrative/Operational – This is an error caused by the inattention of the operational staff due to a) ineptitude b) ignorance or c) understaffed (other priorities). Things like, a disk filling up is an Administrative/Operational issue. Patches not being applied in a timely manner causing a security hole to be exploited is a Administrative/Operational error. A redundant NIC failure that isn’t noticed, then when the primary fails…the server is offline – is a mixture of Hardware and Administrative/Operational error.

That is it. All errors I can think of will fall into one of those 3 categories.

So, what do these categories tell you?

Well, for changes it tells you what type of work you are doing – Break/Fix and Planned Maintenance are KTLO (keep the light on) type work. They are “operational” in nature. They don’t excite the business at all (they do however, keep it running).

Enhancements and Transformative changes are all about BITA (Business IT Alignment) – what are you doing to help the business grow?  Do think you are aligned with the business? Why then are only 10% of all your changes either Enhancements or Transformative?

Legal, M&A – is a mixture of KTLO and BITA. You have to do it keep the lights on but it isn’t IT driven, it is business driven. This data can show them that you do jump when needed.

You can even use these categories to help set urgency (or priority if you are so inclined). What is more important – KTLO or BITA? Where do you put more of your attention, more of your star players? Probably BITA, but that is for you to decide.

On the Problem data, the Hardware category might be interesting but it probably won’t be. What will be interesting to know is if most of your Problems are Engineering related or Operational related. Is it because you are not doing a good enough job in Service Design/Transition or because you are not doing enough in Operations?

They require different organizational responses so it is probably quite helpful to know the answer. Should you invest in a new Testing team, testing manager, testing software or should you spend more on hiring (or outsourcing) Operational efforts? Maybe you have poor processes, or poor operational tools (like an Event tool or alerting tool).

Categorizing your changes and problems in this manner can help you make these decisions in a way that the traditional category methods cannot.

Vendor Management – some thoughts…

Not for the first time I’m working to help establish better ‘vendor management’ Mainly my work is falling into 2 broad  – keeping track of licenses and vendor relationship management.

Keeping track of Licensing and Support

I break this down into 3 main buckets of information that needs to be captured, tracked, reported and analyzed.

What did we buy

First we need to know what we bought. I think the following bits of information is important. Now Purchasing may want more/different information but for IT staff, we will want to know:

  • What licenses did we buy from Vendor X
    • By Product
    • By Purchase Order (date)
    • By Internal Team (It is possible more than 1 internal team bought the same product at different times – for different amounts)
  • What support did we buy from Vendor X
    • By Product
    • Number of Licenses supported  (Not all licenses are always supported – for instance, maybe we bought 100 but only got support on 75 because the other 25 are in our lab for testing)
    • By Purchase Order (date)
    • By Internal Team
  • When will licenses purchased from vendor X expire
    • By Product
    • By Purchase Order (date)
    • By Internal Team
  • How many licenses are currently active from vendor X (Sometimes licenses are superseded by other purchases or by coterminating efforts or other consolidation efforts)
    • By Product
    • By Purchase Order (date)
    • By Internal Team
  • What is the total amount (sum of all active licenses) spent on vendor X
    • By Product
    • By Purchase Order (date)
    • By Internal Team

If you have all this information you will be able to see if you have multiple teams buying the same stuff (this happens), if you are not taking advantage of bulk purchasing (by buying smaller amounts at different times), as well as just getting a clear idea of how many licenses you (believe) you have in total and how much it is costing you.

What Are We USING

Next we will want to know what we are currently using. We will then use the output of this data to compare it to the output of “What Did We Buy” so we can see how are doing

  • How many licenses are we using from Vendor X
    • By Product
    • By Internal Team 
    • Last Audit Date (Audit Date for each Internal Team using a product)
  • How many times did we contact/use support from Vendor X
    • By Product
    • By Internal Team
    • Last Audit Date (Audit Date for each Internal Team using a product)

So, it doesn’t seem like a lot of information here – but the issue here is actually getting this data. This will require various audit processes and probably some manual work. I’d recommend you do this at least 2x a year though.

Once you have this information you can compare what you are using to what you have purchased and see where you are with capacity (under, over?). This can then be used to help you plan future purchases. You can also see if one team is using a product more than another team – this could lead to consolidation and management by the team that uses it the most while the other team just becomes a subscriber.

On the support information – you may find that you are paying for 24/7 support but don’t need it. It isn’t always a question of how often you’ve contacted support though – some applications (or hardware) are business critical so, even if you don’t call support often you may want to have 24/7 support. Otherwise, you may find some cost saving opportunities by reducing the amount of support you are paying for.

THE VENDOR’s RECORDS

The previous two parts seem “obvious” to most (even if they don’t actually do it) – this one though is usually less “obvious.”

The vendor should also have records of what you’ve purchased and how many times you’ve contacted support. This part is to ask them for their records and then you compare this to your records.

You may be surprised to find that you think you purchased 100 licenses while the vendor thinks you have 110 or maybe 90. You may think you have 24/7 support but the vendor thinks you only have 8/5.

This however shouldn’t just be a report or spreadsheet provided by the vendor. Hopefully you use this opportunity to meet with and discuss this with your vendor. You should for instance cover things like – how the licenses work, or what is the future of the product. You may be surprised to know that you are not using the licenses in the intended manner (maybe this is a good thing or a bad thing – maybe you are applying them to your test environment and you don’t have to do that – or maybe you aren’t and you should) that the product will soon be discontinued.

Information you will  want to collect from the vendor:

  • What licenses did we buy from Vendor X
    • By Product
    • By Purchase Order (date)
    • Last Audit date (this should be done at least once a year, hopefully 2x)
  • What support did we buy from Vendor X
    • By Product
    • Number of Licenses supported  
    • By Purchase Order (date)
    • Last Audit date (this should be done at least once a year, hopefully 2x)
  • When will licenses purchased from vendor X expire
    • By Product
    • By Purchase Order (date)
    • Last Audit date (this should be done at least once a year, hopefully 2x)
  • How many licenses are currently active from vendor X (Sometimes licenses are superseded by other purchases or by coterminating efforts or other consolidation efforts)
    • By Product
    • By Purchase Order (date)
    • Last Audit date
  • What is the total amount (sum of all active licenses) spent on vendor X
    • By Product
    • By Purchase Order (date)
    • Last Audit date
  • How many times did we contact/use support from Vendor X
    • By Product
    • By Internal Team
    • Last Audit Date (Audit Date for each Internal Team using a product)

Using the information

Hopefully it is fairly clear what you can now do with this information. This can be a very useful tool in your budget planning, vendor relationship management, internal auditing practices, and even improving your procurement or license management processes.

Vendor Relationship Management

Beyond just leveraging your vendor to help you keep track (verify) all your product purchases and support calls you can leverage your vendor to help you plan for the future.

Your vendor should be able to meet with you and tell you their product lifecycles:

  • What is new
    • What business opportunity does this help create or problem it helps solve
    • Can you help write a business case
  • What product is going away
    • When
    • What does that mean for support
    • Why – is it replaced with something else
  • What product is being upgraded
    • When
    • What are the new features
    • What is the upgrade path
    • Does licensing change
      • If so, how
  • How do your products integrate
    • Which versions of your products integrate with which other versions
    • Will future upgrades change any of the intergration points
  • What products versions you are no longer supporting
    • What versions
  • Is there a “local user group” meeting
  • Is there a vendor conference
    • Can you help fund the cost of going
    • Can we meet developers or product managers
    • Can we meet other customers in our area

You should meet with your vendor and discuss these things at least every 18 months. In my experience these can be hours long and usually require a NDA.

The output of these meeting though can be hugely influential on your own internal roadmaps. You may also get to go to a conference! (Worked for me more than once).

Beyond that you should qualify your vendor as either a strategic, supporting, or periphery type vendor. Meaning, does this vendor supply you with services, software or hardware that is key to your business? Or something quite useful but not quite key. Or something used by can easily be replaced.

You want to spend your time mostly with strategic type vendors and not that much with those on the periphery – although I suggest you do meet with all of them. You never know when someone can move from the periphery to supporting or strategic!

When you meet with your vendor try to keep up with the following:

  • Who is your account manager(s)
    • By services, products
  • Who is their technical resource
    • By services, products
  • Who are their VARs or partners
    • By services, products
  • Who is your account manager’s boss

You should always try to have your technical resources meet with their technical resource and have your management meet with account manager (and above). Not everyone needs to have a full meetings with everyone else. It is not much value to have your Director, VP or CIO to spend a lot of time with their technical resource or have your technical resource in a 2 hour meeting with their regional account manager.

Don’t abuse your vendor…but also don’t be afraid to fire them

Vendor’s can be a terrific resource and be very helpful beyond even “normal” – of course this depends on your relationship. Don’t abuse them. Even if the product does’t seem to be working the way you want (or were sold) it to – that is rarely the fault of the Account Manager or Service Desk you are calling for support. Your Account Manager can provide faster access to 3rd tier support or even directly to the developers. I’ve even had the head of development fly from Germany over to our office to talk about our technical issues. This can happen, if your relationship is good. They are people, just like you.

But also, if they are just not working out, they aren’t really helping you, or being responsive to your requests – fire them. I don’t mean that you just stop doing business with the vendor (although that is an option) I mean, just tell the vendor (usually a regional manager) you don’t want to see that Account Manager anymore. They are off your account. Usually this requires some meetings with a Director, VP or even CIO in your organization with some higher ups in their organization – but if that is what it takes….do it. I’ve done it, and it was worth it.

You want a good relationship, your vendor actually does want a good relationship too. Sometimes, it just doesn’t work out with some personalities, don’t fret about it, just get a new person to deal with.

Project Management, Change Management and Release Management

Change Management

It seems that most people view ITIL Change Management as the recording and approval of “operational” work being done in the production environment.

Typically what I’ve read, heard and discussed with people is some concept of putting in a “RFC” a few weeks, maybe a few days, before the implementation of the change. The Schedule of Change then becomes the go to resource to see what is being “released” in the environment when.

This (what I may call “traditional”) view of Change Management is entirely too limited.

First it completely crushes Release Management to the point where a lot of organizations don’t do this, don’t do it well, and really don’t understand how Release works with and/or is different from Change Management.

Second, it creates limited interaction with Project Management, Service Design functions, or even Service Strategy functions. If you are just considering the risk of a change 8 days before implementation, when the majority of the money, time, and other resources have already been spent…you are not doing much of a “risk evaluation.”

Project Management

All projects are essentially the organization/management of resources with the purpose of implementing change(s). There are of course lots of work that goes into doing that and doing that well. Scope statements, stakeholder communications, requirements gathering, budgeting, coordination across multiple “line” teams and the utilization of various IT processes.

Some things to consider when thinking about Project Management and the (real) role of Change Management…

  • How do we ‘prioritize’ this project vs other organizational efforts?
    • Not just priority vs other proposed work but priority vs current efforts?
  • How do we assess the risk of the project from multiple facets (before work is actually started)
    • Such as “Capacity”, “Availability”, Business Continuity”, “Portfolio/Catalog”,  or “Security”
  • How are we determining, documenting, and then managing what “gateways” this effort must pass through in order to progress from Design to Operations?
    • Not every “change” needs a detailed design review or a new pricing model – how do you determine which does and how do you ensure they go through those checkpoints?
  • How do we document and manage any changes to scope or to risk to the ‘change’ when it is in Design or Transition?

If you are not doing a RFC until a week or so you are moving to Production – you can’t possibly be capturing and managing this type of information using Change Management – so then how are you doing it….or are you doing it at all?

Release Management

The often forgotten and neglected process. Sad and lonely. Do you have a Release Management Board? How does it work with the CAB? Who actually sets the schedule for ‘release’?

In most places it seems that the Schedule of Change (to include date/time) is set by the Change Advisory Board. In doing so, I believe, you force Release to march to that tune and so curtail some of the power/authority a Release Management Process can (should) have.

The Release Management process should dictate the actual schedule of the implementation. The CAB should only state the change is “authorized” – the actual date/time, type of release, resources used in the release, artifacts required are determined by Release not by Change. Change is the ‘macro’ and Release is the ‘micro’.

How they can work together…

A need or idea for a change starts the Change Management process. Some of these will also be Projects, some will not.

Change Management can start months, maybe a year, prior to the actual implementation date. Change Management may review an RFC multiple times.

Consider the following:

  1. Need/Idea
    1. These are: Customer/Business Requirement, Customer/Business Request, Service Improvement, Service Correction
    2. Our new idea is “New Service Desk” tool.  Since it is coming from IT, it is most likely a “Service Improvement” effort.
  2. A high level business case should be put together and then you have your first CAB review
    1. Define problem, define scope/urgency, define benefits/risks, define estimate of resources needed
  3. CAB provides approval to move towards RFP and proof of concept
  4. The ‘project team’ then develops RFP and/or POC, meets with vendors, obtains testing equipment/software, performs POC, reviews POC…
  5. Team updates RFC with POC/RFP information – updates Business Case as needed. Goes back to the CAB. The CAB can then approve/deny continuation of the effort.
  6. At this stage the ‘project team’ must create Design plan, what artifacts (Capacity Plan, Security Plan…etc) will be required/updated , schedule of significant milestones (such as: requirements signoff by stakeholders, beginning of testing) and resource allocation.
  7. The ‘project’ goes back to the CAB – the Design plan is reviewed and denied (maybe they didn’t include the Business Continuity Plan, or maybe the planning seems to include things beyond initial scope) or approved
  8. The ‘project’ moves to development/design – any deviation of dates to significant milestones require an update to the RFC – which requires review by the CAB.
    1. Why was testing pushed back 1 month?
    2. What other efforts will that impact? Are resources still available? How does that impact future ‘change’ requests?
    3. Normal progression through milestones just has updates to RFC (change in sub-status could be helpful here for reporting purposes)
  9. During Design/Development – Release Management starts to become involved. They are the gate keeper to some significant milestones (such as Acceptance of Testing, Implementation Plan Acceptance) – they approve the RFC to migrate through these ‘sub-status’
  10. As the effort moves through testing but prior to implementation – the CAB reviews the change again and then provides “approval” for implementation. The schedule is set by Release Management.
  11. Release Management provides approval for the Implementation Plan and sets the date/time for the release.
  12. After implementation Release Management reviews the “release” and provides input to Change Management to assess overall success/failure of Change.
    1. The ‘release’ component can be successful while the overall change effort can be viewed as less than successful due to schedule/resource overruns, or failure to adequately address customer/business needs. This separates the assessment of the Change from the assessment of the Release.

But let’s just say that you are not doing something that large. You are just doing a  a upgrade to an existing application or maybe you are just adding capacity to a service by putting in more “servers” – Do you have to go through ALL of this stuff?

The answer is a bit of yes and no. You still need to put in the initial RFC. You list it as “Service Correction” or “Service Improvement” and you still need some high level business case (this is your justification or reason for doing the work). It will get approved and you don’t need a RFP or maybe even a POC so you move right to documenting your Develop/Design plan and identifying which documents you will create/update. This is then approved (let’s say your work does not impact Availability, or Security – so you just say you won’t be updating or creating those documents). It is then approved to move to the next stage – which then you will start to engage with Release Management. You have to progress through their stages and you can then get to implementation in production.

Of course you can always create “standard changes” which can speed this process up by “pre-approving” many steps but that of course means you’ve at least gone through this exercise at least once.

Recap…

Project Management is to manage discreet efforts. The may be large in scope but they have a defined scope. They may even have PM Boards which discuss project management practices, or certain artifacts related to Project Management (status reports). Project Management is more about “who” and “how” is something is getting done.

Change Management is to manage ALL change efforts to the enterprise. Big or small. Project or Operational. They must all be recorded, assessed, and balanced against all other requests and business needs. We cannot allow ‘rogue’ work on change efforts without governance. Change Management is more about “why” and “what” is getting done.

Release Management is to manage the transition from the ‘test environment’ to the ‘production environment.’ It is concerned with the details of those plans. Release Management is about “how” and “when” something is getting done.

The “where” is defined in your policies. I’d recommend that this type of structure apply to production as well as applying Release Management controls over your test environment.

What are your thoughts?

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.

Example:

  • 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.

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.

SERVQUAL and ITSM

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 HazyITSM.com: 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 HazyITSM.com

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.