Il est beaucoup plus facile de démarrer un projet que d’en tuer un !

Même si personne n’aime voir mourir un projet, il existe certaines réalités autour du potentiel de succès qui signifient que nous devons poser des questions difficiles sur viabilité et priorités.

Killing a Project: Who Decides?

https://www.quayconsulting.com.au/news/killing-a-project-who-decides/ par Quay Consulting

[…]

Nous avons dicton chez Quay Consulting : “Il est beaucoup plus facile de démarrer un projet que d’en tuer un” et nous le constatons si souvent que notre équipe d’Assurance Qualité a conçu un processus de revue de démarrage pour permettre intervention et remédiation avant que trop d’émotions et d’argent ne soient investis dans un projet qui partirait dans une mauvaise direction.

On permet à trop de projets de progresser sans reconnaître les signaux d’alarme ou les causes premières d’échec potentiel, comme ne pas fournir les bénéfices escomptés ou risquer un retour sur investissement (ROI) négatif.

Alors, pourquoi nous sommes si réticents à tuer des projets et quelles questions devrions-nous poser pour décider de façon déterminée ?

Revenons à Essentiel : Pourquoi entreprenons-nous ce nouveau projet ?

Les changements permanents et la nature à plutôt long terme des projets dans le business signifient que le contexte dans lequel ils ont été créés pourrait fort bien avoir changé au moment où les projets avancent ou s’approchent de la livraison.

Les raisons business, les résultats d’affaires et la valeur que le projet a l’intention de livrer peuvent ne plus apporter autant aussi de valeur à l’organisation qu’initialement projeté. Malgré cela, le projet peut toujours avoir une météo au beau fixe, c’est-à-dire tenir ses délais, respecter ses coûts et ses indicateurs de qualité.

Mais il y a des moments où regarder le projet sous l’angle des avancées masque sa réalité : Il pourrait être le temps d’arrêter le projet et investir les fonds restants ailleurs, sur des projets qui présentent de plus forts retours.

Ce n’est pas quelque chose que nous observons très souvent. Peu d’organisations font des évaluations récurrentes de la probabilité de collecter les bénéfices dans leur suivi régulier de projet. Mettre ces données dans une revue de d’investissements du portefeuille de projets permet de mettre en lumière les projets sous-performants, donnant à l’organisation l’opportunité de pauser momentanément, arrêter, ou continuer en se basant sur le contexte actuel de l’environnement business.

Quand les organisations portent leur attention sur les bénéfices du projet, la réalité pourrait consister en ce que l’organisation ferait mieux d’arrêter le projet et d’investir les fonds ailleurs.

Investissement Émotionnel et ‘Peu importe ce que cela demande’ ne sont pas de bonnes raisons de continuer

les « sunk costs » sont des dépenses non récupérables quoi que l’on fasse.

Les grands projets à long terme deviennent résilients et plus un projet dure longtemps, plus de temps et d’émotions sont investis dans ses résultats.

Il n’est pas rare pour les cadres exécutifs qui sont lourdement investis dans le résultat d’un projet de déclarer que le projet est trop avancé pour s’arrêter maintenant, même s’il ne va probablement pas livrer ce qu’il devrait.

Voici la réalité

Les bonnes équipes de projet savent qu’elles doivent investir de l’énergie émotionnelle pour obtenir de bons résultats. Mais l’investissement émotionnel d’une équipe concentrée sur la livraison peut devenir un inconvénient si le paysage a changé à tel point que la fin ne justifie plus les moyens.

L’expérience de notre équipe d’assurance projet nous a montré que, plus une revue de projet progresse, particulièrement avec des projets problématiques et difficiles, plus la chaleur émotionnelle monte dans la pièce et une fièvre communicative s’installe.

Le ‘peu importe ce que cela demande’ peut sérieusement altérer le jugement et la bonne décision de si le projet reste ou pas une bonne proposition pour l’organisation, sans aller jusqu’à le qualifier de risque inacceptable.

[…]

Capital Politique : Il y a souvent moins de retombées d’un projet qui rapporte peu que d’un projet stoppé net !

money, money, money...Le plus souvent, les projets sont financés par de l’investissement (CAPEX) plutôt que de la dépense opérationnelle (OPEX). Quand une organisation arrête un projet qui peut mener à une écriture comptable négative, cela a un impact direct sur les résultats financiers, ce qui en fait une proposition de valeur très visible et peu attrayante quand les bonus et motivations sont directement liés aux profits réalisés.

A l’inverse, les bénéfices d’un projet peuvent souvent être difficiles à lier directement aux résultats (mis à part les économies fermes, comme des réductions d’effectifs) et les bénéfices s’accumulent normalement avec le temps, pas immédiatement à l’achèvement. Si un projet va délivrer moins de bénéfices qu’attendus, dans beaucoup de cas le propriétaire de projet est parti bien longtemps avant que les bénéfices ne soient comptabilisés (ou pas).

Aussi, face à une décision d’arrêter le projet en plein vol ou continuer jusqu’à sa fin, les sponsors continueront souvent avec le projet car la réalisation des bénéfices peut être nébuleuse et souvent pas suivie à la trace après la livraison, alors que la visibilité et les retombées politiques pour amortir le CAPEX investi peuvent être significatifs.

Autre situation – Utilisation de projets pour financer des ressources opérationnelles

Ce n’est pas une chose rare pour des managers créatifs que d’utiliser des projets pour financer des ressources opérationnelles « Business As Usual » (BAU) sous l’apparence de ressources projet en période de vaches maigres budgétaire alors que le travail doit toujours être fait. Nous l’avons observé : Du CAPEX projet est utilisé pour financer des ressources BAU pour une unité d’affaires ou une fonction complètement différente.

Stopper le projet en vol pourrait causer une perte de financement pour l’équipe BAU qui signifie à son tour qu’ils seront à mal pour livrer ce qui est exigé d’eux. Tant que l’on facture les ressources sur le CAPEX d’un projet financé alors personne ne semble objecter, ce qui ajoute à son tour de la pression pour continuer avec ces projets même si leur cas d’affaires peut sérieusement s’éroder.

Qui est l’arbitre ?

Avec ces forces en jeu, comment les organisations déterminent-elles alors qui décide de poursuivre ou arrêter des projets ?

La montée de l’Enterprise Project Management Office (EPMO) comme  gardien des décisions d’investissement d’entreprise a vu une utilisation plus forte des rapports de management de portefeuille, de l’analyse de triage et du management des critères de bénéfices pour évaluer activement la viabilité en cours d’exécution des projets. Ces informations et cette perspective peuvent aider une organisation à savoir quand commencer, arrêter ou faire une pause sur un projet.

Hexagon est partenaire de DantotsuPM

L’utilisation de pratiques agiles aide aussi les organisations à réduire le temps entre la réalisation de bénéfices et le début de projet, ce qui permet à la dépense projet et aux écarts comptables d’être réduits au minimum et augmente ainsi la capacité de l’organisation à pivoter rapidement autour de circonstances changeantes.

Cela demande beaucoup de maturité de savoir quand et quoi éliminer

Les projets ne seront jamais parfaits et ils seront toujours difficiles à délivrer. Nous voulons voir des cadres exécutifs engagés et des équipes qui produisent des résultats donc nous ne préconisons pas d’arrêt à grande échelle de multiples grands projets.

Mais certains projets doivent vraiment être éliminés et cela nécessite une organisation mâture pour être capable de faire cette analyse claire et prendre la décision ardue. La plupart des organisations ont toujours une marge de progression pour vraiment s’assurer que les « bons » projets sont arrêtés au bon moment.

Avec un focus sur une gestion active de portefeuille, des durées de livraison de projet réduites via l’utilisation de techniques agiles, par exemple (maximum 6 mois jusqu’à la réalisation de bénéfices) et l’évaluation régulière et récurrente des bénéfices du commencement du projet jusqu’à sa livraison, tuer un projet pour les justes raisons peut devenir la norme pas l’exception.

Parlons-en : Quand votre client trouve que la prestation est chère.

Vous payerez effectivement un montant élevé mais vous obtiendrez davantage que ce pour quoi vous avez payé !

“You’ll pay a lot but you’ll get more than you paid for”

https://seths.blog/2018/07/youll-pay-a-lot-but-youll-get-more-than-you-paid-for par Seth Godin

Ceci a toujours été une attitude viable dans le business.

Pour les travailleurs indépendants de toutes sortes, elle reste la meilleure.

La partie difficile n’est pas de facturer cher. La partie difficile est de livrer plus que ce pour quoi la personne a payé.

Pourquoi les compétences financières sont-elles cruciales pour les chefs de projet ?

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

Un ami de très longue date m’a invité à lire cet article centré sur la nécessité de connaissance ou au moins de compréhension des finances de base pour tout informaticien.

Je pense qu’il s’applique tout particulièrement bien à la profession de chef de projet. Même si nous ne sommes pas tous très versés ni fanas des aspects financiers, ceux-ci sont souvent au cœur des argumentaires pour déterminer du lancement, de la poursuite ou de l’arrêt d’un projet. Ils sont souvent déterminants pour sa réussite ou son échec. Comme j’ai pu le constater de visu, le cours « finances pour non financiers » très en vogue dans les grandes entreprises est bien apprécié de tous.

« IT financial skills – mind the gap! » fut écrit en anglais par Michael Gentle, Serial entrepreneur

Avec un budget informatique moyen s’établissant entre 2 et 8 % du revenu et 30 à 50 % de capital (Capex) investi, on penserait logiquement que l’informaticien possède, 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, détrompez-vous. 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, il existe une marge significative d’erreur. Le reste, donc la grande majorité du service informatique a peu d’idées sur 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 pros, mais parce qu’ils ne le considèrent pas comme faisant partie de leurs responsabilités. Ils sont là pour réaliser l’analyse, le développement, le support et autres tâches des systèmes informatiques. Les finances sont le boulot de leurs managers  ou des 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 permet d’atteindre ces résultats financiers.

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 pour 2 à 8% du revenu et 30 à 50% des investissement en capitaux ?

La réponse, bien sûr, est qu’elles ne le peuvent pas. Par exemple, un sondage de PSB Research 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 100 millions d’euros de budget informatique, cela signifie que les chiffres pourraient être erronés de 5 à 20 millions dans 3 sociétés sur 4 !

Autrement dit, pour un budget de €100m, les dépenses réelles pourraient être de €80 millions comme de €120 millions, ce qui n’est pas exactement de la menue monnaie.

Le sondage confirme simplement ce que la plupart d’entre nous soupçonnaient déjà. Au cours de mes nombreuses années passées dans l’industrie, puis dans les services informatiques et la vente de logiciels, j’ai régulièrement entendu dire que les gens – dont les cadres exécutifs – admettent ouvertement qu’ils ne connaissent pas précisément la différence entre dépenses d’investissement (capex) et opérationnelles (opex) !

  • Ni encore, ce qu’est la dépréciation et comment elle s’applique aux systèmes d’information.
  • Ni la différence entre un compte de résultats et un bilan.
  • Ni comment les provisions améliorent l’exactitude du rapport mensuel.
  • Ni la différence entre un budget et un prévisionnel.

Faites le test !

need for budget - besoin de budgetPour voir comment vous vous en sortez sur l’essentiel des données financières, prenez ce test rapide 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.

Manque de compréhension mutuelle

Ce ne serait pas si terrible si les contrôleurs financiers jouaient leur rôle de gardiens et de protecteurs 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 trop souvent les prendre pour argent comptant. C’est aussi vrai pour les budgets que pour les données de consommation réelles. Ces mêmes chiffres sont même parfois refacturés en interne au business, qui n’aura que peu d’idées de ce pour quoi il paie…

OK, et alors ? Qui s’en soucie ?

L’informatique, c’est de la technologie et de la livraison de solutions pour le business, non ? Depuis quand les finances font-elles partie de la description de poste de l’informaticien ?

Eh bien, elles pourraient ne pas faire partie de la description de poste, mais les chiffres pilotent tout. Vous pouvez assembler les meilleures équipes projet, atteindre tous vos jalons et produire tous vos livrables avec la bonne qualité, mais en bout de course, vos projets et logiciels informatiques résultants vivent ou meurent en fonction de leurs résultats financiers.

Et ceci est vrai depuis la planification d’investissement et les prévisions budgétaires jusqu’à la gestion des coûts et leur imputation :

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

Tout le personnel informatique et pas seulement la direction doit augmenter sa compréhension du domaine financier

En fin de compte ce sont les actions de chacun qui contribuent à l’exactitude, la ponctualité et la crédibilité des chiffres.

Cela exige 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.

Quand le produit du projet est transféré aux équipes de support, la référence de base financière est à peu près établie et le suivi des bénéfices devra alors s’y poursuivre.

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.

SMPP est Partenaire de DantotsuPM

connaissez-vous la règle des 18 mois et pourquoi des projets sont 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 dans 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 des 18 Mois déclare que :

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

N’oublions pas que beaucoup de secteurs ont un rythme naturel, par exemple 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 Kryder pour le stockage sur disque (~12 mois) et la Loi d’Haitz pour la production de LED’s (~18 mois).

Pourquoi y-aurait-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 en arrière tous les projets que j’ai managés dans ma carrière, le cycle de 18 mois d’annulation des projets revient à travers industries, contextes, technologies, tailles d’organisations et nationalités. La règle semble universelle. Pourquoi ?

Dix-huit est le nombre maximal de mois pendant lesquels le management peut souffrir. Cette douleur est la répétition des efforts de re-justification d’un projet dont on attend encore de voir les bénéfices.

Pourquoi 18 mois et pas 12 ou 24 ?

monthsPensez à 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 les impacts et bénéfices potentiels. Quand le cycle budgétaire suivant arrive, le projet est bien lancé et le financement est presque assuré car 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. Donc, les ressources sont maintenues en place et le projet continue de progresser.

Le deuxième cycle est une question totalement différente.

Quand le cycle budgétaire suivant survient, des questions s’ élèvent sur le projet :
  • Est-ce que ce projet est toujours aussi important ?
  • Y-aurait-il des projets plus importants que nous devrions financer au lieu de celui-là ?
  • Atteignons-nous les progrès escomptés ?
des budget limités, voire compressés...
il faut se battre pour chaque nouvelle année de financement !
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 laisser le projet mourir et éviter cette peine. Comme nous pouvons tous l’apprécier, éviter la douleur est une réaction humaine naturelle.

Si le management pouvait voir la valeur (quelque chose qui justifie la peine), 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 obtenir les financements 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 sur plusieurs années et que les bénéfices ne viendraient qu’à la fin. Ceci ne prouve-t-il 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 peine grandira avec chaque cycle ultérieur. Ce qui signifie que vous devrez démontrer une valeur et un impact toujours croissants pour pouvoir continuer. La douleur ne part pas avec le temps. En réalité, elle augmente.

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

Comment une équipe évite-t-elle cette règle ?

règle des 18 moisSuivez les quelques étapes simples suivantes :

1) 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 livrables 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 ? Pour esquiver le problème d’évitement d’une peine qui s’intensifie avec le temps car chaque projet remet les compteurs à zéro.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Dans mon expérience, j’ai vu la règle des 18 mois appliquée à des projets qui auraient du être tués dès le départ et à d’autres qui n’auraient jamais dus être arrêtés.

Cette apparente prise de décision 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 ces stratégies de management de projet simples afin d’éviter ce que dans le passé vous aviez attribué à des caprices du management.

CSP est partenaire de DantotsuPM
CSP est partenaire de DantotsuPM

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

Bonne chance !

New Public-Private Partnerships Guidance with APMG and World Bank

APMG will be launching the PPP Certification Guide in October this year in support of the new Public-Private Partnerships Certification Program.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

The certification program is an innovation of the World Bank Group (WBG), in partnership with a range of multilateral development banks.

safe bankA team of PPP experts from across the world have authored the PPP Certification Guide, previously referred to as the Body of Knowledge.

The PPP Certification Guide will be available on-line as a free down-loadable pdf from ppp.apmg-international.com, and can be downloaded by chapter, enabling candidates to select the chapters relevant to their subject area and study at their own pace.

The website will include more news and information on the program, to host the PPP Guide and to support the global PPP community.

Targeted towards Public-Private Partnerships Practitioners worldwide, this Certification Program is suitable for those who would like to demonstrate their competence in participating effectively in a Public-Private Partnerships team and enhance their career prospects.

The new guide aims to improve and standardize good practice to facilitate more effective joint initiatives between the public and private sectors.

Details

Partenaire de DantotsuPM
Partenaire de DantotsuPM

question d’entretien de chef de projet sur le management des coûts

Quand le projet atteint la fin de la phase de planification que vous attendriez-vous voir dans un bon plan de management de projet d’un point de vue management des coûts ?

Premièrement, je m’attache à vérifier que tous les livrables sont entièrement représentés dans le WBS.

crise financièrePuis que l’on a répondu toutes les questions sur le contenu du projet : risques, contraintes, assomptions, les livrables qui sont dans et hors du périmètre du projet.

Il est également critique que les évaluations soient détaillées et qu’elles aient été revues et acceptées par les parties prenantes clés ET les membres de l’équipe projet.

Ensuite, s’assurer qu’il y a suffisamment de marge dans le plan et que nous avons mis en place des mécanismes adéquats de suivi des dépenses.

Enfin, avons-nous bien posé les lignes de référence de base en matière de valeur attendue et de coûts tout au long du projet et en particulier à quelques jalons bien choisis?

contactez-nous pour publier une annonce
contactez-nous pour publier une annonce

La complétude et l’accord de tous sur les évaluations sont à mon avis primordiaux.

Enfin, en fin de réponse, parlez d’une expérience provenant de votre propre vécu.

Décrivez comment vous avez posé ces lignes de référence et mis en place le management des coûts sur vos précédents projets.

5 astuces pour des prévisions budgétaires efficaces dans le management de projet

5 Tips for Efficient Budgeting within Project Management

http://network.projectmanagers.net/profiles/blogs/5-tips-for-efficient-budgeting-within-project-management par Marian Woods

De nos jours, les organisations font face à des pressions croissantes quand on parle de leurs budgets de management de projet. Il y a un réel besoin d’investir seulement dans le projet qui sera réussi. Les prévisions budgétaires et la prise de conscience des bénéfices attendus devraient être au premier plan des préoccupations du chef de projet assigné. Combien ce projet va-t-il coûter ? Tous les éléments budgétaires ont-ils été bien pris en compte : heures de travail, équipement, ressources externes, etc. Pour résumer, ce projet peut-il être livré avec succès dans le budget assigné ?

repartition budgétaire bannerLa répartition budgétaire peut déterminer le succès d’un projet. Tout projet qui est complété dans les délais prédéterminés et qui atteint ses objectif ne devrait pas être considérer comme un succès si le projet ne satisfait pas à ses exigences financières. Donc aujourd’hui, les chefs de projet ont besoin de compréhension financière pour s’assurer que leurs projets ne dépassent pas leur enveloppe budgétaire.

Quelques astuces à garder à l’esprit en manageant vos projets pour vous assurer qu’ils restent dans le budget seraient :

  1. Passez en revue et ré-estimez fréquemment le budget

surveillanceNe pas examiner fréquemment les prévisions budgétaires de projet peut en fin de compte vous mener dans une position sans retour. La prévision budgétaire devrait être régulièrement passée en revue par le management de projet et le service comptabilité pour garantir que le budget ne dépassent pas les montants prévus. Plus un problème est découvert tôt, plus il sera facile de faire les amendements nécessaires au budget.

  1. Managez le contenu de façon très serrée

La dérive de contenu ou les requêtes de changement peuvent causer des problèmes inutiles pour un projet et sont les causes les plus communes de débordements. Le travail imprévu a une façon bien à lui de se glisser dans un projet. Des heures non planifiées de travail de ressources peuvent ravager avec vos budgets alloués de projet. En tant que chef de projet, vous devez avoir un processus en place pour manager tout supplément de travail et contrôler le contenu du projet. Mettre en place un mécanisme de management des changements pourrait vous fournir le contrôle nécessaire dont vous avez besoin pour tenir vos budgets.

  1. Communiquez

Je suis un fort partisan des lignes de communication claires et ma conviction n’est en rien différente quand on considère les prévisions budgétaires. Il est important que vous communiquiez aux autres membres de l’équipe projet tous les détails sur les dépenses et les budgets. Une équipe projet bien informée vous aidera en fin de compte à rester dans les budgets assignés.

Genius Inside est partenaire de DantotsuPM
Genius Inside est partenaire de DantotsuPM
  1. Managez risques et problèmes

Image courtesy of cooldesign / FreeDigitalPhotos.net
Image courtesy of cooldesign / FreeDigitalPhotos.net

Les risques possibles et les problèmes existants ont eux aussi leur façon de trouver leur chemin dans les projets et causer des dommages. Donc, il est important de les suivre et de réduire le niveau auquel ils peuvent affecter votre budget projet. Il est presque impossible d’éviter risques et problèmes, cependant vous pouvez avoir un plan en place s’ils surviennent vraiment.

  1. Connaissez vos ressources

Les ressources assignées à un projet sont en fin de compte là où va une grande partie de votre budget projet. Il est essentiel que les chefs de projet examinent de près les ressources et leurs compétences pour s’assurer qu’elles sont utilisées à 100% et que les ressources idéales sont positionnées sur les bons projets.

keeping moneyLes prévisions budgétaires et le contrôle financier de vos projets doivent être managés proactivement ! C’est un composant important du processus de management de projet qui devrait être régulièrement passé en revue par le chef de projet, l’équipe financière, des parties prenantes et des membres principaux de l’équipe d’équipes projet.

Garder une main ferme sur les budgets de projet vous aidera à faire en sorte qu’ils restent dès le départ dans les paramètres budgétaires établis.

votre premier projet, c’est simple comme 1-2-3 avec Prince2 selon Jeff Ball

Comment démarrer votre premier projet PRINCE2 en 3 étapes simples.

QRP International France
Partenaire de DantotsuPM

téléchargez le document PDF original à partir du site de QRP International

Vous avez suivi une formation PRINCE2, vous avez passé l’examen, vous êtes maintenant de retour à votre bureau, vous rouvrez le manuel de 350 pages, 19 chapitres et 26 documents …

Oui mais …. Par où commencer ?
… Simplifions les choses en 3 étapes !

1. Rédiger l’Exposé de Projet et faites-le approuver par votre exécutif

Comme son nom l’indique, l’Exposé de Projet est un document de synthèse. Il doit être facile à lire. Le manuel PRINCE2 suggère un modèle pour ce document : cependant, mieux vaut privilégier la lisibilité et la clarté plutôt que le formalisme et les détails.

L’Exposé doit contenir la structure organisationnelle du projet. Vous êtes le chef de projet, et vous avez besoin d’un Exécutif. C’est VITAL, le minimum vital. Sans Exécutif vous n’utilisez pas PRINCE2. L’Exécutif va assumer la responsabilité du projet. Vous allez exécuter en son nom le projet.

L’Exposé doit aussi contenir une description du produit du projet, votre livrable final. C’est important  de le documenter, c’est ce qui va définir votre périmètre. Le manuel PRINCE2 nous dit que c’est un document séparé mais vous pouvez l’inclure comme un paragraphe de votre Exposé.

Afin de définir correctement votre produit du projet, vous devez comprendre qui est votre client ou utilisateur (celui-ci peut être un client interne ou externe). Vous devez discuter de vos livrables avec votre client, pour comprendre leur besoin. L’Exposé de Projet doit inclure les exigences qualité du client et les critères d’acceptation.

Une fois l’Exposé rédigé, l’Exécutif doit le valider, vous ne pouvez pas continuer sans cela.

2. Créer une Structure de Décomposition du Produit et en obtenir l’approbation

Car-WBS

La structure de Décomposition du Produit (SDP) est un excellent moyen de comprendre ce qui doit être produit. Le SDP commence avec votre produit du projet, votre livrable final. Le SDP va vous donner plus de détails, 15 ou 20 livrables en tout.

Le moyen le plus simple de créer un SDP est de coller des post-it sur un tableau. Par ce biais il est facile de remodeler le SDP au fur et à mesure que les idées émergent. De manière idéale, faites-vous appuyer d’un collègue ou deux pour garantir une vision plus large. Une fois cela réalisé, convertissez les post-it en version électronique en utilisant un outil tel que Visio ou Powerpoint. C’est important de créer le SDP avant de commencer toute planification. Pour PRINCE2, le SDP est la première étape de planification.

Si vous utilisez un outil de planification, tel que MS Project ou même Excel, vous devez créer d’abord votre SDP et la faire approuver avant de commencer le travail avec ces outils. Votre PC doit être éteint !

Vous devez passer en revue la première version avec les acteurs clés : L’Exécutif, le client ou l’utilisateur et avec les chefs d’équipe qui vont produire la solution. Une fois approuvée vous pouvez créer le plan de projet autour des 15-20 livrables de votre SDP.

3. Créer un Cas d’Affaire en collaboration avec votre Exécutif.

Le cas d’affaire fourni la justification du projet. Il explique les ressources que le projet va utiliser et les compare avec les bénéfices escomptés. C’est un document important, cela dit, il doit être simple et court. Le problème avec le Cas d’Affaire est que l’on ne sait jamais quel niveau de détail est approprié. Votre Exécutif va vous guider sur ce point. N’ajoutez pas de détails superflus (si votre société n’a pas besoin d’exprimer les besoins en termes financiers, ne le faites pas).

balance temps vs ressourcesCommencez avec un résumé de votre besoin en ressources, et les bénéfices escomptés – pour de nombreux projets, c’est suffisant.

  • Les ressources sont habituellement des personnes et/ou de l’argent. Vous devez comprendre quels types de ressources sont nécessaires. (Par exemple, vous avez besoins de développeurs et de testeurs et de l’argent pour acheter les équipements).
  • La justification se base sur les bénéfices – obtenez les informations sur les bénéfices avec votre Exécutif. Tous les deux, vous devez comprendre les types de bénéfices que votre projet va générer (par exemple, réduction des coûts de production, de maintenance).

Une fois que vous avez un résumé vous pouvez détailler davantage, seulement si nécessaire. Il faudra peut-être convertir les ressources et les bénéfices en termes financiers. Vous aurez besoin probablement d’un calendrier et aussi d’un calcul financier complexe tel que la valeur actualisée nette. En tous les cas, simplifiez toujours les choses, n’effectuez pas le travail si ce n’est pas nécessaire.

3 poissons qui sortent du commun
1,2,3…

En trois étapes simples, on a les fondements de notre DIP (Documentation d’Initialisation de Projet).

Les trois piliers clés du DIP sont : l’Exposé de Projet, le Plan de Projet et le Cas d’Affaire. Ces trois étapes nous permettent de créer ces trois piliers. Voici la manière de mettre en pratique les concepts de votre formation PRINCE2 en trois étapes simples.

© Copyright QRP International 2013. Reproduction in full or part is prohibited without prior consent from QRP International.

 

Partenaire de DantotsuPM
Partenaire de DantotsuPM

votre premier projet, c’est simple comme 1-2-3 avec Prince2 selon Jeff Ball

votre premier projet PRINCE2 commence par 1-2-3

Comment démarrer votre premier projet PRINCE2 en 3 étapes simples.

QRP International France
Partenaire de DantotsuPM

téléchargez le document PDF original à partir du site de QRP International

Vous avez suivi une formation PRINCE2, vous avez passé l’examen, vous êtes maintenant de retour à votre bureau, vous rouvrez le manuel de 350 pages, 19 chapitres et 26 documents …

Oui mais …. Par où commencer ?
… Simplifions les choses en 3 étapes !

1. Rédiger l’Exposé de Projet et faites-le approuver par votre exécutif

Comme son nom l’indique, l’Exposé de Projet est un document de synthèse. Il doit être facile à lire. Le manuel PRINCE2 suggère un modèle pour ce document : cependant, mieux vaut privilégier la lisibilité et la clarté plutôt que le formalisme et les détails.

L’Exposé doit contenir la structure organisationnelle du projet. Vous êtes le chef de projet, et vous avez besoin d’un Exécutif. C’est VITAL, le minimum vital. Sans Exécutif vous n’utilisez pas PRINCE2. L’Exécutif va assumer la responsabilité du projet. Vous allez exécuter en son nom le projet.

L’Exposé doit aussi contenir une description du produit du projet, votre livrable final. C’est important  de le documenter, c’est ce qui va définir votre périmètre. Le manuel PRINCE2 nous dit que c’est un document séparé mais vous pouvez l’inclure comme un paragraphe de votre Exposé.

Afin de définir correctement votre produit du projet, vous devez comprendre qui est votre client ou utilisateur (celui-ci peut être un client interne ou externe). Vous devez discuter de vos livrables avec votre client, pour comprendre leur besoin. L’Exposé de Projet doit inclure les exigences qualité du client et les critères d’acceptation.

Une fois l’Exposé rédigé, l’Exécutif doit le valider, vous ne pouvez pas continuer sans cela.

2. Créer une Structure de Décomposition du Produit et en obtenir l’approbation

Car-WBS

La structure de Décomposition du Produit (SDP) est un excellent moyen de comprendre ce qui doit être produit. Le SDP commence avec votre produit du projet, votre livrable final. Le SDP va vous donner plus de détails, 15 ou 20 livrables en tout.

Le moyen le plus simple de créer un SDP est de coller des post-it sur un tableau. Par ce biais il est facile de remodeler le SDP au fur et à mesure que les idées émergent. De manière idéale, faites-vous appuyer d’un collègue ou deux pour garantir une vision plus large. Une fois cela réalisé, convertissez les post-it en version électronique en utilisant un outil tel que Visio ou Powerpoint. C’est important de créer le SDP avant de commencer toute planification. Pour PRINCE2, le SDP est la première étape de planification.

Si vous utilisez un outil de planification, tel que MS Projet ou même Excel, vous devez créer d’abord votre SDP et la faire approuver avant de commencer le travail avec ces outils. Votre PC doit être éteint !

Vous devez passer en revue la première version avec les acteurs clés : L’Exécutif, le client ou l’utilisateur et avec les chefs d’équipe qui vont produire la solution. Une fois approuvée vous pouvez créer le plan de projet autour des 15-20 livrables de votre SDP.

3. Créer un Cas d’Affaire en collaboration avec votre Exécutif.

Le cas d’affaire fourni la justification du projet. Il explique les ressources que le projet va utiliser et les compare avec les bénéfices escomptés. C’est un document important, cela dit, il doit être simple et court. Le problème avec le Cas d’Affaire est que l’on ne sait jamais quel niveau de détail est approprié. Votre Exécutif va vous guider sur ce point. N’ajoutez pas de détails superflus (si votre société n’a pas besoin d’exprimer les besoins en termes financiers, ne le faites pas).

balance temps vs ressourcesCommencez avec un résumé de votre besoin en ressources, et les bénéfices escomptés – pour de nombreux projets, c’est suffisant.

  • Les ressources sont habituellement des personnes et/ou de l’argent. Vous devez comprendre quels types de ressources sont nécessaires. (Par exemple, vous avez besoins de développeurs et de testeurs et de l’argent pour acheter les équipements).
  • La justification se base sur les bénéfices – obtenez les informations sur les bénéfices avec votre Exécutif. Tous les deux, vous devez comprendre les types de bénéfices que votre projet va générer (par exemple, réduction des coûts de production, de maintenance).

Une fois que vous avez un résumé vous pouvez détailler davantage, seulement si nécessaire. Il faudra peut-être convertir les ressources et les bénéfices en termes financiers. Vous aurez besoin probablement d’un calendrier et aussi d’un calcul financier complexe tel que la valeur actualisée nette. En tous les cas, simplifiez toujours les choses, n’effectuez pas le travail si ce n’est pas nécessaire.

3 poissons qui sortent du commun
1,2,3…

En trois étapes simples, on a les fondements de notre DIP (Documentation d’Initialisation de Projet).

Les trois piliers clés du DIP sont : l’Exposé de Projet, le Plan de Projet et le Cas d’Affaire. Ces trois étapes nous permettent de créer ces trois piliers. Voici la manière de mettre en pratique les concepts de votre formation PRINCE2 en trois étapes simples.

© Copyright QRP International 2013. Reproduction in full or part is prohibited without prior consent from QRP International.

APMG International Showcase

PMI finance des projets académiques de recherche

pmi logoPMI will fund 2013 Research Projects

As organisations around the world are advancing their use of project management, they are increasingly seeking skilled project management employees. This search is creating a critical demand for academic research and education programmes in project management and allied disciplines.

pmi-research-conferenceAs part of its core purpose to advance the practice, science and profession of project management throughout the world in a conscious and proactive manner, PMI will fund new academic research projects at four universities in 2013 through the PMI Sponsored Research Program.

Grantees were selected based on their insight and ability to provide new knowledge that will help project managers and organisations improve performance, drive innovation and increase competitive advantage for long-term success.

This year’s call for proposals for 2014 funding will open 1 February and close 25 April 2013. For more details about eligibility criteria and submission guidelines, click here. Questions can be sent to research.program@pmi.org.