3 key dimensions to ensure successful change management

Deployment of an intervention scheduling and optimization solution on-site is – by its very nature – a project of enterprise proportions: transversely, it will necessarily involve the IT director, certain support functions and, without question the senior management of your operational business teams. Whether you are embarking on such a program for the first time, or whether you are replacing a solution or version of an existing work tool, this project will bring about a restructuring of internal and external processes that drives deep into the life of the business, and will transform working practices and give rise to a whole new daily task set: for technical staff working out in the field of course, but also for schedulers and planning personnel, branch or regional managers…

This is why any project of this type cannot succeed without putting in place a strategy for change management that aims to involve users as far ahead as possible with regard to the operational sequence, and support them in facilitating the adoption of the new working toolset. Although many businesses have understood this, it is vital to concentrate fully on the 3 dimensions that are not always well understood or even perceived, and are sometimes brushed aside as being less important, but that will more or less determine the success of the project.

Change management must happen right from the start of the project!

We still see, all too often, change management only coming on the agenda when the project is coming to an end, once all the functional part is set in stone and ready to be deployed. In effect this means it might boil down to being just a training programme, and obviously while this is indispensable, it might just amount to putting end users before a fait accompli: here is your new tool, nothing can be changed at this stage, and it is your job to adapt to using it. If the project is presented in this way, you risk inspiring more resistance than enthusiasm in the minds of those who will be working the new system…

The so-called ‘agile’ methodologies for project management considerably reduce this risk by putting end users and their real-life working needs at the heart of the process right from the start of the project. Since it is practically impossible to bring all users into the process at every stage of the project, the recommended route to change involves putting in place from the start: 

• A product owner (PO) – the operational ideal is for this person to have a mandate for the project duration, and to be relieved of all their other responsibilities while the project unfolds. Within the project team this person is the representative for users of the new product under construction. They will not be the project manager in the usual sense of the term, nor will they be the person in command. The PO is above all the master of user needs and a referee when it comes to setting priorities.
• A group of «key users» – Who are these key users? This is a representative set of users reflecting the diversity of the population impacted by the project. They will be a representative sample of the user base from diverse business sectors, geographic areas, but also in terms of length of service in the organisation.

We often think the longest serving members of the enterprise will be the ones most reluctant to accept or embrace change. But the truth is that these staff are also the ones who know best – and better that many of their colleagues – the realities and constraints of the terrain, the tools that are up and running with all their advantages and draw-backs. This knowledge is vital to the project team during the strategic and restructuring phases, and will have a bearing on definition of targets, objectives, and the validation of newly created tools and processes.

However long they have served, all members of the user group will, from the start of the project through to its completion, play a decisive role in change management – they will be the ambassador for the user group at large. How will this happen? By keeping them informed as the project unfolds, and drawing them in as you progress the project, they will take back to the teams any reactions, fears or doubts they may have, and contribute to the definition of the training programme, and then most likely participating themselves in training and support once the solution reaches the production stage.

A point that is often forgotten is that, to play their role fully, the key users must be relieved of some of their operational tasks during and even after the solution is put into production if they are to remain pivotal points of reference for the general user community.

Making value creation for users the priority

A change in business tool becomes even easier to promote, and even more desirable, when each person affected by the change discovers added value for themselves in the new scenario. Everyone will, of course, be receptive to the idea of gains forthcoming in terms of efficiency, productivity and better overall company performance. But before adopting and adhering to the new scheme, each person will inevitably ask the question: in real terms, what is this going to change for me in my daily work, as regards my workload, working hours, types of intervention handled, the number of kilometres travelled….

One of the objectives of the structuring phase is precisely to identify major changes expected from the new solution, and classify them into a catalogue of real benefits for the different categories of user. For example, if you transfer from several tools to an integrated solution like Opti-Time Field Service, technicians working offsite will no longer have to juggle between several applications on their mobile terminal to consult schedules or send notifications out to customers while on the move. Schedulers and planners, for their part, will appreciate individual Human Resources constraints being already integrated in the solution and automatically taken into account when schedules are populated and filled.

If you apply «agile» principles thoroughly and consistently, life will be easier because the rule is to start from needs as formulated by users in positive terms: «being able to notify a customer that I am running late with just one click», or «I would like the first intervention of my working day to be close to where I live», or «I would like schedules based on realistic intervention times»… doubtless, not all desires or needs will be able to be fulfilled but at least they will be discussed, refereed and prioritised in a transparent and logical way, and with due reference to the project’s overall budget and any constraints that may exist linked to the existing information system.

A «data» workstream that is an entity in its own right

Your optimization engine feeds on data, and its added value will be directly proportional to the availability and quality of these data. This is why any such deployment project that is well managed must have two operational arms working in parallel: a functional arm and a project team dedicated to data. If you don’t work on the data, it will block the essential de-cluttering and sorting of the various data streams sourcing the solution, and in turn, the pledge made to customers to bring about improvement cannot be upheld: the result? …. Disappointed customers!

For example, if your technicians work in retail distribution, the stores they supply, whether small or large, and their opening times, are data that are vital to administering schedules and routes. If these data are inaccurate or incomplete, the first routes calculated by your new tool risk being dysfunctional. If you need to send automated messages to your customers warning them of your impending arrival, you need to know exactly where such messages need to be sent: do you have the correct email addresses, are they still valid, are they the right ones for the technician assigned for the visit? If you want to boost the match between competencies of your technicians and the types of intervention planned, you will need Human Resources data to hand, and so on.

The starting point for the «data» workstream of your project is to catalogue and localise all the data sources the engine is going to have to take into account:

• customer sites and installations (exact address for the purpose of geocoding, but also contact names, types of equipment, working or opening times…)
• the typologies of interventions to be fulfilled,
• competencies of technical staff and working conditions for interventions
• availability of resources (vehicles, branches or depots of affiliation, spare parts…)
• …

Next, you need to put in place an action plan and a calendar for sorting and filtering these different categories of data. This calendar must of course be compatible with that of the functional part of the programme. The action plan for «data» must in other respects specify quality standards and norms to be respected, identify who will be responsible for filtering and sorting the various databases and procedures in place to maintain the quality of data throughout.

All of this may seem a far cry from your idea of what change management entails. But believe us: our experience of deploying field service management solutions in major organisations means we are absolutely convinced of the need to tackle these three strategic dimensions when investing in a project of change, upholding them as key to delivering the overall objective of providing users with a solution they can welcome and adopt unequivocally, because it offers tangible added value on a day-to-day basis.