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.

2 réflexions sur “Audits de projet

  1. Ping : audits et projets en difficultés sur le blog du management de projet « DantotsuPM.com

  2. Ping : Quels principes suivez-vous lors d’une revue de projet ? | DantotsuPM.com

n'hésitez pas à commenter les billets et à partager vos idées.

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.