The Importance of Being Personable and Pragmatic in ITSM

The Technical Consultant Trap

There is a version of ITSM consulting that is technically impeccable and practically useless. The assessment findings are accurate, the process designs are well-constructed, the roadmap is logically sequenced — and nothing changes, because nobody was persuaded that change was necessary or possible.

We have seen this pattern often enough to be certain about its cause: a consulting approach that treats the technical problem as the only problem. In reality, every ITSM improvement initiative is fundamentally a human challenge. The technical work is the easy part.

Why People Resist ITSM Change

The resistance to ITSM improvement is almost never irrational. Practitioners who have seen previous improvement initiatives come and go without lasting impact have rational grounds for scepticism. Teams who have had processes imposed on them without consultation have rational grounds for non-compliance. Leaders who have been given roadmaps without business cases have rational grounds for deprioritisation.

Understanding these rational objections — and addressing them directly, rather than treating resistance as a problem to be managed — is the foundation of effective ITSM leadership and consulting.

What Personable Looks Like

Being personable in an ITSM context is not about being likeable in a social sense. It is about conducting the work in a way that respects the knowledge and experience of practitioners, creates genuine dialogue rather than one-way communication, and builds enough trust that people will tell you the truth about what is actually happening rather than what they think you want to hear.

The most valuable information in any ITSM assessment comes from people who feel safe enough to describe how things actually work, not how the documentation says they should work. Creating that psychological safety is a people skill, not a technical one.

What Pragmatic Looks Like

Pragmatism in ITSM means designing solutions that will actually be adopted in the specific organisational context, not solutions that are theoretically optimal in the abstract. It means right-sizing process designs to the organisation's current capability and capacity to change. It means sequencing improvements so each phase builds on the last and delivers visible progress.

Pragmatism is sometimes confused with lowering standards. It isn't. It is about understanding that an improvement that is actually implemented is infinitely more valuable than a perfect solution that isn't.