I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

in the age of the digital transformation. This age means that we do mobile first (or mobile only?), everything is software-defined, 40% of the Fortune 100 will fail in the next five years or six months or something like that, IT (including the CIO) will soon report to a chief digital officer -- the new CDO will be 23 years old but with deep experience in Reddit. And, in case you have not yet heard, everything is now different.

All right, I am being a bit facetious about the hype around the digital transformation. That said, things really are different. Technology has and is changing the world. Everything moves at the pace of technology innovation, and that pace is break-neck. Many of us (at least those not yet reporting to the new 23-year-old CDO) are driving organizational innovation and so have a sense of the changes taking place. With all that is changing, it is easy for us to forget about the basics of IT -- the blocking and tackling that ensure that we deliver operational excellence. For me, that blocking and tackling is based on the principles of IT service management (ITSM). I have found that the better I am at service management, the better I will be at operational excellence, customer satisfaction and, more important, IT agility. Perhaps my personal example will demonstrate how a solid ITSM strategy enables digital transformation.

Leveraging ITSM strategy to sustain digital transformation

We design, develop and support two SaaS products that our clients and their employees use. When I first inherited these products, they were overly complex, fragile and brittle. All by themselves, they broke several times a week. As you might expect, it is difficult to focus on innovation and digital transformation when we are not good at basic delivery. My first priority had to be to make these products solid, reliable and high-performing. I am happy to report that we have accomplished those tasks. How did we pull that off? ITSM. We defined a service catalog and service levels and then used a quality incident response and resolution process to get to and resolve the root cause of our application issues. As we consistently applied our ITSM strategy to our products, performance improved and we were able to shift our efforts from firefighting to the proactive innovation of our products. And, as we made this shift, we retained our focus on our use of ITSM principles.

As our product foundation improved, we started to seize and realize opportunities to shorten our time to market. This led us to experiment with and start to use agile software development methods and DevOps. We moved from twice-yearly product releases to monthly releases and now to weekly releases. Shrinking our release cycle has created significant value. Fixes, enhancements and good old innovations get to our customers much faster. And, each release is smaller and therefore less complex and less risky. In order to pull this off, we had to be really good at service definition, delivery and management. In other words, we had to have our ITSM act together.

As we shorten our development cycles, we must shorten our incident response and root cause analysis cycles. In our case, we use production worthiness standards that define what we mean by a quality service. We meet weekly to review pending changes (including the week's product release) and any open incidents (an open incident is one for which we have not yet identified the root cause or implemented the counter measure). We focus our attention on the process rather than the specific incident. If the last release introduced a software bug, we ask ourselves how we need to change our software development processes in order to reduce the likelihood of releasing a bug. This short, weekly cycle closes the time gap between incident and counter measure. And, short feedback loops are critical to improved performance.

About the author:Niel Nickolaisen is CTO at O.C. Tanner Co., a human resources consulting company based in Salt Lake City that designs and implements employee recognition programs. A frequent writer and speaker on transforming IT and IT leadership, Nickolaisen holds an M.S. in engineering from MIT, as well as an MBA degree and a B.S. in physics from Utah State University. You can contact Nickolaisen at nnick@octanner.com.

4 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

It’s good to see some advice to focus on the ITSM strategy at the product level to improve the foundation that ITSM is built on. Too many ITSM implementations have a strategy that focuses on implementing service management itself, and don’t really focus on the products that the different “management” areas (Change, Incident, Problem, Release, etc.) support.