pourquoi des projets sont-ils annulés pour de mauvaises raisons ?

Why Projects Are Cancelled For The Wrong Reasons

http://www.fatcat.com.au/news/home/Ask+an+Advisor/418_0.html

Un nombre élevé et disproportionné de projets sont annulés par le management à 18 mois.

Comme avec tout projet, il y a un flux et un reflux naturel. Un rythme naturel. Ce que je trouve intéressant est que le rythme semble s’installer dans ce que j’appelle la Règle des 18 Mois. La règle déclare que :

Un nombre disproportionné de projets est annulé par le management à 18 mois.

N’oublions pas que beaucoup de secteurs ont un rythme naturel. Un exemple est technologique. Le rythme technologique le plus célèbre est la Loi de Moore qui prévoit que la croissance dans le nombre de transistors par puce doublera tous les vingt-quatre mois. D’autres lois technologiques qui ont un rythme naturel incluent la Loi de Kydler pour le stockage sur disque (~12 mois) et la Loi d’Haitz pour la production de LED’s (~18 mois).

Pourquoi y-a-t-il une Règle de 18 Mois pour les projets ? Y aurait-il une certaine loi naturelle dans le travail ? La réponse est simple : oui. La nature humaine.

En regardant derrière moi les projets que j’ai managés dans ma carrière, le cycle de 18 mois d’annulation des projets réapparaît à travers les industries, le contexte, la technologie, la taille d’organisation et les nationalités. La règle semble universelle. Pourquoi ? Dix-huit est le nombre maximal de mois pendant lesquels le management peut souffrir. La douleur est la répétition de re-justification d’un projet dont on attend toujours les bénéfices.

Pourquoi est-ce 18 et pas 12 ou 24 ?

Pensez à un projet donné. La plupart débutent en milieu d’année avec un financement et des ressources alloués à grand-peine par le management en se basant sur le mérite et l’impact potentiels. Quand le cycle budgétaire suivant arrive, le projet est bien en route et le financement est presque assuré étant donné que le projet a démarré depuis moins d’une année et que personne ne s’attend à ce qu’il ait déjà un impact. Le résultat est que les ressources sont maintenues en place et le projet continue à progresser.

Le deuxième cycle est une question différente. Quand le cycle budgétaire revient, il y a des questions levées sur le projet : est-ce que ce projet est toujours important ? Y aurait-il des projets plus importants que nous devrions financer au lieu de celui-là ? Atteignons-nous les progrès escomptés ?

Pourquoi ces questions ? Parce que chacun dans la chaîne de management doit re-justifier le projet pour encore une autre année de financement. C’est ce deuxième tour qui cause toute l’angoisse. Le résultat est que le management arbitrera s’il faut se battre pour une autre année de financement ou simplement laisser le projet mourir et éviter cette douleur. Comme nous pouvons tous l’apprécier, éviter la douleur est une réaction humaine naturelle.

douleurSi le management pouvait voir la valeur (quelque chose qui justifie la douleur), approuver que le projet continue ne serait pas un problème. Là où la plupart des équipes de projet s’attirent des ennuis est qu’elles ne saisissent pas cette réaction d’évitement de douleur du management. Dans leurs esprits, le management devrait seulement l’obtenir et avoir confiance en équipe. Le résultat est qu’un grand pourcentage de projets sont tués à 18 mois parce que l’on n’a pas démontré leur valeur.

Attendez ! Dites-vous. Nous avions un accord que ce serait un projet de plusieurs années et que les bénéfices viendraient à la fin. Est-ce que ceci ne prouve pas que la Règle des 18 Mois ne s’applique pas ? Non. Si vous croyez vraiment que vous pouvez éviter le problème en obtenant un accord au départ, alors vous ne comprenez pas la nature humaine. Au cas où votre projet passerait le jalon des 18 mois, la douleur grandit avec chaque cycle ultérieur. Ce qui signifie que vous devez montrer une valeur et un impact toujours croissants pour continuer. La douleur ne part pas. En réalité, elle augmente .

Ce n’est pas la faute de la direction. C’est la faute de l’équipe de projet qui échouerait à comprendre le désir du management d’éviter la douleur.

Comment une équipe évite-t-elle la règle ? Par les quelques étapes simples suivantes :

Remettre les horloges à zéro1) Comprendre le cycle de votre organisation (ou votre client) pour vous assurer que vous comprenez le timing. Quand les budgets et/ou les stratégies sont-ils bouclés chaque année ?

2) Définir votre portée de projet et de produits pour être certains que ce que vous livrez a un impact/une valeur avant que la règle ne soit appliquée.

3) Pour les projets qui s’étendent au-delà de 18 mois, découpez-les et faites de chaque partie un projet distinct. Pourquoi ? Esquiver le problème d’évitement d’une douleur qui s’intensifie avec le temps. Chaque projet remet l’horloge à zéro.

Dans mon expérience, j’ai vu la règle appliquée à des projets qui devraient avoir été tués au départ et à d’autres qui n’auraient jamais dus être tués. Cette apparente prise de décisions aléatoire du management peut être perturbante et démoralisante dans une organisation.

Si vous êtes dans le management, regardez-vous dans le miroir et comprenez que la nature humaine joue un rôle dans votre prise de décision de tuer des projets. Aidez vos équipes à le comprendre.

Si vous menez un projet, utilisez les stratégies de management de projet simples afin d’éviter ce que dans le passé vous aviez attribué à des caprices du management.

En comprenant la Règle des 18 Mois, vous pouvez assurer que vos projets auront l’impact que vous désirez.

Bonne chance !

comment convaincre votre directeur financier d’utiliser SCRUM

How to Convince Your CFO to Use Scrum

parJan Van den Nieuwenhof

Convaincre votre directeur financier (Chief Financial Officer: CFO) et autres cadres sup de votre société d’utiliser Scrum est en réalité très simple, dans la théorie. Essayez cette stratégie la prochaine fois vous devez aider des exécutifs à comprendre pourquoi Scrum est un processus important et utile pour le développement logiciel.

Selon mon expérience, les experts financiers et les directions sont très attentifs à savoir ce qui arrivera si de certaines situations se produisent et veulent souvent simuler des scénarios dans leur stratégie de management des risques.

stop arrêt de projet "no go"La meilleure approche dans cette situation est d’exposer la valeur business que vous livrerez si le projet devait s’arrêter en cours d’exécution.

Il y a plusieurs raisons pour lesquelles des projets de développement de logiciel sont arrêtés avant leur date de fin :

  • sévères compressions budgétaires
  • changement de priorités de projet,
  • la société a été rachetée
  • le budget approuvé n’est pas suffisant pour couvrir le périmètre complet du projet

En justifiant au management pourquoi utiliser utiliser Scrum il y a quelques années, nous avons posé cette question à la direction : Et si le projet devait être arrêté à environ 60 % de son effort ou calendrier ?

Pour cette démonstration, nous avons comparé deux projets. Le projet W, est exécuté dans une approche traditionnelle en cascade (Waterfall). Le projet S, utilise une approche agile.

Le projet W a un modèle de réalisation et une dépense typique par phase :

  • 10 % du temps/effort concernent la préparation et la définition du projet
  • 25 % du temps/effort sont passés sur une analyse minutieuse du livrable logiciel
  • 40 % du temps/effort sont passés sur le développement et les tests de système
  • 20 % du temps/effort concernent les tests d’intégration et de recette ainsi que les corrections de bogue
  • 5 % du temps/effort sont requis pour mettre le logiciel en production et le lancer avec les clients.

Comme vous pouvez voir, si on ordonne à l’équipe d’arrêter le développement à 60 % du parcours dans ce processus nous serons en réalité en plein milieu de l’écriture de code et de l’exécution de quelques tests système. Dans ce scénario, « la valeur » que le projet W délivre à la société est en fait un tas de documents d’analyse et un morceau de logiciel non testé.

Maintenant jetons un coup d’œil au modèle de dépense du Projet S, fonctionnant en mode Scrum:

  • 10 % du temps/effort concernent la préparation et la définition du projet
  • 85 % du temps/effort sont passés à analyser, développer et tester des incréments de fonctionnalités qui sont livrés itérativement dans des « sprints » bihebdomadaires
  • 5 % du temps est nécessaire pour clôturer correctement le projet

Si le Projet S doit s’arrêter à 60 % en temps ou en effort dépensé, l’équipe aura déjà complété une bonne quantité de sprints  et délivré un certain logiciel utilisable. Dans ce scénario, le projet S délivre une valeur réelle et des fonctionnalités utilisables (probablement environ 40 % à 50 % du produit total) au client.

Dans l’entretien avec la direction, nous avons utilisé un graphique sur la valeur acquise pour mieux illustrer notre point. Il inclut les suppositions suivantes :

  • Le démarrage et la définition d’un projet / produit correspondent à 0 % de la valeur totale
  • La documentation d’analyse et de conception représente 15 % de la valeur totale
  • Le code source avec les tests unitaires système correspondent à 35 % de la valeur totale
  • Le logiciel complètement testé et packagé représente 50 % de la valeur totale

Notre directeur financier et les autres cadres supérieurs ont décidé de commencer à utiliser Scrum pour nos développements de nouveaux produits parce qu’ils croient fermement que, d’une perspective de management des risques de la société, il vaut mieux utiliser Scrum qu’un développement par phase.

le site de microsoft projet en français
Partenaire de DantotsuPM

6 méthodes pour établir la priorité des projets selon Prince2

Article original: Six methods for prioritising projects sur le blog Prince2

Prince 2Il ne manque pas de techniques quantitatives et qualitatives pour choisir et déterminer la priorité des projets et nous passons ici en revue six méthodes qui fournissent un peu des deux.

1. Valeur Nette Actualisée (« Net Present Value » : NPV) : Très prisée dans le secteur public pour comparer la valeur escomptée des dépenses ou bénéfices futurs, cela définit la différence entre la valeur actuelle des dépenses et des bénéfices. Un NPV positif indiquerait qu’un projet devrait être profitable et poursuivi alors qu’une valeur négative indiquerait que le projet devrait être abandonné. Un ensemble de ressources de premier ordre sur le NPV sur Web Office of Government Commerce démontre son utilisation réussie avec des exemples détaillés et des études de cas. Le cours APMP for PRINCE2 Practitioners couvre ceci et d’autres sujets similaires.

2. Période de Remboursement (« Payback Period »): En utilisant cette méthode assez simple, les managers peuvent calculer combien de temps il faudra pour que les bénéfices du projet couvrent les coûts, c’est-à-dire quand ils récupéreront le coût initial. Les projets avec une période de remboursement rapide sont naturellement plus attrayants que ceux avec une période de remboursement plus longue pendant laquelle plus de choses peuvent mal tourner; Tout en gardant à l’esprit qu’une période de remboursement rapide ne garantit pas de meilleure marge. Cela vaut la peine de noter que si la simplicité du calcul de la période de remboursement est sa force, certains pourraient le considérer trop simpliste pour être utilisé seul.

3. Taux Interne de Retour (« Internal rate of Return » : IRR) : On calcule le taux estimé de retour d’un projet, un taux plus élevé de retour rend l’investissement plus probable. Les organisations mettront généralement un taux minimal de retour en dessous duquel normalement ils ne considéreront pas de projet.

4. Analyse de Valeur Acquise (« Earned Value Analysis » : EVA) : Considéré avec précaution par certains parce qu’elle est associée à de grands projets et exige, entre autres choses, une culture de rapport dans une société, ce peut être une technique utile. Les organisations peuvent gérer et mesurer un projet pour avoir une vue intégrée de son coût, ses dépenses et du progrès, ce qui leur permet d’estimer les ressources qui auront été utilisées à l’achèvement. Les managers peuvent utiliser EVA pour les aider à surveiller l’exécution du projet et corriger les variances, geler un projet ou l’abandonner si nécessaire.

5. Tableau de Bord Équilibré (« Balanced Score Card » : BSC) : les organisations l’emploient pour aligner la vision et les activités business de la société depuis quatre perspectives. D’une perspective financière pour tout examiner, du retour sur investissement au cash-flow. D’une perspective interne, des managers de processus commerciaux pourrait évaluer des facteurs comme l’automatisation de processus ou leur alignement. Pour atteindre un niveau élevé de satisfaction de client, le taux de conservation des clients pourrait être examiné. Sous l’angle de la croissance et de l’apprentissage, des entreprises peuvent se concentrer sur des secteurs comme l’expertise des employés et leur satisfaction au travail.

6. « Business Case »: le Business Case fournit à un programme ou un projet sa raison d’être et c’est un composant important tant de PRINCE2 et de « Managing Successful Programmes ». Il décrit les raisons d’investir dans un projet, fournit une structure pour amener les changements coté business et suit le projet pendant toute sa vie. Un Business Case détaillé comporte cinq parties principales. Alignement Stratégique qui considère des problèmes comme les besoins du business et les bénéfices stratégiques; l’évaluation d’options se concentre sur les bénéfices et la quantification des risques et l’analyse de sensibilité; l’évaluation des aspects commerciaux d’un projet impliquerait l’examen en détail du business case et regarder les secteurs tels que les délais de mise en œuvre; Une évaluation d’accessibilité se concentre également sur l’aspect financier en se concentrant cette fois sur des choses comme le budget sur la vie entière du projet; les décisions des composants finaux, la faisabilité d’un projet, exigeant de regarder en profondeur, par exemple, des projets semblables, des rôles de projet, l’approvisionnement et, en bref, le management de projet.

les termes financiers en anglais sont souvent utilisés dans les projets internationaux

Vous vous posez encore des questions sur la signification de certains termes utilisés par quelques uns de vos interlocuteurs anglophones lors de vos revues de projet, lors de la création de Business Case, lors de l’estimation du retour sur investissement, du calcul des revenus escomptés, de la prise en compte des achats…

…ce site de Michael Gentle est fait pour vous

IT Financials Glossary

Michael ne propose pas de traduction mais plutôt une explication en anglais des termes financiers majeurs utilisés couramment en informatique.

Je trouve en fait cette approche beaucoup plus utile qu’une traduction des termes dont je n’aurais pas forcément une compréhension claire,  n’étant pas un expert de la terminologie française du monde de la finance.

les compétences financières sont cruciales pour les chefs de projet

bilan financierUn ami m’a invité à lire cet article centré sur la nécessité de connaissances ou au moins de compréhension des finances de base pour tout informaticien. Je pense qu’il s’applique également à la profession de chef de projet. Même si nous ne sommes pas tous très versés ou fanas des aspects financiers, ceux-ci sont souvent au cœur du sujet pour déterminer la poursuite ou l’arrêt d’un projet, sa réussite ou son échec final. Un cours « finances pour non financiers » est d’ailleurs en général très apprécié comme j’ai pu le constater dans plusieurs entreprises.

Vous pouvez avoir les meilleures équipes et respecter tous vos jalons, mais en fin de compte, les projets vivent ou meurent par leurs données financières.

IT financial skills – mind the gap! article de Michael Gentle

Avec un budget informatique moyen s’établissant à 2-8 % de revenu et 30-50 % de capital investi, on penserait logiquement que, en moyenne, l’informaticien a, sinon une connaissance robuste des données financières de l’informatique, au moins une compréhension raisonnable de l’essentiel, pour qu’il puisse voir comment ses activités quotidiennes contribuent à ces chiffres.

Eh bien, réfléchissez-y à nouveau. Seul le sommet de la direction informatique comprend vraiment ce que les chiffres représentent – ou plus précisément, supposent représenter parce que, comme nous verrons plus loin sur, il y a une marge significative d’erreur. Le reste, qui signifie la grande majorité du service informatique, a peu d’idée comment leur travail quotidien impacte les résultats financiers de la société. Ils ne s’en soucient probablement pas particulièrement, pas parce qu’ils ne sont pas des professionnels, mais parce qu’ils ne le considèrent pas comme une partie de leurs responsabilités. Ils sont là pour faire l’analyse, le développement, le support ou autres ; les finances sont le travail de leurs managers – ou pour les comptables du département financier.

Et pourtant, c’est le travail quotidien de ces personnes, construit sur des corrélations complexes entre des équipes de spécialistes, qui font ces résultats. Comment des personnes qui estiment que les données financières informatiques ne font pas partie de leurs responsabilités peuvent-elles fournir les informations précises qui seront en bout de ligne converties en données financières de l’ordre de 2-8 % du revenu et 30-50 % des investissement de capitaux ?

La réponse, bien sûr, est qu’ ils ne le peuvent pas. Par exemple, un sondage de PSB Research en mai 2009 auprès de décideurs de l’informatique a constaté que presque les trois quarts d’entre eux estiment leur marge d’erreur de 5-20 % dans leurs coûts réels, tandis que seulement 12% auraient une marge d’erreur de moins de 5 %. Pour un $100m de budget informatique, cela signifie que les chiffres pourraient être erronés de 5 à 20m pour trois sur quatre de toutes les sociétés interrogées. Autrement dit, il pourrait être de $80m comme de $120m – ce qui n’est pas exactement de la menue monnaie.

Le sondage confirme simplement ce que la plupart d’entre nous soupçonnent de toute façon. Au cours de beaucoup de mes années dans l’industrie, dans des services informatiques et aux ventes de logiciels, j’ai régulièrement entendu dire que les gens – incluant des cadres supérieurs – admettent ouvertement qu’ils ne savent pas la différence entre dépenses d’investissement et opérationnelles (opex) ! Ou bien, ce qu’est la dépréciation et comment elle s’applique aux systèmes d’information. Ou encore la différence entre un compte de résultats et un bilan. Ou comment les provisions augmentent l’exactitude du rapport mensuel. Ou la différence entre un budget et un prévisionnel. Pour voir comment vous vous en sortez sur l’essentiel des données financières, prenez ce rapide test 1-minute survey et voyez les résultats. Vous pouvez aussi passer à travers le IT Financials Glossary et tester votre compréhension de l’essentiel [de la terminologie financière anglo-saxonne].

sécuriser protéger coffre fortCe ne serait pas si terrible si les contrôleurs financiers jouaient leur rôle de gardien et de protecteur et étaient capables de capturer de telles erreurs. Malheureusement, ce n’est pas toujours le cas. Beaucoup de sociétés souffrent du dilemme classique d’informaticiens ne connaissant pas assez la finance et de financiers ne connaissant pas assez l’informatique. Donc, l’informatique donne des chiffres à la finance, qui doit souvent les prendre pour argent comptant. C’est aussi vrai pour les budgets que pour les données réelles. Ces mêmes chiffres sont alors parfois refacturés en interne au business, qui pourrait avoir peu d’idée de ce qu’ils payent puisqu’ils doivent à leur tour les prendre à leur valeur nominale.

OK, et alors ? Qui s’en soucie ? L’informatique est de la technologie et de la livraison et direction de systèmes pour le business, n’est-ce pas ? Depuis quand les finances font-elles partie de la description de poste ? Eh bien, elles pourraient ne pas faire partie de la description de poste, mais les chiffres pilotent tout. Vous pouvez assembler les meilleures équipes de projet, atteindre tous vos jalons et produire tous vos livrables, mais en bout de course, vos projets et leurs applications informatiques résultantes vivent ou meurent selon leurs résultats financiers. Et ceci est vrai de la planification d’investissement et prévisions budgétaires à la gestion des coûts et leur imputation :

  • Planification d’investissement : de pauvres pratiques financières peuvent aboutir aux choix de mauvais projets d’une perspective justification business (« business case ») (lisez : le projet va probablement échouer malgré les meilleurs efforts de chacun)
  • Prévisions budgétaires : des budgets de projet peu réalistes, par définition basés sur des suppositions et des estimations, deviennent souvent gravés dans le marbre, au lieu de se développer naturellement par prévision mensuelle. Pour la plupart des projets, c’est souvent le budget et pas les dépenses, qui sont erronés.
  • Management des coûts : une attention insuffisante aux données financières aboutit à une énorme quantité de suivi et de rapports frustrants et sans valeur-ajoutée, laissant les projets et applications informatiques exposées à des réductions de coûts par défaut.
  • Imputation : les clients business ont souvent peu d’idée de ce qu’ils payent puisque le projet informatique et les responsables d’applications sont d’habitude incapables de comprendre leur difficultés financières, aboutissant à un focus sur les coûts plutôt que sur la valeur.

Pour conclure, tout le personnel informatique – et pas seulement la direction – doit augmenter sa compréhension financière générale, parce qu’en fin de compte ce sont les actions de chacun qui contribuent à l’exactitude, la ponctualité et la crédibilité des chiffres totaux.

Cela exigera la mise en œuvre de processus financiers de base pour les prévisions budgétaires et le management des coûts dans une structure de management de projet qui va au-delà de la seule livraison du projet. Au moment où la balle est passée aux équipes de support, la référence de base financière est d’habitude à peu près établie et peut seulement augmenter après cela.

Michel Gentle est un consultant informatique de données financières et l’auteur de « An Introduction to IT Project Financials – Budgeting, Cost Management and Chargebacks ». Pour d’autres articles sur ce sujet, visitez www.itprojectfinancials.com.

CSP Formation
Partenaire de DantotsuPM