Les différentes carrières du consultant décisionnel

Je vous parlais précédemment du métier de consultant et de la veille technologique associée, et cela m’a lancé sur une réflexion autour des différentes facettes que l’on regroupe sous ce titre.

L’objectif de cet article est plutôt simple : mieux percevoir l’activité du consultant, savoir quelles sont les compétences à travailler pour progresser et également quelles sont les possibilités d’évolutions qui s’ouvrent à ceux qui prennent leur carrière en main.

Cette vision de la chose est issue de mon expérience personnelle. Je suis donc évidemment preneur de votre retour sur le sujet, d’autant plus si vous utilisez une grille de lecture précise qui diffère de celle qui suit.

Pour faire simple je vais découper l’activité du consultant sur 5+2 domaines de compétences, 5 qui s’appliquent en mission, 2 en dehors. Je regrouperai ensuite ces domaines en 8 carrières classiques, ce qui permettra à chacun d’identifier son positionnement et le titre qui lui convient.

Choix de carrière sur les SIMS Social

On commence donc avec les domaines de compétences en mission:

En Mission


Technologies

Activités Connaissance des outils. Capacité à réaliser.
Question associée Comment faire
Progression Par techno, niveau de 1 à 5 : SSIS / SSAS / SSRS / SQL / DAX / MDX …

Théorie du Décisionnel

Activités Capacité à concevoir des solutions. Connaissance des techniques, de la modélisation.
Question associée Quoi faire
Progression Compréhension de l’activité, qualité des modèles, justesse des propositions et remarques…

Fonctionnel

Activités Connaissance des problématiques clients (RH, Finance, Retail, Industrie…).
Question associée Pourquoi le faire
Progression A travers les projets, en diversité, nombre et profondeur…

Gestion de Projet

Activités Faciliter le quotidien, gérer la logistique dans la mission, suivre l’avancement.
Question associée Quand / Combien
Progression Nb et type de projet (forfait / régie), méthodologies (V, Agile), outils planning et budget…

Relation Utilisateur

Activités Recueil du besoin, conduite du changement, assistance à la recette.
Question associée Qui
Progression Aisance générale, qualité des livrables, forme des presentations…

Plus 2 domaines de compétence hors mission:

Hors Mission


Développement du Business

Activités Avant ventes, construction de l’offre, contribution à l’image publique (blog, whitepaper…)
Périmètre Extérieur à l’entreprise
Progression Réussite des A/V, qualité de l’offre, qualité de l’image (appels entrants, canditatures spontanées…)

Management

Activités Gestion du groupe, formation, logistique entre les missions, accompagnement dans la carrière.
Périmètre Dans l’entreprise
Progression Qualité de la vision à long terme, Satisfaction des consultants, faiblesse du turnover, cooptation

Maintenant qu’on a identifié les compétences, on va pouvoir positionner notre premier métier de consultant : le développeur junior, sur la grille.

Les compétences du Développeur Junior

Son premier chemin d’évolution naturel est de monter en compétence sur les technos, de prendre du recul et commencer à penser solution (théorie du décisionnel) et d’apprendre le fonctionnel à travers ses missions. Plus le bleu est sombre et plus la maîtrise est grande.

Compétences des Développeurs

Mais devenir développeur sénior n’est pas sa seule option, il peut choisir d’évoluer vers les autres métiers du décisionnel, qu’on identifiera à partir de leur compétence majeure (bleu foncé):

Métiers du Décisionnel

On peut noter l’absence d’un expert de la relation client, qui à mon sens est en dehors du périmètre du consulting décisionnel et plus dans l’organisationnel. (Update 18/04/2012) David Tang me propose d’inclure le Formateur comme expert de la relation utilisateur, je trouve ça excellent, l’article est mis à jour en conséquence.

Cette liste je la reprends ici:

  • Développeur : Il a déjà de nombreux projets derrière lui, il connaît les produits, les technos, il sait industrialiser les solutions, il développe en solo ou en équipe. Dans tous les cas, dans toutes les situations, il livre.
  • Expert Technique : Il connaît les produits par coeur, toutes les astuces, tous les bugs classiques, toutes les optimisations. C’est lui qu’on appelle pour décoincer une production récalcitrante ou réussir à implémenter cette fonctionnalité qui nous résiste.
  • Architecte : Il voit la solution de bout en bout, fabrique les prototypes, modélise le datawarehouse. C’est lui qui fait la jointure entre la technique et le fonctionnel, le guerrier du « Many to Many », c’est l’évangéliste de Kimball 😉
  • Consultant AMOA – Assistance à Maîtrise d’Ouvrage: Lui sa spécialité c’est les problématiques des clients. Il connaît les métiers (la RH, le retail…), il sait parler aux utilisateurs pour extraire et transmettre les spécificités de leurs besoins aux autres membres de l’équipe.
  • Chef de Projet : J’ai une notion très « Berkunienne » du chef de projet. Pour moi ce n’est pas un manageur, il ne dirige pas des hommes. C’est plutôt un facilitateur, qui fait tout pour que le projet se déroule sans accroc, pour que les autres membres puissent bosser tranquillement. C’est lui qui surveillera les plannings et les rapportera à qui de droit.
  • Formateur : C’est lui qui répand la bonne parole, et les bonnes pratiques, à travers les centres de formation. C’est également lui qui met en place les événements, prépare les présentations et animation, et entretient l’effort de veille technologique au niveau du pôle.
  • Ingénieur Avant Vente : Il accompagne les commerciaux en avant-vente, c’est lui qui gagne les missions et qui prépare l’arrivée de l’équipe projet. Evidemment il connaît le domaine décisionnel puisqu’il répond aux appels d’offres et participe aux chiffrages, qu’il anime des séminaires et qu’il représente l’équipe sur les salons. Il faut l’aimer, puisque c’est lui qui empêche les commerciaux de dire oui à tout 🙂
  • Chef de Pôle : Le vrai manageur de la troupe, il accompagne les consultants dans leur carrière sur la durée.

Évidemment ces rôles ne sont pas exclusifs, on assume tous très souvent plusieurs casquettes en même temps, lorsque le périmètre est petit ou que les compétences manquent. Typiquement: le chef de projet / expert technique, qui encadre les juniors et répond à leurs questions techniques tout en remplissant les plannings quand il a le temps. On a aussi le chef de pôle / ingénieur avant-vente, tant que le pôle fait moins de 20 personnes. Et toutes les autres combinaisons qu’on peut imaginer.

Cela dit, et pour éviter de se diluer, il est bon de donner une orientation majeure à sa carrière, et donc de choisir un titre de prédilection dans la liste. Une fois qu’on a ce point de départ, on peut se projeter et choisir où l’on souhaite se retrouver dans 5 ans.

La progression s’effectue alors sur 2 axes: le premier c’est ajouter du bleu clair dans de nouvelles cases, et donc potentiellement agrandir sa collection de titre comme on collectionne les pokémons. Le second c’est foncer le bleu dans une case, et donc gagner en expertise sur un sujet. De cette manière on retrouve aussi les pokémons, sauf que cette fois ils évoluent:

  • Le développeur s’endurcit, il sait réaliser tous les caprices exprimés dans les spécifications et jongle avec les 35 étapes requises pour la montée en production
  • L’expert technique gagne en reconnaissance: confère Marco Russo, Chris Webb ou François Jehl, pour rester en Europe
  • L’architecte se séniorise, et invente de nouveaux frameworks… Certainement l’évolution la plus casse gueule
  • Le consultant AMOA devient directeur d’étude
  • Le chef de projet devient directeur de projet
  • Le formateur devient évangéliste, que ce soit auprès de l’éditeur ou pour sa société
  • L’ingénieur avant-vente devient responsable commercial
  • Et le chef de pôle grandit avec sa troupe. Diriger 100 personnes ce n’est pas la même chose qu’en diriger 5.

Faîtes le bilan d’où vous en êtes, choisissez votre chemin de progression, et le tour est joué! Vous ne sécherez plus lors du prochain entretien quand on vous demandera « vous vous voyez où dans 5 ans? », votre arbre de compétences sera déjà tout tracé:

Arbre de compétences - World of Warcraft

Apprendre un nouveau langage de programmation ou lire un bouquin de méthodologie? Choisissez l’option qui correspond à votre plan de carrière. On vous propose 2 missions, l’une orientée AMOA et l’autre gestion de projet? Même combat: choisissez la compétence qui est sur votre chemin de croissance. Formez vous en ligne, montrez votre travail à travers un blog ou une contribution Open Source… Soyez actifs, décidez de votre avenir et vous arriverez au but 🙂

Pour conclure sur ce sujet je m’adresse aux chefs de pôle et/ou aux responsables RH. Si vous en utilisez un, je pense qu’il est très bon de coupler le référentiel de compétences avec votre grille de rémunération pour obtenir des salaires distribués de manière objective (cf Joel Spolsky). Rien de tel pour motiver vos collaborateurs à prendre en main leur carrière. Tout le monde est gagnant!

La BI ça vous gagne: le Best-of de fin d’année!

Vous l’avez surement remarqué, ce blog aura vraiment été tourné sur la partie technique en cette fin d’année. J’ai un peu trop négligé l’aspect business et j’en suis désolé!

Pour me rattraper, et dans la plus grande tradition des chaînes de télé entre Noël et nouvel an, je vous fais mon best-of des articles business de la BI ça vous gagne. C’est une sélection personnelle que j’ai organisé autour des 4 thèmes récurrents que vous avez l’habitude de suivre ici :

Consulting

Développement Personnel
Stratégie / IT
Management
Si après ça vous en voulez encore, je vous recommande ces saines lectures. Il ne me reste qu’à vous souhaitez de joyeuses fêtes et vous dire à l’année prochaine 🙂

Nouvelle mission!

Me voilà parti sur une nouvelle mission! Chouette 🙂

J’aime enchainer les missions courtes, un mois ou 2 c’est bien. Pour moi c’est le meilleur deal: j’ai le temps d’apporter de la valeur au client, mais je n’ai pas le temps d’entrer dans ses conflits politiques internes ni celui de m’ennuyer.

Cette multitude d’expérience est à mon sens l’avantage du consultant. On va chercher un consultant parce qu’il a déjà vu son problème 10 fois, dans 10 contextes différents, résolu de 10 manières différentes. Et la meilleure manière d’obtenir ce recul pour un consultant c’est de changer de mission et de client régulièrement.

Évidemment quand on intervient en mission courte, on a pas le temps de faire dans la dentelle. D’une part les relations avec le client ne sont pas les mêmes, Brent Ozar a une bonne série d’articles sur ce sujet, d’autre part attendre pour une ressource technique devient réellement problématique.

Si sur mes 20 jours de présence j’attends 2 jours pour avoir un poste et 3 jours pour des accès aux serveurs, ça fait 25% du planning foutu en l’air. Les premières fois je l’ai mal vécu: je prenais sur moi d’avoir à délivrer 100% du boulot sur 75% du temps restant. Maintenant c’est terminé. Ce type d’attitude par rapport à ma prestation me fait changer mon approche de la mission. Si d’ordinaire j’arrive avec une quasi obligation de résultat (je m’engage à y arriver), avec ça je bascule à une obligation de moyen (je ferais de mon mieux). Si ça rentre tant mieux, sinon on avisera (travail incomplet ou rallonge). Et mon stress va beaucoup mieux, merci 🙂

Quand on y pense, à ce niveau de prestation (et à ce tarif), c’est quand même dommage de perdre l’engagement de son prestataire dès les 3 premiers jours de mission, surtout pour des ressources qui auraient pu être commandées 3 semaines en avance. Si on va plus loin, en fait ce n’est que rarement une erreur d’inattention, c’est en général plutôt un vrai symptôme de dysfonctionnement du service, voir de l’entreprise. Et c’est souvent le premier indice que cela risque de mal se passer, à surveiller donc!

 

Merlin Mann et la parabole du sandwich

Merlin Mann nous propose une parabole vraiment intéressante sur son site 43 Folders, celle du « vendeur de sandwich« .

Dans cette histoire Mr. Mann imagine comment un client business achèterait un sandwich s’il procédait selon le même process que celui de recrutement d’un prestataire de service.

Un passage que j’adore, le premier paragraphe en fait, dans lequel le client entre dans la boutique et c’est au vendeur de sandwich de se justifier de ça (ma mise en gras dans le texte) :

“Hi,” says The Sandwich Guy. “What looks good to you today?”

“Slow down,” says The Ostensible Customer, as THE LUNCH RUSH starts trickling in. “Lots of delis want my business, so, first I need to really understand what you can do for me.”

Ou encore le passage sur le tabou du budget:

“Well. You know. I do sell sandwiches for a living,” says The Sandwich Guy. “Did you have a certain budget in mind for your lunch?”

“Oh, God, no. I’m nowhere near that point yet. I still need to learn a lot more about how you work, and so, obviously, I have no idea what I want to pay. Obviously.”

C’est un très bon article, je vous encourage à aller le lire. Si vous êtes côté prestataire, ça fait du bien de voir que c’est pareil partout, si vous êtes côté client, je suis sur que puisque vous lisez ce blog vous ne faîtes pas ce genre de chose 😉

Si vous avez envie de creuser le sujet, à la fin de l’article Mr Mann indique 5 très bons articles dont celui de Happy Cog et celui de Richard Ziade. Bonne lecture!

Jeff Lamarche sur les NDA…

… et plus généralement sur le secret professionnel en avant-projet: ça se lit ici.

En version française et adapté au consulting plus généralement, ça donne qu’il ne faut pas avoir peur de partager tous les tenants et les aboutissants de son projet lorsqu’on veut le confier à une société externe, et cela avant même la signature des contrats.

Cela paraît évident dit comme ça, et même s’il est rare que l’on signe des NDA en France (Non Disclosure Agreement, accord de non divulgation), il est arrive encore trop souvent qu’on ne nous livre qu’un minimum d’info avant la signature du contrat, de peur qu’on aille révéler quoi? Je ne sais pas…

A moins que ce ne soit pas par peur que le prestataire aille révéler quelque chose, mais plutôt par peur qu’il s’enfuit devant l’impossibilité de la tâche? Ca c’est encore pire, car si un beau piège a été dissimulé par le client dans l’appel d’offre, ça ne peut que se retourner contre lui. Il ne faut pas croire qu’un accord de réalisation signé sur un périmètre défini est toujours valable si on y rajoute sournoisement le piège qui change tout, pas en France en tout cas. Et même sans cela, rompre la relation de confiance client/fournisseur avant même la signature du contrat? Pas génial pour réaliser un projet avec enthousiasme…

Je rajouterai même que c’est une bonne chose, lorsqu’on fait venir un vrai professionnel, de lui exposer complétement son idée avant même de signer un contrat. Pourquoi? Parce que si c’est un vrai professionnel et que l’idée n’est pas très bonne, il refusera le contrat en expliquant pourquoi. Six mois de budget et de frustration économisés c’est toujours bon à prendre, surtout quand c’est offert par la maison 🙂

Dire aux clients qu’ils ne sont pas communs

Il est vrai qu’on ne dit surement pas assez à ses clients qu’ils ne sont pas communs. Brent Ozar, l’expert SQL Server qu’on ne présente plus, le rappelle dans son dernier article.

Lorsqu’on est consultant, on voyage de client en client et on voit comment les choses sont faîtes, comment les outils sont utilisés, dans une variété de contexte. De ces multiples expériences on retire une espèce d’implémentation type, une moyenne des pratiques rencontrées qui sont appliquées chez 90% des clients. Ce sont des interprétations plus ou moins correctes des bonnes pratiques définis par le référant reconnu, bien souvent l’éditeur.

Et de temps en temps, on tombe sur un représentant des 10% restants. Des clients qui ont complétement contourné ou modifié ce qui est dans les moeurs. Attention, ce ne sont pas des clients catastrophes, qui n’ont définitivement rien compris à l’outil. Ce sont au contraire des clients qui ont sciemment ignoré une pratique commune pour répondre à un besoin spécifique incontournable.

Ces clients là poussent les outils et méthodes à leurs limites, et c’est pour cela qu’il est difficile de répondre à leurs questions de but en blanc (mais c’est souvent les questions les plus intéressantes).

Et bien à ces clients, il faut leur rappeler qu’ils sont hors du commun. D’abord pour reconnaître leur talent (c’est mérité), ensuite pour expliquer notre surprise quand on voit leur implémentation et nos temps de réaction à leurs questions, enfin pour éviter le culte du cargo pour le prochain projet…