An ITAM practitioner is someone who is an all-around guru of ITAM while doing the day-to-day work of organizing, monitoring and reporting. This busy schedule can lead to mistakes. For instance, I was surprised one day when we almost let a software contract renewal go through the process before we realized we had missed checking with the process owner of that software. It turned out that we no longer needed that software. Luckily, we had not yet processed the paperwork and the vendor did not require a 180 day notice for cancellation.
As I reviewed the process to prevent making this mistake again, I kept thinking up more questions. If we make this change to our procedures, how will I know if what we are doing will prevent this situation from happening again? Of course, our department and our company in general have Success Factors and Key Performance Indicators (KPI’s) for our ITAM department. But what about that honest, day-to-day running of the department? Are we doing a good job for ourselves?
KPIs for the Basics
Of course, we ITAM practitioners have our differences. Depending on the size and scope of your organization, your daily work may be focused on specific aspects of ITAM or be very broad. However, let us take into account the common things that contribute to the daily grind of ITAM. Vendor management, asset inventory, software compliance, asset disposition, contract maintenance and configurations or CMDB management are all needed to successfully execute your company’s ITAM policies. If you already have success factors and KPI’s for all of these areas then you can stop reading here. Otherwise, let’s review what can be done to highlight your success and provide opportunity for achieving more success, i.e. the parts where we need to improve.
Write it Down
I’m trying to coin a new industry phrase. I call it the MIPP, the mini-internal policy and procedure. Maybe it will catch on. The MIPP document is strictly internal, for you and your department. The goal of the document is to describe how the daily ITAM work is basically executed. It also includes an easy measurement on the steps you will take to achieve those tasks. The MIPP document is a great starting point for a departmental Standard Operating Procedures manual. I’m sure every good department has one of those… (Sounds like a good idea for a new article).
If you’ve ever written a policy or a procedure, you know how hard it can be to get the language just right so it meets the company guidelines. The MIPP document is much easier. The format is as follows:
That’s all there is to it. The whole document shouldn’t take more than one page at the most. I think that the best way to show the practitioner’s point of view is to do some work and give an example. Earlier, I mentioned the problem I had with a software contract. Here is a short version of my MIPP for that problem.
What MIPPs Deliver
See how little information is needed to show if you are meeting the needs of the department and the needs of the enterprise as a whole. A MIPP can easily be written to define success with contract negotiations, vendor management, updates to the CMDB after a change control or even asset retrieval for disposition. You could put every one of these documents in your Asset Management database as a type of contract to give you an automated notice of review. If that’s a complicated change to the Asset Management tool, then put them in your own email calendar.
There are many reasons why sharing these documents and results with your ITAM colleagues are a good idea, but you can keep it to yourself and measure your own success privately. My goal for the takeaway on this article was to give the average practitioner working in the ITAM department a way to measure and monitor their own success and maybe find a way to add just a little more value to their ITAM department. If you have questions or comments please feel free to contact me at email@example.com.