Publié le : 21 octobre 20209 mins de lecture
Dans les projets, de nombreuses discussions tournent directement ou indirectement autour de différentes approches (par exemple, Waterfall et Kanban) entre les prestataires de services externes (tels que les prestataires informatiques) et les banques commissionnaires. Les deux parties ont leur justification, mais les problèmes associés aux projets doivent être abordés et résolus de manière transparente et le plus tôt possible.
Où se situe le problème?
Dans de nombreux projets, le même problème se pose sans cesse. La compréhension de base de la procédure du projet entre les banques et leurs partenaires diverge tellement que les parties prenantes ne sont pas d’accord sur la question de savoir s’il faut discuter des étapes ou des priorités de mise en œuvre. Il n’est toujours pas clair si le projet est géré au moyen d’un cahier des charges détaillé, d’une vision commune ou d’une gouvernance structurée.
Cette question est restée sans réponse jusqu’à la fin du projet. Même si des solutions ont été trouvées et appliquées à des problèmes spécifiques, la question a toujours couvé sous terre, mais elle est réapparue de manière irrégulière et a donné lieu à des discussions animées qui ont parfois ébranlé les bases de la coopération et perturbé la collaboration axée sur les objectifs.
Questions de base pour une collaboration
Il existe trois questions de base différentes pour une collaboration, qui doivent être convenues au début du projet:
Dans le meilleur des cas, les trois questions de base sont discutées et clarifiées. Cependant, les projets manquent souvent de temps ou de concentration pour cela. Dans ce qui suit, vous allez avoir l’explication de comment la coopération entre les parties au projet peut être structurée efficacement. Pour chacune des questions de base, il est montré ce qu’elle contient, quels avantages sa réponse peut apporter, pourquoi un accord peut échouer, quels risques cela implique et comment ces risques peuvent être atténués.
1 – Une vision commune
Une vision commune garantit que les deux parties poursuivent le même objectif global avec la solution. Cette vision commune guide l’élaboration de la solution et garantit que les objectifs intermédiaires et les tâches de développement sont correctement définis et hiérarchisés.
Les objectifs ainsi créés servent donc en premier lieu à réaliser la vision. Bien entendu, il est encore possible de définir des objectifs ambitieux ou de réaliser des gains rapides sur la voie de la mise en œuvre de la vision. Mais ce n’est qu’avec une vision commune que cela se produit dans la conscience mutuelle que la vision n’est plus directement servie, mais que d’autres objectifs stratégiques peuvent être poursuivis.
Cependant, de nombreux fournisseurs externes de produits standard n’aiment pas renoncer à la vision, d’autant plus qu’ils veulent naturellement offrir des solutions qui sont aussi axées sur le marché que possible. Cependant, les visions individuelles conduisent généralement à des solutions individuelles qui n’ont pas l’effet de levier nécessaire. C’est pourquoi leur coût est généralement disproportionné.
En contrepartie, la banque ne veut pas se voir imposer la vision du prestataire de services, d’autant plus qu’elle ne coïncide pas nécessairement avec ses objectifs stratégiques.
L’absence d’une vision commune peut conduire à une mauvaise définition des objectifs et à une mauvaise hiérarchisation des priorités. Par conséquent, le développement peut être efficace mais pas effectif. Les parties et les fonctions du programme développé ne résolvent même pas le problème que le projet est censé résoudre.
Si aucune vision commune ne peut être établie, cette vision doit être décomposée par le client (c’est-à-dire du côté de la banque) en exigences commerciales individuelles. Il doit être clair par quels canaux et dans quelle qualité (forme, niveau de détail, etc.) les exigences sont transmises au prestataire et comment elles sont traitées par la suite.
2 – Les spécifications détaillées
Les spécifications détaillées aident à planifier le projet et à préparer la banque aux innovations organisationnelles. Grâce à une planification structurée, la gestion des processus peut concevoir, planifier, documenter et préparer la mise en œuvre des nouveaux processus. La gestion des risques permet de vérifier l’existence de nouveaux risques et de prendre les mesures d’atténuation appropriées. Les utilisateurs peuvent être récupérés, impliqués et formés à un stade précoce.
Toutefois, il appartient à la banque de décomposer la vision en fonctions individuelles ou en paquets de mise en œuvre. Toutes les banques n’ont pas l’expérience nécessaire pour traiter avec des prestataires de services externes ; l’interface entre le secteur bancaire et la technologie fait défaut. Souvent, le cahier des charges est trop figé dans les vieux schémas et les nouvelles possibilités techniques passent inaperçues.
En conséquence, le potentiel d’innovation reste inutilisé. Si les objectifs prévus manquent, s’ils sont à assez long terme ou s’ils sont trop instables, une (re)planification organisationnelle, administrative et logistique doit être effectuée à bref délai avant chaque diffusion. Cela conduit à un stress inutile dans le projet et peut, entre autres, amener les parties prenantes (par exemple les utilisateurs) à s’opposer au projet.
Si des exigences individuelles détaillées font défaut, il est d’autant plus important de sensibiliser les parties prenantes à la vision du projet et de les impliquer dans le projet le plus tôt possible (par exemple, dans les tests). Une gestion cohérente des attentes et des règles d’influence mutuelle clairement définies (gouvernance) minimisent le mécontentement des parties prenantes du projet.
3- Une gouvernance structurée
La gouvernance du projet définit sous quelle forme et par quelles plateformes la banque peut influencer la solution. Ce n’est qu’en sachant comment influencer la solution que les banques savent comment traiter ce retour d’information. En termes d’accords de niveau de service, il faut définir par quel canal le retour d’information est effectué, dans quel délai il est réagi, quelles sont les urgences et les questions importantes et sous quelle forme les solutions associées sont fournies.
Souvent, la mise en place d’une gouvernance structurée dans les projets échoue en raison des processus internes existants des deux parties, qui devraient être modifiés, ce qui entraîne un paysage de processus internes incohérents et génère des coûts supplémentaires (qui ne sont souvent pas pris en compte dans le budget du projet).
Si la gouvernance nécessaire fait défaut, le retour d’information des banques est placé avec de fausses attentes. Cela conduit à la déception. La banque se voit privée de ses efforts de test et de documentation, alors que le partenaire suppose d’agir correctement. Après tout, il n’a jamais été promis si et dans quel délai ces réactions seraient prises en compte.
Les problèmes liés à un manque de gouvernance peuvent être atténués en rendant les spécifications suffisamment claires et détaillées, en fixant des objectifs clairs (par exemple des jalons) sur la base de celles-ci et en contrôlant le respect de celles-ci. Il est également utile d’affiner une vision commune. Si l’on s’assure également que les fonctionnalités spécifiées soutiennent efficacement la vision, moins de demandes de changement surviendront dans le projet. Cela réduira la nécessité d’une gouvernance hautement structurée.
Comment procéder ?
Quelle discussion est appropriée dans quelle situation ? Afin de clarifier cette question, une chose est d’abord importante : créer une transparence mutuelle. Les parties prenantes doivent se montrer les unes aux autres quels modèles de procédure, quelles méthodes de travail et quels processus internes sont importants, voire irréfutables. C’est pourquoi les questions de base mentionnées au début doivent être posées le plus tôt possible dans le projet et il faut y répondre le plus ouvertement possible.
Trop souvent, trop peu ou pas de temps et d’énergie sont consacrés à cette phase de découverte dans le projet. Les gens s’appuient sur des accords contractuels (par exemple, les temps de réponse dans les accords de niveau de service) et restent mutuellement dépendants d’attentes basées sur des interprétations et des interprétations implicites. Mais seule une discussion transparente et pragmatique crée les conditions qui permettront au projet futur d’éviter de nombreux écueils.
