在最近的“敏捷澳大利亚”大会上，敏捷教练 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. 敏捷内化后，它强调协作、交流、优雅地响应变化，这会提升组织在运作、尤其是在快速变化的环境中的应对能力。
敏捷方法会经常需要做重新评估，而这对传统培训出来的项目经理来说似乎有些古怪；而对投资组合管理又能自然地契合，这是个有趣的反常的事。但是在敏捷过程中，我们考虑项目实践时关注的是项目层次上的工作行为，而不是项目组合层面上的，这就更反常了。基于这个原因，我们得出下面的结论：
敏捷过程开发的好处之一，是它为我们提供了统一的主题依据，使我们对未来进行考虑和规划的层级，不再是基于项目组合，而是降到项目的层级。
你所在的组织，采纳敏捷方法，对组织的治理流程又产生了怎样的影响呢？
评论