Conseils en conduite de projet (côté client) ?

[aggelon]

Salut les loulous,

Je ne sais pas trop si c'est le lieu pour parler de cela, alors pour faire court : auriez-vous des liens à me proposer pour obtenir des conseils généraux sur la conduite de projet ?

J'ai pas mal de questions en tête, je suis client face à un prestataire inconséquent, je pense qu'il va falloir que je formalise un peu plus ma relation avec lui mais j'y connais tellement rien que je ne sais même pas si le mot "conduite de projet" est le bon

Un caneton compétent pour m'indiquer où se trouve la lumière ?

Merci

[scie_sauteuse]

Moi j'ai une autre question, qui ne t'aidera probablement pas et qu'il ne faut pas mal prendre :
Pourquoi t'es en face du client à devoir le gérer si t'as pas la formation qui va avec ? Ça s'invente pas comme boulot... Je suis généralement du côté du prestataire, et je peux te dire qu'un client qui ne sait pas bosser avec des prestataires, c'est au moins aussi risqué qu'un presta qui ne fait pas son boulot pour un projet... Bon, on n'a pas beaucoup d'infos dans ton post et ce n'est peut-être pas nécessaire de nous en donner plus, mais ça m'étonne comme situation.
J'espère que tu t'en sortiras bien

[aggelon]

Salut scie,

Je ne suis pas sûr de m'être bien expliqué (c'est moi le client ), alors si personne n'a de lien à me filer, je veux bien qu'on continue en MP, car j'ai quelques questions en tête et je suis preneur de conseils

Merci.

[scie_sauteuse]

Salut scie,

Je ne suis pas sûr de m'être bien expliqué (c'est moi le client ), alors si personne n'a de lien à me filer, je veux bien qu'on continue en MP, car j'ai quelques questions en tête et je suis preneur de conseils

Merci.

Si si j'avais bien compris que c'était toi le client ! Je m'étonnais justement que tu te retrouves à gérer des prestataires sans formation, alors que justement c'est une relation qui peut mal tourner si les deux n'arrivent pas à travailler ensembles, que ça soit du fait du client ou du fait du prestataire, et que j'aurais dit qu'il y avait des choses à savoir qui méritaient une petite formation...
Sinon je ne suis pas sure de pouvoir t'aider, je suis plutôt du côté prestataire et technique (dans l'informatique) donc pas vraiment en contact avec le côté "pilotage de projet" du client, mais plutôt de leurs équipes techniques. Ce sont mes chefs de projets qui gèrent la relation client proprement dite, côté respect des engagements, contrats, etc. M'enfin si tu veux demande toujours, je te dirai !

[deathdigger]

Déjà il faudrait savoir de quel type de projet on parle.

[smokytoks]

Pas mieux, balance plus d'infos : secteur d'activité, contexte, type de projet/contrat, etc...

J'suis pas le plus carré que l'on puisse trouver, loin de là, mais j'ai pratiqué (et pratique encore) ça des deux côtés, si c'est pas trop éloigné des domaines que je connais, devrait y avoir moyen de te filer quelques pistes...

[aggelon]

Salut les copaings,

Allez, n'ayons honte de rien, vous saurez tout

Voici le contexte : je suis "informaticien" (le seul) dans une PME de transports. Ca veut juste dire que je m'occupe de tout ce qui est technologique : la hotline/maintenance, un peu de VBA, la téléphonie, etc... un genre de tech généraliste...

Notre secteur d'activité est très concret et demande une forte réactivité. De ce fait, nous travaillons de manière pragmatique et ne formalisons guère (pas de réunionite chez nous).

Je n'ai aucune connaissance en méthodologie de conduite ou gestion de projet
Jusqu'à présent, dans le choix de nos prestataires, on se contentait de passer au crible leurs propositions à travers une grille d'évaluation maison et cela s'est toujours très bien passé : on passe commande, le presta fait le job, on paye et on passe à la suite.


Là, on parle de l'installation d'un progiciel métier. On l'a acheté directement chez l'éditeur, qui se charge de sa mise en oeuvre (install et formation).

Malheureusement, je suis aujourd'hui confronté à un prestataire qui s'est engagé à la légère (vous me direz, nous aussi ? )

Lors de l'évaluation de sa proposition, il a répondu favorablement à un certain nombre de critères mais étant hors périmètre standard, il se rend compte aujourd'hui que ces spécifiques vont lui couter beaucoup plus cher que ce qu'il avait imaginé.
Quant au planning, il est complétement en retard.

Il vient d'adopter une position consistant à dire que c'est nous qui avons mal compris, qu'il a réalisé tout ce qui était écrit dans le "contrat" et que toute demande ne faisant pas partie du contrat ferait l'objet de devis complémentaires.
Il nous annonce déjà que ces devis seront payants !


Dont acte : il va falloir faire avec.



J'imagine qu'il va me falloir changer de méthode de travail pour à l'avenir (en général, et en particulier les futurs devis qu'il va me soumettre) éviter de me retrouver dans une situation similaire.

J'ai plein de question qui tournent en rond dans ma tête :


Ma première question concerne la sélection : nous avons "évalué" le logiciel proposé, en avons déduit qu'il nous convenait et avons signé un bon de commande standard.
J'imagine difficilement que nous n'ayons pas poussé assez loin l'évaluation car notre grille comportait plus d'une centaine de critères organisés par thèmes et criticité.
Par contre, aussi loin que l'on puisse pousser la chose, je ne sais pas comment améliorer cette étape. Je ne sais pas comment illustrer ma pensée, mais pour prendre une comparaison, avant d'acheter Word ou Excel, est-ce que vous allez vérifier que le bouton 'Mettre en italique' demeure accessible lorsque votre texte se trouve de couleur mauve dans un tableau par exemple ?
Non, bien sûr que non, c'est le genre de contraintes auxquelles on ne pense pas et que l'on ne découvre qu'à l'usage. Et quand l'éditeur du logiciel vous répond : "Il ne s'agit pas d'un bug : notre logiciel est fait ainsi !", quels sont les recours ? A tout le moins, comment mieux anticiper en améliorant l'évaluation avant l'achat pour éviter d'être confronté à ce genre de situation ?

Ceci étant dit, il va maintenant falloir que je le fasse s'engager sur des points précis.

Seconde question : imaginons maintenant que nous ayons pensé à inclure Italique_mauve_dans_un_tableau dans nos critères et qu'au moment de l'évaluation, l'éditeur nous regarde en souriant l'air de dire "vous êtes un peu casse-couilles avec vos pinaillages" et nous réponde "évidemment que le bouton Italique demeure accessible".
Ce que nous avons fait, c'est cocher dans notre liste pour indiquer que le critère était rempli.
A l'usage, nous nous rendons compte que ce n'est pas le cas et nous n'avons que la "parole" du prestataire, aucune trace écrite. Ce que je veux dire, c'est que même avec un document amélioré grâce aux réponses de ma première question, ce document reste un document interne, non contradictoire, sur lequel le prestataire ne s'est pas engagé par écrit : comment et à quel étape du projet faut-il le faire s'engager ?
Je veux dire : nous, on a signé un bon de commande type, rédigé par le prestataire. Peut-on rédiger nos propres conditions, par exemple dans une annexe, et demander à ce que figure dans le bon de commande une mention stipulant que le prestataire s'engage à réaliser ce qui est inscrit dans l'annexe ?


Troisième question: dans ce cas, je suppose que dans la liste de ce que nous aimerions avoir, tout ne sera pas techniquement et financièrement réalisable, ce qui veut dire qu'il faut qu'on se mette d'accord avant la signature sur le périmètre de ce qui est demandé.
Comment pratique-t-on ?

Je rédige un cahier des charges "utopique" en amont, je le synthètise sous la forme de ma petite grille d'évaluation, puis après passage au crible avec eux, j'aménage mon cahier des charges pour ne conserver que les clauses sur lesquelles il déclare pouvoir répondre, puis je lui transmets pour signature ?

Par contre, tous les critères ne sont pas simplement oui/non : il peut y avoir certains critères pour lesquels la presta/le soft proposés n'apporte pas une solution telle que nous l'avons a priori imaginée, mais peut y répondre par un workaround voir par une solution plus simple/souple/élégante... il faudrait donc laisser une part de "proposition" au presta... Je leur envois donc un cahier des charges sous forme de questions et ils répondent sous forme de propositions ?


Je suis un peu perdu


Quatrième question: non seulement il va nous falloir agir ainsi sur les fonctionnalités, mais également sur le planning.
Comment cela se passe-t-il ?
On part d'une feuille vierge sur laquelle nous posons nos contraintes, et à partir de là le prestataire nous propose un planning prévisionnel ?
Ce planning, il faut l'établir pendant la négociation avant la signature du contrat, puis qu'il fasse partie du contrat signé afin de s'assurer que le prestataire s'engage ?
Dans ce cas, il faut aussi l'intégrer dans l'annexe ?


Cinquième mais difficile question: comment formaliser qu'ils ont honorés leurs engagements ? En définissant des critères d'achèvement ?

Corollaire: étant rarement tout ou rien, il faut indiquer pour chacun de ces critères d'achévement une méthode d'évaluation ? Genre "vous avez rempli 80% de vos engagements sur ce critère" ? Et sur les délais ?

Pfff... j'ai l'impression de m'engager sur la voie d'une usine à gaz


Sixième question: une fois évalués leurs pourcentages de réalisation, que faire ? Inclure pour chacun des critères des clauses de pénalités ? Comment estimer ces pénalités, sachant que ce n'est pas le fait de percevoir des indemnités financières qui va débloquer la situation et nous amener la fonctionnalité qu'il nous manque...



Septième question: cette "organisation du projet", qui me semble somme toute comme allant de soi car étant la moindre des choses (nous n'avons jamais eu problème avec nos projets précédents), je sens bien que mon prestataire va arguer que cela va générer un surcoût au projet et sans doute vouloir inclure des coûts de "conduite de projet"...
Bien que je ne vois en quoi "prévoir" des dates à l'avance et définir une mesure du taux d'avancement coute, comment peut-on évaluer ce surcoût afin d'éviter de se faire arnaquer ? Il existe des grilles tarifaires standards pour les coûts à la journée (genre SYNTEC ou un truc du genre) ? Quels sont les usages sur le nombre de jours ?

Je parlais au début du message que les devis seront payants. J'imagine qu'il va nous facturer une sorte d'étude de faisabilité...
Comment évaluer cela ?
Rien ne lui empêche de proposer 3 jours d'étude de faisabilité facturables, au bout de 3 jours nous proposer un devis exhorbitant, et au final nous allons nous retrouver à avoir payé 3 jours/homme pour nous rendre compte que nous ne signerons pas le devis...


Bref, comme je l'ai dit, on est habitué à commander et à être livré, à travailler avec des presta sérieux qui font bien leur job et font leur maximum pour arriver au résultat, et là c'est la première fois qu'on voit un désastre pareil sur une presta (paramétrages inadaptés, mails avec screenshot circonstanciés qui restent sans réponse, etc...), je suis donc en plein brouillard et j'ai bien besoin de méthodologie
Comment et à quels moments les faire s'engager sur un résultat et un planning ?

On pourrait annuler la commande et aller voir ailleurs, mais sincèrement de tout ce qu'on a consulté, c'est le soft qui est le plus adapté à notre besoin et on est presque au bout... c'est juste la mise en oeuvre qui est laborieuse... et il va me falloir mieux gérer la suite... mais je ne sais pas comment formaliser cela...

Voilà, maintenant vous savez tous que je suis un incompétent

[scie_sauteuse]

Waouh, c'est un sacré paté que tu nous as fait !
Dans l'immédiat, je pense que tu te poses les bonnes questions. Tu as identifié les points qu'il fallait formaliser et cadrer, et à partir de là c'est déjà un bon début.
Si j'ai un poil de temps dans les jours à venir j'essaierai de t'aider à partir des projets auxquels j'ai pu participer, mais je ne suis pas certaine de pouvoir...

[Neo_13]

Avant TOUT (pour toi) : que dit le contrat ? que disent vos échanges écrits (même les mails, y/c sans réponses) ? le presta est beaucoup plus gros que toi ? Ces 3 points seront nécessaires en cas de contentieux.

Voici le contexte : je suis "informaticien" (le seul) dans une PME de transports. Ca veut juste dire que je m'occupe de tout ce qui est technologique : la hotline/maintenance, un peu de VBA, la téléphonie, etc... un genre de tech généraliste...

As-tu le pouvoir de DECISION sur ces périmètres ? (je veux dire pour acheter un truc ou modifier en profondeur quelque chose)

Notre secteur d'activité est très concret et demande une forte réactivité. De ce fait, nous travaillons de manière pragmatique et ne formalisons guère (pas de réunionite chez nous).

Pas d'incompatibilités en réunions et réactivité. Surtout en conduite de projets.

Je n'ai aucune connaissance en méthodologie de conduite ou gestion de projet

En même temps, c'est un métier et une formation, donc si ton employeur en a vraiment besoin, ... qu'il t'envoie en formation.

Jusqu'à présent, dans le choix de nos prestataires, on se contentait de passer au crible leurs propositions à travers une grille d'évaluation maison et cela s'est toujours très bien passé : on passe commande, le presta fait le job, on paye et on passe à la suite.

Par grille, tu entends quoi ? "Le prestataire dit que" ou vous avez fait une recette ? La recette est-elle connue du prestataire à l'avance ?

Là, on parle de l'installation d'un progiciel métier. On l'a acheté directement chez l'éditeur, qui se charge de sa mise en oeuvre (install et formation).

Malheureusement, je suis aujourd'hui confronté à un prestataire qui s'est engagé à la légère (vous me direz, nous aussi ? )

C'est quoi le lien entre l'éditeur et le prestataire ?

Lors de l'évaluation de sa proposition, il a répondu favorablement à un certain nombre de critères mais étant hors périmètre standard, il se rend compte aujourd'hui que ces spécifiques vont lui couter beaucoup plus cher que ce qu'il avait imaginé.

Son problème, si il a signé un contrat qui dit qu'il fera. Et en partie le vôtre : que ce soit de sa faute entièrement n'exclut pas forcément que vous fassiez preuve de goodwill en lui accordant une rallonge partielle.

Quant au planning, il est complétement en retard.

Qui l'a construit ? S'est-il engagé contractuellement à le respecter ?

Il vient d'adopter une position consistant à dire que c'est nous qui avons mal compris, qu'il a réalisé tout ce qui était écrit dans le "contrat" et que toute demande ne faisant pas partie du contrat ferait l'objet de devis complémentaires.

Et c'est vrai ou pas ?

Il nous annonce déjà que ces devis seront payants !

Si ce sont effectivement des trucs en plus, normal. Sinon, non.

Dont acte : il va falloir faire avec.

A négocier, mais c'est possible

J'imagine qu'il va me falloir changer de méthode de travail pour à l'avenir (en général, et en particulier les futurs devis qu'il va me soumettre) éviter de me retrouver dans une situation similaire.

Être maitre d'ouvrage (ce qui correspond à ce que tu décris), ça s'apprend aussi. Formation pas forcément longue pour les bases, mais inévitable pour éviter la merde.

J'ai plein de question qui tournent en rond dans ma tête :


Ma première question concerne la sélection : nous avons "évalué" le logiciel proposé, en avons déduit qu'il nous convenait et avons signé un bon de commande standard.
J'imagine difficilement que nous n'ayons pas poussé assez loin l'évaluation car notre grille comportait plus d'une centaine de critères organisés par thèmes et criticité.
Par contre, aussi loin que l'on puisse pousser la chose, je ne sais pas comment améliorer cette étape. Je ne sais pas comment illustrer ma pensée, mais pour prendre une comparaison, avant d'acheter Word ou Excel, est-ce que vous allez vérifier que le bouton 'Mettre en italique' demeure accessible lorsque votre texte se trouve de couleur mauve dans un tableau par exemple ?
Non, bien sûr que non, c'est le genre de contraintes auxquelles on ne pense pas et que l'on ne découvre qu'à l'usage. Et quand l'éditeur du logiciel vous répond : "Il ne s'agit pas d'un bug : notre logiciel est fait ainsi !", quels sont les recours ? A tout le moins, comment mieux anticiper en améliorant l'évaluation avant l'achat pour éviter d'être confronté à ce genre de situation ?

Ecrire une recette de réception contractuelle. C'est ultra chiant, mais il faut.

Ceci étant dit, il va maintenant falloir que je le fasse s'engager sur des points précis.

Seconde question : imaginons maintenant que nous ayons pensé à inclure Italique_mauve_dans_un_tableau dans nos critères et qu'au moment de l'évaluation, l'éditeur nous regarde en souriant l'air de dire "vous êtes un peu casse-couilles avec vos pinaillages" et nous réponde "évidemment que le bouton Italique demeure accessible".
Ce que nous avons fait, c'est cocher dans notre liste pour indiquer que le critère était rempli.
A l'usage, nous nous rendons compte que ce n'est pas le cas et nous n'avons que la "parole" du prestataire, aucune trace écrite. Ce que je veux dire, c'est que même avec un document amélioré grâce aux réponses de ma première question, ce document reste un document interne, non contradictoire, sur lequel le prestataire ne s'est pas engagé par écrit : comment et à quel étape du projet faut-il le faire s'engager ?
Je veux dire : nous, on a signé un bon de commande type, rédigé par le prestataire. Peut-on rédiger nos propres conditions, par exemple dans une annexe, et demander à ce que figure dans le bon de commande une mention stipulant que le prestataire s'engage à réaliser ce qui est inscrit dans l'annexe ?

Un contrat est un accord entre 2 parties. Si t'es pas d'accord, tu signes pas et tu proposes le contrat qui TE va.
Maintenant pour les documents internes : c'est un CR de réunion ? A-t-il été envoyé au prestataire ? Y-a-t-il une réunion avec le prestataire après ?
Sinon : il faut rédiger une recette de réception contractuelle. C'est chiant, mais il faut. Comme ça, s'il répond "évidemment", tu t'en fous, la question, c'est de le voir pour de vrai.

Troisième question: dans ce cas, je suppose que dans la liste de ce que nous aimerions avoir, tout ne sera pas techniquement et financièrement réalisable, ce qui veut dire qu'il faut qu'on se mette d'accord avant la signature sur le périmètre de ce qui est demandé.
Comment pratique-t-on ?

C'est le contrat qui fait foi. Donc c'est sur le contrat qu'on se met d'accord.

Je rédige un cahier des charges "utopique" en amont, je le synthètise sous la forme de ma petite grille d'évaluation, puis après passage au crible avec eux, j'aménage mon cahier des charges pour ne conserver que les clauses sur lesquelles il déclare pouvoir répondre, puis je lui transmets pour signature ?

Non :
Je rédige un CdC lettre au père Noël, il répond, vous vous mettez d'accord sur la prestation exécutée, tu rédiges la recette de réception et vous contractualisez par écrit sur le CdC réel et la recette (et les incoterms, Paiements, ...)

Par contre, tous les critères ne sont pas simplement oui/non : il peut y avoir certains critères pour lesquels la presta/le soft proposés n'apporte pas une solution telle que nous l'avons a priori imaginée, mais peut y répondre par un workaround voir par une solution plus simple/souple/élégante... il faudrait donc laisser une part de "proposition" au presta... Je leur envois donc un cahier des charges sous forme de questions et ils répondent sous forme de propositions ?

CdC + recette : si ça peut (ça passe la recette), c'est OK.


La suite plus tard, parce que j'ai le projet de mon client à faire avancer...

---------- Post added at 14h30 ---------- Previous post was at 14h30 ----------

Et au besoin, on peux en parler par skype ou tel...

[aggelon]

Merci pour la réponse détaillée. Je vais prendre le temps de répondre à chacun des points, mais pour l'instant je passe mes journées, nuits et week-end à faire essentiellement du Crystal pour tous les états spécifiques...

Je prendrai le temps de répondre dès que je trouverai 5 minutes de sérénité

[aggelon]

Salut à tous,

Désolé de tarder autant à répondre, mais les journées/soirées/week-end sont complétement saturés

- Avant TOUT (pour toi) : que dit le contrat ? que disent vos échanges écrits (même les mails, y/c sans réponses) ?

Le contrat est assez simple : on a acheté un logiciel et un nombre de jours de main d'oeuvre.
Dès que les échanges de mails ont commencé concernant les manques du logiciels, ils ont commencé à répondre "désolé, c'est pas possible, le logiciel n'est pas conçu comme cela"...

- Le presta est beaucoup plus gros que toi ? Ces 3 points seront nécessaires en cas de contentieux.

Le presta est un peu plus petit que nous.

- As-tu le pouvoir de DECISION sur ces périmètres ? (je veux dire pour acheter un truc ou modifier en profondeur quelque chose)

Oui, notamment pour la partie technique et interface. Concernant la partie fonctionnelle et ergonomie, ce n'est pas moi.

- Notre secteur d'activité est très concret et demande une forte réactivité. De ce fait, nous travaillons de manière pragmatique et ne formalisons guère (pas de réunionite chez nous).
- Pas d'incompatibilités en réunions et réactivité. Surtout en conduite de projets.

Je n'ai malheureusement jamais vécu cela : mon expérience de gens qui organisaient des réunions, c'était toujours une manière de noyer le poisson et de ne pas décider ou de se décharger pour reporter le travail sur d'autres

- Je n'ai aucune connaissance en méthodologie de conduite ou gestion de projet.
- En même temps, c'est un métier et une formation, donc si ton employeur en a vraiment besoin, ... qu'il t'envoie en formation.

Malheureusement, je crois que dans mon entreprise beaucoup d'entre nous devraient y passer, car nous sommes tous responsable de nos achats dans nos domaines... pour l'instant le sujet n'a jamais été abordé car nous n'en avons pas eu besoin : tout s'est toujours bien passé, dans mon service ou dans les autres, pour du matériel ou autres.

Par grille, tu entends quoi ? "Le prestataire dit que" ou vous avez fait une recette ? La recette est-elle connue du prestataire à l'avance ?

C'est un tableau, avec dans chaque ligne un critère, et dans chaque colonne les propositions mise en concurrences.
Ce tableau me sert de ligne directrice lorsque je reçois un fournisseur et m'évite d'oublier des points à aborder.
Je le remplis au fur et à mesure de l'entretien/présentation, puis il sert naturellement de tableau de comparaison.
Nous n'avons malheureusement jamais établi de recette
De ce que tu me dis, ça a l'air d'être ça qui cloche : un premier gros point noir.

C'est quoi le lien entre l'éditeur et le prestataire ?

C'est la même société : l'éditeur a des chefs de projet chargés de la mise en place du soft chez les clients.

[le planning] Qui l'a construit ? S'est-il engagé contractuellement à le respecter ?

C'est nous qui l'avons construit à partir d'éléments indiqués oralement en avant-vente.
Nous avions posé des jalons et lui avons demandé quels étaient les délais entre ces jalons.
Le prestataire ne s'est pas engagé dessus, nous ne lui avons rien fait signé.
Deuxième gros point noir.

[fonctionnalités manquantes, il déclare que nous avons mal compris]Et c'est vrai ou pas ?

Non. On nous a indiqué des fonctionnalités. Ces fonctionnalités n'existent pas.
Nous avons eu récemment une réunion avec notamment leur DG, qui est un des fondateurs de la boite et l'un des premiers concepteurs du soft. Lui aussi était persuadé que certaines de ces fonctions étaient dans le logiciel (on parle notamment de formules de calcul, plus particulièrement de paramètres existants mais non pris en compte par certaines formules).

- Il nous annonce déjà que ces devis seront payants !
- Si ce sont effectivement des trucs en plus, normal. Sinon, non.

C'est la première fois qu'un presta nous annonce des devis payants. Habituellement, les devis sont gratuits.

- Dont acte : il va falloir faire avec.
- A négocier, mais c'est possible

On verra comment évolue notre relationnel...

- J'imagine qu'il va me falloir changer de méthode de travail pour à l'avenir (en général, et en particulier les futurs devis qu'il va me soumettre) éviter de me retrouver dans une situation similaire.
- Être maitre d'ouvrage (ce qui correspond à ce que tu décris), ça s'apprend aussi. Formation pas forcément longue pour les bases, mais inévitable pour éviter la merde.

Oui, c'est bien ce dont je me rends compte

- Ma première question concerne la sélection : nous avons "évalué" le logiciel proposé, en avons déduit qu'il nous convenait et avons signé un bon de commande standard.
J'imagine difficilement que nous n'ayons pas poussé assez loin l'évaluation car notre grille comportait plus d'une centaine de critères organisés par thèmes et criticité.
Par contre, aussi loin que l'on puisse pousser la chose, je ne sais pas comment améliorer cette étape. Je ne sais pas comment illustrer ma pensée, mais pour prendre une comparaison, avant d'acheter Word ou Excel, est-ce que vous allez vérifier que le bouton 'Mettre en italique' demeure accessible lorsque votre texte se trouve de couleur mauve dans un tableau par exemple ?
Non, bien sûr que non, c'est le genre de contraintes auxquelles on ne pense pas et que l'on ne découvre qu'à l'usage. Et quand l'éditeur du logiciel vous répond : "Il ne s'agit pas d'un bug : notre logiciel est fait ainsi !", quels sont les recours ? A tout le moins, comment mieux anticiper en améliorant l'évaluation avant l'achat pour éviter d'être confronté à ce genre de situation ?
- Ecrire une recette de réception contractuelle. C'est ultra chiant, mais il faut.

Donc on écrit la recette avant la signature du contrat, et le presta s'engage dessus. Ensuite, chaque point doit être validé pour considéré que les engagements sont tenus ?

-Seconde question : imaginons maintenant que nous ayons pensé à inclure Italique_mauve_dans_un_tableau dans nos critères et qu'au moment de l'évaluation, l'éditeur nous regarde en souriant l'air de dire "vous êtes un peu casse-couilles avec vos pinaillages" et nous réponde "évidemment que le bouton Italique demeure accessible".
Ce que nous avons fait, c'est cocher dans notre liste pour indiquer que le critère était rempli.
A l'usage, nous nous rendons compte que ce n'est pas le cas et nous n'avons que la "parole" du prestataire, aucune trace écrite. Ce que je veux dire, c'est que même avec un document amélioré grâce aux réponses de ma première question, ce document reste un document interne, non contradictoire, sur lequel le prestataire ne s'est pas engagé par écrit : comment et à quel étape du projet faut-il le faire s'engager ?
Je veux dire : nous, on a signé un bon de commande type, rédigé par le prestataire. Peut-on rédiger nos propres conditions, par exemple dans une annexe, et demander à ce que figure dans le bon de commande une mention stipulant que le prestataire s'engage à réaliser ce qui est inscrit dans l'annexe ?
- Un contrat est un accord entre 2 parties. Si t'es pas d'accord, tu signes pas et tu proposes le contrat qui TE va.
Maintenant pour les documents internes : c'est un CR de réunion ? A-t-il été envoyé au prestataire ? Y-a-t-il une réunion avec le prestataire après ?
Sinon : il faut rédiger une recette de réception contractuelle. C'est chiant, mais il faut. Comme ça, s'il répond "évidemment", tu t'en fous, la question, c'est de le voir pour de vrai.

Oui, c'est exactement cela dont j'ai besoin.
J'ai depuis commencé à mettre cela en oeuvre : réécrire tout ce qui s'est dit pendant la réunion, pour leur envoyer par mail et leur demander de confirmer ou corriger.
J'ai souvent des réponses sur les paragraphes faciles et aucune réponses (malgré plusieurs relances) sur les points sur lesquels ils ne sont pas clairs...

- Troisième question: dans ce cas, je suppose que dans la liste de ce que nous aimerions avoir, tout ne sera pas techniquement et financièrement réalisable, ce qui veut dire qu'il faut qu'on se mette d'accord avant la signature sur le périmètre de ce qui est demandé.
Comment pratique-t-on ?
- C'est le contrat qui fait foi. Donc c'est sur le contrat qu'on se met d'accord.
- Je rédige un cahier des charges "utopique" en amont, je le synthètise sous la forme de ma petite grille d'évaluation, puis après passage au crible avec eux, j'aménage mon cahier des charges pour ne conserver que les clauses sur lesquelles il déclare pouvoir répondre, puis je lui transmets pour signature ?
- Non : tu rédiges un CdC lettre au père Noël, il répond, vous vous mettez d'accord sur la prestation exécutée, tu rédiges la recette de réception et vous contractualisez par écrit sur le CdC réel et la recette (et les incoterms, Paiements, ...)

OK, maintenant j'y vois plus clair.

- Par contre, tous les critères ne sont pas simplement oui/non : il peut y avoir certains critères pour lesquels la presta/le soft proposés n'apporte pas une solution telle que nous l'avons a priori imaginée, mais peut y répondre par un workaround voir par une solution plus simple/souple/élégante... il faudrait donc laisser une part de "proposition" au presta... Je leur envois donc un cahier des charges sous forme de questions et ils répondent sous forme de propositions ?
- CdC + recette : si ça peut (ça passe la recette), c'est OK.

OK, compris.

La suite plus tard, parce que j'ai le projet de mon client à faire avancer...

---------- Post added at 14h30 ---------- Previous post was at 14h30 ----------

Et au besoin, on peux en parler par skype ou tel...

Merci pour la proposition, je note cela dans un coin de ma tête
Je vais déjà réfléchir à tout cela, voir comment je peux le mettre en oeuvre, aborder en interne la question de la formation.
Ce qui est sûr pour l'instant, c'est que ce projet en cours, c'est mort : il fallait que ce soit fait avant, avant signature.
Ma priorité pour l'instant, c'est de faire aboutir, mais j'espère être moins mauvais pour le prochain.

Merci d'avoir pris le temps de me répondre et de m'éclairer, c'est apprécié.

[deathdigger]

Je n'ai pas tout lu (trop de pavés tue le pavé), mais une seule chose : Contrat de maintenance.

Tu achètes un logiciel pro, tu prends TOUJOURS (TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS, TOUJOURS) un contrat de maintenance.
Comme ça, s'il y'a des merdes après, t'es couvert par ton contrat.

[aggelon]

C'est pas du tout la question : on a le contrat de maintenance. Le truc c'est : "non monsieur, vous avez mal compris ce qu'on vous a dit, notre logiciel ne fait pas ce que le vendeur vous a promis"

[deathdigger]

Ben si ça a été validé par le commercial (et que tu en as la preuve), ben ils se démerdent, ils font en sorte que ça fasse ce que ça doit faire.

[gau]

D'après ce que je comprends de ton histoire, soit le besoin a été mal expliqué / compris, soit on vous a "pipoté" pour vous vendre une solution "top méga" qui en fait ne répond que partiellement au besoin.
Je ne travaille pas au contentieux ou au légal donc difficile de te dire quoi faire pour la suite, mais est-ce que le besoin avait été clairement spécifié dans un document partagé avec le prestataire ? Si des éléments ne sont pas demandés et pas présents, c'est un peu logique que le prestataire s'en dédouane ensuite. En plus tu es sur un progiciel, donc tout développement qui devrait être fait spécifiquement pour toi : couterait une blinde et ne serait pas maintenu par l'éditeur sur les changements de version ! (je travaille sur SAP, un tout petit progiciel, donc je connais le problème des spécifiques ). Si par contre vous aviez expressément demandé des fonctionnalités qui n'y sont pas, vous aurez un peu plus de moyen de pression pour faire avancer les choses.

Pour la prochaine fois, il faut rédiger un cahier des charges le plus précis possible. Parfois on se dit que ce n'est pas la peine d'indiquer tel ou tel point, que c'est évident ... non, il faut tout indiquer !
Sur la base de ce cahier des charges, vous pourrez réaliser des appels d'offres (à ce niveau le degré de précision n'a pas besoin d'être le plus fin possible, mais tous les éléments structurants doivent y figurer) mais surtout vous baser dessus pour contractualiser votre demande avec le prestataire choisi. Sopn job sera de répondre au cahier des charges. Ensuite, il devra réaliser des spécifications détaillées que vous devrez valider. Puis il y aura une phase de recette technique et métier afin de valider la solution proposée.

Voilà dans les grandes lignes comment ça devrait se passer dans les règles de l'art.

Et dis toi que même de grosses boîtes peuvent avoir ce type de problème. Sans trop en dire, ma boite a dépassé de 200M€ le budget initial alloué (60M€ au départ) sur un gros projet et ça se passe extrêmement mal avec le (gros) prestataire. Une paille (et la solution a été vendue comme répondant parfaitement au besoin, facilement paramétrable etc. du gros pipo ^^)

[alverdingo]

merci pour le partage

[humble.jok]

C'est pas du tout la question : on a le contrat de maintenance. Le truc c'est : "non monsieur, vous avez mal compris ce qu'on vous a dit, notre logiciel ne fait pas ce que le vendeur vous a promis"

Dans ma boite précédente, on a eu le cas avec un projet CRM que les utilisateurs n'ont pas voulu filer à l'informatique. Résultat: Ils se sont faits baiser et nous, on a récupéré la merde.
Ils ont choisi Siebel parce que c'était dans le bon cadran du Gartner et que le vendeur disait "oui, on l'a" à tout. Le produit en lui même est une sombre merde mais il aurait été possible d'en faire un truc bien si le projet avait été mené correctement. Au final, le vendeur a fait une démo d'une version CLOUD mais a vendu une version Client/Server classique (qui n'existe plus vraiment maintenant).

Jusque là, ça ressemble à ton projet. Un truc a été vendu mais ce n'est pas ce qui était attendu. Le pire est venu après dans la gestion du projet par des gens du business:
- Un mec qui a posé sa dém le lendemain de la signature
- Son stagiaire
- Un auditeur interne qui "surveillait" tous les projets

Les erreurs qui ont été commise sont les suivantes (je pense que beaucoup ont été citées):
1 - Aucun compte rendu de réunion avec le presta (même pas un pauvre email), il y avait pourtant une réunion par semaine.
2 - Aucun suivi des prestas.
3 - Aucune prise en main ou proof of concept avant achat.

Le point 1, c'est obligatoire. Si il n'y a pas de traces écrites de ce qui a été dit, tu peux faire ce que tu veux mais le presta va te baiser. Il va te mentir sur les fonctions demandées ou carrément ignorer ce qui a été dit. Ils sont pas tous comme ça mais vu le démarrage, ça risque de l'être.

Le point 2, idem. L'informatique, sur ce projet, était cantonné à du support technique (création de serveurs, accès bases de données, ...). Un presta si tu ne contrôles pas ces allées et venues, son activité, ça peut être la fête du slip rapidement. Juste un suivi de présence et d'avancement aurait déjà pu éviter le drame.

Le point 3, ce n'est pas forcément nécessaire mais les projets, que je gérais ou dans lesquels j'étais impliqué, qui ont bien marché sont ceux sur lequel un POC a été réalisé.

Quand mon ex-chef a repris le truc, c'était un drame. Seulement 10% des fonctions vendues étaient présentes mais pire encore, les jours/hommes étaient complètement dépensés. Ils ont viré mon chef de l'époque un mois après (pour d'autres raisons) et m'ont filé le truc. Il a fallu tout reprendre en interne avec un code sans commentaires, sans documentations et sans historique des demandes. 200 jours/homme plus tard (prestas plus interne), il y avait vaguement un truc fonctionnel mais plus adapté au besoin car entre temps, il y a eu la crise de 2008 et un changement profond du marché.
Le cout initial devait être de 400000CHF, ça a fini à 800000CHF sans compter les ressources internes (2 gars en full-time dessus ou presque).

Je raconte ma vie pour te prévenir que tu risques d'en chier surtout si ton fournisseur/presta est gros et que ta boite est pas énorme. Nous, on a du se battre contre Oracle et c'est impossible de gagner même quand ton patron sniffe de la coke avec Ellison.

Si tu reprends correctement le truc, tu as des chances de t'en sortir.

Je peux te conseiller un petit bouquin sans prétention mais très très bien foutu: http://www.amazon.fr/Chef-projet-par.../dp/2840827727
Ce sont beaucoup de lapalissades mais c'est toujours bon de se les rappeler.