Speeding up an IT service management (ITSM) project is not just about velocity. As with the saying 'more haste less speed' organisations need to be careful that they aren’t going so fast that they’ll fail to deliver on the desired outcomes. Or will actually deliver late due to reworking mistakes.

To start with, don’t call your ITSM project an ITSM project. And definitely don’t call it an ITIL project. Instead label it to reflect the expected IT and business outcomes from the initiative – this might be one or more of: quicker change, improved IT support, better availability, more effective communications, slicker team working, reduced costs or increased revenues, better service experience, increased customer retention, or similar.

Be clear about the project deliverables and success criteria. Again, while new capabilities or technology are probably the tangibles people will see and touch, the real deliverables should relate to some form of IT and/or business improvement. For instance a new ITSM tool might set back, rather than push forward, IT operations if deployed incorrectly. So just looking at the technology go-live date isn’t really a great deliverable to measure project success, or failure, against.

> See also: Out of service: when yesterday's IT service management meets today's world

Understand that an ITSM process and/or technology project is really a people project. Both types of ITSM change involve people. And the failure to cater for cultural or behavioural aspects, in moving from the status quo to the desired future state, will at best throw up delay-causing obstacles and at worst completely derail the project (or cause the 'completed' project to fail on 'real deliverables' as per the previous point). Again, delivering a new ITSM tool, that people don’t use, to time is not a success.

Limit project scope. There’s no need to take a big bang approach to ITIL adoption, process improvement, or technology implementation projects. In fact many of the ITSM project 'car crashes' we hear about are where the organisation tried to do too much at once. With failure contributed to by one or more of: inexperienced third-party resource, ineffective project management, a lack of planning, insufficient project resource, uncommitted day-to-day resource, organisational immaturity, scope creep, or similar.

Deliver and communicate success incrementally rather than in a final, triumphant fanfare. Building on the big bang avoidance approach, deliver your ITSM project in phases or stages. This not only improves control, is better use of potentially limited resource, and delivers the available project benefits ASAP; it also allows the stream of incremental successes to be celebrated within the project team (to spur on further success) and to be communicated to third-party stakeholders for continued buy-in (and potentially continued funding).

Be conscious of, and honest about, your organisation’s existing ITSM maturity and capabilities. Spending large amounts of money on new processes, new technology, and even new people will be, at best, suboptimal if your IT department’s organisational maturity, operational capabilities, and capacity to change are lacking. So be honest about where you currently are – if you don’t, you’ll have little chance of quickly getting to where you want (or need) to be.

> See also: Why the IT service desk is key to digital transformation 

Use dedicated resource, and the right resource. This is two-tiered. Firstly, avoid the common corporate scenario of using the available, often 'surplus,' people resource for projects – there’s little benefit from having more people than your project needs if they’ve the wrong knowledge and experience, or lack the necessary skills to work on an organizational change project. Secondly, project resource needs to be firmly committed to the project – both on a day-to-day basis, i.e. not having to fit project work around the day job, and for the entirety of the project’s life.

Factor in future requirements. Most projects are finite in scope … hopefully. But this shouldn’t mean that phase two, or the next ITSM improvement initiative, isn’t factored in and catered for by the project at hand. So have a longer term vision and road map beyond the life of the current ITSM project. For instance, that the right touch points are included in readiness for the addition of future ITSM processes or technologies, or that what has been created for IT can eventually be replicated or extended to other corporate service providers such as HR, legal, or facilities if a move to enterprise service management is a distinct possibility.

Involve colleagues from outside the IT department and communicate as much as possible. While ITSM is about IT service delivery, IT support, and more recently the service experience, it’s ultimately about people supporting other people.

> See also: Forgotten and unloved: does business continuity planning need a makeover?

So whether it be the usability of new ITSM technology, the suitability of new processes and the associated customer touch points, or the acceptability of new service level targets, business colleagues need to be involved in the project. They also need to be fully informed on the reasons for, and benefits of, the change. As do the IT team members affected.

Whilst this article is about speeding up ITSM projects, don’t try to go too fast. Referring back to the 'more haste, less speed' quote at the start of this article, move as quickly as you can but don’t move so quickly that you end up at the wrong destination.

Sourced from Sarah Lahav, CEO of SysAid Technologies