Gouvernance de portefeuille, discipline PMO, et les décisions à prendre quand les programmes commencent à dériver. Nous arrivons sur les programmes qui doivent atterrir. Et sur ceux qui ont déjà manqué la date.
Status reports verts jusqu'à ce qu'ils ne le soient plus. Listes de risques exhaustives. Personne avec l'autorité de tuer un workstream. Dépendances entre programmes sans owner. Nous apportons la discipline.
Modèles PPM, contrôle d'investissement, reporting exécutif.
Assez de discipline pour atterrir, pas trop pour se noyer.
Diagnostic + récupération à 90 jours sur les programmes qui ont perdu la confiance.
Agile, traditionnel, ou bi-modal. Ce qui correspond au travail.
Quand l'essentiel de la livraison est fait par des parties externes.
Le programme opérationnel derrière une transaction.
Ce qui est vraiment en vol. Qui est responsable. Ce qui est à risque. Où vivent les dépendances. Vue exécutive vs réalité terrain.
Structure PMO, RACI, cérémonies, cadence de reporting, gates de governance. Assez léger pour être adopté.
Faire tourner la PMO en vivant pour un cycle de reporting complet. Ajuster en fonction de ce qui a survécu au contact de l'organisation.
Opérer la PMO aux côtés de votre équipe pendant que vous recrutez ou développez le leader permanent.
Environ 25 % du temps, la recommandation est d'arrêter le programme. Le diagnostic seul économise plus que la run rate de l'année suivante.
État du programme, vraies raisons du glissement, périmètre récupérable, coût de récupération vs coût d'arrêt. Une conversation honnête, à l'écrit, au sponsor exécutif et au board.
Reset du périmètre, ré-engagement d'une date, tenir la ligne. Leadership de programme interim senior si nécessaire. Progrès hebdomadaire visible au comité exécutif.
ERP global, intégration TMS, continuité business maintenue tout du long.
Construction de 10 000 unités sur friche, livrée 48 % sous le budget initial via redesign et renégociation.
Via DevOps et continuous delivery.
Atteint via discipline service management ITIL.
Via adoption Agile/DevOps dans un business logistique 24/7.
Cycle de reporting financier comprimé via intégration système dans un groupe global de trading et industrie.
C'est un CIO senior qui la fait tourner, pas un analyste junior avec un template. Le rendu est un programme qui atterrit, pas une PMO qui produit 40 status reports par semaine.
Oui. La recommandation d'arrêter fait partie de la valeur de la mission, pas de son échec. Environ un quart des diagnostics de sauvetage finit par "arrêter le programme".
Ce qui correspond au travail. Les migrations ERP sont surtout waterfall. Les builds produit sont surtout agile. Les organisations bi-modales ont besoin des deux.
Non. Nous apportons un leadership de livraison senior et l'operating model. Votre équipe de livraison, interne ou partenaire, fait le travail. C'est pourquoi la discipline persiste.
Ou un qui doit atterrir et où vous ne pouvez pas vous tromper. Apportez-le.