Fournir de mauvaises nouvelles
Vous devez absolument soulever la question rapidement, mais si vous pouvez le faire dans un délai raisonnable (c'est-à-dire quelques heures, pas plus), vous devriez faire une petite analyse d'impact avant de le faire.
Comme pour toutes les mauvaises nouvelles, il est préférable de fournir des informations détaillées (plutôt que de simplement laisser échapper "il va être tard"), alors fournissez autant / beaucoup de:
1) Estimations / délais révisés pour les tâches qui ont glissé.
2) Estimations / échelles de temps révisées pour les tâches futures qui, selon vous, compte tenu du fait que certaines choses sont déjà dépassées, peuvent prendre plus de temps.
3) Très brèves raisons pour lesquelles le glissement s'est produit (ne tournez pas, juste la vérité, mais ne donnez pas l'impression que vous faites des excuses). Dans ce cas, vous déclarez "Nous avons estimé sur la base des règles X et Y mais ils ont maintenant inclus Z qui n'a jamais été mentionné". Il pourra peut-être l'utiliser pour expliquer le retard aux clients et les éduquer sur l'importance d'être minutieux en premier lieu.
4) Si possible, des alternatives pour remettre les choses sur les rails (réduisant généralement la portée mais il peut y avoir d'autres options - d'autres parties du projet peuvent être en avance et il peut être possible de déplacer les tâches).
N'oubliez pas qu'avec les dérapages, l'impact psychologique / de crédibilité est culminant. Vous pourrez peut-être vous en tirer avec un, mais le second sera beaucoup plus difficile et le troisième encore plus difficile.
C'est pourquoi le point 2 est important - révisez non seulement ce qui a déjà glissé, mais aussi les tâches futures qui, selon vous, peuvent prendre plus de temps que prévu. Le glissement se produit dans les TI, ne pas apprendre de ses erreurs est un plus grand péché.
Empêcher d'avoir à livrer de mauvaises nouvelles
Il y a deux scénarios ici: premièrement, vous n'avez pas fait les estimations vous-même, auquel cas vous ne pouvez pas faire grand-chose d'autre que de pousser à participer aux estimations la prochaine fois.
Deuxièmement, vous avez fait les estimations vous-même, auquel cas vous devez voir comment faire de meilleures estimations. Pour moi, la phrase clé de la question est "il y a toujours des surprises car les règles métier sont trop complexes" .
Avec égards, si cela arrive toujours, cela ne devrait pas être une surprise . Si vous n'obtenez jamais que la moitié des règles métier, vous devez supposer cela dans vos estimations et autoriser le fluage des fonctionnalités.
Vous pouvez soit le faire en augmentant les estimations des règles que vous avez (cela fonctionne mais vous n'informez personne de ce qui se passe réellement), mais il vaut mieux dire avec vos estimations "Historiquement, les règles que nous obtenons sont une version simplifiée de ce qu'ils veulent vraiment. Les règles qu'ils ont énoncées prendront 3 jours à mettre en œuvre, mais nous devons prévoir 3 jours supplémentaires pour les règles qui n'ont pas été mentionnées mais qui seront probablement découvertes pendant le développement et les tests. "
Si le PM remet cela en question, vous devez lui rappeler toutes les fois où cela a été vrai (avec des exemples - il est difficile de discuter des exemples) et suggérer doucement qu'il est dans son intérêt de livrer à temps ainsi que le vôtre, n'est-ce pas? vaut mieux être conservateur?
Mais l'essentiel: si vous sous-estimez toujours en raison d'un facteur spécifique (dans ce cas, le fluage des caractéristiques), intégrez-le dans vos estimations.