Helping Your PMO Help You
Do any of these traditional PMO scenarios match your agile team experiences?
Your traditional PMO is so laughably outdated that most agile projects ignore them; other projects produce token deliverables to appease them, but these bear little resemblance to anything actually happening on the agile projects. The PMO looks for conformance to BDUF (big design up front) methodologies with signoffs to premature speculations about requirements and scope definitions. It reports progress on traditional projects such as being 75% through requirements gathering or 50% through analysis and design, as if these non-value delivering activities are actual progress. Finally, when projects have issues, the PMO responds by creating more review and approval groups to ensure competence and adds gates and signoffs to try and improve quality.
If these scenarios sound familiar to you, I would like to ask a follow-up question: How is your agile rollout going? Is the PMO the last bastion of opposition or are you fighting pockets of resistance and misunderstanding throughout you organization? Is the once no-brainer decision to switch to agile actually causing some headaches and frustration? If you answered “yes” to this too, you are not alone.
It turns out the PMO is not usually the problem, but they are a good litmus or “canary in the coalmine” for how an agile
Please log in or sign up below to read the rest of the article.
"That rainbow song's no good. Take it out." - MGM Executive Memo after first showing of The Wizard of Oz |