在最近的“敏捷澳大利亚”大会上，敏捷教练Renee Troughton谈论了她改变组织治理模型，使组织更好地支持采纳敏捷方法的经验。

　　IT News用“项目管理办公室的没落”为题的一篇文章概括了她的讲话。她讲述了新西兰社会发展部如何通过彻底地改变项目立项和审批方法，解散了由60人组成的PMO（项目管理办公室）。她说：

　　通过解散PMO，并创建适应项目规模的标准项目流程，我们能让每天直接使用项目流程的人对流程拥有所有权。

　　会议上，当地的一些其他组织也讲了他们如何改变治理流程，促进授权并专注于消除官僚障碍，包括Telstra和Suncorp——都对项目启动过程做了简化，并通过一些定期审核规则和简单的检查点，来帮助项目组专注于交付最具业务价值的事情，以适应多变的环境。

　　类似地，Mark Thiele也鼓励大家接受“Fluid IT”的思想——利用云服务和敏捷方法，做IT时专注于业务和交付方案，而不必考虑IT组的交付能力或他们的治理流程。他说：

　　专注业务时应当忘记IT，他们应该去看商业机会，依据它的价值决定是否有可行性，而不是考虑IT能力能否跟得上。不过，我并不是说要忽视IT。正相反，让IT服务于商业目标比以往都更重要。能把业务流程和工作成效转化为潜在的IT解决方案，比那些懂得怎么应用IT的人，不是会做得更好吗？

　　在这篇文章中，他从IT服务交付的方面，讨论了IT要做到可改变（即“fluid”）的必要性。

　　另外一位来自cPrime叫Kevin Thompson的评论者，讨论了当组织接纳敏捷方法后，PMO需要做哪些变化。他发表过一篇论文，题为“敏捷PMO”，在文中他讨论了PMO的职责和活动，以及它们怎么被敏捷所影响。他总结说：

　　组织采纳了敏捷流程后，对PMO、PgMO或PPMO产生的变化主要有下面两种：

　　1.敏捷的过程界定或影响了PMO和PgMO的战术实践，也改变了PPMO管理投资组合所需的信息的类型和及时性。

　　2.敏捷内化后，它强调协作、交流、优雅地响应变化，这会提升组织在运作、尤其是在快速变化的环境中的应对能力。

　　敏捷方法会经常需要做重新评估，而这对传统培训出来的项目经理来说似乎有些古怪；而对投资组合管理又能自然地契合，这是个有趣的反常的事。但是在敏捷过程中，我们考虑项目实践时关注的是项目层次上的工作行为，而不是项目组合层面上的，这就更反常了。基于这个原因，我们得出下面的结论：

　　敏捷过程开发的好处之一，是它为我们提供了统一的主题依据，使我们对未来进行考虑和规划的层级，不再是基于项目组合，而是降到项目的层级。