Share via

战胜半衰期 (t 1/2)：实施后管理 PPM 解决方案

  • 项目

本文是我们的“从战壕”集合的一部分。 本文介绍如何设置框架来为 Project Portfolio Management (PPM) 解决方案设置治理模型。 它还包括一个示例治理计划，可用作设置自己的治理策略的起点。

若要下载本文的Word版本，请参阅击败半衰期 (t 1/2) ：治理 PPM 解决方案，实现后：白皮书。

若要查看更多文章，请参阅 “从战壕”白皮书。

击败半衰期 (t 1/2) ：治理 PPM 解决方案，实现后

简介

在放射性物理学中，半衰期 (t1/2) 是一个数量下降到其值的一半所需的时间，在时间段开始时测量。 (参考： https://en.wikipedia.org/wiki/Half-life) 。

那么，这如何适用于最近实施的新项目组合管理 (PPM) 解决方案？ 应用它的原因是，成功实现的 PPM 解决方案附带了到期日期。 如果不花时间围绕 PPM 解决方案的管理来规划、设计和执行治理过程，则可以放心，解决方案将充满过时的数据、错误的设计更改、与实际组织流程不同步的流程，并且列表会继续。 就像一辆从未接受过维护的汽车一样，你的解决方案将停止产生预期的 ROI。 你的用户将变得被动，要么停止使用解决方案，要么大力提倡其他解决方案。

本文的目的是讨论为 PPM 解决方案设置治理模型的框架。 还提供了一个示例治理计划，可用作设置自己的治理策略的起点。

内容和原因

虽然“治理”这个词对不同的人可能有不同的含义，但从核心来看，治理计划是一套自我强加的政策和程序，以确保应用在所有领域都是健康的，并为该工具的投资带来最佳回报。

你问，为什么有必要设置这些限制？ 这类似于你居住的房子的维护。 想象一下，每次需要修复或添加到家中时，都会显示不同的承包商，并且其工作方式与以前的承包商不同。 很快，你肯定会最终出现不匹配的窗口、多设计门旋钮等。 这就是为什么构建者在构建某些内容、需要维护的组件标准等内容时要遵循所有这些代码和准则是有意义的。

同样，PPM 解决方案上线后，将会出现一些更改、增强和删除功能。 除非你为“如何”执行这些更改设置了标准，否则你可以放心，解决方案在一路上完全混乱。

治理领域

开始考虑为 PPM 解决方案设置治理计划时，需要考虑实际想要管理哪些领域。 有许多理论和模型可用于为企业解决方案制定治理计划，你可以自由选择最适合组织的方案。 在本文中，我们将讨论适用于大多数 PPM 实现的模型之一。

确定所需治理领域的最简单方法是考虑可能发生更改的领域，然后设置治理计划来管理这些更改。

注意

即使对于本身不是“更改”的项目，而是标准维护 (例如：添加新用户、更新时间表时间段等，) ，记录一组标准过程也很重要。

通常，PPM 解决方案有四个关键方面可能会发生更改。

PPM 解决方案的四个关键更改领域：信息、设计、基础结构和流程。

信息治理

实现 PPM 解决方案后，可以合理地假设你从解决方案中的良好“主”数据开始。 例如，这些包括企业资源详细信息、企业日历、相关自定义字段等 -- 实质上是使你能够有效使用 PPM 解决方案的所有“主”数据。 但是，随着你继续使用该解决方案，人员会更改部门，一些人离开组织，日历需要更新为新的假日，需要创建时间报告期，可能需要更改会计周期，并且列表会不断更新。 显然，如果未更新此数据，则所有报告都将不准确，安全配置也会不准确。

信息治理负责保持此数据更新和完整，以便解决方案的其余部分可以利用此核心数据。

设计治理

需要成为治理计划的一部分的第二个领域是维护 PPM 部署的“设计”。 继续使用解决方案时，将会有调整解决方案设计的请求。 这可能是由于特定组想要更改其使用工具的方式，或者想要利用新功能。 一个经典示例是切换报告完成时间的方式。 你可能已选择使用工作完成百分比方法，而添加新部门时，为了与其他财务解决方案集成，可能需要将其切换到“每个周期的工时数”方法。 因此，问题是谁将评估此更改在整个解决方案中的影响，以及如何推出更改。

设计治理是管理影响 PPM 解决方案整体设计的更改的计划。

流程治理

很容易将此治理领域视为设计治理的一部分，因为大多数情况下，流程和设计是齐头并进的。 但是，从整体上讲，这一领域涵盖的不仅仅是设计。 它解决了 PPM 解决方案内外流程的治理问题，以提升其有效性。

例如，假设 PMO 应该在每个星期三上午向高级管理层提交报告。 你可能已设置一个流程，以确保时间表在每个星期五的某个时间之前提交，并且所有项目经理在周一上午之前更新和发布其项目计划，然后才进行报告。 现在，假设高级管理层要求在星期一上午而不是每个星期三上午发送报告。 这会触发有关如何使用 PPM 解决方案的过程的更改，而不是更改 PPM 解决方案本身的设计。

这些类型的更改需要由一组标准规则管理，这些规则定义为流程治理的一部分。

基础结构治理

这是另一个看似容易孤立的区域，但可能会与上述其他三个区域重叠。 简单地说，应随安装一起维护支持 PPM 解决方案的基础结构。 应属于此类治理模型的关键项的一些示例包括：

  • 安装 Service Pack 或累积更新。

  • 安装新的加载项或应用程序。

  • 升级基础结构 (添加应用程序服务器、Web 服务器等，) 以解决性能问题。

  • 由于组织中其他应用程序发生更改，基础结构更改 (例如，所有服务器的虚拟化) 。

在等式的一面，决定是否安装某些内容纯粹是基于优点 (例如，它是否会对任何当前生产解决方案产生不利影响，) 。 任何基础结构等式的另一面是查看安装导致的“过程”或“设计”更改。 在某些情况下，基础结构更改可能是其他领域发生任何更改的结果。 如前所述，虽然我们尝试将每个更改分类为其中一个区域的一部分，但某些更改可能会完全重叠所有四个区域。

关键问题

无论你尝试设置哪个治理领域，都需要回答三个关键问题，这些问题将构成治理计划的核心。

  • 例如，PPM 团队如何知道需要发生更改 (，这些更改的触发器是什么？) 。 有时，这些更改本身不是“触发”的，而是 PPM 实现的常规护理和馈送的一部分， (例如，为项目中心添加新视图)

  • 谁批准这些更改，不仅从业务投资回报 (ROI) 的角度来看，而且从治理的角度来看？

  • 谁实际进行了这些更改？ 对于其中许多更改，涉及多个团队。 在某些组织中，某些更改功能会根据业务需求转移到一部分最终用户。 在这些方案中，定义实际将进行哪些更改的人员变得更加重要。

治理团队

任何治理策略的一个关键组成部分是实际执行治理计划的团队。 虽然有几种方法可以切分和切块这个治理团队应该是什么样子，但所有思想流派都会同意的一个建议是保持简单。

以下是设置团队结构的一种方法：

治理区域所有者 这些是本文前面提到的每个治理领域的所有者。 通常，任何影响这些治理所有者指定区域的更改请求都将成为这些所有者的责任。 他们将扮演评估、提供建议、围绕新功能设置治理等角色。

中央治理委员会 (CGC) 这将是可以批准或拒绝治理所有者的建议的决策者团队。 拥有一个中央治理委员会不仅有助于减少官僚主义，还有助于将所有想法引入一个共同的平台，并相互识别地进行评估。

如上所述，根据实现的大小以及组织中存在的其他应用程序的当前流程，这些角色的定义和结构可能会更小或更大。 重要的是，至少要有一个最小结构。

其他关键组件

成功的治理策略的其他一些关键组件包括但不限于：

  • 工作请求解决方案，允许用户请求更改、特性和功能。 这可以像 SharePoint 列表或当前使用的内部工作请求解决方案一样简单。

  • 处理更改的过程，其中包括来自 IT、治理、CGC 和其他涉及的业务职能的评审。

  • 实际实现更改的过程。 这可能是从开发到测试到生产解决方案的简单更改过程，也可以是组织标准的完整Release Management。

进程

让我们将上面讨论的所有组件作为构建治理策略的一部分，并围绕它构建一个流程。 在这里，它的外观 (可能因组织要求) 而异。

治理策略图显示用户如何提交请求，以及如何通过治理委员会将其路由以供评审和批准。

总结

虽然很难预测和规划 PPM 解决方案可能发生的每个更改，但必须制定一个灵活且可缩放到任何方案的策略。

作为分手的想法，请考虑以下构建治理策略的基本常识方法。

  • 治理计划不需要是一个具有许多模糊术语和语言，没有人可以在日常生活中使用的语言。 它可以像 Excel 工作表一样简单，其中包含关键问题) 中 (解决的关键问题的快速解答。

  • 请记住，治理计划不是配置的文档。 它是一个“计划”，用于在必要时保护、维护和更改 (，) 配置。

  • 治理计划需要易于实施，并且应很好地集成到组织的现有流程中。 没有必要重新发明车轮。

  • 了解 PPM 解决方案的治理是一个不断发展的过程。 重要的是不要陷入分析瘫痪。 从小规模开始，提供价值，然后纵向扩展。

关于作者

Prasanna Adavi (PMP、MCTS、MCITP、MCT) 是高级企业项目管理 (EPM) 顾问和培训师，专门从事 Microsoft Project、Microsoft Project Server 和 Microsoft SharePoint 平台。 他的main重点是构建和启用业务解决方案，以帮助组织实现最佳投资回报。

他还在各种领域和垂直领域（包括 IT、ERP (SAP) 、制造、应用程序开发、汽车和创意服务）端到端领导项目方面拥有丰富的经验。 他是全国/地区的各种 Project Server、EPM 和 SharePoint 活动的常规演示者，并定期向 SharePoint 和 EPM 社区参与者。

Prasanna 是) (https://www.prasannaadavi.com 的普通博客作者，还每周两次运行一次播客 (https://www.msprojectpodcast.com) ，主要关注 Microsoft Project 和 Project Server 解决方案。 Prasanna 是 EPMA (https://www.epmainc.com) 的高级顾问。