vos processus ajoutent-ils de la valeur ou contribuent-ils à un travail inutile ?

Do Your Processes Add Value or Contribute to Unnecessary Work?

http://www.pmi.org/eNews/Post/2011_06-24/processes_value_or_work.html par Ginger Levin, PMP, PgMP

Vous reconnaissez l’importance de processus réussis, répétables et fournissant régulièrement des statuts et états d’avancement.

Mais vous pouvez parfois ressentir que ces processus et rapports créent plus de travail ennuyeux qu’ils ne le méritent et répondent simplement à une demande organisationnelle.

Beaucoup d’organisations, particulièrement celles avec un bureau de management de projet (PMO), imposent certaines méthodologies qui consistent typiquement à préparer des plans et rapports à remplir. Ceux-ci incluent:

Les indispensables (bonnes pratiques)

  • Une Structure de découpage du travail (Work Breakdown Structure : WBS);
  • des références de base pour contenu, échéancier et coût;
  • un plan de management de projet; et
  • des plans de communication pour les parties prenantes

Les Facultatifs

  • Organigramme
  • Matrice d’approvisionnement
  • Analyse de marché

Cela demande du temps et des efforts que d’évaluer la méthodologie et les processus. Souvent, les personnes ne veulent pas remettre en cause une pratique qui est en place depuis longtemps même si cette pratique a rempli son utilité première. Alors, comment savoir si vous fournissez trop d’informations aux parties prenantes ? Les données que vous rassemblez régulièrement et vos rapports peuvent ne même pas être analysés, ni des actions prévues en réponse.

Comment pouvez-vous assurer que vos processus sont efficaces et ajoutent de la valeur ?

Réalisez des Enquêtes à la Fin de Chaque Projet

Engagez une tierce partie neutre pour mener une enquête à la fin de chaque projet.

Demandez à votre équipe si tous les aspects des processus prescrits ont vraiment été suivis et sinon, pourquoi.

Demandez aux clients et aux parties prenantes si le produit fini, le service ou le résultat ont satisfait à leurs exigences et sinon, voir si le problème concernait le processus.

Vérifiez combien de temps vous avez dépensé chaque semaine ou chaque mois à vous conformer aux processus.

Questionnez la valeur des processus, leur utilité et les idées d’amélioration.

Quelques personnes peuvent ne pas comprendre pourquoi le processus existe. Elles pourraient demander d’avoir une vue d’ensemble, par exemple, de comment la métrique sur le projet est utilisée par ceux qui ne sont pas dans l’équipe – et de comment mieux préparer les plans et rapports requis à l’avenir.

Revoyez les réunions de Projet et les Rapports

  • Évaluez vos réunions pour vous assurer que tous  participants qui sont là ont besoin d’y être. Chacun devrait avoir un rôle spécifique et pouvoir prendre des décisions.
  • Puis, à la fin de chaque réunion, évaluez le temps requis pour préparer et conduire la réunion, la valeur des plans d’action qui en ont résulté et les décisions qui ont été prises.
  • Pour évaluer l’utilité des rapports de projet, demandez à vos parties prenantes. Demandez s’ils lisent ces rapports.
  • L’équipe devrait aussi évaluer toutes les demandes d’informations Ad hoc comme une autre façon d’évaluer si les rapports existants adressent les préoccupations clés des parties prenantes.
  • Déterminez combien de temps est passé à préparer chaque rapport et si un modèle standard est vraiment utilisé.

Créez un Plan d’Amélioration de Processus

Après avoir évalué vos processus et rapports et identifié pourquoi ils ne fonctionnent pas ou des sujets d’amélioration, vous pouvez créer un plan d’amélioration de processus.

Ce plan décrit les changements proposés et leurs avantages. Il indique aussi comment les améliorations seront implémentées et évaluées dans l’avenir.

Ventura
Partenaire de DantotsuPM - Cliquez sur ce logo pour contacter Ventura pour vos besoins en Management de Projet et PMO

Mettez Votre Processus au Défi

En travaillant dans notre environnement mondial de projet qui est en rapide et constant mouvement, le temps doit être utilisé efficacement pour répondre aux défis et priorités stratégiques de nos organisations.

Les approches testées et vérifiées d’hier peuvent ne pas être appropriées aujourd’hui. Seuls les processus que l’on considère exemplaires devraient être poursuivis.

Les processus qui ont besoin d’amélioration devraient être améliorés et les autres qui ne sont pas utilisés devraient être arrêtés.

Revues de Projet et Alignement sur la Stratégie

Project Reviews and Alignment With Strategy Par Zenkara

Combien de fois voyons-nous de bilans de santé de projet, d’évaluations, d’audits, de revues et d’ « alcootests » business où le management loue les résultats et suspend ensuite le projet. Peut-être même avec les meilleures intentions :

  • Le management n’était pas d’accord sur les résultats des investigations
  • Ils n’avaient pas de temps d’implémenter les recommandations
  • Le budget avait tout simplement été coupé
  • Il n’y avait pas de contenu clair et accepté pour la revue/les livrables/les attentes
  • Des groupes différents ont les idées qui divergent de manière extravagante sur ce que les résultats de la revue signifient pour l’organisation
  • Peut-être l’audit a-t-il pris trop longtemps et l’organisation est déjà passée à autre chose
  • Ou plus probablement une combinaison des points susdits et d’autres

Ce qui est bien connu dans les organisations est qu’une somme d’argent phénoménale est dépensée sur ces revues – Les rapports finissent au bout du compte au placard, servent de serre-livres ou de butoirs de porte.

Au lieu de cela, nous pouvons prendre un point de vue différent et regarder comment les activités de prioritisation dirigent les efforts et comment elles abordent les problèmes sous-jacents de l’organisation.

Les projets d’amélioration consomment une portion de temps significative du personnel opérationnel. Le temps passé sur les activités d’amélioration est du temps loin du développement de produits ou de livraisons client.

Ce qui est primordial est de s’assurer que les projets qui ont le plus grand impact potentiel prennent bien le départ.

Bien sûr la prioritisation peut inclure :

  • ROI – coût réduit, productivité améliorée
  • Établir une base de lancement pour de futurs produits, business, clients
  • Ce qui peut être fait maintenant et qui est approprié au type d’évolution et à l’étape actuelle d’évolution de l’organisation
  • Déterminer si le management et les clients sont en position de piloter le changement avec des impacts acceptables sur leurs projets business actuels
  • Le changement d’amélioration ne va pas sur-compliquer le jeu déjà complexe de changements et de projets organisationnels

Dix Choses à regarder lors d’une revue de planning (d’échéancier) de projet

Dave Paradi a posté l’article en anglais traduit ci-dessous sur les 10 choses à rechercher en premier lieu si l’on vous demande de revoir la qualité d’un MS Project Plan ou échéancier/planning produit à partir d’un outil semblable de planification de projet. J’avais écrit un article sur 4 choses à faire pour construire un bon Work Breakdown Structure (WBS) que l’on retrouve ici.

Quand on vous donne un échéancier à passer en revue, voici dix choses que vous devriez regarder pour en déterminer le niveau de qualité.

1. Paramétrage du Calendrier

Si vous examinez un calendrier, vérifiez la date du prochain jour férié et voyez si des tâches sont prévues à cette date. Vérifiez aussi que le calendrier de projet ait le nombre approprié d’heures de travail par jour. Si ces deux aspects du calendrier de projet ne sont pas définis correctement, le planning du projet sera incorrect et amènera des problèmes de management du projet. Assurez-vous que le calendrier de projet est paramétré pour inclure les vacances statutaires et que le nombre d’heures de travail paramétré par jour correspond bien au nombre d’heures par jour utilisées pour l’évaluation.

2. Paramétrage des Ressources

Vérifiez la liste de tâche pour voir si les tâches ont toutes un coût associé. Le coût de tâche reflétera le coût en matériels et parfois également en personnel.

Ressources Matérielles : Demandez à voir la liste des ressources et contrôlez que chaque ressource matérielle y a un coût assigné. Si un coût n’est pas assigné à chaque ressource matérielle ou s’il manque des ressources matérielles, il devrait y avoir une autre manière en place pour suivre à la trace les dépenses de projet – demandez à voir cette méthode.
Ressources de Personnel : Pour des ressources de type personnel, il est aussi important de vérifier que le groupe dont la ressource fait partie (c’est-à-dire, le département) est identifié. Si une personne ne fait pas partie d’un groupe, il ne sera pas possible de lister les tâches par département pour sécuriser les engagements de ressources des managers fonctionnels. Ajoutez ces deux aspects à chaque ressource s’ils manquent.

3. Longueur de Tâche Trop Importante

Les tâches doivent être réduites à une taille qui permette une estimation précise de durée de tâche. Par exemple, pour un projet de plus de trois mois, une durée de tâche maximum de cinq jours permet le suivi précis à faire chaque semaine. Les problèmes peuvent alors être saisis plus tôt. Contrôlez pour voir s’il y a les tâches qui ont une durée plus longue que cinq jours. L’avancement d’une tâche avec une durée plus longue sera difficile à réaliser avec précision et peut mener à un problème significatif quand le déraillement de la tâche n’est perçu qu’à la fin de l’évaluation originale. Pour des projets de moins de trois mois de long, vous devriez rechercher des durées maximales plus courtes (trois jours pour projets de 2-3 mois, 2 jours pour projets de 1-2 mois et 8 heures pour les projets de moins d’un mois). Si vous voyez les tâches qui sont plus longues, demandez qu’elles soient découpées en sous tâches de cinq jours ou moins.

4. Manque de Liens ou Liens positionnés à un Niveau Incorrect

Un des avantages des plus grands logiciels de management de projet est la capacité de lier des tâches en elles pour montrer des dépendances successeur et prédécesseur. Cela permet au planning de projet de refléter que certaines tâches peuvent commencer seulement après que d’autres tâches soient achevées. Contrôlez que les tâches ont été liées et que les liens apparaissent seulement aux tâches de niveau le plus bas, pas les tâches de niveau regroupement. Vous serez capables d’identifier une tâche de niveau regroupement parce qu’elle a des tâches secondaires au-dessous et les tâches secondaires sont d’habitude indentées dans le planning projet. Sans liens entre les tâches, vous ne pouvez pas déterminer les dépendances et il sera très difficile de voir l’effet d’un problème qui arrive tôt dans le projet sur la date finale de projet. Les liens sur les tâches de niveau supérieures ne donnent pas assez de détail aux membres de l’équipe de projet pour voir correctement le séquençage des tâches et peuvent causer des problèmes dans le  logiciel s’il y a aussi des liens aux tâches de niveau inférieur. Assurez-vous que les liens entre tâches existent seulement au niveau le plus bas.

5. Ressources Assignées aux Tâches

Vérifiez cette chaque tâche de niveau le plus bas ait une ressource assignée et que les ressources ne sont pas assignées aux tâches de niveau de regroupement. Si les ressources ne sont pas assignées aux tâches, il sera très difficile de suivre la progression parce que vous ne saurez pas à qui demander. Si les ressources sont assignées aux tâches de niveau regroupement, le logiciel de management de projet calculera un coût double – une fois pour chaque tâche et ensuite de nouveau pour le coût des ressources de la tâche de regroupement. Assurez-vous que les ressources sont assignées seulement aux tâches de plus bas niveau dans le planning de projet.

6. Contraintes de Dates Imposées Utilisées

Vérifiez pour voir si le plan a forcé des dates de début ou de fin sur des tâches. En forçant le début ou la fin, la tâche a un jeu de contrainte de date imposée. Une contrainte de date causera des problèmes significatifs quand on essaiera de calculer le chemin critique. Pour voir si de telles contraintes existent, contrôlez si toutes les tâches ont une date de début différente et celle de fin, alors que peu ont des dépendances. Les dates devraient être calculées par le logiciel en utilisant les dépendances entre tâches et les durées de tâche. L’utilisation des contraintes de date diminue énormément l’utilité de logiciel de management de projet parce que le flux vers les tâches suivantes de données réelles des tâches précédentes s’arrêtera quand il se heurtera à une contrainte de date imposée. Supprimez ces contraintes de date et remplacez-les des liens appropriés entre tâches.

7. Ressources Surchargées

Demandez un rapport du l’allocation des ressources et cherchez les ressources qui sont prévues pour travailler plus d’heures par jour que le nombre standard d’heures dans une journée ouvrable normale. En surchargeant une ressource, il y a moins de probabilité que les tâches assignées à cette ressource soient faites à l’heure et la productivité de cette personne souffrira en conséquence. Cependant, parfois une ressource apparaît surchargée parce qu’elle a été assignée à une tâche où en fait, elle supervisera seulement une tâche qui sera réalisée par d’autres ressources. Faites des changements au planning de projet pour vous assurer que les ressources travaillent un nombre raisonnable d’heures par jour.

8. Jalons Manquants ou Non Liés dans le Planning

Pour trouver un jalon dans une liste de tâche, cherchez les tâches qui ont une durée zéro. C’est la meilleure façon d’identifier un jalon. Dans un Gantt qui donne une vue graphique, vous devriez voir des jalons comme des losanges. Les tâches jalon ayant une durée plus grande que le zéro ont été incorrectement saisies. Les jalons donnent des buts intermédiaires pour une équipe projet et sans ceux-ci l’équipe d projet risque de manquer la date de fin du projet. Les jalons sont les poteaux indicateurs qui permettent de célébrer et ré-énergiser le projet. Si les jalons ne sont pas liés dans le plan de projet, l’équipe ne saura pas comment atteindre les jalons ou quelles tâches débuter une fois qu’un jalon est atteint. De plus, il sera impossible d’identifier le chemin critique. Assurez-vous que les jalons sont correctement identifiés et liés dans le planning du projet.

9. « Décalages avec retard » (lag time) absents

Contrôlez que les temps de décalage avec retard dans le projet ont été identifiés et représentés dans le planning du projet. Un retard ou une attente se produisent  d’habitude quand l’équipe a besoin d’une approbation ou attend un renseignement. Il y a deux manières de trouver les décalages avec  retard  dans le planning. Une façon est de chercher les tâches qui disent “Attendant …” et qui ont une durée mais aucune ressource assignée. L’autre manière d’identifier un retard est de regarder le champ prédécesseur. Il donnera le numéro de la tâche précédente et ensuite “+ x jours” pour montrer le temps de retard. Si ces décalages ne sont pas dans le plan, l’échéancier sera par trop optimiste et l’équipe devra s’accommoder de plus de changement de planning que  nécessaire. Les décalages avec retard permettent aussi à l’équipe de projet de faire un suivi des items qu’ils attendent et de garder le projet sur les rails. Assurez-vous que vous identifiez les décalages avec retard et leurs liens dans le planning du projet.

10.  Le suivi ne permet pas de prédire le futur

Quand un projet est déjà commencé, vérifiez pour voir si le suivi des données réelles prévoit comment le projet évoluera. Si la méthode de suivi de complétude par pourcentages est utilisée, elle suppose que toutes les évaluations de durée de tâches originales sont correctes, ce qui d’habitude n’est pas vrai. Vous pouvez dire si cette méthode est utilisée si vous voyez que toutes les dates de fin prévues sont égales aux dates de prévision initiale bien que le projet ne soit pas parfaitement dans les temps. L’équipe de projet devrait, toutes les semaines, capturer le coût/travail réel pour chaque tâche, comparer cela avec leur estimation de départ  et recalculer le reste à faire coût/travail de chaque tâche. Le planning de projet devrait inclure des colonnes pour les dates de prévision initiale de début et de fin ainsi que les dates réelles ou re-planifiées. Cela donne à l’équipe projet une meilleure prédiction de quand chaque tâche sera en réalité complète. Le logiciel de management de projet utilise alors ces dates prévues d’achèvement pour calculer l’impact sur les tâches futures, mettant à jour le début prévu et les dates de fin des tâches suivantes. Vérifiez la méthode de suivi pour vous assurer qu’elle permet de prévoir l’état futur du projet.

En vérifiant ces dix aspects, vous pouvez vous assurer que le planning de projet va plus probablement amener à un projet réussi.

Audits de projet

J’ai publié il y a quelques mois un article sur le bien-fondé des audits de projet. Voici un complément apporté par Dave Nielsen qui détaille une approche de réalisation d’un audit de management de projet.

L’article original en Anglais: http://www.pmhut.com/project-audits.

Je me suis personnellement aligné sur les 9 domaines de connaissance définis par PMI et les procédures internes de mon entreprise pour les quelques audits qu’il m’a été donné de réaliser en matière de management de projet.

La plupart des processus utilisés dans vos organisations sont audités et il devrait en être de même de vos processus de management de projet. Il est aussi important de réaliser des audits de vos projets que de vos processus d’assurance qualité. Le PMBOK décrit l’audit comme “une revue indépendante structurée pour déterminer si des activités de projet observent les règles et procédures organisationnelles et de projet.” Il existe beaucoup de vues différentes et d’approches aux audits de projet mais nous allons coller à l’approche du PMBOK dans cet article. Cette approche reprend l’approche utilisée pour des audits financiers où les auditeurs viennent d’une société contractée dans ce but. Il est possible de faire venir des auditeurs de l’extérieur pour exécuter votre audit de projet, il est aussi possible d’identifier et de former des auditeurs en interne. Si votre organisation se vante d’avoir un Project Management Office (PMO), ou un Centre de Management de Projet (PMC), ce groupe devrait fournir le service.

Gardez à l’esprit l’objectif de l’audit en exécutant votre audit de projet. L’objectif n’est pas de déterminer la santé du projet, ou identifier les actions correctives qui amélioreront la performance de projet, mais de déterminer si le projet est managé correctement. Un audit de projet peut être exécuté pendant le cycle de vie de projet, ou après que le projet ait été achevé. Un audit à mi-projet présente l’avantage de pouvoir potentiellement corriger des erreurs de management sur le projet vérifié tandis qu’un audit à la fin du projet n’aidera pas le projet actuel mais les points d’audit profiteront au cycle de vie complet de futurs projets.

L’audit devrait commencer par les standards ou directives qui ont été établis pour les projets entrepris par l’organisation. Ceux-ci peuvent être établis par un PMO ou PMC, ou par l’organisation. Un examen des processus documentés et des plans du projet vous dira si les standards sont atteints et les directives suivies. L’auditeur devrait aussi examiner à quel point le projet suit bien les plans de projet et les processus.

Le Rapport

Le livrable de l’audit de projet devrait être un rapport d’audit qui capture toutes les observations de l’audit. Le rapport devrait capturer chaque point de l’audit. Chaque point devrait être uniquement identifié et la description du point, les recommandations pour la correction et le degré de sévérité devraient accompagner le point. Le degré de sévérité pourrait être une note sur une échelle de 1 à 10, ou un indicateur comme (F) aible, (M) oyen, (H) aut, ou (E) rreur, (A) mélioration, ou (S) uggestion. Le rapport devrait aussi avoir une section « commentaires » où vos observations générales sur le projet seront notées. On peut faire appel à vous pour donner au projet un ok ou échec et dans ce cas vous devez clairement capturer les critères pour de réussite ou d’échec. Rendez la décision de passage ou échec dépendante du score total par rapport à un point de référence si vous utilisez des scores numériques pour les points d’audit. Rendez le passage ou échec dépendant d’un nombre maximal d’Erreurs si cette approche est utilisée. Les critères de passage ou échec devraient être convenus avec les personnes mandatant l’audit et être clairement expliqués dans votre rapport. Ce rapport est ce que vous présenterez aux commanditaires qui ont donné pouvoir à l’audit et au chef de projet.

Démarrage

Le chef de projet pour le projet vérifié devrait être engagé dès le début. Cela ne devrait pas être un processus antagoniste, les résultats de l’audit ne devraient pas être utilisés pour punir le chef de projet à moins qu’il/elle n’ait délibérément violé des standards ou directives. L’audit devrait être utilisé comme une occasion d’apprendre et le chef de projet devrait faciliter l’accès de l’auditeur à toute la documentation de projet qu’il demande. Commencez l’audit par une réunion avec le chef de projet et le sponsor et expliquez clairement le but de l’audit (améliorer la performance en management de projet dans l’organisation) et comment l’audit sera exécuté. Détaillez ce que vous attendez du chef de projet, ce que l’audit produira (le rapport d’audit) et comment cela sera partagé.

La première étape de l’auditeur est d’identifier tous les processus et les procédures qui devraient diriger le management du projet. Ces informations devraient être disponibles auprès du PMO, PMC, ou chef de projet. Le premier document à passer en revue sera la Charte de Projet, l’Énoncé des travaux (SOW), ou l’énoncé préliminaire du contenu. Ce document devrait vous fournir une vue d’ensemble des livrables principaux et des jalons agréés pour le projet. La Charte de Projet devrait aussi vous expliquer l’approche que le chef de projet a l’intention d’utiliser pour atteindre les objectifs de la charte. Ces informations devraient être utilisées comme un benchmark pour mesurer l’efficacité des processus et des procédures de management de projet. Supportent-ils la livraison de l’objectif à ou avant la date prévue? Une absence de charte ou d’énoncé des travaux devrait être notée; tout projet devrait avoir l’un ou l’autre, ou les deux avant de démarrer à moins qu’un autre document ne le remplace.

WBS et échéancier

La structure de découpage du projet (Work Breakdown Structure: WBS) et l’échéancier sont inclus dans cette section à cause de la prédominance de MS Project, qui combine ces 2 plans. MS Project n’est en aucun cas le seul outil disponible pour exécuter ces fonctions mais il est devenu si répandu que nous assumerons que c’est l’outil utilisé pour le projet audité.

Les livrables principaux de la Charte de Projet devraient être saisis dans le WBS/Échéancier et le travail devrait être décomposé en partant de ceux-ci. Les jalons clefs devraient aussi être capturés dans le fichier MS Project. Si le projet est dirigé par un énoncé des travaux (SOW) plutôt que, ou en plus de, une charte, les produits et les jalons du SOW devraient être les lignes de haut niveau de l’échéancier. Quand vous identifiez des livrables ou jalons manquants, vérifiez avec le chef de projet pour déterminer s’ils sont représentés par une ligne différente. Fréquemment la terminologie est abrégée dans ces documents à un tel point que le livrable ou jalon dont ils ont été tirés sont méconnaissables. Vérifiez les jalons manquants de la même manière. Notez tout livrable ou jalon qui aurait été manqué dans le fichier MS Project.

Il se peut que la planification détaillée du projet entier ne soit pas présente dans MS Project si l’audit est exécuté au milieu du projet et que le projet est géré utilisant une approche « rolling wave” (incrémentale) ou itérative (cela devrait être noté dans la Charte de Projet ou le SOW). Utilisez votre propre jugement pour déterminer l’état de perfection du fichier MS Project. Le travail pour l’itération ou la phase suivante doit être planifié avant la revue de jalon précédente, mais combien à l’avance reste à la discrétion du chef de projet.

Les travaux prévus doivent avoir des dates début et de fin et devrait avoir une personne, ou plusieurs, assignée à chaque tâche. Ils peuvent avoir des prédécesseurs, des décalages avec avance ou retard, et un certain nombre d’autres attributs supportés par MS Project. Les tâches dans le fichier MS Project auxquelles personne ne serait assigné devraient être passées en revue avec le chef de projet et notées si aucune personne n’a été assignée. Le fichier MS Project devrait être tenu à jour. Le travail qui est achevé devrait être marqué comme 100 % complet dans le fichier et le travail qui est partiellement complété devrait avoir son degré de complétude enregistré. Cherchez les dates de début manquées, celles-ci sont des dates dans le passé avec une complétude de 0 %. Les tâches avec des dates de début manquées devraient être reprogrammées avec nouveau début et fin prévisionnels. Notez que le fichier MS Project peut ne pas être préparé pour capturer les dates initiales prévues et re-planifiées. Les tâches avec des dates finales manquées devraient aussi être passées en revue. Toute tâche dont la fin est dans le passé est qui est à moins de 100 % complète devrait être passée en revue avec le chef de projet pour déterminer si la tâche est 100 % complète et simplement non mise à jour dans MS Project, ou si le PM n’a pas mis à jour MS Project. Le fichier MS Project ne sera jamais complètement à jour pour le projet, mais cela ne devrait pas être périmé de plus d’un jour ou deux. Une surabondance d’informations périmées dans MS Project devrait être notée dans votre rapport.

Revues de Jalon

Ceux-ci peuvent être appelés autrement par l’organisation comme revue de « Sortie de phase », Points de Décision Business, Points de « Go/No Go ». Chacun de ceux que le projet a passés devrait être accompagné par des documents. Voici une liste de ceux qui peuvent être produits :

  • Une liste de critères pour passer le jalon
  • La décision de jalon
  • Une liste de participants à la réunion
  • Une liste de décideurs
  • Le processus pour atteindre une décision
  • Un passage ou un échec pour chaque critère de passage
  • La décision
  • Actions assignées pendant la réunion et leur statut

Chaque revue de jalon devrait avoir, au minimum, une liste des critères, si chacun a passé ou a échoué et une copie de la décision. N’importe quels critères qui ont échoué devraient avoir une action corrective. Ces actions devraient être capturées dans un Registre d’Action ou un Registre des Problèmes, avec les autres actions identifiées pendant la réunion. Le chef de projet peut avoir utilisé un registre séparé ou un journal pour suivre ces actions, ou il peut avoir utilisé le journal du projet ou le registre mais les actions liées au jalon devraient être identifiées avec celui-ci. Les actions qui ne sont pas fermées devraient avoir date prévisionnelle proche dans l’avenir. Notez celles pour lesquelles ce n’est pas le cas et passez-les en revue avec le chef de projet. Les actions qui ont été négligées devraient être notées.

Le jalon de fin de projet devrait être accompagné par une lettre ou un courrier électronique d’acceptation du client. Cette acceptation peut arriver pendant la Réunion de Revue de jalon Quand le projet est destiné à un client interne, par exemple quand l’organisation informatique crée un système financier pour le département Finance, l’acceptation du système par l’organisation de support devrait être clairement exprimée dans la communication de passage de jalon.

Plans de Projet

Le chef de projet peut avoir capturé tous les plans pour le projet dans un document, ou il peut les avoir capturés dans plusieurs documents. Les secteurs du projet qui peuvent être planifiés sont :

  • Changement
  • Communications
  • Coût
  • Ressources Humaines
  • Approvisionnement
  • Qualité
  • Risque
  • Portée ou Exigences

Ces plans devraient être passés en revue pour déterminer le degré de suivi de l’approche décrite dans la Charte de Projet. Les contradictions entre n’importe lequel de ces plans et l’approche prévue devraient être passées en revue avec le chef de projet. Revoyez les plans en fonction des actions qu’ils nécessitent et comparez ensuite ces actions au ficher MS Project. Les actions ont-elles été capturées dans des tâches de ce fichier ? Par exemple, quand le Plan de gestion des risques nécessite une session de travail pour identifier et évaluer quantitativement les risques pendant la phase de planification du projet, cette session a-t-elle été prévue ? Si Oui, a-t-elle été tenue et le fichier l’indique-t-il à 100 % complète ? Le travail devrait être prévu dans MS Project pour toutes les actions exigées par les plans. Passez en revue les actions qui ne sont pas supportées par des tâches planifiées avec le chef de projet et notez les manques.

Registre des Changements / Requêtes de Changement

La plupart des projets auront un processus qui gouverne comment les modifications demandées au projet sont gérées et de plus ils devraient avoir un registre pour inscrire les changements demandés. Les projets qui ne sont pas supportés par un registre de changement auront un archivage des demandes. Le registre et les demandes de changement individuelles devraient indiquer la nature du changement, une justification business pour le changement, la date à laquelle la requête a été reçue, la solution proposée, l’impact du changement sur le budget, l’échéancier, la qualité et les objectifs de portée, si la requête a été approuvée ou rejetée, qui a pris la décision et une date de mise en œuvre projetée pour les requêtes de changement approuvées. Les demandes de changement devraient aussi être accompagnées par les communications mentionnées dans le Plan de Gestion de Changement. Vérifiez que chaque requête a été accompagnée par la communication appropriée et notez celles qui ne l’étaient pas. Le suivi papier pour des requêtes de changement rejetées s’arrêtera ici.

Les requêtes de changement qui ont été approuvées peuvent ou pas changer une des 4 références de base du projet. Les requêtes de changement qui ne changent aucune de ces références de base peuvent être ignorées par l’audit. Toute requête de changement qui appelle un changement à une ou plus des références de base affectera aussi un ou plusieurs des plans : MS Project (échéancier, le nouveau travail, le travail changé, le travail supprimé), le Management de la Communication (des communications nouvelles, changées ou supprimées), la Gestion de Coût (le budget), des Ressources Humaines (des équipiers supplémentaires, des équipiers en moins), l’Approvisionnement (un changement dans le travail externalisé ou sur la liste de vendeurs), la Gestion des Exigences (ajouté, changé, ou supprimé des exigences) et la Gestion des risques (un changement aux risques gérés par le projet). Un changement qui a changé n’importe laquelle des références de base devrait être reflété par un changement dans un ou plusieurs des plans et une nouvelle référence des bases du projet. Tout changement qui devrait avoir déclenché un changement aux plans et aux références de base et ne l’a pas fait devrait être passé en revue avec le chef de projet.

Registre des Risques

Les risques devraient être capturés et gérés utilisant un registre. Les informations suivantes peuvent y être capturées:

  • Une description du risque
  • Si le risque est accepté ou atténué
  • Comment le risque sera atténué (s’il doit être atténué)
  • L’action ou les actions requises pour réduction
  • Les plans d’urgence pour adresser les conséquences de la matérialisation du risque
  • identifiant MS Project de l’action
  • Statut du risque

Examinez le Registre des risques , déterminez si c’est à jour par rapport au projet ou pas. Les risques devraient être passés en revue périodiquement (en conformité avec le plan de Gestion des risques et l’échéancier du projet), de nouveaux risques identifiés, des risques obsolètes fermés et leurs statuts mis à jour. Vérifiez le registre par rapport au plan de Gestion des risques et déterminez si les activités prévues ont bien eu lieu. Vérifiez le travail dans MS Project si le registre s’y réfère pour vous assurer que les actions requises par le Registre de Risque ont été complétées. Passez en revue toute contradiction avec le chef de projet.

Registre d’Actions et Registre des Problèmes

Les problèmes et les actions qui arrivent partout dans le projet devraient être capturés et suivis à la trace dans un registre d’action ou registre des problèmes. Ces documents devraient vous donner la nature du problème, l’action identifiée pour l’adresser, la personne responsable de l’action et la date d’achèvement prévue de l’action. Passez en revue les registres pour vérifier que toutes les actions ont été complétées si vous exécutez l’audit de fin du projet, ou que les actions prévues avant la date d’aujourd’hui ont été complétées dans le cas où l’audit arrive pendant le projet. Passez en revue chaque dérapage des actions avec le chef de projet pour déterminer si l’action n’a pas été complétée ou si elle a été complétée et le registre pas mis à jour. Ces documents devraient être tenus à jour, aussi, s’ils sont plus d’une semaine de retard vous devriez prendre note de ce fait.

Élaboration du Rapport

Les points d’audit qui ont été enregistrés pendant le cours de l’audit devraient être mentionnés au rapport. Une description du point d’audit devrait être capturée avec les informations décrites dans la section de Rapport de cet article. Utilisez votre jugement en assignant une évaluation de sévérité au point. Vous devriez avoir quelques critères à l’esprit pour une évaluation numérique – ce qui constitue un 10, un 8, un 1, etc. Les points que vous identifiez comme des erreurs devront être corrigés dès que possible si l’audit était exécuté en cours de projet, ou pour le projet suivant. Les Erreurs, les Améliorations et les Suggestions devraient être accompagnées d’une description de l’action qui corrigerait ou améliorerait la performance de management de projet.

Vos commentaires devraient capturer vos observations d’ensemble du projet et toutes les suggestions pour l’amélioration. Il est maintenant le temps d’évaluer la performance du chef de projet sur l’aspect de garder ses plans à jour. Vous pouvez vouloir identifier un point séparé d’audit pour couvrir cet aspect, ou mettre simplement le commentaire dans la section « commentaires » de votre rapport. Les projets où les plans et les échéanciers ne sont pas à jour devraient amener une suggestion d’amélioration.

Demandez aux commanditaires de l’audit s’ils souhaitent que vous partagiez le rapport avec le chef de projet avant de le présenter. Cela semble être une bonne idée dans le cas d’un audit exécuté en interne. L’avantage de cette approche est que s’il y a des erreurs dans votre rapport, elles peuvent être corrigées. Cette approche permettra aussi d’éviter que le chef de projet ait la sensation de tomber dans une embuscade. Un rapport négatif ne va pas être bien reçu par le chef de projet en charge, mais des recommandations appropriées peuvent le rendre plus acceptable. Par exemple, là où il y a des points d’audit suggérant l’inexpérience, ou le manque de formation de la part du chef de projet, suggérez du coaching, du mentoring, ou de la formation. Suggérez un cours PMP, ou autre formation là où l’audit le justifie. La certification de chefs de projet est une étape que les organisations peuvent prendre pour améliorer la performance des chefs de projet et il y a quelques excellents produits de formation disponibles à très faible coût.

Sauvetage d’un Projet : Le Diagnostic

Voici un nouvel article qui mérite attention si l’on se voit chargé de remettre un projet sur les rails.

Article original en anglais de Joanne Wortman: http://www.pmhut.com/rescuing-a-project-diagnosis

Joanne nous dit: J’ai déjà parlé de triage de portefeuille de projet. Le résultat de l’effort de triage est d’identifier ces projets le plus dans le besoin d’intervention immédiate. De même que dans le monde médical, l’étape suivante après le triage est le diagnostic; il est maintenant temps de se concentrer sur les projets du troisième groupe et exécuter un diagnostic de projet. Si vous êtes assigné au sauvetage d’un projet en échec, voici les premières étapes pour trouver la cause ou les causes premières des difficultés du projet.

1. Obtenez un historique minutieux du patient : les diagnosticiens médicaux qualifiés ne peuvent pas compter seulement sur les souvenirs du patient. Dans certains cas ils doivent interviewer la famille et des amis pour obtenir des informations sur des symptômes subtils. En essayant de diagnostiquer des projets en échec, vous ne devriez pas compter seulement sur les entretiens directs avec l’équipe de projet. Une vue multi-perspectives de la situation est nécessaire :

  • Ayez une session à l’abri des indiscrets avec le sponsor du projet : Découvrez quels sont les problèmes-clés sur le projet et commencez à explorer des secteurs où une redéfinition du contenu ou du périmètre pourrait aider à remettre les choses sur les rails. Découvrez quelles réductions de portée vont probablement être acceptés par le business et celles qui pourraient exiger un effort de vente significatif ou une féroce bataille. Comprenez la politique de l’organisation pour que vous puissiez l’intégrer dans votre plan d’actions correctives.
  • Parlez aux parties prenantes  du projet de leurs attentes originales, leurs soucis actuels et toute difficulté qu’ils peuvent avoir avec l’équipe de projet.
  • Créez des canaux de communication confortables avec tous les membres de l’équipe de projet et creusez plus profond que les plans de projet, les rapports de progrès et les registres de problèmes. Découvrez ce qui cause de l’inquiétude dans l’équipe projet. Il y a souvent des indices de valeur à découvrir. Assurez-vous de bien explorer tous les secteurs qui seraient dissimulés ou rejetés trop rapidement.

2. Prenez les signes vitaux du projet :

  • Vérifiez le pouls : Évaluez le taux de dépense des ressources. Consommez-vous le budget plus rapidement que prévu ? Quel est le nouveau coût total estimé ?
  • Tension artérielle : Exécutez une évaluation de risque, en termes de ce qui pourrait arriver entre maintenant et la date de livraison qui aurait un impact significatif. Des approches diverses existent pour conduire cette évaluation. Le modèle Six Sigma FMEA (Failure Mode and Effect Analysis) peut être adapté pour répondre à vos besoins, vous donnant une structure objective pour évaluer tous les endroits possibles où votre solution pourrait échouer et centrer vos actions correctives futures sur celles qui ont à la fois la probabilité la plus haute d’occurrence et la criticité la plus importante.
  • Température : Créez une feuille de température (rouge orange vert) en ce qui concerne les jalons clefs. Cela devrait faire partie de votre rapport de statut régulier, avec une analyse des tendances de base.
  • D’autres tests diagnostiques spécialisés selon nécessité – Évaluez la portée (l’originale et l’actuelle), passez en revue la stratégie technologique, la stratégie de développement, la stratégie de test, la stratégie de livraison et celle de gestion des modifications.

Après l’exécution de ces étapes, vous devriez avoir une meilleure compréhension des raisons pour lesquelles le projet est sorti des rails.

I want my project to be audited!

bad auditorDoes this title sound odd to you? Are you like many PMs trying to escape audits as much as possible? Do you consider them as a waste of time at best and a potential killer in extreme cases?

I did also share these feelings but it does not need to be this way. Audits are very worthwhile, and can be productive and of real benefit to you and your project.

I suggest starting from the inception: who has requested the audit? why? who are the auditors? what is the scope?

I found with experience that finding the answer to the latter of these questions, i.e. scope of the audit, will often shed light on the others. Indeed, once shared and understood, the scope will highlight several areas of investigations and review. It could be the project management practice, the costs, the quality of deliverables, the security, the progress against schedule, the details of the project plan or any combination of these and more.

With a little bit of thinking and discussions with the auditors, it should become clear why this audit and who has requested it. Also, the type of auditors you get, internal versus external, large consulting firms versus specialized players, will tell a lot about the importance granted to the audit and its aim.

0002For example, we were audited during an Enterprise Resource Planning (ERP) system construction and deployment. It was an internal audit. Once we understood that the focus was essentially to ensure that we were in control of project spend and managing the risks correctly, it was easy for the team to provide clear evidence of what we were doing in these areas. We showed our expenses tracking process, time tracking method, issues log and risk register. The Chief Finance Officer was reassured by the findings. Additionally, the auditors helped us to further highlight our top risks to the steering committee during a specific risk management brainstorming and review session with them.

Next suggestion is to learn about the process that the auditors plan to follow. It’s important to understand their approach to better prepare the team for this event that they may initially perceive negatively. Usually, it starts with a few interviews of key project team members and stakeholders, eventually preceded by some documentation request and analysis. The next step often involves further interviews to deep dive into specific areas.

An experience I had about the importance of the above was on a IT project where we were in deep trouble during deployment. As a young PM, I did not have the experience or clout to « manage » the auditor (an external one in this instance). He came in and ran his show without explaining the process to anybody. He made negative comments quite early on. The team became very concerned and somewhat defensive. People provided all materials requested but in a rather unstructured way. There was no overall framework/story around the raw data. The audit took long and was very frustrating for all. In the end, the report did not help the project through its difficult times. In this specific instance, an audit, that could have brought value, ended up killing the project and I still have bad feelings about this useful but painful experience.

meetingYou should also consider that the auditors will most certainly have some checkpoints with management and audit sponsors. They will share their progress at these sessions, expose findings, test the water on initial ideas (to see potential reactions), and at a later stage present recommendations (draft and final).

Last year, I was the lead for the audit of an internal application. As I had been several times on the receiving end of audits, I placed specific focus in this instance on explaining the milestones and approach for the audit. We explained the scope and who would do what. We shared the findings with the team as they became available to avoid surprises. We gave them the opportunity to comment (which they did and we took their input into account). checklistWe shared our recommendations with the project team before management and also helped define and put in place action plans to address the identified issues. We even followed up after the audit on execution of these action plans. This, I am sure, was much more beneficial to the company than a one-off report.

Whatever the scenario, the key for the PM is to actively support the auditors throughout their investigations. We shall provide all relevant information in full transparency and ask our team members to do the same. We shall also make time for them in our busy agendas. We want to be valuable and positive contributors. As we do so, we may gain the privilege to be involved in the preparation of the documents and sessions for management. It could be limited to validate the correctness of facts but that is already very worthwhile. It could be to understand what they will highlight up to discussing some of their draft recommendations.

In my PM role, when asked by the auditors about my expectations of the audit, I highlight 2 items:

  1. Get valuable recommendations to improve the project
  2. Fairness towards team members.

Next stage is when the audit reaches completion and produces its recommendations. Unavoidably, there will be some you agree with or can understand. There will be others that are tougher to accept. In any case, it is absolutely critical to remain positive and open. Moving into defensive mode will never help. Also, keep in mind that  consultants/auditors recommendations are one thing; which of these recommendations management will decide to act upon is something else (that is more critical to you and your project) .

As soon as you understand which corrective or improvement actions are retained, share these with the team in a positive manner. In my experience, it is often the case that the auditors report is not shared; only highlights of the reports are presented that foster the team towards productive actions.

external eyeAs a conclusion, I suggest that if your project is not yet being audited, you consider which areas could be improved using external advice and eventually solicit an audit on these: Get help before someone above you decides that you need to be helped.

On many projects, you will find that auditors will greatly help you to firm up some aspects such as scope control, change management rigor or raising the involvement of your project sponsors in risk mitigation. They look at your project with an external and therefore more objective than you ever can be.