Rollout management And Its Tasks – A Definition
Home office, mobile access to company systems: More and more organizations are thinking about which solution is best for them to withstand the times of digitization. From small companies to large corporations – whether in business or public administration – all aim to digitize processes, introducing new ways of working, methods, tools, or IT systems.
But how should the rollout take place? Does a big bang make sense, or does the iterative approach make sense? The rollout of new methods, tools, or IT systems is a highly complex project – especially if the rollout is to take place across locations. Project management, as well as change management, play a unique role in rollout management.
In this article, I would like to report on the fundamental aspects of software rollout management essentially. In the next blog post, I will detail the subject of change management and, in particular, acceptance management.
What Exactly Does “Rollout” Mean?
Initially, the term “rollout” was mainly used to set up new software and hardware. In the business context, time is also used to introduce a process, product, method, tool, etc. As part of a rollout, cultural changes in a company are also applied to the points mentioned.
IT rollout projects are pervasive and should not be underestimated. Due to the strict time and budget requirements, the high number of stakeholders (e.g., users), distribution across different locations, and high-quality requirements, the rollout of IT projects are highly complex. The rollout should occur with the least possible impact on day-to-day business, little set-up, and downtime. In addition to the technical and entrepreneurial challenges, there are also social relationships and psychological needs in the individual project phases of the users.
I want to present in a condensed form what should be considered in rollout management.
Where Should It Go?
It’s decided. New software is needed. The project order is in place, from which time, budget, and quality goals can be derived for the implementation of the project. It is essential to know the number of users and define the scope in conjunction with the project’s time, budget, and quality parameters.
Now it is a matter of recording user wishes and involving employees. What are the requirements? Many software projects fail because of the goals and requirements. The needs and demands of individual users can differ significantly. Therefore, it is advisable to find out about these different perspectives early to conclude the planning. The following aspects should therefore be worked out:
- Record affected business procedures and processes
- Describe the functional and technical requirements for the software
The requirements must be described in detail. Roughly formulated conditions subsequently lead to additional work. Ideal methods for prioritizing needs are, for example, user stories or the MoSCoW method ( Must have; Should have, Could have, Won’t have).
The Make-Or-Buy Decision Has Been Made
Market research was carried out, long lists and shorts lists were created. It is essential to include the employees in this process. Now the strategy of the introduction has to be determined. When introducing software, a distinction is made between two options—the so-called “Big Bang” and the iterative introduction. If the software is presented for all users on a single weekend, it is called a “big bang.” This form of introduction is particularly suitable when the software does not require any training. Should the users be trained, it should be ensured that as many users as possible are familiar with the software by the deadline.
If the application goes live, for example, per user group or business unit, we speak of an iterative introduction. This type of implementation involves much more planning because the old and new applications may run in parallel. An iterative introduction is less risky because the users can still access the old system.
Also Read: Finally, Digital – It Depends On The Employees
Introduction Of The Software
Now the actual software introduction begins. There are a few things to consider. For example, they are developing a prepared database that is as well-filled as possible from release to release. This is important because employees have easier access when learning the system and can concentrate fully on the functions. Otherwise, a reactance may occur instead of an acceptance, and workarounds are found quickly, and the Excel tables are reactivated.
In addition, aspects such as the provision, integration, or installation of the software play a significant role in rollout management. Because before the software is installed, one should think about the migration of the old data. Furthermore, the user and role concept should be considered. Which role gets which rights and functions in software.
Another critical point is the planning and implementation of training courses. The best system does not add value to the company if the workforce cannot handle it. A comprehensive training concept is therefore essential. Training documents should also be made available after the GoLive.
After the smoke, the test has been successfully passed, and the system has finally gone live, the data quality, performance, etc., must be monitored. Ideally, patches should already be planned so that errors can be reacted to quickly. Last but not least, you should consider building up support that ideally covers three different support levels.
What happens after the introduction? Over time, new requirements will arise during use, which must be implemented in the latest software. Therefore, it is essential to implement a process to collect suggestions for optimization, evaluate them, and have them implemented. One of many good examples would be the visioning method.
New Processes
The new processes with the newly introduced software must also be lived. If the employees work, as usual, this is a sign that there is little acceptance. The success of the project depends on whether everyone is involved early and consistently. Comprehensive communication provides the relevant information and promotes the transparency of the project, and strengthens team spirit.
Key users can act as multipliers and use forms of communication such as workshops, newsletters, social intranets, etc. In a subsequent blog entry, I would like to talk about the essential points of acceptance management.
Finally, I summarize again why rollout projects can fail:
- The project lacks the necessary resources, such as budget, time, or personnel.
- The requirements are not described in enough detail.
- The future users are not included in the project from the start. Be it a lack of transparency in communication or substantial involvement in the project.
- The rollout and migration processes are not adequately tested and validated.
- Inadequate training or instruction leads to inconsistent use of the software.
- The management level does not support the project.
Also Read- Agility In Management & Team:Success Factors For Agile Transformation
