IT Service Management (ITSM) Antipatterns

In my research on Agile, Continuous Delivery & Devops, I often come across the concept of antipatterns (or anti-patterns). According to Budgen (2003, p. 225), an antipattern is "a common response to a recurring problem that is usually ineffective and risks being highly counterproductive". Sourcemaking defines antipatterns as "an industry vocabulary for the common defective processes and implementations within organizations." McCormick (1998) clarifies the differences between design patterns and antipatterns by stating "design patterns provide the most effective form of software guidance yet available, and the whole patterns movement has gone a long way in codifying a concise terminology for conveying sophisticated computer science thinking. Antipatterns are a natural extension to design patterns, focused on the wide and ever-growing selection of repeated software failures in an attempt to understand, prevent, and recover from them. Antipatterns are a new tool that bridge the gap between architectural concepts and real-world implementations."

Some examples of organisational and project management antipatterns include:

  • Analysis paralysis: A project stalled in the analysis phase, unable to achieve support for any of the potential plans of approach.
  • Cash cow: A profitable legacy product that often leads to complacency about new products.
  • Groupthink: A collective state where group members begin to often unknowingly think alike and reject differing viewpoints.
  • Scope Creep: Uncontrolled changes or continuous growth in a project’s scope, or adding new features to the project after the original requirements have been drafted and accepted.

I've found antipatterns for Agile and DevOps a useful way to better understand these concepts as antipatterns declare what is NOT the expected behaviour or practices we expect to see in order to be successful. Sometimes to better understand what is expected, we need to understand what is not expected. I have previously blogged my concerns that ITIL is missing a supportive culture, and there is promise showing in the Core Values established by the Service Management Congress (SMC) which appear to be inspired by the Agile Manifesto.

Perhaps developing a set of IT Service Management antipatterns would assist important stakeholders (e.g. our customers and IT teams) understand what IT Service Management is all about and how it adds value?

To promote some discussion and comments, some of my suggested ITSM antipatterns include:

  • IT Service Management only equals ITIL: The perception that the only (or dominant) way to manage IT services is by adopting ITIL. 
  • ITIL must be tightly adopted to be successful: ITSM processses are configured very closely to ITIL without considering the organisation's culture, goals and other adopted frameworks.
  • ITSM must be centrally managed: Similar to the SMC core value of Trust over Control, the perception that an organisation must have a central team to manage and deliver service management processes/services.
  • Auditing needs over speed of delivery: The introduction or justification of process activities/steps in the belief that internal/external auditors require them as evidence of controls ("we should do that, just in case"). 
  • Reporting equals Progress: The belief that providing regular service management reports (that are actually ineffective and not reviewed) shows the IT department is making a positive contribution. @Lee Cullom suggests the antipattern "Support, Don't Report!"
  • If it ain't broke, don't fix it: The perception that a process/service has been working well in the past, so therefore there is no need to review/change it. 

I'm confident my list above is not extensive and I encourage readers to please post comments with their suggested ITSM antipatterns.

Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. p. 225. ISBN 0-201-72219-4.

McCormick, H. W (1998). Antipatterns: Refactoring Software, Architectures and Projects in Crisis. Retrieved March 29, 2014 from

Sourcemaking (2014). Retrieved March 29, 2014 from

Popular posts from this blog

Improving your IT service delivery and operations with ChatOps

Delivering Problem Management with Kanban

Using the Lean Canvas for an IT solution proof of concept