Sauvetage de Projet

7/30/2019 Sauvetage de Projet

1/27


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


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


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


5/27


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/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


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]


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.).


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


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


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


13/27


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


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


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


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 ?


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


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


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


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


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


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


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


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


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


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.

Sauvetage de Projet

Documents

Transcript of Sauvetage de Projet