Le WBS – Episode 2
Continuons sur le WBS. L’autre avantage c’est que le WBS permet de déléguer. Un chef de projet aussi superman techniquement soit-il, ne connait pas tous les aspects d’un projet en détail. Cependant, il gère une équipe qui l’est (enfin supposé être mais c’est un autre problème qu’on abordera certainement).
Exemple : Un projet qui contient un volet développement et un volet installation/configuration de matériel informatique et réseau. C’est toujours de l’informatique, mais c’est deux expertises différentes. Le chef de projet plutôt orienté Dev, du fait de sa formation, va donc déléguer la production du WBS d’intégration matérielle et réseau à son expert IT. Lui, cependant, s’attaquera à la partie Dev.
Notons que quelquefois, la boite a déjà des standards en place dans une ou plusieurs dimensions du projet (l’architecture matérielle par exemple) et donc des documents et des procédures modèles déjà prêts. Dans ce cas-là, le chef de projet récupère cette partie de la base de connaissance et adaptera lui-même (Eh oui, un chef de projet est polyvalent quand même).
Lorsqu’on réalise un WBS, il est nécessaire de l’annoter avec toutes les suppositions prises dans l’estimation y compris celle où on a shooter au pif (large généralement) parce qu’il est difficile d’estimer à ce stade. Cela constitue la base des points à revoir ultérieurement. Plus l’estimation est solide (expérience du chef de projet ou collective), moins il y a de risques.
Le grand avantage du WBS, c’est qu’il permet de structurer la réflexion. L’approche est méthodique et structurée, à condition bien sûr de ne pas commencer à sauter d’une branche à une autre au grès de l’ennuie. Généralement, il faut commencer par le premier niveau car il est simple à faire (un ou deux exemples d’anciens projets similaires et c’est bon l’affaire est dans le sac). Ensuite, les choses commencent à devenir plus tendues. Quelle est la meilleure approche pour avancer ? C’est difficile à dire. Moi j’ai tendance à avancer pas par pas en commençant du plus facile au plus compliqué (c’est une philosophie générale chez moi), je m’attaque au deuxième niveau sur le sujet que je maitrise le plus. Je vais même jusqu’à détailler tous les niveaux de cette branche. Cela me permet d’avoir un avancement rapide et réel.
En fonction du projet, on dispose ou pas d’experts qui vont aider à détailler le WBS. Dans le cas où on n’a personne (à part des exemples issues de la base de connaissance), il est presque tout le temps nécessaire d’organiser des réunions avec des experts pour revoir la copie. Dans tous les cas, montrer l’avancement rapide fait en la matière, ajouter une petite pression subconsciente qu’il faut faire le boulot aussi.
Pour finir, le WBS est une tache importante dans la vie du projet et ce depuis la phase tender. Il ne faut pas la négliger mais au contraire maitriser si on veut faire de la gestion du projet. Comme décris avant, c’est plutôt le résultat de l’expérience.
Un conseil donc, il faut construire sa petite base de connaissance de WBS. Tout document qui vous tombe entre les mains (planning ou WBS), il faut le macher, l’avaler, le recracher, le re-macher et après l’avaler encore. Analyser surtout les estimations d’hommes jours, les hypothèses utilisées. Notez tout ce qui vous parait incompréhensible à ce stage et n’hésitez pas à poser à celui qui vous l’a envoyé deux ou trois questions sur le WBS (il ne faut pas abuser de questions non plus, sinon tu ne recevras plus rien de lui)