Håkan Anderskär, Xmentor Management, change consultant, with many years of experience on the subject, shares his best tips.
(English) A new solution does not reach its full potential if it is not used in the best way. Improper use can even render the service or product useless. However, optimal use can raise its value to levels that even exceed expectations. A successful introduction of a product can therefore very well be the razor-sharp difference between success and failure. It is therefore important to think about the introduction directly at the beginning of a project.
The stakeholders
First of all, everyone must stakeholders are identified upon an introduction. Stakeholders can be divided into three different categories: the technique to be used for the product, the organization which the product/service must support, as well as the individual (the users) who will use the product. They have no mutual ranking but are all equally central.
Important to ask questions such as:
- Which organizations are affected by the "product". There may be more organizations than the one/those who initiated the introduction itself, for example operational unit, development unit, IT unit.
- Which technical products are affected, i.e. introduced or dismantled in connection with the introduction, for example journal or case management systems, or digital support systems.
- Which individuals/users are affected, for example nurse, system administrator, operations manager.
Goal management
Once the stakeholders are identified, required target management per stakeholder to be able to steer towards the desired end position. A number of goals must be defined for each stakeholder. It is an incredibly important step in an implementation project. A common observation is that this work is neglected because many goals may seem obvious.
Goal breakdown is then done by defining for each phase during the project what must be achieved (sub-goals), per stakeholder. The milestones naturally vary per project. This can, for example, involve describing in which phase the product is to be defined, describing the purpose of the change, determining which target groups are affected, preparing training efforts (also on an individual level), defining communication channels, etc. Of course, goals must also be decided at the start of operations as well as goals for when detailed migration plans are to be ready, e.g. migration of data from old to new system, when must the administration be prepared so that there are clear tasks and personnel responsible for these, etc.
When all goals are defined, broken down by phase and verified with the steering group, the implementation project is in a very good phase. Then it is "just" to plan and execute the introduction!
Implementation planning
The introduction project must then is planned as serious and purposeful as the development project of the service or product itself. Unfortunately, it is not unusual for all planning focus to be placed on development. The introduction should only be "fixed" when the "difficult" development is complete. In the introduction planning, it is necessary to define all activities, as well as plan who will carry them out and when the activities will be carried out. The result will be a good plan to execute the introduction. It is not only activities to reach the goals that are important. Activities are also needed to verify that the objectives have been achieved.
The implementation
Last, but not least, the introduction project be carried out with maximum focus. Of course, this phase must not be de-prioritized either. It is important that implementation projects are staffed with competent people who can allocate the time required. It should not be handled with the "left hand".
An important detail is to add qualitative "dashboards" to be able to follow up the progress of the introduction, step-by-step. The follow-up may result in the original sub-goals or activities being modified.
When all implementation activities are complete and verified, you are done with your implementation project!
Some final tips:
Personally, my experience is that clarity and flexibility are A and O in a successful implementation project, many believe that it is not possible to combine, but it is a prerequisite. In order to…
...it is frustrating to work with ambiguity, while at the same time there is a great risk that important elements will be overlooked in an unclear implementation project.
...flexibility, i.e. what is included in "agile development", is modern but also very necessary during an implementation. On the one hand, you cannot know everything when the first plan is defined, and on the other hand, the world changes all the time, not least the conditions in an implementation project. Dare to change decided plans if the conditions change or if the first plans turned out to be wrong, but do not create ambiguity.
It is incredibly central that the balance between clarity and flexibility is managed carefully, clarity must not come at the expense of flexibility or vice versa!
Good luck!
