Loi 1 : Aucun grand projet informatique n’est jamais mis en place dans les délais, dans les limites du budget, avec la même équipe qu’au départ.
• Le système, finalement mis en place avec retard, ne fait pas non plus ce qu’il était censé faire.
• Le système coûte plus cher, mais c’est une réussite technique (l’opération réussit presque toujours, même si malheureusement le malade meurt souvent),
• Les bénéfices sont inférieurs aux estimations, si on a pensé à faire des estimations.
• Il est fort improbable que votre projet soit le premier à déroger à cette loi.
Loi 2 : L’un des avantages à fixer un objectif vague à un projet est que vous n’aurez pas de difficulté à estimer les dépenses correspondantes, mais inversement l’effort de définition croît géométriquement avec le temps.
• Après l’installation, c’est trop tard.
• Il est conseillé de le faire avant de lancer le projet.
Loi 3 : Les buts, tels que les entend celui qui décide, seront compris différemment par chacune des parties prenantes.
• Si vous vous expliquez avec une clarté telle qu’il soit impossible que qui que ce soit ait mal compris, ce sera le cas de quelqu’un.
• Si vous prévoyez de faire quelque chose qui, vous en êtes sûr, recevra l’approbation de tous, quelqu’un n’aimera pas ça.
Loi 4 : seuls les bénéfices mesurables sont réels. Or, les bénéfices immatériels ne sont pas mesurables, donc ils ne sont pas réels.
Loi 5 : Toute personne qui peut travailler à temps partiel pour un projet n’a sûrement pas assez de travail en ce moment.
• Si son patron ne lui donne pas un travail à temps complet, vous ne devez pas le faire non plus.
• S’il a un problème de répartition d’horaire, le travail de son patron n’en souffrira pas.
Loi 6 : Plus grande est la complexité technique du projet, moins vous avez besoin d’un technicien pour le diriger.
• Trouvez le meilleur manager possible, il trouvera le technicien.
• Le contraire n’est presque jamais vrai.
Loi 7 : Un projet mal planifié prendra trois fois plus de temps à réaliser que prévu. Un projet bien planifié prendra seulement deux fois plus de temps.
Loi 8 : S’il y a un risque que quelque chose marche mal, ça marchera mal.
• S’il est impossible que quelque chose marche mal, ça marchera mal quand même.
Loi 9 : Quand les choses vont bien, quelque chose va aller mal.
• Quand les choses ne peuvent pas réellement devenir pires, elles le deviendront.
• Quand les choses semblent aller mieux, c’est que vous avez oublié quelque chose.
Loi 10 : Les équipes de projet détestent les comptes rendus hebdomadaires d’avancement des travaux parce que ceux-ci mettent trop évidemment en lumière l’absence de leur progrès.
Loi 11 : Les projets progressent rapidement jusqu’à 90% de leur achèvement, puis ils restent achevés à 90% pour toujours.
Loi 12 : Si on laisse le contenu d’un projet changer librement, le taux de changement dépassera le taux d’avancement.
Loi 13 : Si l’utilisateur ne croît pas au système, il créera un système parallèle et ni l’un ni l’autre ne fonctionneront très bien.
Loi 14 : Les bénéfices finaux obtenus sont fonction du sérieux de l’audit a posteriori.
Loi 15 : Aucune loi n’est immuable.
• Le système, finalement mis en place avec retard, ne fait pas non plus ce qu’il était censé faire.
• Le système coûte plus cher, mais c’est une réussite technique (l’opération réussit presque toujours, même si malheureusement le malade meurt souvent),
• Les bénéfices sont inférieurs aux estimations, si on a pensé à faire des estimations.
• Il est fort improbable que votre projet soit le premier à déroger à cette loi.
Loi 2 : L’un des avantages à fixer un objectif vague à un projet est que vous n’aurez pas de difficulté à estimer les dépenses correspondantes, mais inversement l’effort de définition croît géométriquement avec le temps.
• Après l’installation, c’est trop tard.
• Il est conseillé de le faire avant de lancer le projet.
Loi 3 : Les buts, tels que les entend celui qui décide, seront compris différemment par chacune des parties prenantes.
• Si vous vous expliquez avec une clarté telle qu’il soit impossible que qui que ce soit ait mal compris, ce sera le cas de quelqu’un.
• Si vous prévoyez de faire quelque chose qui, vous en êtes sûr, recevra l’approbation de tous, quelqu’un n’aimera pas ça.
Loi 4 : seuls les bénéfices mesurables sont réels. Or, les bénéfices immatériels ne sont pas mesurables, donc ils ne sont pas réels.
Loi 5 : Toute personne qui peut travailler à temps partiel pour un projet n’a sûrement pas assez de travail en ce moment.
• Si son patron ne lui donne pas un travail à temps complet, vous ne devez pas le faire non plus.
• S’il a un problème de répartition d’horaire, le travail de son patron n’en souffrira pas.
Loi 6 : Plus grande est la complexité technique du projet, moins vous avez besoin d’un technicien pour le diriger.
• Trouvez le meilleur manager possible, il trouvera le technicien.
• Le contraire n’est presque jamais vrai.
Loi 7 : Un projet mal planifié prendra trois fois plus de temps à réaliser que prévu. Un projet bien planifié prendra seulement deux fois plus de temps.
Loi 8 : S’il y a un risque que quelque chose marche mal, ça marchera mal.
• S’il est impossible que quelque chose marche mal, ça marchera mal quand même.
Loi 9 : Quand les choses vont bien, quelque chose va aller mal.
• Quand les choses ne peuvent pas réellement devenir pires, elles le deviendront.
• Quand les choses semblent aller mieux, c’est que vous avez oublié quelque chose.
Loi 10 : Les équipes de projet détestent les comptes rendus hebdomadaires d’avancement des travaux parce que ceux-ci mettent trop évidemment en lumière l’absence de leur progrès.
Loi 11 : Les projets progressent rapidement jusqu’à 90% de leur achèvement, puis ils restent achevés à 90% pour toujours.
Loi 12 : Si on laisse le contenu d’un projet changer librement, le taux de changement dépassera le taux d’avancement.
Loi 13 : Si l’utilisateur ne croît pas au système, il créera un système parallèle et ni l’un ni l’autre ne fonctionneront très bien.
Loi 14 : Les bénéfices finaux obtenus sont fonction du sérieux de l’audit a posteriori.
Loi 15 : Aucune loi n’est immuable.
Rédigé par Michel Bruley le Mardi 19 Mars 2024 à 11:59
|
Permalien
|
{0}
Nouveau commentaire :
> A LIRE EN CE MOMENT SUR DECIDEO
-
Gouverner l’intelligence artificielle : cadres réglementaires et normatifs (3ème partie)
-
Tableau démocratise l'analytique en entreprise en s'appuyant sur de nouvelles fonctionnalités à base d'IA générative
-
Salesforce annonce la disponibilité d’Einstein Copilot avec de nouvelles fonctionnalités pour booster les ventes
-
Vincent Cornillet prend la direction du Centre d’Entraînement et de Développement de l’Intelligence Artificielle (CEDIA) de Preligens
-
Teradata adopte Iceberg et Delta Lake pour offrir à ses clients le meilleur écosystème ouvert et connecté pour une IA de confiance
-
Podcast : Quel appareil pour embarquer demain l’intelligence artificielle au plus près de notre corps ?
-
DigDash accompagne France Travail dans le déploiement d’outils de Business Intelligence pour le pilotage opérationnel et stratégique
-
Gouvernance des données : neuf professionnels des services financiers sur dix demandent des réglementations et des normes en matière d'IA
-
L’AIOps, une nouvelle ère pour le stockage des données
-
Tableau et Databricks aident les entreprises à partager, connecter et visualiser leurs données
Profil
Michel Bruley
Liste de liens
Dernières notes
Meilleurs vœux aux parents pour 2024
10/01/2024
RECETTE DE LA DINDE AU WHISKY
27/01/2023
Le 1 to 1 marketing a bientôt trente ans
24/09/2022
Galerie
Archives
Rubriques
Rubriques