Tag Archives: Implementation

The Opportunity of Failed IT Plans

Share twitterlinkedinmail

What went wrong in 2020?

I know, it’s a big question and most people would probably say “Everything.” Or at least, many CIOs would confess that the original strategic plans they had for 2020 were not executed.

There were many initiatives that just failed to get off the ground in 2020 due to COVID-19.

Now that 2020 is winding down — what happens to those initiatives? Should you try to execute on them in 2021? Are they even still valuable to your organization? Will you still have the capital for them? How can you afford them?

Smart CIOs know they can’t carry on as normal. Just because something was on the plan for 2020 doesn’t mean it should continue to be on it for 2021. Yes, strategic projects are still strategic, but it’s time to address whether the strategy has changed. If it has, the CIO has to know how to protect IT’s budget while shifting initiatives.

This is where the opportunity of a failed plan presents itself and where innovative CIOs can reset their priorities, align themselves with the rest of the organization, and ensure budget protection for 2021.

Revisit Your Organization’s Existing Strategic Plan

First, it’s important to understand what impact COVID-19 has had on your organization. This means more than just a workforce that is now working remotely. How did it impact the way your business operates and delivers value to customers? Did business models change? Did you add any new capabilities that are still contributing to ROI?

Now look at your existing IT strategic plan. Does it incorporate the changes made because of the impact of COVID-19?

It’s possible you could have some major changes to make to the IT strategic plan. For example, if your organization has added new revenue streams, then you may need to completely change the strategic plan to incorporate those new streams.

Look for Opportunities in your Value Streams

As you review what has changed in your organizations, you should also be identifying the opportunities for IT inside of this new strategy.

This exercise is best if you know the value streams in your organization (whether they are brand new as a result of COVID or they were already in place). If you don’t know the value streams of your organization, then now is the time to map them along with other members of the executive teams.

Remember, this is a chance for meaningful, impactful change. It’s no longer “business as usual.” We can’t say “Well this is the way it’s always been done” because organizations have proven they are capable of agility and making big changes quickly. When mapping value streams and looking for opportunities, don’t be afraid to open up to possibilities that might have seemed impossible a year ago. After all, most people would have said taking an organization completely remote in 48 hours would have been impossible this time last year but by now, most IT organizations have accomplished exactly that!

Fix any Value Leaks

Now, after you’ve reviewed value streams and are fired up about the new strategic projects you could bring to the organization in 2021, there’s a big question to answer: Where do you find the budget for it?

Some IT organizations were fortunate enough to have larger budgets this year while they enabled remote working — but those checkbooks won’t be as open in 2021.

Here’s what you can do right now to protect your budget in 2021

Look for the value leaks in your organization. Value leakage is a common problem in every organization but few leaders know to look for it. Businesses don’t operate on a consistent basis every single day. Value leaks can occur when changes in business workflows aren’t reflected in technology workflows, or people weren’t trained on new products or features, or when services or products aren’t retired appropriately. Value leaks occur due to poor communications, or when the organization fails to fully understand the costs and risks of any change, no matter how slight it may seem. If no one is monitoring value streams and measuring how value is delivered, then value will start getting dropped along the way.

In the context of protecting the budget for 2021, you can start finding and addressing the value leaks that are happening right now in 2020. When you start to fix the leaks, you can prove to the organization that you’re creating more value. The more value you bring to the table, the more you can justify your future budget and protect the budget for those bigger strategic projects you identify when mapping your value streams.

The Key is the Big Picture

The most important thing any CIO can do to seize the opportunity of failed plans is to not lose sight of the bigger picture. 2020 didn’t go to plan for anyone and every organization experienced shifts that will impact future strategies.

Your strategic projects from 2020 might still make sense in 2021. Or they might not. What’s important now is to look at how the organization delivers value to its customers and the opportunities for IT to enable and co-create that value. Then look at how IT can create even more value by fixing existing value leaks.

I think everyone will say that 2020 changed everything. But only the most innovative CIOs will be able to say that 2020 changed everything in the best way possible.

Share twitterlinkedinmail

What is DevOps?

Share twitterlinkedinmail

“What is DevOps?”

Taken at face value, the question may seem a bit rhetorical, but allow me to explain.

There is no single definition of “DevOps”. If you ask five people “What is DevOps?”, you’ll likely get five different answers.

Need some examples?

Here’s how Gartner has defined DevOps[1]: “A change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach.  DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams.  DevOps implementations utilize technology – especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”

 Take a look at “The DevOps Handbook[2] by Gene Kim and others.  It states that DevOps is “…the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream.  DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organizations, safety culture, human factors, and many others…the result is world-class quality, reliability, stability, and security at ever lower cost and effort; and accelerated flow and reliability throughout the technology value stream, including Product Management, Development, QA, IT Operations, and InfoSec.”

 One of my favorite definitions is from Rob England (aka “The IT Skeptic”). Rob describes DevOps as follows[3] : “Agile is the approach of working with complex systems anywhere. Lean is the approach of optimizing the flow of work anywhere. DevOps is the application of Agile and Lean to the acceleration of value work through IT.”

DevOps Defined?

Perhaps the best definition of DevOps is credited to Jez Humble, one of the co-authors of “The DevOps Handbook” who coined the term “CALMS”.[4] CALMS is a conceptual framework for integrating development and operational (DevOps) teams within an organization.  CALMS is an acronym for:

  • Culture – A culture of shared responsibility
  • Automation – Automate as many tasks as possible
  • Lean – Visualization of work-in-progress; limit batch sizes; eliminate waste; continuous improvement, focus on customer value
  • Measurement – Data is collected on everything, with mechanisms for providing visibility into all systems
  • Sharing – There are user-friendly channels for facilitating on-going communications

In most DevOps thinking and reading, CALMS seems to be a common theme.  But I also encounter a lot of DevOps “anti-thinking” as well.

What DevOps is not

Here are a few examples of DevOps “anti-thinking” that I’ve encountered.  DevOps is not:

  • A standard – There is no documented “DevOps” standard.
  • A tool – There are literally hundreds of tools (I’m not sure if this is a good or bad thing) that claim to be “DevOps” tools. The point is buying a tool does not make your organization a “DevOps” organization.
  • A best practice – There is no defined “body of knowledge” or designated reference for DevOps. In fact, there are literally hundreds of books about DevOps, and some (highly visible) examples of organizations that have successfully adopted DevOps thinking. But there is no designated DevOps “best practice”.
  • Just automation – While automation is perhaps one of the most visible aspects of DevOps, automation alone is not “DevOps”.
  • A silver bullet for IT issues – Just saying that you’re “doing” DevOps is not the same as addressing communication issues, collaboration challenges, wasteful processes, poor measurement practices, eliminating technical debt, and other organizational problems.

What is DevOps?

So, what is DevOps?  At its core, DevOps is a mindset; a way of working together. DevOps is:

  • About building trust and teamwork, sharing knowledge, taking accountability – Teams build trust when members can rely upon one another. Trust is built when team members openly and willingly share their knowledge and contribute to the success of the team.  When mistakes happen, the member making the mistake acknowledges the error; but more than that, there is no blame; the team works together to resolve the error.
  • About tearing down the walls that exist between working groups within IT – DevOps can only be successful when all parts of the IT team are part of the success.
  • About creating a culture of experimentation and learning – Too many organizations work in fear of failure. Much about DevOps is about empowering and learning.
  • About improving the productivity of the overall organization – Sometimes that means searching out and eliminating waste or streamlining the process. If it’s taking too long to get code to trunk and then tested, what can be done to improve that?  If standing up a new development environment requires manual intervention, what could be done to standardize that work so that manual intervention is no longer required?

Avoiding DevOps “Ditches”

Knowing what DevOps is and is not will help you get on the road to success. Here are five ditches to avoid to achieve success with DevOps.

  • Purchasing and implementing tools before anything else – DevOps adoptions taking this approach usually fall into the old “hammer and nail” syndrome (“when all you have is a hammer, every problem looks like a nail”). Well, just because you own a hammer and can swing it doesn’t make you a carpenter.  One of the most common mistakes with DevOps adoption is too much focus on tool implementation and automation of (often poorly or even undefined) processes. When all you have done is implement a tool without designing processes or developing teams, you’ve not “DevOps”- you’re just using a tool – and likely not getting the full benefit of that tool.
  • Getting hung up on semantics – Developers and operations both have developed their own specific languages for what each group does – and this often causes confusion. Take the time to define and agree on a shared terminology.
  • Developers running over everyone else in the organization under the flag of “we’re doing DevOps” – Once, while at a client site, I heard a “DevOps engineer” (seriously) tell a sysadmin that “I’m about to automate you out of a job.” Not a very collaborative, teamwork attitude, huh?  DevOps is about building teams whose members trust and rely on each other- not trying to dominate or control.
  • Arbitrarily throwing out existing process and procedures – Although a process may not be performing as effectively and efficiently as desired, don’t overlook the fact that there was a good reason why that process was defined and implemented in the first place. In my experience, process design and implementations have been treated as “one time” activities and rarely revisited to identify improvements or needed changes.  Before getting rid of an existing process, first understand the reason for the process, and if that reason still exists today.  Then look for ways to improve that existing process, rather than just throwing it away.
  • Ignoring the need for organizational change – DevOps adoption represents a significant change in the way IT does its work. Without good communication, appropriate training, and a shift to a “thinking / experimentation / learning” mindset, DevOps adoption will fail.

Keep CALMS and DevOps on

Knowing what DevOps is and is not is key for success in adopting DevOps.  Following the CALMS model ensures that you’re addressing the complete extent of DevOps adoption, and not just being fixated on a single aspect.

Need help answering the question “What is DevOps?”  Want to build a fundamental understanding of DevOps?  Tedder Consulting offers the DASA-accredited DevOps Fundamentals class.  Visit  our training page to register for an upcoming class! 

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Picture Credit: Pixabay

[1] https://www.gartner.com/it-glossary/devops , retrieved 8/11/2018.

[2] Kim, Gene, et al. “The DevOps Handbook”. IT Revolution Press, LLC. 2016. Portland, OR

[3] http://www.itskeptic.org/content/laymans-definition-devops, retrieved 8/11/2018.

[4] https://whatis.techtarget.com/definition/CALMS , retrieved 8/11/2018.

Share twitterlinkedinmail

Is it because you’ve really not implemented ITIL?

Share twitterlinkedinmail

“Slow.” “Bureaucratic.” “Out-of-date.”

Just a few of the words I’ve recently heard or read used to describe ITIL®.[1]

Could it be because no one has really implemented ITIL?

So before the world reminds me that we don’t “implement ITIL”, we implement “IT Service Management based on ITIL”, hear me out. Is ITIL really too bureaucratic and out-of-date, or is it that few have really implemented ITIL? Allow me to elaborate.

In my experience, the typical ITSM implementation based on ITIL looks something like this:

  • Incident Management
  • Service Desk
  • Change Management (well, sort of)

Some organizations may have rolled out some kind of Problem Management process or Request Fulfillment process.

Some organizations may have implemented what they are calling a Service Catalog, although that “Service Catalog” is actually a Service Request Catalog.

Some organizations have implemented a CMDB, which is often created as an output of a discovery tool. The discovery tool does a fantastic job of discovering anything that is attached to the network and collecting all sorts of information, most of which we really don’t need (or want!) to manage within a CMDB. Perhaps rudimentary, serially-defined relationships are discovered (which is to say that whatever the discovery found next must have a relationship to what was found immediately before). The assumption is that anything that is discovered is a Configuration Item (not necessarily true).

In my experience, the focus of most ITSM implementations are on the day-to-day operational aspects of an IT organization-and not much else.   Of the 26 processes defined by ITIL, most organizations attempt to implement only three to six of those processes. The processes that are implemented are primarily focused around IT operations.

If you think about it, it’s like the old “cart and horse” story, but with a twist. Many ITSM implementations worry about making sure that the cart is ready for use, but ignore the fact that a horse is also needed.

I’m not suggesting that an organization arbitrarily implement all 26 processes. However, if you’re basing your ITSM implementation on ITIL and if some thought isn’t given to the other aspects of the service lifecycle, then the implementation will eventually begin to struggle, will not evolve, and will ultimately fail to deliver on the should-have-been value of an ITSM implementation.

What I am suggesting is to follow a “adopt and adapt” approach. Adopt the concept, and adapt it to meet the unique needs of your organization. So, if we are to adopt the approach that ITIL suggests, then that means we must consider each area of the service lifecycle.

Service Strategy – What does our business need from IT in order to be successful? What services does the business need, and what is IT’s capability for delivering those services?   Is anyone at the executive management level aware of and supporting our ITSM efforts? Has a plan been developed, documented, and agreed that defines the why, who, what, how, and when of the ITSM implementation? Is this plan regularly and periodically reviewed and adjusted as necessary?

Service Design—One of the most frequently encountered mistakes I see is a rush to draft Service Level Agreements (see my blog, “Do you really need a SLA?”). What I usually find are three flaws:

  • Services have not been defined and agreed
  • No consideration has been given to the fact that the organization has critical dependencies on external suppliers in order to deliver Services
  • Metrics have not been defined that reflect business-relevant (not just IT ) measurements

Service Transition – Change Management has three purposes – ensure that the appropriate model for managing a change has been utilized, communicating changes, and scheduling changes so that they don’t collide with one another. Change Management was never intended to be a bureaucratic exercise, but because other aspects of Service Transition do not get addressed, Change Management often is burdened with additional responsibility. For example, in the absence of a formal Release Management process, Change Management often gets tagged with understanding and tracking all of the elements of a build. In the absence of formal Service Validation and Testing, Change Management gets stuck with ensuring that testing and quality assurance has been done.

Continual Service Improvement – Too often, ITSM implementations are treated as “one-and-done” endeavors. I have long said that one of the reasons why to implement ITSM is to establish an approach for continual improvement. The business that you work for today is not the same business it was five years ago, or even one year ago. We need a way to evolve alongside our business. We need a way to identify and implement the right improvements.

I will be among the first to agree ITIL is far from perfect (what is perfect?), but ITIL must be thought of as an ecosystem. Understanding how implementation decisions impact the overall viability of the ecosystem is crucial. Do you need to formally define and implement processes from each phase of the service lifecycle? Perhaps. Or perhaps not.   Regardless, you should define – and document – the approach you intend to follow to adopt and adapt and how you intend to address each phase of the service lifecycle. If you do this, coupled with an approach of continual improvement, your ITSM implementation based on ITIL (or whatever methodology (or methodologies) you choose) has a greater chance for success.

Click here to subscribe to my newsletter!

[1] ITIL® is a Registered Trade Mark of AXELOS Limited

Share twitterlinkedinmail

8 Things to Know Before Starting your ITSM Implementation

Share twitterlinkedinmail

Starting an ITSM implementation is exciting, challenging, while at the same time terrifying.  There always seems to be a lot of angst, anticipation, fear, perception and misperception associated with an ITSM initiative.    It is not a task to be taken lightly, and to be successful, an ITSM implementation requires a clear strategy and approach.  To make sure your initiative gets off to the right start, I’d like to suggest eight things to know before starting your ITSM implementation.

1. Why do you want to do this?

A successful ITSM implementation will transform the way your business does business.  Having clarity regarding current challenges, the issues you’re going to solve, and the expected benefits of the implementation is critical.   To articulate all of this requires a well-formed business case.  A business case not only presents the justification for starting the ITSM implementation, it also gives you a means to obtain and keep senior management support.  For more insights into the value of developing the business case, please have a look at “The Case of the Missing Business Case”.

2. What is the approach?

What are the near term and longer term objectives of the ITSM implementation?  Are there “quick wins” that can be delivered within the first 60-90 days that will result in meaningful value to the organization?  Developing an ITSM Plan clarifies how you’re going to be successful with your implementation.

3. What are the business requirements for this initiative?

As part of developing your ITSM Plan, identify how the ITSM implementation will directly support or enable business requirements or help the business meet its needs.  I’ve always said that the closer you can tie your ITSM initiative to the business mission, vision, and goals, the greater the chance of success.  ITSM processes can help the business ensure compliance with regulations, policies, contracts and so on.  Effective use of ITSM processes can ensure proper controls on data, separation of duties regarding Change Management, compliance with software and other licensing, and so on.  The key here is to ensure that the ITSM implementation is viewed as a “business initiative”, not just an “IT initiative”.

4. What does “success” look like?

If you don’t define what success looks like and who will evaluate success, how will you ever know if you are successful?  Yes, while this may sound like common sense, the defining of “success” is very often overlooked!   One way to define success is to identify and agree on clearly defined goals and targets, along with how progress toward those goals and targets will be measured and reported.  Just as important as defining goals, targets, measures, and reports is identifying who will evaluate success.  Will it be your CIO, or will there be an ITSM Steering Committee?  Knowing who will evaluate success helps you develop the appropriate measures and reports they need to see.

5. Is there sufficient budget?

ITSM implementation is not a trivial endeavor, and will require investments (that you justified in your business case!) to be successful.  First, there will be investment in training and education.  Keep in mind that not all training need be a formal or virtual classroom-based training; there are great learning opportunities at conferences, user group meetings, and webinars.  Also keep in mind that completing a three-day class is not sufficient qualification for architecting and implementing ITSM—think of it as having your “learner’s permit” for driving—it doesn’t make you an experienced ITSM practitioner.  Therefore, you may want to consider bringing in external consultants for some period of time in order to leverage experience and expertise that you don’t have in-house.  Lastly (yes – lastly), you’ll want to invest in needed ITSM tools, identified based on process designs and business requirements.

6. What is the cultural landscape of the organization?

ITSM is all about people, process, and technology.  Notice what aspect I listed first – people.  It is people that make ITSM work.  The best process designs running on top of the best ITSM technology are worthless unless people are engaged and buy-in to ITSM.  The success or failure of an ITSM implementation greatly relies on recognition of the attitudes, behaviors, and culture (ABC) of the organization.   Understanding the ABC of the organization guides your implementation approach, process design, communication and training plans.

7. Who is going to do this?

One of the worse things to do is not having the right team and expertise to execute the ITSM implementation.   Get the right people on the ITSM implementation team, not just people that have nothing else to do.  Look for people that have a “service” attitude- that is, they think in terms of value chains, comprised of the combination of people, process and technology that work together to deliver the outcomes and value required by the business.  Recruit people that have the “big picture” view to understand how IT ‘fits’ within the organization, how IT contributes to the success of the organization, and can advocate for the change in mindsets from “my component” to “our service”.   Lastly, when you find the right people, make sure they are provided with the time to do the job; don’t have the ITSM implementation become “other duties as assigned” or “extra work”.

8. When do we start?

Acting with a sense of urgency and building and sustaining momentum are keys to success for an ITSM implementation.  ITSM implementation must be treated with the same importance and priority as any major initiative of the organization.

Knowing the answers to these eight questions will help you avoid getting “behind the 8-ball” when starting your ITSM implementation.

Need help getting started?  Need to get clarity on these 8 things to know?  Tedder Consulting can help – and without all of that overhead that you’d get (but don’t need) from those big consulting firms. Let’s get started – contact Tedder Consulting today!

For more service management insight, click here to subscribe to my newsletter!

Share twitterlinkedinmail

ITSM is like a jigsaw puzzle

Share twitterlinkedinmail

At some time or another, most of us have sat down and put together a jigsaw puzzle.

Regardless if there are only a handful or hundreds of pieces, there are some constants that apply to solving any jigsaw puzzle.

  • All pieces must be used.
  • All pieces fit with one another.
  • It doesn’t really matter where you start, but in order to solve the puzzle, you must start – somewhere.
  • Having the big picture in mind is helpful for solving the puzzle.
  • Having a strategy for solving the puzzle is helpful.
  • The puzzle is never solved in a single move.

It has often occurred to me that an ITSM implementation is much like putting together a jigsaw puzzle.  Think about it—with any ITSM implementation, doesn’t the same constants that apply to solving a jigsaw puzzle apply to an ITSM implementation?

Every ITSM implementation involves three major puzzle pieces: people, process, and technology.  All three of these pieces must be used.

In addition, these three puzzle pieces – people, process, and technology – must fit with one another.  Too much focus on the technology, and you may wind up with processes that don’t work within your organization (because the out-of-the-box processes found within the technology were designed with sales, not your organization, in mind).  Too much focus on the process, and you may find that months have gone by and the same issues that existed when you started process design are still present.  And by the way, the business didn’t wait on you and has changed since you started the process design activity.  Without enough focus on people – the most critical aspect of ITSM implementation –  the human resources involved may not be able to able to adequately perform their roles and responsibilities, because there’s been a lack of training, communication, inclusion, marketing, and so on.   A successful ITSM implementation finds the right balance – or fit – between people, process, and technology.

There are a lot of opinions regarding where to start an ITSM implementation.  Go have a look – you’ll find as many opinions as you’d like.  From my perspective, there are a few things that are simply table stakes for any IT organization – how to effectively handle service interruptions, how to effectively handle changes, and how to effectively handle requests for IT services.  Any IT organization must do those three things well or frankly, they will cease to exist.   So if you’re not doing those three ITSM things effectively, get to work on them now.  There’s one place to start.  If you are doing those things, are there opportunities for improvement?  Start there.   Another idea is to start with a new IT-enabled business initiative and introduce ITSM as part of that initiative.  Or maybe there are some recurring issues that the Service Desk is constantly dealing with – that might be a good place to start.  Strictly speaking, it really doesn’t matter where you start – just start.   One thing I can say for sure – if you don’t start, your IT organization may never improve.

Just like with solving a jigsaw puzzle, having the big picture in mind and a plan for achieving that big picture are vital for an ITSM implementation.   There’s a saying that inevitably comes up in regards to ITSM implementation – “if you don’t know where you’re going, any road will do”.    This is absolutely true – if you don’t know where you’re going with your ITSM implementation, you will fail.  Seeing the big picture, having a plan for achieving that big picture, and continually making measurable progress toward achieving that big picture will serve any ITSM implementation well.

There are other pieces to the ITSM “jigsaw puzzle” that are often overlooked:

  • Developing the business case for ITSM, to gain senior management support. (For more about a business case, have a look at my previous blog article, “The Case of the Missing Business Case”.)
  • Defining and documenting your ITSM Plan, outlining the scope, time horizon, process interfaces, success criteria, and other pertinent information.
  • Developing and executing a marketing and communications plan, not only within IT, but also with those that IT serves, to ensure everyone is aware of what you’re doing and how things are going.
  • Learning from others, through user groups, conferences, webinars, and blogs (pardon the shameless plug!). You’re not the first nor the last to work on the ITSM puzzle, and there is much to be learned from others.
  • Develop and report business-relevant, meaningful metrics, to ensure you keep the support you earned with that business case.
  • Incorporate continual improvement into your ITSM implementation from the beginning. Having a continual improvement approach will help you “course correct” and identify further efficiencies as your implementation proceeds.

Click here to subscribe to my newsletter!

Share twitterlinkedinmail

Don’t point that finger at me!

Share twitterlinkedinmail

There are a few life-lessons I’ve learned that I can happily attribute to my mother.  I’m sure many of you have some life-lessons and words of wisdom that you can chalk up to your mother as well.  Nuggets like “you don’t get a second chance to make a first impression”.  Indeed!  How about “to make a great omelet, you have to break a few eggs “?  Spot-on.

Here’s one that applies to ITSM.  “Be careful when you point a finger at someone….there are always three fingers pointing back at you.” Well, now…there’s something to think about.

Over the years, I’ve gotten into more than a few conversations about how to make ITSM “stick”.   I don’t know what it is about us IT types….we often seem to think in absolute terms.   It’s either “on” or “off”.  It’s either “black” or “white”….there doesn’t seem to be room for the “gray”.

And while I fully agree that successful ITSM implementations feature clearly defined and “lived” roles and responsibilities, I sometimes run into a perception that ITSM is about “penalty” or “punishment”.    I’ve heard things like “they didn’t follow the process”.  Who is “they”?  Don’t we all work for the same organization?  Isn’t “they” really “us”?   Or “we met the terms of our SLA”.  Sure “we” did.  But when was the last time “we” did a Service Level Review with the customer to ensure that the terms of the SLA were still relevant?  Did “we” develop SLAs that actually have customer signatures, or did “we” document a set of objectives that were decided and agreed upon within IT?  Besides, SLAs are not sticks that are to be used to hit customers over their collective heads, nor are SLAs intended to sit on shelves collecting dust, referenced only when it’s convenient for us.

ITSM is not supposed to be painful nor is ITSM about punishment or blame.  ITSM is about consistency and repeatability, driving effectiveness and efficiency.  Good ITSM is a result of good planning and good execution of that good plan.  ITSM is about continual improvement.  ITSM is about people and being inclusive of people, not segregating people.  It’s not about a number of ITSM-certified folks deciding what’s best for other IT people.  It’s not about just IT people thinking about what is best for the business.  ITSM is about collaboration between the business and IT and moving forward in a planned and agreed way, with shared goals, working to ensure optimal delivery and support of services with acceptable levels of risk at the best cost.

So if and when ITSM isn’t working as expected, don’t point fingers.   I’d like to suggest that you ask the following questions to get to ‘why’:

  • Have you educated your organization about the goals, objectives, and business benefits of the ITSM implementation?

How will ITSM improve what the business does?  How will it improve working both with IT and within IT?  What does “success” look like?  Understanding and educating the organization about the goals of the ITSM implementation, how the implementation of ITSM will enable outcomes needed by the organization, and how ITSM will contribute to business success will help everyone understand why we’re doing ITSM…which will help ITSM ‘stick’.

  • Have you documented your processes? Is your documentation ‘consumable’?

If you’ve not documented your processes, quite frankly, they don’t exist.  No one can say what you were thinking when you designed the process, but put it in writing and everyone can read, discuss, and internalize the process.  Also, be sure that your documentation is ‘consumable’.  What I mean by that is documentation should be easy to read and follow a consistent approach to documentation so the reader knows what to expect when reading the document.  Personally, I’m a big fan of concise, focused documentation – for example, a Policy document should talk just about the policy, rationale, benefits and consequences.  It shouldn’t discuss procedures, roles, etc.; those are subjects for a different document.  Likewise, when I read the procedure document, I can quickly read what needs to be done and how to do it.   I like bite-sized documentation chunks that I can quickly read, understand, and apply.

  • Have you clearly defined roles and responsibilities? Do process actors understand their roles and responsibilities?

People generally perform better when they understand what is expected of them.  People are critical for successful processes – processes will not work without people.  Executing formally designed and on-going training, communication and awareness plans are critical for winning the hearts and minds of those you depend upon for a successful process – the people that interact with it.

  • Have you made your processes effective, yet as simple as possible?

ITSM is not about who can devise the most complex or intricate processes.  While there may be situations that require a high degree of complexity, generally speaking, simpler is better.  The simpler the process, the easier the process will be do it.  The easier the process is to do, the higher the probability for success.

  • Have you clearly defined and published meaningful measures for your ITSM implementation? Do you celebrate those measurable successes? Do you take and publicize actions when those measures indicate opportunity for improvement?

Without measures, ITSM programs will become invisible quickly.  Having and publicizing measures lets everyone know how ITSM is going, and the visibility of those measures will also help make it “stick”.   Having measures that are relevant and meaningful to the business are even better.  Yes, it is important to understand how many Incidents you had this month.  However, it’s more meaningful to the business if your measures illustrate that because of effective Incident Management, the business was able to meet or exceed its widget production goal for the seventh consecutive month!

Remember, when it comes to an ITSM implementation within an organization, we’re all on the same team.  Finger-pointing won’t help.  Getting to the ‘why’ will help make ITSM ‘stick’.

Has your ITSM implementation not delivered what you were hoping for?  Let Tedder Consulting help with workshops or consulting services that will stop the finger-pointing and deliver success.

For more service management advice and opinion, please click here to subscribe to my newsletter!

Share twitterlinkedinmail