I have been quiet on here for awhile.
I suppose having babies will keep you busy on other things besides blogging. Don’t worry, I am still working, thinking, and learning.
Lately I’ve been reading a lot on Systems Thinking, Enterprise Architecture, DevOps, and Scrum.
But the big news right now is that I have been lucky enough (again) to have an opinion piece published by The ITSM Review.
PMP or ITIL v3 Expert – which would be better for your career?
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!
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…
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.
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.
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.
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.
I break this down into 3 main buckets of information that needs to be captured, tracked, reported and analyzed.
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:
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.
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
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 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:
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.
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:
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:
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.
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.
Charles Betz had several wonderful posts on the EMA blog’s but since he no longer works there EMA has seen fit to remove access to his work.
Fortunately for me, one my many habits is to open up about a billion tabs (much to the annoyance of my wife and to the amusement of my coworkers). I had noticed that EMA was no longer allowing access to Betz’s work but I happened to have several of them still open on some tabs! So, I just copied them and saved them to Evernote.
Sadly for the rest of the world we’ve all lost out on some really good information.
Luckily, one of Charles Betz’s blog entries was also posted at Nimsoft located here.
The basic premise of this work and some of this other writing is that IT does not do a good job of prioritizing all work from a universal standpoint.
Sure, we prioritize Incidents (against other Incidents), and we prioritize projects (against other projects) and maybe we prioritize day to day tasks (again, just against other day to day tasks) but we don’t really prioritize all of our work
Here is a direct quote from one of the now lost EMA blogs from Charles Betz:
“Jane is a systems administrator in a large enterprise. Or a DBA, or a security architect, or any of a number of similar positions providing shared services.
There are three primary ways that demand for Jane’s services appears:
On Wednesday, she gets called into a Severity 2 incident involving the organization’s supply chain system. On Thursday, she has a deadline of responding to a security audit finding for the organization’s general ledger system. And on Friday, she has a critical path deliverable due for a strategic enterprise project. Fun life!
There is often no specific prioritization across these tasks beyond “who is screaming loudest.” The Sev 2 incident may command her attention until it is resolved, but is this really the correct priority? What if it’s only a partial outage, and the project manager is ramping up the pressure for her deliverable? Jane may be attempting to do a “little bit of each” – switching her attention across the various tasks competing for her time, a very inefficient way to get work done.
Stories of such overburden pervade the IT industry. Ask yourself: how many people in my company accept both project and service request work (e.g. Incidents, Service Requests, Changes, perhaps “Work Orders” if distinct from Service Requests or Changes)? And are they also assigned to the less formalized initiatives (which we’ll call “continuous improvement”)? Do their line management and their project manager at least have visibility into this aggregate demand and its consequences?”
When I read this I thought my concept for how Change, Project and Release management would fit nicely with what he is talking about – a better way to manage all of IT Demand from a universal perspective. But that still leaves out Incident, Problem, and other routine tasking.
The traditional Plan Build Run methodology basically only considers projects or efforts of significant size. All other efforts are just not “planned” – they are just done, often behind the scenes or under the covers.
Often, as Charles Betz describes, leaving it up to individual engineers, administrators or team leads to prioritize and track this other work is inefficient and sometimes even ineffective.
It seems to make sense that a good way to solve this issue is to track all work and prioritize all work against all other work and not in silos – silos of type of work or often silos by department or team.
Can you imagine IT Managers actually wanting to prioritize and track all this work every day? Well, maybe they will want to…but will they actually do it?
Typically IT Managers are not only as reactive as staff but often are the cause of the reactive nature of the environment. How many times have you seen an IT Manager forgo putting in an Incident ticket and instead just call the engineer directly and task her with work? How many times have you seen an IT Director or a CIO put in a Problem Candidate to be reviewed, prioritized and assigned properly and instead just call the IT Manager and tell them they want to see an RCA and some fix actions by tomorrow? Happens all the time doesn’t it?
So, if we really do want to better manage our resources and really do want to better prioritize our work effectively how on earth can we do it?
Start by at least consolidating work types together.
As I mentioned before – I think all changes requests should be tracked – which would include projects. That is everything from wanting to patch a server to create a new service is tracked in a single Change Management tool and managed by a single overarching Change Management process.
What about Incidents, Problems and “tasks” (things like audits, capacity planning, or CSI efforts)? This is more of a challenge because most IT shops:
Somehow we need to be able to separate the requests and incidents/interruptions that are internal only from those that are end user/customer based. Hopefully we can use the same ‘tool’ but with a different flag or something that precludes it from any customer SLA or customer reporting.
Also, more IT shops need to develop a better understanding and implement more processes around Problem and CSI. We can’t prioritize all work efforts if all work efforts are not being first recorded somewhere!
Finally, we (as in the IT community) need to develop some sort of terminology and framework that captures the non Incident, non Problem, non CSI type tasking that happens all the time.
And however we do this…it has to be easy. : – )
No one is going to bother doing any of this if the system of record takes more than about 10 seconds to create a task, a Problem Candidate, or a CSI candidate or more than 5 seconds to find one you’ve already created. I can send an email in that amount of time and I can search my email sent folder fairly quickly.
We have to do better than email.
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.”
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…
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?
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’.
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:
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.
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?
Over the last few weeks I have just been overwhelmed with just how much “stuff” is out there related to ITSM.
I must live in a rather insular world. No one I know in the “physical” world is on Twitter or regularly uses LinkedIn groups. In general, the several ITSM people I know in the “physical” world are not utilizing Social Media outlets all that well. And I haven’t been doing much with it myself.
I have over the years infrequently responded to blogs, my first response to ITSkeptic (then known as ITILSkeptic) was Sept 24, 2007. From there I found Betz’s blog (ERP4IT) and bought his book (1st Edition – the one with the little shoes on it). I joined LinkedIn October 6, 2008 and have been involved in discussions and groups on and off since then.
So, while I thought I was “there” in the “virtual world” (and I was compared to everyone I know in the “phyiscal” world) I was actually being completely and totally left behind.
If you go to Twitter right now and search on #ITSM you will find an incredible amount of information. Not stupid crap (about people having to wait in line at Starbucks or nekked pictures of people I don’t want to see (which is really all I thought Twitter had) but real, actually useful information. I have found more resources in the last few weeks on Twitter than I did in the last few years without Twitter.
Then there is Facebook and G+. Places to go and collaborate, communicate, ‘engage’ with other ITSM professionals. Learn, grow, challenge your way of thinking. It is incredible.
Where have I been?
Luckily for me my discovery of this incredible online world happened right before TFT12.
If you don’t know about TFT12 – please go here, find out about it, watch the videos.
This is exactly the type of collaboration and huge, wide world of ITSM professionals there is out there in the virtual world. There were 24 hours of FREE conference session videos. You don’t have to travel, you don’t have to even wear pants, and you get to watch some really great material.
Standard + Case – are you kidding me? That concept is going to work its way into “standard” ITSM thinking soon. With TFT12 you have a chance to learn about it NOW, from one the most respected thought provocateurs in the ITSM space.
Chris Dancy – we, as a professional group, are so indebted to this man, dragging us forward. Without him, a lot of this would not have been possible. He made TFT12 possible. I imagine…any virtual conferences that ever happen in the future about anything…ANYTHING…it is because Chris Dancy proved it can be done.
Knowledge Worker – I have read Drucker. I know I am a knowledge worker.
But before I read Chris Dancy – I had no idea what it meant to be a knowledge worker in the 21st century. Or even really how to effectively be a knowledge worker in the ever expanding and important virtual world.
You are not just your physical self. You are also your virtual self. To be an effective knowledge worker in the future (the now) you must create, manage, and expand your virtual self. Failure to do so is limiting to your physical self.
The era of the online reputation is now. Build it, manage it, own it or it will own you.
I have a lot of work to do. A lot.
“If you don’t like change, you’re going to like irrelevance even less.”—General Eric Shinseki, retired Chief of Staff, U. S. Army
http://www.itskeptic.org/content/british-government-cabinet-office-selling-itil-and-prince2
As is Prince – the competitor (if you will) to PMI (the PMP certification).
You can find the tender here: http://ted.europa.eu/udl?uri=TED:NOTICE:347757-2012:TEXT:EN:HTML
What will it mean for ITIL? I’m not sure.
Bigger question is – what will it mean for ITSM?
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.
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?
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.
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:
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:
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):
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:
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…
ITSM MD 