Archives de Tag: finance

capitaliser les coûts de développement logiciels des méthodes SDLC à Agile

8 nov

Capitalizing software development costs from SDLC to Agile.

http://itprojectfinancials.com/insights/2011/06/05/capitalizing-software-development-costs-from-sdcl-to-agile/

Par Michael Gentle

Les couleurs de l’argent

L’argent a diverses couleurs, de vert aux États-Unis à toutes les couleurs de l’arc-en-ciel selon les pays. Dans l’informatique, l’argent a seulement deux couleurs: Capex et Opex.

Il y a diverses régulations nationales et internationales et diverses normes comptables (comme FASB et IFRS) qui fixent des directives claires pour Capex versus Opex quand on développe du logiciel pour un usage interne. Notez que ces directives ne dictent pas si les sociétés doivent capitaliser ou pas, seulement les règles qu’elles doivent suivre si elles décident de le faire. Comme nous le verrons plus loin, quelques sociétés capitalisent leur développement logiciel tandis que d’autres le passent en dépenses.

Maintenant, indépendamment d’où se trouve votre service informatique, vous devriez toujours pouvoir comprendre le débat sous-jacent, parce que, au bout du compte, tout se réduit aux chiffres – Capex ou Opex.

Le règne du Capex contre Opex dans l’informatique

Alors que couvrent les règles comptables ? Essentiellement les trois phases suivantes du développement logiciel, basé sur l’approche « Waterfall » ou le Cycle de vie de Développement de Système (System Development Life Cycle : SDLC) (nous parlerons du développement itératif ou agile un peu plus loin) :

  • Étape préliminaire ou phase d’évaluation de projet, qui établit la faisabilité technique du projet. Ceux-ci sont essentiellement des coûts R&D et sont facturés en Opex, parce que, si le projet s’arrêtait là, il n’y aurait aucun actif duquel parler.
  • Développement logiciel ou phase de configuration d’application. Tout le développement et travail de configuration ultérieur à la faisabilité technique est du Capex. Le résultat final est un actif, comprenant le logiciel (acheté ou construit), le matériel et l’infrastructure.
  • Mise en œuvre ou phase de production. C’est de l’Opex parce que ceux-ci sont des coûts de fonctionnement quotidiens.

Maintenant, si seulement c’était aussi simple! Malheureusement, ce n’est pas de la science ni de l’ingénierie (bien que nous aimions souvent penser que c’en est! ). Par exemple:

  • Des licences d’utilisation d’un logiciel d’entreprise sont du Capex, mais les coûts de maintenance annuels correspondants sont de l’Opex.
  • L’étude fonctionnelle est de l’Opex et la conception technique est du Capex, mais la frontière entre les deux peut être trouble quand réalisée par des équipes collaboratives.
  • Les mises à jour de production ou améliorations sont capitalisables, tandis que la maintenance et la correction de bogues ne le sont pas, bien qu’ils comportent tous les deux des coûts de développement. C’est parce que les premières augmentent significativement la valeur de l’actif, alors que les dernières ne le font pas.
  • Une interface de prise de commande entre ERP et CRM est un coût d’investissement, tandis qu’une interface de migration de données d’ERP à CRM est une dépense. C’est parce que la première est une partie intégrante de l’actif, qui produit une valeur à long terme, tandis que la seconde est unique sans future utilisation alternative.
  • Les déplacements et voyages sont normalement des dépenses – sauf quand elles font partie d’une Activité Capitalisable!
  • Un logiciel en tant que Service ou Software as a Service, SaaS est du pur Opex. Même si vous finissez par personnaliser l’application SaaS, les coûts de développement seront toujours de l’Opex parce que vous louez. Vous ne possédez pas l’actif : Il ne se trouve pas sur le bilan de votre société.

Une chose à retenir de ces exemples est que ce n’est pas l’activité en soi qui est Capitalisable (Eg Développement), mais plutôt le Résultat de cette activité et la propriété de l’actif résultant. Ainsi quand nous disons “Le développement et le test sont Capitalisables”, ce que nous disons vraiment est qu’ils sont Capitalisables à cause de leur Résultat, parce qu’ils sont utilisés pour construire un actif complètement en votre possession qui produira de la valeur économique à long terme.

Comme vous pouvez voir, il y a beaucoup de place pour l’interprétation, aboutissant aux différences de façons dont les sociétés capitalisent les coûts. Alors comment le manager lambda de projet ou d’application – pour lequel la plupart du susdit est probablement une nouveauté – produit-il des prévisions budgétaires et de coûts appropriées qui puissent résister à un audit ? (Testez votre propre niveau de connaissance avec le Questionnaire suivant).

La réponse principale se trouve dans leur niveau de connaissance financière. Malheureusement, une autre enquête démontre qu’environ 50% des personnes interrogées ne connaissent pas la différence entre Capex et Opex et 80% n’ont jamais eu une quelconque formation financière au cours de leur carrière. Cela peut être atténué dans une certaine mesure par le niveau de support qu’ils obtiennent du service financier et le degré avec lequel les systèmes d’ERP peuvent être configurés pour implémenter automatiquement certaines de ces règles.

scrum methodologie agileEt en ce qui concerne le développement interactif ou Agile ?

Les susdites règles comptables et directives sont basées sur la méthodologie « Waterfall » ou SDLC, et ne peuvent pas être appliquées directement au développement itératif ou agile avec son approche collaborative, des cycles courts et l’absence d’une grande conception en amont. Cela signifie qu’il n’y a aucun jalon de processus clair pour la faisabilité technique, ce qui exige donc une approche différente pour  identifier le début de la capitalisation.

Selon FASB, la faisabilité technique peut être basée sur une conception détaillée ou sur un produit qui fonctionne :

  • Conception détaillée : “La conception dans le détail d’un produit logiciel qui amène la fonctionnalité du produit, ses caractéristiques et les besoins techniques à leur forme la plus détaillée et logique, prêts à être codés”.
  • Maquette (ou prototype) : “Une version opératoire du produit logiciel qui est réalisée dans le même langage de programmation que le produit final commercialisable, qui fournit toutes les fonctions majeures prévues pour le produit et est prête pour le test de client initial (d’habitude identifié comme un bêta test)”

Dans le développement itératif ou agile, comme l’explique le consultant et spécialiste agile, Craig Larman, la faisabilité technique sera donc atteinte après un certain nombre d’itérations (appelé des sprints dans la méthodologie Scrum) après lesquelles la capitalisation peut commencer. Cela correspondrait au jalon “fin de conception” de Barry Boehm’s Life Cycle Architecture, ou en méthode Rational Unified Process (RUP).

Une autre différence clé entre SDLC et agile est la quantité de coûts de développement qui peuvent être capitalisés, qui sera en général moindre que sous l’approche détaillée de conception SDLC. C’est parce que le développement initial est fait pendant des itérations Antérieures au fait d’atteindre la faisabilité technique, tandis que dans SDLC tout le développement est fait Après la faisabilité technique (ce qui souligne de nouveau le point fait plus tôt que c’est le résultat plutôt que l’activité qui est l’un des critères principaux pour Capex versus Opex). Mais c’est peut-être un point discutable, parce que le développement itératif exige généralement beaucoup moins de temps pour atteindre la faisabilité technique que SDLC, qui est lourdement chargé en amont en Opex avant le début de tout développement.

Dans tous les cas, ceux distinctions agiles versus SDLC ne se voient pas très souvent en pratique, parce que, non seulement le développement agile n’est pas la norme dans les services informatiques, ceux qui le pratiquent ne le font ainsi à une échelle assez grande pour justifier la capitalisation. Et les sociétés qui pratiquent vraiment à grande échelle le développement itératif ou agile sont d’habitude les sociétés de développement qui ne capitalisent pas de toute façon (voir le point ci-dessous).

Capitaliser ou pas, telle est la question

Comme mentionné au début de cet article, quelques sociétés capitalisent leur développement logiciel tandis que d’autres le considère comme une dépense. Qu’est-ce qui commande de telles décisions ?

Nous devrions d’abord faire la distinction entre des sociétés de développement de logiciels (dont c’est le métier fondamental, Eg Vendeurs logiciels) et les sociétés dont le métier fondamental n’est pas cela, Eg construction de biens ou laboratoires pharmaceutiques :

  • Sociétés de développement de logiciels Comprenez que l’informatique est indiscernable de la R&D – en effet, comme Craig Larman l’indique, historiquement l’informatique s’appelait R&D ou Développement de Systèmes ou Ingénierie. Par conséquent, ils ont fait une comptabilité appropriée tant qu’ils ont été là, souvent ils se sont basés sur l’ingénierie simultanée et des équipes transverses. La norme pour les sociétés de développement de logiciels est de considérer l’informatique comme une dépense (voir l’enquête dans le rapport 2006, , Capitalization of Software Development Costs: A Survey of Accounting Practices in the Software Industry, dans laquelle 146 sur 207 sociétés logicielles n’ont pas capitalisé leur développement logiciel).
  • Les services informatiques internes Et leurs contrôleurs de gestion ne voient pas GÉNÉRALEMENT l’informatique comme de la R&D; Eg dans un laboratoire pharmaceutique, la R&D c’est créer des médicaments, pas construire du logiciel. Donc la méthodologie SDLC dominante prévaut, avec les méthodes comptables qui se prêtent plus au Règles FASB Capex versus Opex décrites dans cet article. Cependant, cela ne signifie pas que tous capitalisent. Certains le font et d’autres ne le font pas.

Une raison clé de passer des coûts en dépenses, identifiées à la fois par Luigi Paraboschi (VP de Finance à HP à Genève) et Eugene Nisker (PDG de Evident Point Software À Vancouver), est de comptabiliser les coûts plus tôt et donc réduire au minimum le poids fiscal à court terme.

D’autres raisons incluent une combinaison d’un faible coût total de projet, un court temps de service et peu de temps entre la faisabilité technique et l’achèvement du développement logiciel. J’ai interrogé un certain nombre de personnes sur cela en Europe, aux USA et au Canada et leurs réponses sont allées de zéro ou très peu à 50/50 (Suraj Nekram, PDG de SteelGlass Consulting au New Jersey). J’ai personnellement travaillé bien plus avec des services informatiques qui capitalisent qu’avec ceux qui ne le font pas.

Alors qu’il n’y a aucune bonne ou mauvaise façon puisque toutes les deux sont financièrement légales, l’opinion communément admise tient à ce que le CIO “préfèrent” Capex parce qu’il réduit le budget informatique de l’année en cours, tandis que les investisseurs préfèrent Opex parce que l’on peut voir la capitalisation comme une augmentation artificielle des profits de l’année actuelle. En répercutant cette vue, le site Web financier Investopedia, Dans un article sur le cash-flow, dit que l’Opérateur de télécommunications “Verizon a voulu inclure le logiciel capitalisé dans ses dépenses d’investissement” Tandis que “Microsoft classifie avec responsabilité tout développement comme un coût … qui améliore la qualité de son cash-flow des d’opérations” (Le terme Avec responsabilité dit tout …). Pour Luigi Paraboschi, l’accessibilité est un critère clé : si votre compte de pertes et profits peut se le permettre, c’est mieux de considérer l’IT comme une dépense.

En conclusion

Au final, si vous y travaillez dans l’informatique, indépendamment de si votre société capitalise ou pas le développement logiciel, vous devriez toujours pouvoir comprendre la mécanique sous-jacente. Tôt ou tard, quelque part, entre la planification des prévisions d’investissement budgétaires et la gestion et l’imputation des coûts, vous entendrez un CIO, un chef de produit, un directeur de PMO ou un contrôleur de gestion amener ce sujet. Alors, comme le dit la formule consacrée “1 PM averti en vaut 2 ! “

Pour aller plus loin

vous devriez toujours pouvoir comprendre le débat sous-jacent, parce que, au bout du compte, tout se réduit aux chiffres

connaissez-vous les 6 étapes d’une analyse coûts/bénéfices?

14 oct

Know the 6 Steps in Cost/Benefit Analysis

http://web.hbr.org/email/archive/managementtip.php?date=062011

Nous savons tous que nous devrions investir quand les bénéfices dépassent les coûts. Mais peu de personnes comprennent ce qui entre réellement dans cette analyse. Voici six étapes pour vous aider à la comprendre :

  1. Comprenez le coût d’un statut quo. Vous en avez besoin pour mesurer le mérite relatif d’un investissement par rapport à ne rien faire.
  2. Identifiez les coûts. Considérez les investissements de départ ainsi que ceux des années futures.
  3. Identifiez les bénéfices.  Vérifiez combien de revenu additionnel l’investissement va générer.
  4. Déterminez les économies de coûts. Que pouvez-vous arrêter de faire grâce à cet investissement ?
  5. Créez un échéancier des coûts et revenues escomptés. Comprenez quand les coûts et bénéfices vont se produire et à combien ils se monteront.
  6. Évaluez les bénéfices et coûts non quantifiable. Y aura-t-il des bénéfices immatériels tel qu’un renforcement du positionnement de votre société par rapport à ses distributeurs, ou des coûts comme la création d’une complexité non nécessaire ?

qu’est-ce que la réalisation des bénéfices ?

9 août

What is Benefits Realisation?

http://www.projectsmart.co.uk/what-is-benefits-realisation.html

Les projets ne se terminent pas seulement avec livraison ‘technique’ et un rapport de clôture

Duncan Haughey, PMP

Vous avez livré votre projet dans les temps, dans le budget, le client l’a accepté et vous avez achevé votre rapport de fin de projet. C’est la fin! Vous avez terminé le projet, le temps est venu de passer à autre chose, exact ? Faux. Vous ne pouvez pas simplement vous attendre à ce que les bénéfices tombent automatiquement de votre projet sans effort.

poches videsLivraison réussie mais aucun bénéfice

Les sociétés dépensent des millions sur des projets qui ne sont jamais finis. Souvent, la raison n’a aucun rapport avec la qualité du livrable. Il est plus probable qu’il n’y ait pas le temps, l’énergie ou l’enthousiasme nécessaires pour s’assurer que le produit ou le service est adopté et intégré dans l’organisation. Souvent, c’est parce que le prochain grand projet, plus passionnant vient nous distraire.

Avez-vous avez jamais livré un projet ‘réussi’, seulement pour découvrir plus tard le produit ou le service n’a jamais été utilisé ou implémenté. Ce n’est pas un sentiment agréable. Alors, que pouvez-vous faire à ce sujet ? La réalisation des bénéfices est la réponse.

Réalisation active des bénéfices

En tant que chef de projet, vous êtes dans une position unique pour aider votre client à tirer les bénéfices détaillés dans le « business case ». Cela peut être une autre phase une fois que vous avez clôturé le projet, ou bien être exécuté comme une partie du projet lui-même. Il se peut que cela ne suive pas directement la fin du projet. Cela peut commencer après une courte période de temps, avant la revue de fin de mise en œuvre, qui a typiquement lieu 3 à 6 mois après la fin du projet.

Les avis semblent partagés de savoir si la Réalisation active des Bénéfices est du domaine du Chef de projet. La vérité est que beaucoup de projets déclarés comme des succès, ne délivrent jamais les bénéfices ou résultats prévus à l’origine.

Le rôle du chef de projet dans l’atteinte des bénéfices du projet, implique de travailler étroitement avec le client pour s’assurer que le produit ou le service est fortement adopté et intégré dans l’organisation. Vous et votre équipe pouvez jouer un rôle :

  • Exécuter des démonstrations et présentations
  • Donner des ateliers et formations
  • Préparer des matériels de commercialisation
  • Organiser les lancements de produit et de service
  • Organiser et présider des réunions
  • Découvrir des solutions créatives aux problèmes
  • Soutenir la cause
  • Conduire les changements

Pour tirer des bénéfices vous devez obtenir du changement.

Dans leur livre le Paradoxe de L’information (The Information Paradox), John Thorp et le DMR’s Centre for Strategic Leadership, disent que :

“C’est un principe central de l’Approche de Réalisation des bénéfices que les bénéfices viennent seulement avec le changement et, également, le changement doit être supporté par des bénéfices.”… “Les gens doivent changer leur façon de penser, de manager et d’agir pour implémenter l’Approche de Réalisation des Bénéfices.”

Changer la manière de penser, de manager et d’agir des personnes n’est pas tâche facile, mais sans cela, votre projet est en danger de rejoindre la longue liste des livraisons réussies de projets qui n’ont jamais été déployés.

Aussi, ne laissez pas vos projets délivrer et mourir, assurez-vous que les bénéfices prévus au départ soient bien réalisés à la fin.

cultivez vos talents – management des coûts

12 juil

Article écrit par Pascal GILQUIN, Responsable Département FINANCE chez CSP Formation et partenaire de DantotsuPM. Retrouvez cet article sur le blog Management de Projet de CSP Formation à l’adresse suivante : http://management-projet.cultivezvostalents.fr

DE L’OBLIGATION AUJOURD’HUI DE MAÎTRISER DU LANCEMENT A LA CLÔTURE DU PROJET

« Les projets ayant un TRI (Taux de Retour sur Investissement ou ROI) de moins de 14 % ne passent plus cette année, l’actionnaire devient de plus en plus exigeant  … »

« Dans ces années difficiles, on me demande d’être plus vigilant et surtout plus réactif d’un point de vue de coûts de projet  »

L’avis de l’expert

Dire que les coûts prennent de plus en plus d’importance est un euphémisme ! Aujourd’hui, presque obligé d’avoir de solides connaissances financières dans la conduite de projet !

AVANT LE PROJET : je dois prévoir et estimer au plus juste : il s’agit de garantir à l’actionnaire une rentabilité de capitaux engagés ; sinon, impossible d’obtenir du financement pour mes projets futurs …

PENDANT LE PROJET : Je dois impérativement contrôler si je m’éloigne de mes prévisions et surtout  effectuer des actions correctrices rapides afin d’éviter les dérives …

On a même inventé un nouveau mot : LA “COÛTENANCE” ou la science de la maîtrise des coûts !

Le champ d’application

Au quotidien, le chef de projet doit posséder une double casquette de management de coûts :

- BIEN PRÉVOIR, ESTIMER SES COÛTS au plus probable

- MAÎTRISER SES COÛTS PENDANT SON PROJET et proposer des actions correctrices

Cela suppose donc 2 niveaux de connaissances orientés coûts demandant des compétences élargies :

Niveau ESTIMATION DE COÛTS :

  • Connaître les méthodes globales, paramétriques, modulaires …
  • Savoir intégrer le coût des risques d’un projet (% d’occurrence, loi statistiques … )
  • Savoir sortir un taux de rentabilité de son projet
  • D’un point de vue cash, savoir calculer au  bout de combien de temps je récupère ma mise de fonds initiale

Niveau MAÎTRISE DES COÛTS :

  • Épouser un vrai rôle de coûteneur ! : utiliser la méthode du Reste à faire, contrôler ses dérives, travailler sur avancement physique, jalons, écarts …
  • Enfin bref maîtriser son coût de projet du début à la fin, il s’agit de tenir à bout de bras son projet sous l’angle COÛTS !

Exemple de mise en pratique Et retour expérience clients

Chez ERAS, (bureau d’études en ingénierie industrielle) chaque chef de projet a un intéressement pour les écarts entre prévu et réalisé inférieur à 5%.

Chaque estimation de ligne budgétaire repose sur un retour d’expérience de projets similaires, une analyse après projet entre budget initial et budget révisé étant faite minutieusement.

Ensuite, chaque ligne budgétaire conséquente est révisée en cas d’écart définitif et le coût prévisionnel automatiquement recalculé.

En tout cas, le chef de projet se doit d’être techniquement bon, bien sûr, mais aussi excellent estimateur avec une bonne perception de la dépense la plus probable. Enfin il doit être un parfait coûteneur avec le calcul régulier de la dérive future, l’outil informatique maison permettant de juxtaposer des données estimatives initiales avec des « re-prévisions » au cours du projet.

CSP Formation

Partenaire de DantotsuPM

7 juillet – Paris – L’évaluation de performances dans les projets de Recherche et Développement

17 juin

AfitepSéminaire : « L’évaluation de performances dans les projets de Recherche et Développement »

Organisé par le Centre de Compétence Technique Management de Projet du CNES et l’AFITEP

Dans un contexte général de concurrence et de limitation des ressources, la préoccupation d’efficacité (ou d’efficience) a gagné les différents champs d’activités d’une entreprise : conception, production, maintenance…

En conséquence directe, l’évaluation des performances s’est progressivement imposée dans les entreprises d’une part comme voie d’amélioration continue et d’autre part comme moyen d’accroître la visibilité externe de cette entreprise.
L’évaluation des performances, déjà appréhendée dans le monde industriel, a gagné le monde de la Recherche et de l’Enseignement Supérieur. Agences d’évaluation et organismes de certification se sont d’ailleurs multipliés ces dernières années.

L’évaluation des performances ne concerne plus seulement l’ analyse qui peut être faite à l’occasion du Retour d’Expérience d’un projet. Il s’agit désormais de faire appel aux bons indicateurs représentatifs des performances de l’entreprise. La détermination de ces indicateurs est le vrai défi posé par cette nouvelle approche d’évaluation, tant le corpus d’information est dense et complexe à l’ère d’Internet.

Le séminaire du 7 juillet prochain organisé par le CCT MAN du CNES et l’AFITEP s’intéressera plus particulièrement à l’évaluation des performances de programmes de Recherche et Développement se déroulant sur plusieurs années.
Pour vous inscrire : http://cct.cnes.fr/cctinfo/programme.htm

identifier le retour sur investissement intangible d’un projet

17 juin

Finding a Project’s Intangible ROI

http://blogs.pmi.org/blog/voices_on_project_management/2011/05/finding-a-projects-intangible.html

Par Taralyn R. Frasqueri-Molina, CAPM, PMP

Project Management InstituteSi vous êtes nouveau dans le management de projet, vous pourriez être étonnés d’apprendre que quelques projets – peut-être certains des vôtres – ne produisent pas de réels bénéfices.

Cela peut rendre plus difficile de montrer à quel point vous êtes doué comme chef de projet et combien votre équipe de projet est forte. Alors, comment pouvez-vous montrer vous avez créé de la valeur si vous ne pouvez pas montrer du revenu ou des profits comme résultat direct de votre projet ?

Regardez le Retour sur Investissements (Return On Investments :ROI) sous un jour différent. Au lieu d’utiliser les bénéfices comme point de référence, considérez des avantages intangibles, comme les gains d’efficacité qui résulteront du Projet, ou un changement positif dans les relations publiques ou dans la dynamique de l’équipe

Avec mon équipe, nous travaillions sur un projet qui comprenait l’automatisation d’une salle de conférences. Un utilisateur pourrait entrer dans la pièce, pousser un seul bouton et l’automatisation ferait le reste. Le projet n’a pas produit de bénéfice, mais les retours d’information des parties prenantes étaient 100% positifs : Mon équipe avait créé un environnement qui travaillait comme prévu et rendu la vie des utilisateurs au travail plus facile et moins irritante. Et cela s’est traduit par une énorme amélioration dans l’influence des parties prenantes.

Quand nous avons eu besoin de leur soutien sur le projet suivant, les parties prenantes étaient plus qu’heureuses d’offrir leur support. Elles ont même accepté si le projet les affecterait négativement (c’est-à-dire à cause de l’espace indisponible pendant le projet, ou une fonctionnalité mise hors de service pendant peu de temps). Il peut être difficile de dire que les bonnes grâces des parties prenantes ont augmenté d’exactement 42%, mais c’est très évident quand votre capacité à les influencer a augmenté. Les choses semblent tout simplement fonctionner sans à-coups.

Vos projets ont-ils produit du ROI intangible ? Comment vos équipes projet en ont-elles bénéficié ?

Un article dans PM Network de Février 2011 (suivre ce lien), en pages 36 à 40, évoquait déjà ce sujet. Il exhorte les cadres dirigeants à aller plus loin que le seul ROI qui étrangle bien des projets en rendant l’organisation myope à d’autres critères de temps, qualité, efficacité, convivialité, développement organisationnel et des hommes et femmes de l’entreprise, développement durable, sécurité, éthique…

PM Network - Feb 2011 - All things considered

Cliquer sur l'image pour accéder à l'article

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

13 mai

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 !

14 Avril – Basel Switzerland – IT financial skills – mind the gap!

8 avr

Why PMs and their teams need to raise the bar in financials.

IT project teams may be well-schooled in project delivery, but they generally have a low level of financial awareness, with little idea of how their everyday work impacts the company’s financial statements. For example, a recent IT Project Financials survey shows that hardly 50% of respondents understand the difference between capex and opex, or what depreciation is and how it applies to IT systems.

OK, so what? Since when were financials part of the job description?

Well, implicitly they are – the numbers drive everything. You can assemble the best project teams and meet all of your milestones and deliverables, but at the end of the day, your projects live or die by their financials, right across the life cycle:

  • Investment planning: poor financial practices can result in the “wrong” projects being chosen (read project likely to fail despite everyone’s best efforts)
  • Budgeting: PMs often work to unrealistic project budgets cast in stone. For many projects, it is the budget, and not the spending, that is out of line.
  • Cost management: poor financials, combined with strong cost pressures, result in a frustratingly high amount of non-value added tracking and reporting.
  • Chargebacks: business customers often have little idea of what they’re paying for, resulting in a focus on costs rather than on value.

Sound familiar?

Then come and listen to Michael Gentle explain the current state of IT project financials, his suggestions for quick wins and long-term change, and why PMs and their teams need to raise their level of financial awareness.

The good news is that you don’t have to a bean-counter to understand this, for only 20% of IT project financials is accounting – the rest is all process.

Register HERE.

thumbnail

About the speaker:

Michael Gentle has over 20 years of experience in IT departments and software vendors in Europe, North America and Asia-Pacific. He brings a refreshingly new angle to traditional project management – and directly challenges IT professionals to raise their level of financial awareness. He is the author of An Introduction to IT Project Financials – Budgeting, Cost Management and Chargebacks (2010), IT Success! (2007) and The CRM Project Management Handbook (2003).

de bonnes raisons de conserver les coûts de formation de l’équipe projet dans votre budget de projet

18 mar

Reasons to Leave the Cost of Training in Your Project Budget By Francis Norman

Souvent, pendant le processus de démarrage de nouveaux projets, il apparaît que les budgets sont sous pression, particulièrement quand le chef de projet nouvellement nommé passe en revue avec le client les endroits où l’argent doit être dépensé. L’une des premières choses à être mise en question et souvent supprimée par la suite est le coût de formation de l’équipe projet qui est facile à cibler pour une réduction de coûts sur bien des projets, mais peut devenir une fausse économie par rapport aux objectifs finaux du projet.

Le processus de revue ressemble souvent à cela : comme le budget est examiné de près, l’équipe de projet essaye de pousser des coûts de formation sur l’organisation mère, soutenant que le projet est seulement provisoire, alors que l’organisation mère est permanente et en tant que telle tirera des avantages à long terme de la formation des membres de l’équipe projet. L’organisation mère repousse cette tentative, en disant que le groupe qui délivre le projet, interne ou externe, devrait porter les coûts de formation puisque la formation est pour leur projet… La cible suivante pour ces coûts est alors le client, qui conseillera de nouveau à l’équipe de projet que les coûts devraient être dans leur budget puisque l’équipe de projet et leur organisation mère en récolteront à long terme le bénéfice…et donc le cycle continue jusqu’à ce que l’une des parties accepte les coûts, un compromis est agréé pour les partager d’une façon ou d’une autre, ou bien la plus grande partie de la formation proposée est supprimée du projet.

Cependant, je soutiendrais que les avantages de la formation sont si tangibles pour toutes les parties que la vraie question ne devrait pas être comment réduire au minimum le volume et le coût associé de formation, mais combien de formation peut être fourni par la somme combinée des parties pour former au mieux une équipe de projet efficace.

Enquête après enquête, l’élément inscrit comme la plus grande motivation pour beaucoup de personnel, dans des rôles projets ou fonctionnels, est l’accès à la formation et au développement personnel, donc investir sur la formation rendra les salariés plus heureux et plus engagés sur le projet. Pour l’organisation mère, une équipe de projet mieux formée sera plus efficace et produira un projet avec un niveau plus élevé de satisfaction pour le client. Elle réduira le risque de livraison et améliorera le résultat final coté maison mère ainsi que sa réputation d’organisation qui a une vue à long terme et pour laquelle les salariés veulent travailler. Finalement, pour le client, une équipe plus efficace de projet, tant de leur côté que de leurs prestataires, livrera leur projet avec moins de risque, plus de fiabilité et une meilleure chance de bénéfices accrus du projet.

Donc, si les différentes parties peuvent convenir de dépenser plus sur la formation pour obtenir ces bénéfices, la question suivante est où dépenser l’argent. Pour la plupart des projets techniques, l’équipe sera tentée de dépenser l’argent exclusivement sur des développements techniques comme davantage d’outils technologiques, des compétences de conception techniques spécifiques et une formation à l’utilisation des nouveaux outils etc. Les compétences de communication sont d’habitude donc placées tout en bas de la liste et classifiées comme “Soft Skills”, compétences douces ou relationnelles, que chacun possède déjà un peu. Cependant, former précisément sur ces compétences peut donner des bénéfices rapides et faciles qui amélioreront tous les aspects de la réalisation complète du projet. Une équipe qui est mieux équipée pour communiquer, tant intérieurement qu’extérieurement, sera une équipe plus efficace. Les réunions deviendront plus productives ; il y aura moins de duplication de travail puisque chacun sera mieux sur les objectifs de projet; les taux d’erreurs seront réduits puisque le personnel sera plus conscient de ce que leurs collègues font ; et les membres de l’équipe seront plus enclins à travailler sur les tâches qui profitent au travail des autres plutôt que des tâches qui pourraient être en conflit ou rivalité avec celles d’autres membres.

En résumé, je soutiendrais que la formation sur les communications interpersonnelles est une cible facile et attractive quand on considère les bénéfices réalisés par rapport au coût dépensé pour tout projet d’une équipe co-localisée ou virtuelle. Une chose à laquelle penser la prochaine fois que vous participerez à une réunion de coupe budgétaire sur votre projet et que le coût de la formation reviendra sur le tapis.

PMGS Formations en management de projet

Partenaire de DantotsuPM

comment convaincre votre directeur financier d’utiliser SCRUM

2 fév

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

← Entrées Précédentes

Suivre

Get every new post delivered to your Inbox.

Joignez-vous à 236 followers