Exo MSI 6 clés de succès et risque d'un projet SI Flashcards
Qu’est-ce qu’un retour d’expérience sur un projet SI?
Un retour d’expérience sur un projet est le transfert d’une expérience acquise par un individu au cours d’une activité sur un projet SI à un autre individu.
C’est de la gestion de la connaissance.
À quelles conditions peut-on avoir un retour d’expérience sur un projet de système d’information ?
Pour que les retours d’expérience soient partageables, il faut :
- organiser la connaissance : Les connaissances sont découpées en éléments manipulables appelés « thèmes » (une connaissance manipulable a des limites clairement identifiables). Ceux-ci sont identifiés de manière claire. Les éléments de connaissances manipulables doivent porter sur une problématique précise, propre à la vie des organisations (exemple : “installation d’un serveur”, et non “informatique”).
- identifier les gestionnaires de la connaissance : l’expert apporte la connaissance relative à son domaine d’action. Le gestionnaire des connaissances est responsable de la création, de la structuration et de l’évolution de la connaissance partagée. Il met en place des outils collaboratifs, permettant à chacun de stocker et de puiser la connaissance souhaitée.
Pour quelles raisons les projets SI peuvent-ils échouer ?
Un projet SI peut échouer pour les raisons suivantes :
a) Au niveau stratégique :
1- la direction générale s’implique faiblement dans la définition de l’objectif,
2- un changement se produit dans l’environnement de l’organisation étudiée rendant obsolète et inadapté le projet,
3- le projet vient s’ajouter à un existant sans remettre en cause celui-ci.
4- la communication entourant le projet est insuffisante.
b) Au niveau de l’efficience du projet :
5- l’efficience (ou performance) du projet est insuffisante du fait :
- de la mauvaise appropriation du projet SI par les utilisateurs.
- d’une sous-estimation de l’enjeu du projet, de son coût.
c) du fait du caractère obligatoire du projet (et d’attentes d’utilisateurs pas prise en compte) :
6- un manque d’attractivité du projet,
7- un cahier des charges insuffisant, mal élaboré,
8- un non-respect des délais.
9- une mauvaise prise en compte des attentes du client,
10- un rejet du projet par les utilisateurs,
d) Au niveau du choix de la solution informatique :
11- une sous-estimation des travaux à faire et donc des délais,
12- une technologie rapidement obsolète,
13- une sous-évaluation de la complexité de l’intégration de la solution retenue dans le SI existant,
14- un manque de compétences du prestataire chargé de mettre en oeuvre la solution technologique,
15- la disparition du prestataire (liquidation judiciaire…),
16- une sous-estimation des travaux de migration entre l’ancien et le nouveau système,
17- une sous-estimation du coût de l’interface entre les applications existantes et la nouvelle solution,
18- une sous-évaluation de la maintenance du projet SI, du dispositif documentaire et de la formation du projet,
19- la taille du projet et la qualité, la stabilité de l’équipe projet peuvent générer des risques.
Comment peut-on gérer les risques inhérents à un projet SI?
Lorsqu’un risque est identifié, plusieurs solutions sont possibles pour le gérer. On peut :
1- chercher à l_’éviter_ (ex : si une nouvelle technologie génère des risques, avoir recours à une technologie plus ancienne),
2- le transférer à un tiers (ex : si pour la maintenance quotidienne, il y a un risque de dépassement de budget, alors confier la tâche à un tiers après la négociation d’un prix forfaitaire),
3- augmenter les nombre de tests, si le risque est le non fonctionnement du projet,
4- diminuer la taille du projet (ex : pour réduire le nombre d’intervenants sur un projet) si le risque est lié à la taille de celui-ci. On le découpe en sous-projets ou on utilise des outils pour suivre l’activité des nombreux intervenants (caractéristiques des grands projets),
5- développer le projet en cascade (validation à chaque étape du projet : étude de faisabilité => déf° des besoins => conception générale =>…..), si la solution technique se révèle complexe avec des risques d’échec,
6- faire participer les acteurs au changement (gestion du changement), en faisant appel à leur créativité, en les associant aux décisions s’il
y a un risque de rejet du projet par les utilisateurs,
7- faire un audit du projet pour identifier les risques et y remédier.
Quelles sont les solutions juridiques possibles lorsqu’un litige apparaît entre le maître d’ouvrage et le
maître d’oeuvre ?
Les solutions juridiques possibles l_ors d’un litige entre le maître d’ouvrage et le maître d’oeuvre_ :
1- tentative de conciliation amiable,
2- tentative d’arbitrage,
3- porter le litige devant un tribunal.
Pour quelles raisons la résolution d’un contrat informatique est-elle difficile à obtenir ?
La résolution d’un contrat est difficile à obtenir pour les raisons suivantes. Il faut remettre les parties dans l’état
où elles se trouvaient avant d’avoir contractées. Ce qui peut être très complexe. Pour obtenir la résolution, il faut
prouver :
- la gravité du travail non fait par le prestataire de services,
- la nature essentielle pour le client de la partie du projet non faite par le prestataire,
- le caractère indivisible ou non du contrat. Si la résolution s’applique, l’ensemble du contrat est-il concerné ?
- la possibilité pratique de remettre les parties en l’état où elles étaient avant d’avoir contractées.
