[null, {"document_url": "http://servicemanagementjourney.blogspot.ca/2015/06/", "unformatted_src": "http://2.bp.blogspot.com/-XaoexLGNqHg/VZHAGpvvQmI/AAAAAAAABCg/LWzAzKydEEs/s200/knowl.png", "src": "http://2.bp.blogspot.com/-XaoexLGNqHg/VZHAGpvvQmI/AAAAAAAABCg/LWzAzKydEEs/s200/knowl.png", "formatted_filename": "knowl", "rendered_width": 172, "rendered_height": 200}, null, null, null, null, {"document_url": "http://servicemanagementjourney.blogspot.ca/2015/06/", "unformatted_src": "http://4.bp.blogspot.com/-o8d01S7F_wo/VYrpA_htt2I/AAAAAAAABB0/jifda7s38ro/s200/ripple.png", "src": "http://4.bp.blogspot.com/-o8d01S7F_wo/VYrpA_htt2I/AAAAAAAABB0/jifda7s38ro/s200/ripple.png", "formatted_filename": "ripple", "rendered_width": 200, "rendered_height": 155}, null, null, {"document_url": "http://servicemanagementjourney.blogspot.ca/2015/06/", "unformatted_src": "http://2.bp.blogspot.com/-Ze0ESY-xwhQ/VYhWM_GpdLI/AAAAAAAABBg/pEWOhScNpEA/s200/hero.png", "src": "http://2.bp.blogspot.com/-Ze0ESY-xwhQ/VYhWM_GpdLI/AAAAAAAABBg/pEWOhScNpEA/s200/hero.png", "formatted_filename": "hero", "rendered_width": 151, "rendered_height": 200}, null, null, null, null, null, null, {"document_url": "http://servicemanagementjourney.blogspot.ca/2015/06/", "unformatted_src": "http://3.bp.blogspot.com/-WTaCV5VlW0o/VXh45dtZp3I/AAAAAAAABAk/OKPIoxW3dNc/s200/sink%2Bpic.png", "src": "http://3.bp.blogspot.com/-WTaCV5VlW0o/VXh45dtZp3I/AAAAAAAABAk/OKPIoxW3dNc/s200/sink%2Bpic.png", "formatted_filename": "sink Bpic", "rendered_width": 200, "rendered_height": 143}, null, null, {"document_url": "http://servicemanagementjourney.blogspot.ca/2015/06/", "unformatted_src": "http://4.bp.blogspot.com/-kFOiZ5PM2m0/VXGiQH2fyYI/AAAAAAAABAI/1xF19Ulfry4/s200/sunpic.png", "src": "http://4.bp.blogspot.com/-kFOiZ5PM2m0/VXGiQH2fyYI/AAAAAAAABAI/1xF19Ulfry4/s200/sunpic.png", "formatted_filename": "sunpic", "rendered_width": 200, "rendered_height": 69}, null, null, {"document_url": "http://servicemanagementjourney.blogspot.ca/2015/06/", "unformatted_src": "http://1.bp.blogspot.com/-et28Rsr5MmI/VW9FWtg6CiI/AAAAAAAAA_0/V6Q9fbqFkaI/s200/seuss.png", "src": "http://1.bp.blogspot.com/-et28Rsr5MmI/VW9FWtg6CiI/AAAAAAAAA_0/V6Q9fbqFkaI/s200/seuss.png", "formatted_filename": "seuss", "rendered_width": 200, "rendered_height": 181}, null, null, {"document_url": "http://servicemanagementjourney.blogspot.ca/2015/06/", "unformatted_src": "https://3.bp.blogspot.com/-nK-mG0ppFos/VWyViJFyxqI/AAAAAAAAA_g/UHn5fskmoxU/s200/simple.png", "src": "https://3.bp.blogspot.com/-nK-mG0ppFos/VWyViJFyxqI/AAAAAAAAA_g/UHn5fskmoxU/s200/simple.png", "formatted_filename": "simple", "rendered_width": 200, "rendered_height": 146}, null, null, {"document_url": "http://servicemanagementjourney.blogspot.ca/2015/06/", "unformatted_src": "//lh4.googleusercontent.com/-e5yxdTIya8k/AAAAAAAAAAI/AAAAAAAAAyw/pxsijdBxYcs/s80-c/photo.jpg", "src": "http://lh4.googleusercontent.com/-e5yxdTIya8k/AAAAAAAAAAI/AAAAAAAAAyw/pxsijdBxYcs/s80-c/photo.jpg", "formatted_filename": "photo", "alt_text": "My photo", "rendered_width": 80, "rendered_height": 80}, null, null, null, null, null, null, null, null, null, null, null, null]

Improving Knowledge Management when you are not a Knowledge Manager Being a part of an IT team one would expect that we have a good grasp on knowledge management. The trouble is that there needs to be method to the madness for your knowledge. Considerations for how it is to be created, curated and consumed should be taken into account.

I was reminded of this recently as I was speaking with a colleague who was asking about an article I wrote entitled “WORN – Write Once Read Never” they indicated that they own ability to capture knowledge seemed a bit ad hoc at best.
I explained that while we are all capturing knowledge on some level or another we may not be positioning ourselves to be able to put this to use in any way which outlines a measurable amount of value.

Just because you are not a knowledge manager doesn’t mean that you can’t help improve the process.
Knowledge management can benefit all areas from a service delivery perspective. The challenge is getting people to stop thinking about this as a “side of the desk” activity. As I have said in many posts before, start small. Look at what you do today and where you can inject a healthy dose of knowledge management. In the beginning this might only apply to some core processes like change or incident management, which is ok. Use the success you gain to leverage some positive marketing for the process so that you can apply it to other teams.

IT Operations or Application Managers
Imagine if your operations teams were able to look at documentation which outlines the post incident reviews for the last 3 incident outages your team was called out on for a particular component of infrastructure. Documenting after these issues is important for continual service improvements. The challenge is finding the balance for knowledge to keep it simple enough that you are in a position to easily create, curate and consume the information. In my opinion this is where most people outside service management teams start to lose some level of traction. Using the example of a post incident review the ops and apps folks might build out these elaborate processes which include an initial PIR meeting which spawn multiple page documents with additional meetings to review findings and so on. The trouble with this is that this might not be re-producible, and in time these are simply not being done.
Having a simple template with a few key questions will allow you to build on something. While your incident team may facilitate these reviews, ultimately all of IT is accountable to providing service and has a vested component in these reviews.

Start with a few key questions like:

Everyone plays a part in knowledge management activities, whether the process is formal or not. While many people might equate knowledge to the service desk from a self-service perspective or even for problem management. There are many other benefits that can be realized when we apply these principals to other teams within IT and beyond.

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

Posted by Ryan Ogilvie at 15:21 2 comments: Labels: ITIL, ITSM, Knowledge Management, Service Management


Service Management Profile: SysAid I recently had the good fortune of connecting with Sarah Lahav, CEO at SysAid to discuss their application and service management.

Tell me about the service management journey for SysAid
With its headquarters located in Tel Aviv, SysAid was founded in 2002 by Israel Lifshitz who believed that there was an opportunity to help IT change things to provide a better customer experience. Since then SysAid has expanded to 5 global offices to accommodate its customer base.

Tell me a bit about the application itself
One of the draws for SysAid, as Sarah explained, was its ability to provide a multitude of tools to support business needs while keeping things simple. Their goal is to provide an excellent user experience while taking away the complications of providing service. Being scalable, SysAid is able to provide service on premise or in the cloud with various editions which suits your particular business needs.

Is there a prime client space?
With a large global footprint, SysAid supports a diverse selection of companies large and small from various streams of business in more than 140 countries. In other words, SysAid is scalable enough to be used by all companies for their service delivery needs.

What is the differentiator for this product vs. its competitors?
SysAid believes that it’s all about people. While it may be implied that being people focussed relies on building relationships, SysAid commits to discussing with the clients what challenges they face while really listening to what the business needs. While these seem like obvious statements, it is a principal that SysAid takes to heart and leverages all the way through to their own research and development to make their own continual service improvements.

From a technical perspective, for those who are looking to make improvements and not knowing where to start, SysAid has a benchmarking capability. This allows them to share information about what metrics might look like for similar organizations and lines of business so their clients can get a better sense of metrics within their current operation.
It is in this collaborative spirit that SysAid provides services such as blogs, training, free webinars and a global community with not only its customers but potential customers as well.

What’s in the works for SysAid in the next year?
A new mobile asset management add on complete with barcode scanning functionality  was developed to facilitate asset management and track inventory right from your mobile device.

Another feature of note is the Bomgar integration which will allow remote sessions to be opened right from the incidents which are being investigated.

In addition to what SysAid is doing, you can see SysAid at the following upcoming events:

To connect with SysAid you can reach them on the following social media platforms:

Online at https://www.sysaid.com/
Twitter @sysaid

Thanks again to Sarah and SysAid for affording me the time to connect!

Do you have an ITSM application, would you like to be reviewed?

Reach out to me via Twitter  LinkedIn or by email

Posted by Ryan Ogilvie at 19:36 No comments: 


Improving Problem Management when you are not a Problem Manager The value realization that problem management brings to the table in the reduction or elimination of incidents is something that, unfortunately, is left as an afterthought in many cases. As I mentioned in previous posts, incident management is driven by the “hero” mentality, where change management is seen as a function of audit and compliance. For right or for wrong these are the realities and teams may see more of a requirement to perform the activities. On the other hand, problem does not fit into these situations and may not be practiced with the same amounts of consistency.

Just because you are not a problem manager doesn’t mean that you can’t help improve the process.

The difference here is that while problem management might be something that is not formally practiced in a ‘day to day’ role capacity, the benefits it can provide can be extracted and applied in small doses. Just as ripples spread out when a single pebble is dropped into the water, the actions of problem management can pay long term dividends.

Service Desk

When we speak of problem management, we are generally speaking of incident reduction and elimination. While the reduction of incidents has a clear benefit for the service desk, think about the benefits from performing some levels of trend analysis on requests we see as well. In some cases the root cause analysis for why we get these requests may point us in a direction to streamline how some requests are handled. An example of this may be that we receive requests for a particular application which could be eliminated if we had a knowledge record which would allow the business to address something on their end. This ability of self-service may free up resources in the service desk to perform other (in some cases more important) activities. Don’t forget though if you are looking to replace activity in this way make sure that you can report on the use of these self-service knowledge articles.

IT Operations Manager
Having your technical specialists in a position to review the top issues and understand what level of work is associated with a permanent resolution will enable us to have the appropriate discussions with business stakeholders on whether we proceed with a fix or not. With metrics like the amount of incidents, durations and level of impact, we may be better positioned to discuss with the business the costs associated in a potential fix as well as the cost of doing nothing from an incident outage perspective. We want to be partners with the business so remember IT shouldn’t be deciding this single handedly.

IT Application Manager
Much like the operations team, we want to be able to quantify the issues we are seeing from an application level so that we can evaluate how best to utilize our resources. Gathering information that pertains to the issues we are seeing may not shed light on root cause but should allow us to ask better questions to get to the bottom of things. Engaging with your business on this will go a long way to better identifying what’s really happening.

Getting all teams in IT together to discuss the top challenges that are facing will further allow you to understand the big picture in regards to service delivery. Having multiple IT stakeholders will allow you to cover off all angles of IT support. From the initial escalations at the service desk, through to the application and operational hurdles that you need to jump over.

Everyone plays a part in problem management activities, whether the process is formal or not. From understanding the volumes of incident and requests, to getting a better sense of overall challenges that your business and ultimately you face to providing exceptional service.


Posted by Ryan Ogilvie at 10:31 No comments: Labels: CSI, ITIL, ITSM, Problem Management, Service Delivery


Improving Incident Management when you are not an Incident Manager Since we have an expectation that ‘things just work’ the visibility to Incident management can take center stage and as a result may be often described as a ‘high value process’. The challenge here is the ‘value’ which is described is not well articulated and in actuality incidents are what we want to avoid rather than covet. In its simplest description, an incident is the breakdown of something working as it was designed. This characterization alone should tell me that this is the opposite of value add. The trouble is that culturally we ‘love the hero’ and incident managers can be seen as those who restore service when we need it most.

Because of this need to ensure service is restored as quickly as possible, many of the support people outside of the actual incident become very hands off in an effort not to slow things down with too many hands working to help. However I started to think about this a bit further…

Just because you are not an incident manager doesn’t mean that you can’t help improve the process.

Think about that for a moment, everyone has some part in improving how an incident can impact your business.
Here's just a sample:

Depending on your organization setup the service desk analysts may not be managing the incidents themselves however they are the IT that faces the business so what they do during the incidents is important. While they are likely capturing the escalations, this is a good time to also capture some knowledge about the service which is impacted. We may know that a capability is unavailable but does IT truly understand the business impact. Gathering further information from the business will allow us as IT to better understand the impact and improve communications. After the incident details such as these are important in a post mortem so that if we need to adjust our responses we can do so based on the impact the business is reporting.

Infrastructure monitoring is something that is done ‘by operations for operations’ in many organizations as we just haven’t tied it into service management for one reason or another. It would make sense to correlate these alerts into real time incidents, so why isn’t this being done? While doing this would allow us to identify issues before the business sees the impact, in reality many times the alerting mechanism is set up as an afterthought to the incident process. For the Ops team to stream line what this looks like they would be able to weed out the garbage alerts that they currently get and in the process better track what their infrastructure is doing.

We have all been involved in an incident that was escalated to networks because we all know that ‘this must be a networks issue. One of the many challenges for incidents as they apply to application level issues is that the symptoms could point to many things. From an application management perspective having a solid knowledge repository of issues allows the incident manager or even the service desk to ask better questions in the event of an issue. Rather than saying that the users are not able to see module x on the application they would be able to lookup previous issues to see that when an issue with module x arises you need to check the following three items to better determine a cause for the issue. Remember knowledge is power. When we review the incident at the post mortem ensure someone from IT applications team is invited, even if this wasn’t an application issue. They will get a sense of the issue and they may have some better insight to the service we provide as a hole and any potential areas which have weaknesses. Getting input from various angles is important to be able to improve.

Everyone plays a part in incident management, big or small. From dealing with escalations to event management and improving communications. Start to think about you can do, not only to improve your incident management process, but your overall delivery of services.


Posted by Ryan Ogilvie at 11:39 No comments: Labels: CSI, Incident Management, ITIL, ITSM, Service Delivery

Wednesday, 17 June 2015

Service Management Road Trip: CSI and 4P As we get ready for summer, many of us are thinking about taking vacations. In some cases the vacation will include a road trip with a full carload of people. “Getting there is half the fun”, begins to take on a whole new meaning if the passengers are not happy. You really want to ensure that each person is satisfied to make the trip more enjoyable.

As we speak in service management terms our passengers are the 4 P’s we have come to know; People, Process, Products and Partners

All these four components are in place in some capacity in your organization (car). The key is to identify how much of a role they play. As the driver you need to assess what needs to be done for each one of these to enhance the quality of the journey.

You need to understand what you want to improve overall. Look at this from the business perspective. While you are always thinking about the big picture from a service delivery perspective start to think about how you can improve on people, process, products and partners individually to make up the whole. Identifying the inputs and outputs will allow us to define who we need to engage, or in this case who or what we need in the car to fix this issue.

Just because some parties may not be vested in this improvement initiative today doesn't mean that we don't need them tomorrow. Much like a screaming toddler in the back seat who is looking for a cookie while we would like them to just be quiet we need to identify the issue (cookie) and satisfy that need. In some cases we may have that passenger that just is no longer a fit in the grand scheme of things for our improvement initiative. A particular component within the 4 P’s may need to be augmented or removed so, like a nagging uncle in the car we might just leave them at the truck stop. Ensure that we have open lines of communication and that all the improvement activities are transparent to all stakeholders. There should be no secret that we are looking to make things better. This goes for IT as well as your business.

Let’s look at an example

We have application “ABC” which needs to have major releases regularly every 6 months. The business has had some challenges with this. In their words “we don’t want this system touched” the driver for this is that they are working on a project with a client of theirs and they are worried any changes could cause this to so awry. They need “ABC” up and running all the time operating the same way until the project has been completed this fiscal year. In the beginning IT had complied however as projects tend to do the launch dates were pushed out and as such so has the ability to update “ABC”. IT is now at a point where we are several releases behind from the application perspective and some of “ABC” integrations to other applications are not working as they should. This has been attributed to the fact that the application is not updated. Now IT is starting to see incidents regularly because of that releases we have not done.

Think about how the 4P’s apply in some way:

People – will involve the people providing the service as well as the people who consume the service. In this example there was a team who were using the application which ultimately impacted clients, who, as you guessed it, are also people.

Process – make sure that our process is measurable and is managed by an appropriate level of people. This should include people (or in some cases a person) who owns, manages or carries out the process itself.

Product – we need to ensure we are positioning ourselves to deliver service based on the stability of the services (in this case application ABC) we provide.

Partners – make sure that we work with your suppliers. While we may have partners from an IT perspective, IT may also be a supplier as it applies to client facing support as in this example.

Overall taking a look at your people, process, products and partners from another perspective is just one component of continual service improvements. Doing this will allow to see if you have everything you need in your car for the long trip ahead.


Posted by Ryan Ogilvie at 08:56 No comments: Labels: Continual Service Improvement, ITIL, ITSM, People, Service Management


Service Management Vendor Profile: Boss Recently I was able to connect with Michael Curran, Director Business Development at BOSS

Tell me about the service management journey for BOSS
BOSS (Business Oriented Software Solutions, Inc.) is a global infrastructure management firm specializing in Service Desk, IT Lifecycle Management, comprehensive Asset Management, IT Best Practices and Software Solutions.
Based in Atlanta Georgia, BOSS began as a group of consultants on the 1990’s who had a client which was looking to perform an asset audit. It was here that they built out the capability in an application which started as an asset management tool and grew into the service management tool that it has become today.

BOSS Support Central is the suite which has Service Desk, Asset Management and Computer Management modules. While the majority of customers install this suite there is an ability to implement single modules based on customer needs.

The large majority of BOSS’ clients are in the United States and Canada with 50% of them in local state or government operations. Aside from this majority many of their other clients are also highly regulated companies in the health care and public sector.

One of the key differences from its competitors is the licensing model it leverages. In addition to its subscription and perpetual licensing scheme, there is also the ability to have unlimited and unrestricted licenses as it applies to both users as well as assets in the system. This functionality is particularly important to organizations who are looking at growth, not only from IT but as well as extending the service management capability to the rest of the enterprise.

What’s in the works for InvGate in the next year?
While many of the current customers have BOSS on premise, they will be looking to offer a SaaS solution in Q1 of 2016. In addition to always looking to improve on current capability they are also in the final testing phase of a OS deployment and imaging capability

To connect with BOSS you can reach them on the following social media platforms:
Online at http://www.boss-solutions.com/
Via email email@example.com
Twitter @BOSS2U

Thanks again to Michael and BOSS for affording me the time to connect!


Posted by Ryan Ogilvie at 19:23 1 comment: Labels: Boss, ITIL, ITSM, Service Management


Improving Change Management when you are not a Change Manager During a recent service management simulation activity I was reminded of the value of perspective on roles that we do not participate in on a daily basis. It was the next morning when a Manager had complained about some roadblocks she was experiencing. When I asked her what it was she said it was someone else’s concern. I always like to operate under the guise that if you are not part of the solution you are part of the problem. This led me to the statement;

Just because you are not a change manager doesn’t mean that you can’t help improve the process.

You might be saying to yourself that you already have enough going on to worry about change management.

Here's the thing, start to look at the big picture rather than limiting your view to the backyard. Place the business you support in your visual horizon.


In many cases the service desk is made aware that a change has not gone as planned long before the implementers or change manager have been made aware. Despite rigorous testing and a solid implementation plan there may have been areas that we did not think to test, or in other cases were not able to test as well as we had thought. Things happen. While the change record will need to be updated to reflect this issue we need to ensure that the ability to learn from this issue is recorded in the change. Depending on the severity of the issue we may also need to have some level of post implementation review to ensure that all vested parties can weigh in on the issues seen, corrective steps taken to correct as well as the learning items to prevent this from going forward.

I have heard countless times from IT operations people that they are ‘in the business of keeping the lights on and as such are not focused on service management. (pause for thought) Despite the term service management, we are all working to provide delivery on a…. wait for it… yes that’s right, a service. In order to do that our friends in the operations department will likely be looking at the usual testing and validation activities but they should also be thinking about how this might impact things from an applications support perspective. Remember that big picture thinking. Asking questions that about an area that may not be your technical domain can sometimes root out an issue that was never considered by those who are in that space every day. The “gee, I never thought of it in that context before…”

Much like the operation manager, these folks are generally thinking about testing and validation in a similar although slightly different way. They too may not be looking at the larger service delivery picture, but should be. While they may not be a change manager, they are also agents of changes. They too need to ensure that all the questions are asked, even if they don’t sound ‘dumb’. Everyone has a valid voice which is generated from a multitude of experiences. Remember the only question that is dumb is the one that isn’t asked.

Everyone plays a part in change management, big or small. From filling out an RFC, attending CAB, testing, communications, and training. This will take cooperation from many people, not only the change manager and implementer. So think about you can do today to help your change management process improve.


Posted by Ryan Ogilvie at 10:51 No comments: Labels: Change Management, Continual Service Improvement, ITIL, ITSM, Service Management


Service Management Vendor Profile: SunView Software Recently I was able to connect with Martin Grobisen, Product Marketing Manager of SunView Software.

Tell me about your service management journey for SunView Software
As Martin Grobisen outlined, this was a cyclical path. Based in Tampa Florida, the company began as a group of Citrix employees who were initially looking at the change management process. As a result of this investigative look ‘Change Gear Service Desk Platform’ was developed. More recently Sun View has started to take a more enterprise look at what is possible and where they could help beyond the initial scope of IT with lines of business. A great example of this is the onboarding process. Despite IT’s typical view that we need to provision computers, phones and peripherals this process has many other components such as HR (hiring) Finance (accounting) Facilities (office space). To complete this circle the company then sees the big picture and the focus comes back to change.

Sunview prides itself on how it leads the industry in change management. They find that particularly now in times when terms like agile and devops are readily used we, as organizations, need to position ourselves to facilitate that ability to govern changes and prepare to be scallable not only to business needs but to be able to meet regulatory requirements.

While the verticals that leverage SunView software are diverse, they have been particularly successful in the mid-market enterprise but since application has such a highly regarded change management component many highly regulated businesses including finance, energy and health care gravitate to this application.

One of many features of note is that the dashboards are incredibly visual. With all people in mind the ability to view data and make good sense and ultimately decisions is simplified by easy to read dashboards.

Another important feature, particularly to growing companies is the scalability of the application itself. Teams are able to leverage more process and functionality as it makes sense to their operational need.
The underlying theme is that this application is also very simple to use in both an operational capacity as well as an ability to configure leveraging the single platform model.

What’s in the works for SunView in the next year?
Looking forward to the next year SunView is working on furthering capabilities as it pertains to change and devops. More exciting changes are coming up so stayed tuned

To connect with SunView Software you can see them at Gartner I&O Summit in June, TIG in Australia in August and at Fusion15 this fall. You can also connect with them on the following social media platforms:

Online at www.sunviewsoftware.com
Twitter @SunViewSoftware

Thanks again to Martin Grobisen and SunView Software for affording me the time to connect!


Posted by Ryan Ogilvie at 06:25 1 comment: 


Basic ITIL as Dr Seuss I recently read a post from Aprill Allen posing the challenge to wax lyrical for ITIL in Seuss-speak.

Dr Seuss Challenge

Here is my attempt.

You have thoughts in your head
You have shoes on your feet
Now you must decide on what objectives to meet.

You’re all by yourself and you know what you know,
And now you’ll decide on the direction to go.

Using ITIL you figure, will help you along,
IT has heard it, like a repetitive song

For service providers in a wide range of roles
But you must be careful not to fall down the holes.

With loads of processes, the guidance is good
Yoda might say ‘Align business objectives you should’.

To improve service delivery is initially desired,
No magic or any hocus pocus is required.

Remember that tools wont always fix what you need
Governance and people are important indeed.

After all of the books and white papers you find
Reach out to your community to get out of a bind.

Work with your business and soon you will see
That a better positioned IT group you'll be.

Based on Dr. Suess “Oh the Places You’ll Go


Posted by Ryan Ogilvie at 11:24 No comments: 


Continual Service Improvement Initiatives - Why I try to ‘under-complicate’ Over the years I have been fortunate enough to learn from a whole host of really good mentors but I have found that I have also learned just as much, if not more, from watching epic fails. One of these lessons is the ability for people to understand what you have helped them to achieve.

I was working on a project at one point where the PM and I were reviewing some documentation which was a result of some training. While going through it there were some ambiguities which I had seen and decided to ask the PM about.

“Don’t worry too much about that, the business owner didn’t seem to care too much about it and frankly in the scheme of things it might have impacted the timeline slightly”. He added “worst case scenario they bring me back for another 3 to 6 month engagement to ‘fix things’” he smiled when he used his hands to make exaggerated quotation marks. What I didn’t know then was that 3 months later he was back to do exactly what he said would happen.

Interested if this was planned or not I half-jokingly asked him about it. He went on to tell me that someday I would understand that clients don’t always get what they need in the time allotted and something needs to give in an effort for them to get going. He told me “you need to over simplify it for them so that they can get the ball rolling and then come back to help them out when they need it again.”

After this discussion I started to think that not everyone does this, so I went and asked a trusted advisor of sorts and he said after some experience you understand at the beginning what manageable chunks your clients can consume and build work components around that. He said “Making things simple, even if they seem smaller, will allow them to understand how to make whatever it is work, but start to see areas for improvement on their own.” He says building this relationship has gotten him repeats on work over the other model as the clients see him (as I do) as a trusted advisor. I replied, “It sounds as though you ‘under-complicate’” and to this he gave a crooked smile.

“You mean over simplify?” He enquired

“No, I think what you are saying is that we want to meet some level of objective but remove what makes this complicated for people to understand.” I went on to explain that it may not be that simple of an objective to reach so we may be stripping out parts that make it work rather than stripping out components which are making the transition complicated.

He thought on that for a second and nodded in agreement even if the grammar was flawed.

Think about your own initiative which is currently underway for your organization. What is making it complicated for you to reach your goals, and what can be done to break down those barriers to reach them? Under-complicate things wherever you can to achieve long lasting service improvements.


Posted by Ryan Ogilvie at 10:28 No comments: Labels: Continual Service Improvement, CSI, ITIL, ITSM, Service Management
