Thursday, 19 December 2013

Lean Methodology at Santa’s Workshop

Did you ever wonder how Santa was able to accomplish the feat of delivering all the gifts in one night with little or no complaints and clearly little overhead? He MUST be following a framework of some type. It is likely that the man in the red suit is following Lean methodology

While Santa is far from Lean himself his workshop operates as a result of efficient processes which minimize waste while delivering quality products on time and at minimal cost. While the origins of Lean are said to come from Toyota Production it is possible a fundamentally similar model was designed by Santa and his devoted team of elves.

While Lean is typically associated with manufacturing, it is being applied to other fields in an effort to improve efficiencies. St Nick already leveraging Lean for manufacturing has taken it to other facets of this delivery service.

The main focus for Lean is on delivering customer value while minimizing waste. In other words, doing more for less. Santa’s workshop achieves this in part by having an endless supply of elves at a minimal expense, gingerbread and candy canes I am told. Even his sled runs on reindeer power which only has stable and feed costs.

Santa, who has an unmatched understanding of his customer base, (you better watch out… you know the song) is able to focus his attention on his processes to constantly improve service delivery.  Santa can maximize value by looking at the big picture rather than the components that drive it such as teams, technology or assets.  As we all know Santa knows what questions to ask and this sometimes is more important the having all the right answers.

The North Pole workshop follows a five-step thought process to guide them through lean thinking.

Identify Value
Ask any kid what the value is on Christmas morning and I am sure you will get the point

Map it out  
Santa and his team have been through a few of these do they have had a chance to get the process done a few times to ensure the outcomes have value 

Create flow
Since Santa only has one night he has to eliminate any component of the flow that impedes delivery of gifts and thus value

Pull
The kids get the value in the morning (provided they were good) in the gifts they receive and full stockings. In other words we don’t assume to provide gifts toll everyone only that are good – thus the pull.

Review
On Boxing Day Santa and team complete a post mortem of the night and make new process adjustments to minimize waste. As Santa puts it "It’s like wringing out the wash cloth a few times over to get it as dry as possible"


Granted there are going to be some challenges along the way….

One challenge is much like a double edged sword. You become more efficient when you discover more issues, so the process never has an end essentially. The commitment to this must be for the long haul so that there is sufficient time to make the improvements and to continue to drive out further areas of waste.

So, why did Santa implement a Lean methodology? Clearly he was looking to minimize costs. His location suggests that the real estate, while in a remote location provided the best value, the elves work for sugary treats. There is also the fact that there is no incoming cash flow. No kickbacks or endorsement deals for this outfit. If you were working for cookies and milk you might be inclined to be leaner as well.

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

Monday, 16 December 2013

Service Management Getting Back to Basics - Conclusion - Wrapping it Together




 
In Part one we talked about looking at your IT team dynamics, thinking about how they worked both individually and as one IT unit. In Parts 2,3and 4 we spoke to some examples of areas which may indicate some holes within the processes these teams are following. Or in some cases not following as well as we may think. While I only spoke to a few examples and there will likely be others we are really trying to get to the "basics" of ITSM. No matter the size of your service management team whether you exist within a SMO (Service Management Office) or you are just starting out with a few people and processes it is going to take some work to identify and fill in some of the gaps that exist.
 
 
You might not get it right the first time. That is ok as long as you can learn something from this and then use that information to improve on what you are doing. You need to start somewhere. Finding areas for improvement in the way that these processes work will enable you to identify some areas where you can improve the customer experience.
 
Being able to clearly quantify where the improvements are will allow you to be in a better position to reach out to your operation and development counterparts to continue improvement initiatives. These IT counterparts will be far more receptive if we can verbalize ways to make the customer happy and streamlining what they already do. Ultimately you will be able to connect with the business to ensure that we are hitting the service delivery mark, but we need to walk before we can run.

 
Start by determining your current state. The real question is that with the processes we execute, have we maximized the value from them yet?

Some key take always from this are:
  • Communication between ITSM components – determine where we win and where we miss the mark
  • Not only reporting on ITSM processes individually but validating these against other processes.
  • What gaps in our processes have surfaced after the review.

Like anything the goal of service improvement is great, but we need some direction to be able to reach out destination. Create a strategy to achieve you targets. Ensure that there are timing points where we can see if we are on target as well as if there are any other concerns
 
We don't always have the answers. Talk to your peers either in your local service management community, the broader global community through social media or feel free to connect with me on either Linkedin or Twitter

Thursday, 12 December 2013

Service Management Getting Back to Basics - Part 4 - Critical Incidents vs Number of Emergency Changes


When it comes to service delivery a happy business makes for a happy support team. What happens though when we see the stats in our reporting which should mean the business is happy but their experience doesn't match up to stats. 

Let's look at a scenario
A few weeks after the monthly IT statistics are published the incident manager runs across one of the application managers in the corporate office kitchen. In the process of preparing their morning coffee the application manager relates his most recent experience of unending emergency changes which involves several after hour deployments the past several months. The Incident manager nods and smiles, she puts a lid on her coffee and then heads back to her desk. While walking back she starts thinking about these weekend issues. She replays the the image in her mind of the application manager motioning his hands like a mushroom cloud. “We didn’t have that many outages last month,” she recalls. Like most service management professionals she pulls up the reporting in the ITSM tool to see what was going on and the metrics look like this:

 
Much as she thought, the volume of Priority 1 incidents was low and did not change from the previous month. She contacts the change manager to get her take on the situation. The change manager indicates that while there has been a slight increase in volume of changes over the past 6 months the percentage of emergency changes has made a much larger increase. The two of them get together and map their stats on one chart which looks like this:
 
Further discussion with the customers confirms that we have more issues going on than our metrics are indicating.

This example highlights once again the need to not only communicate within IT but really take a close look at what are metrics are trying to tell us. Separately, the Incident and Change numbers only told us half the story but combined they are able to show us that we were other issues going on. We could see that while the Incidents were related to the changes the priority was never updated, a good majority of them were left as Priority 4. The Incident manager didn’t realize this mainly because the P4 incidents are rarely reviewed since they are of a lower priority.

To remedy these inaccuracies the Incident and Change Manager will need to review their metrics and identify where the issues lie and what actions will need to be taken to ensure that the incidents are prioritized correctly. Completing these regular reviews will give IT the knowledge to appropriately strategize on service improvements.

Like the other posts in this series we might see a drastic change in the metrics when we relook at how they are generated. That’s OK. I know what you are thinking, “easy for you to say as you type away in your blog about a fictitious situation.” But trust me I have been through this. The key is identifying the issues and taking the next steps to correct the issue. we can explain the anomoly to anyone who is looking at this as an exercise in improvement and communication.

Keep in mind that the only people who are in the dark about the service being provided are IT at this point. The business already experiences the issues first hand.


Check out the conclustion - Wrapping it Together

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


 

Monday, 9 December 2013

Service Management Getting Back to Basics - Part 3 - Incidents but no Failed Changes?

Did you ever have that friend who scored 99% on the test and someone asked “what about the other percent?” By nature many of us strive to achieve perfection. It is the desire to have things "just right" that in some cases prevents us from moving forward on so many other initiatives.


Think about this example:

You are receiving reports that your IT change success rate was 99% or better for the past several months. Let’s also assume that we are in a position where our incidents are increasing steadily.


I know that the Change Management group is smiling but let's not get too excited yet. Remember we still have that thing called 'the business', that despite your change report is having issues regularly. A closer inspection of the situation indicates that the increase in volume of incidents occurs in a regular pattern. There seems to be an increase on Tuesday mornings. not by fluke one of the organizations largest deployment window occurs on, you guessed it, Monday night.

The questions you need to start asking are:
  • Are the incidents actually caused by the changes?
  • Why these changes are being marked as successful when they aren't
  • Is there a breakdown in communication between Incident and Change when the issues happen so the issues aren't recognized as related?

There are likely others we could ask but let's start with the basics here

I have always been an agent for communication. So the first thing to start with is the working relationship between the incident and change teams. Where can we improve the ability to identify when these incidents caused by changes occur? This is the start and we all know it may not be obvious in the beginning.

Does your change team know that there are issues. Working together to relate these issues will not only help to relate incidents to changes, it will help the Change team to see any process gaps they may have, but ultimately our customers get a better experience down the road. In some cases a weekly review of past changes and incidents can pull up those changes which may not be obvious or have been completed in the past week or so. 

Prepare to see a drastic change in the "successful change" metric. While it may look bleak to some it is a more accurate representation of what the business experience is really like. This will allow you to strategize a way to make improvements once you see what you are really working with. Commit to reviewing this at a regular intervals to ensure you stay on target. 



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

 

Thursday, 5 December 2013

Service Management Getting Back to Basics - Part 2 - Whats Driving your Incidents

For whatever reason when the topic of metrics comes up on monthly basis, some IT Teams get “nervous” about what they might see as a result. 

Why, you might ask?

The reasons could be as varied as the aplications we support. For some it may be that they are concerned that they aren't doing as well as their IT counterparts, for others it might be that our incident durations are not going down. whatever teh reason may be the fact remains you business already knows how well you are doing. Hopefully your organization is in a position to take these metrics improve on the delivery of service.

For me, I have always believed that there is no “bad” numbers as long as we are able to use them to make an improvement in some way. Reporting should open up our options for what needs to be improved.  
Take, for example, the increased numbers of incidents or requests with no understanding on what is driving this increase. As you look closely into the potential driver know this, there is always something driving them. We might not be able to see it and it may not always be something critical. If you were to ask the teams which are impacted by the influx they may have some theories, and while in many cases their gut response may be accurate, we need to quantify the drivers for this to be able to tackle things appropriately.
Take the story of the frog in the pot of water. If you were to drop a frog in a pot of boiling water it will jump right out. However if you put it in warm water and slowly turn up the heat it will sit in there, possibly until it boils. This may apply to the way that you record and ultimately report on your incidents. You may only have a few of these now but when you look back after repeated business escalations you are shocked as how you didn’t put this all together while it was happening. This is where Problem Management pays in dividends.
The key is that with any improvement initiative is to have some quantifiable information to go back to. It really wont matter if you have a  formalized problem investigation or not if you cant prove out what you are looking at. this is why we say that to make any real improvements you cant do it only in one process. in this case we need to manage our reporting and document it somewhere, perhaps in a knowledge base.

this discussion started out talking about the reduction of incidents and now it sounds like we need to improve in many areas just to make some improvements. it sounds daunting but we need to take a step back and identify what we want to do and keep it simple and iterative. We need to start somewhere and that somewhere is today. We might stumble a bit, but you have to walk before you can use the “Turbo Boost”.

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

 




Tuesday, 3 December 2013

Service Management Getting Back to Basics - Part 1 - Start at the Beginning


There are many ways in which you can develop your Service Management process. The best place to begin is to look at current state and perform a gap analysis of where you want to be. This will provide a roadmap for your Service Management journey.
 



 
Think in terms of your IT teams.
 
If you were to poll a room of IT Operations people whether they think that their Service Management processes were mature, effective and providing value you might find two basic types of replies:
 
  1. From people who had been with the same organization for a number of years – they might suggest something along the lines of “things work pretty good, a few years back they were pretty messy.”
  2. From people who had only been with the organization for a shorter time frame– “compared to my last job they seem to be about the same.” They might also indicate that the ITSM tools that they have been exposed to have improved or worsened.

The big challenge is that they did not mention the level of value.
Value you say? It is entirely possible that IT Operations are not even aware what would equate to business value. The prime reason for this is that we do not rate IT success in terms of “how we deliver on business outcomes”. The way that Operations are evaluating service management is from an internal IT vantage point. In short, the processes seem to be working as good as we think they should be working.
 
If you were to ask a room full of Development people you might find there replies might be similar, even if slightly different:
  1. Ask a room of predominantly agile developers and they might tell you that the processes don't allow for the quick deployment of releases that they say would add value to the business
  2. If you asked some fans of waterfall deployment they might suggest a similar sediment as their agile kin although their complaint is that while the processes can handle the timeframe of work there may be higher levels of bureaucracy to cover off the larger releases due to higher associated risks.

While there was mention of value it really only spoke in terms of what we can fix today. It doesn't really speak to any long term value, for example if there are any issues with either agile or waterfall deployment styles.
For both Operations and Development we need to look at our core Service Management competencies and where that fits against deliverables.
An easy way to identify gaps is through the current reporting. What does our reporting tell us (or not tell us) about our ability to deliver service. Some obvious items that tend to surface might be:
  • No failed changes last month. How many did we do? However we still see incidents.
  • Low number of critical incidents versus a high number of emergency changes.
  • Steadily increasing number of incidents or requests with no known driver behind them.

I chose these particular examples simply because most organizations have implemented these processes. In the upcoming parts we will take a closer look at some of these and some remedies for them.


 
 
 

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