Tag Archives: people

ITSM is More Than Just Numbers on a Spreadsheet

Share twitterlinkedinmail

This article was inspired by Mel Kerner, whose insightful comments on a recent LinkedIn post of mine started my wheels turning about the heart of service delivery.

Measuring and demonstrating the business value of IT is one of the biggest struggles for CIOs and IT leaders. There are thousands of articles, webinars, and commentary on how to demonstrate the business value of IT (I’ve even written quite a few of those articles!).

There are endless equations of metrics, KPIs, budgets, and technology that one can put together to demonstrate the value of ITSM. CIOs are hyper-focused on that bottom line. What does the IT line on the spreadsheet say about you and your organization?

That’s always the question, isn’t it? I’m not here to argue that CIOs don’t have to prove the financial sense behind their decisions on investments and projects, but I am going to pose another question:

What is at the heart of your service delivery?

I can see some of you rolling your eyes at this vague question that can’t be answered with metrics or financial projections. But I think we need to ask it because there is a goal of ITSM that can’t be measured with specific metrics or financial projections.

People, processes, technology… every IT leader has strategized over these 3 words. They are the 3 parts of every ITSM initiative.

We can measure how much technology is costing or saving the business. We can create baselines from which to measure the improvement of the effectiveness of our processes.

We can’t effectively measure the importance of people. We can capture metrics like call volumes and incident response times, but that doesn’t measure the service being provided. It doesn’t accurately demonstrate the importance of that service to the end-user – or to the organization.

This is important because sometimes everything adds up on paper, but IT is still struggling. Sometimes all of the financial plans make sense and the team is hitting its goals for all of its metrics, but users are still unhappy and service is still poor.

This is a very real disconnect occurring in organizations today. According to PWC, 90% of C-suite executives say their technology choices deliver what employees need. But 50% of employees disagree.

Is IT really delivering services if half of the organization don’t believe they have the technology for what they need? Even when the numbers on the spreadsheet are adding up, if the people in the organization are not satisfied and able to do their jobs, IT is not doing its job.

Impeccable service delivery starts with understanding how much that service delivery means to the most important part of service management: the people.

Do service desk agents understand the true value of solving a user’s technology problem? Do they fully grasp the frustration that arises when a piece of technology is getting in the way of someone doing their job?

Studies have shown that there is a direct correlation between employee experience and company performance. It’s no wonder why employee experience has become one of the hottest topics in business today. For IT leaders, this is an opportunity. They can use this focus on employee experience to remind their teams what is at the heart of service delivery.

Consider author Simon Sinek’s famous quote: “People don’t buy what you do, they buy why you do it.”

Does your IT team understand the “why” behind their metrics?

For example, why is response time important?

Is it important because it’s a box to check off? Or is it important because a service desk agent providing a timely response is able to return a user to their job faster so that they can complete their own work faster. And completing their work faster may mean they are responding to a client faster, closing a sales deal faster, or they’re able to start another project. A timely response time helps a user be better, faster, and more efficient at their job.

Or why is recurring incidents an important metric?

Is it important because it’s annoying for the service desk agent to have to solve recurring incidents? Or is it important because recurring incidents damage the reputation of the IT organization and are a frustration for the user? It can cause their mood and productivity to plummet which can then impact their interactions with customers and colleagues. It can even impact their interactions outside of the office. If you’ve had a frustrating day at work, you may end up bringing that home. The service desk can impact that!

IT leaders must talk with end-users about their experiences with IT. They should investigate the pain points users experience when their service calls are poor and the satisfaction they feel when their work is uninterrupted and technology actually makes their jobs easier.

There needs to be a bigger “why” for IT beyond just collecting metrics and impacting bottom lines. There needs to be a heart to your service delivery and it may be as simple as this: Better service delivery improves the day to day lives of your end-users.

Why does all this even matter if you can’t measure it?

The work IT does is often misunderstood and unappreciated. Most service desk agents won’t be thanked by end-users. Feeling unappreciated and inefficient will lead to burned-out agents who deliver subpar service and that can create a ripple effect. Service management is directly related to employee experience, which is directly related to company performance.

The IT leader must constantly remind the IT team why good service delivery matters. IT leaders need to take the steps to dig into the true “can’t-be-measured” heart of service delivery and communicate that to their teams. Ask the hard questions, dig into how users use services and technology to enable business outcomes, and start capturing and pointing out those immeasurable wins, just as often as you count the measurable wins.

At the end of the day, the numbers at the bottom of the spreadsheet will still matter. But the real story of IT goes far beyond the numbers on the spreadsheet. The real story is the one that’s told and heard throughout the floors away from the C-suite. It’s the story that really matters- the story of the employee’s experience.

Share twitterlinkedinmail

Are You Prepared to Meet Customer Expectations in 2020?

Share twitterlinkedinmail

In November 2018, I examined a few ways customer expectations have changed due to technology and what organizations, especially IT, need to know to stay competitive. Today, we reflect on how those expectations have changed in a short amount of time.

Customers, technology, new expectations. Let’s start off talking about a company that failed to pay attention to any of those things.

Long before we could access almost any TV show and movie from the simple click of a remote, Blockbuster reigned supreme. Anyone born before the mid-1990s probably has memories of heading down to the video store in hopes of finding a new release or a beloved classic. Of course, you never knew what would be checked out so you had to hope for the best. After you picked out and paid for your movies, you’d head home and watch it almost immediately. Because you had to return the thing a few days later to avoid those late fees!

But then in 1997, Netflix came along. And remember, before you could instantly stream thousands of movies to your TV, you could request certain DVDs online and Netflix would send them to you. And then you could send them back whenever you wanted. No late fees! This was revolutionary and it upended the video rental industry.

But Blockbuster failed to catch on. They failed to innovate. They failed to use the technology that was becoming available to them and they failed to meet the expectations their customers now had for their products.

Today, Netflix is booming and Blockbuster is long gone.

It’s easy to look back in retrospect and point out where Blockbuster failed. It’s easy to wonder how they failed to pay attention to the writing on the wall. But, of course, we enjoy the benefit of knowing how the future unfolded. Blockbuster didn’t recognize the impact of technology and, when I think about it, I can actually understand how they failed. At its peak in the mid-90s, Blockbuster had 65 million registered customers and was valued as a $3 billion company. They probably thought that they had happy customers, millions of them, in fact. They might have assumed that if they could just keep most of those millions of customers happy the same way they had been for over a decade, then they could endure some flashy competition.

The problem was not the competition, though. It was their customer’s expectations and their failure was marked because they refused to pay attention to the changing expectations of the marketplace.

While every industry is different, there are several overarching customer expectations that every organization should know.

Instant Response & Seamless Communication

Consumers don’t contact brands like they used to. They won’t call a hotline or sit on hold for hours. Now, they interact with brands just as they would interact with friends or family, through texting, social media, email or messenger. And no matter how they communicate, customers want an instant response. 40% of consumers expect a customer service response within an hour. (And yes, this means on the weekend too!)

Organizations must have the technology for instant response and seamless communication with their customers. Whether it’s incorporating chatbots, creating auto-response tools or using AI, you can’t afford to keep your customers waiting.

Easy Access to All Their Data

A decade ago, consumers understood if they had to be put on hold while you transferred them to another department or waited while you found their file in the filing cabinet.

But things have changed. Fitness trackers provide consumers with a wealth of data about their bodies just by glancing at their watch. Customers can open up Google, type in a word or two and have answers in seconds. Consumers have almost instant access to data these days. They expect your organization to do the same. They simply don’t have the patience for you to transfer them to the right department, dig for their info or wait for access from a superior to their data. Furthermore, you can’t afford to be relying on manual methods of data entry or note-taking inside a customer’s file. Every interaction needs to be automatically tracked. Your organization must have the ability to easily, securely and quickly access every customer data.

Delivery Times

Amazon changed expectations regarding delivery times. In 2015, 63% of consumers surveyed felt that 3-4 day shipping was fast. In 2018, that number dropped to 25%. And while many small businesses would love to gripe that it’s hard to compete with the biggest retailer in the world, griping will do very little to change the situation. Customers don’t care if they are ordering from a billion-dollar company or from a small shop made up of 10 employees. They expect faster delivery time.

This means organizations have to improve efficiency for every piece of the process that leads up to the actual delivery. From processing the order to packaging, organizations need to improve their process, optimize their technology and push themselves to be as fast and efficient as possible to meet demand.

Device-hopping

Consumers go from browsing on their phones to their tablets to their computers and back again. The experience with your brand needs to be consistent no matter what device someone is on. This means a mobile-friendly website, ordering system and contact forms. Everything you publish and promote needs to be accessible and easy to understand from any screen size.

These expectations are not easy to meet. The pressure is intense for every organization but I encourage organizations to look at more than the expectation but the need behind the trend to stay ahead.

Netflix didn’t succeed because they used technology to mail out DVDs. They succeeded because they understood their customers wanted convenience. Customer expectations are born because organizations pay attention to what customers want and need. Whether its speed, convenience, comfort, customer service or quality, there is a need or a want behind every new customer expectations.

Organizations, especially the IT department, should be listening to their consumers and identifying their underlying needs. If they can do this, then they can identify the best services, create better processes and find the right technology to deliver those services, meeting not only these customer expectations but any expectations that might arise in the future.

Share twitterlinkedinmail

What CIOs Can Learn From CMOs

Share twitterlinkedinmail

The CIO-CMO relationship has had a rocky history. The two are often at odds with what they need to accomplish and historically, they’ve never spoken the same language.

But there has been a shift in recent years. As marketing became more digitized, more marketing departments became focused on technology and data while IT departments face increasing pressure to deliver tangible business outcomes.

As digital transformation becomes more widespread across organizations, CIOs and CMOs must play on the same team. CIOs and CMOs are perfectly positioned to become a couple of all-star players within organizations – if they learn to work together.

How can CIOs and CMOs successfully work together to lead their organizations into the digital future? It starts with mutual respect, appreciation, and understanding of what each can learn from the other.

What can CIOs learn from CMOs? Here are four important lessons.

 

Customer Experience

Marketers must know their customers. They are deep in customer data, on top of consumer feedback and they keep a pulse on what the consumer expects from the industry. In short, CMOs are experts in the customers and IT can learn from that.

Customers are looking for more personalized support and solutions and self-service options. Technology can give customers all of those things but only if that technology has the right data. Marketing has the data that IT needs to create technology that will improve the overall experience.

Analytics and Testing

There are no silver bullets in marketing – just like there are no silver bullets in IT. So CMOs and their teams must hypothesize, measure, test, iterate and measure some more. CMOs know they have to have fluidity in their testing and launch phases. They also must adjust their analytics depending on a specific marketing campaign and its goals.

IT teams often get stuck in strict processes that leave no room for experimentation or testing. This usually leads to reduced productivity and IT teams end up feeling stuck performing processes that are inefficient. CIOs can take note as to how CMOs choose their KPIs, identify analytics, and use data to quickly adjust marketing campaigns – and apply these learnings c to IT initiatives.

Agility

IT has had a reputation for being slow to respond or quickly deliver new solutions. Marketing can’t afford to be slow or unresponsive to changes in the marketspace, especially in the digital age where things can (and do) change at lightning speeds. IT needs to take note because, in this age, both IT and marketing are expected to be able to react quickly to meet changing business expectations. Success is always a moving target and both teams must be agile and forward-thinking to keep pace with changing demands.

CIOs can learn how their CMO counterparts adapt to quickly changing markets and expectations. Understanding how CMOs prioritize projects, allocate budgets and resources, and lead their teams to hit their goals, even when the strategy or tactics change, can provide CIOs with great learnings in what it means to be agile.

The Language of the Business

This might be one of the most important lessons a CMO can teach a CIO. CMOs have always been measured by ROI. So CMOs have always had to learn to show how all of their initiatives can increase ROI.

IT, on the other hand, rarely had to demonstrate ROI in the past. They were back-office support teams. But that’s changed now and IT must shift from cost center to revenue generator. To do this, they must learn to speak the language of the business and prove ROI.

CIOs should pay attention to how their CMO colleagues pitch their initiatives, explain their results, and the metrics they use to measure success.

The Future of CIOs and CMOs

The CIO-CMO relationship can be mutually beneficial. When CIOs and CMOs work together, they can champion each other’s initiatives, encourage their teams to collaborate with one another, and create inter-departmental workflows and processes so they work more efficiently and with better results.

If you want to develop the CIO-CMO relationship, these tactics can help.

Find a common language
It’s essential that CMOs and CIOs understand how to communicate with one another. That means having open and on-going conversations about objectives and business needs. Both the CIO and CMO need to discuss jargon or what certain phrases mean within each department. If you are able to communicate openly and understand where each other is coming from, you’ll be prepared to take the next steps.

Align CIO and CMO outcomes
After you learn to speak the same language, ensure you stay in-sync on achieving shared goals. Hold joint meetings on a regular basis to ensure strategies are aligned, and share data and findings regarding the critical interfaces between technology and customer experiences.

Facilitate team collaboration
CIOs and CMOs may make the big decisions but it’s their respective team members that do the work. Therefore, the IT and marketing teams must learn to work together as well. As leaders, CIOs and CMOs must create opportunities for collaboration between the two departments such as holding regular co-department meetings, creating joint projects or inter-department workflows, or hosting joint brainstorming sessions.

The digital revolution is changing the way the business does business and it’s impacting every department – not just IT. But in many companies, it’s the marketing departments that are pioneering the use of emerging technologies to lead a company’s digital efforts. For CIOs and CMOs to be the all-star players the company needs, they need to work together and learn from one another.

Share twitterlinkedinmail

The Ultimate Guide to Measuring IT Success in the Digital Age

Share twitterlinkedinmail

You’ve probably heard the old adage that “you can’t manage what you don’t measure.” While the saying is technically true, it can be misconstrued, especially in IT.

IT has no shortage of measurable tasks. Most IT organizations have been using the same metrics for decades. KPIs like cost per ticket, ticket close time, user self-service completion rate and technician resolution are popular metrics that many CIOs use to determine the success of their IT organization.

But do those rates tell the real story of what’s happening in IT? I’m going to argue that they do not. In order to succeed in the digital age, CIOs must identify new ways to measure success.

The Problem with the “Old Way”

IT is no longer just a support team. Now IT plays a critical role in delivering services to end-users (read “customers of the business”) and can be a driver of business growth within the organization.
Old metrics simply will not measure success in the digital world. Look at the examples of common IT metrics that I listed above: cost per ticket, ticket close time, user self-service completion rate and technician resolution. These are not bad metrics and there is value in measuring them but they certainly don’t give a holistic view of how IT is contributing to the business.

An IT organization could hit every one of those example metrics but still be seen as a cost center instead of a contributor.
While CIOs understand the importance of these metrics, business leaders like the CEO and the CFO may not understand the importance of them. It’s the CIO’s job to use these metrics to point to the bigger picture and demonstrate how those metrics increase business value.

IT metrics need to also tell the whole story, from historical data and into the future. Business leaders should be able to look at IT metrics and understand where the organization has been and what direction it must take to move forward.

Metrics in the Age of Digital Transformation

Metrics in the age of digital transformation can be summed up in one sentence:

Metrics should connect to end-users and the business.

This appears to be a struggle for many organizations. A Gartner study found that only 31% of organizations have IT metrics in place to improve business operations.

If you cannot connect a metric to the end-user, you will struggle to demonstrate business value. This often requires the CIO to take a step back and look at the bigger picture of the business so that they have an understanding of the entire business model.

Metrics should also lead to definable actions – and those actions may touch several different areas of the business. This is important to note because it is going to move IT organizations away from having a silo mentality. IT touches almost every part of the business. CIOs need to collaborate with other areas of the business to determine where IT plays a role and how IT can provide the necessary resources to produce results.

Once you begin working with other parts of the business to identify where IT drives business value, you can then begin to build actionable process and systems and identifying key metrics for success within each one.

The Future of Measuring IT Success

IT metrics shouldn’t just measure technology performance. They should:

  • Track and trend performance over time
  • Diagnose and understand the underlying drivers of performance gaps
  • Prescribe actions to improve performance
  • Establish performance goals for both technicians and IT support overall

Every organization will have unique metrics but there are some starting points you can use to determine your initial metrics to ensure you’re properly measuring IT success in the digital age.

1. Cost and revenue indicators

Digital transformation is changing operational costs and customer acquisition costs. As technology evolves, pay attention to where those costs are, what can potentially be reduced, and where new business models or revenue streams are generated through leveraging technology.

2. Utilization

IT is often seen as a cost center because of the constant need for tools and technology. It’s important to measure utilization of these different tools and the impact of IT tools on business goals.

3. User experience

Are the other employees in the organization engaged with the tools and processes you have made available to them? What is the general level of productivity and business efficiency in the organization? If the users are enjoying a seamless experience and are able to identify productivity in their jobs because of the tools, technology and processes you have defined then you are able to IT’s role in business growth.

4. Customer experience

Finally, in the digital age, IT has a critically important role in providing the overall customer experience. IT can support the business in projects that improve the customer experience. CIOs need to inquire on how each project they play a role is impacting or enabling the right customer experience.

Pay attention to these four areas as you address new projects. If you begin to align your projects to support these areas, you will be able to identify relevant metrics that align with business success.

The Future is Here

The future of IT is already here. The bots have arrived, customer’s expectations have shifted, and the way we work has changed. So it’s time for your measures of success to do the same. If you are leading an IT organization, work with your peers to take a holistic view of business so you can begin to shift your IT metrics to reflect the success of the organization.

Share twitterlinkedinmail

Damn, I Made a Mistake

Share twitterlinkedinmail

 

Buckle up, friends, because this is the one where I share some truths.

I’ve learned many things in my years as a business owner and consultant but a few months ago, I had one of the biggest lightbulb moments of my career.

I made a huge mistake and it was costing me business.

I’ll avoid getting into the nitty-gritty of this mistake but it simply came down to this: I wasn’t listening to my audience and I was basing many of my offers and marketing choices on assumptions about my clients, rather than hard facts gathered by listening to them.

I think for many leaders and consultants, you get to a point in your career where you feel that you’ve seen it all. You learn to trust your instincts and in many ways, this is a good thing. But there comes a point where you start listening to your gut instincts over the voices of those around you. This is where you can start to cost yourself. If you work for yourself, you could be costing yourself business or if you’re part of an organization, you could lose the loyalty of your team and your rightful seat at the table with the C-Suite.

I believe as leaders it’s important to self-reflect on a consistent basis, even when you are moving quickly and chasing big goals. As I reflect on my missteps, I wanted to share three key points that helped me correct my mistakes and will hopefully help you avoid them!

Listen to others

Whether you’re like me and are a consultant, or you’re trying to manage a team and please a C-Suite, listening is a core component of leadership. However, listening is not always easy. You will hear things you don’t want to hear and think, “Well they’re wrong and I’m right so I’m not going to listen to their views.”

Differing views and conflicting opinions are part of business. Modern leaders want the best for their organizations and it’s normal to believe your views are the best. But the next time you hear a conflicting viewpoint and your urge is to “Shutdown and ignore,” I urge you to stop and ask a simple question in return: “Interesting viewpoint. I’d love to dig in on why you feel this way.”

The goal is not to shut down, it’s not to agree and it’s not to give up. It’s simply to dig in for more information. With an open mind and the right questions, you are creating space to find the solution.

Question your assumptions

While you’re working to understand why your team and colleagues feel a certain way, it pays to do the same for your ideas and viewpoints as well.

Questioning your assumptions is a powerplay for every leader.

The IT world changes at lightning-fast speeds. The trends of 6 months ago are now commonplace and the hot new technology of last year has already started being replaced.

In an industry where everything is evolving, your assumptions and beliefs should too. When was the last time you tested an age-old assumption or asked a clarifying question about a process, service or piece of technology to determine if it’s still working?

When you question your assumption, you are creating opportunities for continuous improvement, a hallmark of the modern IT organization.

Commit to learning

Leaders are always learning. This is probably not news to you but I challenge you to view this last point as more than keeping up on the latest trends or reading the latest news every morning. Instead, I encourage you to continue learning about your organization, the end users and your team.

Much like I had to learn more about my clients and their current needs, IT leaders should learn about the other departments, their end users, and, of course, the needs and desires of their own internal IT team just as much as they need to understand the latest piece of software.

This is also a fantastic area for you to encourage your deputies and other members of your team to practice, as well. Every member of your team can learn more about their end users and it will elevate the overall IT organization.

Part of the objectives of a modern IT department is to make an easier, faster and more streamlined experience for users. When was the last time you learned about the needs of a user from the actual user (and not from data or assumptions)?

Leaders make more mistakes than many of us realize. Course correcting along the way is part of leadership and success. We have a little less than half of 2019 left in front of us and this is a fantastic opportunity to look back on this year and ask yourself where you’re not listening, what assumptions your making, and how much you’ve learned so far this year.

I can tell you from experience that while it’s a humbling practice, the outcome of it can lead to more opportunities than you could have experienced otherwise.

Want more? I share more pragmatic leadership advice in my bi-monthly newsletter. Sign up here.

Share twitterlinkedinmail

Enterprise Service Management or Enterprise Silo Management?

Share twitterlinkedinmail

Kelly orders chocolates through her favorite confectioner’s digital storefront from the comfort of her living room. Kelly makes her selection, enters her credit card and shipping information, and presses the “order now” button. Within seconds, she receives an on-screen message from the confectioner, thanking her for her order, and informing her that she’ll have her chocolates the next day.

At the confectioner, Kelly’s request is first processed by the Order Entry Department, who confirms her information and charges the sale to her credit card. Order Entry then creates a sales order, which is sent to the Fulfillment Department. Fulfillment selects the chocolates from inventory and updates the inventory management system with the change. Fulfillment then packages Kelly’s selections and sends the package to the Shipping Department for overnight delivery.

All of this behind-the-scenes activity happened without any involvement from Kelly – other than her single interaction to order the chocolates.

Are your customers enjoying a differentiated experience interacting with your company’s digital storefront?

Are the customer’s interactions seamless and friction-free?

Do materials and information flow smoothly through the organization?

If you’re not able to answer ‘yes’ to the above questions, then you have some compelling reasons to implement enterprise service management (ESM).

Some Popular Approaches to ESM

Many ESM approaches consist of extending the use of the IT service management tool into other areas of an organization, such as Facilities or Human Resources. This is a popular approach that often results in cost optimization of the IT service management tool by using that tool outside of the IT organization.

In a lot of ways, this is a reasonable thing to do. Whether it is a work order being completed by the facilities organization, or human resources on-boarding a new employee, using a tool that facilitates a consistent, repeatable approach to information capture and managing workflow just makes sense.

Another popular approach is establishing an enterprise service desk. Like an IT service desk, the enterprise service desk becomes a single-point of contact for internal employees to receive assistance with any request or issue. Employees benefit from having only a single point of contact for any organizational need or issue. The organization benefits by delivering a centralized approach for managing such contacts, rather than having each department having to individually staff such functions.

Implementing a self-service portal is also a popular approach for ESM. Employees can use a portal to find information or make requests without having to contact anyone. Issues such as requesting a replacement for a burned-out light bulb or updating voluntary benefits can be conveniently managed from an employee’s workplace.

But are any of these approaches really “enterprise service management”? Or are these examples of enterprise silo management?

What You’re Doing is Enterprise Silo Management

Extending the ITSM tool to other areas of the organization may improve the ROI of the tool. Establishing enterprise service desks may help centralize management of internal requests and issues. Implementing enterprise self-service portals can result in time savings for employees. It may even result in optimized departmental processes and workflows.

But if the goal of your ESM initiative is to only extend the use of IT’s service management tool into non-IT areas of the organization, what you’re doing is Enterprise Silo Management. You’re enabling (encouraging?) your organization to continue working as a collection of siloed departments.

While I would agree that optimizing departmental processes and workflows is a good thing to do, keep in mind that departmental optimization will deliver benefit…to only that department. It’s like speeding up one part of a conveyor belt but ignoring the big stack of boxes on either end. In fact, it’s really not speeding anything up – it is only exacerbating the symptoms of an organization whose interdepartmental workflows are not well integrated.

This is where these so-called approaches to ESM fall short. These approaches don’t enable or deliver a cross-departmental flow of information and work. There’s no end-to-end view of enterprise value streams. Requests or issues that (will) come up within the enterprise still requires the consumer (employee) to know what they need and what organization fulfills that need before they interact with the portal.

By following these approaches, your business will never realize the value of enterprise service management.

Why Your business Needs Enterprise Service Management

Organizations operating within a silo mentality, in which the departments within the organization are poorly connected with (or even isolated from) other parts of the organization, cannot react or respond as quickly as needed to changes in market spaces or business.

Think about it. There is no single part of an organization that can exist in complete independence from the other parts of the organization. The best business value is created when all parts of the business are contributing and collaborating to deliver value in the most effective and efficient way.

And in the digital age, having the ability to quickly shift and react to changes in market spaces is critical for business success.

This is why your business needs ESM – Enterprise Service Management.

Good ESM:

  • Provides business decision support – Good ESM provides transparency into how work is done within the organization. Decisions become data-driven, based on objectives measures captured as part of enterprise value streams.
  • Enables organizational agility – Well defined, interdepartmental workflows enable organizational agility because there is clarity and shared understanding regarding workflows. This helps leaders understand where to pivot if needed. Good ESM results in improved cohesiveness and collaboration within the organization and aligns activities toward shared organizational goals, not on departmental objectives.
  • Improves organizational understanding of the business – Individual departments not only understand their workflows and processes, but also how information, work, and value flow across the organization. There is a greater awareness of the interdependencies between the various departments within the organization.
  • Enables an enhanced customer experience – Good ESM removes the internal friction that gets in the way of a good customer experience.

Moving to Enterprise Service Management

Here are some tips to help you move from Enterprise Silo Management to Enterprise Service Management.

1. Strong leadership is required 
To have success with ESM, the focus must shift from achieving departmental objectives to enterprise goals. Silo mentality must be eliminated from the organization.

2. Teach employees the business of the business 
Many employees today are unaware of how the business operates outside of their own area or department. Having a good understanding of how the business does business helps with ESM implementation and enables improved employee productivity.

3. Map the enterprise value streams
No single part of an organization is independent of the rest of the organization; it takes all parts of an organization to deliver value to its customers.  Mapping value streams at the enterprise levels helps the organization visualize how work and value flows through the organization and to the customer.

4. Define or lean out processes
For each value stream, form a cross-departmental team to define any needed supporting processes. If processes are defined, review those processes to ensure that they are as lean and waste-free as possible.

5. Iterate
Don’t try to instantiate all your enterprise value streams within your service management tool at the same time. Rather, start with a single enterprise value stream, capture any learnings, and then apply those learning to the next value stream-to-tool implementation. (By the way, this approach should be the “new normal” for maintaining your ESM implementation.)

So, should organizations optimize at the departmental level or at the enterprise level? The fact is that to be successful in the digital age, organizations must do both. Doing one without the other only results in internal friction and waste.

Following the above tips will get you on the right path for good ESM that also results in optimized departmental and enterprise work streams.

Share twitterlinkedinmail

The Number One Reason IT Is Unappreciated (and how to change it)

Share twitterlinkedinmail

There’s a quiet mumbling that occurs in every IT organization across the world. You can only hear if you listen very carefully. It’s the quiet sounds of IT organizations feeling underappreciated.

The C-Suite and many parts of the organization don’t fully understand what IT does so they pile on projects and hold off on praise. The IT team members get frustrated with their workloads and the thankless nature of the job. If you’re an IT leader, then you have seen this from both sides.

You know that most of the organization sees IT only as a support team and IT feels like they are an order taker. When other departments have unrealistic needs or timelines and IT pushes back, they are seen as resisters who are blocking productivity.

The truth is, many people in the organization don’t understand the complexities of IT and IT team members are so overwhelmed with work that they can’t take the time to explain to other departments how they are contributing to the business.

There is one person in every organization who can help IT feel more appreciated: the IT leader.

IT Is unappreciated because IT can’t clearly communicate its wins and how those wins contribute to the business. The responsibility of communicating these wins falls onto the IT leader.

Let’s take a look at what every IT leader can do to help their team feel more appreciated.

1. Claiming IT wins

Most organizations don’t pay any attention to the IT department until something is falling apart. But IT leaders can help spotlight their teams by sharing wins and updates from their department.

This can be easily done with a regular IT update, either monthly or weekly. Send this to the C-suite or to other leaders in the organization. You may stop me right there and say “Well Doug, I already do that and no one seems to care.” So I’m going to ask you how you framed these wins?

Because, unfortunately, it’s not enough to just share your team’s wins. Unlike the sales department, IT wins don’t always directly relate to revenue. The C-Suite may not understand how improving service desk response times connects to business goals.

As the IT leader, you must be willing to learn to connect each of your team’s wins to the organization’s business goals.

Most people don’t really care what you do unless it affects them. This isn’t just in business. This applies to everything in life. Think of it this way. If you live in Indiana, you may not care about a thunderstorm in Miami. But you will care if you have a flight booked to Miami and that thunderstorm is delaying your vacation.

As the leader, you need to show your organization how that thunderstorm in Miami is affecting someone in Indiana.

How does IT impact the rest of the organization’s ability to do their jobs and hit their goals? This is the question you must regularly ask yourself when you are reviewing projects and strategies.

When you view your team’s wins or accomplishments through the scope of the rest of the organization, you can better communicate them to others so that they care about those wins. This brings me to our next point.

2. Speak business language

In this digital day and age, it is required for IT projects to link to business outcomes and value. Most IT leaders use technology terms that business leaders don’t understand and really, don’t care about. IT often communicates backward. IT loves technology and features and think others do as well. But most others in the organization will only care about the benefits and outcomes of using the technology. The function of technology is not the value. The features are not the outcomes. It’s necessary to focus on the outcomes of every project.

Be willing to look at the data of projects from start to finish. Many organizations justify IT projects by citing anticipated revenue increases or advances in customer satisfaction but many are unable to track these successes after the project is completed. Work with other departments to understand how your IT work contributed to their win.

As an exercise, we recommend dividing a piece of paper into three columns. Label the columns features, benefits and outcomes. Then under each project, service or product, break down them down into each category. You’ll be able to develop value-driven messaging when you view your projects through this lens.

3. Get over the fear of self-promotion

Many leaders struggle with self-promotion but it runs rampant in IT. There is no easy way to release this fear other than to recognize that if you cannot clearly explain how your team is winning, no one else will be able to either.

As a leader, when you self-promote, you are doing so for the benefit of your team members. It’s not bragging or selfish. It’s improving your department and it can improve the entire organization.

When your organization works well. the entire organization runs better. Not only that but when you claim your wins, the organization feels more confident in their own wins and can own them as well. 

If promoting your department truly isn’t for you, there is another option. Many organizations have started hiring IT communications specialists to help market the IT department internally. If you don’t have the budget for it, you may want to enlist help from your marketing department to learn how to better market IT.

4. Be visible

A frequent mistake made by IT leaders is they feel they are too busy to participate in interdepartmental meetings.

While it is tempting to choose to do the work over promoting the work, no one will ever know what you and your team is doing if you are too busy to attend the meetings. No one will know what you’re doing if you’re too busy to attend meetings.

If you want a seat at the table, it’s important to act like you want a seat at the table. Of course, you may point out that you don’t get invited to the high-level meetings. Well, if they don’t give you a seat at the table, you can make one.

Connect with other department leads, form alliances when necessary and support other departments in their goals. These other leaders can help act as a champion for IT when you are unavailable.

If you absolutely cannot be visible and have no choice but to remain in your own department, I recommend being active on emails and quick to respond to voicemails.

5. Training your team to do the same

Finally, it’s important that every IT leader teaches their team to communicate their wins and share the business value of IT. Your team can act as IT department evangelists if you empower them to repeat these steps at their level.

When you talk about your services to your team, identify them in terms of business value and outcomes. Encourage your team to share their wins in your team meetings and ask them about the business value of their wins so that they have a better understanding of how to explain their projects.

How can good SM help IT become appreciated?

1. Defining IT services in terms of business value and outcomes. 

Define and describe the business value and results that your business colleagues get from doing their IT business with you. Remember that PCs and smartphones can be obtained anywhere so you need a case for why they need to go through the IT organization. Create a service portfolio that establishes an understanding of how the business is using technology solutions from IT and how that technology contributes to the business outcome

2. Implementing processes that facilitate, not control, getting work done.

Don’t allow your process to kill your productivity. Too many processes are designed and implemented with “control” in mind. Good process design should enable, not constrain, getting things done. Work with your team to evaluate your processes and measure if they are the most effective way to get the work done.

3. Formalize the business relationship management approach.

Business relationship management focuses on the relationship between the IT organization and the business it serves, as well as the level of satisfaction with IT. Proactively building positive, business-like relationship with key stakeholders helps change the perception of IT from “order taker” to “business differentiator”. 

As much as we don’t want to admit it, there’s politics at play in every organization. IT leaders can hide behind their computers and stay overwhelmed or they can learn to step out and own their team’s wins and communicate their teams’ value.

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

Let’s Stop Playing “Service Provider” and “Customer”

Share twitterlinkedinmail

The concept – at a high level –  wasn’t all bad.

The concept was that IT organizations should adopt a service-oriented mindset when it comes to working within the business.  The attitude of the IT organization must shift from “technology is cool” to “what’s best for our business”.

So best practice advised IT to become a “service provider” to the “customers” found within the business.

But in practice, IT taking on the role of “service provider” and treating business colleagues as “customers” sends the wrong message to the business – and within IT.

It’s the wrong message

When IT treats colleagues as “customers”, and colleagues view IT as a “service provider”, it puts up barriers with an organization.  Not only does it artificially separate the IT organization from the rest of the business, it makes working with the IT organization needlessly more difficult.  Under the mantra of “the customer is always right”, IT often jumps through unnecessary hoops to make the “customer” happy.  Being referred to as a “customer” gives some colleagues a sense of entitlement in their interactions with IT.  Some within the business make and have unrealistic expectations of the IT organization.

Perhaps even worse, the service provider / customer definition divides the IT organization.  The development team makes demands of the operation team.  The security team makes demands of the development and operations teams.  Demands all issued under the guise of “I am your customer – serve me”.

We’re really not service providers.  They really aren’t customers.

If IT was really a service provider, it would find itself competing in an open market place within a business.  IT would have the ability to (really) sell its services at market rates, scale as needed, and invest in new and emerging technology as it deemed fit. But that is not the reality of enterprise IT.  IT has a budget that has been allocated and agreed within the business to which IT must adhere.  This means is that IT really cannot scale resources or significantly alter or add services without agreement and funding from the business it serves.

If “the business” was truly the customer, they could shop for IT services, both from within and external to the business.  “The business” could contract with whatever service provider it chose and not be concerned with interoperability, security, maintainability, and every other -ability with which enterprise IT must be concerned.  But in reality, “the business” is (mostly) a captive user of its organization’s IT services.

IT is not a “service provider”.

The “customer” is not an internal group or person.

So, what are we?

What we are is a business.

A business is an organization aligned by purpose, vision, and goals, with each member working for the benefit of the organization and for the success of all other members of the same organization.   It takes all parts of the business – HR, Marketing, Sales, Manufacturing, IT – for a business to have success.  No single part of a business can stand on its own and be successful without interactions with and cooperation from the other parts.

By working as an integrated entity, a business has unlimited potential.  But what a business does not have is unlimited resources.  And when a business loses sight of the fact that it does not have unlimited resources, it often looks like this:

  • Multiple “number 1” priorities

o   But no additional staff is allocated to help

o   And no postponement or cancellation of other initiatives

  • Lack of investment in “keeping the lights on” – not doing the “care-and-feeding” needed to maintain current operations
  • Quality is often sacrificed to meet target dates

And then, IT often becomes an obstacle for getting something done.

Then in an effort to keep up (or dig its way out), IT overcommits and takes on additional work without fully understanding the demand or impact on its (limited) resources.  And when IT can’t deliver, then IT is looked at as being too slow to respond or react to business needs or changes in the business environment.   IT becomes the “black hole” where business innovations go to disappear.

But here’s the conundrum.

Business – by definition – is an opportunistic endeavor.  Success in business means being in the right place at the right time with the right solution.

But to be in the right place and the right time with the right solution means that a business – including its IT capability- must be prepared.

Become opportunistic – holistically

To be opportunistic means that a business must be prepared.  Because when an opportunity does come along, the business has to be able to make a decision based on the best information available.  But too often, business decisions are made based on “gut feel” or seeing only part of the big picture.

And especially in the digital age, technology – managed by the IT organization – is critical for business success.  Here are four things to do to get prepared.

  • Drop the “service provider / customer” speak. All members of the business are on the same team – there can be no “us” and “them” within an organization.  And to be clear, the customer is not part of the organization.  The customer is who a business is trying to entice to do business with the business. The business is the service provider to the customer.  Stop referring to internal resources as “service provider” and “customer”.
  • Define the service portfolio. A service portfolio articulates and establishes a shared understanding about how the business is using and is planning to use technology-based solutions from IT.  But more than that, the service portfolio provides a holistic view of resource commitments, current and future value, and the total cost of ownership for providing those technology-based solutions-all in terms of business outcomes.
  • Map the value streams of the business. Mapping value streams facilitates visualization of how information and material flow throw an organization to create or deliver value to a customer.  A value stream map helps help “connect the dots” regarding how the various parts of an organization (including IT) work together to deliver that value.
  • Share knowledge – all knowledge. Being prepared to seize opportunities depends on having available, timely, accurate, and relevant knowledge from all parts of the organization, throughout the organization. Knowledge is the basis for good decision-making.

How does doing these four things help?  It’s about being prepared to make a timely and informed decision when opportunity knocks.  A business that does these four things not only understands what it is doing today, but also has the needed insight into how its capabilities could be leveraged when presented with an opportunity.

It’s time for another mindset shift

The service provider / customer concept may have been a good way to start the mindset shift that many IT organizations needed.  It’s now time for IT organizations and businesses to stop playing service provider and customer.  The business landscape is rapidly changing, and technology is becoming the cornerstone of a business in the digital economy.  Being prepared is the best way to take advantage of the opportunities presented in the digital economy.

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

Photo credit: Pexels

Share twitterlinkedinmail

5 ways DevOps thinking can cure “Bad ITSM”

Share twitterlinkedinmail

The ITSM highway is littered with implementation efforts that failed to achieve their potential.

ITSM, done well, has proven to be great for business. Unfortunately, for many businesses, implementation efforts resulted in “bad ITSM”.

Many of these ITSM implementations were initiated by the IT operations team, and perhaps had some early successes managing incidents and service requests. But many of these implementations were too focused on tool implementations that didn’t quite hit the mark or process engineering efforts that resulted in unjustified bureaucracy.

IT Operations then tried to push ITSM onto the other parts of IT, with limited (if any) success. ITSM became the bottleneck rather than the enabler.

Can some DevOps thinking be the cure for “bad ITSM”?

What is DevOps?

First, let’s get clear on what DevOps actually is. The key objective of DevOps is getting the development and operations teams working better together. But what is “DevOps”?

The DevOps Handbook[1] defines it as “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”. DevOps is best thought of as “CALMS”[2] , a conceptual framework for integrating development and operations teams. 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
  • Measurement – Data is collected on everything, with mechanisms for providing visibility into all systems
  • Sharing – User friendly channels for facilitating ongoing communications between development and operations

If CALMS is the foundation of DevOps, can CALMS be a way forward for ITSM?

How DevOps and ITSM are often described

Many ITSM implementations fell short because ITSM was viewed only as something done only by IT operations. In many cases, this perception was deserved because no one outside of IT operations was involved in the implementation.   ITSM was too focused on stability and “status quo”.  As a result, ITSM became a barrier, rather than a way for the operations and development teams to better collaborate.

A recent article[3] described the relationship between development and ITSM as represented in the diagram below:

 

 

 

 

 

The article focuses on the relationship between software engineering and the “IT help desk” (implying that ITSM is just the “help desk”). The article suggested ways to integrate the ITSM and engineering teams, such as providing some method for the “IT help desk” to provide enhancement requests to the engineering team.  Engineering should provide estimates to the help desk regarding planned releases, rather than include the help desk in those planning discussions.  If a help desk representative needs to talk to an engineer about a defect, the representative should not only track such defects in the ITSM tool, but also in the engineering tool….and let engineering know which defect it is within the engineering tool.

Well, doesn’t this sound familiar?

Doesn’t this sound just like the IT operations-centric approach to ITSM, but in reverse?  ITSM is seen as something being done in addition to software development.  Operations must jump through some hoops to talk to the development team.

When does the security team get involved?  Or the QA team?

Isn’t this just perpetuating the so-called “wall of confusion” between the parts of the IT organization?

Isn’t ITSM really this?

For whatever reason, there seems to be this irresistible tendency of looking at IT as a collection of parts:

  • Security – ensures the integrity and confidentiality of data assets; protect data assets from threat or harm
  • QA – provides cost justifiable quality and compliance with regulatory and other requirements
  • Operations – delivers stable, reliable, and consistent IT services
  • Development – encodes and delivers applications and software that solve business challenges

The fact is that it takes all parts of the IT organization – security, QA, operations, and development – working together to deliver viable and valuable services for the business.  No single part of IT can deliver business solutions by itself.

We must stop looking at IT – and therefore ITSM – as a collection of parts.  Shouldn’t we really think of ITSM like this?

 

 

 

 

 

ITSM should be a means of delivering valuable outcomes that businesses require from the use of technology.  It should be Strategy-Design-Transition-Operations as a single, frictionless flow, not a series of gates.  ITSM should be a way to collaboratively align the IT organization to meet shared goals and objectives. ITSM should be about continual improvement, finding ways for the business to improve how it does business, leveraging technology.

If your ITSM isn’t quite where it should be, DevOps can help.

5 ways DevOps thinking can cure “Bad ITSM”

Somehow, ITSM lost its way in many organizations.  But DevOps adoption doesn’t mean that you throw out all of the ITSM work you’ve done – you’re still going to need processes, you still must define services.  Having said that, DevOps can provide a means for organizations to hit the “reset” button on their “bad ITSM” implementations.

Here are five ways that DevOps thinking can cure a “Bad ITSM” implementation:

  • Change the Culture – Like ITSM, success with DevOps starts with cultural change. Cultural change must start from the senior management level and permeate through the organization.  What does this cultural change look like?   Leaders do not allow teams to form siloes.  When errors are found, the team stops work and fixes them, rather than trying to hide the issue or pass the error down the line.  An attitude of collaboration and shared responsibility between development, operations, security, and quality exists from the beginning.  Embed a “DevOps” culture in your ITSM implementation.
  • Drive to automate – Automation first requires effective, well-designed processes.  A symptom of many bad ITSM implementations are processes that are bloated, overly-engineered, and bureaucratic.  Take a DevOps approach and define, simplify, then automate processes. Automation will result in ITSM that is much more effective and efficient.  The more automation, the more responsive the IT organization can be to changes in business needs.
  • Work iteratively – ITSM implementations often suffer from “waterfall-ish” approaches. Take a DevOps approach and work iteratively with process designs, improvements, and solution delivery.  Shift from a “big bang” approach to delivering value in smaller, more manageable and predicable increments – then develop and implement those increments more frequently.  This means smaller release packages or smaller changes, but in return, business realizes value from technology use more quickly.
  • Standardize infrastructure configurations – Both DevOps and ITSM concepts are “technology agnostic”. Having said that, using technology in the best way makes utilizing DevOps and ITSM concepts much easier.  Take a page from DevOps and standardize infrastructure configurations. Define and use a standardized approach to provisioning infrastructure[4] – servers, storage, operating systems, and networks.  The same infrastructure configuration is then used across all environments – development, test, UAT, and production – simplifying testing and validation and improving reliability by removing any variation between environments.  An evolutionary next step would be Infrastructure as Code – which could be codified as a “standard change”!
  • Develop and document test scripts, then continually test – A key DevOps concept is automated testing. This approach allows testing to be done at any point along the development cycle.  Applying this concept to ITSM, develop standardized test and validation scripts and execute those scripts as part of any change, release, or deployment.  Not only will this improve service reliability and confidence in implementing changes, but it can become the foundation for automated testing, and allows for deployments to be decoupled from releases – another key DevOps concept.

DevOps can help organizations realize the promise of ITSM

If your organization is suffering from “bad ITSM”, adopting and adapting these DevOps concepts can help.  But “bad ITSM” cannot be cured overnight, so “start smart”.  Think evolution, not revolution – perhaps start with a service or a process that isn’t performing as needed.  Implement some of these concepts, be willing to experiment and learn, and watch ITSM improve!

 Is your organization suffering from “bad ITSM”? Invite Tedder Consulting to work with you to apply some “Next Generation ITSM” thinking and get back on track!  Contact Tedder Consulting today! 

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

Picture credit: Pexels.com

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

[2] http://whatis.techtarget.com/definition/CALMS

[3] https://devops.com/bridging-gap-itsm-software-engineering/

[4] “Infrastructure as a Service”?

 

Share twitterlinkedinmail