Les modèles de réussite et d’échec en gestion de projets
En déroulant le film de l’année 2007, je me suis demandé ces quelques questions : quels sont les projets qui ont été concluants pour nous? Quels sont les projets qui ont été décevants ou ont carrément échoué et pour quelle raison? J’aimerais m’étaler ici sur les modèles de réussite et d’échecs que nous avons identifiés dans notre propre entreprise en espérant que ces informations vous seront utiles et vous traceront la voie vers une nouvelle année prometteuse et fructueuse.
Les facteurs d’échec :
Mauvaise prise en charge des attentes. Dans quelques situations nous avons eu affaire à des gens qui voyaient dans le logiciel une sorte de baguette magique. Une fois l’application mise en œuvre, ils sont découragés par tout l’effort qu’il y a à fournir. Ils sous-estiment les investissements continus et la gestion des changements qu’il faut pour générer des rapports, mettre en place des tableaux de bord et effectuer les intégrations que l’encadrement attend d’eux. Dans le cas de Tenrox, nos gestionnaires de projets doivent travailler plus à décrire le processus, en mettant l’accent (voire en insistant) sur l’approche graduée (au lieu du big-bang)
et en expliquant les problèmes inhérents à l’implémentation des logiciels d’entreprise. J’ai consacré dans mon livre The Rise of the Project Workforce: Managing People and Projects in a Flat World, publié par Wiley & Sons 2007, (pour plus d’informations consultez le site www.projectworkforcebook.com) des chapitres entiers à l’élaboration de l’analyse de rentabilité, aux défis d’implémentation et à l’adoption du produit par les utilisateurs. Je conseille fortement la lecture de ces chapitres à quiconque veut rechercher un logiciel d’entreprise et se lancer dans un projet d’implémentation.
Exigences initiales et/ou changements mal exprimés. Ceci arrive très souvent et on se sent
tous désarmés face à cette situation. Les parties prenantes au projet font de nouvelles demandes, changent d’idée ou découvrent de nouvelles exceptions en pleine réalisation du projet. Des fonctionnalités qui étaient au début « intéressantes à avoir » deviennent tout à coup une « nécessité » ou une exigence « vitale ».
C’est la faute aux autres! Dès lors que les choses vont mal, les membres d’équipes de projets (que ce soit à l’intérieur ou à l’extérieur de l’entreprise) commencent à se rejeter la responsabilité. Il reste que dans 95% des cas que nous avons examinés, les échecs sont l’aboutissement d’un travail collectif à cause des erreurs, de l’incompréhension, du manque d’expertise, du faible contrôle, du mauvais jugement, de la mauvaise communication, d’une gestion approximative du projet ou d’une combinaison de ces facteurs par chacun des intervenant internes ou externes. Par ailleurs, on ne cesse de se plaindre en interprétant les contrats et les ententes écrites juste pour se dédouaner et rejeter le blâme sur les autres.
Lenteurs. Le lancement d’un projet est toujours précédé par une multitude d’activités. Cependant, les projets qui connaissent l’échec sont souvent caractérisés par la lenteur de l’exécution ou l’inactivité une fois les travaux démarrés. On mobilise des ressources importantes et beaucoup d’attention pour la résolution des crises ou des problèmes plus urgents. Ces retards ont pour effet de freiner le projet, d’en changer la portée et de détourner ses priorités. Ce faisant, les intervenants perdent dès le départ l’élan et la passion qu’ils avaient initialement de mener le projet à bon port.
Les facteurs de réussite :
Petites équipes. L’équipe de projet est souvent très réduite (pas plus de 5 personnes); les petites équipes permettent de nouer des relations fortes entre leurs membres qui deviennent de bons amis et collègues collaborant main dans la main pendant toute la durée du projet. Ces équipes semblent plus heureuses et plus dynamiques et ont un degré de satisfaction plus élevé lorsque les objectifs du projet sont réalisés. Lorsque je reviens sur ma propre expérience durant ma carrière, il y a avait toujours une petite équipe derrière les projets réussis; ce sont les projets dont je suis le plus fier et qui restent gravés dans ma mémoire.
Collaborer sans blâmer. Les membres des équipes qui connaissent la réussite savent implicitement que personne n’est à blâmer lorsque les choses ne vont pas bien. Notre étude montre que les projets réussis rencontrent depuis leur démarrage jusqu’à leur achèvement autant (sinon plus) d’obstacles que les projets échoués. C’est l’effort de collaboration des membres de l’équipe et leur passion à venir à bout des problèmes qui tracent la ligne de démarcation entre la réussite et l’échec. Les intervenants du projet reconnaissent tous qu’ils forment un bloc.
La relation n’est pas perçue sous l’angle « client/fournisseur » mais plutôt comme des professionnels travaillant ensemble pour atteindre un objectif commun.
Expérience. L’implémentation des logiciels d’entreprise peut s’avérer très difficile si le client ne comprend pas assez les nombreux défis qui se mettront au travers du projet. Les professionnels aguerris en gestion de projets ont les aptitudes et qualifications nécessaires pour s’occuper des problèmes de politique interne, d’adoption par les utilisateurs, de changements de périmètre, de déploiement et d’intégration.
Retrousser ses manches. Tout comme dans le cas de « petites équipes », les gestionnaires et équipes de projets qui connaissent le succès agissent beaucoup et délèguent peu. Vous n’entendrez jamais une personne dire « j’ai confié une tâche à quelqu’un et il ne l’a pas accomplie », « j’ai demandé à untel de s’en occuper et je ne sais pas ce qui est arrivé », « Je croyais que c’était fait », « Cela ne relève pas de ma responsabilité ». Les choses sont tout simplement accomplies. La hiérarchie et la délégation ne sont pas utilisées comme des prétextes pour se dédouaner de ses responsabilités.
Retour au bon vieux téléphone. Les projets mal gérés sont l’objet d’un échange incessant de courriels entre les intervenants avec des fils de discussion interminables entre messages, réponses, re-messages et re-réponses. Les équipes de projets efficaces se rencontrent une seule fois ou se servent du téléphone pour se parler directement. Les divergences sont vite aplanies et les membres de l’équipe s’entendent sur une solution qui est presqu’immédiatement mise en œuvre.
Gestion fondée sur les jalons. Les équipes de projets efficaces comprennent que les projets de logiciels d’entreprise ne se terminent pour ainsi dire jamais. Il y a toujours un rapport, un tableau de bord, une amélioration ou une intégration dont on a absolument besoin. Le seul moyen d’achever un projet de logiciel d’entreprise et de définir des jalons et de célébrer les réalisations tout en définissant en cours de chemin de nouveaux objectifs à atteindre. À défaut de reconnaître et de célébrer les succès successifs, il n’y aura pas de sentiment d’accomplissement et les parties prenantes auront l’impression d’avoir affaire à un projet en état d’exécution permanente.
2007 fut une formidable année pour Tenrox et ses clients. Nous avons réalisé un nombre record de projets fructueux pour nos clients. Nos équipes de projets et clients ont appris à éviter ces modèles d’échec et découvert comme favoriser et encourager les modèles de réussite.
Nous célébrons la venue de la nouvelle année avec vous tous et vous souhaitons une bonne et heureuse année 2008 remplie de gloire et de distinctions.
