Monday, 28 April 2014

Why we need Governance when we have a Process

Have you ever asked the question “Why do we do something the way we do?” When you ask it do you get the blank stare or the shoulder shrug response. If you take the question one step further and ask what makes you do that particular thing is the response an “I dunno”

The basic premise of IT governance is that it sets out to control the achievement of business goals through a balancing act of risk and value via IT processes. That sounds reasonable enough, so it shouldn’t be too complicated. The key is to understand your organizations starting point. Where are you today?

Think about whom is doing what. There should be clearly defined roles and responsibilities (possibly a RACI chart would help) to ensure we are positioning ourselves to help the business achieve their goals. It should be no secret on who is doing what.

The “what” is pretty important.

We now know 'who' is doing 'what' but there really is no point if these don’t align with the business objective. I know you hear this over and over so by now it should be sinking in. Bottom line, If you want IT to be a strategic partner with your business then you need to make the business goals yours as well.

Overall IT needs to better understand what the business requirements are, while continually delivering services which optimize cost and providing the best value available. Sounds like a mouthful, and it is. The inability for IT to do this will solidify its demise in the long term. This is where governance enables IT to manage infrastructure, applications, data and people to allow IT to deliver. No small undertaking I’ll grant you that.

Start by performing an initial assessment on the processes and activities which are currently underway. The framework you are leveraging doesn’t matter. What is important is to see where you are and then be able to build a roadmap to outline what needs to be done next.

The trick to establishing a successful governance is to start out simple. By simple I mean that there should be very few chance for misinterpretation. Again, having a formalized and communicated RACI and roles and responsibilities will aloow all mparties to know and understand what is expected to make everything operate accordingly.

Like any improvement cycle you need to be able to measure these activities to create benchmarks for future improvement initiatives. You may only see small improvements in the beginning but make sure that all your progress, whether they are successes or failures are communicated to your IT stakeholders. When it comes to the failures embrace them as you will learn a great deal more from them that success in some cases.

We need to have a fundamental shift in the way we, as an IT organization, think. We are not simply helping the business achieve its business outcomes. The business goals and the IT goals should be one and the same so start thinking on that level as opposed to an “IT and them” level. Governance is a fundamental step in the right direction to achieve this.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

Tuesday, 22 April 2014

Looking at ITSM improvements through 3D Glasses


Your teams have reached a point where they are performing and achieving the goals in which they were initially intended. However over time expectations and goals have a way of changing. The question is whether you, as an IT organization, are positioned to meet these changes. You have to ask yourselves “do we continue to meet requirements?” “Are we positioned to make improvements to ensure we can continue to align with business needs?”

We all know that are business is looking to IT to produce a consistent service in a way that reduces costs whenever possible. So even in times where we haven’t really changed, we are still looking to make improvements.

Does your IT organization think in terms of CSI (Continual Service Improvements), the key word here is continual. We may not need to make huge changes year over year but we should be reviewing regularly how well we are providing service to the business. A part of this review should include the processes which are enabling IT to deliver services.  

As I have mentioned before one of the ways we (IT) as a service provider can do that is through reporting. Reporting plays a big part in understanding how well you are performing or not, however one if the limiting factors in metrics we collect is that we think of them in a process centric way. We need to get away from the one dimensional “did we have incident outages last month” to an overall service metric.

While it is important that we address outages and process focused reporting (because they are the building blocks to service reporting) we need to start thinking in terms of service as a whole, or in 3D so to speak. In essence “How do all activities around the service impact the delivery of that service?”

When we talk about making improvements generally the first step involves taking a look where we are today. There are many measurement tools or benchmarks to gauge this, regardless of which one(s) your organization decides to leverage start thinking in terms of overall service capability.

One Dimensional Thinking

When you think about improvements you might review in terms of Incident OR Change OR Requests etc. Performing reviews in this manner will allow you to improve in each of these areas separately however overall improvement will still be just outside your reach because one process may only improve if the inputs or outputs from another process are able to improve as well. Using this diagram to illustrate this we can see where we are from a capability standpoint for 3 sample processes.


You need to think of the gaps which are holding back the improvement for the service as shown by the red components in this chart.

Identifying these gaps will allow you to add the “3D thinking” and enable you to improve the processes or activities which are currently appearing as limits to the CSI initiatives. Having this big picture perspective will allow your organization to identify a CSI strategy where they may not have been able to do so before.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn




Monday, 14 April 2014

Is your IT Service Desk Still Effective?


Does your Service Desk need to evaluate its relevance to your business needs? For the most part IT organizations have set up a ‘help desk’ to address their business challenges with regards to IT. Over time IT has transitioned this to the Service Desk. The challenge is whether this has this been a transformation in name only.
 

First thing you need to realize is the way that the business uses IT is always changing. Think of about the way your business works compared to even just a few years ago. People are not tied to desks with computers all day, and when they are they have devices to augment this existence. They have become mobile and are leveraging an ever increasing wealth of external services from the cloud.

How has your Service Desk changed to meet this demand?

Coming back to your implementation of your Service Desk versus today, think about the following:

Ways you received escalations
When you started out you may have only received emails and phone calls to escalate issues. The first question is does this still support your business needs. Your business needs which are also ever changing may find these avenues inadequate. They may be looking to leverage information and modes of escalations to include messaging, social media as well as portals which have self-help knowledge articles. Your business is far better equipped to help themselves with the introduction of tools which are far more “user friendly” than they were in the past

Types of issues your customers experienced
As I mentioned above your tools have improved greatly with regards to usability. The challenge of this from the service desk perspective is that your business is able to look up thing online to help themselves in many cases. While this is great for them, the Service desk is limited in understanding the challenges that their customers face since they haven’t changes the way that they relate to their business. From their perspective the issues simply seem to be going away… unfortunately they are not

Ways you assisted your customers
In the past you may have relied on highly technical staff to triage and correct issues, mainly because they were seen as the people who fix things, so they should interact with the business. Now, as our technology has improved, the business requires a more customer friendly point of contact to facilitate the escalation. It is from there, when applicable, that the issue is routed to the appropriate technical support resources. It is in this interaction; whether it is online, on phone or something else which allows you to speak in business terms to better understand the business needs

Customer expectations
Your business is working in an economic climate which drives them to work as effectively and efficiently as possible. As such “time is money” and when they do not get the results they need they will look elsewhere for the answers they need. This is primarily where the term ‘Shadow IT’ comes into frame. But the need is there. If the Service Desk does not put itself back in a position to be a partner with the business to assist them in they will start looking elsewhere. IT needs to better understand the way in which the business works, not the other way around. Start by opening the dialogue to see where improvements can and should be made.


Follow me on Twitter @ryanrogilvie

Monday, 7 April 2014

So you want to start Problem Management....

In an effort to continue your journey to improve the delivery of services your IT organization has decided that it needs to “do” problem management. The first question I would ask is what does “doing problem management” really mean? If you were to go by many standard definitions for the term it would suggest that we are working towards determining root cause of incidents to prevent any recurrence of some particular issue.

For most service management practitioners it is clear why IT would want to implement a problem process. The benefits speak and frankly can pay for themselves including:

·         Increased productivity
·         Through fewer incident escalations to support
·         A reduction in incident volume and durations to business

·         Reduction of Costs
·         Less handling of re-work issues by support teams

·         Improved customer experience
·         Business sees less of the repeatable issues (the “oh not this again”)

These are a few of the really obvious examples, however the challenge then becomes whether we are in a position to be able to “do” (as was suggested earlier) problem management properly? There are several pieces that integrate with a successful problem process.

Leadership buy-in
Always big on my list. You really need to have the backing of leadership for this to be as effective as possible. Almost all organizations will be behind fixing issues as a result of the incident process but there seems to be challenges with regards to fixing something that isn’t broken….yet. Despite the directive to “do” the process it should be understood what is involved in making this happen from a day to day perspective. The results will speak for themselves but seeing that value can take some time. Some patience will be required.

Integrating processes
You may have very efficient incident process, in that the resolution of issues is quick and effective. The challenge for problem management will be the gaps in the integration between incident and problem. For me the challenge is always the level of information that is in the incident knowledge record. After all, these “tickets” are effectively knowledge articles which the problem process can leverage to dig into the root cause analysis. The old saying goes “garbage in – garbage out”. For example if the incident impact was “application slow” and resolution was “fixed issue” we are going to need to take a closer look at the information that is collected during the incident and ways to ensure that it is captured consistently.

Another key process to consider is Change management. After all this is the vehicle to implement the fixes to our issues in a controlled fashion. However if your change process is “fire, ready, aim” you may also have challenges that will prevent effective problem management. For example if we are performing several changes which are documented but not really reviewed or discussed across the broader audience where it might apply we may also be setting ourselves up for problems down the road where there were so many changes that we are unable to pinpoint the areas for diagnosis.

If we are seeing process gaps in either incident or change we may not need to even talk about configuration management. SeeThe Configuration Management System (CMS) – The Service Management Linchpin
These are only a few examples... remember you need to walk before you can run. Take a closer look at how your service management processes work with your organization as a whole to allow your business to operate.

Follow me on Twitter @ryanrogilvie