Deployment of an intervention scheduling and
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.
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:
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.
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
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.
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
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:
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 |