The forgotten final destination of a software implementation

After years of working with an outdated application, the organization has chosen a new product from a new software vendor via a tendering procedure. An ambitious implementation project lies ahead: processes are being redesigned, users are receiving training, and millions of data records must be migrated from the legacy system. End-users’ expectations of the new system are high.

In these types of implementation projects, there is a risk that I, as an ICT professional with extensive implementation experience, have seen recurring: dissatisfied end-users after go-live due to insufficient focus on the output the system must ultimately deliver through exports, reports, dashboards, and/or integration with a BI environment.

System output often overlooked during an implementation

In almost every implementation project, the migration to and the functionality within the new system take center stage. Understandably so, because both of these subjects are complex, immediately visible, and, moreover, decisive in the go/no-go decision for the launch.

Often, much less attention is paid to the question of what information stakeholders will need to be able to extract from the system in order to perform their work well (and continue to do so).

During the tender process, requirements and wishes regarding this area were requested, and the new software vendor indicated the data export, integration, and reporting capabilities within the package. At that moment, in a broad overview, this usually seems to fit well. Consequently, the thinking  is often: it will all work out fine during the implementation. The highest priority during implementation is ensuring that the input and processing within the system are in order. As the pressure on the go-live deadline subsequently increases, the output logically becomes the victim. However, it is precisely regarding this aspect that the biggestt unpleasant surprises arise after go-live.

Complexity and importance often underestimated

A major cause is that the complexity of reports is often underestimated. During the tender and implementation, there is sometimes an assumption that existing reports can simply be recreated later. In reality, this is by no means always a given. A new system is built on a different data model than the system it is replacing. Data is captured differently, relationships between data are structured differently, and processes sometimes have a different logic as well.

As a result, it is questionable whether the operational and management reports used in the previous application can still be made available at the same level of detail. In some cases, necessary data is missing. In other situations, historical analyses, KPI calculations, or detailed reports cannot be reproduced one-to-one. This often only becomes apparent when users view the first reports after go-live and report imperfections. Handling these types of issues during the post-implementation phase often proves to be a challenge. Because the experts’ attention is already focused on the next project, issues are resolved less quickly, and as time passes, complaints and dissatisfaction with the new system increase.

Prevention is better than cure

The basis for preventing these problems lies in the procurement process itself. Organizations would be wise not only to include functional requirements in the tender but also to explicitly verify whether the desired output can be met. Ask potential suppliers to demonstrate, via a Proof of Concept, how specific management reports, dashboards, and operational control information are supported, and have suppliers provide insight into the underlying data structure used to generate this information.

This same subject deserves continued attention during the implementation project following the tender. Test early on whether the new data model can actually deliver the desired information and validate reports together with the future end users. This prevents the focus from being solely on what the system processes, and ensures that insufficient attention is paid to the output the system is supposed to produce.

Here, the well-known expression applies: the whole is greater than the sum of its parts. If the system’s output is not up to par, what is the value of the input and the processing within the system?

Implementing a new system is, in any case, a change process not to be underestimated, requiring adaptability from all users and stakeholders. If, after the go-live, it turns out that the necessary information needs cannot be met, support will quickly diminish, and the adoption of the new system will become a major challenge.

Sjoerd Flipse
Business Analyst