Ce billet concerne plutôt les entreprises de taille moyenne à grande.
J’ai déjà parlé dans des billets précédents, de l’effet de bord d’un projet IT très très cher :
En général, de tels projets sont validés par la direction générale.
Et, comme par magie, le projet est « toujours » un succès.
Pourquoi ?
Parce que si ce n’était pas le cas, la direction serait « challengé ».
Donc, même si dans la pratique c’est pas si rose que ça, on va s’arranger pour dire que « tout va bien ».
Qui ira vraiment vérifier ?
Les équipes vont se débrouiller, jongler entre excel et des applications instables, la communication sera : « on track ».
Et bien parfois, un autre scénario se produit : la mort du projet.
Le scénario est le suivant :
Un projet « mastodonte » est lancé.
A un moment donné, quelques années plus tard, un dirigeant, n’ayant pas trempé dans la décision, regarde le truc, et fait une rapide analyse :
- ça a coûté combien ?
- ça a rapporté quoi ?
Et là, rapidement, la décision va être prise d’arrêter le projet.
le projet est donc mort d’avoir coûté trop cher, au démarrage, et donc d’avoir, les premières années, un bilan « indéfendable ».
Quelle est la différence entre les deux scénarios ?
Finalement, dans le deuxième projet, on peut se dire que la décision n’a pas été prise assez haut, et que le projet n’a pas été vendu assez cher ;).
Plus sérieusement, c’est pour moi un élément complémentaire pour pousser des solutions par étapes, avec une monté en puissance très progressive.
Il faut éviter à tout pris les projets « cathédrale », qui coute cher, sont long à faire, et ont des résultats très incertains.
Il vaut tellement mieux privilégier une approche « agile », par étapes.
Mais pour cela, les mentalités doivent énormément évoluer !
Ah ça… J’en ai connu des projets cathédrales ! La fameuse montagne qui accouche d’une souris…
Plus sérieusement, je crois qu’en France, on commence à sortir de cette logique « il-faut-penser-à-tout-avant-même-si-la-phase-d-etude-doit-durer-neuf-mois ». On se rapproche du modèle de projets anglo-saxon. Certes moins perfectionniste, moins esthétisant, mais plus pragmatique. Plus « time-to-market ».
Tant que le donneur d’ordre ne s’identifie pas pleinement avec le projet, rien ne changera. Pour la réussite d’un projet, il faut être motivé par son accomplissement, et pas par quelque objectif conditionnant le montant du bonus. Le projet a pour but d’apporter quelque chose à l’entreprise: c’est ce qui doit motiver les parties internes.
Concevoir, faire construire et suivre les travaux de sa maison est très formateur à ce sujet:
– on est super motivé et on prend le projet à coeur
– on regarde le budget d’un autre oeil
– on apprend à faire des compromis
– on apprend à prendre et à assumer les décisions
– une fois le béton coulé, on ne vient plus avec d’autres idées, aussi bonnes soient-elles.
J’utilise souvent l’analogie du bâtiment, mais j’obtiens encore trop souvent des réponses du type : « vous êtes bon non ? si on signe ensemble vous devez être agile et on doit pouvoir tout changer si ça ne marche pas, ok ?! » Ouais, mais il faut aussi maitriser son budget mon cher monsieur…
Reste que j’ai quand même le sentiment que ça change et que les DSI des grosses boites sont de plus sensible à ce genre de problématique.
Et je pense que les projets e-commerce y sont pour beaucoup : la rentabilité doit être rapide !