Failed Service

5 Reasons IT Service Management is Failing

Today’s IT organizations are busier than ever. They process more data, employ more people, and empower more businesses than at any other time in history. This growth in IT power and responsibility highlights the necessity that IT organizations build upon good processes. Many organizations turn to ITIL and IT service management to provide structure to their IT organization. While ITIL is a terrific framework for managing IT organizations, it’s not a silver bullet. Simply knowing about ITIL and using it to structure your IT organization isn’t enough to ensure success.

If you’re concerned that your IT service management processes might be failing your team or your business, read on. I’ve laid out five red flags that will help you detect if IT service management is failing.

#1: You’re Not Properly Scoping Changes

A common mistake among IT organizations is failing to set realistic targets for success of new processes. This can take several different forms. All of them are quite damaging to your business.

One form is scoping that may be insufficiently measurable. For instance, leadership doesn’t provide any specific targets but merely sets a goal that things will “get better.” A goal that relies on relative measures of success like “getting better” means measurement will be subjective. Subjective measurements involve the perception of stakeholders, which can be easily swayed by variations in day-to-day service. You don’t want the business to perceive your team as failing because the CTO’s laptop just happened to have a faulty hard drive the day before an organizational review of Service Management objectives.

Another form is scoping that’s too ambitious. An example might be an IT service manager setting a service level agreement that says you’ll resolve all incidents in one hour. That’s not a realistic timeline. Setting unrealistic timelines for employees degrades morale and makes those goals seem meaningless.

The opposite problem can also be trouble for an IT organization. It’s no good to set goals that won’t accomplish anything at all. Setting a goal that’s too loose means your organization won’t need to change to improve and will fail to provide value to the business.

#2: You’re Using the Wrong Tools

While ITIL is primarily focused around creating good processes for your IT organization, tooling is still very important. Regardless of your role in your business’s IT organization, you need the right information at the right time to do your job. High-quality IT service management software is regularly underrated as a part of a good IT service management implementation. It’s not just about getting the right information to the right people. It’s also about making sure that software is easy to use for business users. An effective IT service management implementation puts customers in a position to succeed, even when other parts of the IT organization are failing.

One way to identify failing tools is by looking for common pain points. Spend some time with key users of your IT service management software. Do they regularly have a hard time finding things? Is their time spent trying to make sure they don’t “mess up” the software? Does the software itself suffer regular outages?

If you suspect that your IT service management tools aren’t living up to their promises, you might want to check out a new platform like Enov8. You may find that you can easily cover gaps in your processes with software instead of painful changes on the process side.

#3: You’re Thinking About Incidents Wrong

One way IT service management systems regularly fail their users is by focusing too much on fixing problems. I know, that seems like an odd response. The truth is that sometimes IT organizations can focus too much on fixing their own problems over solving problems for the business.

IT organizations regularly think about incidents as engineering problems while users think about them as an inability to get work done. I really like the analogy of a broken light bulb. An IT organization sees the broken light bulb as the problem. The business doesn’t see it that way. Instead, they feel that the problem is that they’re trying to work in the dark. Engineers might spend days trying to get a new light bulb to users while a much simpler fix would simply be to open the window shades.

IT service management works best when it focuses on delivering the results the business needs. Often times, that requires quality engineering, but it should never be the primary concern. If your team looks at a new incident and immediately jumps to figuring out the technical cause, your IT service management implementation is probably failing. Focus first on fixing the problem for the business before trying to fix the root cause.

#4: Your Processes Are Too Complicated

IT service management is about putting processes into place in order to solve problems for the business. This is a worthy goal! Unfortunately, lots of times organizations lose that vision in the day-to-day running of the team. Something goes wrong as part of incident response, so they add a new step to a process. That new step for the process solves one problem but creates another problem that isn’t immediately apparent. When a problem crops up from that new change, the team adds another step.

You can see where this is going. In trying to fix lots of little problems encountered by your IT service management implementation, you’ve created one big one. Your processes have become much too complicated. The consequences of over-complicated processes are numerous. Employees don’t know what to do while dealing with problems. Management can’t easily understand the state of any given incident’s response. The business is stuck suffering from open issues. Resist the urge to add a new part of the process every time you encounter a problem. If you’re in the habit of doing this, look for what steps of the process you can remove to simplify it.

#5: You’re Not Focused on People

ITIL books and training focus a lot on processes and systems. That’s necessary because people writing books or designing training don’t know the people in your business. But the truth of the matter is that those people are the reason for IT service management. The goal is to make their lives easier. It’s not about implementing a specific process or creating the perfect architecture.

At the end of the day, the true measure of success is whether your IT organization makes working for your business better. Successful IT service management implementations spend a lot of time thinking about their users. They talk with them and listen to the problems those users are facing. Unsuccessful implementations get bogged down by worrying about metrics and tweaks to the process.

The Hardest Part is Recognizing the Problem

Most IT service management implementations don’t fail because of malice. They don’t fail because of incompetence on the part of the team. Those implementations fail because the team didn’t recognize the warning signs of failure before it became entrenched within their system. The IT organizations pursued their implementation with the best of intentions but didn’t know they were headed toward failure. If you recognize some of these issues within your organization, it’s not too late to start fixing them. It’ll require diligence and critical thinking, but you can absolutely be successful.

Author Eric Boersma

This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.

Reasons-Enterprise-Configuration-Management-is-Failing

Reasons Enterprise Configuration Management Is Failing

Reasons Enterprise Configuration Management Is Failing

Enterprise configuration management (ECM) is a big topic. Projects that aim to implement ECM are, by their nature, significant endeavors. You’re trying to encapsulate all of your organization’s core configurations down into a single source. That’s difficult under the best of circumstances, and like most projects, ECM projects may fail quickly. When they do fail, they tend to do so spectacularly too. As a project or people manager, you’re responsible for big parts of your ECM project. You want to make sure that it’s going to be a success. How can you tell whether your ECM project is in danger of failing?

We’ve collected five major “issues” that will tell you whether your project is on the wrong track.

Issue #1: Eroding Trust

ECM projects, as we’ve noted, are massive projects. By necessity, they mean working with people outside of your own team. Different teams within an organization often have different overall goals and varying incentives to meet those goals. Sometimes those goals are contrary to the success of a big organization-wide project like an ECM project. In order for a project like this to succeed, that means teams and individual team members sometimes need to set aside their own goals.

In order to set aside their goals and work together, the teams involved need to trust each other, and that’s true for ECM projects too. They have to be able to trust that the work they’re doing together will be more beneficial to the company in the long run than if they were to prioritize their own team goals.

If you identify that there are trust issues between your teams or members of those teams, that’s a big red flag for your project. It means that those teams, when stressed, do what’s in their best interest, not in the interest of the whole organization.

Issue #2: Losing Sight of the Bigger Picture

Losing sight of the bigger picture is a facet of Issue #1, eroding trust. But it’s not exactly the same thing. While people lose trust in other teams when they lose sight of the bigger picture, losing context doesn’t always mean losing trust.

Sometimes losing sight of the bigger picture can result in people who get too focused on one detail of the project. That can manifest in lots of ways. Maybe they’re overly focused on one detail in a part of your implementation. It could be that they’re hyper-critical of a decision that’s been made while ignoring the bigger implications. Whatever the reason, they’re a challenge to work with because they’re too focused on small details. Since ECM stretches across your organization, you need people who see and promote Enterprise wide IT intelligence.

One or two of those kinds of people in your project aren’t going to kill it. But if you’ve got half a dozen, you’re going to have a hard time. Identifying those people and working out their problems early on is important to your implementation’s success.

Issue #3: Things Stop Improving

Any long-term project needs continuous improvement to be successful. If you and your teams already knew how to do all of this, your project would be done already. Stagnation is the enemy of a good ECM implementation. Even if you’ve already delivered your initial ECM project, you need to constantly search for ways to improve what you’re delivering to the business.

Realistically, no matter how good your ECM implementation is, it’s not perfect. There are always ways that you can improve. Whether that’s as a team or in terms of your technology, the state of the thing is constantly advancing. You need to be able to advance with it. Continuous improvement not only improves your efficiency, but it boosts employee morale too. High employee morale and a good sense of the cutting edge makes it easy to recruit talented new employees. It also becomes much easier to retain the good employees you have.

The converse is also true. If you’re stagnating, you’re going to lose your best employees. It’ll be harder to attract top talent because you’re working with outdated processes and technology. That sort of thing leads to a snowball effect: it’s harder to attract top talent, which means it’s harder to tackle bigger challenges, and the cycle repeats.

Issue #4: Users Don’t Use ECM

This issue is a little tougher to detect. By definition, if your users are working around your ECM system, they’re trying to make sure you don’t know about it. That’s not good! If you find out that people are working around your ECM system to store essential configuration in some other way, that’s a warning sign that there’s something wrong with your implementation. If you find someone who’s doing that, it should be a red flag that you need to find a way to improve your systems.

There’s good news, though. If you find someone who’s working around your system, you know just who to ask to make things better. Instead of getting upset that someone is working around your system, your new knowledge presents you with an opportunity. Take the time to sit down with them and ask why it is that the system isn’t working for them. You might not be able to alleviate every issue they have, but you can help make things better. If one person is working around your system, they’re probably not alone.

Because an ECM is supposed to be a central repository of configuration, anyone working around the system is a small failure. The key for you as a dedicated employee is to figure out just how pervasive those workarounds are. You might find, after a bit of investigation, that the employee in question is just lazy—that’s not a red flag. But if you do find that they’re working around your system for good reasons, your ECM implementation is in trouble. Use that as an opportunity to get out there and improve your team and your process.

Issue #5: Lack of Management Buy-in

Even if you avoid every other red flag on this list, a lack of management buy-in will debilitate any project. This issue can also be the root cause of many of the other red flags on this list too. If managers aren’t bought in, they’ll task their employees with different priorities than what your project needs to succeed. They might erode the time your team needs to think critically about what you’re doing and improve your processes. Another manager who isn’t bought-in will fight over tiny details in an attempt to derail the project. A petty manager will run interference for users who are working around systems instead of taking the time to do the right thing.

As the person responsible for the project, it’s your responsibility to make sure managers understand the what and why of ECM. Old wisdom says that a house divided cannot stand; the same is true in business. Your ECM project is going to have a much tougher time if you have to fight other managers within your organization. If you find yourself fighting other managers, you should be worried about the state of your project. That’s the time to start asking those people if there are ways you can prove the usefulness of the project to them. If you can, that’s a great way to get your project back on track.

To Conclude

None of these issues are fatal for your project. If you find one of them cropping up around your implementation, don’t panic. When you find yourself with a red flag, that’s the time to think critically about the choices you’ve made that have brought you to that point. Evaluate whether there are things you can change and spend time talking to your users and the leads of other teams. They’ll help you determine the root of the causes of your problems, and knowing what to fix is half the battle.

Author

This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.

Test Environment Management Tools Compared

Five years ago, if you were asked to recommend a “Test Environment Management” platforms you might have struggled.  In fact, you might have struggle to identify one, particularly if you would have considered your own DevTest teams’ behaviour. Lot of disruption, delays, misconfiguration and the inevitable use of Spreadsheets for tracking project bookings, MS Visio document for system information capture, Email for Reporting and perhaps if you were lucky, some test automation for platform health checks. Not exactly elegant nor scalable but undoubtedly better than complete chaos.

However, things have somewhat changed and with a raft of solutions now claiming to solve this problem, The Last Frontier of the SDLC, the question now is not “what” but “which” platform will meet our needs and address one of the SDLC’s biggest “Waste Areas”?

At TEM Dot we decided to compare six of the biggest players in this space across 10 key areas:

Key TEM Vendors

Key TEM Performance Areas

  1. Modelling
  2. Booking Management
  3. Coordination
  4. Ticketing
  5. Health Monitoring
  6. Automation & DevOps
  7. Data Management
  8. Reporting
  9. Extensibility
  10. Affordability

Test Environment Management Tool Scoring

Area-1 Environment Modelling

The ability to know what your Environments and Systems look like.

Historically think Visio or your CMDB (if you have one).

Gold Medal Position:   

Enov8 & ServiceNow both offer powerful Visual CMDBs & Component / discovery mapping.

Silver:

Plutora & Xebia offer modelling capability.

Bronze:

Apwide & Omnium modelling is achieved via tabular forms.

Area-2 Booking & Contention Management

The ability to capture environment requirements & manage contention on Environments & Systems.

Historically think Email & an attached Word document.

Gold Medal Position:   

Enov8 & Plutora offer advanced booking & contention analysis methods.

Silver:

Apwide, ServiceNow offer booking requests (ref ticketing) capability.

Bronze:

Xebia has no obvious environment booking or contention mechanism.

Area-3 Environment Coordination

Tracking Events & Release activity across space (Environments) & time (Month, Year etc).

Historically think a MS Project Plans.

Gold Medal Position:   

Apwide, Enov8, Plutora, ServiceNow offer Environment & Release based calendaring.

Note: Enov8 & Plutora offer Runsheets /Implementation Plans (respectively).

Service Now offers checklists.

Silver:

Xebia – Calendaring is release centric (opposed to environment centric).

Bronze:

Omnium (limited capability identified).

Area-4 Ticketing

Ticketing / IT Service Management to capture Environment Change Requests Incidents etc.

Historically think Remedy.

Gold Medal Position:   

ServiceNow has advanced ITSM methods.

Silver:

Apwide (using Jira), Enov8, Plutora have solid Ticketing / Requests functionality.

Bronze:

Omnium & Xebia dependent on other tools.

Area-5 Health Monitoring

The ability check Systems or Components or Interfaces are up.

Historically think Test Automation scripting or your server monitoring solutions like Zabbix.

Gold Medal Position:   

Enov8 & ServiceNow offer integration methods & native agents to monitor health.

Silver

Apwide & Plutora have APIs that logically allow system health updates.

Bronze:

Omnium & Xebia don’t play in this space.

Area-6 Automation & DevOps

The ability to automate key Environment Operations using code.

Think Jenkins or Puppet Jobs.

Gold Medal Position:   

Xebia is a powerful release orchestrator (its primary purpose).

Silver:

ServiceNow Orchestration automates IT & Business Processes.

Enov8 offers “agnostic” Scripting Hub (Orchestration Manager), Pipelines, Playbook, Webhooks & URL Triggers.

Bronze:

Apwide integration is very simple but can be achieved with Get/Post methods.

Plutora needs other tools to automate/integrate properly (like Dell Boomi). The SaaS only option can also be limiting.

Omnium integrates with other tools to automate.

Area-7 Data Management

The ability to manage one’s data e.g. Extract Data, Masking data, Provisioning Data etc.

Think Compuware File-Aid.

Gold Medal Position:   

Enov8 seems to be the only solution for Test Data. Enov8 offers support for Data (PII/Risk) Profiling & Masking and Data Bookings through “Data Compliance Suite”. Enov8’s Visual Orchestrate can also be used to schedule other Data Tools.

Silver:

Xebia & ServiceNow capabilities are limited but they can leverage their orchestrators and call other tools.

Bronze:

Apwide, Omnium & Plutora don’t appear to play in this space.

Area-8 Reporting

The ability to get & share insights about your Environments.

Historically think drawing pretty pictures & graphs with PowerPoint.

Gold Medal Position:   

A lot of the tools have solid reporting; however, focus is Environments: No Gold Medal yet.

Silver:

Enov8 seem to have best out-of-box Environment dashboards. Needs simpler customization.

ServiceNow Env Dashboard are limited but ultimately extensible.

Xebia have some solid report, but more deployment focused.

Plutora is reliant on a new “Tableau” extension. Getting there but seems disjoint.

Bronze:

Apwide leverages Jira’s native capabilities.

Omnium approach is somewhat “download/export” focused.

Area-9 Extensibility

The ability to have the product do whatever you want.

Think of Salesforce or SAP.

Gold Medal Position:   

ServiceNow – An Extensible Engine. You can use it to build anything.

Enov8 – An “Object Oriented” Extensible Engine. You can use it to build anything.

Silver:

Plutora has broad customization features so you can “partially” alter its behaviour.

Bronze:

Xebia allows customization of your processes but not the platform itself.

With Apwide & Omnium you basically get what you get.

Area-10 Cost

The money ball question. And potentially the most important for some.

Gold Medal Position:   

Low Cost of Entry – Apwide, Enov8 (Free Team Edition) & Omnium

Silver:

Medium – Plutora & Xebia

Bronze:

Expensive – ServiceNow (Just add another “0” for licensing & tailoring services)

The “Test Environment Management Tool” Score Card 

Test Environment Management Tools Comparison

Overall Test Environment Management Platform Rating

Final TEM Tool Positions

Position Player Findings
#1 Enov8 Very much a Test Environment centric solution.
#2 ServiceNow An extensible ITSM solution, expensive but powerful.
#3 Plutora More focused on Release Planning.
#4 Apwide Simple & Elegant TEM/Release tool that has its place at the table.
#4 Xebia More focused on Continuous Delivery
#5 Omnium Inexpensive and will be the right fit for some.

Note: Scoring was limited to the ten key areas recognised by TEMDOT as the most important for successful Test Environment management. The scores do not reflect broader functionality i.e. functionality that may be deemed more important for your organization. If you feel there are inaccurate statements in this comparison or a tool missing, please reach out using our contact form.