Whether it is a large issue or some form of a success, by the time we (IT) craft the perfect way to communicate whatever it is, the "it" has long lost its lustre. It may have to do with the way we work within IT. With teams segregated by silos do we find it harder to come together for issues or wins?
The challenge is that IT teams are consistently comparing themselves to other
teams when the delivery of IT services is the goal of the greater IT.
The story goes you are as only as good as the weakest link. In this case of the
silo IT department we need to look at the delivery of services by team to
identify where improvements can be made and then assess what an IT overall
service delivery baseline is based on services and then formulate a strategy to
You can call this IT "sit in" whatever you want under the guise of
whatever process you hold dear DevOps ITIL COBIT but the key is .unifying IT
under the delivery of services to a business to achieve their outcomes is the
only goal you should have
Band together for the issues
IT generally has no issue getting together to solve issues. They are quick to
collaborate to find a fix. By their nature they look to solving problems. So
why is it that in some organizations that once the issue is resolved the
collaborative spirit vaporizes as well? Teamwork is a skill that needs to be
practiced. Aside from critical outages where else to you get to work together.
An effort needs to be made to find ways to integrate and avoid as much rework
as possible. You could be working on similar initiatives which may work against
each other. Remember how does this all relate to business outcomes.
Celebrate the wins
For whatever reason this seems to be more of a challenge. Small wins are still
wins so celebrate them as well. You may not need to take out a full page add in
the local paper but acknowledge the win within the IT team to start. This can
build some momentum as well as practice for communicating the big wins
Again this all starts with the decision to move forward as a service provider
to your business.
Monday, 25 November 2013
Thursday, 21 November 2013
In addition to the volume of normal or standard changes your organization requires to have completed you will also have to manage the way that escalated changes are managed. While the above mentioned change types have a consistent way that they are generated there will always be exceptions. An example of this will be the definition of what makes an emergency change and what is simply urgent. In reality each have their own place. Like 2 brothers they may be related but certainly they are not the same.
Meet Ur Gency
Ur, the younger brother has a tendency to be a bit impatient. You might find him looking at his wrist, even if there is no watch, or tapping his feet. He has an ingrained need to make everything a priority 1 despite whatever is going in around him and despite any other activity priority.
While Emer, the older brother likes to take over when things go a bit outside the lines. Comfortable in chaos, he likes to get all the moving parts back in line and things working again.
Both brothers like to get things moving as quickly as possible and can work well with teams. But as in life we must ensure that we are moving forward with the right amount of due diligence to ensure that there are no additional issues. This is why we need to clearly define the difference between the two, because much like a parent you won't choose one over the other but will need to manage them just a bit differently.
As changes come in, depending on your service management system, you will need to filter through what is an emergency vs. what requires urgent attention. In some environments everything that is escalated may appear to be an emergency. If you were to verify this with the business they may even say that if this doesn't go in heads will roll.
Remind them to breathe…..
Emergencies are likely the result of a break, a critical incident of some sort. Service to our customers is currently unavailable due to some circumstance or event. Urgent changes may be the result of a potential issue. For example if we do not put this in ASAP there will be an Incident.
Understanding and documenting the differences in the changes is important. If we can report on this in some way we may be able to manage or in other cases prevent these from happening again. in the case of urgent changes we might identify that 8 of the 10 times it happens it is the result of a Vendor who has less than stellar communication skills when it comes to visiting sites. Being able to quantify that fact allows us to review that with them when appropriate.
To summarize having a clear understanding on what constitutes an Emergency vs Urgent changes will allow you to ensure that changes are being prioritized correctly and that all input and output processes are performing optimally.
Monday, 18 November 2013
When I was a kid I could hardly wait for the Christmas catalog loaded with all the newest toys to arrive at my house. I would carefully go through it front to back and all the things that I wanted would get a check mark beside it. Then reality would set in, which of these things am I really going to get? While I was generally well behaved (at least I thought so) my parents were not going to get all this stuff. Effectively this made my parents Demand Management. By comparison this meant that as the kid my role was like that of the business.
The business may also have fluctuating needs with regards to a particular service, so one might suggest that we build for the worst case scenario and then we should be good the rest of the time. to put this in perspective, if you had to transport 10 kids in once a year in a maxi-van for a hockey tournament would you buy one for everyday use? It probably wouldn’t be cost effective. You can always build more to do more, but this approach may also not be cost effective and it will not likely add value. To do that Demand will need to determine what services need to be consumed currently and in the future for varying scenarios.
How do I do this you might ask, the answer – understand your business. You need to know what they "do" as well as the “stuff” that they need to use to meet their objectives. You are also going to have to address potential scalability challenges in the future if the requirements for the services change. The challenge here is having the information available to estimate what the business needs. The risk is that if you overestimate you may satisfy the business service needs but the overall costs associated in doing so. The other challenge is keeping infrastructure costs down but not having the capacity for your business needs.
It really can be like walking a tightrope.
It really can be like walking a tightrope.
Friday, 15 November 2013
“What’s the deal with DevOps?” you might ask yourself. “I finally got my IT team on the same page when it comes to ITIL, now I have something else to walk them through?”
The purpose of DevOps for the most part is to ensure that all the IT teams are working towards the same goal, your business outcomes. Think about your IT team for a moment, specifically your development and operations teams. Culturally they are set up in a way which is counter-intuitive to deliver successful results. There may be an “Us vs. Them” mentality engrained in their cultures, they may even sit in geographically different locations.
You need to crawl before you can run. Make sure that your teams are working together in better relationships before you can do anything else. It sounds simple enough doesn’t it? The challenge is that the whole "Dev vs. Ops" mentality is fairly common. See if you recognize these common complaints.
“Operations always has so many roadblocks for deployments, we never can make the customer happy”“Development is in such a rush they deploy stuff that breaks after a week”
Any of that sound familiar?
Before teams get too far ahead of themselves thinking about tools that can perform deployments at the speed of light they should think about what DevOps proposes at its fundamental level, IT being on the same page. In effect DevOps should be part of a bigger picture, and may include several frameworks such as ITIL and COBIT to name a couple to get IT where they can be more of a strategic partner. The key is to find the balance from these frameworks and determine what works best for your organization to achieve your business outcomes.
Tuesday, 12 November 2013
Nothing gets an organization collaborating together like a minor disaster. Teams that would otherwise not work in close proximity are sharing ideas and working to get the business back up and running. Unfortunately this is not the ideal way to test out our disaster recovery plans, if one has been formalized. If one hasn’t, we say “let’s not have that happen again?
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn
Now check back with these same organizations a few months after a “disaster” has occurred. Has anything improved? In environments where disasters due to nature are less frequent you may even find that they have reverted into their “we are swamped” mentality and nothing has really improved.
However, planning for the worst case scenario also affords you the opportunity to have a dialog with the business in simplest terms regarding what services are critical and in what capacity.
The overall objective of the Service Continuity process should align with whatever the continuity plans are for the business since they should line up with the business outcomes.
You don’t have a formalized process for this? Or you have a document that is so old that it likely has very little value? It might be time to review with your team on the ins and outs of Service Continuity
Firstly you should have a fundamental understanding of what services are critical to business continuity and what the impact is of the loss of those services. It should also be understood that some disasters may be lengthy so while some business functionality may not be critical on date x or for duration y there should be some additional consideration put in if the disaster lasts for a longer period of time. As an example if your data center is in a location that was swallowed by a sinkhole it may take a significant period of time to restore.
Once we have an understanding on “what” we really need to think about “how” we can mitigate risk or restore services in the event of a disaster. Enter the disaster recovery plan. This document should be able to guide teams to restoring services in a 1-2-3 approach. Depending on the organization there will be varying levels of recovery options available, whether it is a more manual process or if your organization requires you may be bound by your business to have a disaster recovery site which mirrors your data center.
Disaster can come in all shapes and sizes; they do not have to be natural disasters. In the event that your electricity provider had an outage which impacts your data center would you be able to have services available.
Like fire drills you should also test the disaster recovery. This should include everything in the process from notifying the appropriate people that there is a disaster through to recovery and then to reverting back to regular service. These drills will point out potential holes in your process as well as any gaps technologically you might encounter
Regular review of your continuity management process will allow you to be as prepared as possible should the need arise
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn
Monday, 4 November 2013
Image this scenario; you are in a meeting room with your business. You are sitting across from each other at opposite ends of a table. The topic of service availability has come up. When you ask the customer what expectations there are they reply “Well, we need it all the time”
You then write down a number on a piece of paper which indicates the annual cost of continuous availability, fold it and slowly slide it across the table in their direction.
They look at you for a moment unfold the paper, you can see that there is a slight gasp, and their eyebrows rise, there is a brief hesitation… they reply,
“8 to 5 Monday through Friday will be just fine.”
While discussions like this are the things of satire, there is an ounce of truth in that the customers just want to have their “stuff” up all the time. The key question is how to optimize availability versus cost
How do we go about this effectively one might ask. A good place to start would be to determine what the business really needs:
· Business hours
· 24 x 7 x 365
· Can we allot for maintenance outages etc.
Once we know what the business needs from an overall service availability standpoint we will need to understand what risks are present from an unavailability standpoint. Depending on the capability of your other processes you may be in a better position to identify:
· Volume of incidents which impact the service
· Monitoring the components within the service or the service as a whole via Event Management
· The level of architectural redundancy built into the service and it there any single points of failure or weaknesses
There are several ways to identify what can contribute the unavailability of a service; whichever you choose at the end of the day should allow you to strategize on how to mitigate those identified risks. Changes may be required at an infrastructure level if we have single points of failure. There may also need to be changes in the way that IT provides support during incident outages. These along with other factors you discover during the assessment of the service will identify the costs that are associated with the service unavailability
This price tag will be used to balance on what levels of design and support are required for the availability of service we are discussing. The fact of the matter is that nothing is unbreakable, establishing the availability requirements to manage failures for your customers where they make sense is key. This in turn will translate to value to for your customer.