Une des clés de la réussite d’un projet est la proximité des acteurs fonctionnels et des techniques. Or, dans un projet offshore, cela est contradictoire. Les outils de communication sont alors essentiels pour l’augmentation de cette proximité. En effet, l’échange d’information et la traçabilité de celle-ci deviennent très critiques dans ce genre de projet. L’utilisation d’un wiki par son manque de contraintes de structures figées répond parfaitement à cette demande. D’autre part, les outils de WebConferencing sont prévus pour la réunion quotidienne pour faire le point des actions en cours (problèmes rencontrés, …). L’événement tant redouté dans les forfaits (changement, incompréhension, …) devient alors récurrent et gage d’une bonne dynamique dans le projet. Mais le critère fondamental de la réussite du projet est l’investissement, l’implication ou la disponibilité des acteurs fonctionnels (MOA). Ce qui est moins facile avec la distance entre les équipes. Les vœux pieux de début de projet sont trop souvent confrontés à une réalité souvent oubliée dans l’euphorie du début de projet. Il ne faut pas omettre que la méthode agile est l’équivalent d’une gestion en flux tendu. Un manque d’informations et on se retrouve face à une équipe bloquée en attente d’informations. Si dans une méthode agile, il y a moins d’effort de rédaction de cahier des charges, de spécifications, cette énergie se retrouve répartie sur toute la durée du projet.

Comme tous les projets, la phase de démarrage est critique. Les utilisateurs (ou leurs représentants) doivent être coachés pour assurer la cohérence d’un ensemble homogène : la solution attendue. En effet, pour garder un objectif commun, il est nécessaire que tous les acteurs disposent de ce même référentiel qui n’aura pas le niveau de précision d’un cahier des charges. Le coach est là pour s’assurer que les demandes successives restent bien dans l’objectif initial. On ne parle pas ici de périmètre car ce mode d’organisation doit permettre facilement l’évolution du périmètre apportant ainsi une réponse aux besoins de réactivité sur les projets où le time-to-market (TTM) doit être le plus réduit possible. L’équipe de développement doit être aguerrie à ce type de projet. Nombreux sont les développeurs et les chefs de projet qui rêvent de projets où les changements et les événements n’existeraient pas. Ce type de projet n’est composé que de changements. Les membres de cette équipe doivent donc avoir des premières expériences sur des projets “classiques” pour s’adapter plus facilement. Un projet sur une méthode agile ne peut pas être basé sur un forfait. La visibilité ne sera donc pas totale pour les managers. Par contre, il est essentiel de diffuser régulièrement un reporting du projet (dimension du périmètre identifié, reste à faire, roadmap de la solution, …) aux travers d’indicateurs clairs et compris par tous. Le budget ne peut pas être un chèque en blanc, il est donc indispensable de faire intervenir les décideurs sur les changements majeurs d’orientation, ces événements ayant un impact sur le budget. Les traditionnels comités de pilotage sont donc toujours nécessaires.