Le chiffrage de projet informatique : documentation, équipe near-shore, …

Nous avons vu dans l’article précédent comment chiffrer un projet à partir du cahier des charges. Continuons avec d’autres aspects à chiffrer.

Chiffrer la gestion de projet à partir d’un cahier des charges

Tout dépend de votre manière de gérer le projet. Pour ma part, pour m’aider à chiffrer la gestion de projet d’un projet je décompose, il y a du suivi client et du suivi d’équipe :

– Pour le client, un comité opérationnel hebdomadaire, un comité de pilotage mensuel : préparation et mise à jour des éléments de suivi projet (planning, suivi des pré-requis, des livrables, des validations, …), réunion à proprement parler et compte rendu. Je chiffre quelque chose comme une demi-journée par comité.

– Pour les équipes : accompagnement des personnes de l’équipe, pilotage / suivi, coaching, je chiffre un peu moins d’une demi-journée de suivi par semaine de travail par personne.

Le chiffrage de la gestion de projet est bien évidemment à adapter, je vous présente ma manière de faire. C’est très variable car il peut dépendre :

– du planning, on ne fait pas autant de réunions en 3 mois qu’en 6 même si leur ordre du jour est du coup plus dense. En parallèle, le suivi doit s’intensifier si le planning est plus serré ou si la taille de l’équipe augmente.

– de la maturité du client : si le client « aime » les réunions à rallonge, est toujours en retard sur ses pré-requis, vous positionne 15 interlocuteurs à gérer ou a besoin d’accompagnement sur la méthodologie projet, vous ne passerez pas le même temps.

– de la maturité du chef de projet : doit-il être fortement accompagné d’un directeur de projet ? est-il rôdé à l’exercice à tel point qu’il ira plus vite que la moyenne ?

– de la maturité des équipes : ont-ils l’habitude de travailler ensemble ? avez-vous déjà travaillé avec eux ? connaissent-ils les bonnes pratiques en place ?

Attention également à la phase de recette, qui peut s’avérer extrêmement chronophage pour un chef de projet si elle n’est pas correctement préparée et pilotée. A traiter dans un autre article ..

De manière générale, il est assez difficile de vendre de la gestion de projet, le client veut bien entendre une démarche qualité mais son expérience avec d’autres projets lui montre que c’est rarement au rendez-vous. A vous de prouver le contraire. En attendant, il faut bien tenir compte de cette charge réelle, une astuce peut être donc de la répercuter sur les charges de réalisation.

Chiffrer la formation à la nouvelle application

Souvent les projets s’accompagnent de transfert de compétences, de formation utilisateur ou administrateur. Il faut penser pour chiffrer :

– au temps de préparation d’un diaporama (souvent au format du client) ou autre support: on dit souvent 1 jour de formation = 2 jours de préparation, à adapter au contexte. Il faut également le faire valider par le client. La démarche peut-être plus souple et s’appuyer sur la documentation utilisateur ou un document d’architecture.

– au temps de création des jeux de données, exercices et surtout de mise en place de l’environnement. Assurez-vous que les postes fonctionnent. La satisfaction des apprenants dépendra aussi de la qualité de l’environnement de formation.

– au temps de trajet : mieux vaut caler des journées de formation que des créneaux de 2 heures ou de demi-journées, vous gagnerez en temps de trajet.

Découper la formation sur plusieurs jours permet également de gérer les absents et de laisser à vos interlocuteurs le temps d’assimiler et de tester, sans compter qu’ils peuvent ainsi poser des questions à la séance suivante.

Chiffrer la documentation d’un projet

Pensez à chiffrer la documentation (et oui ça s’est vu, une belle documentation vendue mais pas chiffrée …) et surtout de bien lister les livrables attendus par le client. Il faut penser :

– à se mettre d’accord sur le contenu du document et le niveau de détail (proposer un plan à faire valider avant d’entamer la rédaction)

– au modèle de document à suivre : attention si vous utilisez le modèle de document du client, vous le maitrisez certainement moins que le vôtre

– au format de document à utiliser : attention à la compatibilité des formats et logiciels entre eux (OpenOffice.org et MS Office notamment)

– à se mettre d’accord sur la langue utilisée également (le commercial doit vous aider à y penser compte tenu de sa connaissance du client)

Comptez un minimum de rédaction par document car entre l’initialisation d’un document, la rédaction, la relecture et l’intégration des retours client, même un simple document peut devenir chronophage. Gare aux documentations utilisateur qui peuvent être très complexes et fastidieuses à rédiger (imaginer une documentation utilisateur papier pour Facebook, Amazon ou Voyages SNCF).

Lisez également 10 manières de se tirer une balle dans le pied avec les livrables documentaires !

Pensez à chiffrer les tables de référence

Pensez dans le cas d’un projet de développement au chiffrage des tables de référence et de leurs écrans d’administration éventuels (table de statuts, types de contrat, catégories, …). Demander l’utilité des écrans d’administration pour certaines tables peut vous permettre de réduire le chiffrage : si les types de contrat évoluent une fois tous les 5 ans, ce n’est pas forcément la peine de créer des écrans pour ça.

Méfiez-vous également des générateurs d’écrans CRUD (Création, mise à jour, suppression) proposés par les frameworks : ils vont être génériques et rapides à créer mais parfois peu adaptables à la demande du client qui voudra toujours des spécificités.

Chiffrer la reprise des données

Vaste sujet que la reprise de données ! Je déconseille fortement une prise en charge au forfait d’une reprise de données ou alors en cadrant bien qui fait quoi dans cette phase. Mal cadrée, une reprise de données peut multiplier votre chiffrage par 10 … Il faut donc :

• définir un format figé d’entrée des données qui doit être respecté par le client : à sa charge de faire rentrer ses données dans ce format
• évaluer le nombre de champs qui devront être repris, ne pas se baser sur le nombre de tables (10 tables avec 1 champ != 2 tables x 50 champs)
• évaluer le nombre de relations (clés étrangères) qui devront être respectées à l’import.

Donc même si le client dit qu’il va nettoyer les données et qu’il fournira un format propre, que vous pouvez donc diminuer votre chiffrage, gardez-le vôtre et méfiez-vous : 9 fois sur 10 ce ne sera pas le cas. Non pas qu’il est de mauvaise foi, tout simplement que ça peut être un travail de titan. Mais c’est au client de nettoyer les données. Et le mode itératif est à proscrire ou au pire à chiffrer sinon ça devient :

• « Et avec ces données c’est bon ? »
• « Non ça plante ici, ici, ici … »
• « Et là c’est bon ? »
• « Non ça plante ici, ici, ici … »
• « Ah ok j’avais pas vu et là c’est bon ? »
• « Non ça plante ici, ici, ici … »
• « Ah oui ok j’avais oublié de corriger et là c’est bon ? »
• …

Vendez par exemple 5 itérations de test ou vendez l’utilitaire que le client lancera de manière autonome pour connaître les données qui ne passent pas. N’hésitez pas à faire appel à des compétences en Business Intelligence notamment ETL (un outil comme Talend peut vous faire gagner un temps fou s’il est maîtrisé), après tout chacun son métier !

Cas des équipes distantes : near-shore, off-shore

Idéalement dans un autre pays parce que les coûts sont moindres, parfois en province dans des centres de service pour mutualiser les ressources, les équipes distantes semblent être commercialement la recette miracle pour diminuer le coût d’un projet. Pas si simple en pratique :

– la tâche peut-elle être effectuée à distance : installation de la plateforme chez le client (ça s’est déjà vu / vendu avec 2000 km de distance), aide à la recette technique avec intervention sur place, …

– la compétence est-elle présente dans l’équipe distante : réalisation d’une charte graphique, administration système avancée, …

– l’environnement cible peut-il être reproduit proprement dans les locaux de l’équipe distante : problématique de flux réseau, d’accès au réseau du client, …

– travailler en jour-homme peut devenir source d’erreur selon les profils, garder en tête qui fait quoi et à quel coût lorsqu’il y a négociation d’une modification de périmètre par exemple.

– le rebond fonctionnel : l’interlocuteur métier du client explique le fonctionnel à une personne sur place qui va ensuite le réexpliquer à la personne distante qui en est responsable. Rencontrer le client pour comprendre un besoin est quand même judicieux surtout au début.

– cela dépend des personnes mais une réunion physique permet d’en savoir plus qu’un coup de téléphone : en le rencontrant, vous allez sentir de suite si votre chef de projet distant est serein par rapport à la livraison à venir ou s’il est en galère. Apprenez à connaître vos équipes avant de travailler à distance avec elles.

– Projetez-vous dans la réalisation : comment cela va-t-il se dérouler ? avec l’équipe locale, avec l’équipe distante, avec l’environnement de développement, quel débit entre les réseaux ? suffisant pour faire de la prise en main à distance en mode bureau partagé ? posez-vous toutes les questions en vous mettant en situation.

– Eviter à tout prix de transposer rapidement un chiffrage pour une équipe locale en un chiffrage pour une équipe distante : montrer du doigt sur un écran un bug graphique est plus rapide que de prendre un screenshot, le commenter, expliquer comment le reproduire et l’envoyer ou d’essayer d’expliquer le bug au téléphone .. Si vous êtes équipés d’outils adéquats (vérifiez qu’ils marchent et que tout le monde sait s’en servir ..), sinon méfiance … Et quid d’un concept fonctionnel ?

Pour les plus frileux, vous pouvez travailler en mode forfait avec votre équipe distante mais savent-ils gérer un forfait ? s’ils se plantent, vous vous plantez .. alors bien sûr le coût restera le même les concernant, mais le vôtre va augmenter pour réparer les dégâts ..

Consolidation des éléments de chiffrage

Vérifier, re-vérifier, re-re-vérifier ! vos formules, votre chiffrage, vos sommes, etc. Et si vous n’êtes pas rigoureux, faites-le faire à quelqu’un d’autre. Préférez perdre 10 minutes à ce moment-là, croyez-moi :

Je préparais une réunion de lancement d’un projet pour lequel je n’avais pas participé à l’avant-vente. Je commence à remanier le chiffrage pour me l’approprier et je me rends compte que le tableau récapitulatif (celui qui a servi pour calculer le prix de vente) comptait 107 jours et que la somme des chiffrages détaillés comptait 125 jours ! Commencer un projet avec 18 jours de dépassement au T0 du projet c’est un challenge ! Inutile de vous dire que l’équipe d’avant-vente en charge faisait profil bas …

 

Finalement, une troisième partie s’impose car le chiffrage ne s’arrête pas à un bête tableau : principes et idées-clés à suivre .. !

Et vous comment gérez-vous le chiffrage de ces parties-ci ?