L'éditeur Français d'outil de gestion de projet Sciforma publie régulièrement des statistiques sur la gestion de projet.
Les dernières en date montre de net progrès par rapport aux rapports précédents de novembre 2011 et mars 2011. Il n'y aurait plus que 13% des projets en retard dans leur pane, contre 25% un an plus tôt !
On peut néanmoins s'interroger sur la représentativité du panel en question, dont rien n'est dit. Si ce sont les clients de cette société, leur outil doit être très performant pour réduire aussi rapidement les retards ...
Bref, faute de savoir combien de sociétés sont interrogées, comment, quelle est leur répartition, comment on définit un retard, etc., il est bien difficile de tirer une information utile de cette source.
Dommage, peut-être peuvent-ils nous en dire plus ?
4/01/2012
9/21/2010
Une nouvelle étude française sur les projets informatiques
Une nouvelle étude française sur les projets informatiques confirme les taux d’échecs inquiétants annoncés par le Standish Group et les études anglaises sur les projets IT publics (cf ce précédent article). L’étude, menée par un cabinet spécialisé dans le redressement de projets en difficulté, Daylight, porte le nom d’Observatoire des Projets. Sans avoir pour l’instant de chiffres précis, les premières communications de résultats montrent encore une fois que les dépassements de délais et de budgets sont la norme plus que l’exception.
Ces résultats corroborent la pratique quotidienne et la réalité que les chefs de projets informatiques constatent sur le terrain. J’avais l’autre jour encore dans mon bureau un jeune ingénieur prometteur qui a fuit une grande SSII : il s’est retrouvé dans un centre de service de 25 personnes, pour le compte d’un grand compte du CAC40, piloté par un consultant à peine plus âgé que lui, dans les 3 ans d’expérience, dont c’était la première expérience de management. Il se trouvait quotidiennement confronté aux remontrances du client consécutive du mauvais pilotage. Mais peut-on vraiment en vouloir à un chef de projet junior, sans réelle formation pour cette mission, parachuté à la tête d'une grosse équipe et devant gérer les attentes légitimes d'un client face à une telle organisation ? Certes la pression sur les coûts amène les SSII à s’adapter en prenant des risques. Mais confier à un débutant le pilotage d’un gros centre de service, sans support sérieux, est juste l’assurance de l’échec. Ce n’est malheureusement qu’une anecdote parmi les nombreux exemples que j’ai eu l’occasion de constater.
Il faut souhaiter que cette étude ne se borne pas à un constat alarmiste, et vienne au contraire analyser les causes de cette situation. Quelques pistes sont données dans l’article, mais elles décrivent une situation telle qu’une analyse plus poussée semble nécessaire. D’après l’étude, il faudrait reprendre de vrais basiques et la notion même de projet formel serait à promouvoir ! On en serait au niveau 0 du CMMI, ce qui semble difficile à croire à part des situations isolées … Mais sans aller jusque là, et pour rester positif, il est certain que beaucoup d'organisations manquent de maturité sur la gouvernance des projets et disposent d'un bonne marge de progrès.
Peut-être la conclusion viendra-t-elle conforter les enseignements des études anglo-saxones, mettant la qualité de la maîtrise d’ouvrage et l’implication des utilisateurs au cœur des facteurs de succès des projets. Ceci nous aidera peut-être à convaincre plus efficacement les directions informatiques et métiers à appliquer les bonnes pratiques que l’on retrouve notamment dans les méthodes agiles : itérations courtes dans les projets, construction progressive des applications, implication des utilisateurs régulière et participation active et impliquante du sponsor à la charnière entre les itérations, ainsi qu'une politique de tests systématiques et automatisés imbriqués à la réalisation.
Ces résultats corroborent la pratique quotidienne et la réalité que les chefs de projets informatiques constatent sur le terrain. J’avais l’autre jour encore dans mon bureau un jeune ingénieur prometteur qui a fuit une grande SSII : il s’est retrouvé dans un centre de service de 25 personnes, pour le compte d’un grand compte du CAC40, piloté par un consultant à peine plus âgé que lui, dans les 3 ans d’expérience, dont c’était la première expérience de management. Il se trouvait quotidiennement confronté aux remontrances du client consécutive du mauvais pilotage. Mais peut-on vraiment en vouloir à un chef de projet junior, sans réelle formation pour cette mission, parachuté à la tête d'une grosse équipe et devant gérer les attentes légitimes d'un client face à une telle organisation ? Certes la pression sur les coûts amène les SSII à s’adapter en prenant des risques. Mais confier à un débutant le pilotage d’un gros centre de service, sans support sérieux, est juste l’assurance de l’échec. Ce n’est malheureusement qu’une anecdote parmi les nombreux exemples que j’ai eu l’occasion de constater.
Il faut souhaiter que cette étude ne se borne pas à un constat alarmiste, et vienne au contraire analyser les causes de cette situation. Quelques pistes sont données dans l’article, mais elles décrivent une situation telle qu’une analyse plus poussée semble nécessaire. D’après l’étude, il faudrait reprendre de vrais basiques et la notion même de projet formel serait à promouvoir ! On en serait au niveau 0 du CMMI, ce qui semble difficile à croire à part des situations isolées … Mais sans aller jusque là, et pour rester positif, il est certain que beaucoup d'organisations manquent de maturité sur la gouvernance des projets et disposent d'un bonne marge de progrès.
Peut-être la conclusion viendra-t-elle conforter les enseignements des études anglo-saxones, mettant la qualité de la maîtrise d’ouvrage et l’implication des utilisateurs au cœur des facteurs de succès des projets. Ceci nous aidera peut-être à convaincre plus efficacement les directions informatiques et métiers à appliquer les bonnes pratiques que l’on retrouve notamment dans les méthodes agiles : itérations courtes dans les projets, construction progressive des applications, implication des utilisateurs régulière et participation active et impliquante du sponsor à la charnière entre les itérations, ainsi qu'une politique de tests systématiques et automatisés imbriqués à la réalisation.
3/20/2010
Les taux de succès des projets informatiques sont-ils si bas ?
Le taux de réussite des (grands) projets informatiques est un sujet âprement discuté depuis de nombreuses années. En oubliant que les grands travaux de la vie réelle (les ponts, les autoroutes, etc.) sont eux aussi régulièrement et lourdement en retard et en dépassement, et que parfois ils ne sont à la fin tout simplement pas achevés, des générations de responsables se gaussent ou s’effrayent des statistiques publiées à intervalle régulier par le Standish Group dans les « CHAOS Report » (Chaos Report 1994, Chaos: A Recipe for Success 1999, Extreme Chaos 2001, Chaos rising 2005).
Pour ceux qui ne les connaîtraient pas, je vous en donne ici un petit résumé. Etonné par le décalage entre le nombre de licences de progiciel vendues pour le développement de projet et le faible nombre pour leur mise en production, Jim Johnson, le fondateur de cet institut, s’est aperçu en 1994 qu’une grande proportion de projets informatiques étaient abandonnés en cours de route. Il lui est alors venu l’idée de faire une grande enquête auprès des services informatiques de sociétés pour quantifier plus précisément les projets qui étaient :
On peut comprendre pourquoi ces chiffres ont pu faire réagir, ce qui a par ailleurs assuré le succès de cet institut de recherche. Certaines mauvaises langues vont jusqu’à dire que ces chiffres sont volontairement alarmistes pour assurer son modèle économique.
En tout cas, alors que ces chiffres ont été utilisés dans de nombreuses recherches sur le management de projets informatiques, les détracteurs de ces chiffres sont assez nombreux aujourd’hui. Ainsi R. Glass en 2006 (“The Standish Report: Does It Really Describe a Software Crisis?” Comm. ACM, vol. 49, no. 8, 2006, pp. 15–16.) se demandait si l’industrie informatique serait aussi florissante si la majorité des projets informatiques se soldaient par des échecs. Avec un si faible taux de réussite, on peut effectivement se demander comment il se trouve encore des responsables près à risquer leur budget sur des opérations aussi aléatoires …
La représentativité de l’échantillon de projet ayant servis à faire l’estimation est mise en doute. En effet, le Standish Group ne fournit que des chiffres agrégés, et ne communique pas sur les noms des projets et des compagnies qui les ont lancés. En fait, ils récoltent les enquêtes en échange de la confidentialité des répondants, ce qu’on peut tout à fait comprendre au vu des résultats : autant on peut être fier de montrer des projets réussis, autant on n’a pas envie d’étaler ses échecs sur la place publique … Une idée serait de fournir les données désagrégées de l’enquête en rendant anonyme les noms des projets et sociétés. Mais ceci ne lèverait pas les soupçons nourris sur la représentativité et l’impartialité des données. En tout cas, les propos de Jim Johnson en 2006 (Interview par InfoQ) ne font rien pour rassurer ceux qui s’inquiètent de la représentativité de son échantillon. D’autres comme Molokken et Jorgensen s’étonne de l’évolution importante du taux de dépassement annoncé des projets, mettant en cause la stabilité des méthodes d’enquête dans le temps (« How large are software cost overruns : A review of the 1994 CHAOS Report », Information and Software Technology, vol. 48, no. 8, 2006, pp. 297–301.).
Dans un autre registre et plus récemment, Eleveens et Verhoef (“The Rise and Fall of the Chaos Report Figures”, IEEE Software January/February 2010 ) mettent gravement en cause les chiffres du Standish Group en donnant des exemples de projets menés par différentes organisations.Les auteurs montrent que les projets tombent dans la catégorie des échecs partiels ou totaux du Standish principalement quand l’estimation initiale de charge, et donc de coût et de délai était plutôt sous-évaluée. Or l’étude différentielle des projets de plusieurs organisations montrent que l’estimation initiale est parfois proche du résultat finalement obtenu, parfois très éloignée et dispersée. Mais l’indicateur du Standish peut tout à fait donner un taux de succès élevé à une organisation qui chiffre très mal ses projets (l’estimation initiale est loin du résultat) si elle a tendance à sur estimer. Ou bien donner une très mauvaise note à une organisation qui sous-estime, mais seulement légèrement, ses estimations initiales même si elles sont finalement proche du réalisé. Il suffirait donc de surestimer copieusement pour bien s’en sortir. En d’autre terme, les chiffres annoncés seraient justes, mais leur définition même induit un biais qui ne reflète pas la pertinence des estimations de charge. Néanmoins, le sous-entendu de l'article est qu'un projet est réussi si l'estimation de charge et de coût converge pendant le projet, ce qui reflète une perspective bien particulière.
Pourtant, si j’en crois mon expérience, j’ai une tendance non seulement à croire les chiffres du Standish Group, mais aussi à trouver leur définition du succès ou de l’échec pertinente. Peut-être ai-je une opinion biaisée par le fait que j’ai souvent été appelé en urgence pour rattraper des situations difficiles sur les projets, mais je ne suis pas surpris que l’on trouve une faible minorité de projets qui se passent parfaitement bien. Surtout, je trouve la définition du succès appropriée car, si elle ne reflète pas la précision de l’estimation initiale, elle correspond tout-à-fait à l’opinion que se fera a posteriori un donneur d’ordre en faisant le bilan du projet : ai-je bien ce que j’ai demandé pour les moyens qu’on m’a réclamé ? Il y a d’ailleurs d’autres études autour des projets informatiques réalisés pour l’administration britannique (Sauer, C. and Cuthbertson, C., "The State of IT Project Management in the U.K.", Computer Weekly, Oxford, 2003. ; POST Report Government IT projects 2003) ou par KPMG (Global IT Project Management Survey 2005) qui confirment le faible taux de réussite des grands projets informatiques.
D’ailleurs, les analyses du Standish Group ne s’arrêtent pas au constat de l’échec, mais en cherche aussi les causes. Et l’analyse colle vraiment avec les difficultés que l’on rencontre pendant les projets : utilisateurs peu impliqués et versatiles modifiant sans cesse des besoins mal définis, ou sponsor absent mais exigeant des délais irréalistes. Ainsi, les facteurs clés de succès remontés sont, dans un ordre décroissant :
Ainsi, si la construction de ces chiffres est opaque, ils sont tout à fait réalistes et utiles, et peuvent vraiment servir à comprendre que la réussite d’un projet informatique n’est pas du seul ressort du fabricant, mais aussi et surtout du client.
Pour ceux qui ne les connaîtraient pas, je vous en donne ici un petit résumé. Etonné par le décalage entre le nombre de licences de progiciel vendues pour le développement de projet et le faible nombre pour leur mise en production, Jim Johnson, le fondateur de cet institut, s’est aperçu en 1994 qu’une grande proportion de projets informatiques étaient abandonnés en cours de route. Il lui est alors venu l’idée de faire une grande enquête auprès des services informatiques de sociétés pour quantifier plus précisément les projets qui étaient :
- Réussis (« succeeded »), c’est-à-dire ayant tenus toutes leurs promesses en matière de fonctionnalités alors que les délais et le budget était tenu
- En difficulté (« challenged »), en montrant une combinaison partielle ou totale de dépassement budgétaire, calendaire ou une réduction de leur périmètre attendu
- Abandonnés (« failed ») en cours de route par leurs commanditaires
On peut comprendre pourquoi ces chiffres ont pu faire réagir, ce qui a par ailleurs assuré le succès de cet institut de recherche. Certaines mauvaises langues vont jusqu’à dire que ces chiffres sont volontairement alarmistes pour assurer son modèle économique.
En tout cas, alors que ces chiffres ont été utilisés dans de nombreuses recherches sur le management de projets informatiques, les détracteurs de ces chiffres sont assez nombreux aujourd’hui. Ainsi R. Glass en 2006 (“The Standish Report: Does It Really Describe a Software Crisis?” Comm. ACM, vol. 49, no. 8, 2006, pp. 15–16.) se demandait si l’industrie informatique serait aussi florissante si la majorité des projets informatiques se soldaient par des échecs. Avec un si faible taux de réussite, on peut effectivement se demander comment il se trouve encore des responsables près à risquer leur budget sur des opérations aussi aléatoires …
La représentativité de l’échantillon de projet ayant servis à faire l’estimation est mise en doute. En effet, le Standish Group ne fournit que des chiffres agrégés, et ne communique pas sur les noms des projets et des compagnies qui les ont lancés. En fait, ils récoltent les enquêtes en échange de la confidentialité des répondants, ce qu’on peut tout à fait comprendre au vu des résultats : autant on peut être fier de montrer des projets réussis, autant on n’a pas envie d’étaler ses échecs sur la place publique … Une idée serait de fournir les données désagrégées de l’enquête en rendant anonyme les noms des projets et sociétés. Mais ceci ne lèverait pas les soupçons nourris sur la représentativité et l’impartialité des données. En tout cas, les propos de Jim Johnson en 2006 (Interview par InfoQ) ne font rien pour rassurer ceux qui s’inquiètent de la représentativité de son échantillon. D’autres comme Molokken et Jorgensen s’étonne de l’évolution importante du taux de dépassement annoncé des projets, mettant en cause la stabilité des méthodes d’enquête dans le temps (« How large are software cost overruns : A review of the 1994 CHAOS Report », Information and Software Technology, vol. 48, no. 8, 2006, pp. 297–301.).
Dans un autre registre et plus récemment, Eleveens et Verhoef (“The Rise and Fall of the Chaos Report Figures”, IEEE Software January/February 2010 ) mettent gravement en cause les chiffres du Standish Group en donnant des exemples de projets menés par différentes organisations.Les auteurs montrent que les projets tombent dans la catégorie des échecs partiels ou totaux du Standish principalement quand l’estimation initiale de charge, et donc de coût et de délai était plutôt sous-évaluée. Or l’étude différentielle des projets de plusieurs organisations montrent que l’estimation initiale est parfois proche du résultat finalement obtenu, parfois très éloignée et dispersée. Mais l’indicateur du Standish peut tout à fait donner un taux de succès élevé à une organisation qui chiffre très mal ses projets (l’estimation initiale est loin du résultat) si elle a tendance à sur estimer. Ou bien donner une très mauvaise note à une organisation qui sous-estime, mais seulement légèrement, ses estimations initiales même si elles sont finalement proche du réalisé. Il suffirait donc de surestimer copieusement pour bien s’en sortir. En d’autre terme, les chiffres annoncés seraient justes, mais leur définition même induit un biais qui ne reflète pas la pertinence des estimations de charge. Néanmoins, le sous-entendu de l'article est qu'un projet est réussi si l'estimation de charge et de coût converge pendant le projet, ce qui reflète une perspective bien particulière.
Pourtant, si j’en crois mon expérience, j’ai une tendance non seulement à croire les chiffres du Standish Group, mais aussi à trouver leur définition du succès ou de l’échec pertinente. Peut-être ai-je une opinion biaisée par le fait que j’ai souvent été appelé en urgence pour rattraper des situations difficiles sur les projets, mais je ne suis pas surpris que l’on trouve une faible minorité de projets qui se passent parfaitement bien. Surtout, je trouve la définition du succès appropriée car, si elle ne reflète pas la précision de l’estimation initiale, elle correspond tout-à-fait à l’opinion que se fera a posteriori un donneur d’ordre en faisant le bilan du projet : ai-je bien ce que j’ai demandé pour les moyens qu’on m’a réclamé ? Il y a d’ailleurs d’autres études autour des projets informatiques réalisés pour l’administration britannique (Sauer, C. and Cuthbertson, C., "The State of IT Project Management in the U.K.", Computer Weekly, Oxford, 2003. ; POST Report Government IT projects 2003) ou par KPMG (Global IT Project Management Survey 2005) qui confirment le faible taux de réussite des grands projets informatiques.
D’ailleurs, les analyses du Standish Group ne s’arrêtent pas au constat de l’échec, mais en cherche aussi les causes. Et l’analyse colle vraiment avec les difficultés que l’on rencontre pendant les projets : utilisateurs peu impliqués et versatiles modifiant sans cesse des besoins mal définis, ou sponsor absent mais exigeant des délais irréalistes. Ainsi, les facteurs clés de succès remontés sont, dans un ordre décroissant :
- l’implication des utilisateurs
- le support du management et l’appropriation du projet par un sponsor fort
- une expression claire du besoin
- une bonne planification
- des attentes réalistes
- des jalons de projet rapprochés
- une équipe compétente
- une vision et des objectifs clairs
- une équipe projet travaillant avec acharnement (en dernier !)
Ainsi, si la construction de ces chiffres est opaque, ils sont tout à fait réalistes et utiles, et peuvent vraiment servir à comprendre que la réussite d’un projet informatique n’est pas du seul ressort du fabricant, mais aussi et surtout du client.
2/13/2010
Le second principe s’applique aux données
Définition de l'entropie d'information
En thermodynamique, l’entropie est une mesure du désordre présent au sein d’un système. En théorie de l’information, l’entropie mesure la quantité de données qu’il faut pour décrire une situation. En d’autre terme, plus une situation est compliquée, plus sa description est longue et son entropie élevée. A l’inverse, plus une situation est simple et ordonnée, plus sa description sera succincte et plus l’entropie sera faible.Imaginons que vous deviez décrire une forêt contenant dix mille arbres. Si c’est une forêt sauvage, vous devrez décrire la position, l’essence, la taille et le diamètre de chaque arbre, soit pour faire simple 5x10000 = 50000 informations élémentaires (décrire un arbre est bien sûr plus complexe … c’est une première approximation). A l’inverse, si c’est une plantation d’arbres, tous de la même essence, plantés en même temps, et sur un plan de carré planté à intervalle régulier, il suffit de connaître le diamètre, la taille, l’essence d’un seul arbre et la position de deux arbres situés à deux coins opposés du carré pour décrire totalement la situation, soit 7 informations élémentaires. L’entropie représente donc en quelque sorte la complexité d’une situation.
Cette dernière définition de l’entropie peut tout à fait s’appliquer à un système d’information. En particulier on peut l’appliquer aux données contenues dans ce système.
Exemple de la saisie de données
Je vous suggère de mener une petite expérience pour appréhender la notion d’entropie des données. Demandez à une population de nombreuses personnes de remplir un formulaire (informatique ou non d’ailleurs …). Par exemple, demander leur de remplir leur nom dans une case. Vous constaterez invariablement que les gens ne vont pas tous remplir leur nom de la même manière. Certains vont écrire leur nom de famille, d’autre leur nom et leur prénom, d’autres encore leur prénom puis leur nom. Certains vont préciser Monsieur, Madame, ou Mademoiselle devant, en variant les abréviations. La plupart vont écrire leur nom de famille avec une première lettre en majuscule, d’autres vont l’écrire entièrement en majuscule. Pareil pour le prénom. Si vous augmentez la population, vous en trouverez certains qui plus curieusement laissent tout en minuscule. Et je ne parle même pas des coquilles.C’est un peu facile, puisque l’on n’a pas été précis sur la manière de remplir le formulaire. Mais si vous recommencez l’expérience avec des instructions précises, le résultat sera certes plus homogène, mais vous aurez quand même de nombreuses variantes. Certaines personnes n’auront pas ou mal compris vos instructions, d’autres se tromperont, d’autres enfin ne les respecteront tout simplement pas par défi ou incurie. Pour ma part, après avoir tenté cette expérience dans de nombreuses circonstances, je ne suis jamais parvenu à obtenir un résultat parfait, quel que soit le degré de précision des instructions fournies, même si le résultat s’améliore globalement avec des instructions précises. J’ai même constaté que si l’on cherche à être trop précis, ceci devient contre productif, les gens ne lisant même pas les instructions jusqu’au bout, découragés par leur caractère trop complexe et pointilleux.
Exemple des doublons
Un autre exemple classique d’entropie est la création de doublons dans une base de données. Par doublon, j’entends deux données représentant le même objet physique. Ceci se produit par exemple pour les personnes dans les réseaux sociaux. J’ai environ une centaine de contacts sur des réseaux sociaux professionnels tels LinkedIn ou autre. Sur ces 100 contacts, j’ai eu au moins 3 personnes qui se sont en fait créé deux profils par erreurs, et qui ont ensuite toutes les peines du monde à gérer leurs comptes. Elles ne l’ont bien sûr pas fait sciemment, mais à des moments différents. Sur quelques millions d’inscrits, cela fait quelques dizaines de milliers de doublons.Il n’est pas toujours possible de détruire ces données ou de les fusionner car certaines données ne sont pas effacées physiquement et les procédures de fusion inexistantes. Elles restent donc au mieux masquées et désactivées.
Exemple du recyclage d’identifiants
Dans une base de données des articles vendus chez un distributeur, sur un ancien système informatique, la limite logique du nombre d’article était à 100000. Ceci paraissait élevé au début de l’exploitation, mais 20 ou 30 ans plus tard, de tels systèmes sont en pénurie chronique d’identifiants. Ceci amène à gérer les codes disponibles comme une ressource rare, et à les recycler. Souvent, les systèmes n’ont pas été prévus pour cela et des résidus des anciennes données se télescopent avec des nouvelles sur les codes recyclés. Tel le chiffre d’affaire d’un yaourt à la fraise X du début de l’année cumulé au chiffre d’affaire d’un dentifrice Z à la fin de l’année … drôle de mélange !Ce n’est pas pour rien que l’on utilise aujourd’hui des numéros de séquences incrémentaux et non recyclable pour gérer ce genre de problème.
Exemple du détournement de champs
Un autre cas de désordre apparait quand les utilisateurs détournent consciemment ou non le sens des champs d’une application. Par exemple, dans une base prévoyant « titre » (Mr, Mme, Mlle, Mr ou Mme, etc.), « nom de famille » et « prénom », on a retrouvé pour la plupart des entrées la concaténation des 3 champs dans le nom de famille. « Mademoiselle Catherine Martin » se retrouvait dans le champ « nom de famille » et les champs « titre » et « prénom » restaient vierges. Impossible ensuite d’accéder simplement aux noms de famille dans la base …Caractère normal de l'augmentation
Bien sûr ces exemples sont loin de faire le tour de la question, et il serait vain de faire un inventaire des situations chaotiques que nous rencontrons dans les systèmes d’informations. Je les ai tous rencontrés à titre personnel, et à plusieurs occasions. Et j’avais en général beaucoup de difficultés à faire comprendre aux intéressés en quoi leur comportement était problématique.Le second principe de la thermodynamique précise qu’un système voit spontanément son entropie augmenter. Les exemples précédents vous auront convaincu je pense qu’il en va de même pour l’entropie des données dans les systèmes d’information.
Les exemples donnés montrent comment elle apparait spontanément et croît avec le nombre d’utilisateurs et le temps :
- un utilisateur n’applique pas toujours la même règle pour saisir les données à des moments différents
- plusieurs utilisateurs ont a priori des comportements différents, même si les instructions sont précises et claires
- les utilisateurs ont une probabilité non nulle de se tromper à chaque saisie et ne vérifie pas en général ce qu’ils écrivent
2/06/2010
Pourquoi les développements sont plus longs que prévu ?
Il est bien connu que les projets informatiques ne respectent pratiquement jamais leurs délais. La loi de Hofstadter indique non sans humour :
Même si les chefs de projets rejettent en général la faute de ces dérives sur les dépendances externes, ou sur les modifications demandées en court de route par le client, il faut aussi admettre qu’une des causes principales est la mauvaise estimation des délais nécessaires aux tâches de programmation. Dans un récent article, j’ai lu une explication que j’ai trouvée un peu rapide, et qui m’a amené à réfléchir aux nombreux cas que j’ai dû traiter avec des équipes projets en difficulté.
En effet, il est vain de chercher une explication générale, car de très nombreux phénomènes sont à l’œuvre pour induire ces retards :
Il n’est donc pas surprenant que les projets ne soient pas à l’heure. Ce qui est surprenant, c’est quand le contraire arrive parfois … Peut-être que certains chefs de projet ont trouvé des solutions à tous ces problèmes ?
« Une tâche prends toujours plus de temps que prévu, même si vous prenez en compte cette loi ».Plusieurs des lois de Golub reviennent aussi sur ce phénomène:
« Aucun grand projet informatique n'est jamais mis en place dans les délais, dans les limites du budget, avec le même personnel qu'au départ, et le projet ne fait pas ce qu'il est censé faire non plus. Il est fort improbable que le nôtre soit le premier. »
« Un projet mal planifié prendra trois fois plus de temps que prévu. Un projet bien planifié prendra seulement deux fois plus de temps. »Une fois la satisfaction de l’ironie, du cynisme et de l’autodérision passée, la vraie question à se poser est : pourquoi ?
Même si les chefs de projets rejettent en général la faute de ces dérives sur les dépendances externes, ou sur les modifications demandées en court de route par le client, il faut aussi admettre qu’une des causes principales est la mauvaise estimation des délais nécessaires aux tâches de programmation. Dans un récent article, j’ai lu une explication que j’ai trouvée un peu rapide, et qui m’a amené à réfléchir aux nombreux cas que j’ai dû traiter avec des équipes projets en difficulté.
En effet, il est vain de chercher une explication générale, car de très nombreux phénomènes sont à l’œuvre pour induire ces retards :
- La perspective : de même qu’une montagne lointaine parait petite, une tâche éloignée parait plus simple, car on n’en voit pas tous les détails. Quand on estime une tâche, on fait une simulation mentale de ce qu’il y aura à faire. On ne rentre pas dans les tous les détails car sinon, cela revient à pratiquement à la réaliser complètement d’avance. Donc par conséquent, si on s’en tient aux charges imaginées, on en néglige nécessairement une partie …
- La sous-estimation par fierté: les développeurs technophiles sont en général très optimistes sur leur capacité de réalisation des développements informatiques. Ils sont très fiers de leurs connaissances et de leur capacités, se croient en général plus compétents que leurs collègues et donc sous-estiment chroniquement le temps qu’il leur faut pour réaliser une tâche. Si la tâche est estimée par eux, et réalisée par leurs collègues, la dérive dans le temps de la réalisation les conforte dans leur croyance de supériorité. Ceci relativise d’ailleurs les techniques d’estimation collective comme le poker planning de scrum si les groupes impliqués sont trop marqués par cette tendance.
- « Cà va marcher du premier coup ». Les tâches de développement ont cette particularité qu’elles ne sont finies que quand le programme fonctionne. Il faut donc aménager du temps dans l’estimation pour vérifier que le résultat produit par le développement est conforme à ce qui est attendu (les tests unitaires). Or il est très difficile dans certains cas de prévoir combien de fois il faudra revenir sur le programme et refaire le test pour qu’il finisse par marcher, ou combien d’effort il faudra pour corriger certains problèmes. Face à cette difficulté, la tendance est d’imaginer que le développement marchera du premier coup, ce qui est bien sûr faux en moyenne.
- Le peaufinage. Comme ils prennent du plaisir à programmer et aiment leur métier, certains développeurs ne voient pas le temps passer, s’intéressent à des détails peu importants, refont plusieurs fois une partie de code pour parvenir à un résultat parfait, bref dépassent allègrement leur estimation initiale, mais bien sûr pour d’excellentes raisons …
- La loi de Parkinson, qui stipule que
« le travail s’étale de façon à occuper le temps disponible pour son achèvement. »
En effet, la tendance naturelle face à une situation confortable est de prendre son temps, de ralentir en quelque sorte suffisamment pour vérifier la prédiction. Toute tâche remplit donc au minimum le temps prévu initialement. Ceci annihile toute chance de rattrapage des dérives calendaires d’un projet par des tâches surestimées et explique pourquoi les provisions de délais ou les marges sont systématiquement consommées. - La procrastination, c'est-à-dire la propension à remettre systématiquement au lendemain les tâches difficiles. Ceci se produit quand les tâches élémentaires sont trop longues, ce qui amène le développeur à pouvoir choisir par quoi il va commencer. La tendance naturelle sera alors de repousser les tâches apparemment plus complexes à la fin, pour commencer par les plus simples. Ceci n’est pas forcément conscient, et s’apparente à un déni : la peur d’affronter une tâche difficile crée une angoisse, et c’est bien le report le plus tard possible qui permet de l’oublier un temps pour la contrôler. L’estimation du reste à faire s’en trouve faussée, car au début le développeur accordera faussement à la tâche repoussée la même difficulté que les autres, et les tâches simples avanceront à un bon rythme. Ce n’est qu’en approchant de l’échéance qu’ils reprendront conscience du problème et que l’angoisse renaîtra. Le reste à faire remontera donc, mais trop tard pour pouvoir réagir.
- Une variante de ce phénomène est la dissimulation: les développeurs peuvent rester bloqués sur un problème sans le signaler. Soit par timidité, soit par peur de critiques. Ils préfèrent parfois attendre le moment où il est évident qu’ils n’auront pas fini à temps pour le signaler. Ce problème est typique des situations de management où les gens sont jugés uniquement sur le résultat et non sur la méthode employée pour y parvenir, ce qui arrive quand le chef ne comprend pas le travail concret de ses subordonnés.
« Les projets progressent rapidement jusqu'à 90%, puis ils restent achevés à 90% pour toujours. »
Il n’est donc pas surprenant que les projets ne soient pas à l’heure. Ce qui est surprenant, c’est quand le contraire arrive parfois … Peut-être que certains chefs de projet ont trouvé des solutions à tous ces problèmes ?
1/30/2010
DSI Centre de coûts
On m'a récemment dit que 70% du budget informatique des grandes entreprises est consacré à la maintenance de leur existant, ce qui laisse 30% pour innover et investir.
On pourrait se dire que ce n'est pas si mal que çà si ces budgets n'étaient pas si colossaux ... Et si l'expérience ne montrait que cette évaluation est plutôt optimiste pour certains SI rebelles à toute tentative de modernisation, englué dans les strates successives de migrations avortées.
Comment s'étonner ensuite que les directions générales perçoivent le SI comme un centre de coût ?
Il fut un temps où l'informatique, en simplifiant et automatisant les processus, apportait valeur et avantage compétitif aux entreprises qui l'utilisait. Aujourd'hui, elle est vécue comme un mal nécessaire et un gisement de réduction de coût. Pourtant, j'ai la faiblesse de penser que l'informatique peut encore apporter un avantage compétitif par l'innovation.
J'en veux pour preuve mon expérience récente sur une application décisionnelle de contrôle de gestion chez un constructeur aéronautique. L'objet de l'application était de rassembler les informations de fabrication et d'achat de pièces et sous-ensembles de moteurs pour évaluer le coût de fabrication des moteurs assemblés produits par cette société. Il a fallu pour y parvenir modéliser l'ensemble du savoir-faire des contrôleurs de gestion sous la forme de très nombreuses règles de gestion et traitements de cas particuliers. Ceci a bien sûr été beaucoup plus long et compliqué que prévu, ce qui a engendré surcoûts et retards sur le projet, déclenchant la colère du DAF de la société. Mais aujourd'hui l'application a permis dès sa mise en service partielle de ne pas remplacer le départ de 3 personnes, et d'accéder au coût optimal des moteurs, si les pièces étaient systématiquement achetées au moindre coût. Le retour sur investissement, même si le gisement d'économie de production révélée n'est que partiellement exploité, est inférieur à six mois, car les montants manipulés en production industrielle n'ont pas de commune mesure avec les coûts informatiques.
Cette valeur ajoutée existe vraiment, et rares sont les entreprises totalement optimisées. C'est bien le rôle des DSI de le faire comprendre à leur direction générale, et de vendre aux directions métiers la valeur ajoutée des applications qu’elles produisent.
On pourrait se dire que ce n'est pas si mal que çà si ces budgets n'étaient pas si colossaux ... Et si l'expérience ne montrait que cette évaluation est plutôt optimiste pour certains SI rebelles à toute tentative de modernisation, englué dans les strates successives de migrations avortées.
Comment s'étonner ensuite que les directions générales perçoivent le SI comme un centre de coût ?
Il fut un temps où l'informatique, en simplifiant et automatisant les processus, apportait valeur et avantage compétitif aux entreprises qui l'utilisait. Aujourd'hui, elle est vécue comme un mal nécessaire et un gisement de réduction de coût. Pourtant, j'ai la faiblesse de penser que l'informatique peut encore apporter un avantage compétitif par l'innovation.
J'en veux pour preuve mon expérience récente sur une application décisionnelle de contrôle de gestion chez un constructeur aéronautique. L'objet de l'application était de rassembler les informations de fabrication et d'achat de pièces et sous-ensembles de moteurs pour évaluer le coût de fabrication des moteurs assemblés produits par cette société. Il a fallu pour y parvenir modéliser l'ensemble du savoir-faire des contrôleurs de gestion sous la forme de très nombreuses règles de gestion et traitements de cas particuliers. Ceci a bien sûr été beaucoup plus long et compliqué que prévu, ce qui a engendré surcoûts et retards sur le projet, déclenchant la colère du DAF de la société. Mais aujourd'hui l'application a permis dès sa mise en service partielle de ne pas remplacer le départ de 3 personnes, et d'accéder au coût optimal des moteurs, si les pièces étaient systématiquement achetées au moindre coût. Le retour sur investissement, même si le gisement d'économie de production révélée n'est que partiellement exploité, est inférieur à six mois, car les montants manipulés en production industrielle n'ont pas de commune mesure avec les coûts informatiques.
Cette valeur ajoutée existe vraiment, et rares sont les entreprises totalement optimisées. C'est bien le rôle des DSI de le faire comprendre à leur direction générale, et de vendre aux directions métiers la valeur ajoutée des applications qu’elles produisent.
5/24/2006
Le management est un métier
Manager est un travail à part entière, qui consiste à faire faire aux autres. Or la plupart du temps, on en vient à manager par progression dans une activité professionnelle. Un bon vendeur évoluera naturellement vers de l'encadrement d'équipe commerciale. Un bon informaticien se verra proposer comme progression logique de carrière d'encadrer des équipes. Comme si, finalement, l'expérience opérationnelle d'un métier était la compétence la plus importante pour encadrer, et qu'elle arrivait mécaniquement avec les années pour la plupart des gens.
Ceci semble malheureusement totalement faux. Non seulement il est possible d'encadrer une équipe sans connaître au départ son métier, mais à l'inverse les meilleurs experts d'un domaine ne font pas systématiquement de bons managers.
Car pour faire faire aux autres, il faut beaucoup plus exercer un savoir être qu'un savoir faire. En effet, l'objet, la "matière première" du management, c'est la personne encadrée et sa relation personnelle avec son encadrant. Ce n'est pas celle du travail qui doit être accompli par l'équipe : le client pour le commercial, le système d'information pour l'informaticien, etc. Et c'est bien en travaillant son image, son crédit et son autorité auprès de son équipe qu'on développe cette relation. La connaissance technique préalable du métier sous-jacent n'est qu'un moyen utile d'y parvenir, mais n'est ni nécessaire, ni suffisant.
Comme il s'agit d'un métier en soi, le management exige à la fois des connaissances techniques (comment motiver, communiquer, construire et exercer une autorité), et des compétences humaines (capacité d'écoute, intelligence émotionnelle, contrôle de soi, etc.). Ces connaissances et ces compétences n'ont a priori rien à voir avec d'autres métiers qui auront pu amener une personne en position de manager.
Malheureusement, bien souvent les personnes sont promues manager sans aucune aide pour cette prise de conscience indispensable qu'ils vont à présent exercer un autre métier, en plus ou plutôt à la place de leur ancien métier technique. Ils continuent donc naturellement à exercer leur ancien métier. Ils briment fréquemment leur équipe car, après tout, s'ils sont là, c'est bien parce qu'ils sont probablement les meilleurs dans leur domaine. Ils s'attachent moins au résultat qu'aux moyens d'y parvenir. D'autres auront assez d'intuition pour adopter la bonne attitude, assez de charisme pour s'imposer naturellement et de finesse pour donner envie à leur équipe de les suivre. Mais ce ne sera pas sans faux pas. On n'apprend pas à faire du ski sans chute.
Ceci semble malheureusement totalement faux. Non seulement il est possible d'encadrer une équipe sans connaître au départ son métier, mais à l'inverse les meilleurs experts d'un domaine ne font pas systématiquement de bons managers.
Car pour faire faire aux autres, il faut beaucoup plus exercer un savoir être qu'un savoir faire. En effet, l'objet, la "matière première" du management, c'est la personne encadrée et sa relation personnelle avec son encadrant. Ce n'est pas celle du travail qui doit être accompli par l'équipe : le client pour le commercial, le système d'information pour l'informaticien, etc. Et c'est bien en travaillant son image, son crédit et son autorité auprès de son équipe qu'on développe cette relation. La connaissance technique préalable du métier sous-jacent n'est qu'un moyen utile d'y parvenir, mais n'est ni nécessaire, ni suffisant.
Comme il s'agit d'un métier en soi, le management exige à la fois des connaissances techniques (comment motiver, communiquer, construire et exercer une autorité), et des compétences humaines (capacité d'écoute, intelligence émotionnelle, contrôle de soi, etc.). Ces connaissances et ces compétences n'ont a priori rien à voir avec d'autres métiers qui auront pu amener une personne en position de manager.
Malheureusement, bien souvent les personnes sont promues manager sans aucune aide pour cette prise de conscience indispensable qu'ils vont à présent exercer un autre métier, en plus ou plutôt à la place de leur ancien métier technique. Ils continuent donc naturellement à exercer leur ancien métier. Ils briment fréquemment leur équipe car, après tout, s'ils sont là, c'est bien parce qu'ils sont probablement les meilleurs dans leur domaine. Ils s'attachent moins au résultat qu'aux moyens d'y parvenir. D'autres auront assez d'intuition pour adopter la bonne attitude, assez de charisme pour s'imposer naturellement et de finesse pour donner envie à leur équipe de les suivre. Mais ce ne sera pas sans faux pas. On n'apprend pas à faire du ski sans chute.
Inscription à :
Articles (Atom)