Most of the discussion in the previous article was about operational issues. Something is broken, something is affected, something has gone wrong somewhere and it needs fixing now or soon.
This is known as incident management.
Apart from the usual “fixing what’s broken”, when we get time we look at old issues that results in ongoing incidents. After a while we can see patterns in incidents as they are raised and we group them into problems. We create a problem record, we perform root cause analysis and we either fix it or we don’t. If we don’t we record a known error and move on with our lives.
Interested in more? Download an ITIL book from somewhere as its all in there. We follow that framework to about half of the extent we tell people we do.
We get a multitude of requests from our end users be they internal or external to our organisation. Sometimes we get requests for items that are nothing to do with us but we helped them previously so they expect we can do everything (a common side effect of being customer focused and good at what you do).
It’s our job to keep the lights on. Sometimes that is fixing what is broken. Other times it’s replacing something that someone else has broken. When we have numerous interfaces to other organizations we can’t go through life expecting everything to stay constant. An old Greek philosopher once said “The only thing that is constant is change”. So we are somewhat at the mercy of other organisations with our budget and workloads as they do their own upgrades and decommissions and we have to adjust our systems and business processes accordingly. Sometimes with little notice. Sometimes with no budget (we call that creative accounting).
Enhancements
One of the most time consuming task that I involve myself in is the enhancement request. End users have a myriad of ideas on a better way to do things. Some of them are valid, some of them are invalid and some of them are just “out there”. But each one of them requires (deserves) a response. The end user has taken the time out of their day to put together a request so they at least deserve a response and a purposeful one at that. As an IT department that is trying to justify its existence to the business we have to let the users know we are there and listening to what they say and more importantly responsive to what they want.
Do I do all of the enhancements? Do I do none of them? The answer is actually somewhere in the middle (but closer to the none end). My support officers record each request into our register and give it the status “Pending Review”. Then when time permits we evaluate it in more depth by asking the requester some more questions (first point of contact that shows we are listening). We may engage someone else from the business who is familiar with this area to get a “second opinion”. They may agree with the suggestion or they may not. On occasion this has revealed that its not required and is perhaps a training issue and the correct functionality already exists. Its rare that we don’t pick this up and somewhat embarrassing when we don’t since we are the super-users (but it happens, and we smile apologetically).
If it turns out to be a valid suggestion,we hand it to our development team to do a technical evaluation. At this stage it’s more of a Order Of Magnitude (OOM) assessment determining if it is a small, medium or large piece of work. This translates to free (part of a support release), within our budget capability (meaning a paid package will be generated) or expensive (meaning funding will need to be sourced and a project will need to be stood up).
Sometimes when the upper management decide we need to be more responsive they will give us some funding to do a group of enhancements on a single system. After all its cheaper to run a single block of test cases, requirements documents and implementation plans than to create one for each enhancement. So we pick a system, contact the business owners and start the process to commence a project.
I have to be clear that this then falls outside of my unit and becomes part of the project world. We aren’t part of the project world. We are part of the operations world. Generally the two only intersect during transition from project to support.
So back on topic. The developer has done their technical assessment and comes back with an assessment that says we can squeeze it into a support release. These are usually changes to a drop down menu, a screen label or some very minor functional change. It’s from here we assess the total business impact. A requester may ask for a field to be made mandatory to assist them with their reporting requirements. Sounds fairly innocuous but imagine if everyone wanted a field made mandatory. It then turns out that filling in a form that used to take 5 minutes now takes 3 hours as you have to fill in everything even if you don’t have an answer for it. Our end users will make something up and can be quite imaginative some times. Provides hours of laughs but gives the reporting guys a fit as it throws out all of their forecasts.
Once we determine its a fairly small effort and consequence we scheduled it in and get moving on it. Even if its not a small consequence we may still make a start on it. It just usually requires more stakeholder management and communication to make it a successful enhancement.
Our list of enhancement requests grow and we are currently going through some business change to only time will tell how we fair getting them all done.
In the meantime we can continue our assessments and schedule them accordingly and wait.