sauvetage de projet
TRANSCRIPT
-
7/30/2019 Sauvetage de Projet
1/27
-
7/30/2019 Sauvetage de Projet
2/27
Pourquoi ce livre blanc ?
TheCodingMachine a eu souvent l'occasion d'aider des
clients sauver des projets. Ces situations critiques nous ont
permis d'apprhender les origines de ces drapages, de
trouver des solutions et de les mettre en uvre.
Le "sauvetage de projet" est un sujet passionnant plusieurstitres :
Il ncessite de mettre en pratique une trs large palette
de comptences. Des comptences humaines pour
distinguer objectivement les problmes rels de ceux qui
sont fantasms, des comptences techniques afin de
pouvoir plonger au curdes applications, sans oublier la
la crativit pour imaginer ou trouver les bonnes solutions.
C'est une activit exigeante. Les attentes des clients sont
fortes. Ces missions ncessitent de dployer une nergie
importante dans un dlai record afin de convaincre les
diffrentes parties et mettre en place les bonnes actions
correctrices.
Ce livre blanc est l pour vous livrer une synthse de nosexpriences, les cueils viter et vous exposer les
mthodes que nous avons appliques.
2
-
7/30/2019 Sauvetage de Projet
3/27
A qui sadresse ce livre blanc ?
Si vous estimez que votre projet est en danger ou en pleine
tourmente. Si, plus simplement, vous souhaitez approfondir la
notion de risques sur un projet, ce livre blanc est fait pour
vous.
Avertissement :
Ce livre blanc est le fruit de notre exprience. Vous y
trouverez peut tre des dfauts ou en soulverez des limites.
D'autre part, toutes les solutions prsentes, parce qu'elles
ne s'appliquent pas toutes les situations, ne sont pas
garanties.
Ce livre a pour objectif de vous donner des ides et de
partager nos expriences.N'hsitez pas nous faire part de votre exprience !
Note sur les auteurs et la version :
Ce livre blanc a t crit par Jean-Guillaume DUJARDIN et
Nicolas PEGUIN.
Date de publication de la premire version : septembre
2012.
3
-
7/30/2019 Sauvetage de Projet
4/27
Plan du document :
Le premier volet du document dtaille les risques qui
menacent votre projet et vous donne des repres fort pour
les isoler.
Votre projet n'avance plus ? Est dans une situation critique ?
Le deuxime volet propose de vous donner des cls pour
sauver un projet en distinguant diffrentes tapes :1. Est-il possible de sauver le projet ?
2. Quelles sont les pistes pour rsoudre les problmes
humains ?
3. Comment rsoudre les problmes techniques ?
4
-
7/30/2019 Sauvetage de Projet
5/27
-
7/30/2019 Sauvetage de Projet
6/27
La diffrence entre le risque & une situationd'chec
Le risque est susceptible d'tre gr. Il est donc possible de
mener des actions correctives. A l'inverse, une situation
d'chec est une accumulation de risques non grs qui
aboutissent souvent un blocage global du projet.
Si vous vous posez la question de savoir si votre projet esttotalement plant ou si vous tes simplement en train de
grer un risque, vous tes une tape cruciale du
dveloppement de votre projet. En gnral, plus on se rend
compte tard du plantage, plus c'est grave. Autrement dit,
plus on accumule les risques au fur et mesure du projet,
plus le sauvetage s'annonce difficile !
6
-
7/30/2019 Sauvetage de Projet
7/27
Les dangers qui vous guettent !
Chaque tape dun projet comporte des risques. La plupart
des risquent qui menacent un projet sont connus l'avance
mme si certains apparaissent dans des situations
particulires parce que lis une problmatique unique.
Nanmoins, la manire de structurer la rponse aux besoins
des utilisateurs (expression de besoin et cahier des charges)et le choix du prestataire constituent des tapes cls pour
limiter tout dbordement sur un projet venir. Vous devrez y
porter une attention particulire.
7
Les tapes Risque(s)
Besoin, cahier descharges
Le recueil des besoins, les entretiens avec lesutilisateurs ou les clients (surtout si l'on est sur unbusiness model web) sont indispensables.
Le risque est de rdiger un document complexe etpas assez complet.Si vous organisez une consultation et que vous n'avezpas de comptences techniques, laissez lopportunitau prestataire de concevoir la solution technique laplus adapte et de rpondre avec les technologiesqu'il matrise le mieux. Cependant, ne vousdsintressez pas de la technique. Ne pas matrisercet aspect est trs dangereux.
Vouloir trop de fonctionnalits est parfois risqu.Commencez petit, avec les fonctionnalits
indispensables. Plus vous largirez le primtre plus leprojet sera difficile grer.
[cf. #1 - La peur du pas assez ou le primtre la
drive]Le lotissement de la solution doit tre logique etcomprhensible. Lotir ne veut pas dire construire desbriques non fonctionnelles
-
7/30/2019 Sauvetage de Projet
8/27
8
Choix du prestataire Ne consultez pas un seul prestataire (et surtout si c'estun de vos amis). Mais nen consultez pas trop nonplus. Un trop grand nombre de rponses ne vouspermettrait pas de les traiter correctement.
Si le prix propos par le prestataire estsignificativement peu lev, soit le primtre du projeta t sous-estim, soit le prestataire propose un prixhameon.
[cf. #2 - Le prix hameon]Les plannings doivent tre ralistes. Ils ne respectentpas forcment vos attentes. Dans la rponse du
prestataire, vous devez trouver les lments quijustifient comment tenir (ou pas) le planning.
Il est ncessaire de finaliser le montage du projetavant le dmarrage, c'est--dire claircir les points lesplus compliqus trop souvent ngligs (migration,intgration avec un systme tiers etc.).
Dmarrer un projet sans contrat ou avec un contratmal ficel est trs dangereux. Il risque de vousmanquer des lments fondamentaux tels que laproprit des dveloppements par exemple.
Conception fonctionnelleet technique
Ne laissez pas dmarrer un projet (sauf pour unprimtre trs restreint) sans avoir valid et doncparfaitement compris les spcifications fonctionnelles.
Les spcifications sont le gage de la bonnecomprhension du projet, le dveloppement sera larsultante de ces documents.
Dveloppements Des points davancement doivent tre raliss pourvous assurer de la bonne tenue du projet. Un retardpeut reprsenter un risque technique quant lacomptence des architectes /dveloppeurs de la
solution.[cf. #3Mesurer plutt que supposer]
-
7/30/2019 Sauvetage de Projet
9/27
Dveloppements (suite) Linformation doit tre transmise de faon rgulire,les bonnes nouvelles comme les moins bonnes.Ces points doivent dtailler les risques et la manirede les grer.
Lintgration doit permettre au prestataire de validertechniquement la solution
Une priode de dveloppement trop longue sans
implication des utilisateurs est problmatique. Il estncessaire de parer ce risque en prvoyant desrecettes intermdiaires.
[cf. #4L'effet tunnel]Mise en place de la
solutionImpliquez-vous dans la recette de votre projet.Ralisez des cahiers de tests, crez des jeux dedonnes pour tester les lments cls de votre projet
[cf. #5Le nombre d'anomalies]
Le dimensionnement et les environnements doivent
permettre une utilisation optimale de l'appl ication(gestion des serveurs, de linfrastructure rseau, etc.)Il vaut mieux sparer les dveloppements de laproduction (partie du travail qui consiste mettre enplace les serveurs, les environnements, grer lessauvegardes etc.).
-
7/30/2019 Sauvetage de Projet
10/27
#1 - La peur du pas assez ou le primtre ladrive
La peur du "pas assez" est un symptme frquent. Ds
l'origine du projet, le client dfinit un primtre trs vaste ou
exprime des besoins de plus en plus complexes au fur et
mesure du projet.
Ce cas est frquent lorsque le client souhaite lancer unenouvelle activit. Proposer de nombreuses fonctionnalits
donne l'impression rassurante d'offrir un service plus complet
au client final. Dans la ralit, c'est souvent l'inverse. Il faut
dfinir le primtre le plus petit possible, tester rapidement et
redfinir le besoin en utilisant les retours utilisateurs ou bta
testeurs ("Pave the cow path").
Dfinir un primtre trs vaste donne aussi l'impression
trompeuse de coter moins cher qu'un dveloppement en
plusieurs tapes. Cela ne reste qu'un leurre. Au final, si de
nombreuses fonctionnalits ne servent pas, le cot de ces
dveloppements inutiles et de l'effort ncessaire pour les
produire peuvent mener le projet vers l'chec.
La drive d'un primtre peut aussi tre attribue une
mauvaise gestion de projet. Un prestataire en mauvaise
position, comme par exemple dans le cas d'un retard
important ou d'un problme de ressources, peut accepterdes dveloppements complmentaires en esprant
conserver de bonnes relations avec son client. Il lui rend un
mauvais service. En cumulant retard et nouveaux
dveloppements, le projet risque d'tre encore plus long
finaliser.
10
-
7/30/2019 Sauvetage de Projet
11/27
#2 - Le prix hameon
Le prix propos par le prestataire est volontairement bas afin
de "hameonner" le client. Un prestataire minimise
volontairement le prix de la prestation afin de remporter le
march.
Au fil du projet, deux situations se prsenteront:
Les dveloppements continuent car vous acceptez denombreux avenants
Le projet est bloqu car vous ne souhaitez pas (ou ne
pouvez pas) continuer payer.
Ce "faux prix" peut fortement dgrader la relation que vous
entretenez avec votre prestataire mesure que le projet
avance.
Il est cependant ncessaire de faire la diffrence entre un
acte dlibr (un prestataire qui hameonne un client) et unprimtre qui volue et grandit anormalement en cours de
route (l, c'est un peu la faute du donneur d'ordre).
#3 - Mesurer plutt que supposer
Il est important de mettre en uvre, ds le dmarrage, un
dispositif de gouvernance permettant de mesurer
l'avancement, grer les risques, d'arbitrer les volutions.Ces mesures : temps consomm, avancement etc. doivent
permettre de fournir l'ensemble de l'quipe un avis objectif
sur l'tat de votre projet. Ils permettent de mettre en uvre
des plan d'actions pour grer certains risques ou re-planifier
certaines parties du projet.
11
-
7/30/2019 Sauvetage de Projet
12/27
# 4 - L'effet tunnel
L'effet tunnel consiste dvelopper pendant une longue
priode sans faire intervenir les utilisateurs.
La solution dveloppe risque, in fine, de ne pas convenir
aux besoins/souhaits des utilisateurs. La recette, longue et
donc fastidieuse, risque alors dtre bcle, les utilisateurs nedisposant pas forcment du temps ncessaire pour la faire
aboutir.
#5 - Le nombre d'anomalies
Voil une question qui revient souvent : est-ce qu'un nombre
important d'anomalies durant la phase de recette indique
qu'un projet est en train de se planter ?
Dans la plupart des cas, non ! Plus le nombre d'anomalies est
important, plus vos utilisateurs testent la solution. C'est lorsque
la solution n'est pas assez teste que l'on peut se planter.
Donc, de manire contre-intuitive, cet indicateur est plutt
un facteur de qualit.
La premire recette technique doit avoir permis de rgler la
plupart des anomalies de base. Si cela nest pas le cas, un
recadrage peut savrerncessaire pour viter l'puisement
des utilisateurs en cours de recette.
L'autre nuance que l'on peut apporter est de dterminer si
les corrections sont efficaces. Des problmes lis aux
performances qui ne peuvent tre corrigs indiquent peut-
tre des problmes importants lis la conception.
12
-
7/30/2019 Sauvetage de Projet
13/27
-
7/30/2019 Sauvetage de Projet
14/27
Le diagnostic est sans appel : votre projet est plant. Pas de
panique, TheCodingMachine vous apporte des solutions !
Poser le bon diagnostic rsout une grande partie du
problme, car une fois que les problmes sont identifis, il est
possible de mettre en place un plan dactions efficace.
Pour garantir un rsultat fiable et srieux, solliciter une socit
extrieure reste, notre avis, la meilleure option (si vouschoisissez cette solution, n'hsitez pas nous appeler). Car la
toute premire tape consiste se dbarrasser des
problmes priphriques qui accompagnent invitablement
la drive dun projet et parasitent notre vision. Faire appel
un tiers qui est indpendant et sans a priori permet de
dpassionner le dbat.
L'importance du contexte
Russir le sauvetage d'un projet ncessite de plonger au
cur du problme afin de dresser un tableau objectif de
l'tat du projet. Quels sont les problmes ? Peuvent-ils tre
rsolus rapidement ? Par qui et de quelle manire ?
Les solutions dpendent troitement de l'tat du projet : le
projet est-il encore en dveloppement ou bien en
production. Elles dpendent aussi de la nature des
problmes : est-ce un problme technique ? Un problme
concernant le primtre ? Ces solutions dpendent
videmment de la taille du projet. Plus un projet est petit,
plus il est simple de le reprendre depuis le dbut.
14
-
7/30/2019 Sauvetage de Projet
15/27
Mthode 1 : Ne pas avoir peur de supprimer leproblme
Si les problmes ont une origine technique, l'application
dveloppe a peu de chance d'tre "sauve". Corriger des
erreurs graves de conception de l'architecture est souvent
trs coteux. A budget quivalent, il vaut mieux reprendre
les dveloppements techniques "from scratch".
Lanalyse de lexistant doit donc tre mticuleuse pour viter
de jeter une application qui pourrait tre sauve, mais
galement pour ne pas vouloir sauver cette application
tout prix et faire durerlchec.
Mthode 2 : Grer les problmes priphriques :quelles solutions pour grer les problmeshumains ?
Il faut tout d'abord tablir un constat d'chec. Cela semble
vident aux chefs de projets dont le prestataire est
dmissionnaire. Pour celui qui aura un prestataire qui tente
de le rassurer, lui promet d'aboutir et qui tente de garder une
bonne relation, tablir ce constat sera, en revanche, difficile.
Si l'application mrite d'tre sauve, il est ncessaire de
s'attaquer aux problmes humains. C'est souvent dlicat car
les sentiments qui agitent les parties sont rarement
bienveillants. Il est toujours douloureux de se tromper ou
d'avoir le sentiment de s'tre fait avoir par un prestataire peu
scrupuleux. Se lamenter n'est pourtant pas une solution.
15
-
7/30/2019 Sauvetage de Projet
16/27
Impossible, malheureusement, d'indiquer ici une solution
universelle. Nous vous recommandons bon sens et
pragmatisme : tes-vous victime de votre prestataire ou bien
de vous-mme ? Est-ce que changer le management du
projet va vous permettre de porter un nouveau regard sur le
projet, apporter une nouvelle motivation l'quipe ? Est-il
possible de crer un lectrochoc, de dclencher une prise
de conscience de la part des quipes ?
Dans ce domaine, la crativit n'a pas de limites. Voici une
prsentation des pistes les plus videntes et les plus
efficaces.
1. Le dsengagement du prestataire (et son ventuel
remplacement), permet souvent de voir le projet avec un
il neuf afin d'vacuer les problmes rcurrents. Ce
dsengagement est-il souhaitable, possible ? Quels cotssupplmentaires va-t-il engendrer ? Quels bnfices va-t-il
rapporter ? Comment envisager la phase de transition ?
2. Faire une pause, pour se remettre les ides en place et se
rorganiser : Cette pause est-elle souhaitable, possible ?
Combien de temps (trop risquerait de mettre fin au projet) ?
Qui et comment planifier la suite du projet ?
16
-
7/30/2019 Sauvetage de Projet
17/27
3. Changer les quipes peut redonner un second souffle au
projet. Les quipes uses vont tre remplaces par du sang
neuf. Pour cela il est ncessaire que limage du projet ne soit
pas trop dgrade afin de ne pas dcourager les nouveaux
collaborateurs. Ce changement est-il souhaitable, possible ?
Quelle organisation mettre en place, qui conserver ?
4. Relancer les dveloppements par tape, morceler les
problmes, permet den voir le bout et ainsi de se motiver.
Peut-tre est-il possible de dcouper le projet en sous-
ensembles ? Le cot de cette rorganisation est-il
supportable ? Les quipes sont-elles prtes ce
changement ?
-
7/30/2019 Sauvetage de Projet
18/27
Mthode 3. Grer les problmes techniques
Si le projet peut-tre sauv, alors allons-y, nattendons plus !Ce qui n'empche pas d'intgrer mthode et rigueur notreopration de sauvetage.
Pour identifier les risques et les actions associes la reprisede votre projet, plusieurs techniques sont envisageables.Nous vous en proposons une qui a le mrite d'tre la foissimple partager et facile appliquer :
Classement des risques et actions :
- Impact : le cot associ la survenance du risque. Par
exemple, la chute de la base de donnes principale a un
cot suprieur la chute dun serveur de mail;
- Probabilit : la probabilit de survenance du problme;
- Effort de correction : le cot associ la mise en place
dun correctif;- Catgorie : la catgorie associe au risque (architecture,
scurit du code, ).
18
XXX: Description du risque et de laction associe
Catgorie
Impact:
Probabilit:
Faible/Moyen/Fort : description de limpact
Faible/Moyen/Fort : probabilit de survenance delvnement
Effort deCorrection:
Facile/Moyen/Complexe: description des tchesncessaires pour corriger le problme
-
7/30/2019 Sauvetage de Projet
19/27
Les actions sont ensuite places sur un quadrant :
- En abscisse: impact * probabilit;
- En ordonne: complexit de mise en place du correctif.
Les actions du quadrant en bas droite seront les actionsprioritaires. On remontera progressivement alors vers lasection en haut gauche.
19
Facile
complexe
CritiqueNice to have
A5
A13
A14A8
A6A15
A3A11A4
A2
A7A17
A9A10
A12
A1A16
-
7/30/2019 Sauvetage de Projet
20/27
Les problmes de performances passent souvent la trappedans les projets. Ils apparaissent souvent en fin de mission, s'ilsn'ont pas t anticips, et demeurent difficilementdtectables avant la mise en production du projet.
TheCodingMachine a consacr un Livre Blanc ce sujet.Nous y avons indiqu comment analyser et traiter cesproblmes particuliers. Vous pouvez tlcharger le
document cette adresse :http://www.thecodingmachine.com/fr/hautes-
performances-web
20
http://www.thecodingmachine.com/fr/hautes-performances-webhttp://www.thecodingmachine.com/fr/hautes-performances-webhttp://www.thecodingmachine.com/fr/hautes-performances-webhttp://www.thecodingmachine.com/fr/hautes-performances-webhttp://www.thecodingmachine.com/fr/hautes-performances-webhttp://www.thecodingmachine.com/fr/hautes-performances-webhttp://www.thecodingmachine.com/fr/hautes-performances-webhttp://www.thecodingmachine.com/fr/hautes-performances-webhttp://www.thecodingmachine.com/fr/hautes-performances-web -
7/30/2019 Sauvetage de Projet
21/27
Les projets et les situations voqus ici tant purement fictifs,toute ressemblance avec des projets existants ou ayant
exist ne saurait tre que fortuite
-
7/30/2019 Sauvetage de Projet
22/27
Le projet : Dans le cadre de la dmatrialisation de sescorrespondances avec ses clients, cette filiale d'un acteurmajeur de la banque-assurance a demand unprestataire de crer un systme de gestion lectronique dedocuments (ou GED). Le projet comprenait l'externalisationde louverture et de la numrisation du courrier, puis ladistribution du courrier sous forme dmatrialise traversune application qui grait les workflows de demandes client.
Notre intervention : Devant les retards accumuls
pendant le dveloppement de ce projet et lesdysfonctionnements constats, TheCodingMachine a tmandate pour conduire un audit, analyser finementlapplication et dessiner le primtre dun plan desauvetage.
Problmes dtects :L'architecture de la solution avaitt trs mal pense. Les donnes taient distribues dansdeux bases de donnes distinctes. Le prestataire tait partiavec un outil open-source et une technologie qu'il ne
matrisait pas. Les temps de rponse taient parfois difficile supporter pour les utilisateurs et rendaient mme parfoisl'application inutilisable (avec des temps de rponse parfoissuprieurs 5mn). L'application tait instable, avec parfoisdes arrts de production de plusieurs jours.
Solutions apportes : Le processus de build et lutilisationsystmatique de caches et sessions ont permis de consoliderlapplication sans remettre en cause les fondements deloutil. Lindustrialisation des dveloppements, la mise en
place de bonnes pratiques ainsi que le lancement de testsautomatiss pour garantir les non rgressions assurent lastabilit de lapplication dans la dure.
Notre avis : Le cot du projet (500k) rendait difficile unabandon pur et simple de la solution. Il aurait peut-tremieux valu. Notre intervention aura cot 50k pour rendrel'application utilisable.
22
-
7/30/2019 Sauvetage de Projet
23/27
Le projet : Le client, dans le domaine de l'immobilier,souhaitait proposer ses collaborateurs un Intranet :prsentation des informations, gestion des formations,reporting etc.
Notre intervention : En rupture avec son ancienprestataire, le client devait montrer que son projet n'tait pasen chec. Une partie de la conception a donc t reprisepour conserver le schma relatif de base de donnesassoci la gestion des utilisateurs notamment.
Problmes dtects : La technologie tait parfaitementinadapte aux besoins. Inexprience du prestataire sur cetype de projet (spcialiste des sites vitrines).
Solutions apportes : Refonte du projet dans des dlaisrecord avec un budget rduit: 50k avait dj t dpens,il ne restait plus que 30k de budget pour faire le projet. Unerallonge de 15k a pu tre obtenue. La structure du code atotalement t revue (utilisation dun framework MVC,utilisation de bibliothques open source, etc.).
23
-
7/30/2019 Sauvetage de Projet
24/27
Le projet : Grande franchise lie l'esthtique, le clientsouhaitait proposer la vente de ses services en ligne. C'estune agence marketing qui avait remport le projet, qu'ellesous-traitait, pour la partie technique, une SSII tunisienne.Avec les profonds changements apports par la rvolution,et compte tenu du manque de marge de manuvreautoris par le budget, le projet avait t abandonn par leprestataire.
Notre intervention : Pour respecter les dlais, priorit trs
forte du client, nous avons conduit le sauvetage du projet endeux temps :- nous avons pur le primtre pour mettre en pr-production une version testable par le client et lui permettreainsi d'avoir une visibilit sur les avances du projet,- en parallle, nous avons men finalis le dveloppementdu primtre initial.
Problmes dtects : Nous avons rapidement constatque le projet avait t considrablement sous-estim par
l'agence.
Solutions apportes : Larchitecture initiale (utilisation deMagento) a t conserve. En revanche, nous avonsredvelopp ou reconfigur lensemble des fonctionnalitsspcifiques (multi-boutique, thme, autres modulescomplmentaires).
Notre avis : Effectuer un sauvetage de projet pour lecompte d'un tiers (et non du client final) n'est pas possible.
La communication et le ressenti client est primordial dans cegenre de sauvetage. Il faut se positionner en frontal clientpour le rassurer au mieux. Ne pas partir avec une agence quidnigre la technique !
24
-
7/30/2019 Sauvetage de Projet
25/27
Le projet : Cette socit de vente par correspondance etde vente domicile avait dcid de refondre son systmed'informations (approvisionnement, vente, facturation, etc.).Le choix dun prestataire off-shore et dune organisationcomplexe (pas de communication directe, passage par untiers, etc.) avait conduit le client utiliser en production uneapplication moiti finie.
Notre intervention : Nous avons commenc par un audittechnique de la solution existante (bien que peu de
fonctionnalits aient t abouties). Puis nous avons dcid,conjointement avec le client, dune nouvelle organisation.
Problmes dtects : Deux problmes majeurs ont tdtects :1. Aucune spcification prcise des fonctionnalitsnexistait, les dveloppements avaient tous t mens au filde leau partir d'un document gnral.2. Quand les relations sont devenues tendues entre leclient et le prestataire, les dveloppements ont t
acclrs au dtriment de la qualit technique et des rglesde codage (utilisation des outils installs).
Solutions apportes : Nous sommes repartis du point leplus avanc des dveloppements respectant les rgles etstandards en essayant, au maximum, de rcuprer et derutiliser les fonctionnalits dveloppes. Nous avons ensuiterorganis les dveloppements en crivant les spcificationsmanquantes et en estimant/priorisant au pralable chaquetche.
Notre avis : Il ne faut jamais abandonner les rgles debase de la technique dans le seul but de gagner du temps.Cela savre souvent contre-productif pour la bonneconduite dun projet. Le projet en serait, au mieux, tropcompliqu maintenir, et, dans le pire des scenarii,impossible faire aboutir.
25
-
7/30/2019 Sauvetage de Projet
26/27
Ces mthodes ne s'appliquent pas les unes isoles des autres
mais bien souvent de front. On peut estimer simplement si
cela vaut la peine de sauver l'application en tablissant le
quadrant de gestion des problmes techniques. Ce
quadrant peut aussi tre utile pour diagnostiquer
rationnellement et donc accepter plus facilement que le
projet est vraiment en panne.
Notre exprience nous a montr que la plupart des
problmes peuvent trouver une solution technique mme si
elle est parfois coteuse. Le point le plus dlicat grer se
situe bien souvent dans les relations entre les parties
prenantes. Des relations conflictuelles induites par des
checs accumuls sur un projet s'avrent parfois difficiles
neutraliser. Il est pourtant important de dpassionner les
dbats pour permettre des dcisions rflchies et
rationnelles d'merger, motives par la russite finale du
projet.
Mme s'il est compliqu de gnraliser ce type de
problmatique, nous esprons que ce livre blanc vous aura
au moins donn un peu de courage si votre projet est
l'arrt, en panne ou mme carrment rat.
Evidemment, de nombreux lments mriteraient d'tre
approfondis. N'hsitez pas nous contacter si vous souhaitezen discuter.
26
-
7/30/2019 Sauvetage de Projet
27/27
The licensor permits others to copy, distribute, display, and perform the work. In return,
licenses must give the original author credit.
The licensor permits others to copy, distribute, display, and perform the work. In return,
licenses may not use the work for commercial purposes -- unless they get the licensor's
permission.