Serge Masanovic
Aujourd’hui, nous sommes en droit de nous poser des questions sur les résultats obtenus par la généralisation de cette pratique managériale ?
Les plus critiques parlent d’échecs, de désastres financiers et humains. En informatique, disent-ils, « un projet réussi est… une exception ». Sans tomber dans la caricature, nous devons reconnaître que les résultats des projets informatiques sont en général très décevants, au regard des efforts humains et des budgets alloués. Pour s’en convaincre, il suffit d’évoquer le sujet près de la machine à café. On vous raconte alors l’histoire d’échecs retentissants : délais dépassés de plusieurs années et projets abandonnés, budgets sans commune mesure avec les prévisions initiales, application inutilisée, procès en cours avec les fournisseurs, directeurs de projet mis au placard…
Mesure-t-on réellement les succès ou les échecs des projets informatiques et sommes-nous en mesure d’en tirer des enseignements ?
Si l’échec du projet informatique fait beaucoup parler de lui, nous disposons en revanche de peu d’informations sur les causes réelles de cet échec. Les entreprises ne réalisent pas de statistiques internes. Les seules réflexions post projet sont limitées à des « retours d’expérience », dont l’utilité reste à démontrer et la diffusion du bilan restreinte aux principaux protagonistes. Enfin, aucun organisme indépendant ne publie régulièrement de donnés sur le sujet.
Que croire ? Pour bien comprendre l’ampleur des échecs, nous citerons quelques résultats d’une étude menée il y a quelques années aux Etats-Unis par Standish Group. Ces résultats nous laissent songeur :
- 31% des projets ne seront jamais terminés.
- Plus de 52% des projets auront un coût représentant 189% de l’estimation initiale.
- Uniquement 16% des projets se termineront dans les budgets et les délais initiaux ; ce chiffre tombe à 9% pour les grandes entreprises.
- Le délai moyen de dépassement des projets est de 230%.
- Sur 100 projets lancés, 94% devront en définitive être relancés.
Les ordres de grandeur sont affligeants ! En période de crise économique et donc de restriction budgétaire drastique, il nous semble judicieux d’analyser les causes d’échec.
Les plus critiques parlent d’échecs, de désastres financiers et humains. En informatique, disent-ils, « un projet réussi est… une exception ». Sans tomber dans la caricature, nous devons reconnaître que les résultats des projets informatiques sont en général très décevants, au regard des efforts humains et des budgets alloués. Pour s’en convaincre, il suffit d’évoquer le sujet près de la machine à café. On vous raconte alors l’histoire d’échecs retentissants : délais dépassés de plusieurs années et projets abandonnés, budgets sans commune mesure avec les prévisions initiales, application inutilisée, procès en cours avec les fournisseurs, directeurs de projet mis au placard…
Mesure-t-on réellement les succès ou les échecs des projets informatiques et sommes-nous en mesure d’en tirer des enseignements ?
Si l’échec du projet informatique fait beaucoup parler de lui, nous disposons en revanche de peu d’informations sur les causes réelles de cet échec. Les entreprises ne réalisent pas de statistiques internes. Les seules réflexions post projet sont limitées à des « retours d’expérience », dont l’utilité reste à démontrer et la diffusion du bilan restreinte aux principaux protagonistes. Enfin, aucun organisme indépendant ne publie régulièrement de donnés sur le sujet.
Que croire ? Pour bien comprendre l’ampleur des échecs, nous citerons quelques résultats d’une étude menée il y a quelques années aux Etats-Unis par Standish Group. Ces résultats nous laissent songeur :
- 31% des projets ne seront jamais terminés.
- Plus de 52% des projets auront un coût représentant 189% de l’estimation initiale.
- Uniquement 16% des projets se termineront dans les budgets et les délais initiaux ; ce chiffre tombe à 9% pour les grandes entreprises.
- Le délai moyen de dépassement des projets est de 230%.
- Sur 100 projets lancés, 94% devront en définitive être relancés.
Les ordres de grandeur sont affligeants ! En période de crise économique et donc de restriction budgétaire drastique, il nous semble judicieux d’analyser les causes d’échec.
Christophe Coupé
Nous en avons retenu 4 :
- La rivalité : en devenant une pratique majeure de management, le projet devient un terrain de conflit où les enjeux politiques, personnels, financiers s’affrontent ouvertement. Cette rivalité concerne aussi bien les acteurs internes de l’entreprise que tous les fournisseurs concernés. Il va s’en dire que cette rivalité se fait au détriment de l’entreprise.
- La mesure : le projet étant un exercice sous contrainte (budget, délais, qualité de service), on pourrait croire que les règles de l’ingénieur s’appliquent et que, par conséquent, tout est défini, prévu et mesuré. En pratiquant de près le projet informatique, il s’avère que tout fonctionne de manière archaïque, voire approximative. Des données chiffrées relatives au projet sont en effet produites, mais elles sont souvent inutilisables ou incompréhensibles.
- La logique de résultat : d’un point de vue théorique, un projet se résume à un ensemble de tâches, qu’il convient d’organiser judicieusement, pour obtenir des résultats intermédiaires et un résultat final. Là encore la rigueur de l’ingénieur est mise à mal. Cette logique de découpage doit inévitablement conduire à mettre en œuvre une logique de délivrables et de forfaits. Dans la pratique, l’obligation de résultat n’existe pas. L’entreprise peine à préciser le résultat attendu. Le fournisseur cherche à vendre une intervention en régie plutôt qu’un forfait et, lorsque le forfait s’applique, il cherche à mettre en défaut son client, de façon à appliquer des pénalités.
- L’outillage : les entreprises se sont équipées en outil de gestion et de pilotage de projet, voire de gestion de portefeuille de projets. Cette automatisation du pilotage s’est réalisée au détriment du développement d’un management humain. L’instrumentalisation et la manipulation des données devait remplacer dans les faits le rôle d’organisateur, de communiquant et de meneur d’équipes que doit assurer et assumer la direction de projet.
Dans la mesure où le projet est par nature un saut dans l’inconnu et où l’informatique reste une activité en évolution permanente, un projet informatique sera toujours un projet à risque. Les échecs sont possibles mais pour autant cela ne doit en aucun cas être la règle.
Notre conviction, partagée avec certains clients (pas tous), est qu’il faut revenir à des règles de bon sens :
- Imposer une logique de délivrables et lotir le projet de manière forfaitaire. Si le premier délivrable n’est pas de qualité, il ne faut pas hésiter à le refaire, ou arrêter purement et simplement le projet.
- Définir des critères ou indicateurs de mesure, avec simplicité et pragmatisme. Un projet peut tout à fait se piloter avec 4 ou 5 indicateurs, pourvu que tous les acteurs comprennent bien de quoi il s’agit.
Former et valoriser la fonction de Directeur de projet informatique. Il reste la clé de voute de tout l’édifice. L’outillage est un moyen de gagner du temps, pas une nécessité.
Si ces principales règles de bon sens sont appliquées, alors les rivalités seront moindres, sans pour autant disparaître. Leur pouvoir de nuisance en sera limité et maîtrisé.
Pour que le projet informatique reste une aventure humaine passionnante et efficace, il faut impérativement repenser son management. L’échec ne doit plus être la règle mais bien l’exception.
Serge Masanovic & Christophe Coupé
Christophe Coupé, Ingénieur en Télécommunications, docteur en Economie et consultant, s’intéresse à l’inscription sociale des techniques. Il accompagne les dirigeants et managers pour mesurer la performance et la valeur créée par les projets informatiques.
Serge Masanovic, Associé fondateur de VCM Conseil, est un expert en économie des SI. Il intervient pour anticiper les gains et les bénéfices attendus des projets SI, pour identifier les gisements d’économie et enfin pour mesurer et pilote la performance du SI au quotidien.
VCM Conseil
201, rue de la convention
75015 PARIS
www.vcm-conseil.fr
Retrouvez chaque jeudi l'actualité du BPM sur :
www.bpm-channel.com
- La rivalité : en devenant une pratique majeure de management, le projet devient un terrain de conflit où les enjeux politiques, personnels, financiers s’affrontent ouvertement. Cette rivalité concerne aussi bien les acteurs internes de l’entreprise que tous les fournisseurs concernés. Il va s’en dire que cette rivalité se fait au détriment de l’entreprise.
- La mesure : le projet étant un exercice sous contrainte (budget, délais, qualité de service), on pourrait croire que les règles de l’ingénieur s’appliquent et que, par conséquent, tout est défini, prévu et mesuré. En pratiquant de près le projet informatique, il s’avère que tout fonctionne de manière archaïque, voire approximative. Des données chiffrées relatives au projet sont en effet produites, mais elles sont souvent inutilisables ou incompréhensibles.
- La logique de résultat : d’un point de vue théorique, un projet se résume à un ensemble de tâches, qu’il convient d’organiser judicieusement, pour obtenir des résultats intermédiaires et un résultat final. Là encore la rigueur de l’ingénieur est mise à mal. Cette logique de découpage doit inévitablement conduire à mettre en œuvre une logique de délivrables et de forfaits. Dans la pratique, l’obligation de résultat n’existe pas. L’entreprise peine à préciser le résultat attendu. Le fournisseur cherche à vendre une intervention en régie plutôt qu’un forfait et, lorsque le forfait s’applique, il cherche à mettre en défaut son client, de façon à appliquer des pénalités.
- L’outillage : les entreprises se sont équipées en outil de gestion et de pilotage de projet, voire de gestion de portefeuille de projets. Cette automatisation du pilotage s’est réalisée au détriment du développement d’un management humain. L’instrumentalisation et la manipulation des données devait remplacer dans les faits le rôle d’organisateur, de communiquant et de meneur d’équipes que doit assurer et assumer la direction de projet.
Dans la mesure où le projet est par nature un saut dans l’inconnu et où l’informatique reste une activité en évolution permanente, un projet informatique sera toujours un projet à risque. Les échecs sont possibles mais pour autant cela ne doit en aucun cas être la règle.
Notre conviction, partagée avec certains clients (pas tous), est qu’il faut revenir à des règles de bon sens :
- Imposer une logique de délivrables et lotir le projet de manière forfaitaire. Si le premier délivrable n’est pas de qualité, il ne faut pas hésiter à le refaire, ou arrêter purement et simplement le projet.
- Définir des critères ou indicateurs de mesure, avec simplicité et pragmatisme. Un projet peut tout à fait se piloter avec 4 ou 5 indicateurs, pourvu que tous les acteurs comprennent bien de quoi il s’agit.
Former et valoriser la fonction de Directeur de projet informatique. Il reste la clé de voute de tout l’édifice. L’outillage est un moyen de gagner du temps, pas une nécessité.
Si ces principales règles de bon sens sont appliquées, alors les rivalités seront moindres, sans pour autant disparaître. Leur pouvoir de nuisance en sera limité et maîtrisé.
Pour que le projet informatique reste une aventure humaine passionnante et efficace, il faut impérativement repenser son management. L’échec ne doit plus être la règle mais bien l’exception.
Serge Masanovic & Christophe Coupé
Christophe Coupé, Ingénieur en Télécommunications, docteur en Economie et consultant, s’intéresse à l’inscription sociale des techniques. Il accompagne les dirigeants et managers pour mesurer la performance et la valeur créée par les projets informatiques.
Serge Masanovic, Associé fondateur de VCM Conseil, est un expert en économie des SI. Il intervient pour anticiper les gains et les bénéfices attendus des projets SI, pour identifier les gisements d’économie et enfin pour mesurer et pilote la performance du SI au quotidien.
VCM Conseil
201, rue de la convention
75015 PARIS
www.vcm-conseil.fr
Retrouvez chaque jeudi l'actualité du BPM sur :
www.bpm-channel.com
