Axel Grunwald, senior consultant at IT consulting firm GFT Technologies reminds us of the need to think of the consumer in the development of investment banking projects.

At the outset of a project, the effort to define requirements and scope can be all-consuming. Whilst the user is included briefly at this point, to explain the businesses needs to the technical team, often little provision is made to return the knowledge to the users in an appropriate form.

In the banking sector, this problem is frequently made more complex. Requirements can change during all project phases and the operational model, processes, or procedures continue to be defined or changed alongside the development of the system.

GFT was recently made acutely aware of this issue in a project where a system needed to be devised before the operational team was in place. The lack of users in the early stages meant that our team had to pay particular attention to how the new system would be returned to the client. We had to include in our methodology some key considerations for involving users in the knowledge transfer. We identified these as:

Language

Training

Resources

We noticed that often, as a project progresses from business requirements to technical code, a transformation of the language happens and it becomes unsuitable for the end-user. In order to re-engage with the business user (during UAT and / or production) it is essential that the documentation is re-translated into business language; “null” has to return to “nothing in here”.

Preparation for the handover to the business community must involve training and appropriate documentation. The benefits of this are two-fold. Firstly, as the usage of the application was explained to the user, this provided for a quicker and smoother testing process. Secondly, it also helped to avoid problems stemming from a lack of understanding.

This approach also supported the train-the-trainer concept, as acceptance-testing users were enabled and provided with the knowledge and documentation to pass on to the other business users when the system finally went live.

We found that the best-placed resources to perform this task are the business and technical analysts, who also gather the business requirements and designed the business and technical solution for the system. They have both the understanding of what has been developed and the skills to re-translate the documentation. They are also best positioned to identify gaps that may have emerged during the project lifecycle.

So the same resources that are responsible for enabling the technology people to code the application are also responsible for enabling the business users to understand and use the system.

For best effect, we embedded both business and technical analysts in the internal support unit to directly engage with the business user on a case-by-case basis and to answer specific questions. They were also deeply involved in the production of user manuals, training sessions, and other documentation distributed to all users.

This user-focused approach meant that, despite not existing at the beginning of the project, the users were fully included in the handover. As they are the final client, we discovered that the project is more successful if you don’t forget them!