//
you're reading...
Analyses

Voir plus loin que le planning en escalier !


Toutes mes images (sauf les plannings et l’ishikawa) proviennent du site www.pictofigo.com

 Parlons aujourd’hui approche projet, avec un projet tout ce qu’il y a de plus classique :

Situation initiale : activité identique au sein de l’entreprise, mais processus différent dans chacun des départements, avec outils différents et plus ou moins sophistiqués.

– décision prise au niveau de la Direction Générale de déployer un outil déjà existant au sein de l’entreprise, mais seulement pour quelques Départements, avec ses processus associés

– présentation aux parties prenantes

– analyse de l’existant

– gap analysis

– mise en place/adaptation de la gouvernance

– migration et décommissionnement des éventuels anciens outils

– formation au nouvel outil et aux nouveaux processus

– sign-off et « lessons learned »

Situation finale : activité identique au sein de l’entreprise, processus homogénéisés entre les départements, avec outil identique donc unique.

Si l’on pense à la manière dont on déroule ce genre de projet, on observe l’approche suivante : hormis la présentation aux parties prenantes qui peut avoir lieu sous la forme de sessions plénières, le reste des étapes du projet sont menées indépendamment les unes des autres, département après département. Dans ce cas, on obtient le genre de planning ci-dessous dit « en escalier » :

Stair-shaped planning / planning en escalier

Comprenez D pour « Define » qui comprend (pour les 2 phases D du mois de Juin ci-dessus, le cadrage du projet, l’explicitation de l’objectif du projet, le business case, la validation de l’approche projet par le Sponsor, l’identification des parties prenantes, l’établissement d’un macro planning prévisionnel. Les autres phases D se réduisant au cadrage de la partie projet d’un Département donné, avec explications de l’objectif du projet et l’identification des acteurs clefs et la présentation d’un retroplanning.

M pour « Measure » comprenant l’analyse des processus existants, et éventuellement les mesures pertinentes à effectuer.

A pour « Analyse« , correspondant soit à l’analyse des données mesurées, soit au Gap Analysis d’un point de vue processus uniquement. Dans tous les cas, cette phase mène à l’établissement de la (des) solution(s) choisie (s) pour déploiement en phase I pour « Improve« .

La phase C pour « Control« , qui est malheureusement trop souvent absente dans la réalité, permet de finaliser la documentation du projet, assurer un suivi (support) auprès des utilisateurs, mettre en place des tableaux de bords appropriés pour contrôler la bonne marche du processus à long terme. Dans l’idéal, elle devrait même prévoir un plan d’action en cas de mauvais fonctionnement du processus, en documentant des procédures d' »escalation« .

Honnêtement, dans la plupart des cas, c’est ce que nous faisons, nous consultants avec le statut « expert de la gestion de projet ». Et bien voyez-vous puisque nous somme censés être des experts, remettons en cause ce bon vieux planning escalier. Car il est selon moi assez peu adapté à une grande majorité des projets.

Causes-racines de l’échec et/ou de la mauvaise qualité des résultats d’un projet

Voici les 6 principales raisons qui mettent en danger les résultats du projet :

Ishikawa graph of root causes for projects failure

1. Un sponsorpship faible car occupé par ailleurs, devant géré x priorités en même temps, même chose pour le soutien du Management

2. Une approche projet mal adaptée au contexte et au sujet

3. Une communication de mauvaise qualité

4. Des contraintes externes imprévues (qui auraient pu être prévues ?)

5. Une analyse de l’existant bâclée

6. Une conduite du changement mal gérée, peut-être trop hésitante dans son approche

Puisque notre sujet ici est justement de traiter de l’approche projet, voici un focus sur chacune des 5 autres causes racines.

Cause profonde n°1 : Un sponsorpship faible car occupé par ailleurs, devant géré x priorités en même temps, même chose pour le soutien du Management

 Le Sponsorship et le Management ont notamment pour rôle de rappeler les objectifs globaux du projet de manière régulière, directions mises à jours en fonction des aléas de la  vraie vie (changement de contexte, etc.), afin que les parties prenantes conservent une idée claire de ce que vise le projet, et comment il compte atteindre l’objectif. Leur appui est indispensable car ils ont le niveau hiérarchique suffisant pour se faire entendre, contrairement aux ressources projets.

Voici les principaux écueils que peut rencontrer tout chef de projet :

– surestimation de la connaissance mode projet du Management et du Sponsorphip

– mauvaise connaissance ou connaissance partielle du sujet par le Management/Sponsorship

– aucune remise en causes des hypothèses de départ car l’analyse menée est, par construction, trop rapide (en fait la pré-analyse projet)

– gouvernance projet inexistante ou de mauvaise qualité, Comités de pilotage factices, non atteinte du quorum pendant les réunions, manque de soutien et de participation des parties prenantes, mauvaix choix dans les parties prenantes de chacun des Comités de pilotage, etc.

– décision unilatérale des deadlines de la part de l’équipe Projet

– manque de feedback de la part des équipes concernées, le Management n’appuyant pas cette démarche pourtant indispensable à une équipe projet pour éviter des impasses temporaires qui sont chronophages et souvent responsable de la perte de la dynamique autout du projet. Les semaines passent vite dans ces cas-là, semaines que l’on apprécie très souvent en fin de projet !

Cause profonde n°2 : Une communication de mauvaise qualité

Qui ne s’est jamais dit, cette fois-ci c’est la bonne, je commence un projet et j’établis un plan de communication projet dès le départ ? Et combien sur ces mêmes personnes l’ont vraiment fait ? Il est vrai que débarquer sur un nouveau projet, donc un nouveau sujet très souvent, et en plus anticiper ce qu’il faut penser à dire à chacun pour que tout aille « comme sur des roulettes », ce n’est pas évident… Comme dirait un de mes anciens collègues, commercial de métier, : « J’avoue. » Mais la communication n’est-elle pas la première qualité d’un chef de projet ? La communication n’est-elle pas la clef du succès d’un projet ? Un projet, c’est un tout petit bout de l’histoire d’une entreprise qui doit concentrer pendant sa durée de vie (pas très longue en fait) le maximum d’informations entre toutes les parties prenantes, pour être bien sûr que tout se soit dit, tout se soit échangé et tout se soit appris.

Voici ce qu’implique souvent le manque de communication :

– les parties prenantes manquent de perspectives, donc de motivation, il y a plus d’inertie autour du projet, ce qui ralentit son déroulement et met en risque l’atteinte de ses objectifs. Si les parties prenantes ne sont pas bien informées de ce que l’on attend d’elles, alors le délai de livraison augmente. Ce sont quelques jours par-ci par-là, mais additionnés à la fin du projet encore une fois, cela peut faire la différence.

– la communication doit aussi être très soignée, notamment en ce qui concerne les sujets Ressources Humaines, réglementaires, audit, etc. Eviter les scandales de non respect de la confidentialité de données, ou de divulgation prématurée d’informations très structurantes, c’est mieux. Penser à vérifier avec les experts si vous avez le moindre doute !

– Dans de très nombreux projets, des notions d’écarts ou de différences interviennent, lors de rapprochements de listes d’opérations, d’effectif, etc. Si la MOA et la MOE ont Quality Center pour s’aider (enfin quand l’outil est bien utilisé et expliqué), les chefs de projets en organisation n’ont guère d’autres outils que les emails. Mais la problématique est la même : ne pas laisser de côté pendant des semaines des petits points en suspend qui vont se révéler être les grains de sable dans l’engrenage à la fin d’une étape ou d’un projet. Pire, on peut même les oublier pendant le projet et ils resurgissent, malveillants, en production. Une bonne coordination est donc nécessaire.

– Les clients du projet doivent être particulièrement pris en compte, dans leur réaction, leurs contraintes, car ce sont eux qui vivront avec le fruit du projet et ce sont aussi eux qui subissent le changement, ce qui est un effort de tous. Accessoirement ce sont également eux qui font un retour comme on dit sur votre projet, bref qui vous évaluent. Les conséquences de toute décision doivent être partagées avec eux, afin qu’ils puissent réagir le plus tôt possible et éventuellement vous faire changer d’avis ou tenter d’influencer les décisionnaires dans l’autre sens si besoin est. Le sponsor attend de vous que vous lui fournissiez ces informations précieuses, ainsi que le Management pour qu’ils puissent communiquer les meilleurs orientations.

– Si la formation aux nouveaux produits/services/processus fait partie de la communication, alors faites en sorte de rendre ce moment agréable pour tous. C’est un des rares moments où il est possible de se détendre et de ce fait de créer un esprit de groupe positif autour de votre projet.

Cause profonde n°3 : Des techniques de gestion de projet de mauvaise qualité

Ce paragraphe relève également de la communication, mais autour des livrables classiques de la gestion de projet.

Voici les principaux points d’attention :

– Etablir un planning, ce n’est pas facile, on ne sait pas combien de temps prend chaque étape du projet, et il faut donc communiquer, répéter, reformuler jusqu’à ce que tout le monde ait bien en tête son rôle et ce qu’attend le prochain collaborateur dans la chaîne. L’établissement de Check list, de Ressources planning communément validés sont souvent de bons outils.

– Le périmètre d’un projet est mouvant, il n’y a que très peu de cas où le périmètre est défini une bonne fois pour toute dès le départ. Ce n’est pas grave, en revanche, une mauvaise communication sur le dernier périmètre validé entraîne de la résistance, un travail partiel voire erroné, un retravail chronophage qui, encore une fois, met en danger la date de fin de projet.

– Si le Chef de Projet se doit de fournir un macro planning dès le départ, il ne peut le faire tout seul. Le Chef de Projet n’est pas l’expert de tous les sujets qu’il va devoir coordonner. Il doit s’appuyer sur ces experts pour le construire, à partir des bouts de planning qu’on voudra bien lui fournir. C’est le côté PMO du chef de projet et cette partie de son rôle ne doit pas être négligée.

– Le Chef de Projet détient le planning global du projet entre ses mains et c’est son outil de pilotage. Mais n’oubliez jamais qu’une communication régulière auprès des autres parties prenantes peuvent également les aider à piloter leur propres activités, et une communication juste et régulière des Status Reports permet une fluidification des actions entre les parties prenantes.

Cause profonde n°4 : Les imprévus ou la gestion de la « vraie vie » de projet

Cela peut être par définition n’importe quoi, du changement du programme, à la survenue d’une crise, le départ d’une personne clef. Bon. Mais voici quelques autre petits points moins extraordinaires qui viennent s’ajouter à la difficulté :

– Il arrive qu’on « vende » un processus couplé d’un outil pas si performant que ça… Mais il va falloir faire avec. Le tout est de soigner la communication et de réfléchir à comment contourner le problème le plus intelligemment possible si la solution de changer drastiquement le processus et/ou l’outil n’est pas envisageable.

– La communication d’un outil avec les autres outils et l’étude des processus liés à celui que l’on veut déployer n’est pas superflue. La prise en compte de ces informations vous permettra probablement  d’augmenter l’adhésion autour de votre projet. Attention toutefois à ne pas se noyer dans la masse d’informations que cela génère.

Cause profonde n°5 : Une analyse de l’existant bâclée

On ne se renseigne jamais assez sur l’historique. C’est un prérequis. Pourquoi ? Parce qu’apprendre quelles sont les étapes qui ont abouti à la décision de mettre en place un projet vous permet de comprendre les hypothèses de départ qui ont amenés vos prédécesseurs à prendre les décisions qui vous impactent aujourd’hui. En fouillant davantage, vous obtenez une bien plus complète compréhension du sujet. Par ailleurs, cela n’engage que moi mais réfléchir à nouveau et reprendre le raisonnement d’une autre personne me permet de monter en compétences sur un projet plus rapidement et plus sûrement. Car tout ce que vous ne comprenez pas, ce sont LES questions à poser, et tout ce qu’une autre personne n’a pas penser à creuser pourrait être une trouvaille fondamentale.

Voici les principaux pièges à éviter :

– Un Gap Analysis n’est de qualité que si l’analyse des processus et des outils existants est correctement réalisés. La « voix du client » des parties prenantes concernées doit être rigoureusement écoutée. Si des collaborateurs ont connu un projet similaire, il s’agit de récupérer leurs points de vue et leur expérience.

– Le processus cible doit être décrit de manière suffisamment détaillé pour que le changement demandé ne reste pas « conceptuel », mais pour que chaque partie prenante puisse entrevoir les conséquences pratiques d’un tel changement.

– Le partage des responsabilités doit être correctement effectué et décrit, sinon l’implémentation du nouveau processus sera défaillante.

– Le timing doit être également pris en compte : le processus est un phénomène vivant.

– L’analyse des processus existants doit comprendre les processus amont et aval, ou tout du moins les contraintes d’entrée et de sortie sans quoi on ne saurait « raccrocher » le bout de processus étudié avec le reste de l’organisation de l’entreprise.

– Attention à la non remise en question des cartographies / procédures existantes, souvent trop vieilles, non mises à jour, mal rédigées voire erronées.

– Enfin, un point sur l’établissement d’une matrice utilisateurs x profiles afin de clarifier et d’éprouver les rôles et responsabilités précédemment définis.

Cause profonde n°6 : Une conduite du changement trop légère et hésitante

– Le Management n’appuie pas votre initiative. Vous pouvez vous retrouver seul, mais autant l’anticiper.

– Un processus n’est jamais idéal, cela ne sert à rien de cacher les défauts du système que vous voulez mettre en place, les langues s’occuperont de rétablir la vérité (voire d’être plus négatives que la réalité) en dehors de vos réunions « marketing« .

– Les compétences gestion de projet sont très différentes d’une entreprise à l’autre et d’une équipe à l’autre. Veillez à bien l’évaluer afin de rappeler les fondamentaux si besoin est.

– Ne soyez pas trop laxiste sur l’obtention des validations du management. Sans elles, il est difficile d’avancer puisque ces validations constituent les fondations de votre projet.

– De même, il faut lutter contre le flou artistique en permanence, et veiller à obtenir des définitions opérationnelles des notions clefs de votre sujet.

– Pensez à vérifier la disponibilité des environnements de tests pour vos formations. Les « boulettes » en production, tout le monde s’en passe très bien.

– Les formations ne sont pas à retarder, plus les personnes connaissent correctement le sujet et plus elles vous aident à progresser dans votre démarche en vous pointant les incohérences éventuelles de votre démarche.

– Pensez à recenser toutes les demandes d’évolutions pour ceux qui vous suivront, s’il n’est pas possible pour vous de les mettre en place pendant le déroulement de votre projet.

– Lorsque le processus cible est connu d’avance, et qu’il est plus ou moins imposé aux parties prenantes, écoutez, nuancez, expliquez, il n’y a rien d’autre à faire. Sauf si vous pensez que se lancer dans un bouleversement global du projet peut être positive.

– De jamais considérer le gap analysis comme étant hors sujet. Comment pourrait-il l’être ???!

– lutter au maximum contre le double reporting et les outils historiques / nouveaux qui tournent en parallèle. Cela est redondant et donc inefficace.

– Pensez à faire valider chaque étape fondamentale de votre projet (Check list de validation d’étape ? Tollgate review ?). Cela permet de responsabiliser les parties prenantes et aussi d’avancer de manière plus sereine dans votre projet.

– Une petite vérification de la livraison des tâches de certains acteurs-clefs de votre projet de temps à autres, même quand il est dit que tout est livré, n’est que rarement superflu. Cela évite les mauvaises surprises lors des réunions de validation. « Ah bon ce n’est pas prêt ? » « Euh… non… Désolé… ».

Suggestion d’approche projet en organisation

Comment éviter, contrecarrer les pièges et autres écueils ci-dessus ? Comment faire pour les minimiser ? Pourquoi pas faire comme suit :

Phase n°1 : Pré-analyse et développement de l’expertise

Tout bout de processus concerné par le sujet doit être parfaitement connu, mais pas seulement. Une vue plus large sur les processus amont et aval vous fournit une véritable expertise car vous pouvez directement répondre à toutes les questions des parties prenantes et anticiper leurs spécificités.

De même tout processus similaire, ou ayant un objectif similaire doit être étudié. Pourquoi n’est-il pas concerné par le projet ? Les axiomes de départ ont-ils été vérifiés ? Quelles sont leurs spécificités ? En général, cette étude aboutit à une modification de votre périmètre projet pour mieux répondre aux objectifs de l’entreprise.

Cette pré-analyse est fondamentale pour votre projet. Elle fait de vous l’expert du sujet.

Phase n°2 : Phase d’annonce

La phase de pré-analyse vous aura sans doute permis de clarifier le périmètre et préciser votre approche projet, ce qui vous permet d’établir un planning bien assis. Sur cette base, vous pouvez établir votre plan de communication et commencer par une présentation de votre projet au moyen de sessions plénières si besoin est. Le Top Management doit y participer, aussi bien les utilisateurs historiques que les nouveaux utilisateurs pour qu’aucun bruit de couloir n’affaiblisse votre projet. La Direction Générale doit évidemment vous soutenir dans le cas où elle est à l’initiative du projet. Elle doit présenter ses objectifs, ses contraintes, l’historique qui l’a amenée à prendre une telle décision, elle doit clarifier la problématique. Cette présentation doit expliquer la valeur ajoutée de chacune des étapes du projet, et ce que l’on attend des parties prenantes pour que tout se déroule correctement. Souvent cela commence par l’identification des acteurs clefs qui seront amenés à travailler avec l’équipe projet.

Ces informations/questions/réflexions doivent également être répétées pendant la présentation du projet à chacun des acteurs clefs identifiés (approche top-down de communication).

C’est à la fin de cette phase que l’on doit d’ores et déjà penser à la conduite du changement  et donc au plan de communication. Les utilisateurs historiques doivent être mis dans la boucle très tôt, cela permet de ne pas laisser une sensation de mise à l’écart. Pour vous leur retour est essentiel puisque ce sont les seuls à pouvoir vous fournir un feedback sur le processus cible ! Il est probable cependant que le nouveau projet modifie légèrement leur processus cible, à court ou moyen terme. Encore une fois, pris dès le départ, cette réflexion aura davantage de chance d’être acceptée. L’analyse des processus existants des utilisateurs historiques est à commencer ici.

Enfin, c’est durant cette phase qu’il doit être mis en place un système de reporting projet renforcé et efficace, ne demandant pas trop de temps de mise à jour. Pensez également au système de la Newsletter pour peaufiner votre communication.

Phase n°3 : L’analyse de l’existant

Tout ce qui n’est pas identifié et anticipé dès le début du projet peut resurgir à tout moment du projet et mettre en péril votre date finale de livraison. Souvent une bonne analyse de l’existant, c’est-à-dire complète, non bâclée, permet d’éviter les écueils suivants :

– résistance au changement car sentiment de non prise en compte d’un service donné dans la réflexion

– décisions erronées car fondées sur des processus mal décrits et/ou mal cartographiés, ou car fondées sur une connaissance partielle des processus de l’entreprise

– changement radical du processus cible à déployer en milieu de projet

– découvertes des spécificités de chaque département au fur et à mesure de leur rencontre pour déploiement du processus cible et donc une conduite du changement saccadée

L’analyse de l’existant doit comprendre :

– l’analyse des processus existants des utilisateurs historiques et la vérification des axiomes de départ (ils ont tous le même processus ! Mouais, ou pas…)

– description détaillée du processus cible (souvent inspiré d’un processus existant trop rapidement décrit)

– compréhension des processus en amont pour mieux comprendre les inputs du processus cible

– compréhension des processus en aval pour mieux comprendre les outputs du processus cible

– en bref une analyse de bout en bout pour comprendre la Voice Of the Customer

– analyse des processus existants à remplacer par le processus cible pour optimiser la conduite du changement grâce à un Gap Analysis de meilleur qualité

– le processus de migration qui permet de passer d’un outil à l’autre. Ce dernier est très important pour que vous puissiez maîtriser votre planning. Par ailleurs c’est également lui qui vous permettra de comprendre les phases qui peuvent être consolidées pour l’ensemble de votre périmètre et les phases à effectuer une par une au fur et à mesure de la rencontre des équipes chez qui le processus cible doit être déployé.

En résumé, cette analyse de l’existant détaillée vous permettra de :

– ajuster le processus cible, prenant en compte au maximum les spécificités de chacun

– mieux anticiper la charge associée à la migration et donc de mieux maîtriser votre planning projet

– optimiser l’adhésion des différents services à votre projet, surtout lorsqu’il s’agit d’une décision de la Direction Générale qui ne plait pas forcément à tout le monde

– répondre de manière professionnelle aux objectifs initiaux, en ajoutant les mesures d’accompagnement nécessaires et en collectant les données vous permettant d’être un chef de projet consciencieux et précis. C’est le rôle du Département Organisation d’une entreprise de penser « transverse » en prenant en compte l’intégralité des informations relatives au sujet qu’on vous a confié. Concentrer toutes les informations concernant les implications de toute décision du sponsor tout au long du projet, en partageant et en comprenant les impacts avec l’ensemble des parties prenantes, chercher systématiquement à intégrer les tenants et les aboutissants d’un projet, voici le rôle d’un chef de projet au sein du Département Organisation. Il n’y a pas d’autres postes dans l’entreprise qui soit aussi central en matière de consolidation de l’information. Cette consolidation d’informations a une durée de vie limitée : celle du projet. C’est elle qui permet d’aboutir avec succès.

Phase n°4 : Derniers préparatifs

Même si on n’effectue que très rarement la cartographie des acteurs, le premier contact permet d’évaluer la résistance au changement qui est plus ou moins importante suivant les profils, l’historique du département autour du sujet, etc. Il s’agit donc d’ajuster le planning en fonction de ce paramètre. C’est pourquoi rencontrer tout le monde dès le début du projet est nécessaire, d’autant que cela permet de laisser le choix aux personnes impliquées sur le moment du semestre où il est opportun de les faire travailler sur votre projet.

Même si certains départements ne sont concernés que par une partie du projet, par exemple uniquement par la formation et non par la migration vers le nouvel outil, il s’agit de les rencontrer au plus tôt, faute de devoir speeder à la fin du projet car « on a pensé qu’on avait le temps ».

Par ailleurs, si jamais le processus cible à déployer n’était pas idéal, au lieu de s’en rendre compte en plein milieu du projet, le fait d’avoir rencontré tout le monde dès le début du projet vous permet d’ajuster ce processus cible dès le départ, d’où une communication bien plus solide (pas besoin de recontacter les gens chez qui on a déjà déployé le processus cible bancal, avec son air le plus piteux !)

Vous pouvez même entrevoir à ce stade des actions non considérées au départ dans votre projet, mais qui permettraient d’aller plus loin, d’être plus complet dans l’approche. Ne vous mettez pas d’objectifs irréalistes, mais gardez ces actions de côté pour vous : si vous avez le temps, et que vous pouvez les mettre en place, ce sera encore mieux !

Phase n° 5 : Déploiement

C’est là que nous arrêtons de réfléchir pendant des heures et qu’on rentre dans le vif du sujet, c’est aussi à ce moment que le Business est rassuré car vous allez pouvoir commencer à livrer et c’est la seule chose qui intéresse le Business. Pour autant il est de votre devoir de chef de projet en organisation de réfréner cette naturelle obsession du Business à vouloir livrer tout de suite, car c’est comme ça que vous répondrez mieux à leurs demandes, même s’ils vous soutiennent le contraire mordicus. C’est qui l’expert projet, eux ou vous et votre équipe ?

C’est dès le début du déploiement que doit commencer la conduite du changement et pour tout le monde. Pourquoi ? C’est très simple :

– vous faites monter en compétences vos interlocuteurs sur le sujet, qui ont donc l’impression d’être mis dans la boucle dès le départ, et qui sont moins inquiets face au changement car ils le maîtrisent mieux eux-mêmes. Par ailleurs, leur collaboration et leur point de vue critique vous seront très utiles pour mener un déploiement impeccable. Ils seront en mesure de détecter d’éventuels anomalies et vous donneront l’opportunité et le temps de les corriger. Le service rendu est donc de meilleur qualité de cette manière.

– vous augmentez l’adhésion à votre projet car vous permettez à vos interlocuteurs de voir concrètement la valeur ajoutée du projet. Le conceptuel n’étant pas la passion de tout le monde, encore une fois l’inquiétude et donc la résistance au changement diminue en montrant les livrables, les possibilités de l’outil, en bref ce que vos interlocuteurs ont concrètement à y gagner avec votre projet.

– tant que le projet reste conceptuel, le management vous identifiera des acteurs clefs mais il se peut que certains se trompent. Si vous les formez dès le départ, ces mêmes personnes choisies par erreur pourront vous dire qu’elles ne sont pas les bons interlocuteurs et, encore une fois, vous pourrez ajuster le tir an amont. D’autant que vous pouvez également découvrir que des sessions de formation supplémentaires doivent être organisées : autant vous laisser le temps de les livrer.

C’est également dès le départ et pour tout le monde que doit commencer le Gap Analysis. Pourquoi ? Voilà  pourquoi :

– c’est lors du gap analysis de chacun des départements que vous recensez les besoins et les spécificités de chacun. Avant de mettre en place vos actions qui décideront de prendre en compte telle ou telle demande supplémentaire, vous avez besoin de savoir combien de personnes sont concernées. Le fait d’avoir rencontré tout le monde vous permet de construire une matrice des priorités. Vous pouvez même imaginer la tenue de sessions de brainstorming inter-Département. N’oubliez pas que la valeur ajoutée de votre rôle est censée être le fait de dédier du temps à une analyse transverse d’un sujet. Les demandes d’évolution doivent être capturées tout au long du projet de manière consciencieuse.

La migration des Départements vers le nouvel outil doit être étudiée au moyen du processus de migration que vous avez cartographié préalablement. C’est ici que vous savez s’il est possible de s’occuper de cette phase one shot ou d’être obligé de reprendre, pour cette partie du projet seulement, ce bon vieux planning en escalier. Ici c’est souvent le cas, pour des raisons de disponibilités des ressources expertes sur le sujet. Par ailleurs il est bien probable que le Business dût valider un certain nombre de livrables nécessaires aux experts fonctionnels pour la migration. Et la taille des départements peut avoir un impact non négligeable sur la charge associée à la migration. Votre planning doit en tenir compte.

Une fois le déploiement et la migration réalisés, lorsque vous annoncez le Validation meeting à vos clients côté Business, vous vous êtes évidemment assuré auparavant au moyen d’un genre de « dress rehearsal » que tout allait bien. Il est hors de question que ce Validation meeting échoue et entraîne un deuxième Validation meeting. On est d’accord. Le meilleur moyen de s’en assurer est de créer une Check List de validation. Tous les feux doivent être au vert avant. Invitez le Management autant que possible pour promouvoir votre projet, et vendre la qualité de service des experts fonctionnels. Remettez à ce moment des livrables « marketing » tels que les exemples de  livrables du nouvel outil, personnalisés pour le Département concerné, des supports de formation en français et en anglais, des fiches techniques plastifiées, des leaflests « marketing« . Vous devez éblouir ! enfin autant que possible quoi. C’est le moment ou jamais 😉

Phase n° 6 : Lessons Learned

C’est une réunion qui a lieu une fois que l’équipe projet est passée. Tout le monde est plus détendu, et peut parler de manière constructive sur ce qui s’est bien passé et ce qui s’est moins bien passé. Échanger avec l’équipe projet et les autres équipes qui ont vécu le même changement est très instructif pour tout le monde. Les réactions du type « Ah bon ?! Je ne savais pas que vous aviez à faire ceci ! » sont assez classiques et permettent aux interlocuteurs de mieux se comprendre et donc d’être plus indulgents. Vous leur apprenez en quelque sorte à travailler en groupe sur un projet. Enfin, c’est un des rares moments où vous avez un feedback sur votre projet et cela vous servira pour les prochains. Une impression de clôture du projet est ainsi faite, ce qui ne peut nuire à votre image !

Phase n° 7 : Contrôle

La phase de contrôle est trop rarement tenue. Elle comprend :

– le support aux utilisateurs pour qui la migration est récente, pendant quelques semaines environ.

– la mise en place des tableaux de bords côté experts fonctionnels qui permet de piloter et donc de contrôler l’efficacité du nouveau processus mis en place. C’est l’outil de pilotage qui doit être livré avec le processus et les indicateurs clefs formalisés. Des reporting construits de manière synthétiques et intelligentes doivent être construits.

– la rédaction d’un document Post-Mortem pour capitalisation sur le projet

– une communication finale pour annoncer les résultats obtenus et clore le projet !

Conclusion

Le très classique planning en escaliers est à remettre en cause autant que possible. Mutualiser les étapes entre elles vous permet non seulement d’être plus rapide, mais également d’être plus précis. Bref, vous appliquez le Lean Management à votre propre approche projet : réagir plus vite pour mieux répondre à la demande du client.

D’où un planning Lean comme par exemple :

Publicités

Discussion

Pas encore de commentaire.

Laisser un 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 )

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 )

Photo Google+

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

Connexion à %s

Follow me!

%d blogueurs aiment cette page :