Il y a aussi le concept du 2 sur 3 au niveau du Temps – Qualité – Prix … Si pour le client, le temps est le plus important, ça donne une bonne indication de l’importance de la date…

Je continue de croire que tout est négociable et par négociation ça implique que les 2 parties doivent avoir une ouverture…

Les deadlines durs sont ceux sur lesquels le gestionnaire de projet chez le client a très peu de pouvoir: date de lancement d’un produit décidée par la haute direction, date de départ en vacances du client, etc. Dans ces cas-là, ça vaut la peine de se défoncer pour livrer à temps car une seule journée de retard a des conséquences désagréables pour le client. Dans la plupart des cas le client en sera reconnaissant et même s’il ne nous le dit pas explicitement, il continuera de faire affaire avec nous.

Quant aux deadlines « mous », ce sont des dates fixées plus ou moins arbitrairement par le client pour s’assurer que les choses ne prennent pas trop de retard: c’est le cas lorsque le client fixe l’échéance de livraison une semaine plus tôt pour se garder du temps de test. Trois jours de tests auraient peut-être été suffisants, mais il fallait mettre une date dans le contrat… Il est dans ce cas compréhensible que le client prenne 3 jours pour regarder notre travail même si on a passé une nuit blanche pour livrer à temps. Combien frustrant… mais combien compréhensible aussi… Dans ces cas-là, une bonne communication avec le client peut rendre possibles des accommodements raisonnables!

1) Le fournisseur choisi n’est pas présent lors de la réunion définissant la problématique à résoudre.

2) Le client ne se sent pas responsable de son produit : il ne s’implique pas dans le processus de développement.

Puisque le fournisseur n’est pas présent lors de la réunion définissant la problématique à résoudre, le fournisseur reçoit un mandat où il doit développer une solution pensée par le client — qui est rarement spécialiste de l’industrie du développement, il est spécialiste de son propre domaine d’affaires — et non un mandat où il doit développer une solution à une problématique. La problématique à laquelle le développement doit s’adresser apparaît malheureusement souvent trop tard.

Alors que le client est le seul spécialiste de son propre domaine d’affaires, il ne voit pas l’intérêt de s’engager et de s’impliquer à l’intérieur du processus de développement. La faute revient ici au fournisseur qui, bien souvent, oublie de sensibiliser le client à s’impliquer et à s’approprier son propre projet. La réussite d’un projet dépend grandement de l’apport du spécialiste du domaine d’affaires.

Sans nécessairement être une réponse à l’ensemble des problèmes de gestion de projet de développement personnalisé, les méthodologies de gestion dites Agiles (http://agilemanifesto.org/principles.html) et plus particulièrement SCRUM (http://www.controlchaos.com/) que je connais mieux, améliorent la situation en proposant des méthodes concrètes pour impliquer et responsabiliser le client (qui devient le Projet Owner).

Si la chose vous intéresse, je vous recommande chaudement de consulter les liens inclus dans mon commentaire. Vous pouvez également consulter le site du groupe d’utilisateurs Agiles de Montréal : http://agilemontreal.ca/

Bonne lecture!

Je souris parce qu’il n’y a qu’à accepter (quand même) le mandat du client pour se rendre compte que l’échéancier n’est pas si important que ça… Si on l’accepte pas, le client n’ira que voir un autre fournisseur qui lui aussi lui dira que l’échéancier est correct. Alors, pas fou, on prend les projets, et dans 90% du temps, on se rend compte que l’échéancier n’était qu’une façon de « motiver » (?) le fournisseur à ne pas perdre son temps.

J’ai des clients qui ont déjà peu subtilement remis en question le fait que je ne ferais pas rentrer des gens la nuit pour livrer leur projet à temps. Les quelques fois où j’ai cédé à la pression, on s’est rapidement rendu compte que le client n’en avait pas vraiment besoin pour le lendemain (ça lui a pris 3 jours avant de regarder ce que l’on avait fait…). Ça ça te démotive une équipe…

Pourtant, il y a encore des projets où les gens se donnent corps et âmes, et où ils feraient du temps supplémentaire sans compter. Sans surprise ce sont les projets où ils connaissent le client, où le client est impliqué et motivé, où le client comprend, respecte et valorise leurs efforts.

Certains diront qu’on devrait accepter QUE les clients impliqués et motivés, qu’on devrait dire « non » aux autres, qu’on devrait faire à notre tête et ne pas faire de compromis. Honnêtement, je n’y crois pas. Parce que 1) c’est impossible de différencier les clients au départ, 2) les clients comme les fournisseurs peuvent changer du tout au tout en cours de mandat, 3) ça dépend souvent des individus en relation. Et honnêtement, la diversité, ça fait apprendre, et apprendre on aime ça.

Donc, ma façon de voir les choses, c’est qu’il y a, pour nos services, un tarif de base, le prix, mais que l’efficacité et le retour sur l’investissement viendra d’abord et avant tout de l’implication et de la motivation du client face à l’équipe. On devrait écrire un livre sur « comment être un bon client, même si vous avez toujours raison ».