Tag Archives: tools

The Curious Case of the Wasted IT Investment

Share twitterlinkedinmail

There’s no doubt that if you want to be an efficient IT organization, you need efficient tools. Some might say that you need the best tools.

But when happens when those tool investments fail? And perhaps, more importantly, how do you prevent poor investments from ever happening again?

Here’s a story that might sound familiar to you of a (fictional) company who made an investment in a tool and then failed to see any return for it – and what they did to improve.

The Curious Case of the Wasted IT Investment

Dwight is a CIO for a mid-sized organization. He recently convinced his boss, the CEO, Lynn, that they needed to make a significant investment in a service management tool.

Lynn, recognizing that technology was more important than ever and there were increasingly more demands on the IT organization, agreed that IT needed the best tool on the market. They agreed that they needed a tool that would grow as that demand grew. They needed a tool that would help IT drive consistency and repeatability in process execution, but at the same time, facilitate innovation as new business drivers emerged. And while they had only developed and implemented a few service management practices, they anticipated that they would need the capability to support additional service management capabilities as the organization continued to digitize its operations. It wouldn’t be too long before the organization would need to leverage capabilities like automation, process orchestration, and chatbots. And frankly, their current service management tool had seen its better days – it was time to get a modern service management tool. Perhaps even a tool that could be used within other parts of the organization!

They decided to invest in the most expensive, fully featured service management tool on the market. It truly could do anything that they wanted to do…and more!

Dwight, Lynn and the entire team were delighted with their choice! The tool can do everything. It will undoubtedly solve all of their service management issues.

But a few weeks go by, then a few months… and both Dwight and Lynn are noticing that things aren’t improving. Even with the fancy new tool, Dwight can’t get all of the information he needs to present his updates to Lynn, who wants to see that improvement and consistent performance from the use of this tool. The IT organization still isn’t doing things in a repeatable way and many team members are still performing tasks manually. Processes are still disjointed and information does not flow well from process to process – and automation is nowhere close to becoming a reality for the IT organization. Dwight consistently ends up scrambling to gather data for the management reporting needed by Lynn.

Lynn is beginning to wonder why they decided to invest in modernizing the IT organization with this tool. Meanwhile, Dwight is worried that they failed in their modernization. He is seeing other departments prove their ROI and he is fearful that he blew their budget and won’t be able to convince Lynn ever again to invest in tools.

If you purchase the most capable tool, then how do things go wrong? The problem was never in the tool. The problem was before the tool and therefore, the tool can’t fix the problem. It’s like trying to build a house on quicksand. No matter what materials you use to build the house, it’s not going to stop it from sinking until you deal with the quicksand problem.

Let’s start with where Lynn and Dwight made their mistakes.
The first mistake is thinking a tool investment was the key to modernizing IT. A tool should never be your first investment. Are tools important? Absolutely! But a tool-first mentality ignores the most important part of your organization: the people using that tool.

Let’s start with the members of IT and how they need to be a part of modernization.

Lynn and Dwight should have asked themselves:

  • Do the members of IT understand why we’re investing in this tool?
  • Do they understand what role the tool will play in their everyday work?
  • Do they know how the tool will improve their work?
  • Have they been properly trained to use every part of the tool?

The mindset and buy-in from the team is important above all because these are the individuals who will be using the tool and ensuring it’s providing maximum return. When they feel they are part of the decision-making process, they will be more invested in learning and working with the tool. If everyone in the organization is invested in working with the tool, they’ll take the time to learn it and master it so that they are actually seeing all of the benefits of its many features.

The next thing Dwight should have addressed is the organization’s processes. Dwight should have ensured his processes were clearly defined, documented and adaptable. Then he should have identified how the tool will enable those processes, and communicate the processes and the tool’s role across departments and within the IT organization.

Defining (or redefining) processes will remove any ambiguity in service delivery. It ensures that there is transparency within IT. And Dwight and Lynn will have a clear idea of how the tool is working – and how well IT is able to contribute to business outcomes.
These steps seem simple, don’t they? But Dwight and Lynn skipped them because they were so certain that investing in the premium tool would instantly (and easily) fix all of their problems. Instead, they ended up in the exact same place they were before they purchased the tool – only now they’re spending a boatload of cash, and not getting the return they had hoped. A curious case of a wasted IT investment.

The lesson for every CIO, CFO, and CEO?

Don’t invest in a tool thinking it will solve the problem. If your car wasn’t working properly, you wouldn’t just purchase a new engine and think it will do the trick. You’d pop open the hood and find out exactly what’s not working then find the part that will fix it. If there’s somewhere in your organization that isn’t operating efficiently, try popping open the hood and doing the work to find the problem before you invest in a high-price, fully-featured tool.

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

Five Lessons for Successful Transformation

Share twitterlinkedinmail

I received an email from a well-known web hosting provider titled “Transform your business with a second phone number”. The email stated that with a second phone number, I can separate my business calls from my personal calls – and do that using a single device.

I suppose that would be an interesting use of technology. It might even be an impactful change in how I’m doing things. But would it really be ‘transformative’? Or just a change?

Change vs. Transformation

What is the difference between ‘change’ and ‘transformation’? A change results in current things being done in an incrementally different way. Transformation is a process by which current ways of working are converted into or completely replaced by something completely different.

For example, business transformations consist of new lines of business, an acquisition, or a spin-off of a business unit. Digital transformation results in new business models, moving from a pipeline approach to a networked ecosystem of providers, producers, owners, and consumers. Service management transformations introduce methodologies and new mindsets to facilitate business value delivery based on the use of technology.

Has ITSM been transformative for your organization?

ITSM, done well, is transformative.

Has that been your organization’s experience with ITSM? I’m guessing that for some that read this article, the answer will be “no”.

Why haven’t some ITSM implementations been transformative? In my opinion, because those implementations only made incremental changes – not transformed – how IT was utilized. There was no effort to map IT’s contribution to business value chains. There was no effort to defining services in terms of business value and outcomes.

In these implementations, the focus was only on operational activities like how an incident was being handled. What was implemented as “ITSM” was really an incrementally different way of doing what was already being done. The IT organization was already taking calls from its business colleagues before there was a service desk; it was already reacting to outages before formally defining an incident management process.

ITSM is transformative when the utilization of IT within an organization becomes dramatically different. The (whole) organization talks, acts, and works in terms of business value and quantifiable results. The focus is not about IT-business alignment, but rather an integrated, collaborative approach within an organization (yes, the organization includes IT) working toward achieving shared business goals.

Unfortunately, many efforts to promote ITSM as transformative failed because ITSM was presented as a just a tool or a support solution, and not as a way for IT to deliver business value.

In short, the ITSM implementation was just an incremental change to what was being done, not a transformation.

What makes it a ‘transformation’?

Transformation requires rethinking the current ways of doing things. Transformation is wide-reaching and pervasive across an organization. Transformation is often high risk, but also high reward if the transformation is successful.

Transformation is really a leap into the unknown. Transformation requires courageous actions in the face of resistance, confusion, and ambiguity.

I am convinced that IT must transform…or IT will die. Many IT organizations are approaching (if not already on) the brink of irrelevance. In many organizations, IT is viewed as an order taker. A cost center. Nonresponsive and slow to deliver. Too expensive. A black hole.

IT should be a valued collaborator. Innovator. Partner. Leader. Integrator. Enabler. This is the transformation that will result from good ITSM.

But in many organizations, IT is viewed as the former and not as the latter. ITSM – done well – can transform IT. If IT doesn’t transform – and soon — IT will no longer be relevant.

Lessons in (ITSM) Transformation

If transformation is critical for IT, and good ITSM is transformative, then why have so many ignored the lessons from transformations that fell short? When I think about transformation and ITSM, there are five things that I’ve learned.

Don’t start until the desired business outcomes are defined, understood, and agreed
ITSM presented as a technology or IT-only initiative will (eventually) fail. Too many ITSM implementations have only addressed the operational aspects of service management and never the strategic or business aspects.

What is the business trying to achieve? What outcomes does the business require? How can ITSM help business achieve its goals and deliver the required outcomes?

The closer you can align ITSM with the vision and goals of the organization (through measurable, business-relevant contributions), the more successful you’ll be with ITSM.

Don’t blindly believe all of the hype
An organization should not pursue a ITSM transformation just based on the what they’re reading or hearing from industry analysts, a consultant, or a tool vendor. The fact is that your company is unique. Companies must evaluate the potential advantages and difficulties of ITSM for their specific organization with a critical eye.

This means that you must do your homework. Learn what is “good ITSM” and the investment that is required to achieve success. Know that there will be missteps, false starts, and mistakes. There are no transformation cookbooks, no shortcuts, or instant fixes. You must evaluate what will be best for your company, develop the business case, define the plan, and execute.

Don’t lead with technology
Abraham Maslow stated in his 1966 book, The Psychology of Science, “When all you have is a hammer, everything looks like a nail”. When you start ITSM implementation based on a tool, there will be a tendency to try to solve every issue using that tool before completely understanding the issue itself.

Before you can determine what tools are needed, first identify and understand the requirements of your ITSM implementation. Have discovery conversations with business colleagues to understand their particular challenges with and expectations of technology. Determine how ITSM can help. Then identify the technology needed to support the required ITSM solution.

Don’t underestimate the need for cultural change
Transformation with ITSM can’t happen without providing a compelling reason for change, rewarding and recognizing those that embrace the change, and making the resisters part of the solution. This means that you must market, communicate, and train those involved with ITSM.

Then you have to do it again. And again. A single ‘town hall’ meeting or a memo from senior management will not cut it when it comes to cultural change. And even when you think the transformation has become rooted within the organization, you must continue reinforce the transformation by investing time, energy, and resources into the attitudes and behaviors required for good ITSM. Cultural change is not a one-and-done event, but must be an everyday effort. Without this ongoing investment, it is too easy to slip back into the old ways of doing things.

Don’t assign accountability without also assigning authority
An important aspect of ITSM implementation is establishing ownership and accountability. Having ownership and accountability not only drives transformation, it also enforces a sense of urgency. But assigning accountability without also assigning authority is not only ineffective, it is also demotivating for both the change agents (those that have been made accountable) and those that want to transform.

Authority provides the needed “permission” from senior management to drive the transformation that results from a good ITSM implementation. This means that senior management must recognize that authority must go across the whole organization, and publicize that authority has been given to those that have been made accountable for ITSM implementation.

If your ITSM implementation wasn’t transformative, there’s still time – but you must act. Don’t just make an incremental change. These five lessons will get you on the right path for successful transformation.


Is your ITSM implementation transformative … or just an incremental change? Consulting services from Tedder Consulting transforms ITSM implementations. Don’t wait to transform – contact us today!

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


Image credit:  pexels.com

Share twitterlinkedinmail

The End of the Service Desk?

Share twitterlinkedinmail

It was the two words that caught my attention. It was the two words that I heard repeatedly over the course of the two days.

“Call deflection.”

I attended the 2017 HDI conference, which gave me an opportunity to visit several ITSM vendors in the expo hall. Nearly without exception, when I asked vendors about their tools and products, among the first words I heard during each visit were “call deflection”.

“Call deflection” is a nice, non-threatening way of saying that the service desk does not have to take a call from a consumer for support. In other words, the consumer is being provided with other ways to get technology support.

As I was walking around the expo floor, I had an epiphany.

It is the beginning of the end of the service desk — at least as we know it.

The challenges of the current service desk model

The current service desk model is too reactive, too cumbersome, and too vulnerable to subjectivity and interpretation. Often times, the service desk is the victim of inadequate enablement by the rest of the IT organization, which results in frustration, both for the service desk agent and the consumer. And while many companies have invested heavily in training service desk agents and implementing remote control tools and knowledge bases, it hasn’t been enough to overcome the frustration that many consumers have with service desk operations.[1]

By definition, the current service desk model is interrupt-driven. The actions of the service desk are triggered when a consumer reports an issue or makes a request. That trigger is also the exact moment when the service desk becomes vulnerable to subjectivity and interpretation – the consumer that relays their interpretation of their issue or request; and the service desk agent, who then interprets the consumer’s issue or request into technology terms. Further compounding the issue is a categorization scheme that is defined in technical, not consumer-friendly terms and cumbersome, linear processes that do not enable the service desk agent for success.

The new capabilities of ITSM tools

Can technology provide the solution? With most of the solutions now provided by ITSM vendors, there is little reason to actually call a service desk.

Integration of monitoring systems, along with the maturation of event management procedures, have enabled ITSM platforms to proactively identify and resolve incidents. With the information captured by monitoring, there is no need to ask the consumer about symptoms – the monitoring system and the (now) integrated ITSM tool already knows. Because of this integration, automated response can be invoked to prevent an outage from occurring. Integration of advanced automation technologies allow ITSM tools to take complex corrective actions for incidents than cannot be prevented.

ITSM tools have long collected a gold mine of user data and information, but that data was locked inside the tool. No more — many ITSM tools now feature data analytics capabilities, producing valuable insights as to how services and technologies are being used. This, in turn, enables proactive, data-driven decision-making that was not possible just a few years ago. With recent acquisitions by some ITSM tool vendors, machine learning-based actions using this data is not too far into the future.

Even if the technology cannot directly resolve a consumer issue, the technology can still deflect the call from the service desk. Chatbots and virtual agents facilitate a natural language, conversation-like interaction with a consumer regarding support issues, but without human intervention. Leveraging cognitive computing and a robust knowledge base, chatbots and virtual agents enable the consumer to make queries and get the exact help that is needed.

The technologies for deflecting calls away from the service desk are real and are available now.  What does this mean for the service desk?

The service desk of tomorrow

The service desk, as we know it today, will no longer exist.

Not only has technology enabled a new service desk concept, but other methodologies are redefining the concept as well. Methodologies like DevOps are redefining the support model, with the same team that developed a service also providing the support of that service. Swarming changes the management of incidents, replacing a linear, tier-based support approach with a collaboration-based approach wherein the incident moves directly to the person most likely to be able to solve it. That person may involve others if needed, but is ultimately responsible to ensure the issue is resolved.[2] Today’s service desk is not conducive to either of these approaches. So, what is the service desk of tomorrow?

The service desk of tomorrow is a multi-channel, multi-point-of-contact entity that provides direct, individual support to the consumer, exploiting the use of technology. The service desk will no longer be a self-contained unit. Rather, the service desk of tomorrow will be as a loosely-coupled team of specialists working in separate but interrelated functional and process areas. These specialists will share the same ITSM platform that is used by the consumer, but advanced technology along with multi-methodology enablement will result in a differentiated consumer experience. For example, cognitive computing based on business rules will determine the person or swarm group to address any issues that are unable to be resolved through automation or self-service.

Get ready for the service desk of tomorrow

To deploy the service desk of tomorrow requires preparation today. Here are four things IT organizations must do to prepare for the service desk of tomorrow.

Build the right knowledge – To be useful, knowledge must be captured and made available in the context of the consumer of that knowledge. This is no different than today. However, greater emphasis must be placed on usability of knowledge by the consumer. End-user-facing knowledge articles cannot read like technical documents. Making knowledge available in various formats, such as “how to” videos or short animations, augmented by smart keyword tagging to help optimize searching will be key for the service desk of tomorrow.

Design comprehensive processes and workflows – The service desk of tomorrow must be responsive and efficient. Comprehensive process and workflow designs promote effective automated response and well as enable cognitive systems, providing the responsiveness demanded by consumers.

Define and agree business rules – Like workflow design, defining and agreeing business rules establishes the foundation for cognitive computing, chatbots, and virtual agents. Additionally, defining and agreeing business rules for consumer support also enables the consumer and ITSM to meet business objectives or comply with company policies.

Focus on simplifying, while enriching the user experience – With the service desk of tomorrow, self-service portals cannot be busy, menu-based interfaces that overwhelm the consumer. Instead, involve current consumers to design a user experience that is intuitive and choice-driven, presenting the user only with the right options, based on the choices she has made and the applicable business rules.

Your company’s demand for the Service Desk of tomorrow is closer than you think .  Tedder Consulting can help you get ready with our Service Desk Optimization consulting offering.  Contact Tedder Consulting today to get started!

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

[1] Drogseth, Dennis. “Introducing IT Service Management (ITSM) 2.0: A Cornerstone for Digital and IT Transformation”. Enterprise Management Associates. Sept 27, 2016. Web. Retrieved May 17, 2017.

[2] “Intelligent Swarming SM”, The Consortium for Service Innovation. www.serviceinnovation.org Retrieved May 26, 2017.

Photo Credit: Pixabay

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