Quand on va chez un client pour la première fois, il arrive que l’on tombe sur une très jeune personne, avec deux à trois ans d’expérience, mais qui a toutefois une capacité de décision importante sur le dossier qui motive la rencontre.

Ces jeunes profils sont généralement très compétents techniquement sur le dossier dont ils ont la charge, mais ils sont moins expérimentés lorsqu’il s’agit de faire appel à des prestataires externes. Immanquablement, leur attitude consiste à appliquer le principe de précaution. Ils ne disent rien, ou alors le moins possible.

La discussion devient très vite difficile car, sans informations, difficile de faire une proposition. Le cahier des charges est un vague brouillon, on n’aura aucune idée du budget, on ne saura pas non plus comment est organisé le client, quelles démarches il a déjà initié, etc.

Notre jeune ami(e) se mure dans un sourire crispé qui semble supposer qu’il connaît la musique, que tout est implicite, alors que non : c’est le brouillard complet. Peut-être veut-il jouer au Master Mind ? Peut être croit-il que le prestataire a des talents d’oracle ?

En fin de réunion on commence à comprendre que « ce qui serait bien » ce serait de lui faire une proposition avec des options et des modules, presque une « application à proposition » dans laquelle notre jeune ami(e) n’aurait plus qu’à rentrer son budget, ses fonctionnalités, son calendrier, ses contraintes, etc. pour connaître notre proposition et nos engagements.

On essaye bien d’expliquer qu’aucun prestataire de service (tout du moins ceux qui vendent in fine du jour/homme) ne peut s’engager dans cette voie, mais notre interlocuteur répond que « c’est à nous de voir si le dossier nous intéresse ou pas ».

Les jours, et parfois les semaines, passent. Inquiet du silence des prestataires, il va commencer à paniquer car il n’a personne sur la ligne de départ de son projet, la plupart des prestataires ont senti le projet foireux. Alors il rappelle tout le monde et donne toutes les informations qu’il a, et en invente même si nécessaire.

Après le mutisme, on bascule dans la verbosité.

Au final, tout le monde a perdu du temps, et le travail d’échange et de discussion qui aurait pu s’installer en amont se fait dans la précipitation et dans de mauvaises conditions.

Je sais bien qu’il est difficile de parler quand on ne maîtrise pas les relations avec les prestataires. Aussi mon conseil serait le suivant dans ces cas là : commencez par annoncer votre budget. Et si vous ne le connaissez pas, ce n’est pas grave, faîtes vos hypothèses, cela permettra de mettre les échanges sur une bonne voie, quitte à ce que, au final, le budget ne soit plus du tout celui qui avait servi d’hypothèse (il va de soi que je ne parle pas ici des marchés publics).

Bien évidemment, chacun peut voir les choses différemment. En ce qui me concerne, je préfère toujours commencer les discussions sur ce qui est sensible ou ce qui peut bloquer. En la matière, les aspects budgétaires sont une contrainte très forte, surtout quand le prestataire est intimement convaincu, à tort je crois, « que l’on peut tout faire, ce n’est qu’une question de budget ».

No related posts.

Un classique, mais à la lecture duquel il est toujours difficile de ne pas avoir un petit sourire.

Cliquez pour agrandir :

Mais tout çà c’était avant les projets web 2.0, le SaaS ainsi que les méthodes agiles…

Related posts:

1. Les prévisions du Gartner pour le SaaS Gartner nous donne ses prédictions pour le SaaS en cinq...
2. Ars Industrialis sur Twitter Vous pouvez à présent suivre l’actualité d’Ars Industrialis sur Twitter....
3. Au pied du mur C’est quand on est au pied du mur, dans une...

C’est un constat que je fais depuis longtemps, non seulement à propos des développeurs, mais plus largement au sujet des profils techniques dans l’entreprise :
Nos écoles d’ingénieurs forment des ingénieurs qui, à peine sortis de l’école, veulent soit être « chef de projet » soit faire un master en management. C’est à dire ne pas être ingénieur, ce pour quoi ils ont normalement été formés.

Pour la petite anecdote, voici un extrait d’un entretien avec un jeune diplômé :

- Moi : Qu’est ce qui vous intéresse et qu’est ce que vous voulez faire ?

- Lui : Je veux être « chef ».

- Mais chef de quoi ?
- Peu importe, je veux des responsabilités.

- Pour en faire quoi ?

- Pour permettre à l’entreprise d’atteindre ses objectifs.

- Mais vos objectifs à vous, quels sont-ils ? Et qu’est-ce qui vous motive ?
(il fait une pause et semble réfléchir)

- Ma motivation se construira en fonction des opportunités que m’offrira l’entreprise

(çà y est, là je suis agacé)

- Encore faut-il que vous soyez une opportunité pour l’entreprise, ce dont je doute…

Pour aller dans le sens de mes propos, le témoignage d’Eric Groise est très enrichissant. Il respire le vécu et le bon sens. Il devrait être diffusé dans de nombreuses écoles :

Related posts:

1. La mutation du statut de l’oeuvre Le piratage est un phénomène qui touche les produits les...
2. Droite(s) en France Il y a plusieurs droites en France, René Rémond en...
3. Oracle rachète BEA L’annonce est donc tombée aujourd’hui, au lendemain du BEA Convergence...

Ok, vous avez gagné un gros projet. Maintenant il faut le commencer.
Votre esprit doit basculer dans un mode différent, vous n’êtes plus le consultant en avant vente, vous ne cherchez plus à vendre. Maintenant il faut le réaliser, c’est le temps du delivery.

Première préoccupation : comment le piloter ? Comment construire une vision commune et proposer un environnement dans lequel chacun peut travailler efficacement ? Chacun, y compris le client !

Je dis « le client » mais, en l’occurrence, l’interlocuteur client doit être une forte partie prenante du projet. Le pire des clients est un client qui se comporte comme un … client. Un consommateur en mode passif.

Il faut donc instaurer des mécanismes participatifs forts avec chacun des participants du projet.

C’est là que les applications en lignes prennent tout leur sens. J’utilise :

Un compte Google avec :

• Gmail pour le mail;

Les clients n’acceptent pas tous de changer d’adresse mail le temps du projet, et pour le projet, mais je crois que la proportion va progresser dans le bon sens, ne serait-ce qu’avec le couplage avec :

• Google Doc & Tableur, pour les fichiers bureautiques partagés;

L’ensemble de la documentation du projet est en ligne, consultable et modifiable par tous les membres du projet en même temps.

• Google Agenda, pour l’agenda partagé bien sûr.

• ZOHO projects ou Base Camp, pour la gestion du projet (tasks, milestones, planning, livrables en version finale, forum, etc.)

Personnellement je n’ai encore essayé que ZOHO, Base Camp est plus proche de la simplicité que l’on attend d’une application en ligne (c’est le charme des services proposés par 37Signals) mais certaines fonctionnalités sont manquantes dans l’offre gratuite de base (notamment la taille de disque pour le stockage des documents)

Les documents de pilotage et de référence sont donc toujours en ligne en mode consultation et écriture ( avec les droits d’accès associés) : plus de valse des mails en communication point à point avec des pièces jointes de multiples versions d’un même document. Pas de système d’archivage de la documentation projet avec des noms de répertoire et de fichiers abscons.

Pour le PAQ (qui n’est pas encore un PAQS ), on le met en ligne car c’est un document de référence (même s’il tombe traditionnellement en désuétude au fil des mois) qui a pour vocation d’évoluer tout au long du projet.

Ensuite, on créé un tableur en ligne avec différents onglets pour avoir le tableau de bord du pilotage du projet : acteurs du projets (noms, contact, rôle,..), suivi des charges, management du risque, liste des actions, indice qualité de la prestation, planning.

A chaque comité de pilotage on constate l’évolution et la modification des indicateurs (puisque chacun peut les modifier en permanence) et on prend une photo à l’instant t avec un copier/coller que l’on insère dans le document en ligne « Compte Rendu de Réunion » que l’on diffuse dans la foulée de la réunion.

On ajoutera un outil de Conférence Web comme Skype pour les réunion ne ligne qui peuvent être efficace grâce à la consultation simultanée des documents en ligne.

Dans cette démarche le client est pleinement participatif dans la conduite du projet, pas d’effet tunnel. Les livraisons sont permanentes et les corrections se font au fil de l’eau.

Croyez-moi, quand on y a goûté on ne revient pas en arrière. Surtout si on travaille en mode projet.
Et vous, vous utilisez quoi quand vous travaillez en mode projet ?

Related posts:

1. Le Système d’Information des SSII Je ne pouvais pas commencer cette note sans évoquer ce...
2. La stratégie du Boa Si vous travaillez en mode projet et que vous avez...
3. Le référentiel documentaire de projet Un référentiel est un système de références faute duquel aucune...

Sans redéfinir ce qu’est un Plan Assurance Qualité (PAQ), on peut en retenir qu’il s’agit d’écrire et de tracer ce que l’on fait, et ce que l’on dit dans le cadre d’un projet pour s’assurer de la qualité et de la conformité de ce que produit le projet.

Un support de mémoire en quelque sorte.
Ces écritures d’un PAQ donnent lieu à beaucoup, énormément même, de documents. Et dans ces documents, on s’y perd. C’est pourtant en apparence très structuré, mais c’est un vrai labyrinthe car l’accès y est pensé selon les paradigmes du papier et non selon ceux des supports numériques.

Ecrire avec des documents sous Word, même avec des numéros de pages et des nomenclature de nommage de fichiers à rallonge ce n’est pas vraiment écrire au sens numérique.
L’écriture numérique est active, l’écriture sur support papier est passive. Un PAQ est, de fait, souvent plus subi qu’autre chose car son écriture n’est pas pensée selon le paradigme du numérique. Le PAQ devient alors de la « paperasse » dont les administrateurs sont souvent les « personnes du troisième âge » des SSII (pour la maîtrise d’oeuvre) et des cabinets de conseils (pour l’assistance à la maîtrise d’ouvrage).

Ce qu’il faudrait, c’est que cette expertise des senior dans le PAQ permette la réalisation d’un outil pour ne plus se contenter d’être un acte pieux et religieux comme peuvent l’être les dix commandements du PAQ.

Pourquoi donc n’y a-t-il pas de logiciel dédié pour instrumenter la vie et la réalisation d’un Plan Assurance Qualité ? Pourquoi un Content Management System avec un système de workflow, et couplé à une vision calendaire, le tout indexé par un moteur de recherche ne serait-il pas utilisé ?

Je verrai bien une petite modélisation en RDF du domaine plan assurance qualité, avec un moteur d’inférence pour faire des propagations d’état et des interfaces web de consultation et d’écriture. Rajoutons même un peu de Jasper pour générer des états et des rapports.
Cà deviendrait peut-être agréable piloter un projet avec un outil de PAQ sémantique ; en tout cas cela aurait peut-être une première vertu qui serait de limiter l’entropie de la production documentaire. N’avez-vous pas remarqué que moins on comprend, plus on produit des documents dans la vie d’un projet (mail et Word en tête) ?

Faisons maintenant un peu de « Business Fiction » :
Si les petits gars de Mondeca se sortaient le doigt (je plaisante, hein?), ils pourraient nous faire çà – le PAQS – en quelques semaines et inonder le marché de la gestion de projet. Dans un an ils se font racheter par Microsoft qui créé le logiciel « Microsoft Semantic Project », le compagnon idéal de « Microsoft Project », version Qualité et Pilotage.

A moins que Google ne prenne le géant de Redmond de vitesse, dans le rachat de Mondeca, pour faire du PAQS un outil libre, en ligne, de gestion de projet. Ainsi après le mail, le calendrier, le traitement de texte, le tableur et le keynote, Google fait de « Google Semantic Project » le fer de lance de sa stratégie de pénétration du marché des entreprises, un des derniers lieux où il n’inquiétait pas encore Microsoft.

Related posts:

1. Ironie du sort Le « slogan » de Microsoft pour décliner sa mutation vers le...
2. Microsoft contraint à sortir du bois Quand l’anglais Fasthosts propose les solutions de Microsoft en mode...
3. Piloter un projet avec des applications gratuites en ligne Ok, vous avez gagné un gros projet. Maintenant il faut...

Un référentiel est un système de références faute duquel aucune analyse, ni aucune utilisation optimale, n’est possible. Un référentiel documentaire se doit donc de proposer un système de références permettant de s’y retrouver en palliant à la désorientation due à la profusion des documents, de leur nature, de leur contenu, de leur forme et de leur finalité.

Tout projet (Informatique ou Métier) génère une quantité de documentation proportionnelle à sa complexité, sa durée et son périmètre. Il porte en lui-même une culture et des référents qui permettent aux acteurs du projet de s’y retrouver. Cette culture du projet engendre des référents qui peuvent être soit explicites, soit tacites. Mais, une fois le projet fini et les équipes dispersées, le risque de perte de compréhension des livrables du projet augmente avec le temps :

Schéma : la courbe de production (vert) représente le volume croissant de production documentaire d’un projet dans le temps. La courbe d’utilisation (rouge) représente l’évolution du pourcentage d’utilisation des documents dans le temps. L’écart qui se creuse entre les deux courbes dans le temps peut détériorer la bonne utilisation des documents si un référentiel documentaire (bleu) n’est pas mis en place.

La finalité d’un référentiel documentaire est précisément de palier à la diminution de la possibilité de compréhension, d’usage et d’évolution des documents issus d’un projet.

Related posts:

1. La stratégie du Boa Si vous travaillez en mode projet et que vous avez...
2. Piloter un projet avec des applications gratuites en ligne Ok, vous avez gagné un gros projet. Maintenant il faut...
3. Le projet informatique en image Un classique, mais à la lecture duquel il est toujours...