Lancez votre projet


Vous imaginez un nouveau projet qui vous permettra de réorganiser votre travail, celui de vos collaborateurs et d’apporter un meilleur service à vos clients, vos adhérents, vos bénéficiaires ?

Lancez votre projet !

  • Épisode 1 : Cadrer son projet
  • Épisode 2 : Qu’est-ce qu’un projet ?
  • Épisode 3 : Préciser la demande
  • Épisode 4 : Écrire le cahier des charges
  • Épisode 5 : Organiser et suivre le projet

Deux précisions  avant de commencer :

  • Nous nous intéressons ici aux projets aboutissant à la création ou à l’évolution d’un outil -généralement informatique- et la transformation d’une façon de travailler.  C’est à dire aux projets informatique et organisation.
  • Nous nous placerons tout au long de cette série dans la position du client du projet (Client, métier, Business, maîtrise d’ouvrage…)

Et sans plus tarder…


1/ Cadrer son projet

Faire naître un projet

La plupart du temps, un projet va naître de la rencontre de deux intuitions :

1/ Nous avons un problème.
2/ Nous allons résoudre ce problème, et en profiter pour nous améliorer.

Explorons cette première intuition.

  1. Quel est le périmètre concerné par ce problème ?
  2. Quel indicateur ne répond pas aux attentes ?
  3. Quel objectif n’est pas atteint ?
  4. Quel problème cela pose-t-il ?
  5. Quelles sont les conséquences de ce problème ?
  6. Que se passera-t-il si nous ne faisons rien ?

Autrement dit

Dans le périmètre (1) l’indicateur (2) nous montre que l’objectif (3) n’est pas atteint. Cela pose le problème (4) qui a ou aura pour conséquences (5). Et si nous ne faisons rien (6).

Dans ce service, le faible taux de dossiers correctement remplis montre que les personnes ne sont pas accueillies comme il convient. Leurs besoins sont mal identifiés, nous ne pouvons donc pas y répondre. Si nous ne faisons rien, ces dysfonctionnements nous amenderons à remettre en cause l’existence de ce service.

Est-il alors bien utile le lancer un projet ? La réponse est Non, si…

  1. Le problème posé est simple. La réponse n’est pas un projet, mais une tâche. Réglons le problème et avançons.
  2. La solution au problème est connue. Visiblement, le promoteur du projet n’est pas au courant ou préfère l’ignorer.
  3. Le problème nécessite seulement un peu de travail que personne n’a envie de faire.
  4. Le problème vient d’en haut. Que les dirigeants le règlent entre eux si quelqu’un a le courage d’aller leur dire.
  5. Le périmètre est trop large. Trop d’objectifs, trop de processus concernés, de points à améliorés, de parties prenantes. Le projet doit être découpé.

Temporairement rassurés sur la pertinence et l’opportunité du projet, continuons notre progression.

Pouvons-nous, à partir du problème rencontré élaborer une intention claire et mobilisatrice d’amélioration ?

  1. Pourquoi lançons-nous ce projet maintenant ?
  2. Que voulons-nous obtenir à la fin de ce projet ?
  3. Que ferons-nous de ce que nous allons obtenir ?
  4. Qu’est-ce que ça changera pour notre entreprise, notre association… ?
  5. Quel décideur a un intérêt particulier à ce que le projet aboutisse ?

Il n’est pas toujours facile de répondre tout de suite avec justesse et sincérité à ces questions, mais en le faisant, nous posons une vision, nous cadrons le projet et nous donnons une impulsion.

Présenter son projet

Vous devez maintenant présenter le projet à un interlocuteur ? Vous voulez être bref mais ne rien oublier ? Utilisez le DPIF !

Ce mnémonique militaire permet de donner un ordre de mouvement :

  • Direction : Que cherchons-nous à faire, à obtenir, en lançant ce projet.
  • Point à atteindre : Objectifs en terme de livrables, d’effets, de bénéfices.
  • Itinéraire : Plan d’action, planning prévisionnel, principaux jalons.
  • Formation : Qui s’en occupe, qui participe, régulation du projet.

En voici une version de présentation de projet :

Nous souhaitons mieux suivre et mieux prévoir les adhésions et le paiement des cotisations. Pour cela, nous avons choisi de nous doter d’un logiciel.
Début septembre, nous disposerons d’un outil, destiné aux gestionnaires et aux adhérents, sur ordinateur et mobile.
Nous consultons trois prestataires qui présentent une première maquette dans deux semaines. Le prestataire que nous aurons retenu devra délivrer une version de test mi-juillet. Nous ferons un premier bilan de l’opération en janvier.
Catherine est responsable du projet. Elle est assisté par la comptable et la secrétaire qui traitent habituellement ce sujet. Elle rend compte au bureau de l’association.


2/ Qu’est-ce qu’un projet ?

Le lancement d’un projet est déterminant pour son succès.

Or, le client lancera généralement son projet bien avant de le confier à un intervenant habitué à mener des projets, ici un prestataire informatique. S’il n’en a pas l’habitude, le client va vite se sentir un peu seul.  Il se rassurera en appelant tout de suite le prestataire, ou en se projetant dans des problématiques informatiques.

En d’autres termes :

  • il ne va pas faire ce qui relève de sa responsabilité ;
  • va –mal– faire ce qui ne relève pas de ses compétences ;
  • et le moment venu disposera d’un outil purement technique pour résoudre des problèmes qui ne le sont pas.

Pour éviter ces problèmes, avant de poursuivre notre projet, tâchons de comprendre ce qu’est un projet SI à son démarrage.

Quelques définitions

Un projet SI est l’organisation temporaire d’une collaboration entre des personnes afin de créer, livrer et déployer un dispositif SI.

Une organisation est à la fois une répartition du travail entre plusieurs personnes, et des modalités de collaboration et de décision entre ces mêmes personnes.

Le dispositif SI est composé d’outils informatiques, de données, de processus et de règles métier, d’une organisation et de personnes exploitant l’ensemble. Le dispositif SI répondra à la vision et aux besoins de parties prenantes.

Les parties prenantes sont des personnes ou des groupes de personnes, des activités et des contextes de travail concernés par le projet. Ces parties prenantes sont identifiées et surtout caractérisées par des besoins spécifiques, des contraintes spécifiques, et des ressources –notamment des compétences– mobilisables sur le projet.

Le cadrage de projet permet de rassembler explicitement les acteurs sur un terrain de jeu commun. Les limites du terrain, l’organisation, les règles, les buts à atteindre…

Les résultats attendus : Le dispositif livré par le projet permettra de produire des effets opérationnels dont les parties prenantes retirent des bénéfices.

LEB

Le périmètre permet de préciser ce qui est dans, mais aussi hors du projet. Le périmètre peut évoluer au cours du projet. Ces changements de périmètre doivent être rares, nécessaires, explicitement approuvés. Ils engendrent des risques qui doivent être appréciés et suivis.

La vision, les enjeux, donnent une direction générale au projet qui doit être de répondre à la stratégie de l’organisation. Les enjeux donnent le sens du projet en précisant ce que l’organisation peut y gagner ou y perdre.

Les objectifs permettent d’organiser l’autonomie relative des acteurs, de passer à l’action et d’évaluer celle-ci. Ils peuvent être déclinés en plans d’action, en feuilles de route. Les objectifs sont atteignables à la fin du projet.

Les indicateurs choisis au début du projet permettent à chacun d’évaluer son action et sa progression.

PEOI

Plus le périmètre, les enjeux, les objectifs et les indicateurs sont clairs, partagés, et voulus ; plus le projet a de chances de réussir.

La difficulté de l’exercice tient aux intérêts plus ou moins explicites des parties prenantes. La plupart convergent, certains sont propres à telle ou telle partie prenante, d’autres divergent. L’ignorer ou le masquer peut conduire à l’enlisement ou à l’explosion du projet.

Définir des objectifs

Les objectifs SMART sont largement connus. Il existe plusieurs versions de l’acronyme en anglais,  et bien davantage de traductions, voici celle que nous utilisons et comment nous la comprenons.

  •  Spécifique  : Spécifique au projet, précis, détaillé.
  • Mesurable :  L’atteinte de l’objectif, comme la progression vers l’objectif sont mesurables.
  • Atteignable  : « Réduire le nombre d’incidents » n’est pas atteignable, nous pourrons toujours le réduire encore. « Réduire de 10% le nombre d’incidents » est atteignable.
  • Réaliste : …mais ambitieux. L’objectif est posé face à des contraintes et des ressources.
  • Temporel : Inscrit dans le temps : échéance, fréquence.

Maintenant, tachons de nous montrer plus malin que l’objectif !

Pourquoi nous atteignons nos objectifs :

  • Nos objectifs sont clairs, univoques, précis.
  • Nos objectifs sont écrits.
  • Nos objectifs donnent envie d’être atteints
  • Nos objectifs sont déclinés en plan d’action, en feuille de route.
  • Nous avons agis pour les atteindre..
  • Nous avons été persévérants.

…et pourquoi pas ?

  • Nous n’avons rien écrit.
  • Nous nous sommes dispersés sur un grand nombre d’objectifs.
  • Nous ne nous sommes pas concentrés sur ce qui est possible de faire maintenant.
  • Nous avons confondu activité et efficacité.
  • Nous ne savons pas vraiment à quoi va nous servir d’atteindre cet objectif.
  • Vous ne voulons pas vraiment atteindre cet objectif.
  • Nous n’avons même pas essayé.

L’équilibre du projet

Les enjeux, les objectifs et les indicateurs doivent systématiquement être associés sous peine d’être vides de sens, stériles ou de produire des effets pervers.

OVAR

Le projet tient en équilibre sur quatre pieds complémentaires : le périmètre, les coûts, les délais, et la qualité. (Par qualité nous entendons les produits attendus et leur conformité aux exigences exprimées.) Chaque fois que les instances de décision privilégieront une de ces composantes, il sera nécessaire d’assouplir les exigences sur les composantes complémentaires.

Créer une équipe projet

L’équipe projet est composée de personnes qui vont, à un titre ou à un autre, participer à la réalisation du dispositif. Chaque personne apporte ses compétences et peut intervenir à une ou plusieurs des étapes du projet. L’équipe projet est donc par définition pluridisciplinaire, transversale, et sa composition pourra varier au cours du projet.

La mission du chef de projet –quelque soit le titre qu’il porte ;-)– est de coordonner ces différents acteurs afin d’atteindre ensemble les objectifs fixés. Il s’assure que chacun dispose du même niveau d’information, liste les tâches à mener, informe sur le planning, rend-compte au porteur du projet, et mobilise l’équipe, notamment face aux difficultés.

Les rôles sont distribués pour chaque tâche à accomplir, à partir des compétences nécessaires et identifiées, des
disponibilités, et de la responsabilité des différents acteurs.

Posons quatre rôles principaux :

RACI1

Les activités retenues (tâches, livrables) et les rôles peuvent être formalisés dans un tableau daté, mis-à-jour régulièrement, communiqué à toutes les parties prenantes. Un acteur et un seul peut avoir un A sur un livrable. Il importe de limiter le nombre de R sur un livrable.

RACI2

Les différents acteurs désignés sur un livrable ou un ensemble de livrables, doivent –indépendamment de leur rôle– collaborer régulièrement et de préférence quotidiennement à la production de chacun des livrables.

Les acteurs doivent collaborer, et notamment partager les informations, le plus simplement et le plus directement possible. Ce qui n’exclut pas une formalisation a posteriori des informations et des décisions.


3/ Préciser la demande

Notre projet est cadré : Nous avons tracé le terrain de jeu de façon à pouvoir recueillir utilement les besoins. Un terrain assez ouvert pour ne pas frustrer les attentes, mais délimité de façon à pouvoir décider et agir.

Nous devons maintenant convertir une intention, d’une vision, d’un besoin en  une demande.

Notre objectif : à partir des besoins exprimés par les parties prenantes, préciser des résultats attendus, et les hiérarchiser. De façon à présenter une demande précise et un niveau d’exigence.

Nous allons, pour cela, emprunter à deux outils de façon très souple et très ouverte :

  1. L’analyse fonctionnelle
  2. Le modèle de Kano.

L’analyse fonctionnelle

L’analyse fonctionnelle est souvent une étape clé de formalisation des services attendus et du niveau d’exigence. Elle est le principal point de référence de toute évolution du périmètre, plus particulièrement lorsque les contraintes de budget ou de délais nous obligent à revoir le niveau de qualité attendu.

Certaines méthodologies de réalisation se passent de cette analyse. Mais ce qui va nous intéresser particulièrement ici, c’est d’exprimer une attente d’une façon claire et univoque.

Ces résultats attendus peuvent utilement être décrits sous forme de fonctions :

  • une fonction rend service à quelqu’un ;
  • une fonction agit sur quelque chose ;
  • une fonction aboutit à autre chose.

La tondeuse à gazon a une fonction « Couper l’herbe » qui me permet d’agir sur le gazon pour obtenir une pelouse tondue.

Nous avons tout intérêt à décrire une fonction avec rigueur afin d’éviter toute ambiguïté, tout malentendu.

Nous utiliserons pour cela un verbe à l’infinitif et des compléments en évitant absolument les conjonctions « et » et « ou ». Leur emploi impliquerait que la fonction peut être divisée en deux autres fonctions. Nous éviterons aussi d’énoncer des solutions techniques.

Chaque fonction doit ensuite être associée à des critères d’appréciation qui permettront d’en évaluer les effets.

Je serai satisfait de la fonction « Couper l’herbe » : si je peux tondre un hectare de pelouse, à cinq centimètres de hauteur, en une heure.

Nous pouvons à partir de cette expression modérer nos exigences (5 cm à 1 cm près) mais aussi valoriser les effets produits.

Cette fonction me fera gagner deux heures de travail hebdomadaire.
Je suis prêt à la payer deux kilos d’oeufs en chocolat.

Nous nous aidons souvent de cette grille pour formaliser des fonctions.

La tondeuse à gazon permet à l’utilisateur de couper l’herbe.
Si l’utilisateur lâche la poignée, la tondeuse doit s’arrêter immédiatement.
La tondeuse doit collecter l’herbe coupée.
Lorsque la tondeuse ne peux pas collecter l’herbe coupée, la tondeuse doit le signaler.

Notez qu’à aucun moment nous n’évoquons  la solution qui sera employée pour collecter l’herbe coupée.

Le modèle de Kano

Le modèle de Kano (développé par Noriaki Kano) permet de mesurer, d’anticiper, de représenter la satisfaction d’un client, d’un utilisateur, d’un usager. La méthode qui en découle se révèle souvent pertinente pour affiner ou arbitrer entre des demandes, des fonctions attendues.

Sans nous attarder sur le modèle lui-même (Internet regorge d’articles -souvent très bons- sur le sujet), examinons trois idées qui nous semblent importantes dans un projet.

1/ Le service rendu et le service perçu sont deux choses différentes.

Ça a l’air bon, mais je n’aime pas les assiettes carrées.
(Fig. 1)


2/ La satisfaction et l’insatisfaction ne sont pas symétriques.
Je peux être satisfait d’un service, et indifférent à son absence.

Oh la jolie fleur… mais s’il n’y en avait pas eu, je n’y aurais même pas pensé.
(Fig. 2)

Ou être mécontent de l’absence de service, et indifférent à l’avoir.

Je n’ai pas de couvert ; mais si j’en avais, je ne serais pas satisfait pour autant.
(Fig. 3)


3/ Les demandes incontournables, auxquelles il est indispensable de répondre, ont le plus de chances de rester implicites. (Les fameuses évidences qui n’en sont jamais que pour soi-même)

J’avais réservé une table, sans préciser que je voulais aussi une chaise.
(Fig. 4)


Quand nous démarrons un projet, nous avons donc tout intérêt :

  • à ne pas prendre trop de raccourcis ;
  • à évitez déductions faciles ;
  • et à creusez les évidences.

Utilisation

L’approche de Kano se prête particulièrement bien à l’analyse d’une demande exprimée sous forme de fonctions.

Nous pourrions nous contenter de classer les fonctions selon deux axes :

  • Facile/Difficile
  • Très demandé/Peu demandé.

Et cela suffit parfois.

L’analyse des fonctions selon le modèle de Kano suppose d’interroger les parties prenantes sur chaque fonction ou groupe de fonctions.

  • Seriez-vous satisfait ou insatisfait si cette fonction était présente dans le résultat.
  • Seriez-vous satisfait ou insatisfait si cette fonction était absente dans le résultat.

Et d’en déduire le niveau d’attente mais aussi la nature des attentes des parties prenantes.


4/ Écrire le cahier des charges

Disons-le tout de suite, un bon cahier des charges est d’abord un cahier des charges adapté à la situation et aux enjeux. Si deux pages suffisent à cadrer le sujet, poser le contexte, exprimer la demande, le cahier des charges fera deux pages.

Un client commande la réalisation d’une chose à un prestataire. Ce client va expliquer au prestataire ce qu’il veut, d’une façon ou d’une autre. Le plus souvent, il décrira la solution qu’il imagine, les besoins auxquels il veut répondre, les contraintes qu’il doit respecter, les résultats auxquels il veut aboutir, ou simplement un contexte. Parfois un peu de tout ça.

Ces éléments prennent place dans…

Un cahier des charges

Le terme de cahier des charges est d’usage ancien et son usage recouvre des réalités infiniment variables, plus ou moins figées. Notons, avant de poursuivre, que le cahier des charges sera la plupart du temps intégré au contrat qui relit le client au prestataire.

Le client formalise son besoin, le prestataire le réalise.

Nous écrivons un cahier des charges

  • pour que des prestataires nous proposent des solutions :
  • Pour donner envie aux meilleurs de nous répondre.
  • Pour leur permettre de répondre avec pertinence et justesse.
  • Pour gagner du temps dans la sélection et les discussions.

Nous écrivons souvent pour nous mettre d’accord en interne sur ce que nous voulons, ce que nous en attendons, ce que nous en espérons.

Enfin, ce cahier des charges nous servira de repère tout au long du projet.
Nous rencontrerons inévitablement des variations, des évolutions, des précisions à ce qui a été écrit dans le cahier des charges. Le cahier des charges doit l’encourager dès le départ, mais aussi permettre de le mesurer.

Comment aborder le cahier des charges ?

Le préalable minimum au cahier des charges est une demande cadrée. Ce qui signifie que nous avons identifié un demandeur, une demande, et un périmètre.

À partir de là, nous allons nous intéresser aux personnes et aux fonctions concernées par le sujet.

  • Niveau 1 : Les personnes qui utilisent le dispositif (organisation et outils) dans le but pour lequel il a été conçu.
  • Niveau 2 : Les personnes qui interagissent avec les membres de ce premier groupe, pour les soutenir ou les solliciter.
  • Niveau 3 : Les personnes qui n’utilisent pas le dispositif mais sont concernées par son utilisation.

Exemple : Dans un établissement médico-social, nous révisons la procédure d’accueil et les documents utilisés. Niveau 1 : les professionnels chargés de l’accueil. Niveau 2 : Les personnes accueillies. Niveau 3 : les cadres intermédiaires, les intervenants, la direction de l’établissement.

Il est souvent intéressant à ce stade de pousser l’exploration aux activités et aux contextes dans les quels ces personnes vont intervenir.

Ensuite, nous réfléchissons (oui, il faut en passer par là) :

  • À ce que nous voulons, et à ce que nous ne voulons pas.
  • Au résultats opérationnels et stratégiques que nous attendons de ce que nous voulons.
  • À ce que nous avons à y perdre et à y gagner.
  • Aux principales contraintes que nous donnons.

Exemple : Nous voulons que l’ensemble des collaborateurs ait accès à l’information interne de référence. Ce qui nous permettra d’harmoniser et d’améliorer l’accueil des usagers. Idéalement, nous souhaiterions que tous les professionnels aient accès en permanence à une information à jour. Jusqu’à présent nous diffusions cette information à travers les postes informatiques partagés et par affichage. Nous voulons maintenant passer par les terminaux mobiles des collaborateurs, en respectant les cadres réglementaires et légaux.

Pour définir les quatre faces du projet :

  • Périmètre
  • Coûts
  • Délais
  • Résultats

En bref…

Chaque projet est unique, chaque cahier des charges doit l’être.
Mais des méthodes, des techniques, peuvent et doivent être transposées d’un projet à l’autre.

Posons quelques principes.

  • Le cahier des charges doit clarifier la demande sans préjuger des réponses possibles.
  • Le cahier des charges doit être lisible et compréhensible par toutes les personnes concernées.
  • Le cahier des charges doit être sincère.
  • Le cahier des charges est à la fois un instrument de pouvoir et un instrument de collaboration. À nous de doser.

« Toutes les choses sont poison, et rien n’est sans poison ; seule la dose fait qu’une chose n’est pas un poison.» (Paracelse)

Un modèle de cahier des charges

porte

Le modèle de cahier des charges que nous vous proposons ici est un modèle générique.

Un bon cahier des charges fonctionnel (c’est à dire abordant un projet informatique ou organisationnel sous l’angle des besoins fonctionnels d’un métier) peut faire 10 à 150 pages, et la durée de la rédaction varier dans les mêmes proportion.

Le volume du document dépend des enjeux du projet,
– mais aussi de l’originalité du projet,
– de la maturité de la demande
– ou encore de la méthode retenue pour choisir un prestataire.

L’investissement sur le cahier des charges ne reflète pas la complexité ou la durée du futur projet dans sa globalité.

La rédaction du cahier des charges débute, ou est précédée, par un cadrage du projet qui permet poser le périmètre, les enjeux et les objectifs (résultats, effets opérationnels, et bénéfices attendus, risques et coûts acceptés)

Proposition de plan

Nous abordons ensuite la rédaction du cahier des charges à partir d’une trame, qui évolue assez peu.

Cette trame de cahier des charges comporte huit sections :


  • Introduction
  • Contexte du projet
  • Principaux concepts
  • Processus cibles
  • Besoin de sécurité
  • Analyse fonctionnelle
  • Environnement technique
  • Cahier de réponse

Dans le cahier des charges final, des sections auront disparu, d’autres fusionné. L’ordre pourra varier : Cette trame permet surtout de vérifier que nous n’oublions rien..

1. Introduction au cahier des charges

  1. Choix du prestataire
  2. Cadrage de la réponse

Quel est l’objet de ce cahier des charges ?
Qu’en attendons-nous ?
Comment y répondre ?
Comment évaluerons-nous les réponses ?
À quoi serons-nous particulièrement attentifs dans notre choix ?

L’introduction doit, de façon plus ou sophistiquée, répondre à ces questions. Et par là, faciliter aux prestataires la lecture du cahier de charges.

2. Contexte du projet

  1. L’entreprise ou l’association
  2. Présentation générale du projet
  3. Les enjeux et objectifs
  4. L’organisation du projet
  5. Le principe de solution

Les éléments de contexte servent à donner un maximum de clés de compréhension aux prestataires. Pas un maximum d’informations, mais un maximum d’informations utiles à la compréhension du projet.
Les principes de solutions doivent donner à voir la solutions dans la quelle nous nous projetons. Il ne doit pas s’agir d’une contrainte. Le prestataire peut s’en écarter.

3. Principaux concepts

  1. Vocabulaire
  2. Concept 1
  3. Concept 2
  4. Concept n

Cette section, bien souvent oubliée, nous semble importante. Nous devons poser et expliquer le vocabulaire qui est le nôtre. Rentrer dans le détail des concepts les plus importants. Partir à la chasse aux évidences.  Cette section permet d’éviter les malentendus, d’évaluer la capacité du prestataire à rentrer dans notre métier, et d’imposer un vocabulaire fonctionnel avant de se voir imposer un vocabulaire technique.

4. Processus cibles

  1. Processus 1
  2. Processus 2
  3. Processus n

Tous les sujets, tous les projets, toutes les organisation ne se prêtent pas à l’exercice de formalisation, ou d’amélioration des processus. Il nous parait cependant important de s’y essayer. Le résultat doit être être compris par plus grand nombre, sinon par tout le monde.
Si vous avez l’habitude d’utiliser des outils de formalisation, de modélisation, et que les parties prenantes y sont réfractaires, préférez des récits d’utilisation structurés.

Les processus doivent être compris et utilisables par toutes les parties prenantes.

5. Besoin de sécurité

  1. Contexte
  2. Évènements redoutés
  3. Mesures de sécurité

Le besoin de sécurité pourrait être rattaché à l’analyse fonctionnelle. Le sujet en lui-même, certains aspects méthodologiques, le peu d’appétence des parties prenantes pour ce sujet militent nous semble-t-il pour que la sécurité et la gestion des risque et menaces soient traitées dans une section autonome.

6. Analyse fonctionnelle

  1. Gérer les utilisateurs
  2. Administrer la solution
  3. Composante 1
  4. Composante 2
  5. Composante n

Cette section est le coeur du cahier des charges fonctionnel.
Dans un soucis de lisibilité, nous avons intérêt à regrouper les fonctions attendues.
Nous utilisons le terme de composantes pour désigner ces groupes de fonction, tout autre terme conviendra aussi bien. Nous pouvons regrouper les fonctions par thème, par processus, par activités…

Dans le cas de projets bien identifiés (ERP, CRM, SI RH, GED…), l’analyse fonctionnelle notamment pourra être abordée différemment.

Attention cependant. La tentation est alors grande de passer rapidement sur les phases de réflexions amonts au prétexte que les paramétrage métiers précis et souvent complexes, ainsi que les questions techniques, s’imposent d’eux même.
Combien de projets SI RH, ERP, BI dérapent -dans le meilleur des cas- faute de définitions clairs des enjeux, effets et bénéfices attendus ?
Combien d’orientations stratégiques ne sont pas ou ne peuvent pas être déclinées en actions, en choix opérationnels et techniques, en paramétrages ?

7. Environnement technique

  1. Cartographie des interfaces
  2. Reprise des données existantes
  3. Sauvegardes et restauration des données
  4. Utilisateurs
  5. Formats d’échanges
  6. Accessibilité
  7. Environnement et intégration

C’est la section dans laquelle nous sortons du domaine fonctionnelle. La section qui nécessite l’intervention d’informaticiens plus ou moins spécialisés selon la taille de notre structure. En s’absence d’informaticien, des fournisseurs doivent pouvoir répondre.

Cette section permet de communiquer au prestataires des éléments importants pour la conception, la réalisation, la mise en production du produit attendu. Elle permet aussi de mouiller les informaticiens maison et les amener à préparer tôt la bascule du projet.

8. Cahier de réponse

  1. Présentation de la société
  2. Présentation de la solution
  3. Charges et coûts

Si nous devons mettre en concurrence plusieurs prestataires et comparer leurs offres, nous devons obtenir des réponses… comparables.

Il nous semble alors judicieux d’exiger du prestataire qu’il renseigne un cahier de réponse. Cette exigence nous permettra de :

  • Vérifier précisément  le périmètre couvert par la réponse
  • Rendre les offres comparables en termes fonctionnels et financiers
  • Éliminer les prestataires qui ne s’y plient pas, ou avec une mauvaise volonté évidente.

Bien entendu, une fois le cahier de réponse renseigné,  le prestataire a toute latitude pour ajouté des documents, des présentations, dans les formats qu’il a l’habitude d’utiliser.


5/ Organiser et suivre le projet

Après avoir cadré le projet, préciser la demande, et écrit un cahier des charges, nous allons sortir de ce qu’il est convenu d’appeler la phase amont du projet pour nous intéresser à la phase de réalisation.

En tant que client, que demandeur, nous n’allons pas nécessairement avoir la charge d’organiser et suivre ce travail de réalisation.  Il sera néanmoins important de pouvoir comprendre les informations communiquées par le prestataire, et de pouvoir faire des arbitrages en cours de projet.

Nous allons pour cela découvrir trois activités dans le contexte d’un projet :

  1. Organiser le travail
  2. Animer une équipe
  3. Piloter le projet

Organiser le travail

Au cours de notre projet, nous voulons

  • Visualiser le travail à faire, en cours, fait ;
  • Limiter le travail à faire ;.
  • Prendre des décisions (priorités et gestion des ressources) ;
  • Améliorer en permanence la production.

Les tâches

Commençons par décomposer le projet en étapes. Chaque étape aboutit à un résultat opérationnel autonome : Préparer le dîner, mettre la table…

Chaque étape peut ensuite être découpée en tâches. À chaque tâche un livrable, c’est à dire un résultat concret et précis attendu : Poulet et pommes de terre au four, salade, serviettes (propres !)…

Nous allons donc :

  • Identifier les tâches nécessaires à la réalisation du projet, leur livrable, leur charge ou durée, leurs délais.
  • Identifier la dépendance des tâches (Je dois percer un trou avant de mettre une cheville avant de mettre une vis dans le mur)
  • Ordonner au mieux les tâches en fonction de leur dépendance, des ressources qu’elles mobilisent et des contraintes de délais.

Début et fin

Pour chaque tâche, il doit être possible d’indiquer au moins un début au plus tôt (DTO) et une fin au plus tard (FTA).

Par exemple, je ne rentre pas chez moi avant 19h00. Je dois cuire mon poulet une heure. Mes invités passent à table à 20h30 et commencent par le poulet : Tâche [Cuisson du poulet], durée : 1h, DTO : 19h00, FTA : 20h30. À 19h30, la tâche [Cuisson du poulet] devient une tâche critique. C’est à dire que tout retard sur cette tâche entraîne un retard général.

Il est possible d’affiner ces paramètres, mais cela s’avère généralement inutile sur des projets simples : [Cuisson du poulet], durée : 1h, Début au plus tôt (DTO) : 19h00, Début au plus tard (DTA) : 19h30, Fin au plus tôt (FTO) : 20h15 (je peux le maintenir au chaud un quart d’heure mais pas plus), Fin au plus tard (FTA) : 20h30.

L’effort, la charge et la durée

La tâche [Cuisson du poulet] est pilotée par la durée et mobilise une ressource matérielle : le four. La tâche [Découper les pommes de terre] est pilotée par l’effort et mobilise des moyens humains et matériels (couteaux et économes). Si nous nous mettons à trois à découper les patates, cela devrait prendre à peu près trois fois moins de temps.

La charge représente de temps de travail nécessaire, la durée l’intervalle entre le début et la fin de la tâche. L’effort est le rapport entre la durée et la charge.

Diviser la charge de la tâche par les ressources disponibles ne fonctionne pas toujours. Certaines tâches ne sont pas strictement pilotées par la durée ou l’effort. Toutes les ressources n’ont pas les mêmes capacités. Et la coordination des ressources représente une charge supplémentaire.

Si nous sommes trois à éplucher les pommes de terre, nous mettrons probablement trois fois moins de temps. Si nous nous y mettons à dix, nous y passerons deux fois pus de temps. Essayez 😉

Estimer la durée et le coût d’une tâche

La méthode la plus fiable n’est pas nécessairement la plus précise.

Estimons, seul ou à plusieurs, pour chaque tâche :

  • Une durée raisonnable (Dr)
  • Une durée optimiste (Do)
  • Une durée pessimiste (Dp)

Puis calculons une durée estimée (Do+4*Dr+Dp)/6

Préparation et improvisation

Mieux les tâches sont identifiées et planifiées, mieux nous pourrons faire face à l’imprévu, aux cas non conformes : Je viens de lâcher le cartons qui contenait les verres : quel est l’impact de cet incident sur le projet (quelle gravité et quelle urgence), dois-je résoudre ce problème et si oui comment, avec quelles ressources, dans quel délais, et quelles seront les conséquences sur le planning ?

Mais attention !

Plus nous détaillerons ces tâches, plus la gestion du projet sera longue et fastidieuse, et plus nos estimations s’avèreront fausses. Soyons clairs et précis quand c’est nécessaire. Restons flous quand ça ne l’est pas.

« On n’improvise bien que quand on a bien préparé. » répétons-nous souvent. « On s’habille pour la chute, pas pour la route » répondent les motards et « Proper Planning and Preparation Prevent a Piss Poor Performance » affirment les militaires britanniques.

La préparation est indispensable. Elle doit servir l’exécution et prévenir les risques. Mais ne doit ni empêcher, ni gêner l’action.

Marges de sécurité

La marge de sécurité –le pied de pilote– est indispensable pour mener le projet à bon port.

Elle engendre malheureusement quelques effets pervers qui réduisent souvent son utilité à néant.

Voici quelques petits trucs qui nous permettront de rester à la manœuvre :

  • Prévoyons les délais de corrections et de réajustement des livrables, tenons-les et faisons-les tenir.
  • Définissons une marge de sécurité globale pour le projet (empiriquement 5% du projet, 10% maximum)
  • Suivons la consommation de cette marge. Nous commencerons à corriger quand nous en aurons consommé la moitié. Nous considérerons que le projet est en crise si nous atteignons le dernier quart.
  • Nous serons enfin particulièrement attentifs à démarrer dans les temps les tâches critiques. C’est à dire les tâches les plus contraignantes pour le planning du projet.

Et finalement, qui fait quoi ?

TâcheDébutFinResponsableLivrableRisqueRésultat

Animer l’équipe

Les outils indispensables au démarrage d’un projet sont faciles à rassembler : des Post-It, des stylos, une corbeille à papier.

Il n’en faut pas nécessairement beaucoup plus pour organiser et suivre le travail d’une équipe qui travaille sur le même lieu. Alors en avant !

Dans un lieu accessible à tous, préparons le support : tableau blanc, vitre, papier kraft tendu sur une cloison ; puis organisons-le de la façon suivante.

Chacun peut noter une tâche sur un Post-It : un verbe + un complément. Éventuellement une échéance. Essayez de vous astreindre à n’utiliser qu’un verbe, qu’un complément. Si vous n’y arrivez pas, décomposez la tâche. Elle le mérite probablement.

Les trucs insuffisamment mûrs partent dans la case [Idées]. Les tâches récurrentes, qui doivent et réaffectées régulièrement vont… vous trouverez bien.

Les tâches exceptionnelles sont [À affecter].

La méthode d’affectation des tâches est ensuite assez ouverte. Le manager -présent lui-même dans le tableau- peut affecter les tâches. Les équipiers en prendre une lui-même. Les affectations peuvent encore être discutées en réunion. Les méthodes et toutes leurs variantes peuvent coexister.

Chaque équipier gère ensuite ses tâches en respectant deux contraintes :

  1. Personne ne peut avoir plus de trois tâches dans la colonne [En cours]. Les cas échéant, le surplus doit repartir dans la colonne précédente.
  2. Une tâche ne rentre dans la colonne [Terminé] qu’avec une date de fin.

Les tâches terminées sont périodiquement passées en revue, par le manager ou en équipe. Elles peuvent repartir dans le tableau ou en direction de la corbeille, ce qui procure toujours une grande satisfaction.

Piloter le projet

Le «pilotage d’un projet» consiste  pour beaucoup à élaborer des rapports, des tableaux de bords –plus ou moins sincères– afin de présenter l’avancement de quelque chose à un comité de pilotage. Creusons un peu.

Piloter un projet est une activité qui appartient… à un pilote. C’est à dire une personne (éventuellement un groupe de personnes) qui a une responsabilité, qui observe, qui agit et qui veut aller quelque part.

  • Le pilote est responsable du projet. Il peut prendre des décisions, et dispose de ressources.
  • Le pilote regarde son tableau de bord, mais aussi et surtout, agit sur les commandes.
  • Et enfin, le pilote sait où il est, où il va, par où il peut y aller.

En matière de projet, le «Où nous allons» peut prendre cinq formes :

  1. Pilotage par les coûts : Il s’agit d’un contexte de pilotage fréquent. Les aléas seront traités en réduisant les résultats attendus, ou en allongeant les délais : Le pilote vise le respect du budget.
  2. Pilotage par les délais : C’est la situation des projets débouchant sur un évènement. La tenue impérative des délais peut conduire à des dérapage de coûts, ou une baisse de la qualité : Le pilote vise des échéances.
  3. Pilotage par la qualité : Les résultats à obtenir, leur qualité, sont des impératifs. Nous sommes près à allonger les budgets et les délais pour nous y tenir : Le pilote vise la qualité des résultats.
  4. Pilotage à l’aveuglette : Certains projets très exploratoires ne permettent pas de poser tout de suite des critères de qualité, de coûts, de délais ou de périmètre. Ils appellent un pilotage prudent, fait de petits bonds avec des enjeux limités : Le pilote veille à ce que les enjeux restent limités.
  5. Pilotage tout puissant : Qualité élevée, budget et délais stricts, peu de risques, aucune situation non-conforme. Ces projets ne nécessitent aucun pilotage : Le pilote veille à ne pas être mêlé à ça de trop près.

Il est fondamental pour la réussite d’un projet que le pilote, ou le groupe qui pilote, se positionne rapidement sur les éléments d’arbitrage prioritaires : Coûts, Délais, Qualité, Périmètre. Et qu’ensuite ce même pilote accepte de piloter.