Tag Archives: culture

Let it go

Share twitterlinkedinmail

I remember when I first realized it.

I was participating in an itSMF USA local interest group leadership workshop in St. Louis in 2008. It was the last day of the workshop, and the itSMF USA had arranged to have a speaker make a presentation about leadership and the topic of setting and achieving goals. There were about 50 or 60 of us in the room, seated at round tables. As I recall, at one point during the presentation, the speaker had us stand and each hold something in our hand; I chose to hold a glass of water. The speaker then asked us to find something located in the middle of the table, reach out, and hold it in that same hand.  I saw that there was a coffee cup about midway on the table. I put the glass down and reached out to get the coffee cup.

That’s when I realized it.

If I was to achieve a goal – any goal – I first had to “let go” of what I had.

Isn’t the ultimate goal of an ITSM implementation exactly the same situation? If an organization is to realize the benefits of its ITSM implementation, doesn’t it first have to “let go “of what it is doing today? To get the coffee cup, I first had to let go of the glass of water. To truly achieve business-IT alignment, both the business and IT need to “let go” of how they each are interacting with each other today. Neither the business nor the IT organization will achieve the vision and goals of an ITSM implementation by continuing to hang on to the “old ways”.

Let go of old ways

What are some of the “old ways” that must be “let go”?   Attitudes and behaviors where we are too concerned about being right, instead of doing what is right. Too worried about “saving face” versus owning and learning from setbacks and poor decisions. Recognizing that we achieve more by working together than by working in silos.

What does this mean?

From the IT perspective, it simply means this:

  • It is all about the business.
  • It is not about doing IT for IT’s sake.
  • IT exists to enable and deliver value and outcomes needed by the business.
  • IT must have regular, frequent, and ongoing discussions with the business it serves – at all levels.

From the business perspective, it simply means this:

  • The business must decide how it wants to exploit its use of IT.
  • IT must be included in (and in some cases lead) these strategy discussions.
  • IT must be properly funded and enabled if it is to achieve the vision of the business.
  • Business must have regular, frequent, and ongoing discussions with its IT organization – at all levels.

To achieve this, IT must take on the roles of integrator, partner, innovator, leader, and service broker (to read more about these roles, have a look at my blog, “IT doesn’t have Customers”).

Let’s go one step further. The secret to ITSM success is that IT recognizes the business is in “the driver’s seat”. The more that the business drives ITSM, the more successful it will be. ITSM must be a business initiative, enabled by IT.

There will be those that will not like this and will resist. Some in IT will look at this as a loss of control or power. Frankly, in the business-IT relationship, IT never had “power” or “control” – and it never should have been about this anyway. Some in the business will have to change their approach and include IT as part of their planning discussions. They won’t have IT to blame anymore when they didn’t include IT as part of their planning- it should have always been this way anyway. On both sides, it will take commitment and effort. It will feel very uncomfortable. There will be a lot of fear of the unknown. There will be mistakes made. There will be lessons learned. It will be okay. Focus on and keep working toward the goal.

And “let it go”.

Click here to subscribe to my newsletter!

Share twitterlinkedinmail

Shysters, Highwaymen, and others on the ITSM Journey

Share twitterlinkedinmail

Travel in medieval times was always full of challenges and dangers. Travel usually took place during the daylight hours, following roads perhaps built during the Roman Empire period, or following other roads that were not well paved, if they were paved at all. Sometimes the “road” was simply a rarely used path or obscure trail. Travel was slow; usually by foot or perhaps horseback, and journeys took days, if not weeks to complete.   Any journey was quite an endeavor, as people usually traveled in groups, not only for company, but for protection as well. Those traveling had to pack some provisions and hope to find a safe haven with shelter and food along the way in a roadside tavern. Travel was dangerous, as highwaymen hid in the nearby underbrush, looking to rob an unsuspecting party or unaccompanied traveler. Even during stops at a roadside tavern, the travelers couldn’t totally relax. Shysters would approach the traveling party and promise rewards in exchange for a sum of money, but the reward would never materialize, leaving the traveler with nothing. Travelers could also encounter mystics, who like the shyster, for a sum of money, would predict the future; when morning came, the mystic was nowhere to be found. Sometimes travelers found the journey too treacherous and stayed near the tavern or even turned back. Further compounding the journey was the various fiefdoms that traveling party had to pass through. Each fiefdom had its own set of customs and laws, despite the fact that the fiefdoms were all part of the same kingdom. Bad weather, rivers, mountains, and other obstacles presented challenges to the travelers as well.

But for those that planned well, took appropriate precautions, and remained vigilant, the traveling party accomplished their goal and reached their destination. Many times, there was a feast for the travelers to celebrate the successful journey.

Certainly, I think you can agree that modern travel has come a long way since the medieval times.  Medieval travelers encountered challenges, obstacles and shady people on their journeys.

But it occurs to me—are ITSM implementations so different than medieval travel? It isn’t so much of a stretch when you think about it:

Medieval Travel ITSM Implementations
  • Poor or non-existent roads
  • Often trail -blazing – there is no current road!
  • Had a destination in mind before traveling
  • Business Case and ITSM Plan
  • Traveled in groups
  • ITSM implementation team
  • Travel was slow
  • ITSM implementations take time (“journey, not sprint”)
  • Many obstacles and challenges
  • Many obstacles and challenges
  • Shysters, highwaymen, mystics, traveling party
  • People who support, doubt, or resist ITSM


Do you see the similarities?   While there is a lot here I could discuss, I’d like to focus on the aspect of people.

Are you encountering shysters, mystics and highway men on your ITSM journey? How are you keeping your traveling party focused on the goal? What are you doing to keep those that want to stop or turn back engaged?

When I think about it, I think that the people we encounter on the ITSM journey generally fall into one of three groups:

  • Believers –This group is energized about the implementation and put heart, soul, and mind into the effort. They don’t become discouraged when the inevitable obstacles and challenges arise, but use those challenges and obstacles as motivation to achieve success.
  • Doubters – Generally the people in this group take a “wait and see” approach. While they may not resist the ITSM implementation, they aren’t quite convinced that it will be successful either.
  • Resisters – This is the group that wants nothing to do with the ITSM implementation, and often work against the implementation.

In your ITSM implementation, you must address all three groups. All three groups are a part of your ITSM “traveling party”. None of these groups can be ignored nor favored to the determent of the others. So how to ensure that all three groups are being engaged? Here’s some suggestions:

  • Believers – Keep in mind that ITSM implementations are journeys – they take some time! Have your believers participate in the development of goals and objectives and identify interim achievements. Celebrate successes along the way, and approach challenges and obstacles as learning opportunities. Showcase the efforts and accomplishments of the implementation. Proactively engage them, solicit and incorporate their feedback on the implementation.
  • Doubters – Develop appropriate measures and reports, and show them the evidence that your making progress. Show this group how the use of continual improvement practices will help overcome challenges. Show them how ITSM is helping the organization achieve its goals and objectives. Proactively engage them and solicit and incorporate their feedback on the implementation.
  • Resisters – This one may surprise you—make them part of the solution! Purposefully include resisters on the process design teams and workshops. Have them articulate specific (not general) areas of concern and engage them to help determine the resolution to those concerns. Proactively engage them, solicit and incorporate their feedback on the implementation.

The ITSM journey will take some time. You may have rebuild some worn down roads or in some cases, blaze new trails. There will be those on your journey that want to sell you things you don’t need, or worse, take your money and vanish. You will encounter obstacles and challenges.   But in my opinion the most important part of the ITSM journey is the people that you’ll meet on the way.   Engaging your believers, doubters, and resisters – all three groups – is a key to a successful ITSM journey.

Need some guidance on your ITSM journey?  Tedder Consulting is here to help – contact me today!  Get my monthly insights into all things service management – click here to subscribe to my newsletter!

Share twitterlinkedinmail

We don’t need another hero

Share twitterlinkedinmail

Do you like movies featuring superheroes?  You know the ones – the superhero has some superlative ability, like superhuman strength, or telepathic ability, or super speed, or heat vision, or shape-shifting.   The plots of these movies are generally very similar – it is usually an epic battle of good vs. bad, which means that there is usually some threat or menace that threatens to take over the earth or at the very least, would certainly end life as we know it. Then, just when you think it can’t get any worse, or the last domino is about to fall, the superhero appears and saves the day.

And, if you’ve watched enough of these superhero movies, perhaps you’ve noticed a few other similarities:

  • The hero tends to be a loner, and doesn’t really work well within teams.
  • The hero may save the day, but usually leaves a mess– a big mess—behind that someone else has to clean up.
  • Others usually watch the hero, but few (if any) rarely (if ever) get involved.

Does this sound like someone in your organization?  Do you have a “hero” on your ITSM team?

So while it may be entertaining to watch the hero at the movies, it’s only a movie.  When it comes to ITSM, we don’t heroes.  In fact, heroes are bad for ITSM.  Why?

Businesses depend on IT to be reliable and consistent, which are a couple of the many good reasons why IT organizations undertake an ITSM implementation.  While heroic actions may save the day, by definition, heroic actions are not reliable and are inconsistent. Good ITSM depends on consistent, repeatable and measurable processes.  Efforts from the hero are not repeatable, not sustainable, and frankly, leave a mess.  This ‘mess’ takes the form of damaged relationships not only within the team, but damaged reputations for both the business and the IT organization.  Internal business partners eventually grow tired of the hero, so they often begin to work around the hero, or may even avoid IT altogether.  So while in the near term, the actions of the hero may be appreciated (and even wrongly rewarded!), over the long term, it’s just not good business.

Good ITSM depends upon good teamwork, with everyone working together within roles as part of a team.  In my role as a consultant, I often point out that if it only took one person to do everything that needs to be done within IT, then why is the rest of the IT organization here?   We simply cannot work in silos or alone (as the hero often prefers) and expect long-term success.  Heroes destroy teams.  Heroes cause resentment within teams, because often the hero is treated ‘special’ by management and as a result, acts as if the rules or policies or process definitions do not apply to her.  Ironically, heroes typically have no respect for or trust in management. Compounding the situation is that others on the team notice the special treatment that the hero receives, and become resentful.   If this treatment of the hero continues, the rest of the team begin to watch, and begin to withdraw from the team, only getting involved when absolutely necessary.

Good ITSM depends on knowledge sharing.  The hero tends to hoard knowledge, because to share knowledge would be a threat to their position as the ‘hero’.  Because the hero is so busy “saving the world”, he doesn’t have time to document knowledge, and if anything actually does get documented, it is minimal and difficult to consume.

I’ve yet to see a process RACI matrix that defines a role for the ‘hero’.   We don’t need a hero; we just need good ITSM.

Click here to subscribe to my newsletter!

Share twitterlinkedinmail

IT doesn’t have Customers

Share twitterlinkedinmail

“Business – IT Alignment.”   “The business is IT’s customer.”

When I started my personal ITSM journey, these were a couple of the early concepts to which I was introduced.  When I first heard these concepts, they made a lot of sense.   In a lot of ways, these concepts still make sense.

“Business – IT Alignment”.  What this means is:

  • IT must align to the business. IT must serve the business, not itself.
  • New technology and software are cool. But technology and software have no value unless it supports, delivers, or enables a business outcome in the most effective and efficient way.

“The business is IT’s customer”.   What this means is:

  • To deliver effective solutions for the business in the most effective and efficient way, IT has to improve how it works with the business. We need to get better at gathering requirements, get better at getting beyond the ‘what’ the business needs and understanding the ‘why’ the business needs it.
  • We must work much closer with the business and get out from behind the ‘closed door’ that characterizes many IT organizations.
  • Don’t do IT just for “IT’s sake”.

I get the ‘why’ behind the two concepts.  The culture of IT organizations needed to–in some cases, still need to–change.  The collective IT culture must “mind shift” from looking at itself as collections of “my component” to “our service”.

So fast forward….to the Pink 15 ITSM Conference in February, where I listened to a presentation from Dr. George Westerman.  Dr. Westerman is the author of the book “The Real Business of IT: How CIOs Create and Communicate Value”.1

Dr. Westerman’s presentation opened my thinking to what this new culture must be about.  Dr. Westerman made a few points (and I’m paraphrasing) that jarred my thinking:

  • The business is not IT’s customer.
  • IT does not have customers.
  • IT is part of the business.
  • The “customer” of the business is outside of the organization.

Whoa.  I came away from Dr. Westerman’s presentation realizing that the culture of IT needs to evolve even further.  In a lot of ways, the concepts of “Business-IT Alignment” and “the business is IT’s customer” are becoming obstacles of IT’s own doing.

I had to learn more.  Immediately following Dr. Westerman’s session, I purchased and downloaded his book onto my iPad.    The Las Vegas-to-Chicago leg of my flight home provided me with the opportunity to nearly read  the entire book.

One of the things Dr. Westerman discussed in his book was this idea of a ‘value trap’.  He defined a ‘value trap’ as “practices that seem to be good ones, but actually  prevent IT from delivering and communicating value”.  An example of such a value trap is the use of the term “customer” by IT when referring to the business.  While this may appear to be a good idea, Dr. Westerman argues that it actually inserts a wedge between IT and the business it serves.

If we as IT are to avoid this value trap, that means we need to change our perspective and take on new roles as a progressive IT organization.  What are these new roles?

  • Integrator — Identify and synthesize services and solutions to the organization to deliver outcomes that the business needs, drive efficiencies, and eliminate waste.
  • Partner — Go where your business colleagues are. Learn what they do.  Understand where challenges exist and how IT can be used to overcome those challenges.
  • Innovator — Identify and promote opportunities for using technology, software, processes, and methodologies in creative, value-generating ways.
  • Leader – Don’t wait to be asked how IT can be leveraged or exploited for business success. Proactively develop solution proposals and the business cases needed to sell the proposal to decision-makers in the business.
  • Service Broker – We are more inter-connected with our suppliers than ever before, and that trend will only continue to grow. Recognize skill gaps within IT and leverage areas of external expertise to deliver solutions that the business needs.

This represents a significant paradigm shift for many IT organizations. This may not be easy.  But I believe that its doing and learning from the hard stuff that makes us better, both as IT organizations and as individuals.   The important thing is that we start making the paradigm shift.

What can we as IT professionals do today to start the paradigm shift?

  • You’ve heard this one from me before. Become an expert on the business of the business. Understand what drives your company—beyond just revenue and profits.  Does your company take pride in its culture, its place as a good corporate citizen, or its history?  Is your company more entrepreneurial in nature?  Figure out what your company values, and then determine how IT can support or enable the realization of that value.
  • Drop the ‘geek speak’ when you are with business colleagues outside of the IT organization.   Outside of IT, no one really cares about network utilization, swap rates, and processor speeds.  It’s not that they don’t expect us to know that stuff–they do.  But what they do care about and what they want to have a conversation about is how are you as IT are making their job easier, how are you as IT delivering true business value, how you as IT are making a difference.
  • Talk and think in terms of ‘business value’. It’s not about availability of systems, it’s about providing services with such warranty and utility that enables the business to produce 10,000 widgets per month or handle expected call volumes to the customer care center.

Do we still need to ‘align’?  Yes—from the perspective of ensuring IT strategy aligns and supports business strategy.  But we need to take that thinking even further.  Try this on– there is no such thing as an “IT Strategy” and a “Business Strategy”.  To me, ‘alignment’ now means there is one strategy – the business strategy – of which IT is a significant contributor in its new roles of innovator, partner, integrator, service broker, and leader.

So it’s time to change some of our thinking.  IT doesn’t have customers.  The business does.   IT must start acting like its part of the business, no differently than Marketing, Sales, HR, Logistics and so on.   I believe that our businesses want us to do this; it’s just that they may not know how to ask.  Don’t wait to be asked.  Be an earlier adopter and exhibit the role of the new IT organization.

Click here to subscribe to my newsletter!

1 The Real Business of IT:  How CIOs Create and Communication Value”, Hunter and Westerman.  2009, Harvard Business School Publishing, Boston.

Share twitterlinkedinmail

Yes, you *can* just turn on your new ITSM tool…

Share twitterlinkedinmail

I understand.  I really do.  Your company has made a significant investment in a new ITSM tool.  Your company needed a new ITSM tool, and it’s just been sitting in the box on your bookshelf, waiting for you to get it in installed and running.   Your CIO has stopped by your workplace a couple of times in the past few weeks, asking how the installation is going, and when she will start seeing those dashboard reports that she heard about.   The features of the new ITSM tool are the talk of the Service Desk Agents, who can’t wait to get their hands on it.  Other managers are absolutely giddy about how the new tool will fix the consistency issues within IT and see the new tool as an opportunity to improve the undeserved poor perception of the IT organization.

So I may be about to say something you would not have expected from me.

Go ahead and install that new ITSM tool.  Turn it on.  Start working with it.  Have your Service Desk start logging tickets in the new tool.  It will be great.  It will work exactly as you’ve imagined…..if…..


If you’ve defined what activities will be performed as part of the execution of the process, and how the process moves from beginning to end through each activity.

If you’ve defined the roles that are involved with the processes you’ve decided to implement, the responsibilities and expectations of those roles, and who is doing what activity within the process.

If you’ve identified what events start the execution of the process.

If you’ve determined what inputs are required for the proper execution of the process, where that input data is coming from, and how you’re going to capture and validate that data within the new ITSM tool.

If you’ve determined who will get the results from the execution of the process and how those results will be delivered.

If you’ve identified how success will be measured, defined the measures that you need to capture from the execution of the process, how you’re going to capture those measures, how you’re going to measure effectiveness and efficiency of the process, and how those measures will be translated and formatted into those dashboards the CIO is expecting (along with whomever else will need reports from the process).

If you’ve defined, documented, and informed your organization of the policies and procedures that help control the use of your processes.

If you’ve gained agreement, support, and sign-off from senior management for the enforcement of those policies that govern those processes.

If your Service Desk Agents have been trained in the optimal use of the new ITSM tool.

If you’ve adequately communicated and educated your organization about the benefits of the ITSM initiative the new tool is intended to enable.

Make no mistake—you do need the functionality that a new ITSM tool can bring to your organization.   But, if you can answer “yes” to all of the ‘ifs’ I listed above, your new ITSM tool implementation will go much better.

Need to get that ITSM tool up and running, but you’ve not defined processes?  Our Process Design Workshop is just the ticket – contact Tedder Consulting today to make it happen!  Get more pragmatic insights to service management by subscribing to my newsletter

Share twitterlinkedinmail

It Always Comes Down to This

Share twitterlinkedinmail

Now that I’ve been in the consulting side of ITSM for a while, I’ve noticed a pattern.  Maybe it’s always been there, but I’m now really tuned into it.

The success of every ITSM implementation comes down to one thing.  People.

The process and technology parts of an ITSM implementation, in comparison to the people side of an ITSM implementation, are relatively easy.

People, or more specifically, IT people are the most significant obstacle to effective ITSM.

Believe it or not, when you articulate the outcomes of an ITSM implementation in ‘business terms’ to the business—the business actually *wants* IT to do this.  They want IT to become reliable, to act in a consistent manner, to be cost-effective while delivering business value (yes, it can be done!), to become the trusted advisor in the use of technology, to identify and drive improvements, to become integrated (not just aligned) with the business…

It’s IT that usually can’t get out of its own way.  Sorry, but I’m calling it as I (often) see it.

Why is this?

I was having this conversation just the other day.  IT people don’t appreciate processes and procedures.  Accounting has processes and procedures that entire companies follow and utilize, everybody does what they’re suppose to do, and it works.  Payroll has processes, and everyone understands that in order to be paid correctly, there are certain procedures that must be followed.  I could keep going…sales…manufacturing…distribution…inventory….all have processes and procedures.

Why does IT think or act as if processes and procedures don’t apply to IT?  Or even worse, why does IT often take a “my way or the highway” approach when implementing ITSM?

From my perspective, the problem is usually found between the collective two ears of IT people.  Does the following sound familiar?

  • Lack of teamwork…”they” need to get their act together over in <insert department name here> …WE don’t need ITSM; we are doing fine.
  • Resistance… I will support ITSM as long as I don’t have to change anything that I do.
  • Everyone wants accountability, but no one wants to be accountable.
  • One of my favorites:  “This will just slow me down”….then hearing the complaints about having to work over the weekend or late into the evening cleaning up the mess from a poorly designed and tested change.  You don’t have time to plan, test, and communicate it, but you complain about the time it takes to fix it?  Really?

These are just a few of the cultural issues that must be overcome to be effective at ITSM.

Amazingly, there are two very simple things that will go a long way towards addressing these issues.

  1. Communicate – talk to each other.  Talk about the issues.  Talk about the challenges.  Talk about what went wrong.  Talk about what goes well.  Talk about what is missing.  Talk about what could be.  But it’s more than just “talk”.  Listen.  I mean really listen, not just hear.  While bringing issues and challenges to light is important, talking without anyone listening is just noise, and is not communication.  Listen for the common themes.  Listen for the good ideas.
  2. Inclusion.  Good ITSM is not just something that the ITSM team does.  It’s what everyone does, so involve everyone.  Take those good ideas and common themes and make them part of the ITSM solution.  Remember, process owners by themselves do not execute processes….people do.  Be part of the solution, make it work.

Communicate.  Include everyone.  Doesn’t sound so tough, does it?

Click here to subscribe to my newsletter!

Share twitterlinkedinmail