Your Next ITSM Tool Should be Neither

TL,DR; decouple IT operations from customer service and development. Then realize the incredible savings and benefits thereof.

The term “ITSM” has always bugged me, and I think I know why.

The primary customer of ITSM is IT; everything else is lumped into “customer service” and “customer experience”.

ITSM_WikiEven Wikipedia says there are too many “fluff words” and that ITSM has an unclear definition.

But in IT, we know better. We understand what we’re talking about when we say Service Management. It’s a standard way of operating so we don’t fail.

So why would any business person buy Service Management?

To keep the lights on.

“But that’s what we hired you for! We don’t care what you call it. We don’t want to buy it, we want you to DO IT!”

Then I’ll need $1.5m every three years to replace my tools, redesign processes and…

Wait, $1.5m? Don’t you remember when last year we were managing changes via email? Don’t you remember the spreadsheets of Assets? Why $1.5m?

Technology has become complex and our colleagues want to reduce risk. Some also want to understand the value and depreciation of assets. ITSM is just IT Operations Management + Customer Service.

DING DING DING DING DING DING – we have a winner! Here’s your $1.5 million. But why every three years?

Think of ITSM tools like a car lease. Three years comes along, and it’s time for a fresh smelling one, the latest one with all the bells and whistles.

Do the bells and whistles keep the lights on?


Then why keep upgrading and rebuilding your operations empire?

The tools and practices that surround Service Management change, and they change often.  Have you considered who benefits from that change?

Consider separating your systems of operation from your systems of service. It gives you the freedom to change platforms without impacting your customers.

The impact of this is far greater than you realize. We believe in building systems of engagement separate from systems of record. To understand the nature of this problem:


systems-of-recordDoes this image describe your problem? If so, you’ll be interested in understanding our approach to enterprise software. Read more here, or just call us directly: 1-651-556-1030

The Benefits of Focusing on Technology ROI (Return on Incrementalism)

Bombarded by rapidly changing business requirements and frustrated by the constraints of legacy management and control systems, the natural reaction of technology decision makers may be to rip out the big, old platform and replace it with a big, new one. But that isn’t always the best answer.

As Sanjay Srivastava and Gianni Giacomelli write in IndustryWeek (Separating Impact from Hype: How CFOs Achieve Technology ROI), ” A huge, multi-year implementation is no longer the only option available to leverage better technology. In fact, massive implementations can sometimes undermine actual business goals.”

Benefits of an incremental approach to technologyThe two authors ask why “so many companies reach the end of a multi-year deployment only to discover they are not materially better off than before, and that the world has moved on to the next big thing,” and contend this is because, in many instances, enterprises “implement a vast array of process and technology improvements rather than surgically target the actual drivers of desired business outcomes.” In other words, firms take a revolutionary “rip and replace” approach to large systems rather than implementing flexible, incremental answers to specific business needs.

Continue reading “The Benefits of Focusing on Technology ROI (Return on Incrementalism)”

Service Providers—Do the Math on Visible and Hidden Benefits

By Brett Norgaard

The other day, we got some feedback from a large service provider who’s been struggling with their service request management tool for the usual reasons—it is inflexible, dependent upon programming, risky to make changes to the database structure, cumbersome to move from development to production without rework, hard to survive upgrades to the underlying service platform and constantly reinventing the wheel. After experiencing a demonstration of Kinetic Request and Kinetic Task’s configuration driven approach, reusable and cloneable service items and handlers as a starting point for creating new service items, visual work flow, and portability between environments, versions and instances they said something powerful, “This will save us two to three years of development time and will put us that much ahead of schedule.”

Here then is a list of the “visible” business benefits that they saw:

  • Cost savings
  • Time-to-market
  • Using a more readily available and less costly resource (business analyst vs. programmer)

While this is very interesting, think about something else—this represents one client. This service provider has many clients. While each is unique, our experience tells us that there are similar standard service items that could be deployed across the entire client base. Working from a master library, this service provider could also construct an automated method to generate not only a standard service catalog, but specialized service catalogs that command premium pricing based upon their business value to the client. They would also have the money, time, and a satisfied client willing to look at doing more with them.

For simplicity sake, if this service provider had ten clients in the same boat as described above, the cost savings they could point to collectively would be 20-30 years of development time. Now we are talking some serious money as well as some seriously happy clients that can consume the service provider’s offers now vs. two to three years down the road. As author Michael Lewis pointed out in the book, “The New, New Thing” when referring to Jim Jordan (silicon valley guru) and his sales pitch to investors, “Do the math.”

Service providers who have the right knowledge, architecture, tools, and skills in place are poised to accrue “hidden” business benefits as well as the “visible” ones sooner vs. later.

Facebook Has Taken Over the World

A Vision from Down Under
By Michael Poole


We hear this, even in the antipodes, so often and it may be true, especially for anyone under 40.

Why? Well, obviously it provides a way to communicate with friends and acquaintances; but it’s unlikely it would have been as successful if it had followed the design methods that can be found in too many corporate intranets.

One of Facebook’s major features is “consistency.” Consistent styling; consistent behavior; consistent look-and-feel.

Consistency is paramount to the success of all successful social networking sites. In fact, consistency is such a hallmark of these sites that ANY change to the design makes headlines or at least millions of wall posts!

If Facebook was like most corporate intranets, I doubt if users would have returned again and again.

The “public” internet sites of companies are owned and controlled by the marketing department whose whole purpose is attract visitors and ensure that the site is friendly, usable and informative. They usually follow the same design philosophy that has produced Facebook – consistency and ease of use.

Intranets, on the other hand, are usually owned by IT departments and the content is produced and published by individual departments with differing design (or non-design) skills.

Each department will often have a different set of design parameters and styles. Without a set of design guidelines that stress consistency and ease of use, the intranet can easily look like a “mash-up” – or perhaps a “mess-up” – of isolated intranet sites with jarring and confusing inconsistencies from page to page and area to area.

We have all experienced the corporate intranet that changes themes, banners, fonts for each department area. Intranets that use different layouts, even within department areas – some departments may have text links to some forms, buttons for others; one part of the site may work with IE9 – other parts need will not work with IE7; one might use bold, bright colors, another subdued pastels. The variations can be as many as there are contributors to the intranet site.

Rule one for a successful intranet

The intranet should look and behave in a consistent way. Having an intranet that changes its appearance and behavior between sections disorientates users and can introduce doubts into their minds as to whether or not all sections are as reliable and current as each other.

Of course, I can hear some of my readers saying: “Yes, we tried to do that, we had a theme designed, set standards for user interaction, had a template for all pages. We did all that but then we had to integrate a web-based application into the intranet and it all went bad. We could not change the way that application looked or worked, so we just had to compromise and accept it.”

So, many people, though trying to build in consistency into the intranet, are brought to a crashing halt by having to incorporate inflexible and inconsistent applications.

Why has this happened?

Let’s face it, most corporate applications have been around for some time. Many pre-date the internet and most certainly Web 2.0. They have been developed for dedicated user clients – some were even developed for dumb terminals. And when they produced the “web” version they did try for consistency – but it was consistency with the old, pre-web version. As a result, they produced clones of the old client down to the colors, key-strokes, layout etc.

With this design philosophy – consistency with the past – when they developed “new” functionality, they repeated the design errors of the past. And because in the past they had prescribed the layout, theme and style of the application, they did it again with the new functionality. As a result, application portals came so they fitted in with the parent application and not easily, if at all, styled to be consistent with the intranet they would be integrated into.

If you want a graphic (no pun intended) proof of this, look at the majority of ITSM application vendor’s web offerings – nearly all clones of the dedicated client interfaces of the past.

Should this be the way?


The web is designed to be able to be styled and themed in very powerful ways giving developers the ability to produce interfaces and pages that can be easily integrated into any existing style or theme or to any device.

One way to do this is to use Cascading Style Sheets (CSS) to define the look and feel of an individual web page or a whole site.

This is the strategy that we have embraced when designing not just Kinetic Request forms but the whole Service Request Portal interface. We have empowered our clients to easily integrate both Kinetic Request forms and portals seamlessly into their existing intranets by leveraging the CSS definitions that they use for the rest of the intranet site. The result is CONSISTENCY – consistency of style, functionality and experience, and a reduction of confusion.

By putting the focus on enabling consistency of styling and functionality in the web interface to request management and fulfillment, our users have not had to compromise the consistency of the intranet. The payback is not only better customer satisfaction and better adoption by the users but also a reduction in costs of implementation, user support and training.

It is not the magic bullet – your intranet will never be as popular as Facebook and you will still have to battle to get HR to follow a design guideline – but having the power to enforce consistency is a major step along the way!

The Myth of the IT Service Management Upgrade

By Brian Shealey

In the IT Service Management space, it seems as though organizations are on a continual quest to upgrade to the latest and greatest version of their IT service management platform. And, like everything in life, newer is always “better,” right? Well… it depends!

An important question to this organizational pattern of perpetually upgrading that rarely gets answered is “Why are you upgrading?” What’s the purpose of upgrading today to version 7.x, when version 8, 9 or 10 will be released in the next six months? You know that the next version released will include even more feature functionality than is available today. So, if you are upgrading your ITSM platform to the “latest and greatest” version, you will not achieve a final state of “upgraded,” but instead you will be doing the next project in the life cycle of the system. There is no perfection in the world of IT service management tools. It is a myth!

Contradictions of Intent

If you actually pose the question “Why are you upgrading?” to an organization preparing for, or in the throes of an upgrade, the responses will vary. Many organizations will say, “We are adopting ITIL as a strategy and need an ITIL-aligned toolset.” Sometimes, you may hear, “We need to be more out-of-the-box because it is painful to move our customizations to the new versions when we have to upgrade.” And then, there’s my favorite: “Our vendor doesn’t support our version because it is too old.”

I know there are many other reasons, but the vast majority of reasons customers give for upgrading fall within those three categories. The real underlying question that is relevant to a successful upgrade is: “What is the business benefit of the upgrade?”

In other words, does this upgrade help us sell more widgets as a company, deliver our services better, or support our products better? In some cases it may, but I think to stop and ask this question along the way is done less often than you would think by IT organizations.

I admit—some upgrades do fix bugs and/or enhance functionality, making the organization more efficient through a better-performing toolset, alignment to a need, etc. From my experience, most organizations are continuing the path of upgrading with the hopes that the latest version/upgrade will fix all of the issues (perceived and otherwise) with their ITSM platform. Rarely do we see organizations stop and ask, “What is the business benefit of this upgrade?”.

Adopting ITIL Aligned Tool Set

ITIL is designed as a framework for aligning IT with the business. Therefore, an upgrade to “align with ITIL” doesn’t make sense. According to ITIL principles, the goal of an upgrade of any system should be to make the business more efficient. Upgrading for the sake of ITIL alignment is a contradiction in itself.

Need a More Out-Of-The-Box Solution

In the premise “We are too customized, and upgrades are painful,” there is also some inherent contradiction. If you are only upgrading to out-of-the-box ITSM because upgrades are perceived as painful. I would argue that the upgrade to ITSM definitely doesn’t solve this issue. ITSM tools are very complex. Upgrading from one version to the next, regardless of vendor, is often just as painful, if not more so, than upgrading a custom application that was aligned to the company’s needs from its inception. You not only have to deal with new tools, but also with major process changes from the way workflows were handled in the custom tool. With out-of-the-box ITSM apps, workflows are designed generically, with no thought of your company’s needs. Your processes must be changed to fit the vendor’s out–of-box ITSM platform workflows, or you are stuck customizing the new application, defeating the purpose of trying to be out-of-the-box. It’s a contradiction in intent.

The reality, in my humble opinion, is that this is actually driven by the ITSM vendor. With the right marketing and positioning of these out-of-the-box ITSM tools, they can appear to be a much better option to the company than the old, custom ITSM application.

Unsupported or Old Version Reason

This common reason for an upgrade has to do with supported versions of products. If a vendor discontinues support for specific versions of their software, and your organization sees the risk as too great to have an unsupported version of the ITSM tool, then you may be forced to upgrade. However, it’s important to really understand what you are getting.

For instance, if you upgrade the core component of your ITSM tool, and it creates more issues from a management, administration and cost standpoint than the unsupported old version, you may want to reconsider the upgrade. It is usually a smart decision to look around once in awhile to see what others are doing. Maybe look at alternatives to the upgrade, third-party support or another toolset altogether. It never hurts to take time and gain perspective prior to making decisions that are potentially very costly. In some cases, the cost of an upgrade may equal the cost of a complete replacement of the current tool set.

The Reality of the Upgrade…Happiness Is Not a Destination, and Perfection Does Not Exist

Here is the reality of an ITSM upgrade: An organization using an ITSM system is never going to be upgraded, or current, enough. Vendors will continue to put out new versions of their products to solve issues, fix problems, be more competitive, or just make their product “better.” However, is that version of better actually better for you? That is always an important question to ask.

Specifically, I believe that what’s best for Company A is: What is best for Company A.

Pardon the Yogi Berra-ism, but what I mean is this: Every organization has its own set of unique challenges. There are costs to those challenges, and problems to be solved specific to that organization. An upgrade is a concept that is driven into the mind of IT managers by their ITSM vendors—as a “must have” for whatever product they are using in pursuit of IT service management perfection.

There is no such thing as perfection in IT service management. Not in processes, not in technologies and certainly not in people. If you can invest in tools that allow you to continue improving your business and better deliver services both internally and externally, you are on the right track. A “good” upgrade is one that solves challenges in a cost-effective way and helps improve the business of the organization.

A friend of mine would always say, “Happiness is not a destination.” I think that certainly applies in the world of managing and maintaining ITSM platforms.