This is volume 1 of 137. (Just kidding.) But the reasons why IT Transformations fail are as numerous as grains of sand on the beach. In this article, I will cover some of the more common reasons why IT Transformations fail and also provide some guidance on how to avoid the major pitfalls.

Dr. Edward Deming’s now famous PDCA concept (Plan, Do, Check, Act) actually has very deep roots. Dr. Deming always referred to it as the “Shewhart cycle” in recognition of his collaborator and mentor, Dr. Walter Shewhart. Its roots, however, trace much further back, originating from concepts put forward by Sir Francis Bacon, Aristotle and Socrates.

The basic concept that you must first methodically plan what you intend to do, then do it, then check to see if it achieved your intended result, and then act to correct anything that didn’t work as intended, is powerful in its simplicity. The concept just makes sense. Yet, too often during transformational efforts this basic process is forgotten. There is normally a fair amount of effort put toward the “Plan and Do” phases, but it seems to stop there. Teams seem to believe that if they can simply develop a process or procedure and “implement it”, it will somehow work perfectly.

That’s rarely the case. There is a misperception that the four stages of PDCA are equal in duration and effort. In fact, the “Plan and Do” stages typically represent much less than half of the effort required to truly embed change into a culture and realize the improvements sought. This white paper explores how to ensure cultural adoption through a series of specific activities that must occur after “implementation.”

Have you ever gone through the process of a transformation effort and suddenly found yourself conforming to a standard or framework without really knowing why? Have you ever finished a transformation effort and realized that it really didn't meet the business drivers that initiated the effort to begin with?

Many IT leaders have found themselves in this situation and, in many cases, end up abandoning frameworks all together. But are frameworks really the problem? They're not.

Business is moving faster and faster every day - and demanding that IT move with it. As a result IT organizations are moving toward new development methodologies, approaches and tools such as SOA and Agile to reduce time to delivery of critical business apps. But as these same organizations adopt IT Service Management principles, an apparent conflict arises pitting SOA and Agile against Change and Release Management.

In this brief 45-minute webinar you will learn key insights and techniques to help you bridge the apparent gap between rapid development approaches and ITSM, and create true organizational agility, including:

• Why SOA, Agile and Change/Release Management are after the same goal
• How SOA and Agile relate to Service Design and why it matters to your ITSM efforts
• How to design a change and release process that can support SOA and Agile