The goal is to use Lessons Learned to carry out future projects more efficiently and quickly while preventing errors. To achieve this, it is important to reflect on and compile the experiences made as detailed and self-critically as possible, for example using the Starfish Model. Before starting a new project, it is always recommended to review the Lessons Learned from previous, comparable projects and incorporate these valuable insights.

The Starfish Model – Capturing Lessons Learned Efficiently and Clearly

In agile project management, team members meet for retrospectives to reflect on the project progress so far and learn from the past. The so-called Starfish Model can also be used, which clearly owes its name to the starfish. Based on the number of arms of its namesake, five categories are distinguished and presented in a star shape: Start doing, More of, Less of, Stop doing, Keep doing. The individual participants of the retrospective consider points for the five topics and then present their thoughts.

In the category “Start Doing“, all factors that should be implemented and tried out in the future are collected.
“More of” are aspects that were already used in the project and should be used more strongly or more often in the future.
The opposite is represented by the category “Less of“, as it stands for things that should be used less frequently in the future.
Elements in the category “Stop Doing” should not be considered at all anymore.
Aspects that work particularly well in a project and should continue to be used are noted in the category “Keep Doing“.

Starfish Model for clear capturing of Lessons Learned (based on @BryanMMathers)

This reveals all participants’ views on the project. These then need to be clustered and structured. It is recommended to prioritize the individual topics and then work on them in depth according to their importance.
We used this method, for example, after the successful completion of a software rollout in a large corporation and were able to identify five essential Lessons Learned for ourselves.

Our 5 Learnings from the Software Rollout Project

The aforementioned project in the large corporation involved the rollout of Windows 10, Microsoft 365, and Exchange Online for a total of over 70,000 clients. From a project of this magnitude, project managers can take away valuable experiences and numerous insights can be derived. Among others, we have worked out the following Lessons Learned.

1. Precise and Early Project Planning
In numerous projects, it has become very clear how important early and precise planning is even before the project begins. Because the further the project progresses, the more difficult it becomes to correct inaccuracies in planning or even errors. Without clearly defined milestones and binding delivery dates for the individual project phases, it will be difficult, especially in the early phases (i.e., when defining scope and requirements), to convey a sense of urgency and maintain constant project progress. Moreover, it has been shown that it is fundamental to the success of a project that sufficient buffer times are also factored into the planning.

2. Baseline in a Rollout Project
A baseline in project management is a clearly defined starting point for the project plan. It is a fixed reference point against which the progress of the project can be measured and compared. This way, the performance of the project can be assessed over time.
In our numerous IT rollout projects, it became apparent that the baseline and the progress measured during the course of the project should be calculated from a consistent data source as much as possible to obtain clear and unambiguous statements. The reasons for limiting to one or very few data sources include, for example, access security to information, clear and consistent presentation of data, as well as the scope and objectivity of the information.

3. Choose Push Strategy for Particularly Extensive Rollouts
When it comes to rolling out an application such as Microsoft 365 in companies with a high number of employees worldwide within a given time frame, we have come to the conclusion that a push strategy should be employed in this case.
With the pull strategy, employees install the software independently from the company’s internal software catalog. In contrast, with the push strategy, it is usually handled in such a way that a specific date is agreed upon with the respective employee, on which the software is automatically installed on the PC.
Under the condition that it is a scheduled rollout, it makes sense to pursue the push strategy, as this ensures that each individual employee actually installs the software and thus the project timeline is adhered to.

4. Use HyperCare Feedback from End Users as Added Value
In a globally implemented rollout project, it quickly became apparent that the use of a HyperCare team brings enormous added value to the entire project. The team focuses early on the feedback from end users from various sub-areas and regions. This enables them to understand their specific technical needs precisely and to provide the best possible support for potential problems. The HyperCare team dedicates itself specifically to the concerns of end users and can answer arising questions within a very short timeframe, ensuring more efficient SLAs and faster response times.

5. Clear Reporting
Reporting also plays an important role in IT rollout projects, as it encompasses all means and measures of a company used to develop information about an operation. In practice, however, it has been found that despite its great importance, many reports are inadequate.
Management primarily needs transparency and precise information to make quick and logical decisions based on this. For this purpose, they are often provided with project progress or results via PowerPoint documents. However, the slides usually contain insignificant and too much information, requiring management to spend more time capturing the relevant details. In these cases, the use of BI tools, such as PowerBI, is recommended. These can be used to create clear dashboards that display data in real-time and can also be automated and individually filtered.

Conclusion

For the success of large software rollouts in corporations, it is important to plan the project early and accurately, and to rely on only one data source as much as possible when calculating the baseline. Especially in such extensive projects, it is recommended to choose a push strategy for the rollout, employ a HyperCare team, and use clear, automated reporting, for example via BI tools. We collect these and other valuable insights in a central location and derive best practices from them, creating a shared knowledge base for project managers. The experiences can thus be used for many more projects to generate added value there.