Comment réussir un projet en augmentant son budget?
Alors je lisais cette réponse et cela m'a rappelé une question que je tenais depuis un certain temps mais que je n'ai jamais eu à poser.
Si vous avez un projet en retard avec une portée, un calendrier et une qualité fixes, vous êtes censé être en mesure de le résoudre en augmentant le budget, mais ... comment?
Il est évident que la suppression de la portée ou l'augmentation du calendrier sauvera un projet défaillant. Mais selon The Mythical Man-Month (et selon ma propre expérience), ajouter des personnes à un projet déjà en retard rendra le projet encore plus tard.
Alors ... exactement comment l'argent infini pourrait-il être utilisé pour sauver un projet de portée / calendrier / qualité fixe?
Réponses
La réponse sera propre au projet individuel. La loi de Wallace sur la gestion de projet, le travail principal du PM est d'informer les parties prenantes de l'effet de tout changement sur la portée, le calendrier et la qualité.
Votre question est perceptive - c'est la raison pour laquelle ils embauchent un PM. Un bon PM aura toujours une réponse "Si je vous donnais un budget supplémentaire de N%, comment le dépenseriez-vous? Comment amélioreriez-vous la portée, le calendrier ou la qualité avec de l'argent supplémentaire?"
Une partie de la réponse se trouve dans votre plan de projet - vous avez calculé la chaîne critique et les chemins critiques alternatifs à travers le plan de projet - laquelle de ces alternatives est la plus plausible avec un budget supplémentaire?
Une partie de la réponse se trouve dans d'autres questions que vous avez déjà développées. Quelles sont vos contraintes? Quels choix avez-vous dû faire en raison de choix budgétaires qui seraient modifiés si le budget était augmenté.
la plupart des réponses se trouvent dans votre journal des risques / problèmes. Quels risques / problèmes pourraient être des opportunités si vous aviez un budget supplémentaire?
petite chicane; le budget ne peut pas faire réussir un projet. Un budget infini ne crée pas une probabilité infinie de succès. Le budget est une contrainte, et la probabilité de succès du projet est toujours déterminée par la contrainte la plus restrictive. Si le budget est infini, la portée ou le calendrier régiront le projet. Une voiture ne peut pas rouler si le réservoir d'essence est vide, mais elle n'ira pas plus vite si le réservoir d'essence est trop rempli. Si le budget est suffisamment bas pour contraindre le projet, il est facile de prédire comment l'augmentation du budget améliorera la probabilité de succès; si le budget est suffisamment élevé, il est alors difficile de prévoir comment le budget supplémentaire affectera la réussite du projet. La formulation de la question détourne quelque peu les vrais problèmes. "Comment réussir un projet en augmentant son budget?"? 2/3 du temps, vous ne pouvez pas - parce que le projet n'est pas limité par le budget. Mais c'est un problème avec la formulation de la question.
Le budget comme contrainte non liée
Jeter de l'argent à un coût irrécupérable ne «sauvera» pas un projet qui échoue, mais si vous n'allouez pas les ressources adéquates pour répondre aux autres contraintes de votre projet, un projet ne peut pas réussir en premier lieu. Par exemple, si vous avez trois développeurs gérant un processus qui prend sept personnes, il est peu probable que le projet se termine à temps. L'ajout de quatre développeurs supplémentaires une semaine avant la sortie du projet ne sera d'aucune utilité (voir la loi de Brooks ), mais l'ajout de ressources adéquates au dernier moment responsable - en laissant le temps de mettre à niveau l'équipement, les processus et le personnel - peut permettre un projet pour répondre à ses contraintes de temps ou de portée.
Il est préférable de bien dimensionner le budget à l'avance. Un budget plus important vous permet d'investir dans de bonnes personnes, une formation de cadres et de compétences, des outils améliorant l'efficacité, des matériaux et équipements de meilleure qualité, etc. Le sous-financement d'un projet crée une contrainte, mais un budget (en soi) n'est généralement pas suffisant enabler.
Prenons l'exemple suivant:
- Etant donné que le projet a un délai serré de 6 mois à partir de maintenant (calendrier fixe),
- Et un ensemble de fonctionnalités non négociable (périmètre fixe),
- Quand le projet est planifié
- Ensuite, le budget (coût) doit être ajusté pour s'adapter à la portée et au calendrier.
En d'autres termes, vous disposez de trois curseurs qui s'influencent mutuellement. Vous ne pouvez pas verrouiller plus de deux d'entre eux, par exemple "Vitesse, coût ou fonctionnalités; choisissez-en deux!" Plus vos autres curseurs sont contraints, plus vous avez besoin de flexibilité dans la dimension non liée.
Si vous n'ajustez pas le sommet du budget pour répondre aux exigences des sommets fixes, vous ne vous retrouvez pas avec un triangle - vous vous retrouvez souvent avec un objectif de gestion non financé (ou sous-financé). Une fois que cela se produit, vous devez immédiatement réviser la vision de votre projet pour lire: "Nous créons l'échec grâce à la pensée magique."
Le triangle de fer du coût, de la portée, du temps, n'en choisissez que deux , est un modèle de contraintes de projet. C'est un bon modèle, mais déroute parfois les gens qui pensent ne pouvoir travailler que sur une dimension, tout en gardant les deux autres fixes. Si le temps et la portée du projet sont ensemble si contraignants qu'aucune somme d'argent ne peut les compenser, votre projet ne réussira pas en augmentant le budget. Si je vous donne un quatrillion de trillions de dollars pour mettre un autre homme sur la lune demain après-midi, vous ne pourrez pas le faire. Et c'est la même chose avec les projets logiciels.
Si vous jetez de l'argent sur des problèmes trop tard ou si vous vous attendez à beaucoup, vous avez toujours des problèmes . Si votre projet est en retard et que vous apportez de l'argent trop tard, cela ne sauvera pas votre projet. La réponse de Todd couvre bien cela, donc je n'insisterai plus là-dessus. Ce que je veux souligner cependant, c'est le fait que l' argent est un catalyseur. Les choses qui étaient «fixées» pourraient tout à coup ne plus l'être.
Par exemple, supposons que votre projet consiste à optimiser une application pour qu'elle s'exécute efficacement sur de petites machines virtuelles, en utilisant efficacement les ressources matérielles, en maintenant les coûts du cloud à un niveau bas et en permettant un scalling horizontal plus efficace à l'avenir. Vous avez identifié le travail à faire et vous avez deux mois pour le faire (pour une raison quelconque). Au bout d'un mois, l'équipe découvre qu'elle va probablement manquer la date limite. Ils ne peuvent pas réduire la portée, car tout ce qui y est défini est nécessaire pour que tout fonctionne. Et ils ne peuvent pas déplacer la date limite parce que c'est réglé. Alors vous apportez de l'argent. Beaucoup.
Vous pouvez faire venir plus de personnes, mais ce faisant, vous découvrez que la loi de Brooks s'applique, et maintenant l'équipe pense qu'elle le sera encore plus tard. Mais le temps et la portée sont toujours fixes. Ou sont-ils?
Si vous prenez l'argent et le mettez dans les plus grandes machines virtuelles que vous pouvez trouver, autant que vous pouvez en trouver, vous ne vous souciez plus du tout de la portée du projet. Votre portée fixe disparaît soudainement complètement. Ce n'était pas si arrangé après tout. Votre application peut maintenant être une corne de ressources sur le cloud, et vous ne vous en souciez pas car vous avez de l'argent pour payer les factures.
Donc en conclusion :
- ce n'est pas trois contraintes, choisissez seulement deux. C'est en fait un équilibre entre tous et les changements dans l'un affectent les autres d'une autre manière.
- une augmentation de budget peut sauver votre projet mais seulement si elle est appliquée au bon moment et sur les bonnes choses .
La portée, le calendrier et la qualité définissent «ce que» le projet doit livrer, mais ils ne définissent pas «comment» il livrera. Comme indiqué dans d'autres réponses, un budget plus élevé peut permettre de modifier le «comment». Dans mon esprit, je vois le "Triangle d'Or" comme une "Pyramide d'Or", où le triangle de base est formé des contraintes "Coût, Temps, Portée", et la hauteur de la pyramide définit la "Qualité". Par conséquent, tous les quatre sont liés.
Il est vrai qu'il est rarement efficace de consacrer des ressources à un projet sans discernement, mais si le moment est opportun, davantage de ressources peuvent être en mesure d'apporter un projet à temps et de qualité. Comment? - Eh bien, il n'y a pas de bonne réponse unique, mais diviser le projet en morceaux plus gérables et allouer les bonnes ressources aux bons éléments du projet sera généralement mieux que de simplement intégrer plus de développeurs dans le mélange sans restructurer le projet pour les accueillir.
Alternativement, plus de fonds peuvent également permettre une approche totalement différente. Par exemple, plutôt que de créer une solution en interne pour éviter le coût d'achat d'une solution coûteuse mais disponible dans le commerce, l'argent supplémentaire peut changer cette décision. Vous fournirez toujours le résultat attendu - mais vous achèterez la solution plutôt que de la construire. Mais encore une fois, si vous attendez trop tard dans le projet, vous échouerez.
Ce que je dis, alors, c'est que si vous identifiez les problèmes suffisamment tôt, vous pouvez prendre des mesures pour dépenser plus d'argent efficacement pour réaliser le projet. Et c'est la clé: le timing est tout. Croiser les doigts et espérer que "tout ira bien dans la nuit" jusqu'à ce qu'il devienne clair que ce ne sera pas le cas, est une recette pour un désastre. Une bonne gestion de projet, un suivi, une surveillance, une analyse des risques, une planification et des conversations avec votre sponsor de projet seront toujours payants et vous permettront d'apporter des changements suffisamment tôt pour être efficace, en identifiant les problèmes le plus tôt possible, puis en dépensant l'argent nécessaire. (ou changer d'autres aspects de votre approche) pour résoudre les problèmes émergents.
Ouais, ce serait super d'avoir une réponse universelle à "comment collecter des fonds" :) Mais si vous devez choisir, je pense que la haute qualité bat la plupart du temps.
Bien sûr, nous sommes souvent en retard sur le calendrier et quelqu'un d'en haut commence à faire pression et nous cédons et accélérons. Mais si nous nous retrouvons avec un mauvais produit, nous serons toujours (!) Dans les mémoires comme de mauvais programmeurs. J'entends des gens se plaindre de la qualité des produits terminés il y a des années - les utilisateurs détestent toujours ces développeurs parce qu'ils continuent à utiliser des outils peu pratiques (en réalité, les développeurs n'étaient pas mauvais).
En même temps, si nous ne terminons pas certaines fonctionnalités cruciales , nous resterons un peu dans la niche, mais il est alors possible que le projet soit financé davantage en raison des demandes de l'entreprise .
Mais si vous avez rejoint un projet qui a beaucoup de problèmes, il est probable que vous puissiez résoudre certains problèmes et l'accélérer.
Je suis un partisan de Brooks Law mais je ne suis pas d'accord avec l'idée que c'est 100% vrai 100% du temps avec 100% des projets. Différentes tâches ont différents degrés d'élasticité des ressources où l'ajout de travailleurs aura des résultats variables à la fois en termes de calendrier et de qualité, en fonction de la tâche, en fonction de l'environnement, en fonction des matériaux de travail disponibles, en fonction d'une multitude de variables connues et inconnues qui ont un impact sur les résultats.
Je pense donc qu'un budget infini, si une telle chose était une réalité, pourrait et aurait un impact favorable sur un projet en difficulté confronté à des problèmes de calendrier ou de qualité sur certains projets, dans certains environnements, pour certains types de problèmes de causes profondes. Je pense que c'est quelque chose qu'un PM et une équipe devraient évaluer au cas par cas et je soupçonne qu'avec d'autres variables aléatoires qui affectent nos résultats, vous gagneriez parfois, perdriez d'autres fois.
J'ai l'impression que ma réponse est vague et ambiguë; cependant, je pense aussi que les projets complexes traitant d'humains complexes dans des environnements complexes sont tout aussi vagues et ambigus. Cela nécessite une analyse, de l'innovation, des expériences et une prise de risque.