Pourquoi il est préférable de choisir une AMOA qui connaisse SharePoint ?
À la lecture d'un cahier des charges d'un projet SharePoint, il a dû déjà vous arriver d'avoir la sensation étrange que le besoin fonctionnel a été décrit sans lien direct avec SharePoint bien qu'il soit mentionné que la solution technique choisie soit SharePoint. Pour ma part, j'imagine que les rédacteurs du cahier des charges ont dû se faire aider par une assistance à maitrise d'ouvrage qui ne connaissait pas SharePoint. J'expose dans ce billet les raisons pour lesquelles je pense qu'il est préférable de choisir une AMOA qui connaisse SharePoint.
La raison la plus fréquemment rencontrée est que le cahier des charges est de nature à comporter davantage la vision du projet que l'analyse fonctionnelle détaillée ; on y retrouve alors les éléments d'analyse nécessaires mais non suffisants pour "lancer" le projet : les enjeux, les objectifs et les impératifs du projet.
Quels sont les types d'AMOA qui ont été choisis pour établir ces éléments ; ils peuvent être de plusieurs natures, plutôt en fonction du type de projet SharePoint :
Des conseils en communication plutôt orientée marketing, pour des projet de sites internet, intranet ou extranet
Des conseils en communication plutôt orientée organisation, et stratégie, pour des projet d'intranet
Une des raisons de ce choix s'explique parfois par le fait que les AMOA sont choisis de plus en plus souvent non par les directions informatiques mais par les directions de la communication/ressources humaines, qui sont en lien avec des agences de communication et de graphisme qui proposent leurs services en matière de conseils et stratégie Intranet.
A mes yeux, il n'est pas primordial que le consultant en AMOA réalise obligatoirement cette partie du projet même si, dans un souci de meilleure gouvernance de projet possible, à mon sens, chaque la mission d'un consultant en AMOA démarre par le recueil du besoin et la conception de la solution.
Par contre, le consultant en AMOA doit posséder la culture générale du fonctionnement des organisations suffisante pour intégrer ces aspects fondamentaux dans son projet car la gouvernance, le champ des fonctionnalités et le paramétrage vont, par exemple, être fonction du type de site : dans un souci d'efficacité, il est préférable de choisir une AMOA qui connaisse SharePoint pour bâtir la solution fonctionnelle en termes d'architecture et de fonctionnalités.
Le consultant en AMOA qui connait SharePoint sera alors en situation :
d'indiquer à son client lorsqu'il sort des usages prévus et s'engage sur la voie de développements spécifiques
de proposer l'alternative de se recentrer sur l'utilisation standard du produit lorsqu'elle existe, quitte à limiter le champ de la fonctionnalité initialement prévue.
Jeff Teper, Vice-Président SharePoint de Microsoft Corp., ne recommandait'il pas, à la sortie de SSP 2013, de commencer par utiliser SharePoint comme une application finie autant que possible avant de développer les couches de fonctionnalités personnalisée ?
Les développements informatiques complémentaires sont ainsi minimisés et l'expérience utilisateur en sera également simplifiée : ceci peut être temporaire car une adaptation de SharePoint peut être nécessaires pour simplifier ou étendre fonctionnellement son SharePoint.
C'est également sur la base de cette recommandation qu'ont été écrit les billets suivants :
- "comment s'élabore la stratégie de formation à SharePoint", (la formation, une "Valse à 2 temps") ?
- "Je vous présente ma matrice de déploiement et d'adoption SharePoint", constituée d'un formulaire de capture de besoins, de synthèses visuelles et d'une partie plan d'adoption.
