Méthodologie et préparation du projet
Introduction
Ce chapitre propose une méthodologie simple de projet, adaptée à un environnement de type PME et sans prétention d’exhaustivité. Tout responsable informatique n’est pas forcément rompu aux techniques poussées de gestion de projet et ses moyens financiers sont limités. Les environnements SharePoint peuvent être bien plus complexes en termes de ressources informatiques, de personnes impliquées et d’usages que ceux décrits ici.
Même si le contexte de votre entreprise correspond parfaitement à celui décrit au chapitre précédent, il faut garder à l’esprit qu’implémenter un outil comme SharePoint représente un changement considérable dans les méthodes de travail pour certaines entreprises et peut se solder par le désintérêt de la direction, des services métiers ou des personnes membres du projet.
Tout projet voit le jour après une phase de réflexion. Cette phase est informelle et résulte de discussions avec des responsables métiers ou de fonctions transversales de l’entreprise (finance et contrôle de gestion, manager qualité et environnement...). Elle doit néanmoins aboutir à la rédaction et à la présentation d’un document de synthèse présentant les différentes...
Méthodologie de projet
À ce stade, si l’outil correspond aux pistes évoquées lors de la phase de réflexion, il faut passer à la phase étude. Elle permet de délimiter le périmètre, c’est-à-dire définir qui peut se servir de l’outil et pourquoi. Il faut :
-
Imprimer les formulaires qui seront numérisés ;
-
Lister les fichiers qui circulent régulièrement entre services par e-mail ;
-
Détailler les étapes de validation des documents ou des données ;
-
Lister les documents qui sont refaits à l’identique par plusieurs personnes sans concertation ;
-
Décrire les flux de travail entre services ou sites/entités d’un groupe qui ont du mal à être appliqués par manque d’échange de données, etc.
Cette phase se fait via des interviews dans les services administratifs afin de collecter les informations correspondantes. Un document de synthèse est rédigé par exemple sous forme de tableau permettant de lister les utilisations prévues du site et les fonctionnalités SharePoint utilisées comme dans l’exemple suivant :
Ce document servira de base de travail et pourra être enrichi au stade de la maquette.
Le cahier des charges contient de nombreuses autres informations, certaines liées à la planification technique du projet, d’autres liées au choix du produit SharePoint comme :
-
Le choix de la topologie technique ;
-
L’estimation des besoins ;
-
Le nombre et le type d’utilisateurs estimés ;
-
Les profils de droits d’utilisateurs ;
-
Les choix sur la création et la maintenance des sous-sites du portail ;
-
La matrice de gestion de la sécurité des sites ;
-
La proposition de mise en œuvre (planning des tâches et coûts).
Ensuite, une maquette avec un nombre restreint d’utilisateurs cibles testeurs est réalisée, grâce aux produits de virtualisation de serveurs. Là encore, une entreprise ne disposant pas de sa propre infrastructure pourra tirer parti des offres d’hébergement de serveurs comme Microsoft Azure ou Amazon Web Services.
Cette maquette appelée Proof Of Concept, expression qui sous-entend la notion de prototype pleinement fonctionnel, est un point de soumission important...
Conclusion
Ce chapitre vous a présenté une méthodologie de projet possible pour aborder la mise en œuvre de SharePoint. Les documents de préparation présentés ici ne sont pas exhaustifs. Nous avons développé la première notion importante dans le jargon du produit : la ferme SharePoint. Ensuite, nous avons parcouru la phase d’estimation des besoins. Cette phase n’est pas complexe dans un environnement PME mais comme tous les documents du projet, il convient d’exprimer noir sur blanc les contraintes et attentes par rapport à son entreprise. Nous sommes prêts pour l’installation de notre ferme SharePoint qui fait l’objet du chapitre suivant.