Il est rarement agréable de manquer une échéance, et parfois cela peut carrément limiter la carrière. La semaine dernière, nous avons évoqué certains problèmes qui contribuent au non-respect des dates d'un projet. Explorons maintenant quelques solutions.
Nous avons déjà abordé l'importance des objectifs et des spécifications du projet. Bien entendu, pour définir ces objectifs, il faut connaître les parties prenantes et obtenir leur participation. Dans cet article et dans d'autres, j'utilise le terme " parties prenantes " pour désigner l'ensemble des personnes qui s'intéressent à ce projet. Il peut s'agir de vos clients, de votre directeur, des personnes qui travaillent dans les systèmes modélisés, etc.
Lors de la création d'un plan de projet, deux adages viennent à l'esprit.
<center><em>"Attendez le meilleur ; prévoyez le pire"</em></center>
Je pense qu'il est normal d'être optimiste et d'espérer, voire de s'attendre, à ce que les choses se passent bien. Mais je ne compte pas là-dessus. Je ne fonde pas mon plan sur des hypothèses optimistes. J'aime commencer par ce qui me semble être une estimation raisonnable, puis la doubler pour tenir compte de toutes les choses dont je sais qu'elles vont mal se passer. Cela peut sembler être du "rembourrage", mais l'objectif est de déterminer un calendrier réalisable. J'ai rarement, voire jamais, constaté que ce qui semblait être un calendrier "raisonnable" au départ était en fait réalisable en fin de compte, en raison du grand nombre d'inconnues dans un projet typique.
Bien sûr, on peut toujours passer plus de temps à étudier le problème en amont pour réduire le risque à un niveau acceptable et éventuellement améliorer la précision de ses estimations. Mais à ce moment-là, le projet n'a souvent plus de raison d'être car les décisions ont déjà été prises. Les estimations de temps sont toujours des suppositions et sont toujours erronées, alors trouvez une méthode qui vous convient et passez à autre chose.
" Moins de promesses, plus de résultatsPour moi, cela signifie être conservateur. J'essaie d'éviter de trop m'engager et, dans la mesure du possible, d'éviter de partager mes intentions optimistes . Par exemple, alors que je m'attends à créer une animation 3D convaincante, je ne garantirai peut-être qu'une animation 2D ou une simple animation 3D. De même, si j'ai l'intention de modéliser des applications secondaires afin d'explorer des améliorations potentielles du système, je ne le garantirai pas dans le cahier des charges du projet.
En fait, les spécifications de mes projets comprennent généralement trois catégories :
- Produits livrables garantis - Quoi qu'il arrive, le projet n'est pas considéré comme terminé sans ces produits.
- Produits livrables probables - J'ai l'intention de les réaliser, mais si les choses tournent mal, ils peuvent être supprimés. Souvent, les parties prenantes ne savent même pas que cette liste existe, en fonction de leur tolérance à la flexibilité.
- Liste de souhaits - Dans les rares cas où le projet se déroule exceptionnellement bien, je mets en œuvre des tâches de cette liste. Cette liste ne figure jamais dans un plan de projet public.
Cette approche m'offre une certaine souplesse pour
a) éviter de décevoir les parties prenantes au cas où le projet se déroulerait mal, et
b) conserver la possibilité de ravir les parties prenantes si le projet se déroule bien.
Que se passe-t-il ensuite ?
Ces deux premières étapes ne sont que le début d'un projet. Dans de prochains articles, j'aborderai la définition des priorités, l'agilité, la communication et bien d'autres sujets qui contribuent à prendre date et à faire du projet une réussite.
Jusqu'à la prochaine fois, bonne modélisation !
Dave Sturrock
VP Produits - Simio LLC