Week after week the Change Manager in your organization hears all the excuses for why details may be lacking in your change records. Here is a lighthearted look at a few of my favorites, why we continue to see them and the remedies for what ails them
1. What Not to Hear at CAB
Presented by
Ryan Ogilvie
2. Intro
The (CAB) Change Advisory Board is a group of people that
reviews, prioritizes, schedules, authorizes upcoming changes
3. Intro
The output of these discussed changes will directly impact your
customers, and their ability to achieve their business outcomes
4. Intro
The discussion in CAB is
around assessment,
scheduling, priority
Oh Yeah….
“What could possibly go
wrong”
Here's some common excuses
and corrections
6. This is a quick 30 second change
Remember how this ended up...
7. This is a quick 30 second change
Despite a quick change what are the implications of “quick”, and how
much work could be created (prevented) as a result.
18. Words you really don't want to hear
Shouldn't
Doesn’t sound very certain
Question to ask is why won’t it?
How can we ensure that this “wont” happen
19. Words you really don't want to hear
Probably
Sounds like you are running the odds
rather than implementing a change
How are we mitigating any risk if any issues should
arise?
20. Words you really don't want to hear
Might
(see shouldn’t)
If the might is something that is getting
business signoff (accepted risk)
Ensure the front line staff get the rundown of how to
handle the situation
21. Words you really don't want to hear
I think
similar to probably this implies that not
all the details are verified
VERIFY THE DETAILS and get them QUANTIFIED
22. Words you really don't want to hear
N/A and TBD
Generally,
if these are in the RFC more thought is required to be
put into this change before reviewing at CAB
23. Summary
Remember
The output of these discussed changes will directly impact your
customers, and their ability to achieve their business outcomes
24. Questions and Comments
Twitter: @ryanrogilvie
Blog: Service Management Journey
Linkedin: ca.linkedin.com/pub/ryan-ogilvie/2b/183/873/
Hinweis der Redaktion
Introduction
Good morning and thank you for attending the ITSMF September Breakfast event.
My name is Ryan Ogilvie and I am currently an IT Service Delivery Advisor at Tervita in Calgary. By background has included various practitioner roles in IT service management including Service Desk, Incident, Problem, Change, Configuration and most recently with Service Delivery
The (CAB) Change Advisory Board is a group of people that review, prioritize, schedule, authorize upcoming changes
This could be made up of IT or a combination of IT and Business Stakeholders
The output of these discussed changes will directly impact your customers, and their ability to achieve their business outcomes
Not sure if the CAB at the Death Star reviewed the small “port” which inevitably led to its destruction or not.
Perhaps an epic fail when reviewing the risks and mitigations associated with them.
The positive to having many vested parties in the review allows for “what about….” questions to come up
As creative and believable as a dog eating you homework there are a list
As you may or may not know when our fearless hero here approaches the sensor plate he has already gone through some significant work, cautiously negotiating through many obstacles. Unfortunately it is here where his haste produces some unsavory results
Enter Giant Boulder….
These “quick” changes may have some serious repercussions associated to them so due care should be taken to avoid issues.
No one intends to impact customers, however, from time to time issues can happen. Do not assume that the impact is trivial or minimal. Have a plan to mitigate risks should they occur. Even discussing the Incident escalation should something unforeseen happen
Take into consideration the technology you are implementing and the level of understanding your customer has. On the left there is a start button. On the right there is the icon. While it may be obvious to you the question needs to be asked
Where's the start button
Will your customer “get” what changes have been made. Was training provided? Is there a person or place to go for questions – or will this just flood your Service desk with calls.
These considerations should be discussed – Are the right people at CAB?
Unlike the Ronco grill, changes are not “set it and forget it”.
Even simple changes require some validation that they were successful. More often than not the implementer filling in the RFC knows that there are going to verify that the “lights on the server are on”, they just don’t want to fill out the Change.
Fill it out! if something happens and we need to review we may identify a step that was not planned for originally but can be applied to future implementations or at the very least improve our knowledge base
There are dozens of theories about how the Titanic sinking could have been prevented most of the criticism focuses on the lack of safety features, but there is one obscure flaw that was intentionally designed
The center propeller didn't work in reverse. The Titanic had three steam-driven propellers, with the outer two driven by piston engines and the center screw driven by a steam turbine. Steam turbines have the advantage of generally being smaller and more efficient than their piston counterparts, but have the drawback of being one-way; that is, the steam can only flow forward and the shaft can only turn in one direction.
So when First Officer Murdoch put the Titanic into full reverse in order to avoid the iceberg, the outer two screws started turning the other way, while the center one just stopped. It sort of makes sense; if you're trying to go backward, you don't want one of your propellers still pushing you forward.
However, the center screw was directly in front of the rudder, and shutting it down meant less water was washing over the rudder, which crippled the ship's handling.
Had the center prop been designed in such a way that it kept turning in the event of a reversal (or if they hadn't reversed at all), it's pretty likely the ship would have missed the iceberg completely, saving the lives of 1,514 people
In the 1950s, companies were making the first venture into jetliners, and leading the pack was the de Havilland Comet. It was a state-of-the-art jet with many never-before-seen features, such as a pressurized cabin that allowed it to fly higher and faster than other aircraft.
Unfortunately, in 1954, two Comets disintegrated midflight for no apparent reason, killing 56 people total.
Simple Flaw: It had square windows.
This is one of those things that is easy to miss (the designers missed it, for instance) but easy to understand once it's explained.A square window is made up of four 90-degree notches cut out of your wall, creating four weak points effectively. if you have brick or stucco on your house, go outside and look. You'll find cracks there, protruding right from one of those sharp cornersIn engineering, that sharp corner is called a "stress concentration," a spot where the shape of the object makes it more likely to break under stress.Well, have you ever noticed how on every plane you've ever been on, the windows you look out of have rounded corners? Those curves are pretty much the only thing keeping the plane from tearing itself apart in midair It distributes the stress to all of the various points along the rounded curve, rather than on that one sharp corner, which otherwise would (as they found out) tend to pull apart and form a crack over time.Small – Yet Critical change
This story starts out in Boston at a hotspot called the Cocoanut Grove. It was the most-happening nightclub in town in the 1940’s, and anybody who was anybody went there.
Until 1942, when a fire killed 492 people.
But the thing is, most of those people died not due to fire, but due to door hinges.
Namely, that the exit doors all swung inward.
The main entrance was a revolving door that quickly became jammed with people trying to get out, so they flocked to other entrances and were pressed against the doors so hard that they couldn't open. The fire department estimated that if the doors had swung out, over 300 people could have survived.
Unfortunately, this was not the first time (nor the last) that having inward-opening doors killed people
It is in the arrogance that errors tend to occur. The “I could do this with my eyes closed” mentality generally allows for more issues to bubble to the surface
Even if your success rate is 99% that is still 10000 failures in a million
Take a good look at this picture….
Development Environments “may” differ from Production. In many cases they do – so its important to quantify that with your test plan and identify what risks may be associated.
Not every production environment is going to have the resources duplicated in non prod environments. It just isnt cost effective among other things. So… what you can and can’t test from one environment to another should be outlined from the get go. Load for example. All the non testable items should be identified (for risk assessment) and should have a mitigation plan for them.
Managing the risks that may present themselves during your implementation should be in the back-out plan at the very least. We may not be able to plan or test every eventuality but when we say “shouldn’t” we should ask why it won’t
Even the word Probably can’t be said with any real authority. The wording around this should be “the only potential roadblock in this implementation will be x.” “ it can be managed through y”.
If there is a potential risk for your deployment rather than saying “might happen”, change the verbiage to if this issue arises the business has been made aware and signed off on the associated risk.
Or
If this potential risk presents itself the Service Desk has been made aware and will instruct customers to perform action “x”
When you say I think what you really should be saying is that I know. Verify what you know and quantify the details. You may find out that there is something that you don’t know about. Find the answer and manage it appropriately
These words alone do not speak volumes.
If the Communication plan does not apply (N/A) – why not? – Specify
If there is a component in the Testing that is “TBD” – when will it be Determined – what’s holding it back
The output of these discussed changes will directly impact your customers and their ability to achieve their business outcomes
In an effort to align with your business we need to ensure that the components that make the machine run are moving as smoothly as possible
There's nothing wrong with finding issues. Learn from them, share them and ultimately improve from them
During this session please feel free to comment or ask questions at #ShareIT13
Please feel free to connect with me on Twitter @ryanrogilvie if you have any questions after the presentation
The presentation will be made available to attendees by ITSMF Southern Alberta Chapter