Comprendre les projets informatiques
et le digital interne d'Entreprise
La gestion de projet, c'est avant tout une culture à acquérir...
Pour que tous les acteurs s'entendent et se comprennent, ils doivent tous avoir un minimum de culture projet, au risque de profondes mésententes qui auront des répercutions sur la vie du projet, et sur les relations entre les acteurs.
Ce chapitre se propose de revenir sur les fondamentaux de la gestion de projet.
Les projets informatiques
Les fondamentaux
Projet, verus "tâches récurrentes"
Un projet, par opposition à des tâches récurrentes, est une opération ponctuelle ayant un début et une fin, et nécessitant la mise en oeuvre de ressources humaines et matérielles pour sa réalisation.
La gestion de projets concerne donc toutes les tâches nécessaires pour gérer le projet et le mener à terme: c'est ce qu'on appelle le pilotage.
Les acteurs
Le projet met en oeuvre différents acteurs : maîtrise d'ouvrage, maîtrise d'oeuvre , éventuellement maîtrise d'ouvrage déléguée, et tous les autres acteurs impactés par la réalisation du projet (développeurs, utilisateurs, ...).
Des responsables sont chargés du pilotage pour chaque périmètre du projet (maîtrise d'ouvrage ou maîtrise d'oeuvre) : ce sont les chefs de projets . En véritables chefs d'orchestre, ils doivent battre la mesure pour tous. Nous y reviendrons en détail dans la partie "Acteurs" de ce site (cliquez ici).
Avant d'entrer dans le vif du sujet, une petite définition de ce qu'est un projet s'impose. Pour cela, je saisis mon vieux "Dictionnaire de management de projet" de l'Afnor (que j'avais en 1995 quand j'étais en DESS gestion de projet) pour en tirer une synthèse de leur définition :
Cette définition est évidemment claire et brillante. Néanmoins, j'y apporterais bien quelques compléments
Définition
Le besoin
Dans la définition ci-dessus du mot "projet", vous y verrez en bonne place le mode "besoin" (formulé par la maîtrise d'ouvrage).
Le "besoin" est l'essence même du projet : c'est sa raison d'être. Sa bonne description est donc un point essentiel du projet.
La finalité
La finalité d’un projet informatique n’est pas la technologie : la finalité est humaine.
Quelque soit le projet, technique ou industriel, en bout de chaîne, il y a l’homme. Ce sont vos clients, ou ce sont vos collaborateurs. Dans tous les cas, le projet que vous mettez en place a une finalité et contribue à aider vos clients ou vos collaborateurs.
Cette finalité, cette aide que le projet est censé apporter aux hommes ou à l’organisation que les sert, c’est bien ce qu’on appelle le besoin.
La priorité du projet, ce n’est donc pas de commencer à taper des lignes de code et à aligner les technologies les plus modernes. La priorité, c’est de savoir très exactement ce à quoi le projet va servir, à qui il est destiné, et quel est le service qu’on attend de lui.
L'enjeu
Le risque dans un projet informatique, c’est de ne pas suffisamment prendre de temps à la définition du besoin, et de penser que la réussite du projet repose uniquement sur la technologie, et donc sur les informaticiens. Pire, c'est d'imaginer que la technologie pourra palier l'absence de réflexion sur le besoin, par des technologies ou des modifications du code.
Le risque, c’est aussi de penser que le projet terminera d’autant plus tôt que les informaticiens ont déjà commencé à programmer, avant même que le périmètre du besoin fondamental soit clairement posé.
La réussite du projet, pourtant, c’est bien de couvrir le bon besoin, et de fournir ce service aux bonnes personnes, et surtout au bon moment. Ca a l’air évident, mais dans les faits, ça ne l’est pas toujours.
Qui, quoi, quand
On pourrait résumer la définition du besoin avec ces trois mots. Et derrière chaque réponse, il y a des choix technologies ou fonctionnels différents qui vont impacter le projet :
- QUI : à qui est destiné le produit ? Selon s’il s’agit de collaborateurs internes ou de clients externes (internautes), les questions sécuritaires seront différentes. Si le produit est destiné à des professionnels ou à des novices, l’ergonomie sera différente. Si le produit doit être interconnecté avec le SI métier, les technologies seront différentes ;
- QUOI : quel est le service que doit rendre le projet. Quelles sont les attentes, le positionnement au sein du SI, etc… De cette réponse va dépendre les fonctionnalités, et éventuellement, les technologies à mettre en œuvre ;
- QUAND : à quelle date le projet doit-il être terminé ? Cette question toute simple va avoir un impact éventuellement sur le périmètre fonctionnel. Si le temps manque et qu’il n’est humainement pas possible de tout intégrer, des priorisations seront nécessaires, et une livraison par versions sera probablement proposée ;
En résumé, réussir le projet, c’est d’atteindre la cible que la maîtrise d’ouvrage aura défini. Mais pour atteindre la cible, encore faut-il être sûr de savoir à quoi elle ressemble et dans quelle direction elle se trouve. Dans ce sens, la définition du besoin est donc bien l’une des phases essentielles du projet.
Importance du détail
Un projet informatique ressemble à de la musique classique. C’est l’art d’écrire des partitions qui seront exécutées par des musiciens jouant chacun d’un instrument différent, mais en pleine harmonie. Et comme dans un morceau de musique classique, il suffit qu’un seul instrumentaliste fasse un couac pour ruiner la réussite du concert.
La situation est relativement similaire pour les projets informatiques, comme pour tout autre projet de façon générale. Il n’est pas rare par exemple que des moyens pharamineux soient positionnés sur les fonctionnalités majeures d’un projet, en délaissant des fonctionnalités moins nobles, ou jugées moins essentielles.
L’exemple flagrant, ce sont les états (impressions papier). Lorsqu’un projet comporte comme fonctionnalités des sorties d’état papier, cette fonctionnalité est souvent reléguée au dernier stagiaire arrivé : un bon sujet simple pour démarrer ! Seulement voilà, lorsque l’outil est en production et que les états ne sont pas carrés, l’ensemble du système peut bien tourner comme une horloge, c’est un échec si les utilisateurs ne peuvent pas exploiter les états, base de leur travail.
Un exemple dramatique
L’exemple industriel le plus représentatif, c’est la malheureuse histoire du Queen Mary II (cliquer ici).
Ce projet gigantesque, dantesque a été réalisé dans les règles de l’art. Le navire, majestueux, a été livré dans les délais. Ce fut un magnifique projet technologique et naval.
Seulement, on avait oublié une petite chose : cette petite passerelle qui devait permettre au public de venir découvrir le bateau. Elle fut donc construite en toute hâte, sans une définition bien précise des caractéristiques que l’on attendait d’elle (la définition du besoin).
On connaît la suite : l’effondrement de la passerelle et 15 morts. Le projet aura été une grande réussite technologique, mais un détail en a ruiné l’image.
La finition de votre application
Bien moins grave, on peut aussi penser au soin apportée à la finition d’une application informatique.
Imaginez que votre équipe ait développé une application particulièrement ardue technologiquement, avec des traitements sophistiqués. Imaginez maintenant que l’équipe a monopolisé toute son énergie sur le fond (la mécanique) mais que pour ce résultat, elle a choisi de sacrifier la forme (le look, l’orthographe des libellés et des messages affichés à l’écran).
Du point de vue utilisateur, l’image qu’il aura de votre produit sera l’image d’une application d’amateur. La confiance qu’il lui accordera sera réduite, car l’utilisateur se dira que si vous avez pu laisser passer de telles choses, vous n’avez pas du mettre beaucoup d’énergie à vérifier le bon fonctionnement global.
Coût, délai, qualité
Voici ce qu'on appelle le triptyque de la gestion de projet. Ce sont les trois éléments qui sont sous surveillance pour n'importe quel projet, qu'il s'agisse d'un projet informatique, ou tout autre projet.
Un projet réussi c'est un projet dont on respecte les coûts définis avant son lancement lors du chiffrage initial. C'est également un projet qui est livré dans les temps, selon un planning défini à l'avance. C'est aussi un projet qui respecte la qualité promise.
Coût
Le cout d'un projet doit être estimé avant son lancement, pour plusieurs raisons. La première, la plus évidente, c'est pour que la maîtrise d'ouvrage qui gère son enveloppe budgétaire, puisse évaluer s'il a les moyens de le payer.
La seconde, tout aussi importante, c'est de pouvoir, avant le lancement du projet, estimer si le retour sur investissement (le fameux ROI) est positif, c'est à dire si les coûts de mise en réalisation, mise en œuvre et maintenance sont inférieurs aux gains financiers apportés par le projet. Selon le résultat, le GO de réalisation sera donné, ou pas. Mieux vaut donc respecter l'enveloppe initial du projet.
Le troisième point, c'est de maîtriser les dépenses. Chiffrer le projet avant son lancement permet de se fixer une ligne directrice en dépenses de moyens. Respecter cette ligne tracée au démarrage du projet permet d'éviter les sorties de route, et permet de cadrer également le périmètre fonctionnel du projet qui pourrait avoir tendance à enfler au fil du temps.
Délais
Chiffrage et planning veut de paire. On ne peut réaliser un planning réaliste si on ne connaît pas par avance la charge, c'est à dire le nombre de jours nécessaires pour faire toutes les actions pour mener le projet à bien.
Avant le lancement de la réalisation, un planning précis sera donc élaboré. Et tout au long du projet, un contrôle minutieux du respect de ce planning sera réalisé par le chef de projet. La réussite du projet en dépend : un projet livré en retard peut être une catastrophe dans certains cas et ruiner tous les efforts dépenses pour sa réalisation.
Qualité
Imaginer un projet informatique réalisé dans les temps, et dans le budget alloué initialement, mais qui serait bourré de bugs, quasi inutilisable. Ce serait assurément un échec cuisant. Il y a eu par le passé des exemples qui ont fait la une des journaux. Le dernier en date : la refonte du logiciel de paie des armées, dont les dysfonctionnements ont mobilisé des centaines d'épouses de militaires.
La maîtrise de la qualité consiste donc à s'assurer que le produit livré est fait dans les règles de l'art et qu'il sera facilement maintenable. C'est aussi et surtout contrôler qu'il ne présente pas de dysfonctionnement technique connu.
Mais la qualité, on l'oublie aussi, c'est aussi garantir la conformité du produit livré avec les spécifications initiales. On peut en effet avoir un outil technologique et brillant, beau, sans problème technique, mais qui ne fait pas du tout ce qu'on attendait de lui.
... sans oublier l'adéquation
Je me suis toujours demandé pourquoi les critères qui font la réussite d'un projet n'étaient qu'au nombre de trois. Je pense que c'était pour faire un bon triangle, sinon, pourquoi manque-t-il toujours ce quatrième critère auquel je tiens beaucoup : l'adéquation.
J'entends par "adéquation", l'adéquation du besoin exprimé au besoin réel sur le terrain. Car un projet peut être une réussite sur l'angle du fameux tryptique, mais être un retentissant échec sur le plan métier. Un projet peut être mené avec une maîtrise parfaite du coût, du délai de réalisation, et de la qualité : il peut être 100% conforme aux spécifications formulées par la maîtrise d'ouvrage, mais que se passe-t-il si les besoins de la maîtrise d'ouvrage sont erronés ?
Or un projet informatique répond avant tout à un besoin métier précis. Si ce besoin métier est mal exprimé, mal compris par la maîtrise d'ouvrage, l'application, tout en étant une réussite complète en termes technologiques, peut s'avérer être un échec complet s'il ne répond absolument pas aux vrais besoins du terrain.
Le pilotage
Maîtriser le délais
Pour commencer, un postulat de base : tout projet, quel qu'il soit, doit avoir un planning visible au démarrage du projet. Ce planning doit afficher clairement les dates des principaux jalons. Le planning est au chef de projet ce que la cible est au tireur à l'arc. L'avancement du planning est donc un critère essentiel à surveiller.
Faire ce suivi n'a rien de bien sorcier. Il faut pour cela faire des points réguliers avec les différents acteurs pour vérifier que le
projet passe bien "les portes" prévues, au moment prévu. D'ou l'importance de jalonner le planning de jalons représentatifs
facilement contrôlables.
Le respect du planning est également important pour garantir que les rendez vous entre les équipes seront respectés. Exemple : votre équipe de développement aura peut être parfaitement tenu ses délais mais si l'équipe en charge de l'infrastructure ne respecte pas le planning l'application sera quand même livrée en retard. La responsabilité pourra être imputée à l'équipe en retard mais également au chef de projet qui ne se sera peut être pas assez inquiété de leur avancement.
La détection précoce des retards permet de lever les alertes. Il est alors possible d'identifier la cause du retard, son impact réel et le cas échéant de mobiliser des ressources supplémentaires pour rattraper le retard si c'est possible.
Maîtriser la qualité
C'est le point le plus complexe. Le mot qualité couvre un large domaine : c'est à la fois le respect par les développeurs des règles de l'art, des règles internes de développement. C'est également la qualité globale de fonctionnement avec le moins de bugs possibles.
C'est aussi la conformité de l'application avec ce qui a été spécifié. Si tant est que les spécifications soient lisibles. On réalisera ces contrôles par des audits de code et par de la recette par les deux maîtrises : la maîtrise d'oeuvre en premier, suivie par celle de la maîtrise d'ouvrage.
Un projet c'est comme une voiture : lorsqu'elle roule, mieux vaut garder les mains sur le volant et les yeux sur la route sinon c'est le mur ! Et plus vous lâcherez votre attention, plus le choc sera violent.
Les cadrans
On a abordé dans cette rubrique le célèbre tryptique "coût délai qualité". Ce sont en synthèse les trois cadrans principaux que le chef de projet ne doit jamais quitter des yeux. Le pilotage, ce sont ces petites actions de tous les jours qui vous permettront de conserver votre projet sur les rails.
Maîtriser les coûts
Tout au long du projet le chef de projet doit avoir une vue exacte et précise des "consommations" c'est à dire du temps consacré par chacun sur le projet.
L'idéal est d'avoir une vue planifiée à l'avance de la consommation prévisionnelle de vos ressources. Si on le dit de façon plus simple : l'idéal sera de prévoir avant le démarrage du projet, en fonction de votre planning, combien de jours de travail devraient être consacrés à la fin de telle ou telle étape, de façon à vérifier que vous êtes dans les clous ou pas.
Si la consommation réelle ne correspond pas à ce que vous avez planifié, deux solutions : votre estimation initiale était erronée ou vous avez un problème dans le déroulement de votre projet.
Si vous surconsommez des jours de travail, c'est que le périmètre s'est enrichi par rapport aux spécifications initiales, ou que l'equipe rencontre des problèmes techniques imprévus, ou qu'un des équipiers à des difficultés dans son travail (débutant, ...) ou tout simplement, ... que votre équipe profite de la vie et n'a pas (assez) de pression sur le sujet (;->).
Si vous avez consommé à un jour J moins de jours que prévu initialement plusieurs explications possibles : la réalisation est en retard (l'équipe a peut être travaillé sur un autre sujet entre temps) ou une ressource était absente et non remplacée (maladie) ou vous avez peut être oublié de prendre en compte les vacances dans votre calcul prévisionnel d'avancement.
Animation
Ça consiste également à faire tout ce qui est nécessaire pour garantir les bonnes interactions entre les acteurs en s'assurant que tout le monde est en phase sur son domaine de responsabilité.
L'animation c'est aussi de créer l'ambiance et de faire en sorte que tout le monde s'entende au mieux, se comprenne et s'estime. Ça, c'est plus compliqué voir parfois impossible. Mais personnellement je n'ai jamais vu un projet être une grande réussite quand les acteurs s'étripent entre eux pendant la réalisation.
Ma théorie, c'est qu'un projet bien animé a toutes les chances de réussir parce que ces efforts améliorent la mobilisation et la motivation, les interactions, la solidarité, le partage et évite les malentendus fonctionnels et humains.
Comment on anime?
La manière d'animer un projet dépend beaucoup des outils que vous utilisez et de votre style personnel d'animation qui correspond à votre caractère. Prochainement, un dossier complet sera mis en ligne sur ce vaste sujet.
Pour ma part, la mise en place au sein de l' entreprise pour laquelle je travaille d'un réseau social d'entreprise dès 2010 a révolutionné ma façon d'animer les projets ; je vous en dirai plus dans le dossier spécial consacré à ce thème.
Les clés de réussite
Je n'aurai pas la prétention de donner ici les conseils universels garantissant à tout projet informatique une réussite assurée.
Ce serait d'autant prétention que certains des projets dont j'ai eu la responsabilité n'ont pas été non plus tous des succès planétaires. Mais je peux quand même vous donner quelques pistes.
Que faut-il faire pour réussir un projet informatique ? Ce n'est pas une action en particulier, mais bien une conjonction de plusieurs choses qui, conjuguées ensemble, donnent plus de chances à la réussite de votre projet.
Respecter les rôles MOA / MOE
La première chose que des auditeurs font lorsqu'ils auditent un projet informatique, c'est de bien cerner la distinction qui est faite au sein de la société auditée entre maîtrise d'ouvrage et maîtrise d'oeuvre car bien souvent, la première cause d'échec est un périmètre flou des responsabilités.
Un projet peut échouer si la maîtrise d'ouvrage est "faible", c'est à dire elle ne remplit pas complètement le rôle qui est le sien, ou elle oblige la maîtrise d'oeuvre à assumer ce rôle à sa place. Ca peut être l'inverse également, avec une maîtrise d'oeuvre qui en fait trop, et qui prend la main fonctionnelle sur un projet informatique sous prétexte qu'ils sont, justement, informaticiens (mais ils ne connaissent pas forcément le vrai besoin).
Le respect des rôles maîtrise d'ouvrage / maîtrise d'oeuvre est essentielle, et une bonne relation de partenariat entre les deux maîtrises l'est encore plus. Maîtrise d'ouvrage et maîtrise d'oeuvre sont sur le même bateau. Si l'une est en difficulté, l'autre le sera aussi puisqu'ils travaillent sur un projet commun.
Rester réaliste et pragmatique
L'application informatique qui va être réalisée dans le cadre du projet informatique doit répondre à un véritable besoin utilisateur. Il est fait pour les utilisateurs, et doit être adapté à leur utilisation. Il n'est pas fait pour faire plaisir à un manager, ni pour être à la mode.
Le projet doit rester réaliste, dans ses fonctionnalités, dans son périmètre, dans son budget et dans son planning. Un projet lancé en retard par la maîtrise d'ouvrage risque évidemment d'être ivré en retard par la maîtrise d'oeuvre si la date de fin prévisionnelle n'a pas été révisée. Pire, pour respecter un délai plus court que prévu, des impasses techniques seront faites, et la qualité en patira.
Un projet trop ambitieux ne disposant pas d'un budget à la hauteur de ses ambitions ne doit pas être réalisé aux forceps, en forçant la maîtrise d'oeuvre à accepter le challenge, sachant dès le départ que le budget est insuffisant pour absorber la charge nécessaire.
Le projet doit rester pragmatique. On préviligiera un découpage par "lots fonctionnels" réalistes, pour aborder la nouvelle application informatique par petits bouts, et non dans son grand ensemble.
Clarifier les responsabilités
Certains projets n'avancent pas, tout simplement parce que personne ne sait ce qu'il doit faire. Les problèmes de communication au sein des projets ne sont pas des légendes, c'est une réalité. Un projet reste avant tout une aventure humaine : ce sont des hommes et des femmes qui conçoivent, réalisent, testent , mettent en oeuvre et utilisent les applications informatiques.
Il n'est donc pas inutile de repréciser les responsabilités de chacun au sein du projet, et éventuellement les tâches qui se rattachent à ces responsabilités. Il n'est pas inutile non plus de se pencher sur les techniques de communication pour prendre conscience des risques et des techniques utiles pour les réduire.
Enfin, il ne faut pas éviter à s'appuyer sur des outils pour partager l'information du projet, et dans ces informations, intégrer les rôles de chacun, et les tâches en cours.
S'impliquer dans le projet
S'impliquer dans le projet est essentiel pour sa réussite. S'impliquer, c'est mettre en oeuvre tous les moyens pour réussir le projet. Concrêtement, cela se traduit par la mobilisation des ressources humaines sur les tâches de validation des besoins de leur description, des tests (recette), ...
Pour une maîtrise d'ouvrage, c'est consacrer du temps à la définition du besoin, aux questions de la maîtrise d'oeuvre, à la relecture des documents et à leur validation. Pour les maîtrises d'oeuvre, c'est de traiter le projet à part entière, et non entre deux autres projets.
C'est donc au final faire le maximum pour que atteindre les objectifs qui ont été assignés à chacun, dans le périmètre des responsabilités. C'est aussi tout simplement respecter les plannings des tâches que l'on doit réaliser.
Réfléchir aux fonctionnnalités et savoir les expliquer
Quelque soit la technologie la plus moderne pour réaliser le projet informatique, le résultat final ne pourra être que ce qui a été décrit par la maîtrise d'ouvrage, puis compris par la maîtrise d'oeuvre.
La maîtrise d'ouvrage doit s'impliquer dans la réflexion sur l'outil. Il doit s'impliquer pour étudier tous les aspects fonctionnels avec les utilisateurs. Il doit recueillir leurs besoins, les analyser, et les expliquer. La maîtrise d'ouvrage doit ensuite s'associer à la maîtrise d'oeuvre pour détailler ces besoins pour en faire un outil informatique utilisable.
Le développeur se trouve en bout de chaîne. Entre lui et le responsable de la maîtrise d'ouvrage se trouvent un nombre important d'interlocuteurs, qui se seront plus ou moins bien transmis la connaissance du projet. La documentation du projet, et la qualité de la rédaction (explications sans ambiguïté, document illustré d'exemple, ...) est la seule garantie pour permettre une bonne restitution des explications à tous les niveaux du projet, depuis la maîtrise d'ouvrage jusqu'au développeur.
Disposer d'une maîtrise d'oeuvre compétente
Le développement de l'application informatique est une étape délicate. Les risques de dérapage sur cette phase sont nombreux, et réels. La maîtrise d'oeuvre doit être compétente, et maîtriser toutes les phases du projet, depuis la création de la base de données jusqu'à l'écriture de la dernière ligne de code.
La maîtrise d'oeuvre doit être capable de faire les bons choix technologiques pour la mise en place du projet. Si les compétences internes manquent, elle fera appel à de la prestation extérieure. La maîtrise d'oeuvre s'impliquera dans la réalisation du projet, en effectuant un contrôle continue du travail des développeurs. Elle veillera à ne pas laisser un débutant seul sur un projet, sans être supervisé par un développeur plus expérimenté. Déléguer, ce n'est pas abandonner.
Le développement doit se faire dans les règles de l'art, notamment pour des questions de capacité en charge, et des problèmes de sécurité informatique.
Faire les bons choix technologiques
Le choix de la technologie à mettre en oeuvre est aussi impactant pour l'avenir de l'application informatique que ne l'est le choix de l'écartement des rails, dans le domaine du chemin de fer. La responsabilité de la maîtrise d'oeuvre est ici directement engagée dans sa responsabilité de conseil.
Lorsque l'heure du choix sonne entre plusieurs technologies, entre plusieurs éditeurs de solutions informatiques, l'instant est cruciale, car l'outil reposera pendant toute la durée de sa vie sur cette technologie. Solutions "open source" ou solutions propriétaires, une fois le choix fait, il faudra s'y tenir. Gare aux éditeurs défaillants, ou aux solutions non maintenables.
Faire de vrais tests
Maîtrise d'oeuvre et maîtrise d'ouvrage sont tenus de réaliser des tests (recette) de l'outil informatique qui a été développé. Cette phrase, souvent jugée ingrate, doit être réalisée de manière rigoureuse. Elle ne saurait être confiée à un stagiaire sans expérience et sans méthode.
La recette permet de valider l'outil avant qu'il ne soit accessible par les utilisateurs finaux. De la première appréciation de ces utilisateurs dépendra l'appropriation ou le rejet systématique de l'outil. Il n'y a qu'une seule chance de faire bonne appréciation du premier coup, et la recette garantit cette chance.
Intégrer les questions de sécurité
Les questions de sécurité sont essentielles dans les systèmes informatiques, et plus particulièrement dans ceux accessibles depuis le monde extérieur (internet, ...). Un manquement à la sécurité, une intrusion dans le système peut avoir de sérieuses conséquences : pénales, financières, et surtout des impacts en image de marque auprès des clients, surtout s'ils vous ont confié leur numéro de carte bancaire !
Les questions de sécurité doivent donc être intégrées le plus en amont possible du projet, car le respect de la sécurité peut avoir un impact sur la conception de l'application, et sur son développement. Faute de quoi, la prise en compte après le développement risque de coûter beaucoup plus cher, ou d'être impossible.
Accompagner les utilisateurs
Un projet informatique, c'est avant tout un projet humain. La nouvelle application sera proposée à des utilisateurs qui verront leur mode de travail modifié par ce nouvel outil. Ces utilisateurs développeront un certain frein au changement qui sera d'autant plus fort que l'accompagnement au changement aura été plus ou moins bien fait.
Le projet informatique, même s'il est une réussite technologique indéniable, peut être un véritable échec si l'accompagnement au changement est mal géré.
La maîtrise d'ouvrage doit s'impliquer dans cette étape importante. Cela passe par une information sur l'outil, sur ses enjeux, sur les avantages que les utilisateurs vont en tirer. Cela passe aussi par des formations à l'usage de l'outil, au risque de les bloquer dans leur travail.
Penser au futur
Le projet a une date de début ; il a aussi une date de fin. Une fois terminé, le projet n'est plus projet ; il devient alors un outil en production, que des équipes d'infogérance doivent contrôler et surveiller. Mais sa vie n'est pas finie. Penser le plus tôt possible aux futures évolutions de l'outil est un gage de réussite sur l'avenir.
Je ne parle d'animation projet que depuis fin 2010. Je n'en parle que depuis que j'utilise un réseau social d'entreprise pour tous mes projets, petits ou grands.
Pilotage et animation
Pilotage et animation de projet sont deux choses complémentaires mais bien différentes. Pour reprendre l'analogie avec la voiture, le pilotage c'est le fait de regarder les cadrans du tableau de bord, d'appuyer sur l'accélérateur ou le frein, de donner des coups de klaxon ou de changer de vitesse.
L'animation c'est l'ambiance que je mets dans la voiture dans laquelle se trouve les autres acteurs du projet. L'animation c'est les infos que je leur communique, ce sont les questions que je leur pose sur la route à suivre. Ce sont aussi les bons moments de détente qui créent du lien social, de la solidarité, l'esprit d'équipe.
C'est quoi, animer un projet ?
Pour vous expliquer, je me contente de vous donner un extrait de la définition du verbe "animer" avec tous les sens possibles :
animer, verbe transitif - Donner du mouvement, de la vie. Pousser à agir. Rendre plus vif, impulser. Présenter un débat, une émission, les diriger.
Vous l'aurez compris, l'animation ce sont toutes les actions que le chef de projet va réaliser pour que tous les acteurs se mettent en mouvement dans la même direction, dans un même but et en ayant le même niveau d'information. L'animation consiste donc à partager la connaissance sur le projet : objectifs, enjeux, documents, actualités, ....