Facebook EmaiInACirclel
Développement front-end, back-end

Projets offshore : l’externalisation et les changements impliqués dans l’organisation de nos clients

Dan Deusan
Dan Deusan
Head of Business Development

Une des questions que me posent souvent les prospects et clients avec lesquels je suis en relation est : « Que devons nous changer dans nos pratiques pour intégrer facilement notre nouvelle équipe de projet offshore ? » La réponse à cette question est une des clés de la réussite du projet offshore et elle doit être finalisée dans les premières semaines de la collaboration.

Pour moi, en tant que directeur de projets,  le premier élément de la réponse est la désignation d’un responsable (chef de projet offshore) coté client, chargé de la communication et la coordination de la nouvelle équipe. Ce responsable doit pouvoir prendre et assumer des décisions concernant le projet offshore: planning, changements de priorités internes, choix fonctionnels etc.

La suite dépend de plusieurs facteurs : la taille de l’équipe, le cycle projet, le modèle contractuel, le type du projet et,  sans doute le plus important, l’organisation actuelle du client. La taille de l’équipe est importante pour déterminer la charge d’un chef de projet coté client. J’estime à 2-3 heures par jour pour une équipe de 3-4 personnes et pratiquement un temps plein pour des équipes supérieures à 10-15 personnes.

Concernant le mode d’organisation, je pense qu’il y a deux approches principales sur un projet offshore:

  • l’approche classique avec le cycle en V
  • l’approche agile avec le SCRUM

En fonction du mode choisi, il faut prévoir des réunions hebdomadaires entre les deux chefs de projet pour le cycle en V ou des points quotidiens (SCRUM daily meetings). L’approche agile suppose aussi des livraisons plus fréquentes, des sprints de 2-3 semaines en général, et donc, globalement, une implication plus importante du chef de projet client.

Par rapport au modèle contractuel, un projet au forfait suppose une implication variable de la part du client qui doit être très présent dans les phases de spécifications et validations, avec des engagements contractuelles sur les dates associées à ces phases, et un peu moins dans les autres phases du projet au forfait quand il doit répondre aux questions éventuelles de l’équipe, préparer et planifier les prochaines étapes, etc.

Le type du projet et l’organisation actuelle du client sont les facteurs qui me donnent la possibilité de finaliser ma réponse. Un projet web est en général un projet ayant des livraisons multiples, qui demande des validations rapides, avec des contraintes fortes de planning, ou les départements marketing doivent être très présents etc. Je préconise donc une méthodologie Agile type Scrum pour ce type de projet.

Un projet de développement d’une nouvelle application métier ou d’une migration vers une nouvelle application aura d’autres types de contraintes, sur une période plus importante, avec peut-être moins de livraisons intermédiaires etc. On peut donc ici partir sur une méthodologie plus classique type cycle en V.

Concernant l’organisation client, on analyse des éléments comme le flux interne d’information, la relation entre le département informatique et les « clients » internes (souvent le marketing), le processus de validation etc.

Pour conclure, je dirai que pour être totalement prêt le jour du démarrage de l’équipe, il faut arriver avec une réponse ou à minima en ayant réfléchi à l’ensemble des éléments que j’ai rapidement présenté ci-dessus. Enfin, j’ajouterai que l’organisation imaginée au départ peut évoluer pendant la durée du projet pour intégrer des améliorations et les éventuelles changements survenus dans les conditions initiales.


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *