#
由 superadmin 于 2024/05/12, 11:01 最后修改
Show last authors
1 {{info}}
2 **学习长河老师 ¥599元  [[ITIL4基础级认证核心考点讲解和习题辅导网课>>https://www.itil4hub.cn/bin/view/ITIL4%E8%AE%A4%E8%AF%81%E5%9F%B9%E8%AE%AD%E8%80%83%E8%AF%95%E8%B5%84%E6%96%99/ITIL4%E5%9F%BA%E7%A1%80%E8%AE%A4%E8%AF%81%E5%BF%85%E8%80%83%E7%9F%A5%E8%AF%86%E9%80%9F%E5%AD%A6%E7%BD%91%E8%AF%BE/]]，领取500元考试券**
3 {{/info}}
4
5
6 **申明：**
7
8 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注**微信公众号：ITILXF**，并回复“**ITIL 4项目管理**”即可。
9
10
11 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为AXELOS持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守AXELOS 和 TSO所申明的所有版权要求。
12
13
14 本文档翻译工作参与人员：
15
16 翻译：黄翔
17
18 审校：唐波
19
20 审核：樊伟焯
21
22 总审：长河
23
24 统筹：常宏
25
26
27
28 ----
29
30 {{box cssClass="floatinginfobox" title="**Contents**"}}
31 {{toc/}}
32 {{/box}}
33
34 = **1. 关于本文档** =
35
36 本文档为项目管理实践提供了实用指南。它分为五个主要部分，包括：
37
38 ● 关于实践的一般信息
39
40 ● 本实践相关的流程和活动及其在服务价值链中的作用
41
42 ● 参与本实践的组织和人员
43
44 ● 支持本实践的信息和技术
45
46 ● 对本实践的合作伙伴和供应商的考虑
47
48
49 == **1.1 ITIL 4资格认证计划** ==
50
51 本文档中的部分内容可作为以下教学大纲的一部分以供检查：
52
53 ● ITIL战略领导者–数字化和IT战略
54
55 详情请参考各部分教学大纲。
56
57
58
59 ----
60
61 = **2. 一般信息** =
62
63
64 == **2.1目的与描述** ==
65
66 * **关键信息**
67
68 项目管理实践的目的是确保组织中的所有项目都成功交付。这是通过对项目的所有方面的规划、授权、监督和维护的控制来达成，并确保相关人员的积极性。
69
70
71 **ITIL 架构师笔记**
72
73 在设计ITIL 4架构的时候，将项目管理实践纳入到ITIL的范围中似乎是一次革命性的决定。有效管理项目的能力对于每个组织都很重要，尤其是在它擅长针对需求和环境定制各种方法的方面。因此，添加了项目管理。然而，在我们研究这些实践的细节时，我们得出的结论是，这还不够，因为项目绝不应被孤立地管理；它们应有助于实现组织和/或项目群定义的更大的用途。因此，此实践指南涵盖项目和项目群管理；此实践的用途可以更新为以下内容：
74
75 项目群和项目管理实践的目的是确保组织中的所有项目都成功交付，并为组织及其干系人创建价值做出贡献。
76
77 实践在本指南中称为项目和项目群管理（PPM）。在专门针对项目管理或项目群管理的部分和段落中，我们使用了特定的术语来指代项目或项目群。
78
79 我们希望这种扩展的范围对从业人员来说很有价值，我们计划将在ITIL Foundation和其他ITIL出版物的下一版中引入项目管理。
80
81 项目群和项目管理在规划中扮演着不可或缺的角色，对组织引领变革时，优化了资源的使用，风险的掌控，并链接了变更以实现预期的价值。
82
83 项目群可以由组织不同领域的项目组成。例如，推出新的产品或服务可能依赖于销售、营销、分销和IT部门中运行的项目，所有这些部门都侧重于交付计划所需的结果。项目群可以是独立的，但更常见是项目组合管理的一部分（有关详细信息，请参阅投资组合管理实践指南）。
84
85 项目通常侧重于交付特定的输出；一个项目群的重点是为组织和其他利益干系人创造价值的结果和收益。项目群通常比单个项目持续时间更长。
86
87 项目和项目群与日常运作（通常也被称为日常业务）的区别在于它们是：
88
89 ● 引入重大变化
90
91 ● 是临时组建的
92
93 ● 带来超出日常业务之外的风险和机会。
94
95
96 == **2.2 术语和概念** ==
97
98 一个专业的重要元素之一是专业群体特有的知识体系。在过去50年中，世界各地的项目管理协会认真尝试以专业协会的身份行事，并花费大量时间和精力发展知识体系（BOKs）及其相关的认证方案。
99
100 BoK是一种资源；提供构成专业标准的概念、功能和活动并且为成功交付该专业核心功能提供关键信息。在这种情况下，其核心功能是项目和项目群管理。
101
102 所有项目管理BOK都描述了如何指导、管理和交付项目，但它们在术语和生命周期上都有所不同，这就是为什么去弄明白是哪个BoK在项目背后去推动其变化是很重要的。主要的项目管理BoK是APM知识体系（APMBoK^^®^^）和PMI知识体系（PMBoK^^®^^），尽管还有其他与变更管理（CMBoK）和网络安全（CYBoK）有关知识体系。
103
104 在本实践指南中，关键术语和定义基于AxelOS PPM Bokes和方法，包括：
105
106 ● PRINCE2^^®^^
107
108 ● PRINCE2 Agile^^®^^
109
110 ● Managing Successful Projects^^®^^
111
112 ● P3O^^®^^
113
114
115 === **2.2.1 项目群** ===
116
117 * **定义：项目群**
118
119 一个临时的、灵活的结构，用于协调、指导和监督一系列相关项目和活动的实施，为交付与组织战略目标相关的成果和利益而进行的活动。
120
121 项目群的重点是取得成果和效益，而不是产出或产品。与项目相比，协调其边界内的项目，更关心利益干系人参与、沟通和指导。
122
123
124 项目群致力于通过其下运行的相关项目逐步实现组织能力的变化。围绕能力和利益交付的不同阶段性变化而构建的一组项目称为一个“批次”。这些渐进的变化使组织能够在项目群期间实现利益，而不是等待整个项目群结束。
125
126 成功管理项目组（MSP）中描述了典型的项目群生命周期或转型项目群的流程。这在图2.1中显示。
127
128 (% style="text-align:center" %)
129 [[image:1644740057187-223.png]]
130
131
132 图2.1 MSP转换流动
133
134
135 === **2.2.2 项目** ===
136
137 * **定义：** **项目**
138
139 为根据约定的商业案例交付一个或多个产品而创建的临时结构。
140
141 项目的重点是在规定的时间、成本和质量内交付产出（产品或其他可交付成果）。通过这样做，这些输出对组织是有价值的。
142
143 这些输出同样为组织实现了价值，但是，在传统（瀑布）项目中，这些益处主要是在项目完成之后才会体现。
144
145 图2.2中显示了传统线性（瀑布式）项目的典型生命周期，如使用PRINCE2^^®^^管理成功的项目所述：
146
147 (% style="text-align:center" %)
148 [[image:1644740482201-233.png]]
149
150 图2.2 PRINCE2项目管理流程
151
152
153 敏捷方法的工作方式和项目群类似，但是时间被高度压缩。敏捷交付是按增量计划的，并且预期在每个增量的部署中产生收益。因此，组织可以尽早地获得它的好处。
154
155 图2.3中显示了如PRINCE2 Agile^^®^^中所述的敏捷项目的典型生命周期。
156
157
158 (% style="text-align:center" %)
159 [[image:1644740499328-897.png]]
160
161 图2.3 PRINCE2敏捷项目管理流程
162
163
164 === **2.2.3 敏捷** ===
165
166 “敏捷”一词非常宽泛，在敏捷社区中以许多不同的方式来看待。有一组被称为“敏捷方法”的众所周知的框架，也有众所周知的行为、概念和技术被认为是敏捷工作方式的特征。没有一个简单的敏捷定义能准确描述敏捷，但是敏捷宣言图2.4中显示的已相当接近了。
167
168
169 (% style="text-align:center" %)
170 [[image:1644740523147-503.png]]
171
172 图2.4敏捷宣言2001
173
174
175 敏捷之所以如此流行是因为它有助于解决对软件交付方式提出的新要求。它需要更频繁地被生产出来，同时保持特定水准的质量，以满足数字化时代的需求。（有关敏捷软件开发的更多信息，请参见软件开发和管理实践指南和ITIL^^®^^4：高速IT，第4.2节）。
176
177 与传统的交付方式相比，敏捷阶段更短，迭代更多，更渐进。如图2.5中所述，还存在通过尽早部署产品来更快交付收益的举措。
178
179
180 (% style="text-align:center" %)
181 [[image:1644740539714-441.png]]
182
183 图2.5敏捷vs瀑布
184
185
186 在图2.5的左侧，增量敏捷方法允许在项目上进行多个部署。右侧的瀑布式交付倾向于在项目的末尾进行单次交付。
187
188
189 === **2.2.4 瀑布（传统）** ===
190
191 "瀑布"是第一个软件开发方法，继承于制造和建筑行业，在那些行业你可以或不能迭代（当你建造了一座塔或一座桥，你不能回到"改进"的基础）。但是，由于软件容易频繁使用变更，瀑布并不总是最佳解决方案。
192
193 瀑布经常被与敏捷并谈，但这两种方法相互对立。它们之间的主要区别是瀑布对频繁更改反应不佳，这就是为什么它在频繁变更是常态的软件开发社区中声誉不好。
194
195 在瀑布式方法中，项目分为不同的阶段来完成（请参阅图2.5），并逐步向客户，业务或消费者做最终的发布。首先有一个很大的设计，然后以线性方式执行计划，希望设计没有变化。
196
197 在敏捷空间中，在有足够的前提设计来推动项目发展，知晓设计必将演化，而变更是不可避免的。随着组织许多方面的数字化，敏捷方法被成功应用于许多数字化解决方案，而不仅仅是软件开发。其中包括数字化营销、发布和其他与内容相关的活动、数字化基础架构和数字化通信。专注于灵活、不断发展的资源（组织、社区、伙伴关系、知识）的非数字化项目也受益于此敏捷方法。
198
199
200 === **2.2.5 整体方法** ===
201
202 项目管理实践并不限于管理项目的进度；它应该有助于价值共创和组织的总体战略。为了实现这一目标，组织的项目管理方法应该是整体性的。PRINCE2描述项目管理的七个关键方面应作为实践的一部分不断解决。它们被称为七个PRINCE2主题，在表2.1中进行了概述。
203
204 表2.1 PRINCE2关键主题
205
206 [[image:1644740610249-186.png]]
207
208
209 === **2.2.6 定制** ===
210
211 组织通常基于一个或多个Bok、方法和框架开发PPM方法。无论最佳实践的选定来源如何，组织都应根据组织的特定需求、功能和约束调整其指导。定制是一项正在进行的活动，通常通过基于间隔和基于事件的对PPM方法的持续审查来完成（参见第3.2.1节）。
212
213
214 === **2.2.7 指导，管理和交付** ===
215
216 PPM实践中有三个关键的控制级别：指导，管理和交付。在项目群和项目中，这三层之间具有“空隙”，以使管理的层级可以执行控制，而无需微观管理下面的层。这些“空隙”的构成是各层之间的受控连接，因此每个层都可以在上一层所确定的参数范围内工作。这被称为异常管理，只有那些参数的异常才会引起上层的注意，以便做出决策。
217
218 图2.6显示了此方法的示例。
219
220 (% style="text-align:center" %)
221 [[image:1644740632994-471.png]]
222
223 图 2.6在组织中指导、管理项目和交付产品
224
225
226 === **2.2.8 项目群管理** ===
227
228 为了成功地管理项目群，需要：
229
230 * 领导力
231 * 愿景
232 * 聚焦价值
233
234 ==== **2.2.8.1 领导力** ====
235
236 项目群将组织的战略目标转化为个别项目的具体目的和目标。领导和指引项目群为在战略目标、业务运营和项目交付之间架起了桥梁。因此，有效领导的关键原则包括：
237
238 * 有能力创建一个有吸引力的愿景，描绘出一个有益的未来，并将它传达给一系列利益干系人。
239 * 授权决策，给予个人有效履行职责的自主权
240 * 可见承诺与授权
241 * 相关技能和经验提供有效管理。
242
243 ==== **2.2.8.2 愿景** ====
244
245 愿景是美好未来的图景，是一个必不可少的要点，是任何项目所涉及的大型利益干系人社区的接受认同、动力和活动协调的推动者。
246
247 愿景宣言概述了愿景，并用于传达所需“将来”状态的宏观印象，一个好的愿景宣言应该是：
248
249 * 写给未来的状态：组织在未来的一个快照
250 * 可以很容易地被各类的利益干系人理解
251 * 适用于最广泛的利益相关者群体作为目标受众
252 * 描述一个令人信服的未来
253 * 与所传达的愿景相匹配的转型变化程度
254 * 除非愿景真正依赖于时间，避免设定目标日期。
255 * 足够灵活
256 * 简短而易记。
257
258 ==== **2.2.8.3 聚焦价值** ====
259
260 价值驱动项目群管理的许多方面，这意味着它是项目群管理的中心；项目群主要通过提供利益来实现价值的需求驱动。
261
262
263 **定义：利益**
264
265 由成果产生的可测量的改进，被视为一个或多个利益干系人的优势。
266
267
268 图2.7说明了项目群中管理的影响范围
269
270 (% style="text-align:center" %)
271 [[image:1644740699654-707.png]]
272
273 图2.7项目群中管理收益的影响范围
274
275
276 === **2.2.9 指导项目** ===
277
278 为了成功地指导项目，项目委员会的职责包括：
279
280 * **责任** 项目委员会对项目群或公司管理负责，对项目在项目任务中定义的约束范围内的成功或失败负责。
281 * **统一方向** 这是关于项目委员会级别的团队合作。虽然每个项目委员会成员都有责任满足特定利益干系人类别的利益，但至关重要的是，必须商定并传达项目的一个统一的总体方向。
282 * **有效的授权** 项目委员会成员必须使用PREECE2为此设计的组织结构的控制来授权。该方法在这方面的关键特性是管理阶段的实现：逐个阶段地将项目的管理委派给项目经理。项目委员会定义了如何执行项目的框架，以确保整个企业中的一致性。
283 * **跨职能集成** 项目管理团队是临时的，几乎总是跨职能型，由项目具体负责设置的结构。项目委员会会成员必须确保职能型或管理组织承认和尊重这一点，并确保项目委员会的权威不受损害。
284 * **承诺资源**  项目委员会成员负责承诺为成功完成项目所必需的资源。这是一个重要的标准，总的说来，他们应该能够提供项目成功所需的所有资源。
285 * **有效决策** 项目委员会为项目做关键决策。做决策是施加控制的方法，PRINCE2为此提供了优化的框架。
286 * **对项目经理的支持** 项目经理关注的是项目中的日常管理，它通常是一个忙碌而压力较大的角色。项目委员会可以通过展现对项目经理的可见和持续支持，帮助消除一些障碍来减轻部分项目经理的压力。
287 * **有效沟通** 项目经理必须确保沟通及时，并且有效的，无论项目内部，还是与关键的外部利益干系人。
288
289 === **2.2.10 管理项目** ===
290
291 与瀑布项目方法相比，在敏捷方法下管理项目需要稍微不同的形式。在传统项目中，项目经理在日常决策流程中更加核心。在敏捷情况下，团队有权在设定的参数内做出决策，而项目经理促进产品的发展，而不是指导工作。
292
293 为实现自组织和协作，项目经理应：
294
295 * 信任团队，而不是参与
296 * 让团队独立工作，不扼杀他们的创造力
297 * 信任那些提供最正确的解决方案的人
298 * 确保项目委员会确切了解"授权"的含义，以便团队得到支持，而不是被否决
299 * 让团队参与发布规划，真正了解什么是可以发布的和何时可以发布
300 * 专注于拥有稳定的团队来驱动创新和正确的解决方案
301 * 坚持客户全程参与，并在需要时提供建议
302 * 确保团队认识到客户完全融入到团队中，以便他们提供业务的需求。
303
304 要维护透明度和沟通，项目经理应：
305
306 * 清晰地向团队传达产品愿景，以便他们知道他们正在构建什么以及为什么
307 * 提供客户/用户可以经常使用的东西，以便获得快速反馈
308 * 确保包括客户在内的整个团队都参与到愿景中，以获得最大的动力
309 * 确保团队拥有真正"最小"的可行产品
310 * 确保项目委员会和高层利益相关者理解MoSCoW的优先级技巧，以便他们的预期可以提前设置。
311 * 契动与了解项目利益相关者避免误解
312 * 理解和沟通团队的利益和威胁，这样他们就不会只依赖产品
313 * 确保客户代表的需求得到满足，并且解决方案满足业务的需要
314
315 为了保持健康而鼓舞人心的工作环境，项目经理应：
316
317 * 与团队经理合作确保团队良好合作
318 * 确保团队在Scrum方法中接受培训，并在敏捷交付方面有良好的基础
319 * 确保团队知道什么样的敏捷方法正在被使用，以便它可以被适当地裁剪。
320 * 明确与利益相关者传递流程，以便正确地设定他们的期望
321 * 与产品经理（Product Owner）合作
322 * 确保团队可以按需发布，以便于发布交付不受到基础架构的影响。
323 * 确保团队尽可能一起集中办公，以促进合作和沟通
324 * 确保团队了解"服务领导者"的角色，以便他们了解辅导和指导之间的区别
325
326 要成功计划、监视和控制，项目经理应：
327
328 * 参加每日站会，了解项目的状态
329 * 集中精力解决问题，使工作没有障碍物。
330 * 确保定期举行回顾会议以改进交付
331 * 确保团队知道“修复什么”和“完善什么”，以最大化价值满足业务
332 * 确保项目信息/报告（小组委员会）是可理解的，以实现进度跟踪
333 * 确保项目级别需求尽快被优先考虑，以帮助专注业务的需求
334 * 使用生产为基础的规划，并将产品链接到收益，以便在正确的时间创建正确的输出，以便尽早创造收益。
335 * 同意报告标准，对进度报告的准确性有信心
336 * 在不同项目上同步冲刺团队以保持接口相关
337 * 确保团队不会不断将"困难"内容延迟到后续冲刺阶段，以避免不断发展的解决方案的完整性遭到破坏。
338
339 === **2.2.11 在敏捷环境中交付产品** ===
340
341 敏捷环境中的产品交付依赖于考虑两个主要方面的不可分割的联系：
342
343 * 哪些是固定的，哪些是灵活的
344 * 优先级和时间限制/冲刺。
345
346 ==== **2.2.11.1 固定的和灵活的** ====
347
348
349 (% style="text-align:center" %)
350 [[image:1644740780898-455.png]]
351
352 图 2.8将公差应用于项目
353
354
355 表2.2演示了PRINCE2 Agile视图。
356
357 表2.2PRINCE2敏捷如何对项目的六个方面的容差进行查看
358
359 [[image:1644740963824-501.png]]
360
361
362 ==== **2.2.11.2 优先级和时间限制/冲刺** ====
363
364 在决定哪些是固定的，哪些是灵活之后，团队需要对那些他们将要调整的方面进行优先级排序，以便保持在一定的时限范围内。
365
366 优先级可以基于MoSCoW技术。这些规则是非常具体的：
367
368 * **必须有** 要求将提供最小可行产品，可以保证交付。这可以通过确保在时间范围内分配给必须满足需求的工作不超过60%来实现。
369 * **应该有** 重要的要求，但不是至关重要的。如果这些被排除在外，业务可能会发现很困难。这可能会使他们不得不采取代价高昂的变通方案。
370 * **可以有** 更不重要的要求，可以被看作是一个愿望清单，如果不考虑，最终解决方案不受什么影响。建议将最多20%的时间分配给该类别，为时间提供20%的容差。
371 * **不会有 **（这个时间）要求是项目团队已经同意的要求将不会在这个特定的时间内交付。这并不意味着他们将永远不会交付，因为他们可能在项目后期在一个不同的类别实现。
372
373 在设定优先级后，团队现在可以在时间限制或冲刺规划级别执行详细的规划，同时牢记分配给各种MoSCow优先级的百分比。时间盒是一个固定的时间（通常在2到4周之间），在此期间，开发人员进行了一系列迭代唯一的目的就是在此期间尽可能多地交付。然而，第一个关注是提供“必须有”要求后跟"应该有"，然后"可以有"。如果时间不足，业务将决定首先放弃哪些"可以有"，以便满足更高的优先级要求。这意味着业务必须对它将会得到什么和不会得到什么采取新的思维方式。然而，由于他们参与到交付中，没有什么会让人感到意外。
374
375
376 == **2.3 范围** ==
377
378 PPM实践利用管理人员对计划、监控和控制项目或项目群的所有方面的能力，激励所有相关人员按时实现目标，并实现指定的成本、质量和性能。这是通过如下达到：
379
380 * 定义项目管理方法并与利益干系人保持一致
381 * 确保项目管理方法采用并嵌入到组织中
382 * 指导项目
383 * 管理项目
384 * 不断回顾实践以改进。
385
386 尽管PPM实践与项目和项目群管理仍然密切相关，但有多个活动和职责范围未包含在PPM实践中。表2.3中列出了这些内容，并列出了可以找到它们的实践参考。重要的是要记住，ITIL实践仅仅是价值流的背景中使用的工具的集合；根据情况，应根据需要将它们组合在一起。
387
388 表2.3与其他实践指南中描述的PPM实践有关的活动
389
390 [[image:1644741017868-902.png]]
391
392
393 == **2.4 实践成功因素** ==
394
395 **定义：实践成功因素**
396
397 一个实践的复杂功能组件，是实践实现其目的所必需的。
398
399 实践成功因素（PSF）不仅仅是一个任务或实现价值，因为它包括所有服务管理四个维度的组件。活动的性质和实践内的PSFs的资源可能不同，但是它们共同确保实践是有效的。
400
401 PPM实践包括以下PSFs：
402
403 * 在组织中建立和维护项目和项目群管理的有效方法
404 * 确保项目和项目群的顺利实施。
405
406 === **2.4.1 在组织中建立和维护项目和项目群管理的有效方法** ===
407
408 在组织中为项目和项目群建立最佳实践的使用相对容易。优胜者必须选择最适合文化和组织风格的方法，然后吸引培训、工具和技术所需的投资，这些是参与者成功操作方法所必需的。
409
410 随着时间的推移，组织的变化和组织内部的变化驱动程序会适应外部力量，维护方法可能会变得更加复杂。如果目前的方法没有调整，可能会对它们构成挑战。为了实现这一目标，项目和项目群管理的方法和方式需要作为整个组织健康状况持续评估的一部分进行评估。
411
412 成熟度模型（如P3M3）可以用来评估组织中方法、工具和技术的流行程度，以及项目管理专业人员的能力，以便它们与不断发展的需求和组织的愿望保持一致。这些评估的报告应用于纠正或调整似乎达不到交付该方法预期的服务的任何领域。
413
414 对现有标准的任何更改都必须通过教导或简报的方式通知实践团体；因此，与早期版本相比，最新的思维转换是无缝的，并且这些方法自然成长和进化。
415
416
417 === **2.4.2 确保项目和项目群的成功实现** ===
418
419 项目和项目群的成功主要与收益交付有关。实施后的评审可能会指出技术交付中的一些缺陷，在尝试下一次项目之前，应解决这些缺陷。从经验中学习非常重要，因此，回顾、嵌入经验教训和反馈至关重要。
420
421 确保一致性在交付项目和项目群时需要遵守指南，以及项目/项目群的应用程序也确保遵循该指南。然而，如果不获得好处，这并不总是以成功交付告终。因此，保证需求的方法要比检查指南或标准更全面。项目也与人有关：那些提供需求和资源，创造产品，并商定投资人。这些利益相关者需要确信项目正在为他人尽其所能地交付。
422
423 项目可能失败的原因有很多，这可能包括：设置不切实际的期望、糟糕的方法和需求、资源不足、糟糕的项目管理以及未经过培训的团队成员。但是，通过采用有效的实践和项目管理技术来避免，有助于在所有利益相关者之间建立对期望和流程的明确理解。
424
425 一般来说，有一套简单的五条规则可以帮助防止项目失败：
426
427 * 以终为始：从明确的项目范围开始
428 * 构建项目计划：可视化在时间线上完成的所有内容
429 * 不要太在乎计划：事物可以变更，计划也是如此
430 * 检查、更新和监视：检查进度时间表，更新时间线的实际性能，监视资源的使用情况
431 * 关注质量：你不能改进质量，而不好的质量带来了不好的收益。
432
433 寻找表明项目可能出现故障的迹象也是很重要的。他们中的一些人可能是：
434
435 * 团队士气开始下降
436 * 产出的质量开始恶化
437 * 缺乏沟通。
438
439 在拥抱敏捷的组织中，ITIL指导原则为上述五个规则提供了有用的扩展：
440
441 * 聚焦价值
442 * 从你所处的地方开始
443 * 基于反馈迭代推进
444 * 协作和提升可视化程度
445 * 通盘思考和工作
446 * 保持简单实用
447 * 优化和自动化
448
449 == **2.5 关键度量** ==
450
451 ITIL实践的有效性和性能应该在每个实践所贡献的价值流的范围内进行评估。与任何工具的性能一样，实践的性能只能在应用程序的上下文进行评估。但是，在设计和质量中，工具可能有很大差异，根据其目的使用时的有效性，这些差异定义了工具的潜力或能力。有关指标、关键性能或绩效指标（KPI）以及其他可帮助实现这一问题的技术的进一步指南，请参阅度量和报告实践指南
452
453 PPM实践的关键指标已映射到其PSF。它们可以用作价值流的环境中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.4中给出了一些关键指标的例子。
454
455 表2.4实践成功因素的关键指标实例
456
457 [[image:1644741168809-180.png]]
458
459
460
461
462 ----
463
464 = **3. 价值流和流程** =
465
466
467 == **3.1 价值流贡献** ==
468
469 与任何其他ITIL管理实践一样，PPM实践有助于实现多个价值流。请务必记住，价值流绝不是由单个实践组成。PPM实践与其他实践相结合，为消费者提供高质量服务。实践贡献的主要价值链活动是：
470
471 * 设计和转换
472 * 获取/构建。
473
474 图3.1中显示了PPM实践对服务价值链的贡献
475
476 (% style="text-align:center" %)
477 [[image:1644741217430-208.png]]
478
479 图3.1 PPM实践对价值链活动的贡献的热力图
480
481
482 == **3.2 流程** ==
483
484 每个实践可以包括一个或多个流程和活动，这可能是实现实践的目的所必需的。
485
486
487 **定义：流程**
488
489 一组相互关联或相互作用的活动，将输入转换为输出。流程采用一个或多个定义的输入，并将它们转换为输出。流程定义动作序列及其依赖关系。
490
491
492 PPM实践活动构成了四个主要的流程：
493
494 * 管理组织的PPM方法
495 * 指导项目
496 * 管理项目
497 * 管理产品交付
498
499 === **3.2.1 管理组织的PPM方法** ===
500
501 此流程专注用于项目和项目群的定义、同意、沟通和推广组织全范围通用方法。它包括表3.1中列出的活动，将输入转换为输出。
502
503 表3.1输入，活动，以及管理PPM流程的通用方法的输出
504
505 [[image:1644741299528-934.png]]
506
507
508 图3.2显示了该流程的工作流程图
509
510 (% style="text-align:center" %)
511 [[image:1644741308699-642.png]]
512
513 图3.2管理PPM通用方法的工作流程
514
515
516 表3.2提供了流程活动的示例。
517
518 PPM流程通用管理方法活动表3.2
519
520 [[image:1644741339035-694.png]]
521
522 [[image:1644741397451-150.png]]
523
524 [[image:1644741422020-185.png]]
525
526
527 === **3.2.2 指导项目** ===
528
529 指导项目流程的目的是使项目委员会能够对项目的成功负责，通过做出关键决定并行使总体控制，同时将项目的日常管理委托给项目经理来进行。该流程包括表3.3中列出的活动，并将输入转换为输出。
530
531 表3.3指导项目过程的输入、活动和输出
532
533 [[image:1644741969679-345.png]]
534
535
536 图3.3显示了该流程的工作流程图
537
538 (% style="text-align:center" %)
539 [[image:1644741992310-221.png]]
540
541 图3.3指导项目的工作流程
542
543
544 流程表3.4描述了流程的活动。
545
546 [[image:1644742043978-611.png]]
547
548
549 === **3.2.3 管理项目** ===
550
551 管理项目流程的目的是使项目经理能够代表项目委员会负责运行项目的日常任务。此流程包括表3.5中列出的活动，并将输入转换为输出。
552
553 表3.5管理项目流程的输入、活动和输出
554
555 [[image:1644742086315-470.png]]
556
557
558 图3.4显示了该流程的工作流程图。
559
560 (% style="text-align:center" %)
561 [[image:1644742097649-309.png]]
562
563 图3.4管理项目流程的工作流程
564
565
566 表3.6提供了流程活动的示例。
567
568 表3.6流程管理项目活动
569
570 [[image:1644742133150-912.png]]
571
572
573 === **3.2.4 产品交付管理** ===
574
575 管理产品交付流程的目的是使解决方案开发团队能够根据业务优先级创建不断发展的解决方案，并在业务规定的时限范围、成本和质量内实现。表3.7包括流程中的活动，并将输入转换为输出。
576
577 表3.7管理产品交付过程的输入、活动和输出
578
579 [[image:1644742168647-547.png]]
580
581
582 图 3.5显示了该流程的工作流程图。
583
584 (% style="text-align:center" %)
585 [[image:1644742181444-433.png]]
586
587 图 3.5管理产品交付流程的工作流程
588
589
590 表3.8提供了流程活动例子。
591
592 [[image:1644742220426-154.png]]
593
594 表中描述的工作包可以采取传统工作包的形式：一组由项目经理整理的关于一个或多个所需产品的信息，用于将工作或交付责任正式传递给团队经理或团队成员。
595
596 在敏捷方法下，工作包可能采用略有不同的形式，但相同的期望结果。在这种情况下，它们将是谨慎的时间限定或冲刺（sprint），根据这些产品的业务优先级，在时间限定或冲刺中完成相关产品。
597
598
599
600 ----
601
602 = **4. 组织和人员** =
603
604
605 == **4.1角色、能力和责任** ==
606
607 实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定的每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
608
609 流程和活动的背景中描述了角色。每个角色具有基于表4.1所示的模型的能力类型。
610
611 [[image:1644742261773-235.png]]
612
613 表4.1能力代码和资料
614
615
616 负责所有PPM活动的角色通常是实践所有者。此角色的能力概况是CLA，尽管每个能力的重要性根据实现价值的不同而各不相同。表4.2中列出了负责PPM活动的其他角色的示例，以及相关的能力概况和特定技能。
617
618 表4.2PPM活动中涉及的角色示例
619
620 管理组织的PPM方法
621
622 [[image:1644742308000-857.png]]
623
624 [[image:1644742330945-255.png]]
625
626 [[image:1644742341899-835.png]]
627
628 [[image:1644742353372-788.png]]
629
630 [[image:1644742371680-933.png]]
631
632 [[image:1644742383748-872.png]]
633
634
635 === **4.1.1 项目群经理** ===
636
637 项目群经理的职责通常包括：
638
639 * 项目群的日常管理，包括将项目群从任命，监督和控制以及关闭项目群
640 * 作为项目群赞助商的日常代理，确保成功交付新的能力
641 * 项目群的规划以及设计，主动监控总体进度，从而解决问题，并在适当的情况下启动更正性措施
642 * 开发和实施项目群的治理框架
643 * 有效地协调项目及其相互依存关系
644 * 管理和解决可能出现的任何风险和其他问题
645 * 维护完整性的整体和项目群的一致性，并开发和维护项目群环境以支持其中的每个单独的项目
646 * 管理项目群的预算并随着方案的发展监控其支出和成本效益
647 * 促进项目交付团队的人员任命
648 * 确保项目的产出或服务交付符合项目群蓝图的要求，并符合相应的质量，时间，预算的要求
649 * 通过相关人员的输入和利益相关者的批准为蓝图的开发提供便利
650 * 管理蓝图并确保提供的功能与之保持一致
651 * 管理项目群团队的绩效
652 * 最大限度地在整个项目群中有效分配资源和技能
653 * 管理项目群的内部和外部供应商
654 * 管理与利益相关者的沟通
655 * 在项目群中存在差距或出现问题的情况下，启动额外的活动和其他管理干预措施
656 * 定期向项目群发起人报告项目群的进度。
657
658 项目群经理的技能集中在决策和业务管理。
659
660
661 === **4.1.2 项目经理** ===
662
663 项目经理是项目的日常管理的单一对接点。这个人有权在项目管理层规定的限制范围内代表项目管理层运行项目。项目经理的角色不得共享。
664
665 项目经理所需的技能更多是“硬技能”，旨在不同知识领域执行一些职责或活动。
666
667 项目经理的专业素养是基于以下能力领域的熟练程度领域：
668
669 * 管理控制
670 * 利益管理
671 * 财务管理
672 * 利益干系人参与
673 * 风险管理
674 * 组织机构治理
675 * 资源管理
676
677 项目经理负责项目管理和生产的管理工作交付流程。项目经理还将管理产品交付的职责委派给了团队经理。
678
679 作为项目的日常管理的单一对接点，项目经理的角色有许多不同的方面，其中一些显示在图4.1中。
680
681 (% style="text-align:center" %)
682 [[image:1644742415499-507.png]]
683
684 图4.1项目经理角色的各种方面
685
686
687 === **4.1.3 团队经理** ===
688
689 团队经理的主要职责是确保将产品按照项目经理所定义的适当质量生产，并遵守由项目管理层接受设置的时间和成本。团队经理向项目经理负责并受其指导
690
691
692 === **4.1.4 Scrum Master** ===
693
694 Scrum Master以多种方式为产品负责人服务，包括：
695
696 * 确保Scrum团队每个人都很好的理解目标，范围和产品域。
697 * 寻找有效的产品待办项管理的技巧
698 * 帮助Scrum团队了解清晰明确的生产待办项内容
699 * 在实践经验的环境中了解产品规划
700 * 确保产品负责人知道如何布置产品待办项以最大化价值
701 * 了解和练习敏捷
702 * 根据要求或需要促进Scrum方法事件。
703
704 Scrum Master以多种方式为开发团队提供服务，包括：
705
706 * 指导开发团队掌握自我组织和跨功能
707 * 帮助开发团队创建高价值产品
708 * 消除阻挡开发团队前进的障碍
709 * 根据要求或需要促进Scrum方法事件
710 * 在尚未完全理解和使用Scrum方法的组织环境中指导开发团队
711
712 Scrum Master以多种方式为组织服务，包括：
713
714 * 领导和指导组织采用Scrum方法
715 * 规划组织中的Scrum方法实现
716 * 帮助员工和利益干系人了解Scrum方法和产品开发的实践
717 * 为增加Scrum方法团队的生产效率提出改变
718 * 与其他Scrum Master合作，以增加Scrum方法的在组织中的应用效果。
719
720 == **4.2 组织结构和团队** ==
721
722 从项目到项目，项目团队的结构可能会有所不同，并且在很大程度上取决于项目管理采取的方法。
723
724 在PRINCE2中，有九个角色被定义为特定职责。它们与项目方向，项目管理和项目交付；尽管对于项目交付，PRINCE2仅指团队经理，而不是交付团队的成员。 角色如下：
725
726 * 项目委员会
727 * 高层
728 * 高级用户
729 * 高级供应商
730 * 项目经理
731 * 团队经理
732 * 项目质量控制
733 * 变更授权
734 * 项目支持
735
736 有关角色的详细说明，请参阅使用PRINCE2®管理成功的项目。
737
738 敏捷方法的角色列表更加简化，通常包括团队成员，团队经理（例如Scrum Master），产品负责人，有时还包括业务分析人员。它没有项目经理这个角色。
739
740 每个项目的团队结构都应根据组织的项目管理的方法以及项目的规模和复杂性而定。
741
742
743
744 ----
745
746 = **5. 信息和技术** =
747
748
749 == **5.1 信息交换，输入/输出** ==
750
751 PPM实践的有效性基于所使用信息的质量。该信息包括但不限于以下信息：
752
753 * 客户，用户和其他项目干系人
754 * 项目产品，用户和客户需求
755 * 组织对变更和项目的处理方式
756 * 市场环境和消费群体
757 * 服务及其架构和设计
758 * 项目中的合作伙伴和供应商，包括其提供服务的合同
759 * 组织的策略，产品组合和项目群
760
761 根据项目的性质，此信息可以采用各种形式，实践的关键输入和输出在第3节中列出。
762
763
764 == **5.2 自动化和工具** ==
765
766 在某些情况下，PPM实践可以从自动化中受益匪浅。在可能的情况下 有效的方法可能涉及表5.1中概述的解决方案。
767
768 表5.1PPM活动的自动化解决方案
769
770 [[image:1644742582009-461.png]]
771
772 [[image:1644742598934-357.png]]
773
774 [[image:1644742620541-611.png]]
775
776 [[image:1644742637085-164.png]]
777
778 [[image:1644742649868-897.png]]
779
780 [[image:1644742669212-394.png]]
781
782 [[image:1644742684438-229.png]]
783
784
785
786
787 ----
788
789 = **6. 合作伙伴和供应商** =
790
791 很少有服务是仅使用组织自己的资源交付的。大部分（如果不是全部）依赖通常由第三方在组织之外提供的其他服务上（请参阅ITIL第2.4节基础：用于服务关系的模型的ITIL 4版）。这意味着组织在他们的项目中使用供应商来获取服务管理的四个方面中的资源。这个包括但不限于供应商的产品和服务，能力和专业知识，工具和数据，市场占有率，战略关系等。
792
793
794 如果组织旨在确保快速有效的项目管理，他们通常会试图与合作伙伴和供应商达成密切合作的协议，消除在沟通、协作和决策制定中的官僚主义障碍（更多信息请参阅供应商管理实践指南）。
795
796 项目中涉及的外部资源应适当整合以配合团队合作假设，文化，沟通渠道和工具。与供应商的人际关系应得到持续监控和管理，如有冲突，异常情况和问题需尽快解决。应利用异常情况审查正式和非正式的供应商协议，并重新调整。
797
798 适当时，各方应就如何定义项目交付成果以及如何对于验收和移交过程达成共识。工作包的定义对此至关重要。
799
800 有时将第4.1节中描述的特定于实践的角色和团队外包。通常，如果组织有自己的项目管理卓越中心（例如，PMO），用于将外部项目管理专家集成到项目团队中。如果供应商在管理项目时采用相同的方法和过程，那么外包也会受益。
801
802 组织从外包整个项目管理中的职能或流程转变为外包一个特定的能力。通过这种方式，组织获得了它所缺乏的知识和经验，但也保留了组织内部对项目的决策、控制和责任。
803
804
805
806 ----
807
808 = **7. 重要提醒** =
809
810 实践指南的大部分内容应视为组织在建立和培养自己的实践时可能考虑领域的建议。实践指南是组织可能考虑的事情目录，而不是答案列表。使用ITIL实践指南的内容时，组织应始终遵循ITIL指导原则：
811
812 * 聚焦价值
813 * 从你所处的地方开始
814 * 基于反馈迭代推进
815 * 协作和提升可视化程度
816 * 通盘思考和工作
817 * 保持简单实用
818 * 优化和自动化
819
820 有关指导原则及其应用程序的更多信息，ITIL Foundation：ITIL 4出版物第4.3节
821
822
823
824
825 ----
826
827 = **8. 致谢** =
828
829 AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
830
831
832 == **8.1 作者** ==
833
834 Richard Rose
835
836
837 == **8.2 贡献者** ==
838
839 Raymundo Sanchez Tico, Mauricio Corona.
840
841
842 == **8.3 审阅者** ==
843
844 John Edmonds, Allan Thomson, Michael Macgregor, Dinara Adyrbai, Roman Jouravlev, Erika Flora.

导航

需要帮助？

如果您需要有关XWiki的帮助，可以联系：

深圳市艾拓先锋企业管理咨询有限公司