While at the Pink Elephant Conference back in February, I successfully completed an ITIL intermediate class/exam and the really cool part of this is, that I’ve been able to use the knowledge gained in the course to change my company’s adoption plan and help streamline our strategy.
I was discussing this sequence of events and outcomes with colleagues. Our conversation kept circling back to the things we have to do in ITSM to help drive adoption and how many of those things that are not covered in ITIL courses. I have jotted them down here to help you in your planning, as these items can be the “sticking” points that disrupt and delay ITSM activities.
In any ITSM plan you need to have a sales strategy and sales plan. You are bringing concepts and ideas that may be seen as “threats” to the way your colleagues currently conduct business. You will need to be able to convey your message to senior/executive management, line staff, mid-level management, and customers.
You will not find much in the ITIL books that explain how to sell a new idea/change to your business. You will need to master this skill on your own and you will need to spend time outside of work perfecting it.
One other point to mention is that people sometimes swap the terms “sales” and “marketing” in similar context. Personally I do not think they are the same thing. Sales plans are designed to help decision makers “buy” your ideas/concepts. Marketing plans are designed to help teams adopt decisions. Of course, there is overlap in the definitions though. I encourage you to gain insight in to how your organization views these terms and plan accordingly.
Have a “sales” plan for each ITSM item
Read books on selling or discuss with professionals who sell things for a living
You and your team will have wonderful ideas. While we know you have the organizations best interests at heart, not everyone may see your proposals as progress. You will need negotiation skills to help settle difference in opinions and reach the best possible outcome. You will need to assess attitudes, understand what knowledge is available, and draw on interpersonal skills to obtain a win-win situation.
Mastering this skill will not only benefit you in an ITSM role but may also help you be seen as a better candidate for future positions.
Take courses on formal and informal negotiation techniques
Build a relationship/mentorship with a person who negotiates for a living. Practice negotiating with this person
Of all the potential pitfalls you may encounter, building relationships can be the showstopper. This skill is necessary regardless of the work you do. You MUST learn to network and build relationships with people throughout your company/organization.
Think of it this way; a person’s decision whether to help you may depend on how you make them feel, how much they trust you, and their perception of how willing you are to work with them. Building good solid relationships with everyone who will execute your ITSM vision is critical for success.
Yes, it will be a lot of hard work. You will need to prove you put their needs before yours, be prepared to give consistently and receive occasionally, value the message and the messenger, and be willing to see the other person’s view without bias. You do not necessarily need to have deep, meaningful contact with everyone but you do need to have the ability to allow others to perceive they can be comfortable around you.
Try to meet someone new in your company every day. Once you have met everyone in your company branch out to your community
Make notes on family, hobbies, likes, etc., on your contacts. Review these notes prior to meeting with the person
Use social media to meet people from around the globe
Do not force this – build relationships at the other person’s pace
The value equation
In ITSM, we spend a great deal of time discussing the value of a service. We discuss the importance to the business of showing value in the services we offer, we discuss the pitfalls off not showing value, and we discuss the criteria and mechanics of how to show value. Do we discuss how to show the value of ITSM adoption?
The CIO has made an investment in the IT department by deciding to adopt ITSM. The CIO most likely had to get someone above his/her role to agree this was a good idea as well. Regardless of stated requirements for your role, the CIO expects you to demonstrate value. You will need to show the ROI of an improved process, the TCO of service activities, how efficiently it has provided more resource capacity, how teams are now utilizing the additional resource capacity, and how the ITSM program is fit for purpose & fit for use.
Understand how to calculate ROI and TCO and how your company interprets this information.
Be able to show the utility and warranty of your ITSM work.
Hold regularly scheduled reviews with senior leadership on ITSM value.
I learned about most of these items the hard way. Most (if not all) the things listed here are (possibly unstated) expectations of you. Remember:
Focus on building relationships. Good relationships will take you far in your journey.
While you need to be in charge of the sales plan, you do not have to be the chief seller. If others in your company are good at selling, enlist their help.
Make sure you understand what information/reports your boss and the CIO want/need regarding the value of the ITSM program
Do not get overwhelmed if you cannot quickly master these skills. These skills take time to learn and internalize. Remember this is an iterative process and little improvements on each interaction are good.
Do not forget to record your accomplishments somewhere. You’ll need them for your value calculations and discussion.
Do not forget to enjoy what you do and have fun. You can quickly succumb to the negatives in ITSM work. At the end of the day, especially the tough days, ask if you helped make your company better. If the answer is no, regroup and try again tomorrow. If the answer is yes, pat yourself on the back move onto the next goal.
This was my first time attending the Pink Elephant conference and I must say, I was very impressed. I had heard that Pink is the “must-attend” service management conference and I’m pleased to say that Pink did not disappoint. The Pink staff, the sessions, and the people all are top notch, even the food was great. To post every highlight would simply be impossible but here are the “standout” items (at least in my mind)
There were multiple keynotes across the conference, but there were two in particular that really stood out for me.
Commander Chris Hadfield – Commander Hadfield fulfilled my boyhood dream; become an astronaut. What stood out to me in his presentation was the human that he is. Simply the person that he is was what was inspiring about his session. His recollections of the moment he looked out of the windows of the International Space Station at the beautiful thin slice of world we inhabit. The recollection of struggling to understand a Russian-speaking colleague. His memory of helping lead thousands of school children in a song (he truly capitalized on the opportunity of the song lyric “I’d like to teach the world to sing, in perfect harmony…”.). There isn’t any doubt that Commander Hadfield is an incredible man.
My takeaway – Practice Failure. His stories of how he and the ISS team dealt with emergencies all lead back to the practice of situations that might. Success is an important trait for many of us, but are we successful because we practice success or because we practice failure?
Caroline Casey – There are those moments when you see some step onto a stage and you just know they are genuine. And then there is Caroline Casey. This woman’s story is incredible, moving, and tugs at your heart. Her outer beauty is truly diminished by her inner beauty.
My takeaway – A disability is in the eye of the beholder. We all have our disabilities. How are you working to make yours an ability?
Takeaways from the conference
There were many, but here is my top seven:
Over the next year, IT will be squeezed like never before. IT teams will need to make tough decisions on the services they offer and how to collaborate with other/external providers. Demonstrating value to the business will be more critical. The ability to act with agility will become a greater differentiator.
Strategy still matters. In my discussions with many of the attendees, strategy seemed to be the sticking point in adoption plans. Many of those I interacted with are looking back at their strategic development of services to ensure the business is able to see the value their IT team provides.
Discussions around buzzwords seem to be diminishing. While CMDB and BYOD were topics on the session agenda, they were not mentioned as frequently as words like leadership, management and value.
The business will be looking to IT to prove value
Culture is the next great differentiator
IT generally does not understand how to work/use governance. The business is depending on IT to fit into existing governance models OR to advise on changes. Does IT have skills in this area?
There is and will continue to be a multitude of framework/methodology options. There is not a “cookbook” for service management. Be like an “Iron Chef” – make something dazzling with your secret ingredient – IT needs to become a “melting pot” – input/ideas from areas mixed into a delightful concoction that will please the palette of the business
I had the good fortune to meet many of the people I interact with on Twitter for the first time at Pink14. There are too many to mention here and I would most likely forget someone, but please allow me to say:
It was an honour to meet you
Thanks for the time you spent discussing service management with me and for those who were out with me at all hours
The pictures aren’t getting posted anywhere!
It truly was a great gathering and I look forward to seeing everyone again soon!
“Oh, we are working on configuration management…Why? Because it’s an ITIL process”
The conversation continued with “…yeah, I don’t know why it’s not going well. We bought <well-known tool name here> which has a CMDB. We have been adding configuration items (CI) into the CMDB for the last two months. Nobody in the IT team is using the CIs for incidents or change…”
I walked away, no longer wanting to hear any more of the gory details. Unfortunately, I feel this is more the norm than the exception. Let us take a few moments to examine why.
IT is notorious for buying lots of stuff (that is a technical term) and equally notorious for not decommissioning items. Working in Higher Education, I often see departments who have plenty of funds and those departments who have to do whatever necessary to survive. This culture propagates surviving on the “scraps” thrown off by the “rich” departments when they get new items. IT often helps “repurpose” equipment to defer costs. Unfortunately, we end up with rooms full of devices, some of which may be running important business operations, with limited knowledge of what/how they are connected, the service they help provide, or why. Sometimes it may even become difficult to know who supports the device.
These actions have positioned IT to have a “hoarder” mentality. Don’t think so? We all know the team mate who has a copy of Windows 3.1 on 3½” disk who is hanging on to them because “…you just never know when the might be needed…” The spare equipment room, items sitting on inventory shelves, unappropriated devices in communications closets, servers under desks, overhead desk cabinets full of various versions of software, all adding up to “a big ol’ mess”.
With this much stuff, the task of building usable CIs becomes daunting. The sheer volume (thousands of items) becomes overwhelming and dooms the thinking of the configuration management team to “…we can’t do this…”.
It’s all about the CMDB
Ask this question “Are you doing any type of configuration management?” There is a good chance you will get a response of “Yes, we’ve got a CMDB”. This is just maddening.
I do not blame vendors for this. It is the vendor’s job to promote its products, but unfortunately, too many folks take the information provided by the vendor and translate it into “…to do configuration management we need a CMDB…”” to making your configuration management process work. Configuration management is about understanding the items that make your services work and their relationships. The CMDB should help the IT team mitigate risk during change decisions, help in trending during problem management, and allow the IT team to understand the impact of their operational decisions.
Education on Configuration Management
Where is the education? Now before all the ATO send me hate mail, I’m taking about where are the practitioners talking about configuration management? Formal training is not the issue. There seem to be very few good storytellers out there when it comes to configuration management.
In fairness, the reason there may be so few good storytellers may be due to how much context plays in configuration management. Let’s be honest, the context of my organization is different from the context of your organization. Incident management runs pretty much the same across all organizations. Simple premise of “get the issues resolved as quickly as possible” translates to everyone. The stories are transportable to each organization regardless of context. Because of this, ideas become quickly adaptable and usable.
With configuration management, we do not see the same ability to be transportable. Configuration management begins with the relationship of your services to the business. It becomes difficult to adopt an idea that does not match with your context.
Configuration management also seems to be the place most people really want a “recipe” for. “Just tell us how to do it”, the phrase uttered from many configuration management teams who realize the level of work they will need to do just to figure out where to start. Education on configuration management is most likely not a fair phrase. Configuration management does require a “deep dive” into the method and diligence to obtain desired outcomes. Make sure your team has the passion and the “intestinal fortitude” to make the tough decisions to build a configuration management process for your context.
“Ownership” of CIs
When you start discussing Configuration Management, you will undoubtedly run into folks in your organization who feel they “own” whatever CI you may be discussing. Sometimes their attitude may be perceived as “…this <device> is my responsibility…how dare you have an opinion on what I should do…” or “…I don’t report to you…you can’t tell me what to do…” They come by this honestly. For many years, IT perpetuated “silos” and one did not simply cross boarders without permission. Because of the way IT has worked in the past, many people see the items that they manage as “personal” pieces of their work and change for those items “require” a personal level of collaboration with the individual.
As we know, ITSM breaks down this paradigm and promotes a spirit of service across departments. Unfortunately, this does not always hold true when it comes to people managing devices. Depending on your organization culture, you may have teammates who do not buy in to the concept of configuration management. The configuration management team must do everything they can to break down these walls and ensure all teammates understand configuration management is not about taking away authority. Building a plan that helps IT deliver great services depends on team member participation at all levels. If your organization culture values individual performance over team achievement, you will have problems getting configuration management to stick.
Final Thoughts and Tips for Configuration Management
Configuration management is tough because:
Everyone in IT must commit to the process
It depends on organizational context
It may require big organizational change AND individual change
Understand the services your organization offers. Have discussions regarding CIs around how they relate to services.
Find people who are willing to do the deep dive into Configuration Management and who are willing to change the organization. Having a few “cynics” who are willing to challenge ideas is a good thing as long as they are working for the betterment of the business and not disrupting progress.
Repeat with me, “IT’S NOT ABOUT THE CMDB!” The CMDB should be something that helps accelerate other processes.
At some point, someone is going to take the change personally. The Configuration Management team should practice dealing with this issue. Have a script on how to respond when challenged with why the change is necessary. Remind others, it’s about us looking good.
Take the time to move a CI through its lifecycle manually. Doing so will help the Configuration Management team understand how CIs are used with other processes, the relationships CIs have with services, and if your process meets your context. Once you have perfected the flow, use the CMDB to accelerate processes.
Configuration management is not impossible but it does require commitment, compassion, and compromise. Be sure to build a team that has the passion to build a configuration process and to help IT commit to using it.
As 2013 begins to draw to a close, I thought it would be nice to finish off the year with a final article that’s an overview of what has happened at the ITSM Review over the last 12 months. That’s right, this will be our last post for 2013 because the entire team is heading off to fill their faces with mince pies and sherry. But don’t worry we’ll be back in 2014 with slightly bigger waistlines and lots of exciting plans for 2014 (insight into which you can find at the end of this article).
Ironically I like neither mince pies nor sherry.
Visits and Growth
We have had nearly 230,000 page views this year, an increase of a whopping 210% from 2012!!! A huge thank you to the circa 120,000 of you for coming to read our content.
Visits to our site increased by an astounding 58% between the end of June and end of July alone, and then continued to grow on average by 5.5% every month.
Our Twitter followers increased by 193%.
One thing that I think it’s worth pointing out here as well is that the bulk of our readers are not actually situated in the UK (which is what a lot of people presume given that this is where we are based). In 2013, 17% of our readers were from the UK, but an impressive 30% were actually from the USA. Perhaps we should open a US office?! A large proportion of visitors also came from India, Germany, Australia, Canada, The Netherlands, France and Sweden, as well as plenty of other countries too.
Owing to us attracting more and more visitors year-on-year from outside of the UK and America, we are increasingly being asked to produce region-specific content. We are therefore looking for practitioners, consultants or analysts based in Asia, South America, Africa, and Europe who would be interested in writing about their experiences of ITSM in other countries. If you are interested please get in touch.
Of those articles only number 3 was actually written and published in 2013.
I have to say congratulations specifically to Simon Morris here as well, because his KEDB article was not only the most-read article of the year, but it achieved 37% more hits than the second most popular article of the year! (And that’s not counting the hits it originally got in the year it was published).
Of the articles written and contributed in 2013, the top 3 were:
Is there a specific topic that you would like us to write about? Are there are practical pieces that you would like to see us cover to help you in your day-to-day job? Please let us know.
In 2013, we were pleased to welcome 3 new, regular content contributors to the ITSM Review. These are people who now write for us on a regular basis (roughly once a month), so you can expect to see a lot more great content from them in 2014. They are:
A great big thank-you to all of our regular and ad hoc contributors for helping supply with us with such fantastic content.
If you’re reading this and think you might be interested in contributing content (we welcome content from all, including) please get in touch.
Given that we had over 230,000 pages view this year, I thought that many of you might be interested to see what it was that people were searching for on our site. The top 20 searches of the year were as follows:
Known Error Database
Proactive Problem Management
What is Service Management
Cherwell Software Review
Gartner ITSM Magic Quadrant
ITSM Software Review
Major Incident Management Process
Free ITIL Training
KEDB in ITIL
Are there any search terms that you are surprised to see on there? Or anything that you would have expected to see that isn’t?
Our aim was not only to spread the word about The ITSM Review, but to spend time with delegates to find out what things they are struggling with and how we might be able to help them.
Next year you can expect to see us the PINK conference in Las Vegas, and we hope to announce some other new, exciting partnerships for 2015 in the New Year!
In May we launched the ITSM Review App (Search ‘ITSM’ in the Apple App Store).
Then there is the ITSM Tools Universe, which we launched at the end of November. The Tools Universe hopes to shed light on the emerging ITSM players (as well as the major competitors) and, over time, the changes in the position of the companies involved and moves in market share. Most importantly it is free to participate and unlike any Magic Quadrant or Wave, the ITSM Tools Universe is open to ALL ITSM vendors. 9 vendors are already confirmed.
If you are a Vendor and are interested in learning more the ITSM Tools Universe please contact us.
Additions to the team
As of 1st January 2013 the ITSM Review was still simply just the man you all know and love Martin Thompson (he tried desperately to get me to remove what I just said there… modest and all that jazz).
However, ITSM Review finished 2013 with an additional 3 employees:
In January 2013 Glenn Thompson (you’d be right to suspect that they might be related) joined full-time as the company’s Commercial Director. For some reason there was no official announcement (we’ll blame Martin) so for some of you this might be the first you’ve heard of it! Without Glenn we’d struggle to continue to offer all of our content to readers free of charge, so despite the fact that he’s a Chelsea fan, you’ve got to like him.
In July, for some reason Martin decided it would be a good move to hire some strange blonde lady who liked penguins (that would be me) as the Marketing and Community Manager.
Finally, in October Rebecca Beach joined as a Research Analyst. Famous for being a “gobby midget”, Rebecca will be writing most of our ITSM research and reviews in 2014. Rebecca also spends time (in conjunction with me) making fun of Martin and Glenn on a regular basis (it’s not our fault they make it so easy).
So then there was 4.
If you’re interested in any upcoming job opportunities at the ITSM Review (or ITAM Review), then please let us know. We certainly plan on increasing that number 4 in 2014.
What’s planned for 2014?
Next year we are hoping to broaden our coverage of the ITSM space even further by securing new content contributors; participating in more industry events; launching new products (such as video product reviews, webinars, and case studies); and more.
We’re also looking very seriously at the possibility of running regular ‘social meet ups’ like we recently did with the Christmas get-together.
In addition to the publication of our ITSM Tools Universe in the Spring we will also be continuing our Group Tests, and a full list of topics for the Group Test series will be published early January.
In addition to the above we also have some planned changes in the works for our website. Nothing too major (it will still look like the ITSM Review that you know and love), just some cosmetic updates to make it easier on the eye and increase your ability to easily find what you are looking for.
Watch this space and we’ll keep you updated of our plans throughout 2014!
Is there anything you would like to see us doing in 2014 that we’re not doing currently? Are there any changes that you would like to suggest to the website? Would you be interested in a tooling event or social get-togethers? Are you a Vendor who is interested in our Group Tests? We welcome your feedback, so please get in touch.
2013 is drawing to a close. Our success and growth throughout the year has made everybody here happy bunnies; but most importantly we hope that our content / site / presence this year has made YOU a bunch of happy bunnies. The whole purpose of the ITSM Review is to help ITSM practitioners, and everything we do has that end goal in mind. Even if we only gain an additional 5 readers in 2014, so long as our content aids those 5 people and makes their work lives easier then these bunnies will continue to have smiles on their faces.
So with that image of turning the entire ITSM industry into smiley rabbits, I bid you all a Merry Christmas and a Happy New Year! Thanks for reading throughout 2013; without you… the ITSM Review doesn’t exist.
For 2014 itSMF UK has decided to focus on four key topics that will drive its agenda for the next 12 months. These topics will be the basis for all of its content, events, SIGs, Regionals, and Masterclasses throughout next year.
The aim is to create a sense of coherence and continuity across all of its activities and give its members (and the wider ITSM community where possible) the support they need. Yes, these four key topics (referred to as the “ITSM Big 4”) are chosen by YOU.
In order to help select these four topics there has been:
An online poll
Numerous discussions with the itSMF UK member base
Two Twitter Chats
Two roundtables at the itSMF UK Conference in early November
I have to say it’s great to see how proactive itSMF UK has been with this initiative, adopting new channels (Twitter) and also proactively communicating with people outside of the UK for their opinions, despite the fact that the concept will be UK-based. However, having taken part in both the Twitter Chats and the roundtables at the event I couldn’t help but feel that there is a specific type of input missing – practitioner input.
I think it’s important to stress here that this isn’t itSMF UK’s fault. Within the ITSM community there are a lot of dominant voices and opinions, which is not a bad thing (I must stress), but it does sometimes mean that either other voices cannot be heard over these opinions, or it can prevent others from coming forward with their thoughts (specifically if their thoughts differ). It’s also often the case that practitioners are so knee-deep in actually doing ITSM that they often don’t have the time to provide input into these sorts of initiatives.
I had hoped that the practitioner presence may be more noticeable in the roundtables at the conference, but in reality I struggled to spot more than one practitioner amongst the large group of consultants in the room. This is when I started to realise, that if not careful, the ITSM Big 4 will be chosen based on perceptions of vendors and consultants alone, with very little input from the ITSM Big 4’s actual target audience – the practitioners… the people actually doing all of the stuff that we are talking about.
Unfortunately I don’t have the answer as to how itSMF UK (or any of us for that matter) can better succeed in reaching the ITSM practitioners of the world, but I do know of four practitioners dotted around the globe that contribute content here at ITSM Review on a regular basis. So I thought, why not ask them?
Below, ITSM Review regular contributors and practitioners provide their views on the ITSM Big 4.
First of all I want to say that I think that the ITSM Big 4 concept is a very cool idea. I like that itSMF UK is working to focus on 4 major topics. Secondly, rather than simply giving you my top 4, I wanted to start by commenting on some of the themes/ideas that I have seen being raised in the Twitter Chats.
IT as a business partner – Yes, this is key: IT caring about the business objectives/Business caring about the technology provided.
The future of service management – I think the future of “ITIL” is a little too narrow in focus – stop making the discussions about the theory of a framework.
Is ITSM maturity a “regional” issue? – As I sit across the pond, it is so easy to me to see where the US is a “late” adopter of this movement – when I communicate with one of my ITSM brethren in the UK, Europe, or Oceania how they think about ITSM is well ahead of where I see my fellow countrymen. If that is truly the case, how do we start building better communities?
Building skills over certification – to me, working as a practitioner is like being on a daily version of “Iron Chef” – I don’t know what the “special ingredient” for the day will be but I know I have a short amount of time to impress the business with innovate processes to help the business satisfy its appetite (outcomes). It doesn’t matter how many certificates I hold, it’s how well I apply the lessons I have learned.
Basics – Should anyone ever talk advanced ITSM concepts if they can’t show they are providing best in class IT basics? I think there is a lot of “improvement” to be made around Incident, Problem, and Change because we have still not mastered those disciplines (assuming most people would consider Incident, Problem, and Change as basic operational processes for IT).
ITIL and AXELOS – As a practitioner, I do not care who owns ITIL, what type of profit they are looking for, or the issues regarding improvement of the model. It’s like walking onto a car lot and being told “…oh, we know you want to take a test drive, but let me redirect your focus on to how we mined the ore to make the engine block” – give me something I can use to make my business more efficient and effective.
So, to sum up… ITIL shouldn’t be part of the big 4, concentration on basics is essential, I don’t care as much about the future as I care about the NOW, and yes, demonstrating IT value to the business and opening two-way communication is critical to success.
The questions I ask myself on a day-to-day basis are:
How do we improve operations in context of what the business needs?
How do we improve beginner, intermediate, and advance ITSM practitioner skill sets? What does the pathway from practitioner to consultant/industry expert look like? What do I need to do to be taken seriously in my ITSM community/context?
As far as I am concerned frameworks and Tools really don’t matter – it’s how we build knowledge on best class operations and allow the practitioner to select/use the framework/tools that best suit their context that is key.
Looking at the public conversations around the itSMF UK ITSM Big 4 initiative it certainly feels as though the channels are flooded with pundits wanting to share their ideas. So I guess I should add my little practitioners view to the mix.
I see two main areas where people like me need help;
Help us with management
As a practitioner, it can often feel all uphill when you approach the thought-leaders of the business. You are constantly told that you need to work outside-in and top-down. But sometimes it’s very difficult to do that without management support or understanding.
I would like bodies like itSMF UK to focus on how to spread the word further than to those of us who already “get it” but can’t do much about it. I’m stuck with my management and even if I did have some influence it doesn’t take me far enough when wanting to change things. I could have the most brilliant idea in the world to work outside-in and top-down, but without management on board (or to be honest, without even getting them to listen to me in the first place) I have no chance of implementing it.
I don’t know that much about the ITSM-scene in the UK and other countries, but when it comes to Sweden a lot of practitioners like myself are having problems with management that are not interested (or sometimes don’t even know what you’re talking about) when you try to speak service management with them. They’ve all heard of ITIL, but they don’t understand the whole concept of IT Service Management.
I also know that itSMF Sweden struggles to get CIO’s, CEO’s and that type of executive to its conferences and other events. And we (the practitioners and consultants) get stuck in only talking to each other about how things could be done, if only we could reach management and get them to listen to us, and more importantly understand what we’re talking about.
The other thing that I see a huge need for is more practical advice on how to succeed on an actual day-to-day basis. How we successfully use and implement processes, what tools we use, what the best methods are for specific things etc.
We’ve got a huge body of knowledge in the ITIL-books and we’ve learned a lot on the theories there. But the books, the consultants and the thought leaders all tell us that we need to take all this stuff and change it so that it suits our organization, our special needs and circumstances. But then they tell us not to change it to much! Or they tell us that if we change the wrong stuff, we’ll be screwed! Nobody actually tells us what to do on a more practical level, nobody tells us how much change is ‘too much’, or what the ‘wrong stuff’ is that we shouldn’t change.
Of course some practitioners may be lucky and may find some good consultants to help them with the practical stuff, but for most of us that isn’t an option.
Some of the ‘themes’ raised in the Twitter Chats etc. such as: the future of ITIL; innovation from IT driving and helping the business; maximizing and exploiting IT investment; anticipating the future; business alignment and integration of IT services, etc. they are all interesting topics and they all have a part to play, but they are not relevant to many practitioners right NOW. How can we possible focus on maximizing and exploiting IT investment, when we don’t even know how to successfully do the basic practical stuff and we can’t get management to pay attention to us?
I would really like to see itSMF UK (and all the other itSMF bodies for that matter) keep in mind that there is a great body of practitioners that still struggle with management support and how to make incident/problem/change work.
In my view ITSM has gone on this self indulged journey, where it was so focused on itself it became inflated to the point of exploding. In my opinion, it becoming inflated had some benefits, but created many misconceptions and failures along the way as well. I recall watching an online presentation by Rob England a while ago where he was talking about ITSM and DevOps and how they might be at that point where they are a bit inflated…
I think for the first time I see something new in ITSM circles – we’ve realised we were a bit too impressed with our badges and libraries with pictures of shells on them, and that we lost a bit of touch with reality. That is why getting back to the basics resonates with me. One tweet from Barclay that I think is very true:
@itSMFUK most of the Q's I get from practitioners are about fairly basic practical advice – where to start< how 2 make #itsm work #itSMBig4
We all make the assumption that people must be ‘getting’ the basicsby now – but in reality this is exactly what most people struggle with – they don’t ‘get’ the basics, and they cannot envision how to implement or use the basics, or how it applies to the chaotic world they travel in every day.
By that I still believe there is a lot of value in the ‘new’ – e.g. anti-fragile, DevOps, Agile, Gamification etc – but only because it gives you a perspective of the past and where we have come from, and it gets people excited about the future – to see that we are not becoming stagnant.
We need to see how ITSM fits into the real world, with its challenges etc, not the perfect world or utopia where you have highly competent and skilled people and resources, clearly defined process and wonderfully automated tools. We need to see ITSM in bare feet not high heels. I also believe more needs to be said about Cultural change and effective ways to achieve that in imperfect organisations – which comes back to the wise saying by Rob:
“Good people will deal with bad process – in fact they’ll fix it. And good process can work around bad technology (and identify requirements). But new technology won’t fix process. And improved process won’t change people.”
AXELOS has to be a subject up there on my list – as of January 1st they will be officially launching and the best practice management landscape will change for everyone. I feel that they’ve done a good job of interacting with the ITSM community but I’m still not convinced if the same can be said for the project management community. PM’s I’ve spoken to don’t know anything about AXELOS and companies that have approached me regarding Prince2 training haven’t had AXELOS cross their radar…which I find worrying considering the significant role that they now have with the best practice management portfolio. Because of the changes that will happen long-term, we (the practitioners) need to be aware that change is inevitable and more importantly what the impact of said changes that will be in the long-term.
Demonstrating value of IT to the business – how do you really demonstrate value to the business? It can be down to how IT is perceived by the business and not necessarily in a monetary term, for example, beg the question would you recommend your service desk to your work colleagues? If so, why – if not, why not…and work from there.
The service catalogue in my opinion is the jewel in the crown of ITSM…I get told it shows how IT can demonstrate the value to the business, and that it’s a key part of ITIL and SIAM. If this is the case why is it that so few IT departments actually do it? I can only imagine that the Service Catalogue is being pitched at the wrong level. Sure, practitioners get it and I’m sure IT managers understand the advantages of it BUT if the business was aware of the tangible benefits perhaps it would demand it.
With this in mind I’ve been lucky to attend several conferences this year and at each one I’ve been in sessions where the audience are asked who has a service catalogue and every time I would say less than 5% put their hands up…this number ideally needs to grow for the service catalogue to stay relevant, the question is how.
Practical advice and skills – Cobit5 is all about the governance and ITIL is all about the doing in service management, more practical advice that’s less vendor specific would be helpful. We don’t have the time to read volumes of books, but case studies would give practitioners useful snippets of topical guidance. These case studies could perhaps be categorised by different sectors.
Soft Skills – when I was at the itSMF UK conference this year a common thread was “engage with people in the business”, talk with them and more importantly listen. Getting back to the good old basics of “the fluffy stuff” as it’s referred to is important but appears to be a skill largely forgotten.
So what will the ITSM Big 4 be?
itSMF UK will announce the chosen four focus areas on December 11th at 8pm GMT via it’s third Twitter Chat, so there is still time to have your say (and remember you don’t have to live in the UK to make your voice heard). You can get involved on Twitter using #ITSMBIG4, you can use the comment box on this article, if you are an itSMF UK member you can join the discussions in the online forum, or if you would prefer to remain anonymous you are welcome to send me your thoughts directly or via our contact form to share with itSMF UK on your behalf.
So to all you practitioners out there, please do step forward and share your thoughts. This initiative is aimed at supporting you in the areas where you need support, it shouldn’t be based solely on what consultants and vendors think you need.
And remember, as always, regardless of the ITSM Big 4 initiative please do let us know what it is that you need help with. All ITSM Review content is aimed at helping you on a day-to-day basis, so please do tell us what you need and want from us and we will always do our upmost to provide it. That’s what we’re here for!
As a final note, thank-you to Earl, Tobias, Francois and Greg for taking the time out to provide their input.
Lather, Rinse and Repeat (LRR). Straightforward instructions. Hard to mess up. Or is it? If you follow these instructions, when do you stop?
The phrase has come to be indicative of two things; a) a way of pointing out instructions, if taken literally, would never end (or would continue at least until you run out of shampoo), or b) “a sarcastic metaphor for following instructions without critical thought”.
The author Benjamin Cheever wrote about these words in his book “The Plagiarist” (SPOILER ALERT – in the book, a marketing executive becomes an overnight legend by simply adding the word REPEAT to the instructions. Of course, sales of shampoo skyrocket).
The point is this, this is a process and the process has not changed or been updated in a long while.
Are you sure it’s a process?
Yep. Here is how I know.
The base statement of “Wash Hair” does not cover the steps needed to complete the activity. LRR fulfills the steps. LRR is not a procedure, as the activities do not provide instruction on how to complete the steps.
So what is the problem?
On the positive side, the process is simple and easy to understand. However, the biggest issue with it is “Do I really need to repeat”? “What happens if I don’t”?
So what’s the point with regards to ITSM?
Let’s first look at the positive to LRR, it’s a simple process to follow, it isn’t complicated. Do we work to make ITSM process as simple as possible? My experience shows that we, as IT people, tend to grab Visio, graph every possibility without question, and produce a monster swim lane diagram. Do we add complexity because the customer requires it or because we have cool systems that do cool things? Or can we learn from the simplicity of LRR?
Another plus point to LRR, the process is universal and aimed at the end-user. Regardless of why or where you have bought your shampoo, you know what to do with it when you are ready to use it. You can execute the LRR process with little training and/or thought. With regards to ITSM do we design processes to help our customers or to help IT? Can customers execute IT processes with little training and/or thought? It is always interesting to ask why we (IT) do something. It is shocking to see how many times the reason focuses on making things better for IT and not for customers.
Then there is the negative, is the process a) even necessary, b) actually adhered to (I can’t say that I lather my hair twice, do you?). Lauren Goldstine takes on the need for LRR in a 1999 article entitled “Lather, Rinse, Repeat: Hygiene Tip or Marketing Ploy” In her article, Ms. Goldstine indicates that Repeat is probably no longer necessary due to the advances in shampoo tech, yet most shampoo bottles you look at will have the process. In ITSM do we spend time looking at how to make a process better?
Ok but seriously, what can ITSM learn from a shampoo process?
As ITSM practitioners, do we take the time to think about the processes we ask others to adopt? Do we work to remove obfuscation? Or do we trot out big ideas/opinions regarding how IT should work? To me, LRR is a reminder to design processes that can be easily executed and deliver desired results. With that in mind, here are my tips for process design.
Tips for process design
Keep it simple – look for redundant steps. Remove points of “distraction” from the process flow. Ask frequently, “do we really need this step?” AND “what value does the customer get from it?”. If you cannot answer the value question, most likely, you do not need this step of the process. Other tests to verify your process is simple – can people easily explain and discuss the process? The more complex the process is the greater the chance that people will not internalize it and probably will not discuss it with colleagues and customers. If the team is not willing and/or capable of talking about the process, how will you get continual improvement to happen?
Make it elegant – keeping it simple should not translate into “skimp on feature”. You should design processes to meet the needs of the business and to be easy enough to execute. The context of your situation should drive how elegant your process needs to be.
Customer first – design every process with the mantra of “Customer First”. Take the time to learn who the customer is, why they need the process, and what they expect from the process. If you determine that there is a gap between expectation and delivered value, determine how to close the gap.
Borrow liberally – don’t keep “reinventing the wheel”. Look at other processes (both inside and outside of your organization) and determine if the process/steps fit the context. If so, use them! The benefit is that IT teams should not need to undergo additional training since they already know how to execute specific steps. In fact, if I am in a service owner role, I would ensure that I look at the processes of my fellow service/process owners, and when I find a process that will work for my situation, I would simply declare “I follow team x process”. Doing this would alleviate me from the ownership and management of the process and documentation, but would also mean that I must work to build/maintain a partnership with the other service/process owners.
Test – verify what you think will actually work. Get feedback from the folks who will execute the process (in fact, do this all the way through your design). Ensure the process will meet the expected business outcomes. Do not launch a process that will not meet needs or is not ready. At the same time, do not try to make the process perfect. Doing so means you will never launch simply because “it just needs a little more tweaking.”
Spend time in the design phase determine what constitutes “success” for the process and make sure you measure as you test.
Then, with all of the steps above: Plan, Build, Test. Lather, Rinse, Repeat.
It really is that simple. And yes, the idea for this article came to me in the shower.
When I started my current role of Total Quality Manager, my CIO lovingly dubbed me “Darth Vader”.
In his view, Darth is the ultimate project manager and the CIO wanted the same qualities in me.
The CIO needed me to brutally prioritize tasks, make decisions based on data, honor commitments, manage risk, be persuasive, take on the big problems, and not be afraid to get my hands dirty.
Recently, the CIO asked me to morph out of Vader mode, so I thought I would take opportunity to reflect back on Vader moments in an ITSM project.
Don’t be too proud of this technological terror you’ve constructed
A lesson early on, an ITSM project is not about technology. The technology will only be as good as the process constructed. If your incident management process does not work when you execute it on paper, adding any technology is just going to accelerate the pain. Remember to include your stakeholder in the design and to put people first. Even if the process does not work, the people, if you have gained their trust, will quickly find a good workaround and help improve the next iteration.
Lesson Learned: Involve stakeholders and communicate intent. Use technology to accelerate good processes
Don’t underestimate the Force
As with any project, you will have your Jedi and Sith plus a lot of people simply trying to get through the rebellion. Dealing with Jedi and Sith is the easy part. The “political” alignment is easy to spot and understand. For me, the Jedi are teammates who help lead the “we’re not changing” attitude (i.e. the ITSM rebellion). While my Sith brethren actively and proudly helped build the “Death Star” (i.e ITSM processes).
The difficulty in my ITSM project was dealing with the “just trying to get through” crowd. We had:
Uncle Owen – wanted nothing to do with the rebellion (“just leave things alone”)
Greedo and Boba Fett (bounty hunters) – worked to “take out” new process and changes
Droids (but not C-3PO or R2-D2) – folks you really could not communicate with and simply seemed to be focused on doing the next programmed task
Lando Calrissian – people who seemed to be on your side but you still are unsure of their motives
Admiral Ackbar – people who kept reminding others the project is “a trap”
This group is easily swayed by the Force and Jedi mind tricks from the Jedi and Sith. As we all know, the Force in our organizations is culture, and this is what binds everything together. Small shifts in the Force can lead to misunderstandings and misinterpretations.
Need an example? Ever brought up an idea, just as a concept, with no intent of doing anything more than creating a discussion and suddenly you are fielding questions/comments/concerns about this idea? “When are we doing this?” “Nobody discussed this with me!” “You just can’t decide on your own to change my job” If you dig a little, you find members of the Jedi used the Force and Jedi mind tricks to build FUD and sometimes to derail the work.
Lesson Learned:There is a fine balance of culture in an organization. Little things (changes, ideas) may not upset the balance but a buildup of little things can cause a great disturbance. A lot of change can happen, sometimes quickly. Keep communication channels open. Let people express their concerns and take each concern seriously. Work to displace FUD.
And now, your highness, we will discuss the location of your hidden rebel base…
I knew we had “shadow systems” running in our support environment. Proving it, along with the issues caused, was difficult. We got to a point where we started asking, “If a shadow system works (really) well, should you disrupt it just because you are adopting a service management framework?”
We tackled this issue by talking to our Service Owners and finding out why the system was in place. In several cases, it was simply old design and the system worked so well, nobody felt there was an issue to address. We used the ISO/IEC 20000 standards to help determine if the system met the level of quality we desired. If it did, we worked to formalize the process. If not, we worked to transition to an appropriate process. Along the way, we continued to build trust and fight Jedi.
Lesson Learned: If something works well, meets your goals, and satisfies customers, stick with it.
You are part of the Rebel Alliance and a traitor!
Confronting those who actively worked to disrupt the project is one of the most difficult and challenging aspects of the job. In any project, you must understand the FUD statements. Determine why your colleague(s) feel this way. It is important to listen carefully. Find out why they perceive the project as a “threat” to their job/career/lifestyle. Make sure you address why they feel they way they do.
You will receive many opinions while managing an ITSM adoption project. Keep in mind two things:
You are charged with getting the project to completion
Know who charged you to get this done.
Comedian Jerry Clower tells a story where he was hired to perform at a show. When Jerry walked into the theater, the lighting director walked up and asked “Mr. Clower, how would you like the lights tonight?” Jerry thinks for a moment and then responds, “Son, I don’t know. You’re a professional. Just make everything look as good as you can.”
Next, the makeup artist asks Jerry, “How would you like your makeup done?” Jerry responds with “You know, you ain’t got a lot to work with…just make me look as good as possible. I trust you”.
Finally, the manager of the theater asks, “Mr. Clower, would you mind coming through the audience and shaking hands as you come on stage?” Jerry responds with “Sir, it would be my pleasure to do so!” The manager pauses for a moment and then says “Mr. Clower, I’ve been talking with my staff. All of them tell me you are so friendly and trusting of their abilities. We get a lot of artists in here who just are not that way. Why are you so different?”
Jerry looks the manger dead in the eye and responds, “Son, did you forget? You hired me.”
The point of the story – don’t forget who you work for. The CIO wants this project done. Know the reasons why. Also, know and understand the level of support from the executive team, the service owners, and process owners. Everyone has to be on the same page for this to work.
Lesson Learned: It takes a village to adopt ITSM. Know the key reasons for the project. Know the stakeholders and their expectations. Remember who you work for.
May the Force be with you
Finally, here are some additional thoughts:
You may be Darth Vader in your project. Just remember to stay true to people first then the project. Don’t give into the Dark Side.
Search your feelings – Always use as much data as you can but don’t forget to use intuition and the counsel of others to help make decisions.
“I’m altering the deal. Pray I don’t alter it any further” – Remember, it’s a project. It’s not a recipe, cookbook or set of instructions. Know the scope of your efforts and be flexible as possible without compromising the quality of the project.
Can you relate to this? Which Star Wars character are you when it comes to your ITSM project?
I am undergoing a very personal transformational change right now. I am trying to learn how to eat in the real world and maintain a healthy weight. I had really let myself go.
No exercise, eating too much, eating the wrong things and not caring. The results: 360 lbs.; the inability to walk at least 50 feet without wheezing; acid reflux; and an impressive expanding waistline. I felt horrible. My body simply hurt all the time.
After much self-loathing, I made the decision to change. Now, I control my calories, carbs, fat and protein levels and I get 60 to 90 minutes of exercise in a minimum of 5 days per week. I made my health issues a “big rock” in my life (see Stephen Covey’s “Put your big rocks in first”).
The results: I currently weigh 320 lbs., I’ve lost 4 inches on my waist, and I feel a heck of a lot better.
The funny thing in all of this, people keep asking me what “diet” I’m using. Okay, here it is – I eat less, make better food choices, and exercise as much as I can. Disappointed with my answer? I find that many folks are looking for me to give them some “magical” advice like “oh, I lost the weight by following the Krispy Kreme diet”. There are no silver bullets. You have to eat right and exercise.
So, what’s the point in relation to ITSM?
The point is this; you must build and follow a plan for an ITSM initiative to work. There are no simple solutions or silver bullets to make adoption easy. Be prepared to work hard, suffer some failures, learn from those failures and iterate, just like you do with a diet.
In order to be successful in ITSM adoption (or in your diet) I recommend following the key “exercise and eating” tips and advice listed below.
Don’t fall for hype
“Just follow our simple x step plan every day, and we’ll guarantee you will lose weight”
I’ve seen ITSM blog posts and consulting statements that indicate the same thing “…just follow our advice and you’ll be doing x process in no time” or “buy our product and we guarantee you will be ITIL compliant”. If it sounds too good to be true, it probably is. Any offering of a “quick fix” probably will not work. Think about the long term and what you want the program to achieve. Learn good habits.
I don’t do “diets” but there are items within the multitude of diet plans out there that do make sense for for certain individuals. ITSM is no different.
If something works, adopt it. If it doesn’t, forget it. For example, Problem management as detailed in ITIL® doesn’t fit well with how my organization works. We therefore adopted LEAN 8-step method as the primary way to execute our problem management but use the information in ITIL® to ensure our process is as robust as needed.
Build a plan that works for you and helps you achieve your goals
There are many ITSM frameworks out there and no rules that say you have to use a specific one. My advice is that you read, learn, and research.
You may need to use ITIL®, LEAN, COBIT®, USMBOK®, and/or combinations of the aforementioned to build your plan. Don’t do something just because someone else says you should do it. Know what you are trying to achieve and select the appropriate framework to work toward it.
For example, my company uses many different frameworks along with ISO/IEC 20000, with ISO/IEC 20000 as an indicator of “world class” IT operations. Despite this, we have attempted on four different occasions to start the adoption process for Configuration Management. What we found is teams did not understand what to do with CIs or how to move them through a change process. We therefore took a step back and spent more time looking at our Change process, and are now starting to have tabletop discussions on moving a CI through a change.
In doing this exercise, we found our teams had different execution of change, different ideas on what a CI is, and different ideas on how to move a CI through a change cycle. These discussions gave us the opportunity to drop back and review all the frameworks for a “good fit” to help accelerate what we do.
If the plan is not working, change it
When exercising, eventually your body can become use to a specific exercise and become efficient in the activity. At that point, you can continue doing the same thing, but the results will not improve. An ITSM plan is the same. If your plan is not getting the results you desire, mix it up and try a different approach. Focus on a specific aspect and find the change that helps you get the results you need.
During the adoption of incident management at my company, we had team members onboard who had been doing incident work for many years and yet our design process kept missing key steps we needed to fulfill ISO/IEC 20000 requirements. Clearly we needed a different approach and so we went back to the beginning and built a checklist of items that the design team needed to complete prior to submitting deliverables. This helped us to identify the missing steps and fix the design process.
When it comes to exercising and being healthy, my FitBit gives me all types of data to help me determine if my behaviors match my plan. Data helps us measure where we are against our goals, which is important in any ITSM initiative.
What you measure is up to you, you cannot allow others to dictate what data you need to collect. Identify your goals, and collect and analyze data that helps you reach those goals.
At my company, we ask our service owners to identify “pain points”, the place where their team or their customers indicate something in the process doesn’t deliver the promised goods and/or causes them problems. We have found that focusing on a few key measures and “pain points” leads the service owner and their teams to think more holistically about the service and why they are doing what they do. This organically leads to continuous improvement, brainstorming and discussion about user experience.
Keep the goal in mind
It is easy to get discouraged when you go a couple of weeks without losing any weight, and the same is true in ITSM. Don’t lose sight of what you have done and where you are now.
Sometimes it may seem easier to follow the same path as you always have and get the same (bad) results to achieve quick “outcomes”, but how does this help overall? Remember, incremental improvements over time lead to reaching goals.
One of the toughest issues I have with weight loss is overthinking the situation – I can become my own worst enemy. The same is true with your ITSM plan. Work the plan you built, and if something doesn’t work so what? Try something new! Be mindful of your situation and don’t be afraid to change. It will all work out in the end so just remember to breath and relax.
And a bonus tip!
Be as transparent as possible in any ITSM initiative or project, routinely discussing your success, failure, trails, and tribulations. This will help you to stay grounded and on top of where you really are in your process/project. Use your measurements to remind yourself and others of the progress you have made and make sure you understand the deliverables and timeframes.
ITSM adoption, just like maintaining a healthy lifestyle, can be tough. It takes planning and execution, measurement and analyzing data, and it also takes support. Remember, don’t fall for the hype; always evaluate; build a plan that works for your situation and change it as required; measure your progress; relax; and always keep your end goal in mind.
We had spent a lot of time designing and tweaking.
And so I went into my meeting excited to explain the new process. Alas, I was not ready for what was about to happen. Barely ten minutes into the explanation of the process, the first salvo was fired:
“This is not what we do. That will not work.”
The exchange over the process escalated from kind explanation, to defending work steps, to questioning professional ability, to name-calling, and it didn’t end there. Trust eroded and partnerships dissolved. After the meeting (and several antacids), I tried to regroup and figure out what went wrong.
I didn’t realise that I just had the opportunity for a “crucial conversation”.
What is a “crucial conversation”?
The entire meeting interaction bothered me so I did a little soul searching to determine why I felt so bad. In my search for answers, I came across the book “Crucial Conversations”. The liner notes quickly described my meeting. Intrigued, and somewhat skeptical, I bought a copy and started reading.
A crucial conversation (as defined by the book) is “a discussion between two or more people where (1) stakes are high, (2) opinions vary, and (3) emotions run strong.
Any journey undertaken to adopt ITSM has many perils. One of the toughest perils is communication. No matter how well you communicate, there always remains an opportunity for somebody to misinterpret, misunderstand, or change the information provided. When I discuss tough challenges of ITSM adoption with other practitioners, communication issues always rank in the top three. The truly toughest conversations not only exist when talking with the C-level, but in the day-to-day conversations with the teams who convert the vision to reality.
Why are they crucial? Simple, they are the day-to-day conversations that affect your life. Crucial conversations are crucial because a) opinions vary; b) stakes are high; and c) emotions run strong. Crucial conversations can be a service desk agent assisting a customer, a CAB discussing a change request, a service owner discussing a process with operation teams, or DevOps teams planning a release.
The Power of Dialogue
Di•a•logue (dìʹ ð-lôǵʹ)n – the free flow of meaning between two or more people.
We each have opinions, feelings, theories and experiences that shape how we view a topic. As we discuss a given topic, we do not necessarily share the same views as others. We do not have a “shared pool of meaning”. People who have mastered the skill of dialogue make it safe for others to add their meaning to the shared pool and having a shared pool of meaning is a key deliverable for any ITSM project. A shared pool of meeting leads to better discussions, better debate, and better decisions. If we position people to purposefully withhold meaning from the shared pool, individually smart people can do very stupid things. Shared meaning helps teams build synergy.
Time to look in the mirror
The key to good dialogue is heart, specifically your heart. We’ve all grown up with various forms of poor communication during crucial moments in life and/or work – debate, silent treatment, manipulation. Not the best role models or behaviors for important conversations, which is why you must work on your changing your own communication first. While we may want, wish, and desire others to change, the only person you can consistently inspire, prod, and shape is the person looking back at you in the mirror.
What do you want?
When I ask other practitioners what they most want in an ITSM relationship with a teammate, the answer is usually “good partnerships”. Successful ITSM adoption only occurs when everyone believes others are working to help improve the state of their situation (a shared pool of meaning).
In all likelihood, you are going to have moments (both in life and in ITSM) where someone completely disagrees with you. You present a change, like a new process for example, and the person counters with:
“We’ve been doing well for the past x years…this change will just confuse things and make it more difficult to do our jobs.”
You know the change is the right thing for the organization, but how do you make those reluctant to change understand this? In the past, when confronted with this type of situation, I have been defensive, offended, and even arrogant. Of course, those qualities led to failure in getting the change adopted and damaged any future efforts for collaborations with the person.
After reading the book “Crucial Conversations”, I changed how I approach these situations. I now take a step back and ask myself the following questions:
What do I really want?
What are my motives and are my motives changing as the conversation moves forward?
What do I really want for others?
What do I really want for the relationship?
How do I behave if I really want my desired results?
By asking these questions, we affect our psychology and physiology. We can think differently, look teammates in the eyes, and become genuinely interested in what others have to say. We get away from the old (bad?) habits, which we have been exposed to over the years and instead ask ourselves questions that remind us of our goal(s). This helps our brains stay on a path to focus on achieving said goal(s).
Winning and Losing
We often talk ourselves into the idea that we must win or lose, choose between peace and honesty, or try to find a way to make “everyone happy.” The idea behind Crucial Conversations is that we all need to win. We need to help everyone on our team, in our company, in our family, and in our circle of influence reach the results that make us successful. Crucial conversations are necessary to help people find ways to hold emotional and risky conversations safely and with purpose.
Don’t expect to read the book and then be beautifully successful in all your conversations moving forward. You won’t be perfect on your first attempt, but don’t worry about it. Just like ITSM, your ability to hold crucial conversation is a continuous improvement process. Just be persistent. Doing so should help lead you to better relationships and collaborations.