La réussite de votre projet : comment les processus de gouvernance, de réalisation et de support peuvent vous y aider.

 Il existe trois catégories de processus de projet : les processus de gouvernance, les processus d'ingénierie et les processus de support. Chacun de ces processus a des objectifs et des fonctions différents, mais ils travaillent tous ensemble pour assurer la réussite d'un projet.

Les processus de gouvernance sont responsables de la direction et de la supervision d'un projet. Ils incluent la planification, la budgétisation, la gestion des risques et la gestion des changements. Ces processus sont essentiels pour s'assurer que le projet reste sur la bonne voie et qu'il respecte les délais et les budgets impartis.

Les processus de réalisation, quant à eux, sont responsables de la conception, de la construction et de la mise en œuvre du projet. Ils incluent la gestion des exigences, la gestion des tâches, la gestion de la qualité et la gestion des ressources. Ces processus sont cruciaux pour s'assurer que le projet est construit de manière efficace et efficiente.

Enfin, les processus de support sont responsables de l'entretien et de l'amélioration du projet une fois qu'il est mis en œuvre. Ils incluent notamment la gestion de la configuration, la gestion documentaire  l’assurance qualité, la métrologie, la gestion des plateformes et outils nécessaires. Ces processus sont importants pour soutenir le bon fonctionnement des niveaux gouvernance, et réalisation.

Bien que chaque catégorie de processus ait des responsabilités distinctes, ils sont tous interconnectés et travaillent ensemble pour assurer la réussite globale du projet. Ils sont fréquemment utilisés pour structurer des normes (eg CMMI, PMBoK) ou des référentiels d'entreprises.

En tant que leaders de projet, il est important de comprendre les différents processus et de les utiliser de manière efficace pour assurer la réussite de votre projet. En travaillant ensemble, ces processus peuvent aider à gérer les défis et les incertitudes tout en garantissant que le projet est livré à temps, dans les limites budgétaires et avec les exigences de qualité appropriées.

CMMI : les 3 modèles pour améliorer les processus de votre entreprise

Vous êtes chef de projet et vous voulez améliorer les processus de votre entreprise pour atteindre vos objectifs de performance ? Alors, vous devez absolument connaître les 3 modèles CMMI : CMMI-DEV, CMMI-SVC et CMMI-ACQ.

 

Mais pourquoi 3 modèles, vous demandez-vous peut-être ? Tout simplement parce que chaque entreprise est unique, avec des besoins spécifiques. Le modèle CMMI-DEV s'adresse aux entreprises qui développent des produits, divers mais le plus souvent informatiques, bien qu’il soit applicable à n'importe quelle activité d'ingénierie.  Il vous aidera à améliorer les processus des projets, donc  liés à la conception, au développement et à la fabrication de vos produits.

 

Le modèle CMMI-SVC, quant à lui, est conçu pour les entreprises qui fournissent des services. Il vous aidera à améliorer les processus liés à la gestion de projet, à la gestion de service et à la gestion de support. Et aussi d'optimiser la qualité de vos services et de répondre aux exigences de vos clients.

 

Enfin, le modèle CMMI-ACQ s'adresse aux entreprises qui gèrent des acquisitions de produits et de services. Il est utile pour améliorer les processus liés à la planification, à l'acquisition, à la gestion et à la surveillance des projets d'acquisition.

 

En somme, les 3 modèles CMMI sont conçus pour répondre aux besoins spécifiques des entreprises en matière de développement de produits, de fourniture de services et de gestion d'acquisitions. Utilisez-les pour améliorer vos processus, pour structurer votre référentiel méthodes et booster votre performance.

 

En adoptant ces modèles, vous pourrez assurer un meilleur suivi de vos projets, une meilleure gestion de vos clients, et une meilleure qualité de vos produits et services. Les modèles CMMI sont les alliés incontournables pour tout chef de projet qui veut être performant et compétitif. 

Comment un référentiel méthode peut améliorer la qualité et la réussite des projets informatiques

 

Dans le monde des projets informatiques, la réussite dépend de nombreux facteurs, tels que la planification adéquate, la gestion efficace des risques et la mise en œuvre de pratiques d'ingénierie de qualité. Un référentiel méthode peut jouer un rôle clé dans la réussite de ces projets en offrant une mémoire collective accumulée, partagée et enrichissante des bonnes pratiques.

 

Un référentiel méthode est un ensemble de règles, de procédures et de pratiques qui guident la conduite des projets informatiques. Il peut inclure des politiques, des processus, des modèles, et des techniques pour aider les équipes à planifier, à gérer et à exécuter des projets de manière efficace. Il peut également inclure des exemples de projets réussis et des cas d'études pour aider les équipes à comprendre les meilleures pratiques.

 

Le développement d'un référentiel méthode présente de nombreux avantages pour les entreprises qui réalisent des projets informatiques. Tout d'abord, il fournit une base commune de connaissances et de pratiques pour tous les projets, ce qui permet une meilleure coordination et une communication efficace entre les équipes. Il permet également de réduire les erreurs et les retards en standardisant les pratiques et les processus.

 

De plus, un référentiel méthode peut contribuer à améliorer la qualité des projets en fournissant des outils et des procédures pour évaluer et améliorer la qualité des produits et des services développés. Il peut également aider les équipes à identifier les risques potentiels et à les gérer de manière efficace.

 

Enfin, un référentiel méthode peut contribuer à améliorer les compétences des employés en leur fournissant des opportunités d'apprentissage et de développement professionnel. Il peut également aider les employés à rester à jour sur les dernières tendances et les meilleures pratiques dans leur domaine.

 

En résumé, un référentiel méthode est un outil clé pour aider les entreprises à réussir leurs projets informatiques en offrant une mémoire collective partagée et enrichissante des bonnes pratiques.

 

 Il est donc important pour les chefs de projets et les directeurs informatiques de s'assurer que leur entreprise dispose d'un référentiel méthode complet et à jour, et d'encourager le développement et l'utilisation de celui-ci dans tous les projets informatiques. Cela peut être fait en mettant en place des dispositifs pour collecter, partager et enrichir les bonnes pratiques, et en encourageant les employés à utiliser le référentiel méthode dans leur travail quotidien.

 

Par ailleurs, il est important de veiller à ce que le référentiel méthode soit adapté aux besoins de l'entreprise et des projets en cours, et de le mettre à jour régulièrement pour tenir compte des changements dans les tendances et les technologies.

 

Enfin, il est important de rappeler que le référentiel méthode n'est qu'un outil parmi d'autres pour aider les entreprises à réussir leurs projets informatiques. Il doit être utilisé en combinaison avec d'autres outils et méthodes pour garantir une réussite optimale.

La publication interne de la méthode projet : Un élément clé pour une meilleure efficacité de vos équipes de projet

 

La mise à disposition de la méthode projet sur un intranet ou un wiki présente de nombreux avantages pour tous les acteurs des projets. Il faut entendre ici méthode projet ou encore référentiel de conduite de projet, ou framework qualité.

 

Tout d'abord, cela permet une accessibilité facile et rapide à ces informations pour tous les membres dans les équipes projets, quel que soit leur rôle dans le projet. Cela garantit que tous les acteurs travaillent de manière harmonieuse et efficace en utilisant les mêmes normes et processus. Chacun pouvant se référer à son rythme et selon ses besoins aux pratiques publiées.

 

De plus, un intranet ou un wiki permet une mise à jour facile et rapide des informations, permettant ainsi de s'assurer que les méthodes utilisées sont toujours à jour et adaptées aux besoins actuels des projets.

 

Cela permet également une meilleure communication et collaboration au sein des équipes impliquées dans des projets, car les membres peuvent partager des informations, des idées et des ressources sur les bases d’un vocabulaire commun à l’entreprise.

 

Enfin, cela contribue à un meilleur enrichissement des processus et pratiques, en incitant chacun à faire des suggestions d’améliorations au corpus des connaissances publiées, avec un dispositif de suggestions / boite à idées électronique ou les feedbacks et les suggestions sont encouragées.

 

Ainsi grâce à sa publication en interne, la mise à disposition de la méthode projet constitue un véritable atout qualité pour tous les acteurs des projets.

La formation au référentiel méthode : un investissement clef pour standardiser les pratiques et les processus dans les projets informatiques"

 

La maîtrise de l'utilisation d'un référentiel méthode est fondamentale pour la réussite des projets informatiques. En effet, un référentiel méthode est un ensemble de règles, de processus et de bonnes pratiques qui guident la conduite des projets informatiques, mais il ne sera efficace que si tous les employés sont formés à son utilisation et l'appliquent dans leur travail quotidien.

 

En formant les employés à l'utilisation d'un référentiel méthode, on garantit que tous les employés comprennent les exigences et les processus nécessaires pour réussir un projet. Cela permet également de s'assurer que les employés sont en mesure de gérer les risques et de respecter les normes de qualité définies dans le référentiel méthode.

 

De surcroit, la formation contribue à améliorer la qualité des projets en fournissant des outils et des procédures pour évaluer et améliorer la qualité des produits et des services développés. Il permet également de faciliter la communication et la coordination entre les différents acteurs du projet en ayant une base commune de connaissances et de pratiques.

 

Enfin, la formation contribue à améliorer les compétences des employés en leur fournissant des opportunités d'apprentissage et de développement professionnel. Il permet également de rester à jour sur les dernières tendances et les meilleures pratiques dans leur domaine.

 

En résumé, la maîtrise de l'utilisation d'un référentiel méthode est fondamentale pour la réussite des projets informatiques. Il est donc important de s'assurer que tous les employés de l'entreprise sont formés à son utilisation et l'appliquent dans leur travail quotidien. Cela permet d'améliorer la qualité des projets, de gérer les risques et d'améliorer les compétences des employés. Il est important de prévoir une formation régulière pour maintenir les employés à jour sur les évolutions et les tendances du référentiel.

CMMI : la clé pour améliorer vos processus et booster votre performance

 CMMI, c'est quoi exactement?

Il s'agit d'un modèle de maturité qui vous aidera à améliorer les processus de votre entreprise.

Imaginez un miroir qui vous permet de vous regarder, de manière critique,

pour découvrir les domaines où vous avez besoin de progresser. 

C'est exactement ce que fait CMMI, il vous aide à identifier les zones qui nécessitent des améliorations

pour atteindre vos objectifs de performance.

Mais pourquoi est-ce important? Tout simplement parce que les entreprises

qui ont des processus bien gérés ont tendance à être plus compétitives,

à satisfaire davantage leurs clients et à réduire les coûts. 

C'est pourquoi CMMI est souvent utilisé dans des domaines tels que les services informatiques, 

la gestion de projets, l'ingénierie, la fabrication et les services de soutien.

Il permet de garantir la qualité des produits et services,

 de réduire les délais de livraison et de renforcer la compétitivité de l'entreprise.

En résumé, CMMI est un moyen efficace pour améliorer les processus de votre entreprise

et augmenter votre performance. C'est un outil incontournable pour toute entreprise

qui veut être compétitive sur le marché et répondre aux exigences de ses clients.

Alors, êtes-vous prêt à regarder votre entreprise dans le miroir de CMMI?

Assurance qualité et qualité produit.

Quelles différences? Pourquoi deux types de démarches qualité ? 

Dans les deux cas on vise la qualité d'un produit réalisé mais à travers des approches et des processus différents.  

Alors que dans l'assurance qualité produit on va s'intéresser à vérifier à contrôler les différents aspects du produit final désiré, dans l'assurance qualité on va s'intéresser davantage aux différentes étapes de conception et de fabrication du produit final.  

Mais alors pourquoi faire de l'assurance qualité si on peut contrôler directement la qualité du produit fini?  

En fait on s'est aperçu depuis longtemps que pour des produits complexes qui nécessitent une ingénierie  longue, compliquée, complexe, des erreurs peuvent survenir à différents moments. Et elles se transmettent en aval des phases, et se cumulent dans le résultat de la chaîne.
Effectivement des étourderies peuvent aisément se glisser dans des processus de design et de production.  En effet il a été constaté que si on ne fait rien pour corriger les défauts à chaque phase, ils vont en générer d'autres dans les phases suivantes, et s'ajouter à d'autres , 

 les défauts avaient tendance à s'accumuler tout au long des processus et à s'aggraver mutuellement jusqu'à la phase finale de réalisation de produit. Et donc celui-ci pouvait se trouver avec une quantité assez considérable par accumulation  d'anomalies, issues d'oublis, de coquilles, de  fausses interprétations, de confusions et de défauts de conception... c'est à dire une quantité d'anomalie à corriger.
Evidemment l'analyse des anomalies  tout en fin de réalisation est une opération coûteuse  car très tardive... Cela peut exiger de remonter loin en amont dans la conception , les spécifications, voire même à l'expression de besoin. Une situation assez peu enviable en coûts, délais, énergie et transpiration ...

Afin de réduire le risque d'arriver à des circonstances si peu désirables, l'idée est donc apparue d'éviter cette accumulation d'erreurs au long du processus. Ne pas laisser s'installer les déviations, maladresses, bévues et autres faux pas.
Le principe consiste alors à éliminer ces indésirables, au fur à mesure des différentes étapes, pour éviter qu'une étape transmette à une autre des erreurs qui allaient se cumuler et se complexifier. C'est ce qu'on appelle l'assurance qualité et concerne la qualité des processus.  Et est concerné l''ensemble des processus - à bien identifier - qui sont utilisés pour contribuer au produit  final.  

Ainsi par exemple des erreurs dans le cahier des charges, seront sources d'erreurs d'interprétation dans les spécifications qui seront concrétisées dans le produit qui les reflétera comme autant d'éléments du cahier des charges.
De façon similaire la détection de défauts dans les spécifications évite qu'elle soit propagées lors des étapes suivantes de conception, d'implémentation de la solution.  

Autrement dit en travaillant proprement à chaque étape, en évitant des erreurs à chaque période du projet, on évite qu'elles soient  propagées et se retrouvent comme défauts jusque dans le produit final.      

Assurance Qualité, des bénéfices sous estimés

L’AQ est une prestation interne qui est encore trop souvent négligée. En effet, elle offre des bénéfices variés importants, à court et à long terme, tant dans l’harmonisation des comportements, dans la maitrise des risques, que de l’enrichissement du savoir-faire collectif. Toutes ces contributions tirent l’entreprise vers le haut, vers l’excellence collective.

L’AQ tient un rôle d’avertisseur lorsqu’on sort du chemin de la méthode, cet itinéraire qui joue un rôle garde-fou envers les déviances. C’est donc une occasion de rappel à réduire les écarts au chemin balisé. Si l’entreprise a défini un chenal balisé c’est pour minimiser les risques sur la base de ses expériences et donc sortir de ce chenal c’est potentiellement risqué. Cette vision de l’AQ est une vision sécuritaire de réduction des risques.
Dans une perspective complémentaire, l’AQ joue un rôle d’éducateur pour les équipes sur le terrain. Avec la répétition des rappels à corrections des non-conformités détectées, la mémorisation des bonnes pratiques à suivre est renforcée. Ce qui contribue à une montée des compétences de long de la courbe d’apprentissage  et à sa stabilisation. C’est la posture du coach bienveillant qui rappelle inlassablement les bons comportements. Enfin c’est aussi une occasion de création de valeur par l’amélioration des pratiques collectives. Au-delà de la phase initiale d’homogénéisation des comportements et d’adhérence aux processus et procédures, le focus de l’AQ et des revues peut s’orienter davantage vers les améliorations innovantes, grâce aux leçons tirées de l’expérience dans la durée : collecte de pratiques d’excellence novatrices généralisables et diffusables à tous. Autant d’opportunités d’ajout de valeur au capital collectif des savoir-faire, ce véritable asset constitué par le référentiel des processus et pratiques.

Réduire le coût d'usage de l'outillage, facteur de résistance aux bonnes pratiques.

La résistance au changement s’oppose à l’amélioration des processus, c’est devenu un lieu commun. Parmi les nombreux facteurs en jeu, il ne faut pas négliger la dimension outillage.
Les processus de développement de projet peuvent être handicapés par l’outillage associé. Il ne suffit pas d’avoir une collection d’outils de génie logiciel. Si la valeur et la qualité des outils, leur intégration, leur interopérabilité est jugée déficiente par les équipes projet, le déploiement des bonnes pratiques, dont l’outillage est le soutien, sera handicapé. D’autant plus que les utilisateurs sont des professionnels de la fabrication du logiciel.

Le facteur de résistance au changement réside dans le cout d’usage (trop) élevé pour les utilisateurs. Voici quelques exemples que chacun peut confronter à sa situation :

-        Stress associé à la lenteur de fonctionnement d’outils fréquemment utilisés (sous-dimensionnements, capacités sous évaluées)
-        Rework pénible du fait des saisies manuelles redondantes fréquemment demandées dans divers outils (doublonnages des informations à la charge de l’utilisateur)
-        Risque d’incohérence lorsque de mêmes informations doivent être fréquemment mises à jour manuellement dans plusieurs outils
-        Solutions partielles obligeant à effectuer des opérations manuellement. (ex : outillage  de gestion en configuration sans baselining).
-        Stress issu de la multiplication des logins pour les différents outils
-        Rework fastidieux en l’absence de moyen simple de reprise des données dans l’outillage.
-        Réticences à effectuer du reporting ou de la diffusion d’information en l’absence de simple capacité d’exportation des données vers des formats populaires (eg XL)
-        Dispersion et divergence des pratiques si l’outillage n’a pas la capacité à définir des templates structurants et des règles de bon emploi.
-        Difficultés à piloter des processus par les indicateurs, en cas de carence de métriques paramétrables dans l’outillage, et sans capacité de présentation de tableaux de bord d’indicateurs
-        Manque de traçabilité dans l’outillage sur l’historique des modifications, les versions, les statuts et les validations, et leurs auteurs.
-        Réticences à produire des artefacts uniquement pour démontrer les preuves lors de revues AQ ou lors des évaluations SCAMPI. Cas d’outillage n’ayant pas la capacité naturelle à tracer et à historiser les modifications, activités, versions, étapes/statuts, les validations, et leurs auteurs.

Ces difficultés relevées sur le terrain sont autant d’opportunités de compléter les exigences d’une suite d’outils pour faciliter leur appropriation. Une bonne partie de ces exigences dérive des General Practices CMMI et les autres relèvent du bon sens. Et bien sur dans tous les cas, au delà des outils eux-mêmes, il faut assurer également des activités de formation de support à l’outillage.

Prendre en compte ces besoins des utilisateurs n’est pas un luxe, c’est s’assurer d’une bonne adoption des pratiques et de l’outillage associé.

Le piège de la rupture de maturité entre MOE et MOA en déploiement CMMI-dev.

Lorsque des difficultés se manifestent dans les relations MOA-MOE, malgré le dispositif du PAQ, que faire ? Par exemple, des dérives sont constatées sur les délais et charges en raison de requirements sous spécifiés ou fluctuants ou encore a des priorités changeantes. Voire même parfois à la difficultés à cerner les processus métier à automatiser par exemple. C’est à dire que les pratiques de MOA et de MOE correspondent mal, sont mal accordées et ne respectent pas les dispositions prises dans le PAQ du projet-  pourtant co-signé - que faire ?

Le PAQ a le mérite de fixer un cadre de travail commun aux équipes MOA et MOE, en s’appuyant sur des pratiques sélectionnées par l’entreprise au fil de ses années d’expérience. Le manque d’adhérence du segment MOA au PAQ et plus largement aux processus de gestion de projet est le signe d’un déploiement essentiellement focalisé sur les MOE, où les MOA sont peu ou mal impliquées, à la marge en fait. De leur coté le déploiement méthodologique en particulier via la formation au référentiel est limité, pas aussi systématique et rigoureux qu’il l’est pour les MOE. De tels déploiements partiels arrivent dans des organisations où les MOE et les MOA ne relèvent pas de la même ligne hiérarchique (DSI versus hors DSI). Les MOA ne sont pas en cause car le mode de déploiement est un choix d’entreprise.
Ainsi les MOE sont soumis à des revues AQ, mais généralement pas les MOA (bien qu'étendre les revues soient bénéfique), ce qui prive ces dernières de visibilité et de soutien dans l’emploi des bonnes pratiques. En conséquence de leur coté les MOE ont progressé dans les bonnes pratiques et maintiennent un niveau de maturité stable, d’un autre côté les pratiques des MOA sont fluctuantes, décalées, voire divergentes d’avec le reste des processus de projet. Ce choix de déploiement ne rend pas service ni aux MOA, ni aux MOE. Car cela accentue le différentiel de maturité entre les deux segments MOA et MOE.
C’est sous-estimer l’importance que la réussite du projet l’alignement des pratiques des 2 équipes MOA et MOE qui doivent coopérer. Et la Qualité de cette Chaîne de Valeur = segment MOA + segment MOE est déterminée par la Qualité du segment de niveau moindre. C’est le vieux principe du maillon faible. Il devrait contribuer à établir des stratégies de déploiement CMMI plus fiables, plus efficaces. Et à éliminer une cause importante de frictions et de gaspillages entre les deux partenaires du même projet.

Augmenter la création de valeur en étendant sa check-list de revue AQ au traitement causal

Pour éviter la reproduction infinie des mêmes non conformités, au delà des actions correctives sur des non conformités qui peuvent se reproduire , comment améliorer sa check-list AQ ? Faut-il traiter le (les) symptôme(s) ou  traiter la (les) cause(s) ?

Lors d’une revue Qualité il est possible d’avoir 2 actions correctives sur 2 plans différents, d’une part sur la correction immédiate du symptôme constaté, et d’autre part sur la correction de la cause à l’origine de ce symptôme. Pourquoi ne faire que de la correction symptomatique ?

Pourquoi ne pas concevoir une check-list AQ qui mette en œuvre ces deux principes : traitement symptomatique et traitement causal ? Le traitement symptomatique assure la correction à court terme, et par ailleurs le traitement causal s’efforce de prévenir la reproduction de la non-conformité.

L’ajustement de la check-list AQ  est minime, il suffit d’étendre les informations associées à la gestion des non-conformités relevées. La check-list AQ comprendra les éléments suivants : non-conformité relevée (symptômes), action corrective (du symptôme), causes probables, action corrective (de la cause choisie).

Le bénéfice est double car en gérant les 2 niveaux - causal et symptomatique – la qualité augmente sur le court et le moyen terme, de façon réactive et pro-active.

Dans une organisation de maturité moyenne, l’utilisation la zone de traitement causal de la check-list AQ peut être optionnelle, mais son existence incite à agir sur les causes et contribue en douceur à réduire la répétition des mêmes non conformités.

---

Traiter les non conformités en revue AQ : gérer des symptômes sans les causes

Traditionnellement les revues AQ identifient des non conformités et posent des actions correctives. Tout RAQ expérimenté constate au fil des revues et des années la récurrence des mêmes non-conformités et par conséquent le gaspillage d’énergie associé. Pourquoi constate-t-on que les non conformités se répètent ? N’est-ce pas une belle opportunité d’amélioration du processus des revues AQ ? Pourquoi malgré les actions correctives voit-on les mêmes non-conformités se reproduire ?

Un simple changement de point de vue enrichi considérablement le traitement des non-conformités. Se rappeler le principe de Cause à Effet est la première étape, laquelle amène immédiatement à considérer que les non-conformités sont des symptômes. A ce point cette prise de conscience est créatrice de valeur puisqu’elle incite logiquement à rechercher les raisons d’être des non conformités.

L’orientation du processus de revue AQ est alors à examiner, en particulier sa stratégie de traitement des non conformités: traiter le symptôme ou traiter la cause.

Traiter les symptômes = C’est le mode classique, traditionnel, des revues AQ. Apparemment rapide  et de moindre coût, mais seulement dans le court terme  car en réalité cela implique un risque significatif de reproduction à l’infini des mêmes non-conformités, donc perdant l’opportunité d’éliminer des coûts inutiles.

Cette stratégie d’action limitée au symptôme est toujours une solution de facilité à court terme. Le désir d’agir rapidement est probablement à l’origine de ce type de traitement, ainsi que l’oubli du principe de cause à effet.

Traiter la cause = C’est la mise en œuvre du principe de cause à effet : on considère les non-conformités comme des symptômes, c’st-à-dire des effets issus de causes situées en amont. Pour vraiment améliorer durablement et éviter  les pertes de temps sur les mêmes non conformités, la frustration et le stress du rework, il faut éliminer l’origine des non conformités en remontant vers leur source.

Cette stratégie d’action sur la cause est toujours plus intelligente et elle créé plus de valeur que la correction du symptôme. Eradiquer une cause élimine généralement simultanément plusieurs effets dans les non conformités. Le traitement causal présente aussi l’avantage d’avoir une portée plus importante dans le temps.

Pour vraiment améliorer durablement, il faut aussi investiguer et agir dans une optique de prévention plutôt que n’agir uniquement sur du court terme en mode réactif.  L’attitude réactive à court-terme implique de toujours corriger encore et encore les mêmes non conformités récurrentes, plutôt que corriger les raisons en amont avec un esprit de prévention. Une stratégie intelligente de gestion des non conformités combine donc traitement symptomatique et traitement causal.

Premiers pas vers l’analyse des causes de non-conformité

Un questionnement du type :  «?  Qu’est-ce qui fait que ce symptôme se produit ? Pour quelles raisons est-ce que cela arrive ? » aide à trouver des pistes d’amélioration. Il suffit ensuite de décider sur quelle cause agir en priorité. Cette analyse sera efficace en y impliquant les acteurs concernés.

Chacun trouvera de nombreux exemples d’action sur les causes de non-conformité. Par exemple l’incomplétude dans des demandes de changement peut être efficacement anticipée à leur source, par la mise en place de check-listes spécialisées en vérification amont en revue de pairs. Autre exemple, les oublis de production de livrables annexes peuvent être évités par le suivi de plannings détaillés de réalisation de livrables. Encore un exemple, de nombreux incidents suite à la mise en production d’une release applicative peut être limités par un monitoring de la couverture des exigences par les plans de test de recette et des règles de granularité et de rédaction des plans de test de recette.

Evidement trouver la cause d’un (des) symptôme(s) peut demander des tâtonnements , plusieurs essais, le succès n’est pas garanti dès la première tentative, il faut parfois gratter pour aller comprendre ce qui se passe sous la surface de la non conformité. Mais une fois la cause majeure supprimée on économise la répétition de bien des efforts de corrections des non-conformité.

L’action sur les causes lors de revues AQ n’est certes pas exigé par le modèle CMMI en niveau 2 mais seulement en niveau 5. En effet, sans doute dans un souci de simplification, et de gradation dans les process areas, le process area PPQA ne mentionne pas l’intérêt de l’action sur les causes, source des non conformités.

Il n’y a aucune raison d’attendre que l’organisation établisse un objectif de niveau 5 pour mettre en œuvre cette approche classique d’amélioration en amont. Faire mieux que les minima du cadre méthode de l’organisation augmente en douceur le niveau de maturité des processus.

---

Les processus : plus critiques que les ressources technologiques

Si on devait présenter à un martien les processus de développement IT, on pourrait dire qu’ils sont synonymes de façon de travailler pour créer un système informatique. Mais toutes les façons de travailler ne se valent pas, et celles qui fonctionnent sont précieuses. Elles sont inventoriées et cartographiées sous forme de processus .
Bien sur des outils et langages de programmation sont des ingrédients nécessaires pour fabriquer une application. Mais ils ne sont pas pérennes, le changement technologique qui les fait naître fini aussi par les rendre un jour obsolètes. Les technologies changent de plus en plus vite, c’est leur propre, personne ne peut donc garantir qu’une technologie donnée perdurera pour répondre aux problèmes de demain.
Alors que les technologies (outils et langages IT) naissent, évoluent et deviennent obsolètes, les processus demeurent, assurant la maîtrise de la complexité des projets à réaliser.
Non seulement les processus peuvent être  perfectionnés intégrant ainsi plus de valeur ajoutée mais de plus ils sont bien plus durables que les outils de développement. En fait les processus de développement portent un savoir faire collectif  et durable. De plus, à la différence des technologies qui sont des ressources que l’on peut acheter, les processus et méthodes sont des aptitudes à faire, on ne peut en faire l’acquisition sur étagère.
De ce fait, leur développement est délicat, et prend du temps, les processus ne peuvent être confondus avec des ressources marchandes. Ce sont des formes de compétences collectives, associées à une organisation.


Quel que soit le projet informatique à réaliser, et dans tous les secteurs d’application, la maîtrise des processus permettra de répondre aux challenges posés par la complexité croissante.  Les organisations ont donc intérêt à gérer et à améliorer leurs pratiques : processus, méthodologies...qui constituent une richesse immatérielle non achetable. Voici pourquoi, en ce qui concerne le développement logiciel, de plus en plus d’efforts significatifs sont réalisés pour prendre conscience des processus, les inventorier et les cartographier et les améliorer. C’est un réel capital de savoir-faire collectif, source de prospérité.

« Je n'utilise pas ce processus dans mon projet...je ne vois pas à quoi il sert »

C’est une des résistances fréquentes au déploiement d’un processus ou d’un de ses aspects. Ce type de remarque peut apparaître lors de revues qualité ou d’audits ou de coaching. Ce type d’objection indique souvent un manque de compréhension ou de communication.
Personne n’aime obéir sans comprendre. Ici il ne manque pas de détails sur le processus ou de fonctions dans l’outillage. Non, bien au contraire, il s’agit d’une carence de communication, à un niveau relativement macroscopique, sur l’intention et les bénéfices qui justifient le dispositif décrit dans le processus. Cette objection ne doit pas rester sans réponse, car sans motivation claire des raisons d’être un changement imposé dans la façon de travailler n’est pas aisément accepté.

La réponse réside dans l’affirmation explicite de la politique interne à suivre pour ce processus, telle que décidée  par le management. Elle est parfois oubliée ou sous-estimée, mais c’est une carence aisée à corriger. Une politique interne doit démontrer la volonté du management de mettre en œuvre tel processus, mais c’est insuffisant pour faciliter l’adoption de nouvelles pratiques. Au-delà de cette marque d’autorité, la politique choisie devrait inclure les motivations sous-jacentes qui rendent le processus utile et même incontournable, ainsi que l’approche retenue dans sa mise en œuvre. L’approche c’est la façon de traiter le sujet au centre du processus, habituellement suivant quelques critères principaux.
Cette politique doit trouver sa place dans le référentiel (méthodologique ou des processus, suivant le vocabulaire adopté).C’est le sens de ce que demande la pratique GP2.1 « Etablir une directive organisationnelle ».  La formulation d’une politique confère autorité et justification au dispositif organisationnel  défini dans le processus, et c’est donc avec raison que le modèle CMMI l’exige.

Les risques relevés par le processus d’assurance qualité.

Les revues d’assurance qualité offrent une évaluation du bon fonctionnement des processus mis en œuvre dans un projet. Comme les balises lumineuses qui guident les jets lors de l’approche de l’aéroport, les revues qualité donnent de précieuses indications sur les écarts hors de la route balisée, qui peuvent mettre le projet en péril. A ce titre les avertissements relevés lors processus d’assurance qualité, et les demandes de correction qualité, doivent être vu comme une contribution à la Gestion de Risques du projet. Dès lors il est donc logique d’inscrire dans le registre des Risques du projet ces non-conformités qualité. Tant que les actions correctives n’ont pas été implémentées et validées, les risques correspondant subsistent.

La centrale des risques

Des risques peuvent être identifiés à tout moment des étapes du projet. Bien souvent des risques émergent lorsqu’on gère une activité tout à fait autre que les risques, et on note de nouveaux risques dans le livrable même que l’on est en train de rédiger, par exemple on note nouveau risque lors du compte-rendu d’un point de PCC (ex :la livraison du lot2 peut être décalée par manque de visibilité sur une dépendance), ou lors de la révision de son PGCL (ex :on a 2 environnements distincts de CMS, il peut y avoir des difficultés avec la cohérence des config) ou de son PGR (RMP), ou de la réception d’un rapport de revue Qualité (ex : les tests plans d’UAT ne couvrent pas toutes les exigences)…
Il est tout à fait naturel et sain de trouver des risques lors de diverses activités de Gestion de Projet. La Gestion des Risques est un processus indispensable, identifié dans CMMI (standard du SEI). Certains ont tendance à noter ces risques dans le document qui est justement en cours de rédaction, après tout c’est lié au sujet, non ?
Attention ! Il faut avoir le bon réflexe « Processus de Gestion des Risques » : pensez à centraliser tous vos nouveaux risques dans votre table de suivi des risques, prévue dans votre Projet. Ne pas le faire au fil de l’eau, c’est s’exposer à perdre de vue ces risques, qui ne seront pas gérés. Les projets sont déjà assez complexes sans rajouter en confusion en s’astreignant à suivre des risques en divers support dispersés ! Et même si vos magnifiques capacités de mémorisation vous rendent confiant pour penser à tous ces risques, en ne les centralisant pas, il sera difficile d’évaluer les priorités et criticités relatives et de faire des choix judicieux.
Mettez donc vos nouveaux risques dans votre Table des Risques, au fil de l’eau. Cela vous épargnera bien des soucis. Parce que si vous oubliez le risque, le risque, lui, ne vous oublie pas…

Dynamisation et perspectives du projet.

La vision du  projet : le motivateur du projet.

De bonnes pratiques des processus en gestion de projet sont nécessaires à la maîtrise des projets, et pour assurer la qualité de leurs produits et livrables, certes. Mais que faire lorsque les participants semblent désorientés sur les choix à effectuer? Que faire lorsque malgré le suivi et un bon relationnel  avec ses participants et acteurs,  le devenir du projet lui-même semble incertain ou sujet à doutes ? Ou encore lorsque l’implication des personnes semble limitée ou leur motivation tourne au ralenti ? Quel diagnostic faire, face à ces symptômes ?

« Il n’y a pas de vent favorable à celui qui ne sait où il va » [Sénèque].

Le manque de cap est la première piste à explorer. Un but clair donne une direction sur laquelle s'aligner. Un projet sans but serait voué à l'échec et au gaspillage. C'est avant de lancer un projet, en phase d'avant projet, que le but est déterminé. La décision de lancer et de financer un  projet, n'a pas de sens sans un but clairement exprimé. Ceci est challengé dans le processus de Gestion de la Demande. Et celui ci peut être soumis à l'Assurance Qualité.

« Rien de grand ne s’est accompli sans passion ».

Il est donc peut probable que le management décide d'investir sans un cap préalablement clarifié. Mais est-ce suffisant ? Avoir un cap à surveiller va t il motiver l'équipage embarqué ?
Gouverner un navire selon un cap, cela n’a jamais renforcé la motivation d’un équipage ni poussé à la performance, au mieux cela va leur donner une route à suivre. Mais après ? Pourquoi tenir ce cap plutôt qu’un autre ? Voila visiblement une question pour laquelle la direction de projet se doit de fournir une réponse satisfaisante au risque de ne pas susciter l’adhésion de l’équipe.

La motivation est dans la vision. La vision est l'objectif rêvé à atteindre par le projet. La vision est liée au désir de faire le projet. La vision n’est pas un livrable du projet, mais le manque ou la faiblesse de la vision est ressentie par l'équipe. Forger la vision du projet c’est visualiser un futur souhaitable. Communiquer la vision du projet c’est la partager avec tous, et  faire la faire résonner en eux. De belles visions peuvent trouver un écho chez les participants. Pour leur transmettre le désir de concrétiser cette vision. Pour donner envie d’agir pour que cette vision se réalise. Et c'est le projet qui sera le vecteur de sa réalisation.

La vision véhicule des intentions dans une perspective globale, elle s’exprime donc en termes généraux (non spécifiques). Les objectifs viendront ensuite préciser la vision en termes plus concrets. Si la vision n’est pas attractive, elle ne suscitera pas de mobilisation forte, qui puisse donner un élan à l’équipe, et induire de la performance. Bien sur l’action de l’équipe peut être motivée tant par la désirabilité que par la nécessité, mais le meilleur potentiel d’énergie pour réaliser un projet sera toujours mû par une vision désirable et entraînante. Identifier une vision dynamisante n'est pas toujours  un exercice aisé.

Le sponsor, directeur et chef de projet ont des rôles essentiels dans la communication à l’équipe d’une vision dynamisante. Le sponsor - en premier lieu - est celui qui est  convaincu de l'intérêt du projet. Directeur et chef de projet seront les relais du message visionnaire formulé par le sponsor.

Inclure une vision motivante dans ses « livrables verbaux » n’est pas un luxe, c’est un moteur dynamisant pour l'équipe. Le management de la qualité renvoie aussi parfois vers la qualité du management.

De l'importance des processus.

Un filon à mieux exploiter : décrire ses processus métier avant de les automatiser.

Pourquoi est-ce si important de penser processus ? Pourquoi investir du temps sur les processus métiers et éviter de sauter à pieds joints sur une solution ?
Pourquoi est-il si capital de s’intéresser à la vue processus ? C’est parce que ce sont les processus qui portent les vrais besoins de fond, les solutions sont toujours au niveau du moyen, des ressources (SI). (cf. Cobit). Le vrai besoin est toujours au niveau du processus métier (i.e. ses activités), alors que les applications ne sont que des outils, certes productifs, mais plus ou moins interchangeables.
Les objectifs essentiels sont donc portés par les processus métiers, et non par les solutions technologiques : cela parait évident, mais c’est encore souvent oublié. Et il suffit d’effectuer une revue d’Expression de Besoins, pour s’apercevoir que ce n’est pas si bien compris par toutes les Maîtrises d’Ouvrage. Un (bon) Cahier des Charges doit parler métier et pas technologie. La focalisation sur les processus métiers : c’est la voie du ROI qui doit guider les MOA pour le pilotage des projets de SI. Une bonne modélisation peut être d’une grande valeur pour cela.

Lancement - Kick-off .

Vous êtes concerné par la Gestion de Projet ?
La mise en oeuvre de la norme CMMI et les déclinaisons de la série CMMI : CMMI developpement , CMMI Services ?
Les processus de développement de projets et leur amélioration ?

Ce blog est fait pour partager avec vous des Bonnes Pratiques, issues de retours d'expériences d'un consultant en Méthodes, Qualité, Amélioration des Processus.  Ces leçons tirées du terrain sont là pour vous faire gagner du temps.
A très bientôt.