Why do Service Management software implementations take months or even years to be completed? Is it complexity? Is it the approach taken?
Here are some horror stories I heard at the recent itSMFnz Conference:
- An accounting firm selects a service management software vendor but is unable to find an implementation partner. They have to hire a contractor for a year to get it up and running.
- A distribution company spends two years implementing service management software and are now looking at replacing it for something "easier".
If you can relate to these stories or wish to avoid a similar story for yourself, then read on...
The demand for a rapid return on any investment is high and service management is not immune. A rapid deployment offers a fast time to value backed up by continual improvement (as in ITIL v3) to add to or improve the solution as it is used. Essentially we need to usher in a new era of software implementation which we can call a rapid deployment + continual improvement. Gone are the days of lengthy software implementations with all manner of detailed analysis, integrations and customisations.
So before you jump in, consider the following 9 tips to a successful software implementation, using this rapid deployment + continual improvement approach.
1. Do not run the implementation as a project
Rapid deployment means getting up and running as soon as possible and this does not typically sit very well with the project office. That's why at ViFX we run "deployment engagements" rather than Service Management projects. Projects require a certain level of documentation, checks and balances (and rightly so) that a rapid deployment does not. Eliminating detailed functionality and use cases and taking a "just enough" approach means you can go-live with your solution, knowing it is not perfect but can be improved later.
My favourite saying "perfection is the enemy of done" sums this up nicely! Service Management software deployment and associated continual process improvement needs to be modus operandi and this does not fit well with defined project start and end dates. In effect, there never is a project close down report! Getting continual improvement ingrained into teams lessens the shock of a rapid deployment, as everyone will know that follow-up improvements can, and indeed must, be done.
2. Appoint a product champion
The product champion will drive the deployment and make binding decisions. Software is unable to make decisions, rather it enables the decisions to happen through workflow or automation. Often a lot of time is spent defining processes, procedures and workflows that could all be done prior to deploying new software. Get processes defined and decisions made early (this can be done irrespective of what software is selected), so that implmentation time can be spent on deployment, not round table discussions.
Also note the need for the product champion to be supported by Management commitment. If you do not have active and ongoing involvement from Management, then your rapid deployment is at risk from internal politics, business as usual demands, along with funding and resourcing delays.
3. Stick to out-of-the-box
Stick to out-of-the-box, knowing you can change it! The emphasis here is on the word "you", such that you do not have to use expensive developers to change the software to suit. It amazes me how many vendors prefer their customers do all the changes, customisations and integrations up front. If a vendor is unwilling to go-live with an out-of-the-box solution (with improvements done post go-live) then ask why. This may identify upgrade issues, difficult customisations when live, or other challenges to improvement post go-live.
The new paradigm of rapid deployment + continual improvement affects the way software implementation budgets and resources are planned. Vendors that understand this take a roadmap approach to their software implementations, as they know go-live is just one step on the path to a continually improved solution. To help with this, a new role - the Service Management Analyst (SMA), can be employed. The SMA is part BA and part software configuration expert, who takes over from the product champion post go-live.
4. Condensed consultation
Broad consultation is necessary for projects that involve a lot of business change. A service management rapid deployment however, is best done with a tight team that can make the best decisions rather than teasing out decisions by committee. Continual improvement means you can focus on the major issues and pain points for go-live, leaving other issues for post go-live improvement.
For go-live then, it is about identifying the universal or well-known points or existing software shortcomings that should not need a committee to agree on. Condense the consultation but broaden the resolver groups input. Get early involvement of tech teams, especially for look and feel of new software.
5. Get key internal benchmarks
No matter how awful your current solution is, try and get process KPI reports as benchmarks, even if that means a KPI is "unavailable". This will be your starting point to measure process improvement. Also consider what other metrics are needed to measure the success of the new solution including time to value.
6. Do not migrate transactional data
This may seem a hard pill to swallow, but to enable a rapid deployment with relevant selection data (e.g. categories, drop down values, etc.) then this is the way to go. Migrating transactional data causes the most delays, headaches, heartaches, and consumes the most money. It would need to have extraordinary justification to be included. Migrating customer and asset data is OK, bearing in mind these will typically be synchronised from an appropriate external source (e.g. AD, SCCM, etc.). Consider the value the existing data will bring versus the time to value for the new solution.
7. Use built-in interfaces
Use built-in interfaces for data import and synchronisation to enable quick and easy data loads from master data. Any solution worth its salt should have standard directory, email, csv and database connectivity built-in. Rapid deployment is about configuring built-in integration leaving custom integration to post go-live improvement. While using built in interfaces should be easy, the obvious issue here is to check that the master data is of a suitable quality to be used!
8. Focus training time towards resolver groups
Allow more training time for resolver groups and customers (if deploying a portal). This training needs to be actual use not just overview sessions. Getting early feedback and buy-in during the deployment makes training sessions more valuable as staff are not facing a new solution from scratch.
Manage cultural change within your organisation by using clear, appropriate communication to all interested parties. Remember that there is a wide range of interest groups - process owners, management, support teams, end users, etc., all interested in your Service Management solution from their own perspective.
A rapid deployment + continual improvement process may not be suitable for all Service Management solutions or vendors. However, if you are looking to reduce the time to value and implement a solution that you can own and continually improve, then you need to engage with a vendor that can empower you to do this yourself. Once you have this, and after following the nine steps above and you'll be well on your way to a successful deployment.