Maîtrise des risques d’un projet informatique.


Je tenais à mettre ce sujet en lumière, car c’est souvent cette étape initiale et son suivi qui sont zappés, y compris dans les projets énormes.

Trop souvent la gestion de projet se résume à une planification des tâches ( méthode PERT ), une gestion des ressources, et parfois un suivi du budget.
bien sûr il faut le faire , mais j’ai le souvenir d’un truc énorme, avec qqun qui ne maitrisait pas très bien son logiciel [1] Ca fait partie des risques;

Une nouvelle mode vient de sortir : Le projet Power Point

Power Point est utile pour la com du projet, et comme support en réunion, mais il ne faut pas confondre « Com » et « Conduite & Maîtrise des risques d’un Projet ».

Ou les « slices » : ça en jette tout de suite de parler de « slices », mais ça cache parfois un grand vide.

L’ analyse des risques d’un projet , n’est pas toujours facile à imposer..

C’est une sorte de jeu de la vérité avant de lancer le projet : ca peut révéler des lacunes dans la boite , et le boss compte sur vous pour régler toutes les merdes qui pourraient arriver. Vous ne voulez pas le décevoir, ni vous sous-estimer. Mais si jamais ça foire il vous reprochera de ne pas l’avoir prévenu, ou vous serez carrément viré. Ils ne sont pas tous comme ça, mais parfois ça arrive. De toutes façons si c’est un projet qui concerne un site à risques, il vaut mieux se barrer, si ça commence aussi mal. ( voir à la fin de ce billet )

On ne compte plus les gros projets qui ont capoté, comme le Dossier Médical Personnalisé ou dont les coûts , et les délais ont explosé, comme Chorus, le système de gestion de l’ Etat.

Le DMP

http://www.sante.gouv.fr/assurance_maladie/actu/dmp.htm

Interview du président du conseil du comité d’orientation du DMP en Mars 2005, un médecin.

« Nous sommes sur un chantier qui s’étalera sur au moins dix ans. »

La rédaction , 01 Informatique (n° 1805), le 14/03/2005 à 18h46

01 Informatique : Quels bénéfices pensez-vous retirer du DMP ?

Le dossier reste très embryonnaire ( autrement dit il a rien glandé ) dans notre pays et nous sommes sur un chantier d’une durée d’au moins dix ans. Ceux qui pensent le contraire se trompent. Mais si je me réfère aux Anglo-Saxons, plus avancés sur la question, les bénéfices sont indubitables : économies sur la redondance des examens, augmentation de la qualité du suivi des patients et, donc, des soins… Le DMP devrait déboucher sur des économies importantes. Les enjeux sont même tels que le poids du budget informatique, aussi significatif soit-il, ne représente pas grand-chose ( quelques milliards , à peine ) au regard du retour sur investissement.( bingo )

L’échéancier va-t-il être modifié ?

Pas nécessairement. Nous allons être très attentifs sur la conduite des projets et espérons, d’ici à deux ans, passer dans une phase industrielle. D’ici là, nous comptons rencontrer ( oui mais c’est pas sur ) les établissements ayant développé des petits ou gros projets, retenir des sites témoins, évaluer les offres, tester, vérifier pour essayer ( ils vont essayer, ils ne sont pas sûrs d’y arriver , mais au moins ils auront essayé ) d’élaborer une solution.

Quelles sont les grandes étapes prévues dans le cadre de votre mission ?

Pour l’instant, nous formons l’équipe. Nous allons rencontrer les établissements qui ont mis en oeuvre des projets, puis nous établirons un calendrier. Nous comptons aussi lancer un appel d’offres pour la configuration. Quand ? Difficile à dire. Nous sommes très loin du stade opérationnel. Je suis juste en mesure d’établir un programme pour les mois à venir.

Je l’ai découpé en trois volets : la sécurité, c’est le sujet de base car il faut un système fiable et sûr ; l’utilité, cela paraît évident, mais le DMP doit être d’une utilité avérée pour les professionnels de la santé ; et enfin, la convivialité. Le DMP doit être aussi « fun » qu’une messagerie électronique ou que tout autres outils de ce genre, sinon on n’obtiendra jamais l’adhésion des patients et du milieu médical.

C’est hallucinant de précision pour un projet. Putain dix ans !!! il ne prend pas de risques. Et s’il ya beaucoup de conditionnel, il y a aussi des affirmations :comme : « ceux qui pensent le contraire se trompent ». Au contraire si on ne veut pas se planter, il vaut mieux écouter certains avertissements de personnes plus expérimentées.. ou « Je » l’ai découpé en trois volets

Comment faire capoter un projet informatique en dix leçons ..

J’adore cette comparaison avec Airbus

18 avril 2006 – Philippe François – iFRAP

DMP – Le Dossier Médical Personnel, c’était un si beau projet !
Mettre en place 62 millions de dossiers médicaux, les tenir à jour, les rendre accessibles de partout et les sécuriser, c’est au moins aussi complexe que construire l’A380. Mais EADS n’a pas dit à ses équipes et à ses sous-traitants : « commencez la construction, on vous donnera le cahier des charges plus tard », « comme on est en retard, sautez la phase 1 d’expérimentation et passez tout de suite à la phase 2 », « développez chacun votre modèle (6 au total), on verra plus tard comment les raccorder », « on a pris un an de retard en un an, je veux pas le savoir ! » et « on ne sait pas comment le financer, mais faites-nous confiance ». C’est ainsi que le projet DMP est mal engagé. Pas étonnant que Pierre Bivas, le Président du projet, ait démissionné en juillet 2005, que le Directeur Jacques Beer-Gabel vienne d’être viré au moment où les industriels qui travaillent sur le DMP publient un appel au secours.

Mais EADS a tout de même fait une énorme toile qui a généré des retards de livraisons, avec des conséquences financières énormes .

Daimler a voulu conserver son vieux logiciel de CAO pour définir le cablage , au lieu de le faire avec Catia qu ‘utilise Airbus et il y a toujours des problèmes d’exportation entre applications CAO, même si elles utilisent le même format.

A l’arrivée des éléments à Toulouse il manquait 5 cm, il a fallu refaire tout le cablage.

Le pire est qu’on leur a signalé ce risque avant, mais à la tête ce sont des financiers qui décident , les pb de CAO leurs passent au dessus de la tête .

Un autre site Web a fait le travail pour le DMP :

http://philippe.ameline.free.fr/phis/

Paris ; Inspection générale des finances

Institué par la loi n°2004-810 du 13 août 2004, le dossier médical personnel (DMP) avait pour but de favoriser la coordination, la qualité et la continuité des soins.

Compte tenu de la complexité du dispositif, un GIP, composé de l’Etat, de la Caisse des dépôts et consignations et de l’assurance-maladie, avait été constitué en avril 2005 pour piloter la mise en place du DMP.

Celui-ci devait être généralisé à tous les bénéficiaires de l’assurance maladie pour le 1er juillet 2007.

La mission conjointe IGAS-IGF-CGTI, mise en place en juillet 2007, fait le point sur l’état d’avancement et le pilotage de ce projet ainsi que sur sa capacité à répondre aux objectifs initiaux.

Elle estime notamment que le dispositif s’est vu, d’emblée, doté d’objectifs irréalistes, aussi bien dans le calendrier imposé, le coût du projet que dans le modèle économique choisi, modèle dont le potentiel d’économies attendu pour l’assurance maladie ne s’est pas vérifié. Elle observe par ailleurs que le projet DMP souffre d’une perte de crédibilité et de lisibilité et présente d’importantes zones de risques et d’incertitudes.

Sur la base de ce constat, la mission présente une série de recommandations pour « sauvegarder les acquis, restaurer la confiance et relancer le projet de DMP ».

Après le fiasco, un rapport de l’ IGF en 2007 : Diagnostic et recommandations

Ce rapport constitue le REX ( retour d’expérience ) qu ‘on devrait faire à la fin de chaque projet.

http://www.ladocumentationfrancaise.fr/rapports-publics/074000713/index.shtml

Téléchargez le rapport complet ci dessous :

http://lesrapports.ladocumentationfrancaise.fr/cgi-bin/brp/telestats.cgi?brp_ref=074000713&brp_file=0000.pdf

Le projet sera relancé après ce retour d’expérience de 2007.

Apparament ça n’a servi à rien. On ne change pas une équipe qui gagne !!!

Rapport de la Cour des Comptes de février 2009 :

Mais c’est plus le management, les compétences et l’interventionnisme éxagéré de l’ Etat ( encore une fois ) qui sont pointés.. et sur i-med ce n’est que protestations sur l’ensemble du management du SI de la Santé.

Enfin voilà comment on gaspille l’argent public en période de crise.

http://www.ccomptes.fr/fr/CC/documents/RPA/6-gestion-GIP-dossier-medical-personnel.pdf

Chorus, le logiciel qui empêche l’Etat de payer ses factures

Par François Krug | Eco89 | 12/05/2010 | 19H41

Fournitures de bureau et armes de guerre… Depuis fin
2009, l’Etat accumule les impayés à cause du nouveau logiciel.

http://eco.rue89.com/2010/05/12/chorus-le-logiciel-qui-empeche-letat-de-payer-ses-factures-151106-0

http://www.ifrap.org/La-mise-en-place-de-CHORUS-devoile-les-insuffisances-de-la-comptabilite-publique,11565.html

http://www.agoravox.fr/actualites/citoyennete/article/chorus-qui-veut-gaspiller-des-16253

AIFE : en savoir plus sur Chorus.

http://www.budget.gouv.fr/directions_services/aife/presentation_chorus0912.pdf

Publication du poste de chef de projet :

http://www.budget.gouv.fr/directions_services/aife/fiches_poste/chef_projet_deploiement_chorus.pdf

Rapport de la Mission informatique de la loi des finances.

http://www.lemagit.fr/article/telecharger/pqid6hqr45wk7y4v7mlwh2emn2q3byri.pdf/

Manager le risque d’un projet informatique

Les projets informatiques comportent des risques spécifiques qu’il convient de connaître et d’anticiper afin de mieux les gérer. Ce cycle permet d’atteindre ces objectifs en s’appuyant sur l’expérience issue de méthodes appliquées dans le domaine industriel et adaptées aux projets informatiques.

Objectifs

* Identifier les risques liés à un projet informatique et évaluer leurs conséquences
* Mesurer la sensibilité du projet à ces risques
* Mettre en place des stratégies de réponse adaptées

Nature des risques dans le cadre d’un projet informatique : exemples et impacts

* Stratégique
* Financier
* Contractuel
* Relations MOA / MOE, sous-traitants
* Cahier des charges
* Faisabilité technique
* Gestion des modifications et de la recette
* Défaillance de ressources humaines
* Intégration

Analyse et traitement des risques (AMDEC)

* Analyse des risques potentiels (criticité) et de leurs effets potentiels (gravité)
* Plan de gestion des risques
* Structuration du projet en fonction du risque, externalisation

Actions correctrices

* Suivi des risques, provision, révision d’objectifs
* Ajustement des ressources
* Intérim
* Sous-traitance

Capitalisation

* Processus PDCA d’amélioration continue
* Bilan de projet : enseignements à tirer

source : http://www.cesi-entreprises.fr

Un excellent document du CNRS :

www.dsi.cnrs.fr conduite-projet analyse de risque d’un projet

Il ne s’agit donc pas de faire une analyse des risques au début, il s’agit bien de faire un suivi régulier de l’évolution des risques en cours de projet. Il peut y en avoir de nouveaux, des risques jugés négligeables en début de projet peuvent soudain évoluer.

Cette analyse porte sur un projet défini.

Mais il y a un risque majeur avant :

Un projet est défini pour satisfaire un besoin précis. Si ces besoins sont mal exprimés ou si le projet ne peut pas les satisfaire on va droit à la catastrophe.

A cette étape on raisonne trop souvent en terme de solutions , exemple :

« on va mettre SAP ! on peut tout faire avec SAP ..presque tout le monde utilise SAP ! ( .y compris mettre le bronx.et le projet sera ingérable ). »

Inversement en refusant de parler de solutions, on risque d’être trop vagues, et on nous proposera une solution qui ne répondra pas au besoin réel, ou coûtera plus cher.

Dans le cas de Chorus , ils ont voulu garder les applications existantes et les interfacer avec SAP.

Peut-être la solution aurait été de tout basculer sur SAP, pour avoir un système homogène et réduire les coûts de maintenace… ( attention : quand on veut tuer son chien on dit qu ‘il a la rage )

Mais ça change alors la nature du projet ( et tout son déploiement, ce qui amène d’autres risques ) qui correspond à d’autres besoins qui n’ont pas été exprimés ou mal définis ou sous estimés.. en particulier l’aspect financier.

Il faut regarder aussi un peu plus loin que le bout de son nez..

Un autre risque est qu ‘une réorganisation intervienne, une fois le projet réalisé. ces vieilles applis qu’on a gardé seront elles toujours d’actualité ?

Voir le sujet à venir : Analyse des besoins qui est la première étape du projet.

Une autre exemple , vécu :

C’était un système de téléexploitation et de télémaintenance, cogité au plus haut sommet, destiné à suppprimer des interventions sur des sites éloignés ou des déplacements pour faire des controle dans le cadre de la maintenance préventive.

Mais l’objectif réel est de supprimer du personnel d’exploitation.

Bonne idée au départ : prendre un logiciel existant, ca coute moins cher.

En plus ce logiciel marche très bien, j’ai eu l’occasion de vister une installation équipée avec ce logiciel , ses utilisateurs sont satisfaits.. ( sauf qu ‘ils n’ont pas du tout les mêmes objectifs )

Ce logiciel ne fait pas de télémaintenance, c’est pas grave : il suffit de lui ajouter une base de données.

C ‘est un des risques connus : il est parfois plus simple de réécrire entièrement un logiciel que d’en bricoler un existant pour lui ajouter des fonctionnalités

A la sortie : comme le logiciel n’aavec la base de données n’a jamais été évalué correctement , ça a mis a genou les PC 386 ( les plus performants de l’époque ), il était impossible de se connecter à distance ou même de prendre la main au clavier sur place.. Donc plus de téléexploitation.

Jamais je n’ai vu des chefs de projets d’aussi mauvaise foi !

Ils avaient déjà englouti pas mal d’argent dans ce projet, et on leur demandait des comptes. Il aurait fallu dire que ça marchait.

Ils n’étaient donc pas prêts à écouter la moindre critique.

Là les bricolages dans l’application ont commencé.. les engueulades aussi, et jusqu ‘au sommet.

Surtout le volet télémaintenance ne correspondait pas aux besoins.

Il s’agissait de détecter des dérives de certaines mesures, avant d’arriver à l’incident.

Comme on surveille la température d’eau du moteur de sa voiture..

Si ça chauffe trop, on vérifie qu ‘il ne manque pas de l’eau dans le réservoir. avant de casser le moteur.

S’il ne manque pas d’eau, on va jusqu’au premier garage , au ralenti, avant que le moteur serre ou de voir passer les pistons à travers le capot.

Bien sûr, il y avait des alarmes classiques, mais quand à prédire la fin du moteur, avec un historique et des moyennes de températures journalières hebdomadaires , mensuelles, annuelles, de l’eau du moteur, on se demande si ces types sont des ingénieurs..

Si vous n’utilisez pas votre voiture pendant un mois, l’eau reste à la température ambiante du garage et fausse toutes les moyennes qui sont alors le reflet de l’utilisation de votre véhicule, en fonction des saisons et de vos activités.. reflet inluencé par le climat.

Pour certaines données, ces moyennes étaient représentatives et leur dérive permettait de détecter une anomalie avant qu ‘il soit trop tard. Mais le logiciel d’historique, qu ‘ils sont allés pêcher je ne sais où ( un logiciell pour la météo ? ) ne permettait pas de faire des traitements différents, et perdait son temps à calculer des moyennes non représentatives.

Un temps tellement long, qu ‘il remettait en cause le calcul des moyennes, et même la fonction de téléexploitation.. Le logiciel étant borgne pendant de longues minutes..

Puis les gains espérés, par la télé exploitation n’ont pas été atteints, largement surestimés : on ne peut pas tout régler à distance…

Il avait été prévu de faire un bilan objectif.. il l’a démontré et en plus les gens se déplaçaient pour relancer le PC qui était planté ( choses qu’on pouvait raisonnablement voir diminuer une fois l’appli au point )…

Suite à un gros pépin, une analyse de risques ( risques liés à l’exploitation de ces sites ) qui aurait due être faite au départ les a anéantis et a même remis en cause les suppressions de personnel qui avaient été faites….

Mais il y avait bien d’autres problèmes, ce projet était mal barré dès le départ,.

On est en plein dans le sujet de la maîtrise des risques d’un projet.

Les rôles de chacun étaient très mal définis, la conduite du projet d’automatisation qui allait avec cette application, complètement folklorique.

La MOA ayant complètement abandonné la maîtrise du projet au MOE, impossible de valider quoi que ce soit.. en plus sur fond de rivalités interservices depuis une réforme qui avait séparé en deux entités, et sur fond de guerre des chefs au sommet.. Rarement vu un tel bazar et bien sur ça a un impact non négligeable sur le projet.

N’ ayant pas le pouvoir d’imposer une méthode qui avait fait ses preuves pour des informatisations plus importantes, et que d’autres jugeaient superflue pour des petits sites, j’ai fait mon analyse de risques de ce projet pour moi.

Quelle conne d’être allée me fourrer dans ce piège, ( mais je n’avais pas tous les élements pour juger lors de l’entretien d’embauche..)

Et j’ai conclu qu ‘il était préférable d’aller voir ailleurs, convaincue qu ‘on allait droit au carton : ce qui n’a pas manqué d’arriver, malgré les alertes..

Une connerie dans l’info industrielle peut faire des centaines de MF de dégats et presqu’ autant en pertes de production.

Fort heureusement il n’ y a eu que des dégats matériels ; il y aurait eu des morts , les sanctions pénales seraient tombées. C’est autre chose que de chercher un autre boulot ailleurs..

Il n’ y a pas de place pour les fous, les amateurs et les magiciens dans ce métier.

Les risques ça se maîtrise, et j’aimais bien ce bon stress qui oblige à la rigueur, à la prudence, à la réflexion..

Parfois c’était chaud, le stress se lit aussi sur les visages de l’entourage, mais si on a tout vérifié, on y va !

Le stress est aussi amplifié par le vacarme lorsque la machine démarre, qqun qui n’a pas l’habitude se sauve en courant et pendant une vingtaine de secondes on se demande si on a pas tout arraché.. Belle montée d’adrénaline. Ouf, une fois les 300 tonnes de ferraile élancées, le bruit redevient normal, le préposé à l’arret d’urgence peut enfin lâcher le bouton.. et on voit tout le monde respirer, sourire.. Après c’est la teuf.. avec la pression qui retombe.

Mais hors de question de partager l’irresponsabilité de qui que ce soit, même sous la pression..

Il m’est arrivé à la fin d’un gros chantier, quand tout le monde a bouffé ses délais, que ma semaine d’essais se réduise à un vendredi après midi .. Bien que les gens insistent lourdement, car ils ont promis une date de remise en service, c’était Niet ! Il n’y a pas de crainte à avoir, car ces gens là sont des inconscients arrivistes, les essais sont parfaitement justifiés et on ne peut pas faire des miracles.. C’est avant qu ‘il fallait gérer les retards des uns et des autres..

[1] lors d’une réunion de chantier , où il y avait de nombreux corps de métiers, un jeune ingénieur nous présente son graphique PERT en couleurs, fait avec un logiciel… je ne me souviens plus des détails, mais il avait fait une belle toile. C’est le patron de l’ entreprise de génie civil, un petit bonhomme sicilien avec le borsalino, gros cigare, chaussures en croco, self made man qui devait avoir un CAP et ne connaissait rien aux ordinateurs, qui a soulevé le problème. Comme l’ingénieur avait oublié de nombreuses choses, on a refait le pert au tableau, et il a recopié.. D’où l’utilité de ces réunions où chacun exprime ses contraintes qu ‘on ne peut imaginer si on est pas du métier..

Si le PERT est facile à comprendre, le maniement de ces logiciels est souvent trop complexe, on passe plus de temps à le vérifier qu ‘à le faire à la main.

Publicités
Cet article a été publié dans Gestion de Projets. Ajoutez ce permalien à vos favoris.

Laisser un commentaire

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 )

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 )

Photo Google+

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

Connexion à %s