Tag Archives: culture

Are Processes Killing Your Productivity?

Share twitterlinkedinmail

Every IT organization knows that good processes are critical to the success of a company. The right processes can improve efficiency and create an organized workflow. However,when taken to the extreme, processes can kill productivity and ruin your team’s morale.

Let’s take a step back and talk about processes and why they matter.

Processes are a defined sequence of tasks that keep the organization running smoothly. Processes provide organizations with a way to measure progress and productivity, which can help a team feel more efficient and accountable for their work. Standard processes create a consistency of work and provide a foundation for continuous improvement. Lastly, defined processes enable automation, which helps IT become more responsive to business demands.

So we can all agree that processes are a good thing in business. Except for they when they get in the way or go out of control. Many studies are showing that processes are beginning to hinder productivity across the globe.

In a study of U.S. and European companies, The Boston Consulting Group found that “over the past fifteen years, the amount of procedures, vertical layers, interface structures, coordination bodies, and decision approvals needed…has increased by anywhere from 50 percent to 350 percent.”

The same report found that in larger and more complicated organizations, managers “spend 40 percent of their time writing reports and 30 percent to 60 percent of their time coordinating  meetings.”

This does not leave much time to actually accomplish the work that needs to be done.

How can you tell if your process is working or if it is killing your productivity? There are a few ways you can test your processes.

1. Does the process accommodate all projects?

Processes cannot take a narrowly-defined, “one size fits all” approach. l. As an IT organization, your team is most likely handling a wide variety of projects. Your processes have to accommodate the variety of projects while at the same time providing needed consistency.   

Agility is just as important as having a standard process. Today, new technologies are coming to market at lightning fast speeds.Businesses are adopting technologies quickly and demanding that the IT department keep up with supporting these new technologies.

IT needs to be able to react quickly to these needs. If a process was not designed for agility or to accommodate the variablity found within a specific project, IT cannot react quickly. When you insist the process stay exactly the same for every project, you are asking your employees to try to sprint while attached to a ball and chain.

Too many organizations fall into the “process for process sake” mindset. They insist on maintaining every aspect of a process for every project, even when it doesn’t make sense.

If you find that your process has worked really well for some projects but did not work well for other projects, we recommend examining where the process stopped working. Take a look at the areas where flexibilty or a different approach is needed. Don’t lose sight of the end-goal for the process and the goals of the projects.

2. Are you focusing more on the process than the people?

No matter what innovative technology exists, it’s the people who make your business run, not the technology. Process should enable people to take advantage of the technology, not inhibit the use of technology.

When leaders focus too much on the process and ignore the needs of their team, the team doesn’t feel empowered to do their job effectively.

It’s not empowering when individuals are given more responsibility yet still have to obtain a large number of approvals and sign-offs to get anything done. This signals a lack of trust to your team.

Leaders need to start relying on their team’s expertise and experience just as much as they rely on the process. When you start to do this, you can often improve your processes because your team feels empowered to do so.

It’s critical to empower with action, not with permission. When your team is empowered to take action to get the job done, they feel a greater sense of pride in their work, are more invested in the project and more appreciated by their bosses.

When jobs depend on meeting metrics or process approvals, the creativity and innovation of teams suffer. The last thing you want is a team who can’t – or won’t – find ways to innovate and improve.

3. Are you relying on tools too much?

We’ve seen it time and time again. Organizations invest in a very pricey tool. They implement it one way and create a process around it and then they try to force that tool and process onto every problem that arises in the business.

Tools are fantastic but they are not problem solvers. People are problem solvers and your tools and processes should be built around the people and the problem that needs to be solved.

Processes built around tools are doomed to fail but processes built around problems and supported by employee action will always work.

4. Do you have process silos?

Organizations that are siloed will always struggle with processes. For example, what happens when IT has a process for onboarding a new employee and HR has their own process for onboarding and they are completely separate? Undoubtedly, it causes unnecessary extra work and possibly, some confusion for the new member who is being onboarded.

This is where cross-departmental communication and collaboration must come into play. Linking processes across departments and achieving buy-in from team members in both departments will avoid wasted time and energy.

Again, this will rely on your process being agile (see the first point) as you may need to adjust several of your processes to become cross-functional with other departments.

Work with other department leaders to understand their processes and determine how you can combine the two into cross-functional processes. Then clearly define and document these processes so that there is no confusion across teams.

5. Have you avoided process audits?

If you’ve learned anything from this article, we hope you’ve learned that processes are ever-evolving. They are constantly shifting to adapt to the growth of the organization and the specific project at hand.

So it’s necessary to perform regular process audits to ensure your processes are working to the best of their ability and improving the productivity output of your team.

How do you perform a process audit? It’s best to start by looking for any drops in productivity during the process or where output slows down. Additionally, monitor for signs of unhappy teams. Do you see resistance from the team at any certain stage?

Look at your processes and determine if any piece of it does not add value. If you’re unsure, speak with your team on this. Since they are using the processes, they will know what are the most valuable and impactful parts of it.

Let’s be clear on one thing: I am an extremely big fan of having documented, well-defined processes in your organization.

But I want to encourage you as the business leader to always be monitoring processes and keeping your eyes on the end goal and the people implementing and using the processes.

Focus on people and improving communication and innovation so that you can solve business problems. The process will fit naturally and be more powerful when they are viewed as the means to a goal and not the goal itself.

Share twitterlinkedinmail

Why ITIL Doesn’t Work For Your Business

Share twitterlinkedinmail

There are two camps of people in the IT world: those that will explain the benefits of ITIL all day long and those that find ITIL doesn’t work and think it’s a bureaucratic waste of time.

But upon further investigation, we’ve realized something. It’s possible so many people dislike ITIL because organizations aren’t really implementing ITIL.

Or excuse me, they’re not implementing “IT Service Management based on ITIL.” Whatever you want to call it, people approach the use of this framework wrong and it costs them a lot.

Let’s talk about why ITIL won’t work for your business.

When ITIL Doesn’t Work

1. You treat ITIL as gospel.

ITIL isn’t a cookbook. It’s not the gospel. It’s guidance and a framework of best practices. But what happens in certain organizations is that some manager on some level gets really excited about the idea of ITIL and then tries to implement every guideline in the book. This approach will never work!

ITIL was originally created by the British government’s Central Computer and Telecommunications agency in the 1980s. It was never meant to become a proprietary product that would be commercialized and sold. The original project was supposed to gather best practices to assist with what the government saw as increasing dependence on IT combined with a lack of standard practices that resulted in increased costs and errors.

ITIL spread to private corporations because it works. But not in the way many organizations think it does.

ITIL works because it includes best practices but it’s just a framework. It doesn’t have to be followed step by step.

The best way to get ITIL to work in your business is to adopt the guidelines and practices that make sense for your business and forget the rest.

2. You ignore the business case or business inclusion.

ITIL and ITSM have “IT” in their titles but that does not mean they are purely “IT initiatives.”

IT can’t work in a silo anymore and implementing ITSM based on ITIL without getting buy-in from anyone in executive management or anyone outside of the IT is a recipe for disaster. You have to understand how IT interacts with the rest of the business. Consider what the business needs from IT to be successful and IT’s capability for delivering on those needs, and how ITSM can help

If you want to utilize ITIL successfully, learn how to explain it in a way that senior leaders understand. They won’t speak in ITIL jargon, so you have to recognize how it can benefit the business and be able to articulate that – in business terms. If you are able to do so successfully, you will get support and investment from senior leaders.

Including business objectives and understanding the business value of IT will help your team and your organization to adopt ITIL so that it helps to facilitate business outcomes, which is the goal!

3. You don’t create a roadmap for adopting and adapting ITIL.

ITSM and ITIL are not about implementing processes for process sake. Too many organizations get so focused on implementing processes that they ignore the overall goal for why they needed those processes.

The goal is to deliver services that provide value for the business.

Creating a roadmap and connecting it to business value will help you adopt the right ITIL practices so that it supports the services and doesn’t just implement processes for the sake of implementing processes.

If you’re too rigid and you try to implement everything all at once for no real reason other than you think you should, your team will resist. That’s why so many IT professionals think ITIL is too bureaucratic.

But if you haphazardly throw certain approaches into certain projects, then no one will be able to recognize how ITIL is improving your workflow.

A step by step roadmap gives you something to measure against as you move forward with adapting ITIL.

4. You don’t invest in training or consulting

There are many ITIL Foundation training classes and many IT professionals receive their ITIL certification. But those classes often fail their students –  many students become ITIL certified professionals but have absolutely no idea how to apply any ITIL concepts.

The truth is, anyone can read a student guide and learn ITIL concepts but that isn’t going to get them or their organization very far. Like we’ve said, ITIL is guidance not gospel. You need to understand how it can impact and fit into your organization. The only way to do that is to invest in ITIL foundation class with an experienced instructor who can show students how to apply ITIL to their organization.

Similarly, many organizations make the mistake of adapting ITIL without any qualified, expert guidance. This can work for a little while but undoubtedly, whoever is leading the charge is going to become distracted with day-to-day operations. A qualified consultant acts a guide to plot a course to ITIL adoption. They can help avoid common mistakes and increase adoption speed.

5. Trying to find a short cut with a tool

If there are many training classes, there are even more tools designed to help adopt ITIL and ITSM into organizations.

But a tool isn’t going to understand the value of IT or how IT contributes to business outcomes. A tool is not going to be able to understand the needs of the business.

A tool is just what it’s described as, a device used to carry out a particular function. Tools can help you adopt ITIL but it certainly is not going to do all the work for you.

When Will ITIL Work For A Business?

There’s no really no such thing as ITIL implementation. You can only adopt and adapt ITIL to your organization. You can do this with a clear implementation roadmap, a well-formed business case for ITSM , and getting training from a good instructor.

If you want to adopt ITIL the right way and avoid wasting time, money and energy, then learn more about ITIL at our upcoming ITIL Foundation Class this October. Or contact us to learn about ITSM adoption and roadmap planning services.

Share twitterlinkedinmail

The Great Debate: Is DevOps a Role or a Method of Working?

Share twitterlinkedinmail

In a world that seems to debate everything, there is one debate in the IT world that seems to never end. Is DevOps a role or is it a method of working? There are many people in the industry asking what does DevOps mean?

The DevOps debate isn’t one that should go on forever though. Because the truth is, when it’s understood and applied correctly, DevOps can strengthen teams and increase productivity.

Let’s start by discussing what is DevOps and what it’s not.

What Does DevOps Mean?

We’ll get right to the point: DevOps is not a role and DevOps is more than a way of working together.

While it’s tough to define DevOps, we use an acronym to explain it. CALMS, was coined by Jez Humble, one of the co-authors of “The DevOps Handbook.” CALMS is a framework for integrating development and operational teams. In other words, creating DevOps teams.

CALMS stands for:

  • Culture
  • Automation
  • Lean
  • Measurement
  • Sharing

And yet, DevOps is more than the Dev team and the Ops team working together. I know, what you’re thinking. So it’s not a role and it’s not a way of working together; then what does DevOps mean?

True DevOps results in a cultural change that breaks down the functional silos between Dev and Ops teams. DevOps helps to create cross-disciplined teams that have end-to-end responsibility for delivering software with speed and agility.

It sounds great, right? And almost kind of easy, doesn’t it? You just get the Dev team and the Ops team to work together.

Except, it’s not that easy and organizations who approach DevOps with this type of attitude won’t be able to make it work for their organization.

How To Shift Towards DevOps

The shift to DevOps starts with a culture shift and in order for that culture shift to happen, you need buy-in from everyone. This is hard to do!  Whether we want to admit it or not, humans don’t like change. If teams have been working in one certain way, then they are going to resist changing that.

There are a few things you can do to help encourage the DevOps buy-in across the organization. The first thing to do is start at the top. The C-suite and management must buy into DevOps before anyone else. If even one member of the C-suite asks “why DevOps” and is resistant, then DevOps will likely fail.

After the C-suite is firmly on board and ready to implement this shift in your organization, you can start working on your teams.

  • Be inclusive with everyone on the team about the DevOps implementation plan.
    • The entire Dev and Ops teams must be included in these conversations about implementing DevOps. You want to start the practice of knowledge sharing across all teams. Knowledge sharing only works if management and leaders start sharing knowledge.
  • Align teams along product or service lines.
    • Many organizations struggle with this but in order for DevOps to be properly implemented, teams cannot be aligned along functional hierarchies. Often in hierarchal organizations, teams will just throw issues “over the wall” to other teams. This is anti-DevOps behavior and the only solution is to realign teams along product or service lines.
  • Hold each other accountable.
    • Speaking of throwing issues over the wall, accountability is a must in a DevOps culture. There has to be an organization-wide acceptance for accountability. If you say you are doing to do something, it must get done. Making mistakes should be embraced as part of the culture because, in DevOps, everyone must be able to accept, own and learn from their mistakes.

How Companies Make Mistakes In DevOps Implementation

Even though I’ve been saying that DevOps is a cultural shift that ends silos and forms cross-discipline teams, let’s make one thing clear. There’s no such thing as a “DevOps team.” Hiring someone and putting DevOps in their title or creating a DevOps team does not mean you are implementing DevOps.

Let’s look at a popular DevOps “title” to address the issues with it. What is a DevOps engineer?

Many organizations create a DevOps Engineer role but it’s actually a SysAdmin using a tool. This is quite anti-DevOps. DevOps is not just implementing a tool.

If an organization truly wants a DevOps engineer, then they should identify someone who can act as a project manager or Scrum Master who can become a DevOps evangelist. Whatever the role, you need anyone with a DevOps title to be an active proponent of the key components of DevOps culture.

It’s also bad practice to just relabel roles and shift teams around. If you’re at a boring party, shuffling around the guests in a different seating order isn’t going to change the fact that the party is, in fact, boring.

Remember, it’s not about combining two teams or having people in certain roles. It’s about adopting a culture of collaboration and accountability.

One complaint I’ve heard is that in many big companies, a DevOps team simply ends up being a team of people mandating certain processes for everyone and exerting complete control of those processes.

In case you haven’t been following along, that’s still silo mentality! Except now you’re just calling that silo “DevOps”.

What Is DevOps?

When we look at what does DevOps mean, we can see that it’s so much more than what most professionals assume. DevOps isn’t a title. It isn’t a department. It isn’t a team.

DevOps is a mindset, an attitude. It’s a cultural shift that requires acceptance from every member, communication across teams and complete accountability.

If your organization is in Central Indiana and is ready to get started on your DevOps Journey, register for our DASA DevOps Fundamentals Class on September 11. In this class, you’ll learn the foundations of DevOps. You’ll also you’ll learn from real-world examples and exercises so that you can take back and show your organization what DevOps would look like when applied to your company and how it can shift a company towards improved productivity. 

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

Why your company isn’t so excited (but should be!) about ESM

Share twitterlinkedinmail

Enterprise Service Management (ESM) describes the use of service processes and technologies across an organization.  ESM also describes business management software which provides an integrated view into business practices. [1]

And what part of any organization doesn’t rely on the use of processes and technology for running its business?  None!

But organizations have traditionally taken a departmental or system-based approach to processes and technology.  Such an approach usually focuses on the needs of a specific department, or those directly impacted by the implementation of a system.  Rarely (if ever!) does this approach address the entirety of a value chain, or the movement of work and information from a point-of-origin through the point-of-consumption.  Value chains within an organization typically involve multiple departments.  But because of a disjointed approach to processes and technology, work efforts are usually disjointed, and the organization works as a collection of parts.

ESM could fix that, as a good ESM implementation would facilitate and integrate the flow of information and activities within an organization.

Why your company needs ESM

The idea of ESM is not new, but there is now a renewed focus on the need for ESM.  Why is ESM suddenly so important?  I would argue that the most compelling reason why ESM is so important is the customer – especially in the context of today’s digital world.

A challenge often encountered by customers today is that one part of the company is unaware of what the other parts are doing, much less how their activities impact or depend on those other parts.  As a result, departments within companies often tend to work in isolation without regard for any upstream or downstream processes.  Things simply fall through the cracks.

And in the digital age, customers simply will not deal with organizations that act in this manner.  They will quickly (and quietly) move along.

An effective ESM implementation can result in an organization acting and working as an integrated enterprise.   Done well, ESM enables a frictionless and differentiated customer experience, as it reinforces an enterprise-wide, process-oriented approach for providing value to a customer.  By underpinning an organization’s value streams, ESM:

  • Can help identify and ensure that proper interfaces between individual systems are in place.
  • Brings clarity to the organization and breaks down internal barriers and silos.
  • Results in clearly defined and integrated value streams across the organization, not just within a department.
  • Brings transparency, consistency, and measurability into the movement of work and information across the organization.
  • Reflects the true picture of end-to-end service delivery.

Sounds great, right?  So why isn’t your company excited about ESM?

What is in the way of ESM?

ESM adoption has its own set of unique challenges.

  • Success with ESM will require a change in organizational behaviors. The internal service provider/customer model utilized in many organizations must end.  The “customer” is outside of the organization, and all parts of the organization must collaborate to deliver products and services to that customer.
  • Most organizational structures are hierarchical – which is a barrier to collaboration. A hierarchical organizational structure is typically pre-disposed to not collaborate with other parts of the organization.  This is because most organizational compensation and recognition schemes are focused inwardly on departmental goals and objectives and not enterprise goals.
  • Organizations lack defined, enterprise-wide business processes. Business processes are typically defined only at the departmental or team level and tend to focus only on a particular domain or area.  How business processes interface is at best poorly defined, if defined at all.
  • Technology has been used as a band-aid. Because organizations took a departmental approach to process and technology use, additional technology was often deployed to close the gaps between disparate systems within the enterprise.
  • Lack of clarity regarding organizational 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.  But often, there is no clarity or ownership regarding value streams within an organization.

Don’t repeat the ITSM sins of the past with ESM

Some organizations have approached ESM as just an extension of their current IT Service Management (ITSM) implementations.  I would agree that many ITSM concepts, such as having a centralized service desk and taking a coordinated response to service requests and interruptions, are applicable across the enterprise.  But I would also argue that for many organizations, if the ESM implementation mimics the approach taken for ITSM implementation, ESM will fail.  Why?  Because many ITSM implementations just aren’t delivering on their potential.

  • Many ITSM implementations only addressed operational issues and not the entire IT value stream. As a result, ITSM became a barrier, rather than an enabler, for working within IT.
  • ITSM was driven as an IT initiative, not as a business initiative. Rather than identifying, promoting, and delivering business value, ITSM became an obstacle for getting IT to do any work for the business.
  • IT services were defined as “things that IT does” and not in terms of business value and outcomes. As a result, there is no clear definition or shared understanding of how IT provides business value. To the rest of the organization, IT appears to be a cost center, not a value enabler.

Three things to do to get ready for ESM

To really make a positive impact, ESM must be more than just establishing an enterprise service desk or rolling out a self-service portal.  ESM has to reflect and support the true end-to-end delivery of products and services throughout the enterprise.  But ESM will require strong management commitment and an investment of time and resources.  It will not get done overnight.  So how do you get started?  Here’s my tips for getting ready for ESM:

  • Work on getting your ITSM house in order. IT is one of the few organizations within an enterprise that has a true enterprise view of the organization.  If current ITSM processes are ineffective, or if services are poorly defined, now is the opportunity to improve and learn.  The knowledge and skills you gain from making those improvements will be valuable as your organization begins its ESM journey.  Your business colleagues will also notice the improvements as well – this is critical, because you’re going to need their support.
  • Become an expert on the business of the business. This means learning the language of the business; what the business does to deliver value to the customer; understanding how the parts of the business interact to deliver that value to the customer.  Tools like COPIS (or “backward SIPOC”) diagrams are useful for capturing how value is delivered from the customer perspective back into the organization (in other words, from the outside-in).  This will also help you gain the support and credibility you’ll need from your business colleagues.
  • Develop a strong, compelling business case. Perhaps the most important question to answer is “Why should your company implement ESM?”. How will the gains in effectiveness and efficiency from ESM adoption translate into bottom line impact across the enterprise?  Perhaps ESM will result in improvements in the cost per sale or unit.  Maybe ESM will result in the reduction of lead times for product or service delivery.  Whatever the impacts may be, your business case must articulate the clear value proposition in terms of increased revenues, decreased costs, improved productivity, company differentiation, or improved customer satisfaction.

The digital age demands that organizations execute as frictionless, integrated enterprises. But to do so will require many companies to rethink how they are organized and how they collaborate to deliver both customer and business value.  Done well, ESM will transform organizations from “collections of parts” to an integrated, customer-focused enterprises, providing both an outstanding customer experience and improvements in efficiency and effectiveness.

Worried that your ESM efforts will fall into the “bad ITSM” trap?  Want to make sure that your leverage, not abandon,  your ITSM investments as you expand  into ESM?  Let us introduce you to VeriSM – the service management approach for the Digital Age.   Tedder Consulting can help you leverage VeriSM to achieve ESM – contact us today!

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

Picture Credit: Pixabay

[1] Wikipedia, retrieved May 30, 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