À l'ère des bouleversements numériques, la capacité à fournir rapidement de la valeur est essentielle à la survie d'une organisation. Ce besoin est l'une des raisons de la popularité croissante d'Agile, avec sa capacité à livrer plus rapidement et à permettre des cycles de feedback plus rapides avec les clients. L'agilité a parcouru un long chemin depuis l'époque où elle était une idéologie marginale réservée aux francs-tireurs et aux penseurs qui sortent des sentiers battus. De nos jours, les grandes organisations du monde entier adoptent Agile à grande échelle et s'éloignent du modèle traditionnel de financement des projets.
Il y a un aspect d'Agile dont on parle beaucoup de nos jours et que relativement peu de gens comprennent vraiment :le modèle de produit. Cette approche est utilisée pour décentraliser la prise de décision et aligner de manière plus étroite et cohérente la capacité des ressources numériques sur les secteurs d'activité par lesquels l'entreprise apporte de la valeur aux clients. Il s'agit de s'éloigner du modèle traditionnel de financement de projet, par lequel la prise de décision était centralisée via un processus lent et coûteux d'estimation de tous les travaux potentiels et d'allocation temporaire de ressources partagées aux travaux approuvés, pour adopter un style plus Lean Portfolio Management de planification, de financement et de livraison des travaux.
Avant de pouvoir comprendre correctement le modèle de produit et ses avantages, nous devons d'abord examiner le modèle de financement de projet pour comprendre pourquoi il est apparu et les défis qu'il crée.
Problèmes associés au modèle
Lorsque vous décrivez Agile à des personnes qui travaillent depuis longtemps dans l'informatique, il n'est pas rare d'entendre : "Mais c'est comme ça qu'on travaillait avant !" Ils n'ont pas tort. Avant les 1990s, les départements informatiques étaient beaucoup plus petits qu'aujourd'hui, car l'informatique se limitait aux ordinateurs centraux et autres grands appareils centraux. Les 1990s ont vu l'émergence des systèmes client-serveur basés sur PC, et notamment ceux délivrés via un navigateur web. Tout à coup, chaque département d'une entreprise pouvait créer un logiciel client à l'aide d'outils relativement simples - et ils l'ont fait. Vous avez vu des serveurs surgir partout - sous les bureaux et dans les placards à balais. C'était excitant, mais cela a créé quelques problèmes.
Les directeurs financiers ont remarqué toutes ces dépenses et ont réalisé à quel point elles étaient souvent inefficaces. Chaque département achetant son propre serveur puissant pour faire fonctionner un système n'était pas la meilleure utilisation de l'argent. Tous ces ordinateurs éparpillés dans le bureau représentaient un risque pour la sécurité - beaucoup de données sensibles qui pouvaient être volées ou perdues si un disque dur tombait en panne. De plus, le travail était souvent effectué de manière incohérente, chaque département engageant ses propres programmeurs, ce qui rendait le support et l'intégration vraiment problématiques. L'informatique a donc été recentralisée. Un plus grand nombre d'entreprises ont créé des départements informatiques centraux sous la direction de directeurs de l'information, qui rendent souvent compte au directeur financier.
Dans ce modèle, le service financier décide chaque année du montant qu'il souhaite consacrer à la technologie, compte tenu de la situation financière de l'entreprise, et "taxe" les unités commerciales d'une partie de leurs revenus pour créer une réserve centrale. L'équipe de direction établit des stratégies qui sont censées guider les décisions d'investissement. En théorie, les projets sont sélectionnés sur la base de ces stratégies afin de concentrer les ressources sur les plus hautes priorités pour l'ensemble de l'entreprise. Dans la pratique, les priorités locales sont généralement à l'origine du processus, chaque région travaillant sur le processus pour récupérer "son" argent.
Les cas d'affaires sont massés pour générer la jolie image qui obtiendra le feu vert de la finance. Une fois que le travail commence réellement, presque toute l'attention se porte sur le fait de tenir l'informatique responsable de ses performances par rapport aux estimations qui sont souvent ajustées au cours du processus de planification afin d'obtenir l'approbation. Et, la valeur commerciale initiale qui avait été promise est rarement évaluée après le projet. Le succès est généralement mesuré par le triangle de fer de la gestion de projet : respect des délais, de la portée et du budget. Peu importe si le travail fourni a réellement généré des résultats réels pour l'entreprise.
Le modèle de projet a créé un certain nombre de problèmes qui ont eu un impact négatif sur la façon dont les équipes ont planifié et livré l'innovation.
Les problèmes liés au modèle de financement de projet ne s'arrêtent pas là pour les organisations où personnes relèvent de silos fonctionnels-- ce qui est courant dans les organisations informatiques -- et des pourcentages de leur temps sont temporairement alloués à diverses équipes de projet. Cela crée une situation inconfortable où plusieurs projets se disputent les mêmes ressources, à savoir que les personnes sont affectées à plus d'un projet. Et naturellement, dans cette situation, chaque chef de projet fait valoir que son projet est le plus important pour l'entreprise.
Comme vous pouvez l'imaginer, cela crée un environnement de travail difficile qui finit par nuire à l'entreprise. Cela signifie que différentes équipes au sein d'une même organisation travaillent les unes contre les autres pour atteindre les objectifs de leur projet, au lieu de travailler pour faire avancer l'entreprise. De plus, ce modèle laisse l'organisation dans un état constant d'incertitude et d'instabilité. Les ressources étant partagées (et disputées) entre plusieurs projets, un revers sur une initiative aura un effet domino qui nuira à tous les autres projets.
Cela semble contre-productif, non ? Elle l'est.
En plus d'être instable et imprévisible, ce modèle de ressources partagées n'est pas efficace pour fournir une amélioration continue. Les gens sont constamment retirés de leurs départements fonctionnels et affectés à différentes équipes de projet. Une fois qu'elles ont rempli leur mission au sein d'une équipe, les personnes sont retirées et affectées à un nouveau groupe, et le cycle continue. Ils sont coincés dans un état transitoire, sans avoir le temps ni la motivation d'investir de l'énergie dans l'amélioration continue. En fait, étant donné les exigences de respect des délais, de la portée et du budget, l'équipe est positivement encouragée à ne pas se concentrer sur autre chose que la réussite du projet. Et il y a souvent une séparation entre les personnes qui mettent en œuvre les projets et celles qui s'occupent des opérations et de la maintenance. Ainsi, les équipes de projet n'ont pas à gérer les problèmes qu'elles causent en aval. Loin d'encourager l'amélioration, c'est une recette pour la mauvaise qualité et la dette technique.
Dans la prochaine partie de cette série , nous allons examiner comment ces problèmes sont traités dans le cadre du modèle de produit. En attendant, apprenez-en davantage sur la façon dont Planview permet de passer des projets aux produits en regardant la démo ou téléchargez notre livre blanc sur "Lean Portfolio Management for the Enterprise" pour voir comment les organisations se tournent vers le LPM pour les aider à passer à un modèle centré sur les produits.
