les sources de risques cachés dans les projets

Sources of Hidden Risks in the Projects

http://www.pmhut.com/sources-of-hidden-risks-in-the-projects par Girish Deshpande

Les risques sont inévitables dans tous les projets. On ne peut pas éviter tous les risques et espérer une exécution de projet sans heurts. Vous pouvez seulement accepter ce fait et vous préparer pour les risques imminents. Souvent les risques sont bien cachés et enfouis dans des endroits peu probables (vu de l’équipe projet).

idée : check-list des domaines de risqueLes chefs de projet cherchent des risques dans des emplacements connus ou dépendent totalement de leur expérience antérieure lors de l’identification des risques potentiels dans leur projet. Leur registre de risque s’améliore comme ils acquièrent davantage d’expériences plus diverses. Mais cette éducation est extrêmement coûteuse pour le projet et le sponsor de projet. La rigueur dans l’exploration systématique des risques dans des secteurs connus de problème doit être accomplie avec rigueur dans tout projet. Une telle exploration devrait être systématique et devrait être faite en utilisant une liste de contrôle. Nous ne pouvons pas laisser cet aspect critique à la seule mémoire du chef de projet. Et une telle liste de contrôle devrait vivre et devrait être mise à jour quand de nouveaux faits ou connaissances sont rendus disponibles lors de l’exécution de nombreux projets.

Ci-dessous sont listés certains des secteurs qui doivent être explorés (ou au moins visités) pour vérifier si des risques s’y cachent.

1. Les risques liés à la portée (au périmètre)

Le contenu du projet dérive parce que les besoins de projet ne sont pas clairement définis. Les critères de performance sont-ils bien définis ? Toutes les conditions de bornage sont-elles définies ? Où votre travail commence-t-il et s’arrête-t-il ? Avez-vous défini les responsabilités de chaque partie prenante dans les phases différentes du projet ? Avez-vous défini et expliqué le processus de management des changements dans la déclaration de travail (Statement Of Work : SOW) ?

2. Les risques liés à l’échéancier et aux estimations d’efforts

estimatingLa dérive de contenu est le risque majeur pour l’échéancier et les coûts mais des évaluations de mauvaise qualité sont aussi un facteur significatif. Le manque d’expérience antérieure et/ou d’expertise sur le sujet, le manque de revues et de vérifications adéquates sont les causes de ces évaluations imprécises. Cela rapporte d’être pessimiste et paranoïaque quand on parle des estimations du projet. L’optimisme est souvent mortel.

3. Les risques dans les assomptions

Les assomptions de projet sont-elles clairement définies dans la déclaration de travail (SOW) ? Couvrent-elles tous les aspects et les phases importantes du projet ? Avez-vous documenté le recours qui sera entrepris si une supposition est prouvée fausse et se métamorphose en risque projet ? Votre client/sponsor a-t-il passé en revue et été d’accord avec vos suppositions et plans d’action pour chacune ? Idéalement toutes les suppositions devraient être listées et revisitées dans chaque rapport d’avancement et revue de projet.

4. Les risques liés aux dépendances

Le projet est dépendant de nombreuses parties prenantes. Par exemple, client/sponsor, vendeurs, sous-traitants, agences externes etc. Il existe des risques associés à chaque dépendance. Avez-vous clairement documenté toutes les dépendances dans votre déclaration de travail ? Avez-vous listé les livrables de chacun ? Avez-vous précisé le moment où ils devraient livrer leur part de l’engagement ? Et avez-vous mentionné quelle est le plan si le risque se matérialise quand l’engagement n’est pas respecté par la partie prenante ? Idéalement toutes les dépendances devraient être inscrites et revisitées dans chaque rapport d’avancement et revue de projet. Quelques exemples de tels risques sont : des retards fournisseurs, des problèmes de visa, des problèmes de sous-traitance, des retards clients, des retards d’expédition, des retards douaniers etc.

dépendances5. Les risques liés aux contraintes

Presque tous les projets ont certaines contraintes et il y a peu ou pas de projet sans contraintes. L’exemple d’une telle contrainte (dans les projets informatiques) pourrait être … une mémoire limitée ou la puissance du processeur, le coût des composants et matières premières pour réaliser le livrable, des échéances serrées, la nécessité de s’interfacer avec certains produits propriétaires, la nécessité de conserver de vieux modules, le manque de documentation dans un projet de migration, des années de support et garantie pour le produit etc.

6. Les risques liés à la technologie

Circuit BoardLa technologie choisie peut poser des risques selon ses limitations. C’est particulièrement vrai si la technologie est non prouvée ou mal supportée au cas où vous auriez besoin d’assistance technique. La limitation technologique peut aussi causer une impossibilité d’interopérabilité avec d’autres systèmes dans le futur. Cette même technologie peut poser problème si vous êtes scotchés sur la version précédente alors que le vendeur s’est déplacé à une version plus récente. L’obsolescence des pièces détachées est un risque majeur dans le développement de circuits intégrés électroniques, particulièrement si vous devez supporter ces produits sur le terrain pendant de nombreuses années. C’est vrai pour bien des produits industriels et du domaine de l’Énergie.

7. Les risques liés aux critères d’acceptation

Des critères vagues ou mal définis d’acceptation dans le contrat sont une cause majeure de soucis pour le chef de projet. C’est aussi l’aspect le plus difficile à bien fixer dans la première étape du projet quand la déclaration de travail est signée. Si le plan de tests de recette est défini au préalable, il peut donner ces critères, mais si un tel plan n’est pas disponible alors vous devez rapidement le préparer dès que les besoins sont gelés et l’architecture de haut niveau faite. Dans quelques projets cette question importante n’est pas adressée jusqu’à tard dans le projet. Cela laisse le projet exposé à un risque inacceptable.

8. Les risques réglementaires

L’équipe projet doit soigneusement évaluer le régulateur et les besoins de certification pour leur livrable et en évaluer l’impact sur la dotation en personnel, la conception de produit, l’échéancier de projet et les coûts. Si l’équipe projet n’a pas traité l’aspect certification du projet, cela devrait être traité comme un gros risque et suivi régulièrement. De tels risques ont un impact très élevé dans les projets. Ils ont un impact tant sur le coût de projet que le temps et peuvent impacter sévèrement le client/sponsor et leur satisfaction.

9. Les risques liés aux personnes

chaise videCela inclut les démissions et départs, le manque de compétences, l’expérience, le moral, les engagements, les relations dans l’équipe etc.

10. Les risques liés aux compétences et expertises

La disponibilité d’expert de sujet (Subject Matter Extert : SME) peut être un besoin important dans bien des projets. Cette expertise peut être sur le domaine industriel ou la technologie. Le projet peut avoir besoin de tels experts pour concevoir un système qui soit fiable, pour passer des tests de certification et satisfaire aux besoins de l’utilisateur final. Si une telle connaissance spécialisée est nécessaire alors se développent une dépendance et un risque associés. Le départ d’un tel SME peut déstabiliser le projet. Il est aussi possible qu’il n’y ait personne d’autre dans l’organisation pour évaluer la qualité du travail fait par le SME.

11. Risques politiques

organigrammeNous ne pouvons oublier cet aspect important dans aucun projet. Ce projet a-t-il le support des constituantes importantes dans l’organisation ? Le sponsor de projet a-t-il un support et un budget adéquats de la direction ? Qui sera impacté par ce projet ? Et leur coopération est-elle nécessaire pendant l’exécution ? Quelle précaution devrait être prise si une partie prenante importante dans l’organisation client refuse de coopérer ? Qui le client contactera-t-il s’il veut générer une escalade ? Avez-vous dépeint aussi bien l’organisation de l’équipe projet que l’organigramme approprié dans l’organisation client dans la déclaration de travail ? Y-a-t-il un point unique de contact (Single Point of Contact : SPOC) des deux côtés ? La matrice d’escalade est-il définie en dehors de ces deux personnes dans les organisations respectives ?

12. Risques liés à la propriété intellectuelle (IP)

Comme dans la bataille Apple contre Samsung sur la violation IP montre que cela peut devenir risqué si non pris en compte dès le départ. Si vous utilisez des composants de code en Open Source, vous devez évaluer leur impact. Devez-vous publier une partie de votre travail auprès de la communauté Open Source? Est-ce acceptable ? Faites vérifier, avec l’aide de conseils en propriété industrielle et intellectuelle bien sûr, que votre conception n’empiète pas sur un quelconque brevet et droits IP ?

13. Les risques liés à la garantie

Des contrats différents ont des clauses différentes de garantie. Le plan de projet doit prendre en considération les termes de garantie définis pour ce projet et planifier en fonction. Des clauses de garantie devraient idéalement décrire quel genre du support l’on fournira au client/sponsor pendant la phase de garantie. Il n’est pas inhabituel de voir des clauses de garantie pluriannuelles et elles posent de grands risques. Comment conservez-vous la connaissance et l’équipe pendant cette période où vous devrez respecter les engagements ? Comment conservez-vous les licences pour les outils pendant cette période ? Comment traitez-vous l’obsolescence d’outils et équipements essentiels?

14. Les risques liés aux pénalités

keeping moneyBeaucoup de contrats incluent une clause de pénalité sur la performance de l’équipe projet. La pénalité peut porter sur la conception si le projet est retardé au-delà d’une date limite ou si le produit livré est de mauvaise qualité. Votre estimation initiale devrait prendre en compte de telles pénalités potentielles. Vous pouvez vouloir tenir compte de cette perte possible de revenu dans votre évaluation (une marge supplémentaire).

15. Les risques liés à la qualité

Qu’est-ce qui pourrait mal tourner en termes de qualité du produit ? Les exemples de mauvaise qualité sont la performance, difficulté d’utilisation, produit mal conçu, pauvre fiabilité etc. Cela aide de définir les paramètres critiques à la qualité  (Critical To Quality : CTQ) pour le produit très tôt pendant la définition du contenu et mesurer ensuite la qualité de produit envers ces critères.

16. Les risques liés au marché

Vous avez construit le produit mais le marché peut présenter des risques significatifs si le produit a de mauvaises  fonctionnalités, une piètre qualité, un coût plus élevé, est difficile à utiliser, ne passe pas les tests de certification, est difficile à produire, difficile à maintenir ou si l’introduction sur le marché est retardée etc.

17. Les risques liés aux catastrophes naturelles

Ces risques sont souvent ignorés par le chef de projet parce qu’ils semblent être au-delà de sa sphère d’influence. Mais ces risques doivent être pris en compte dans la planification de grands contrats et programmes. Les plans de réponse de risque doivent être documentés et en place afin que l’équipe puisse répondre en cas de désastre. Le but est ici de réduire au minimum les dégâts autant que l’on peut car l’élimination totale du risque peut ne pas être faisable. La mitigation pour de tels risques est la diversité géographique, une robuste gestion des connaissances et une documentation à jour, un mécanisme de communication efficace et toujours synchronisés, un management de configuration et de gestion de version digne de confiance, le suivi des problèmes centralisé etc.

avis personnel risks workshops
relisez le billet sur les workshops de management des risques

Connaissez-vous d’autres catégories de risque majeures que l’on peut considérer en identifiant les risques dans le projet ? Quels risques sont par habitude ignorés ou minimisés par les chefs de projet ? Quelles seraient les premières 5 sources de risque à votre avis ?

2 réflexions sur “les sources de risques cachés dans les projets

  1. Ping : les sources de risques cachés dans les projets | Consulting Times | Scoop.it

  2. Ping : les articles les plus consultés en Janvier 2013 | 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.