Thursday, 24 September 2015

Constraints Broken Down in Simple Terms

While taking the DevOps Foundation course, through ITSM Zone , we explored the concepts of constraints. What I found most interesting was the way that this could be applied to even the simplest of everyday activities, beyond the application in IT. The theory of constraints is a practice in the ‘First Way’ of DevOps. This theory outlines that every process has a potential for a bottleneck. In the journey to improve efficiency we seek to identify and reduce the impact for these bottlenecks.

In some cases we may not be able to remove the constraints but part of the discovery is to identify how best to minimize the effect of the constraints. The output of this identification recognizes that:

  • Improving constraints is an effective way to improve a process
  • Like most things a process is only as successful as its weakest link
  • Every process has at least one constraint

When we are talking about constraints we really need to consider the way that they impact the process before and after the bottleneck. Think about it, if we improve the flow before the constraint we could have the work log jam at the bottleneck and if we make improvements after the constraint then the process will be twiddling their thumbs.

In other words reduce the impact of the constraint.

A method to do this is using the ‘Five Focusing Steps’ to identify and eliminate constraints.

Step 1 – Identify the constraint – Need I say more

Step 2 – Exploit the constraint – using quick wins to make some immediate improvements

Step 3 – Subordinate the constraint – review all other process activities to ensure they support the constraints

Step 4 – Elevate the constraint – If the constraints still exists this step looks at mitigating it if it can’t be eliminated

Step 5 – Prevent inertia – like any improvement cycle, wash rinse and repeat

If we were to look at this in an everyday example I would take my local fast food drive-thru. A few months ago I was looking for a quick bite and decided that since the drive-thru looked not too busy that I would just drive through. As I sat in line for what seemed to be forever I wondered if I should just leave but since I was hungrier than ever I rode it out. As I got to the order speaker to place my order I saw that there was only one car ahead paying and another ahead if it which was waiting for its food so I thought the worst was behind me. Unfortunately I sat there for another 5 minutes until I got my order, which by then I almost forgot why I went there in the first place.

Last week I was once again in a rush and needed to grab a bite. As I passed the same restaurant I saw that here was a sign that said “try our newly improved drive-thru” being a sucker for punishment I decided to try it out. As I pulled in, the queue looked significantly longer than before. I started to wonder if this was going to be a mistake. However the order speaker was positioned at the beginning of the drive-thru entry so I ordered as soon as I went in. Hardly taking my foot off the brake I arrived at the payment window where I asked the manager who was there about the change. He said that before the bottleneck was that the ordering and payment activities were too close together and because of this it slowed down the start of making the food. Spacing the process out in the drive-thru gave the restaurant the opportunity to complete the orders consistently.

In other words they identified their constraint and made an adjustment for it to improve service. This distance adjustment made a huge difference in the way that service was delivered without impacting the internal restaurant operations.

Over the next few weeks I will post a new tidbit from the training and how it relates to what I have experienced. Feel free to send me questions, comments or any other feedback

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

Monday, 21 September 2015

Implementing Problem Management

So you have decided to implement Problem Management….

The key question that your leadership is going to ask is “How much will this cost me?” The question that should be asked, or rather how this should be perceived is “how much money can we save or even re-appropriate to other activities?”

This discussion doesn’t come without some research. You really need to be able to determine the return on investment for Problem Management. Depending on the maturity of your organization you may have an easier time determining accurate numbers to provide your leadership team.

The first step in marketing this is for everyone to understand what Problem Management is all about. There may be many perceptions on what it is for but this is the perfect opportunity to showcase what it is meant to accomplish. you will also want to highlight some of the key savings which include:

  • Avoiding repeating incidents
  • A reduction in Incident durations through handling
  • Increased first call resolution
  • Reducing business outages
  • Customer satisfaction (while this is not a direct cost, you can’t really put a price on a happy customer)

Now that you know which key stats to start with you need to figure out the cost savings for each. This is where it can get a bit tricky. Depending again on your organizations maturity you may (or may not) have the ability to pull metrics to calculate the dollars and cents.

You will need to know, even if roughly, the labour costs for the support team(s) so you can translate this to a salary/minute. You will also need to know what the cost of the service outages are. this may involve discussions with business units to determine what the service uptime is worth.

Once you have these numbers you should be able to roughly calculate the savings for each of the items above based on what the estimated percentage of Problems generated would be.

Once you have the amount of savings it will be easier to determine (and justify) whether you require a Problem Management person, team, or function.


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

 







Wednesday, 16 September 2015

Do You Understand Your Business?

It is a simple question, however if you answer yes and were asked follow on questions you may be in a position where you made assumptions on what you ‘think’ the business is all about rather than on concrete information.

A good example of this is when someone in the business says that functionality in a particular application is not working as it should. If you truly understand the business you should be in a position to validate if this particular issue is impactful or not. From a consumer perspective many things are tested long before they are unveiled to the consumer base to ensure that something will be liked (and purchased) by the masses rather than disregarded.

The trouble is that when we don’t fully understand our business we enter into a seemingly never ending loop of assumption and treat all things with equal amounts of importance. This will work for a while until we spend time working on one issue when we should have worked on another which ends up impacting the business.

How do we remedy this?

Take yourself out of the equation
We often get caught up on ‘loudest voice’ activities. If this term is new to you, I am referring to the work that gets done by who might escalate something the most rather than its impact on achieving business outcomes. Taking an objective look from a step back will allow you to look at the big picture. The trick is that while you will still need to address the loudest voice you need to manage what really matters to the business and ensure those who are escalating understand the reasoning behind it

Admitting you don’t know
For some, admitting that you don’t know something is difficult but it is the first step in the journey to understanding. Look at this in terms of what knowledge is:

Validated – Information that we know to be accurate through a source of truth

Assumed – Information that we think we know or are certain we heard somewhere, but not validated

Uncertain – Information that may be different depending on the person you ask

Unknown – No one is sure of the answer

Separating these items will allow you to get a good sense of the knowledge about your business. This will position you to see what information you don’t have and also what is assumed. The later will like may be assumed by others so sharing what you learn about your business is an important part of the understanding process.

The key is that when you look at the information you have to not get discouraged on all the data that cannot be validated. It might be a daunting task however this should be looked at in terms of a marathon rather than a race. This is simply an opportunity to learn about your business and improve relationships with people who work there.


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

Wednesday, 9 September 2015

Is Your IT Team the Appendix for the Business?

In some way or another we have all seen this before on some level, business units outside IT making technology decisions or purchases without IT knowing about it.

The question you need to ask – is IT the organizational version of the human appendix?

The appendix is not a vital organ and medical researchers still debate its exact function in our bodies. One hypothesis is that it had a larger function in a time long ago, starting to see any similarities?

More than ever the business units are finding that they are positioning themselves to not only spend technology dollars but make technology related decisions. Why does this happen? Well, many of the leaders of these teams believe that they are more informed in this digital age to make decisions where they do not ‘need’ IT. When you ask these teams why, they will say that it is just easier to do it themselves.

It’s not all doom and gloom for IT we just need to be scalable to new ways of working with our business. Among the roles that are surfacing is that of a service broker. This role consults with business partners to not only understand their needs but also to facilitate the sourcing of technology from a provider. This doesn’t necessarily mean outsourcing; it could be something that we as an IT organization already provide. In some ways IT may already be managing this function today without formally calling it this.

This forward thinking view is great and everything but the most common response from a long time IT person will tell you that “you still need to keep the lights on with legacy systems”. This is where those less likely to adapt will outline that IT’s existence is not over yet. The trick here is that despite this mentality we need to think about your business being able to deliver on its objectives. However, if legacy applications or infrastructure become the bottleneck for the business, than it will ultimately be the topic of discussion on “why do we need IT”?

Here’s the good news, we know what we need to do to survive – evolve. As IT starts to take a renewed look at how it works with the business it will ultimately build relationships which will improve the delivery of services. An IT team which looks at solutions from this business objective perspective will be making decisions and suggestions which will line up with what the business wants in the first place, not what IT assumes that they might need.

Overall you need to look at how you are delivering services. Understanding the business is the first step. From there whether you need to focus on the service broker function, or simply have a more people focused approach a strategy to create this value has to be outlined.  


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