Lean, low-code et agile sur projets SharePoint et O365 – le recueil de besoin

Les projets SharePoint sont comme de tous les projets d’intégration : l’éditeur vous fait miroiter des projets rapides, faciles, et des retours sur investissements mirifiques. Dans la pratiques, dans bien des services informatiques, la situation n’est pas celle attendue et ce n’est pourtant pas la faute du produit, pas forcément celle des acteurs et développeurs pris individuellement, mais surtout un problème de méthode (et un peu parfois de méconnaissance du produit).

Il y a quelques temps, je vous expliquais pour répondre à ces situations que sur les projets d’intégration, il fallait être faignant, être radin, être impatient et être agile, et que pour cela, il fallait coller au standard. C’était la théorie, je vous propose de s’intéresser à la pratique avec le recueil de besoin.

Ce que je vous propose, à destination des chefs de projets ayant déjà exercé, c’est de partager un retour d’expérience (10 ans de route quand même) et vous donner une méthode éprouvée sur des projets des plus petits à des plus gros chiffrant en millions d’euros et quelques milliers d’utilisateurs à travers le monde. A l’aube des projets de gestion documentaire qui vont pleuvoir avec la GDPR, ca ne fera de mal à personne.

Tout d’abord, comment s’amorce le projet

Idéalement :

  • Vous avez déjà SharePoint en place dans votre offre IT
  • Vos métiers viennent vous voir en amont, sans trop avoir encore formalisé leurs besoins (c’est-à-dire que les spécifications ne sont pas encore rédigées)

Dans la vraie vie, vous aurez parfois des de beaux appels d’offre ficelés qui tomberont sur votre bureau, une spécification de 40 pages et un engagement forfaitaire demandé. Et déjà, là, ça coince sur plusieurs points :

  • Tout chef de projets/ingé formé par le système cartésien français le sait, il faut commencer par écrire ce qu’on veut, c’est logique et on surnomme ça une spéc’ (le problème est sensiblement le même dès l’étape de l’expression de besoin). Le hic, c’est que la plupart du temps, c’est mal fait et pour plusieurs raisons / le document a été écrit à la va vite, est parfois trop détaillé sur certains points, pas assez sur d’autres et surtout, au lieu de se cantonner à une expression de besoin (c’est en dire,  » dans mon métier, j’ai besoin de pouvoir faire ceci afin de pouvoir faire/améliorer cela ») on se retrouve avec des descriptions de solutions (j’ai « besoin » d’un bouton de cette forme, cette couleur, qui fait ceci, j’ai besoin de telle métadonnée, j’ai besoin de convertir en PDF, etc.) inspirée de ce que chacun connaît ailleurs (autres applications, Internet, etc.).
  • Entre le temps d’écriture des spéc’s, celui de validation (qui est une blague, dans 80% des cas, le valideur ne passe pas la 5ème page du document), de l’AO, du démarrage projet, le besoin aura déjà changé.
  • Les sociétés demandent des engagements au forfait afin de maitriser leurs couts. Ca marche bien dans le bâtiment, où les matériaux et techniques sont rodées, souvent répliquées, etc. là où dans l’informatique, dans bien des cas, on fait du neuf. S’il s’agissait de refaire du déjà fait, on reprendrait exactement le code de la précédente solution, et le projet serait fini. Ca conduit à tous les défauts qu’on connaît à la méthode en cascade, les effets tunnels, la non réactivité au changement, les livraisons dans la douleur et au final les avenants au projet.

La liste des problèmes de ces démarches pourrait encore s’allonger, mais c’est suffisant déjà pour poser le décor.

Bref, si vous partez sur une situation comme celle-ci, prenez votre téléphone, demandez un rendez-vous, discutez de vive voix pour en revenir au besoin, commencez l’étude projet là où elle aurait dû commencer et … jetez la spéc’ à la poubelle.

Les ateliers

Pour en revenir au cas idéal, vous allez commencer par un ou plusieurs ateliers (le nombre et la taille varient suivant les premiers éléments à disposition). Durant ces ateliers, l’important est d’écouter, mais surtout de faire parler et de cadrer les échanges afin d’être efficace. La trame est assez simple.

Quel que soit le type de projet

Tout d’abord, qui est le sponsor?
pexels-photo-259234La question peut aussi se résumer à « Qui paye? ».
Commencez par comprendre qui est demandeur, qui fixera les priorités, qui aura le droit de vie et de mort sur le projet, qui devra remporter les lauriers quand le service sera ouvert aux utilisateurs et qui, s’il n’est pas assez impliqué dans le projet, pourra à la fin vous faire recommencer de zéro.

Ensuite, quels sont les objectifs du projets?
Des objectifs métiers biens construits donnent de beaux projets.
« Construire une application GED » n’est pas un bel objectif. C’est le signe que vous n’avez pas compris pourquoi vous êtes là.
« Accélérer le temps de traitement des demandes », « Construire un référentiel d’information afin de réduire les temps de recherche et éviter de manquer une information », « S’assurer de l’application des procédures afin de gagner en performance ou être auditable », « Mise en conformité GDPR », c’est déjà plus précis et plus mesurable. Donc n’hésitez pas à faire reformuler au sponsor les objectifs jusqu’à ce que vous ayez quelque chose de convenable. C’est important, on s’en resservira plus loin.

Quels seront les acteurs du projets?
Faite un tour de table. Y a-t-il des services non présents qu’il faudra embarquer dans le projet?
Profitez de la pause-café, cigarette ou afterwork pour comprendre les relations entre ces différents acteurs et s’il y a des frictions « politiques » entre eux.

Entrer dans le besoin, le cas des projets de gestion documentaire

A chacun sa manière d’amorcer la chose et de mener les discussions.
Quel est le métier des utilisateurs? ce qu’ils font? ce qui leur pose problème? les potentiels impacts sur le service client ou la production attendus? etc.
Essayez de garder la discussion à un niveau vraiment métier, ne parlez pas de SharePoint, ne parlez pas solution, nous sommes là pour étudier le besoin.

Le but sera double :

  • Pour vous , avoir une vue claire du périmètre afin d’étudier la faisabilité, commencer à concevoir la solution et donc faire une estimation de prix.
  • Forcer le client/métier à se poser les questions qui fâchent et se fâcher le plus tôt possible si cela doit être fait.

Au travers de la discussion , vous devez être en mesure de répondre aux différents points qui suivent :

Qui?
PeopleQui sont vos utilisateurs? Si on construit une application, c’est pour aider des personnes à faire leur travail, donc autant commencer par avoir une vision claire de qui ils sont. Quels sont les services et les équipes qui devront avoir accès à l’application? Pourquoi faire? Sont-ils sur poste fixe ou nomades (tablette/mobile)? Sont-ils habitués aux outils bureautiques et la navigation internet ou non (ca va grandement impacter l’ergonomie et la navigation de votre solution). Combien sont-ils? (ca peut impacter les cout de licences ou l’infrastructure à mettre en place).

Quels contenus?
ContentQuels sont les informations qui devront être partagées?
Quels sont les types de documents si vous êtes sur de la GED?
Sur du collab,  quelles informations « non documentaires » ont besoin de partager les équipes (ex : agendas, taches)?
Pour les intranets sociétés ou de services et les bases de connaissances, quels sont les rubriques qui devront être disponibles?
Énumérez les tous (bizarrement, les métiers n’ont jamais les idées claires la dessus, vous verrez, et justement, c’est un élément à travailler au plus tôt afin d’éviter les ajouts de dernière minute, prévoir un design graphique adéquate et dimensionner votre infrastructure).
Pour chaque rubrique, type de document, de quels volumes parle-t-on? Ceux qui connaissent SharePoint savent que la gestion des volumétries est un point clef pour éviter que le projet ne tourne au cauchemar. Si vous avez des volumes importants, il vous faudra faire une projection sur plusieurs années de l’augmentation des volumes d’items par liste, documents par bibliothèque, par collection et de gestion des quotas.

De cela découle aussi les axes de recherche des contenus (par client, par année, par projet, par thème, etc.). Je parle d' »axe » car c’est un terme neutre, savoir si on fera des dossiers, des colonnes de site ou des métadonnées gérées, c’est une fois tous les besoins collectés, avec une vision de l’architecture de l’information en tête qu’il est possible de voir ce qu’il est possible de proposer.

Y a-t-il aussi des informations supplémentaires sur ces contenus qui doivent servir à autre chose que leur recherche (pour du reporting par exemple)? Là encore, rentrez dans le détail. C’est typiquement ce qui manque dans la plupart des documents de spécification, qui oblige les demandeurs à se mettre d’accord entre eux et qui peut faire apparaître des divergences de vision rapidement. S’il y a des désaccords, au plus tôt ils apparaissent, plus ils sont faciles à traiter.

Pour chacune des données qui se présente comme une valeur à sélectionner pour l’utilisateur (genre liste déroulante), cette liste est-elle longue? Si oui, combien de lignes? Quelle évolution à prévoir sur ce nombre? Est-elle amenée à évoluer souvent?

Si vous êtes face à une liste longue, il est probable qu’on vous demande de connecter le futur outil à une autre application dans le système d’information afin d’automatiser sa mise à jour. Dans ce cas, quelles sont les sources de données? Sont-elles à jour?  Contiennent elles vraiment toutes les données attendues (par exemple une application contiendrait la liste des clients, mais pas celle des prospects, hors nous en aurions besoin pour notre projet). Dans les grandes organisation, quels que soient les outils en place (MDM, EDI, web services), c’est souvent une question épineuse. Si rien techniquement n’est en place ou s’il y a des incertitudes sur le sujet, dégagez ce point de votre périmètre en demandant un CSV à jour de ces données dans un dossier partagé à partir duquel vous ferez votre import. Au métier/client de trouver comment remplir ce fichier de manière automatisée. C’est le niveau zéro de la connexion applicative, mais c’est résiliant. Si l’idée d’aller directement lire ou écrire des données d’une application A vers une application B est une idée intuitive souvent avancée par les métiers, ça reste une hérésie pour tout architecte IT. Chaque application est responsable de ses données. Il faut donc prévoir des connecteurs et des formats pivots d’échange des données.

Quelle fonctionnalités?
ClickTapEn dehors des fonctionnalités de lecture/ajout/modification/suppression de données (CRUD) et de recherche, y a-t-il des fonctionnalités particulières attendues?
On retrouve souvent là-dedans les besoins d’envoi de notification sur certains événements, de génération de rapports, de génération de documents.

Y a-t’il des procédures/actions à automatiser
FlowAu-delà de ce que votre outil sait déjà faire en standard, y a-t-il des actions à automatiser? Y a-t-il des enchainements d’étapes (validation par N+1 puis N+2)? Y a-t-il besoin de garder la trace de ces actions pour des raisons de conformité réglementaire?
S’il y a des procédures (workflows), ces derniers sont-ils formalisés, documentés et validés par la direction? C’est encore un sujet de friction possible au niveau des métiers.
Dans le cas des projets intranet et collab, cette rubrique est souvent vide.

Le design graphique
GraphicalDesignÇa concerne surtout les portails intranets, mais aussi dans une moindre mesure les outils collaboratifs et les GED. Quelles sont les attentes en termes de graphisme?
Y a-t-il une charte graphique? Un logo? Y a-t-il des applications ou sites web dont ils souhaitent s’inspirer?
Vous noterez que je pose ce point à la fin. C’est par ce que tous les projets orientés contenus (ECM) que j’ai croisé qui ont commencé par celui-ci avant le reste ont systématiquement dérapé dans le budget, le planning et souvent connu plusieurs versions avant d’aboutir péniblement en production à l’heure où la V2 commençait à poindre.

Une fois passé tout ceci, vous devriez alors avoir une vision votre projet.
Ça peut tenir en quelques slides Powerpoint. Nous sommes devenus feignants, à l’ère du bullet-point, plus personne ne prend le temps de lire sérieusement les Word.

Reste un dernière question qu’il est, une fois tous ces éléments identifiés, celle des permissions.
PermissionsQui a le droit de faire quoi sur quel contenus suivant quelle étape?
Le métier ayant une tendance naturelle a complexifier les choses et à les voir telles qu’elles devraient être, plutôt que telles qu’elles se passent sur le terrain. Il vous faudra certainement challenger la demande exprimée initialement pour la rendre plus simple et éviter des problèmes de gestion des droits et de limites de performances SharePoint. Ça doit tenir sur un simple tableau Excel de quelques lignes et quelques colonnes si vous n’avez pas de workflow (et si vous avez des workflows, essayez de faire simple quand même et réduire à l’indispensable en distinguant la matrice de responsabilité (qui « devrait » faire quoi) de la matrice de permission (qui a concrètement le droit de faire quoi)).

Une fois tout ceci clarifié, sans avoir parlé technique, sans avoir parlé SharePoint (comprenez donc que cette phase convient à tout type de projet centré contenu, quelle que soit la technologie utilisée), vous pouvez alors passer à l’étape suivante que je vous raconterai dans un prochain article.

En attendant, si vous souhaitez plus d’explications sur certaines parties, n’hésitez pas à le dire dans les commentaires, je pourrais faire un article dédié.

Source image entête : https://www.pexels.com/photo/pile-of-covered-books-159751/

2 réponses à “Lean, low-code et agile sur projets SharePoint et O365 – le recueil de besoin

  1. Très bon article! J’aurais aimé y voir un peu plus de détails pratiques (à moins que tu ne l’aborde par la suite). Par exemple, comment sélectionnes-tu les personnes de l’atelier? As-tu un format spécifique pour la rédaction d’un besoin? Comment fais-tu le lien avec l »‘agilité »? etc. En tout cas, tu as bien raison, la prise de besoins est une étape centrale, malheureusement bien trop souvent négligée…

    J'aime

    • Merci Frank 🙂
      J’ai élagué pour essayer de me concentrer sur les points essentiels. Pour rentrer dans la pratique, il faudrait que je fasse des études de cas (un jour, peut être…)
      Pour les personnes en atelier, ça dépend de la taille des projets, du budgets de cette phase d’étude : plus tu mets du monde, plus ça génère d’échange, donc plus ça nécessite de temps; à contrario, pas assez c’est pas assez riche. L’important, c’est d’avoir un unique décisionnaire en face de soit. L’autre retour d’XP, c’est que les mêmes causes amènent les mêmes effets. J’ai eu plusieurs projets qui étaient des remplacements de projets existants (déjà digitalisés ou pas). Si on remplace, c’est que l’ancien n’allait pas (et s’il allait bien, comme on va changer de techno, il faut quand même changer sa manière de répondre aux besoins). L’erreur est de se dire: ceux qui connaissent le mieux le process, c’est ceux qui ont travaillé sur l’ancien projet. C’est vrai, mais ces acteurs là ont tellement travaillé sur l’ancien que leur manière de penser est figée dans le précédent mode de fonctionnement. Il y a toujours des exceptions, mais en règle générale, c’est très difficile de leur ouvrir l’esprit et oublier l’existant pour reposer le problème à plat.
      Pour le format de rédaction, j’écris le moins possible (« soyez faignants… »), ça doit tenir en quelques slides. Mais toute la subtilité vient dans la phase d’après et justement, c’est là qu’on va parler agilité. Ça sera dans le prochain article 😉

      J'aime

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.