Nous avons beaucoup entendu parler du rôle, ou du manque de rôle, du bureau de gestion de projet (PMO) dans le monde Agile. Et, sur la transformation de l'informatique d'un atelier axé sur les "projets" à un atelier axé sur les "produits" - ce qui menace à nouveau le rôle du PMO. Quel est donc le rôle d'un PMO ? Le même que celui qu'il a toujours eu. Non - pas la gouvernance. L'époque où le PMO faisait office de police de la méthodologie est révolue depuis longtemps. Le véritable PMO stratégique est un "portfolio shop", qui facilite les décisions concernant le travail à effectuer plutôt que la manière de le faire. S'assurer que le travail s'aligne sur la stratégie et est équilibré entre les départements, les ressources et les sources de financement. De plus, le suivi de l'avancement de ce travail pour assurer une livraison réussie.
Alors pourquoi un PMO devrait-il passer à une orientation produit ? Trois raisons.
1. Agilité
Tout d'abord, la plupart des développements de logiciels sont réalisés à l'aide d'un certain type de méthodologie Agile, et ce pour une bonne raison. La méthode Agile permet de livrer fréquemment des travaux de plus petite envergure, ce qui réduit considérablement les risques d'une initiative plus importante. Mais Agile fonctionne également mieux avec des équipes de longue date orientées autour d'un seul "produit" logiciel. Dans le monde du PMO, les produits équivaudraient à des applications - ERP, CRM, PSA - choisissez votre acronyme. Plutôt que de financer des projets distincts, il est judicieux de financer des équipes pour chacun de ces "produits" d'application, puis de leur confier le travail souhaité.
Le bugaboo dans ce domaine a toujours été l'infrastructure. Vous n'allez tout simplement pas construire un centre de données en itérations Agile. Ou l'êtes-vous ? Aujourd'hui, de nombreuses entreprises ne construisent plus leur propre infrastructure technologique. Ils l'achètent chez Amazon, Microsoft, Google et d'autres. Pour mettre en place les serveurs et l'infrastructure nécessaires à un nouveau système CRM, il suffit de s'abonner à un système et de le configurer sur AWS. Le monde de l'infrastructure a donc pris le chemin du "logiciel" et peut lui aussi travailler de manière Agile.
2. Capacité
"Eh bien, j'ai encore des aménagements de bureaux et d'autres infrastructures non cloud à construire. Pourquoi est-ce que j'organiserais ça comme des produits ?" vous pourriez demander. La réponse est simple : la capacité. Disons que nous avons un atelier informatique de 500 personnes, et supposons que tout, y compris le développement d'applications, utilise encore une approche en cascade. La manière traditionnelle de traiter la gestion de la capacité des ressources consisterait à planifier chaque projet proposé par type de ressource ou par une sorte de pool de ressources. J'ai donc maintenant, disons, 100 types de ressources pour planifier la capacité entre elles. Tout ce que je veux savoir à ce stade est, laquelle 20 de ces 200 propositions devrions-nous même amener à l'étape suivante ? Essayer de le faire par une planification détaillée des ressources conduira à une sérieuse paralysie par l'analyse.
Cependant, dans un grand atelier informatique, certaines personnes se spécialisent. Vous n'aurez pas un DBA SQL polyvalent, vous en aurez au moins un pour votre système ERP, votre système CRM et votre présence Web frontale. Idem pour les programmeurs, l'assurance qualité et autres. Il ne reste que votre équipe d'infrastructure - qui est son propre produit partagé. Nous avons donc maintenant notre gamme de produits - un pour chaque application, puis l'infrastructure d'application, la mise en réseau, la sécurité et d'autres "produits" communs. Cet alignement nous permet de déterminer la capacité des équipes virtuelles travaillant sur ces produits. Nous pouvons ainsi séparer les demandes par produit et les faire correspondre à la capacité de chaque équipe.
Organiser la capacité par "équipes" de produits est tout simplement logique lorsque vous essayez de faire correspondre l'offre de capacité à une demande presque toujours écrasante.
3. Alignement stratégique
Quel est le rôle du PMO dans ce nouveau monde axé sur les produits ? Le PMO - qu'il s'agisse de l'entreprise ou de la technologie - peut aider à déterminer quelles sont les lignes de produits et les équipes de ressources (virtuelles ou réelles) qui travaillent sur ces produits. Ils peuvent apporter la stratégie d'entreprise à la table pour faciliter les conversations de financement pour chaque produit. De plus, étant donné qu'il y a plus de demande que de travail, ils peuvent organiser le travail par produit pour s'adapter aux paramètres d'investissement et de ressources de chaque produit. Le travail pourrait prendre la forme de backlogs de style Agile ou de projets complets disposés de manière ordonnée sur une feuille de route pour chaque produit, et ils pourraient être regroupés en un seul portefeuille d'entreprise combiné. Enfin, le PMO doit encore surveiller et aider à guider le travail pour une livraison réussie et mesurer si le travail a atteint les résultats commerciaux visés.
Dans le monde du développement de produits, le rôle de la gestion de produits est "d'apporter le travail aux équipes d'ingénieurs". Le rôle du PMO d'entreprise, et surtout du PMO technologique, est très similaire.
