Monday, 28 October 2013

Access Management Process Reviews

It seems that only when the topic of audit comes up do we think about the way we review the overall Access Management process. While it is likely that we regularly review the access to systems (quarterly etc.), should we not be thinking in terms of the access lifecycle. In other words, do we really review the way that access is managed?

To take this back a step, IT organizations in simplest terms are managing the way that access is granted to key systems through 3 activities

  • Onboarding – person is starting new position / role and access is granted via a manual process, or automated with tools and may be verified through a “source of truth” authority in either a team (HR) or an application
  • Changes / Modifications – person is modifying position / role and will require either manual intervention through various managers or again automated through a toolset
  • Offboarding – person is leaving position / role in one way or another and the termination process drives the removal of access either manually or through tools

For the most part validating the onboarding and offboarding (joiners and leavers) may be simplest to define. “Gillian is unable to do her work as access has not been granted” (Onboard) “Desmond has quit, remove access” (Offboard).  

It is the “Changes / Modifications” component that may need to be tightened up from a process perspective. The managing of users and roles across the enterprise, especially large and diverse ones, can be quite complex when there is no underpinning process to govern it.

For example, let’s suppose we have an employee who works in Business Unit “A” and is moving to work in Business Unit “B”.

Questions you should be asking already:
  • When people change roles does your Access Management process discontinue all access from role A and then grant access to role B in a seamless way?
  • How is access to roles validated – the dreaded “just mirror John Smith” can create major access issue?
  • Could lingering access from Business Unit A follow this person to the new role?

You really need to ask yourself if your overall Access Management process is checked in a regular time frame (quarterly, annually)?

I can already hear some people saying, we have an automated tool that handles all of this. Just because it is automated does not mean it is working or still valid. The process governing how the tool works should be validated just like in the situation above

This process impacts a wide variety of stakeholders, not just the service desk and the users. Any improvements to the process should be reviewed with them as well. It might include:
  • Human Resources
  • Audit and Compliance
  • Business Owners
  • Application Owners
  • and Risk Management to name a few

Remember, finding gaps in the process and mitigating risk shouldn’t be something that is discovered as a result of an issue. Regular process checkpoints should allow you and your organization to proactively move on these before they become problematic


Feel free to connect with me on Twitter @ryanrogilvie and/or on LinkedIn
If you like these articles please take a few minutes to share on social media or comment

Thursday, 24 October 2013

#SMFlashBook – My Best Tip for Building the Service Catalog - Baby Steps to the Service Catalog

While there are many drivers for the implementation of a Service Catalog, in my experience I find that there are two keys which I would start with.

Scope and Perspective

From a project perspective, scope has to be clearly defined if we are ever going to reach our deployment target. Let’s face it there are many things which will contribute to scope creep, so having something solid is critical. The scope for Service Catalog is to, oddly enough, catalog services. But within the scope we need to define what the service is before anything else. It is possible that the journey to define services has an underlying initiative to introduce SLA’s but you have to crawl before you can run 

While perspective might not be on the list of things to review, I find that it needs to be considered before beginning to avoid any potential repeating pitfalls we might have experienced in the past. Perspective may have a few fundamental components

Have we tried this before? If so what happened?
If we have attempted this is in the past we need to identify what didn’t work so that the same mistakes are not repeated. Sounds like a no brainer but repeating issues happens all the time. Stakeholders in both IT and the Business may have some reservations regarding the success of this newest attempt and might ask WIIFM (What’s in it for me)

We also need to ensure that we communicate and keep all stakeholders, whether they are IT or Business, informed on the progress we are making. I have seen countless projects of all types start out with a big bang and then the communication fizzle begins. Drive some excitement about this initiative and gain some momentum around that

What is a service really?
It may be in the infancy of these projects that IT assumes that they know what a service is and that they then can create the service catalog around it. The challenge here is that there may be a difference in the understanding of the defined services. You may never make it simple enough but a clear definition from the onset when discussing the services with the business if critical. This ultimately ties back into your scope

Overall starting the implementation on the right foot will allow you to position IT to provide exception services for your business.

But this is just the beginning…..


Follow us on Twitter @ryanrogilvie

Monday, 21 October 2013

CSI - Collaborative Service Improvements

I spoke recently with a service delivery manager who was frustrated with his inability to make lasting improvements to his current service management processes, and it was impacting his ability to improve service delivery. I asked him where he thought the plateau might be originating, but he was unsure, saying that his change management process was really good. Good being a pretty subjective term, I asked him what good looked like.

He said that their Change success rate was through the roof—almost at 100%—but for some reason incidents were still coming up. Immediately an alarm went off in my head. He continued to say that even with the success of change management, the other processes couldn’t seem to make the same level of improvements.
It sounded as though the service management processes were attempting to operate in a silo even though that was not the intention. I asked him how he was planning to address the fact that incidents were on the increase despite a nearly spotless change implementation record. The lines in his forehead suggested that he was hoping I could help with that. I decided it would be best to share an example.
Assume for a moment that a challenge faced by your business (remember, it’s about them and achieving their outcomes) is that small issues seem to arise with regularity after IT implements changes. Sometimes these appear right away, while others seem to take a while to bubble to the surface. While some people might have the gut feeling that this issue was the result of the change put in last week, no direct relationship was established, and the Service Desk who receives the initial escalation may not be in a position to put the two together.
This is where having a collaborative approach to service management is beneficial
Breaking down Silos
If, as my colleague suggested, Change is the driver in all things service management, then the IT organization may look to the Change owners to connect the dots after changes are implemented. However, gathering the process owners (or those responsible) for each of the processes on a regular basis to discuss what is working well and what is not will lend itself to a practice of breaking down internal silos. In a discussion, the following dialog may occur:
  • Change owners are quick to point out that these identified issues were small enough not to have been caught in testing or validation, and that in future deployments of this type this testing will be included.
  • The Service Desk Manager indicates that the defect wasn’t identified right away, and when it was, it may not have been recognized as a result of the change completed due to misaligned timelines. Initially they created low priority incidents, which they forwarded to support teams.
  • In receiving this multitude of incidents, the Incident and Problem Managers should have communicated to all parties to tie all things together. Unfortunately they kept the information close and worked solely with support resources to correct the issues.

Because all these activities were worked on in silos within service management, the ability to make improvements through a collaborative spirit is diminished. Just because you work together, don’t make the assumption that you actually are doing the “together” part. What should happen when we have issues like this that we are trying to tie back to a change is some form of weekly review. In this particular example in ITSM alone we had several stakeholders from the service desk to Incident, Problem and of course Change.
Remember, the issue has already happened. We need to learn from this experience and endeavor to not have this happen again if possible. We should ask questions like:
  • What could we do better next time?
  • What have we learned?
However, to get lasting improvements you may need to look at these gaps from a big picture perspective. With regards to this example what if I asked you to also consider some the following:
  • Configuration Management
  • Knowledge Management
  • Event Management

At the end of the day, IT has a goal to provide services. There should be no internal finger pointing with an “us vs. them” mentality. You need to collaborate with all the teams to ensure lasting success. You also need to ensure that all this is documented and shared with not only service management but in IT as well, to grow on what has been begun.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn
If you like these articles please take a few minutes to share on social media or comment

Tuesday, 15 October 2013

Service Management Reporting - Beyond the TPS Coversheet

I bumped into a colleague over lunch and asked how things were going and he said with a degree of dismay on his face

"It's time for me to submit my Service Management metrics to IT leadership."

He didn’t seem particularly enthusiastic about the prospect of this.

"What's the challenge?" I asked.

“It’s the same thing I hear each month; the managers from each of the groups I report on complain that the numbers aren't right. Yet they never seem to do anything with them.”

I stood there nodding in agreement.

He went on to outline the following that they report on the usual suspects

  • Incidents by workgroup.
  • Incident volumes
  • Incident Resolution times
  • Priority breakdown

I mentioned to him that comparing against the silos in IT was really like comparing apples and oranges. the incident resolution time from one group may not be expected from another. I asked him if he had a way to report against services. These current metrics really only allow the group that owns them to work on an internal component of the way that they provide service. At the end of the day all that really matters is that your service is provided to business expectations.

My colleague mentioned that they are way far away from being able to talk about service metrics and sharing those with their customers in even a limited way. I totally understood where he was coming from.

This is as good a place to start as any. It’s time to stop thinking about things in the limited IT scope and start thinking about reporting in terms that the business will not only understand but be able to contribute in a way that you will be able to work together to improve the delivery of service.

Find out what is causing the roadblocks to achieving this. If it is a process, for example you aren’t able to map services to CI’s because you don’t have a structured CMS, or maybe one at all. Maybe you don’t truly understand your business services.

Once you get the ball rolling start the discussion with the business. Let them know that you are in the beginning of this journey and that you need their help to get you to a place that collaboratively you are achieving your business outcomes together

Follow us on Twitter @ryanrogilvie

Monday, 7 October 2013

The ITSM Implementation Scope Creep – A Savage Creature

There may be a time where you will need to implement a new ITSM process or will need to improve on one. This can be where the ITSM Scope Creep lurks. This creature preys on those who dare to dream of making sweeping improvements overnight.

Scope Creep

Scopius Creepius

The Creep Habitat

The Creep will remain dormant until a "what about" is asked by either someone from the implementation team or a senior manager. The what about is a question that may sound like this “We are enhancing our problem management process but what about our knowledge process?” It can be very easy to let the creep in. especially when the question is coming from the Senior Management or from the project sponsor. The risk here is that these types of things should have been flushed out in the requirements phase so that when these questions do (and they always do) come up we can answer to them accordingly

Creep Population

As long as a project exists there are Creeps at every turn

Creep Diet

The creep feeds on the what abouts. So it can be crucial for the team working on the service management improvement project to find a way to handle these questions effectively. These questions may be valid and should be managed as such. In the case above where the question was asked about knowledge management we could say either that we have tabled this pending activity or that this is planned for the next iteration or phase of improvements

Creep Life Span

The potential for Creep to occur is always there, and even the implementation team may have trouble ignoring even the simplest what abouts. There have even been reported cases where Creeps have reproduced into other activities spawning further scope creep. However, allowing the smallest crack in the dam to present itself may be just the thing that can prevent a successful ITSM improvement from being implemented.

Learn to deal with this creature. Allow the what is presented to be turned into something productive in future implementations or allow the current one to be directed in a positive way.

Follow us on Twitter @ryanrogilvie