月度归档： 2013 年 12 月

CMMI 的全称为：Capability Maturity Model Integration，即能力成熟度模型集成。
CMMI过程改进共有18个过程域，分别是：
OPF: Organizational Process Focus(组织级过程焦点)
OPD: Organizational Process Definition(组织级过程定义)
OT: Organizational Training(组织级培训)
PP: Project Plan(项目计划)
PMC: Project Monitoring and Control（项目监督与控制）
RSKM：(Risk Management)风险管理
SAM (Supplier Agreement Management)供应商协议管理
IPM： Integrated Project Management（项目集成管理）
MA： Measurement & Analysis（度量与分析）
DAR： Decision Analysis and Resolution（决策与分析）
RD&REQM：Requirement Management& Requirement Development（需求开发与管理）
TS： Technical Solution Context （技术解决方案）
PI： Product Integration（产品集成）
VER&VAL: Verification & Validation(验证与确认)
CM： Configuration Management（配置管理）
PPQA： Process and Product Quality Assurance （质量保证）
其它需要了解的
SM: Senior Manager （高级经理）
EPG：Engineering Process Group(工程过程组)
MSG：Management Steering Group（管理指导组）
PI：Process Improvement（过程改进）
OSSP：Organization’s Set of Standard Process 组织标准过程集合

CMMI评估是用于评价组织过程改进的现状。由于CMMI采用了两种不同的表示法，产生了二种不同类型的评估，一是关于具体的过程能力等级的评估；二是组织整体成熟度水平的评估。通过评估分别产生能力等级剖面图或成熟度等级。
目前，CMMI的成熟度等级评估在业界应用最广泛。
CMMI的评估要求

组织使用CMMI模型评估时，需要符合CMMI评估要求（Appraisal Requirements for CMMI，ARC）文件中的要求。评估关注识别过程改进机会，将组织过程与CMMI最佳实践对比。评估小组使用CMMI模型和遵循ARC评估方法，来指导评估和报告结果。这些评估结果被用于策划组织过程改进，产生成熟度等级或能力等级，缓解产品采购、开发和监控的风险。
ARC文件描述了几种类型评估的要求，分别是A类、B类和C类，见表1-1。
要求

/tr>

要求	A类	B类	C类
客观证据收集类型	文件审查和访谈	文件审查和访谈	文件审查或访谈
评级	必需	不必	不必
组织覆盖	必需	没有要求	没有要求
最小的评估组规模	4人	2人	1人
评估组长的要求	主任评估师	经过培训和有经验的人	经过培训和有经验的人

表1-1 评估类型的对比
CMMI标准评估方法SCAMPI

使用CMMI模型评估时，通常采用“标准CMMI评估方法”（Standard CMMI Appraisal Method for Process Improvement，SCAMPI）。SCAMPI定义了一些规则，确保评估定级的一致性。对于与其它企业实现标杆性对比的评估，评估定级必须确保一致性。
SCAMPI评估方法家族中包括了A级、B级和C级的评估方法。SCAMPI-A是最严格的和唯一能评定等级的评估方法。SCAMPI-B提供了可选部分，但实践描述是一个固定比例的范围和这些实践得到实施。SCAMPI-C提供了更广泛的选择范围，使用者可以预先定义好评估的范围，在进行过程描述时也是采用一种非常接近的方式。
CMMI评估注意事项

影响CMMI评估的要素如下：
选用CMMI哪个模型用于评估（CMMI或CMMI+IPPD）。
确定组织涉及到的评估范围和被评估的CMMI过程域，确定评价的是成熟度等级还是能力等级。
选择一种评估方法。
选择评估小组成员。
选择被访谈者。
建立评估的输出文件（例如：等级或特定实践的发现报告）。
建立评估的约束条件（例如：时间和地点）。
SCAMPI允许预先确定评估范围，这些评估选择是帮助组织商业需求和目标与CMMI进行关联。
CMMI评估计划和结果的文档中，通常包括了评估选项描述、模型范围和实施评估的组织范围。CMMI评估计划和结果的文档确定了是否满足标杆的要求。
CMMI评估原则

高层领导作为评估的发起人。
关注组织商业目标。
为被访谈者保密。
使用文件化的评估方法。
采用一种参考模型。
采用团队合作方式。
关注过程实施的具体活动。
CMMI评估流程

分析评估的要求
(Analyze Requirements)
编制评估计划
(Develop Appraisal Plan)
选择和组成评估小组
(Select and Prepare Team)
获取和分析初始客观证据
(Obtain and Analyze Initial Objective Evidence)
筹备客观证据的收集
(Prepare for Collection of Objective Evidence)
　
检验客观证据
(Examine Objective Evidence)
验证和确认客观证据
(Verify and Validate Object Evidence)
记录客观证据
(Document Objective Evidence)
产生评估结论
(Generate Appraisal Results)
宣布评估结论
(Deliver Appraisal Results)
整理和存档于评估库
(Package and Archive Appraisal Assets)

各地政策补助概览

在基于CMMI实施软件过程改善时，有些根本的思想认识问题解决不了，往往会使实施的周期比较长，效果不好，甚至导致过程改善的失败或中止。软件企业的高层领导、企业的过程改进主管、项目经理及一般的开发人员都需要对这些问题统一认识，在此基础上才能消除各方面的阻力，把握好过程改善的方向，控制好过程改善的进度。CMMI不是万能的，只有CMMI是不行的，还要技术(开发方法、工具)、人员二个要素一起改善。
　　在软件工程发展的历史进程中，人们为了解决软件危机，尝试了采用诸如形式化描述语言、结构化开发方法、CASE工具、构件化开发方法等等各种解决方案，但是效果并不那么显着， SEI提出了软件过程能力成熟度模型集成(CMMI)基于过程的角度来解决软件/系统危机。那么是否实施了CMMI，软件企业的开发能力就一定能提高，一定能带来经济效益呢?答案是否定的。如果企业里要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高，才能保证带来经济效益，因为人员、技术和过程是支撑软件开发平台的三条腿，少了那一条都不行。大家也都知道木桶原理，一个木桶可存储水的最大容量是由最短的那根木头决定的。在企业的开发能力中过程、技术(含工具、方法)、人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，都是有害的。
　　在开始实施CMMI时，最容易犯的一个错误就是“唯管理论”或孤立地只抓过程改善，忽略了开发技术与人员的提高，过分强调管理的作用，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改善就难以继续进行了。有的企业采用面向对象的开发方法进行软件开发，但是企业内并没有对面向对象技术真正了解的专家，虽然也采用RUP过程、也采用ROSE等开发工具，但是仅仅是形似，没有做到真正的OO方法，没有得到OO方法的精髓，这种问题仅仅依靠过程改善是无法解决的。还有的企业开发人员的积极性很差，工作热情很低，企业的激励机制没有起到很好的作用，这种问题也是依靠CMMI无法解决的。
　　1. 管理就是预防，管理的作用是隐性的，不都是立竿见影的，大家要有耐心。
　　在实施CMMI时，企业的管理层在开始时往往会对过程改善期望值太高，希望短时间内效果显着，正如上面所述，效果显着与否不是由一个方面的要素决定的，需要多个因素共同改善。而管理的最大作用是预防，防患于未然。
　　任何的管理的改善都是符合J曲线的，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，不过渡过了这段时间就会看到效果。所以在改善的初期大家要有这个思想准备，要有耐心。
　　2. 坚持活学活用，以我为主
　　机械照搬CMMI的条文是在实施CMMI时常犯的错误。在国内的软件企业中，都是从作坊式的软件组织逐步发展过来的，也没有经过系统工程化阶段，甚至也没有什么标准、规范。真正超过10年软件/系统工程经验的人员更是比较少的，加上大家不愿从事管理，因而有的企业所组建EPG的人员中可能在工程经验方面是有欠缺的，又没有真正的有实践经验的专家进行指导，所以对CMMI的理解就不可能一下就很深刻，不敢裁剪CMMI，容易机械照搬CMMI条文，其实这恰恰违背了CMMI的精神，CMMI是系统工程经验的集大成，是从实践中总结出来，用以指导实践的，CMMI本身也在更新版本，不断完善。每个企业都有自己的特点，就象微软的MSF，那是微软自己内部的管理过程标准，是微软的产品开发经验总结，有些内容是CMMI中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地来尝试。
　　在推行CMMI时，所以遇到的阻力，很大程度上是由于照搬CMMI的条文，不切合项目组的实际，没有具体情况具体分析。实际上，一线的管理人员、开发人员最了解实际。谁了解实际，谁有发言权。所以在制定CMMI规程标准时，尤其是在制定大家要执行的操作规程、模板和记录模版时，一定要得到执行者的认同，否则就容易造成执行和沟通的障碍，你硬要推，表面上看来似乎大伙也照规程做了，其实是表面文章，对改善没有实际帮助，以导致SPI工作受阻。
　　3. 要改良式不要革命式
　　以革命的方式来实施CMMI，期望通过一场运动来解决过程能力的问题，一种可能是不懂CMMI，不晓得管理的改进是循序渐进的，一种可能是明知故犯，期望在短期内通过CMMI评估，单纯追求市场上的轰动效应。有的企业在短时间内虽通过了CMMI几级评估，我想恐怕由于没有实效而得不到大家的认同而难以将这种“水平”持续下去。一个企业引入CMMI之后会从本质上影响企业的文化，改变大家的思想与做事方法。有人曾形象得将过程改进比喻为减肥，你是可以依靠减肥药在短时间内减轻体重，但如果不从根本上改善饮食、生活、运动的习惯，那么体重将会在短时间内恢复到原来，我认为这个比喻是十分形象的。
　　4. CMMI与企业的创新文化是不矛盾的
　　软件企业的有些管理人员，也包括一些开发人员往往抱怨或认为严格的管理会束缚他们的创新，他们认为在CMMI中提倡的一种按部就班，什么活动都要做计划、按规程标准来做，对企业的创新文化会起负面作用。在我遇到的开发人员中，越是技术钻研越深的人持这种观点的越多。我想形成这种观点主要有二个原因：一是企业在推行CMMI时，过分机械，没有从实际出发，不能与实践紧密结合，挫伤了开发人员的积极性。比如说在分析与设计阶段，需要开发人员能够发挥创意的成分更大一些，如果你要求他们一定就要按统一的文档标准来写文档，甚至字号大小、缩进格式一点也不能差，这的确很难做到，可能你需要在项目组配备文档支持人员，有他们来做这些完善工作，降低分析与设计人员的这些工作量。二是这类人员缺少真正的软件工程经验，做的大项目太少，经历的失败太少。关于这一点是不要争论的，CMMI是系统工程经验与教训的集大成，我们无需再去重复那些失败。
　　软件企业必须形成创新的文化，事实CMMI本身也一种系统工程管理的创新，而技术创新是必须进行管理才能使其有效地转化为生产力，转化为企业的实际效益，达到效益最大化，这是最根本的。
　　5. 要勇于实践，也要允许犯错误
　　CMMI就是系统工程经验与教训的总结。在实施CMMI的过程中，肯定会走些弯路，甚至于要犯错误，由此许多人会议论纷纷，一直会反映到高层经理处，这时不要犹豫，要敢于尝试，更不能因为有困难就打退堂鼓，现在大家都是“摸着石头过河”，不下水，是没有办法过河的，临渊慕鱼不如退而结网。要少说不，少说难，勇于实践，有错就改。对于软件企业的领导尤其要注意这一点，不要因为在过程中的一些实践失败，就对项目经理、SEPG等人员有偏见，要提倡这种文化。
　　6. 管理过程改进是组织内所有人的事情，而并非仅仅是SEPG的事情
　　按照CMMI专家的建议，在一个组织内专职从事软件过程改善的人数应为组织总人数的2-3%，根据这一建议，企业内一开始就配备专职的工程过程组(EPG)，这些员工专职负责企业的软件过程改善工作，另外我们根据需要组织一些技术任务组(TWG)，他们会兼职的参与特定过程规程、标准的制定、试点和修改完善工作。在这种情况，可能会出现如下的问题：
　　SEPG成了最忙的人，TWG的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖，最后还是由SEPG的成员替代TWG做工作;
　　企业的非开发人员对管理过程改进的效果一下没有明确地感受到，甚至看到由于加了些新的活动可能使项目拖期可能会更严重，于是他们可能就会将这些抱怨反馈到企业的高层经理，在推行过程中经常会听到：我这个项目时间太紧，当前不适合使用CMMI;
　　7. 高层经理迫于市场的压力，甚至可能会提出不合实际的项目工期等等。
　　推行CMMI不仅仅是管理人员的事情，每个人都要积极参与。要改变原来的一些做法：即EPG是在使劲的推进CMMI的工作，而不是大家自觉自愿的来实施CMMI。从EPG的角度来看，要做好培训的工作，首先要解决的大家的思想认识问题，这还是比较难的，有些人的思想还是比较顽固的。
　　管理首先要解决的是思想认识上的问题，不但在主观上要解决，在客观上也要有措施，光说不练是不行的，光练不说也是要否定的。曾经遇到过类似的问题，有的开发人员或者项目经理在口头上是可以接受变革的，会配合工作的，但是在具体操作，很可能又会遇到事实上的否定，这时作为CMMI的推广人员要尽快提出实施的具体措施，尽快落实。任何变革都要涉及到企业内的权利的再分配，不要忽视企业政治，这是客观存在的，所以一定要预防那些光说不练者。

1、企业如果通过了系统集成资质的认定，首先是进入了一个规范有效的宣传平台，有需求的企业会根据系统集成认定平台来筛选企业，这样就为企业增加了项目来源的可能性，也有利于借助官方平台做了宣传。
2、企业在通过系统集成资质的认定过程中，会按照评定条件从很多方面规范了自己，提高了自己的经营管理能力和技术能力，也给系统集成企业的发展提供了方向。
3、企业通过系统集成资质，很有利于提高企业的竞争能力，同时对于没有资质的企业也是一个竞争门槛。
　　更多关于系统集成资质如何申请详询桂林盈智企业获取系统集成资质的流程。

环国际项目管理中心PMP认证是由美国项目管理学会(PMI)在全球范围内推出的针对项目经理的资格认证体系，通过该认证的项目经理叫”PMP”，即ProjectManagementProfessional（项目管理专业人士）。
　　
　　自从1984年以来，美国项目管理协会（PMI）就一直致力于全面发展，并保持一种严格的、以考试为依据的专家资质认证项目，以便推进项目管理行业和确认个人在项目管理方面所取得的成就。国内自1999年开始推行PMP认证，由PMI授权国家外国专家局培训中心负责在国内进行PMP认证的报名和考试组织。该认证的通过两种方式对报名申请者进行考核，以决定是否颁发给PMP申请者PMP证书。
　　
　　1.资历审查
　　申请者的基本资历要求为：

　　申请者需具有学士学位或同等的大学学历，并且须至少具有4500小时的项目管理经历。PMI要求申请者需至少3年以上，具有4500小时的项目管理经历。仅在申请日之前6年之内的经历有效。需要提交的文件一份详细描述工作经历和教育背景的最新简历（请提供所有雇主和学校的名称及详细地址）；一份学士学位或同等大学学历证书或副本的拷贝件；能说明至少3年以上，4500小时的经历审查表。

　　申请者虽不具备学士学位或同等大学学历，但持有中学文凭或同等中学学历证书，并且至少具有7500小时的项目管理经历。PMI要求申请者需至少5年以上，具有7500小时的项目管理经历。仅在申请日之前8年之内的经历有效。
　　
　　2.PMP考试

　　PMP申请需参加PMI组织和出题的PMP考试，并且合格，合格的标准是你必须答对全部题目中的131个题目，PMP考试目前在国内一年开展四次。相对而言，PMP考试的审查更为严格，而且是硬性的，没有变通的余地。全球统一出题统一标准，各方面体现全球化。

所有的项目在刚开始的时候，看起来都充满了希望。但不幸的是，不是每个项目都能发挥其所有的潜能。那么你应该如何开始你的ITIL计划，并保证能量水平与所关心的ITIL要求之间的运转正常呢？
威廉，莎士比亚的名言说道：“期望是一切悲痛的源头。”他诚恳地用喜剧化语言告诉我们，当你负责领导某项业务的时候，你必须为了项目能够顺利进行而设定目标。所以我不得不对这位伟大的诗人说抱歉了，因为我要将他的名言改为：“不合理的期望是一切悲痛的源头。”

期望——我怎么知道什么是合理的

无论你是否具有系统开发、项目管理、商业分析或者其他的专业领域的背景，都应该听说过设定目标的重要性。但是如果每个人都知道它的重要性，为什么每个项目都不能达到预期的目标呢？也许最相关的问题是你应该如何合理的设定预期目标。

期望依赖于建立合理的目标。根据本文的主题，我们规定目标的含义是股东们对于某个项目成果的共识。清楚的目标是最好的，因为它们最容易被衡量。显然，这是股东们定义项目成功的标准，但是如果项目没有达到预期目标，股东也是最容易失望的人。

为了将项目风险最小化，首先应该有一份完整的股东名单，并确保每位股东都包括其中。如果你发现某位股东不愿意参与此事，你有三种选择。你可以劝说他们参与，也可以请高级管理人员帮助你劝说股东参与，如果前面两种方法都不可行，你可以记录下来哪些股东没有参与该项目，并将其列为一大风险。因为如果你的项目结果不尽如人意的话，那么股东是最有可能对此表示不满的，无论这是不是他们的本意。其次，一定要尽可能地减少那些不确定的决策。当然，你在作决定之前没有先见之明，怎么降低风险呢？

弥补差距——我应该如何开始

绝大部分项目都有开始阶段。这个阶段中需要确定股东，起草项目文档，明确项目目标，详述债务来源及总数，明确项目小组成员和组织者，明确项目进程中的里程碑和交付时间。所有这些内容都应该包含在项目计划文档之中。

不幸的是，绝大部分项目都在开始阶段结束之后才开始进行人员培训，那个时候项目中重要的计划文档通常都已经完成了。你可能需要在项目开始之前就对项目中的关键人员进行培训。在项目的开始阶段，公司开始同厂商接触，了解能够帮助实施ITIL解决方案的工具。你必须在接触厂商之前就形成内部的专家意见，这样才能够和厂商位于同等地位。至少股东和团队成员应该上一堂ITIL基础课。

即使你还没有确定厂商，早期的培训也能帮助你的项目小组成员形成共同语言，帮助他们快速准确地讨论如何实现这一构架。很多项目小组都会在事后追悔莫及“我们不知道我们当时所不了解的是什么”。及早培训能够避免这种情况的出现。

ITIL计划中四个重要的问题

为了确保项目取得成功，所有的项目小组都必须管理期望——ITIL计划也不例外。ITIL计划中，你需要管理的最大的期望就是——你希望可以象管理所有其他项目一样管理它。下面是ITIL计划同普通项目之间的四大差别，这将影响你决定项目会议和整个项目周期。
1、你的ITIL计划可能会持续几年的时间

确保每个独立的项目目标符合整个企业的ITIL目标，且每个项目都对整体目标都有价值，是非常重要的。例如，你在实施Configuration Management（配置管理）项目的时候，规定使用Configuration Management Database（CMDB，配置管理数据库）来保存所有的CI（Configuration Items，配置项）信息。从这个项目本身的价值考虑，你必须优先处理最重要的CI类型。选择的这些CI类型可能会引起冲突。你可以按照一个时间进度给大家提供一个清晰的说明，告诉他们哪些CI类型会被存放到CMDB中。你的股东可不希望出现在你的列表中的第20名，如果他们知道自己没有被忽略或忘记，那么他们将更有可能支持你的项目。记住，共同的培训经历将会让人们有一个平等讨论基础。

2、你应该把相关的ITIL项目作为一个整体程序进行管理

绝大部分希望利用ITIL管理项目的公司都会创建一套项目执行的方法。但很多公司都缺乏能够在几年的时间里，统一管理相关项目的机制。

如果ITIL计划实施的周期横跨几个年度，而项目的周期通常较短的话，你可以成立一个比较长期的小组，该小组存在的时间会超过单个项目周期，称之为程序组。程序组的职责是在整个执行过程中确保整体一致性，并在与并行项目发生冲突的时候，做出协调和判断。

还是回到我们上面举的CMDB的例子，你可能注意到我们将CMDB描述成一个精确、实时更新的CI信息管理库。但是这个库并不是凭空产生的。它要求Change Management（变化管理）工作来保证数据的更新（项目1）。等数据到位以后，Incident Management（事件管理）开始使用这些数据改善服务响应（项目2）。Problem Management（问题管理）可以将事件和问题联系起来（项目3）。在CI之间建立起完整的联系（项目4）能够改进影响力分析，帮助改善变化规划，提高应用效能，减少无计划的停工。从总体上检查这些独立的项目是程序组的职责。如果目前你没有这样一个小组，就应该考虑成立一个。

3、你在建设的是构架而不仅仅是产品

总的来说，产品比构架更容易实施，因为绝大部分主流的软件厂商都已经在大量的企业用户身上积累了丰富的经验，并将软件产品打造得比较完善了。但是，如果你要建设的是ITIL构架，就突然要做很多决定，决定如何在ITIL的世界里重塑现有的方法。如果你目前的方法已经存在于当前的应用之中，那么就需要将这些方法关联起来。

不要试图去寻找单一的最佳答案。你必须在各种不同的方法之间权衡，并限制可以使用的基于ITIL进程的自动化工具。但是最重要的是，你必须让股东做出他们的决定。因为ITIL不是告诉人们做事情的唯一方法，人们可以尽可能地展现他们的想法。如果你发现自己身处这样的处境之中，就一定要提醒股东，所有的项目都仅仅是漫漫长路中的一步。你可以在将来重新考虑这个决定。4、在计划实施过程中你可能会逐渐失去一些资源

我在回顾项目会议的时候发现最普遍的项目计划/风险之一是假设完成项目所需要的金钱、时间和人力资源都是稳定而持续的。对于持续时间不长的单个项目来说，你可以指望某个人从项目的开始到结束都能参与。但是我很怀疑参与ITIL计划的每个人都能从现在开始陪你走过未来的几年。

如果你同意我的观点，那么就应该在你的项目中采取一些安全措施来应对人员变动和交接的情况——甚至可能是高层人员。有两种方法能够减少影响：第一，尽可能多地为项目中的职位准备好接替的人员。你不需要设置一些正式的职位，你只要确保每个项目中都有不只一个人理解单项工程的关键因素就可以了。显然，实时更新的文档和状态报告对此非常有帮助，但是如果条件允许的话，你应该尽量避免只派一名成员参加培训课程。如果预算有限，只能培训一名成员的话，你就应该想办法让团队成员能够尽快共享这些知识。第二，为新加入项目的团队成员制订培训计划，这样能够帮助他们快速上手。最糟糕的情况莫过于让一名新人加入项目团队，但却没有系统化的办法让他快速进入状态。

管理一个ITIL项目和管理其他项目有所不同。如果你按照本文中提到的要点去做的话，在结束的时候，每个人都会得到自己想要的东西。

讲师简介
n 管理实战讲师，管理咨询顾问，项目管理专家
n 清华大学领导力中心、中兴通讯学院、影响力教育集团等著名机构培训讲师
n 25年信息技术及高科技、制造业、咨询及教育培训行业工作经历
n 20年民营企业、上市公司、国有企业中高层岗位管理工作经验
n 10年专业咨询、培训工作经验，长期专注于企业管理实践，以及管理者能力发展
n 丰富的企业管理、项目管理、信息技术、学习创新、市场营销等领域专业经验
风格特点
n 目标导向，关注价值——以提高个人、团队及组织的业务绩效和管理能力为目标
n 聚焦实践，突出实务——紧扣企业业务和管理现状，帮助解决重点、难点问题及困惑
n 以事明理，以例示范——精选与培训需求相匹配的关键知识、典型案例，深入演绎
n 强化行动，学以致用——运用互动学习理念方法，实现从行为到态度再到结果的持续改变
n 理性亲和，严谨活跃——以学员为中心，强调有效，避免“坐而论道”，拒绝“华而不实”
课程领域

一、管理者素质与能力提升

n 领导力修炼：包括面向中高层管理者、基层管理者的不同层次领导力提升及职业化素质训练课程
n 管理技能提升：包括MTP管理才能训练及各模块课程（管理者角色认知、自我管理、工作管理、员工及团队管理）
n 沟通技能：包括人际沟通、组织沟通、谈判技巧、人际影响与冲突管理等
n 思维创新：包括逻辑思考与表达能力、问题分析与解决能力、团队决策能力、学习创新能力训练等
n 其他相关课程：包括目标管理、绩效管理、计划管理、冲突管理、会议管理、非人力资源经理的人力资源管理等

二、项目管理相关领域

n 专业模块实战课程：包括项目分析、计划管理、项目监控与变更，以及项目质量管理、风险管理、成本控制、项目沟通管理、项目人力资源管理等
n 特定项目实战课程：IT项目（软件、系统集成等）、工程项目（通讯、基建等）、产品研发项目、服务外包项目、营销活动项目、生产制造项目、管理创新项目、教育学习项目、招商引资项目、投资项目、政府管理与公共服务项目等
n 其他相关专业课程：包括组织级项目化运营管理实践、项目管理软技能提升、企业招投标项目策划与操作实务、企业采购与供应商管理实务等

P3O培训介绍了如何衡量P3O对组织的价值，如何取得高层领导对P3O的支持，P3O在组织变革管理过程中的作用，P3O模型与方法，P3O生命周期模型及其最佳实现，P3O实施的技术、工具和成功标准，P3O人员角色与职责等所有战略项目管理办公室理论与实践框架。

1、3P Office 的含义与关系

项目（Project)，项目是根据特定的业务情况，为了完成或创造一个特定的产品或服务而做出的暂时性努力。
项目群(Programs)，为了完成和组织战略目标相关的结果和收益，协调、指导和监督一组相关项目及其活动的灵活机动的组织。
项目组合（Portfolio)，项目或项目群的集合，组合起来支持高效管理。项目组合中的项目或项目群之间不一定相互依赖或直接相关。
项目（Project）、项目群(Program)、项目组合(Portfolio)，分属三个级别，构成公司项目金字塔，保证项目交付符合企业整体战略。可以站在企业管理高层（如CEO,CFO，副总等）的角度，从上往下看（Top-Down），通过战略分解实现价值。也可以站在部门和总监的角度，从下向上梳理（Bottom-Up），通过归并项目组，保持与企业整体战略一致。

2、为什么要P3O

越来越多的组织正在探索和优化项目群管理和项目管理最佳实践，许多组织构建了这些实践，但是难于维持。在日益激烈的市场竞争环境下，需要做更快的决策，需要有更快的变革周期，还可以做些什么？
项目管理办公室PMO（Project Management Office）是国际项目管理界今年来的一个热门的词汇。一般认为PMO是在组织内部将实践、过程、运作形式和标准化的部门，这些标准化的程序应该能形成一致和可重复的结果，同时项目成功率是上升的。
但是一直以来，国际上没有一套公开的、成熟的、体系化的PMO运作参考标准。P3O的发布弥补了国际上的这一空白。这套新的核心指南，融合了OGC 已经发布的PRINCE2、MSP 和MOR，整合了原理、流程和技术，通过授权、挑战和支持结构的方式，极大地缩短了战略制订者与组织执行部门之间的距离，促进有效的项目组合、项目群和项目管理，进而实现高效的公司项目治理。
P3O指南旨在形成对项目进行统一集成的治理和上报机制，揭示变革发起活动组合的规律，为项目组合、项目群和项目提供决策支持和交付服务的一个完整的框架。简单来说，P3O模型提供了一整套促使组织变革的功能和服务。这些服务提供给项目、项目群和高级管理层，为这些团队中的项目群经理和项目经理提供支持。
P3O指南成功实现了业务变革时增强运营效率，通过集成项目群、项目和业务运营单位实现组织战略和绩效的要求。P3O指南构建了一套输出评价指标，确保收益可以得到管理、衡量、监督以及完善，进而实现优化投资和战略目标。

3、使用P3O的好处

企业引入P3O能够带来以下好处：

1）从变革项目中提升更多的价值,驱动更多的收益实现，增强对于项目产生的业务成果识别和实现，即使是在虚拟的工作环境汇总，对于期望成果也是一致的和清晰的。
2）选择正确的或最佳项目群和项目，并且排定优先级，以确保实现战略目标，驱动创新。
3）评估组织有能力交付已经选定的项目群和项目。包括有时候需要停掉一些与战略无关的项目和项目群。
4）按照目标、时间线、关卡来协调和驱动相互依赖的活动。
5）合理安排整个产品生命周期的活动。
6）为组织内部的项目提供统一标准的流程和文档，因此可以持续改进组织的绩效。
7）减少由于项目群和项目失败带来的浪费。
8）提高项目群和项目的流程的效率。

对于项目群管理和项目管理中可以带来的好处包括：

1）增加组织开展的项目的可视化。
2）统一投资和业务目标。
3）正确分配投资优先等级。
4）提高执行能力。
5）确保项目群和项目形式的正确变革得到执行。
6）确保变革高效率和高效益的完成。

4、P3O对中国企业的现实意义

P3O指南描述了一个高阶的组织模型和机制，构建组织内部所有关于变革的决策支持与交付的结构及机制，允许永久的和临时的办公室及其组合，而员工分配到项目群和项目中。实施P3O，并不意味着需要设立一个单一的办公室交付所有的P3O服务。合适的P3O需要根据公司的愿景、战略、现有的组织架构、业务发展的要求等，寻求在合理的成本上提供所有必要的支持功能和服务。
具体的形式既可能是集中式的一个常设的专门办公室，也可以是分布式的成网状的体系，由一系列办公室的结合而成（包括项目组合办公室、项目群办公室，项目办公室），这些办公室可以是常设的（支持业务目标，并且保持一致性），提供集中式和分散式的服务相结合。
然而P3O需要至少一个企业级的要素，以决定这些服务的最佳实施。此外需要注意的是，P3O模型并不直接管理个别的项目和项目群，具体的项目将分别由每个项目群和项目的管理团队完成。然后，这些团队中的项目群经理和项目经理由P3O模型提供支持。

5、P3O模型的生命周期

第一阶段，识别P3O根据P3O评定组织现有状况，呈现需要解决哪些问题。 定义引入P3O后的愿景，同时设立任务与目标，规划与之相关的商业案例。
第二阶段，定义P3O设计P3O模型在组织内如何操作，需要设计P3O团队，开发相关治理方案、蓝图以及开发与P3O有关的全面商业事例。 计划P3O交付的阶段或分类形式 开发和通过P3O过渡计划的阶段性实施。
第三阶段，发起P3O，通过组别或阶段的形式进行实施，并且交付实施或过渡计划以实现利润。
第四阶段，结束P3O实施，包括对项目群或项目实施的结束与回顾，进而正式结束P30，并对实施进行评估和经验总结。

6、P3O的发展趋势

项目组合管理的出现

1）帮助高级经理做决策
2）挑战与监督作用

经历P3O培训的员工对组织而言更可靠

1）成为个人的职业道路而非垫脚石
2）具有批判性的朋友角色
3）具有战略与赞助/SRO操作功能

标准模型、服务和语言

1）集中式服务促使产出和支持水平高—灵活性高的资源模型
2）P3O模型提供整体的治理和提升
3）虚拟办公室 致力于持续性标准

关于PRINCE2
　　实际上，PRINCE2（PRojectsINControlledEnvironments的缩写，意为“受控环境中的项目”）在英国就是事实上的标准。该标准最初为英国政府开发，目前在英国和全球的私营行业都得到了广泛应用。PRINCE2是公用的，为各领域的项目管理提供最佳实践指导。任何人都可以使用该方法，可以通过网上书店购买PRINCE2手册，也可以通过英国政府网站www.ogc.gov.uk/prince购买。PRINCE2具有严格的认证流程，包括对培训机构、培训师、从业者以及咨询师的认证。（认证单位是APMG公司，该公司的网站www.apmgroup.co.uk及中国网站www.apmg-china.com上列出了获批的培训机构、咨询师和从业者。）

　　PRINCE2是基于流程的结构方法论，强调了在理解和有效表述的情况下，8个特别的组成部分如何有效降低所有项目类型中的风险。虽然PRINCE2与PMBOK有着同样的基础，但PRINCE2将PMBOK诸多领域具体化并回答了“如何在我的项目中进行应用？”的问题。

　　PRINCE2的结构

　　PINCE2并不声称像PMBOK一样全面。正如所有项目方法论都必须做的那样，PRINCE2同样建立在PMBOK的原则基础上。PRINCE2对要素（“组成部分”）进行了精选并把注意力集中在这些要素上，认为组成部分对于项目的成功评估和完工至关重要。它构建了一个能将这些要素组合在一起从而降低整体项目风险的流程，并提供了对它们予以支持的技术。《PMBOK指南》对知识领域的整合是松散的、概括性的，而PRINCE2则提出了一种能将这些知识领域组织起来的有效途径。PRINCE2的本质是：“以这种方法使用这些要素，是降低项目风险并保证项目质量最有效的方法。”

　　PRINCE2的组成部分和流程跟PMBOK相容，但PRINCE2不包括PMBOK的所有知识领域和细节。PRINCE2关注关键领域，因此项目经理仍需要深入、充分地利用PMBOK和其他资源，以完成项目管理工作。PRINCE2的目的是组织和补充项目管理知识。它假定使用这些方法进行学习和工作的人们所具备的经验水平足以使他们能够填补PRINCE2所忽视的细节。在PRINCE2中，流程、组成部分和技术的规模和内容应当根据项目的规模和性质进行调整。

　　PRINCE2组成部分

　　PRINCE2由8个“组成部分”组成。它们是：商业论证、组织、计划、控制、风险管理、项目环境中的质量、配置管理和变更控制。大致上，它们跟PMBOK的以下知识领域相对应：

　　　这些组成部分不像知识领域那样有一个综合定义。例如，PRINCE2在其计划讨论中，涵盖了PMBOK的时间和成本管理，但仅限于时间和成本的发展信息在相关计划级别上是必要的。以下概述了PRINCE2组成部分：

商业论证：可行商业论证的存在是PRINCE2项目的主要控制条件。商业论证在项目开始前和项目整个流程中的每个重大决策点都要由项目委员会进行核实。当商业论证不管任何原因丧失可行性时，项目应当被终止。
组织：由于项目经理经常不得不指导一些向另一个管理结构汇报工作的员工，因此就需要组织的高层管理人员保证这些不同的资源都能投入该项目。此外，可行性决策要由对项目进行投资并负责通过项目经理交付项目的管理层做出。在PRINCE2方法中，这个监督组织是项目委员会。
计划：计划是任何项目所必需的管理信息系统的主干，需要得到项目组织中适当级别的批准和委托。“计划”要素强调了规划这一核心概念；主要步骤在流程模型“规划”部分得到了突出显示。
控制：控制跟决策相关：它的目的是保证项目（a）能够产出所要求的产品——这些产品达到设定的验收标准；（b）按照进度表进行并符合资源和成本计划；（c）保持商业论证的可行性。
风险管理：由于项目工作的不可预期性要高于非项目工作，风险管理就成了项目管理的一个重要部分。为了包容项目中的风险，必须以一种规范的方式通过风险分析和风险管理（如PMBOK）对这些风险进行管理。
项目环境中的质量：质量管理确保客户期望的质量可以通过一种质量体系（跟PMBOK相似）实现。项目交付成果的质量要求以产品描述为基础，该产品描述由项目经理准备并由项目委员会批准。
配置管理：配置管理使得项目管理团队可以对项目资产（项目开发出的产品）进行控制，这对于任何质量体系都至关重要。它提供了一种跟踪和控制项目交付成果的机制，也提供了一个跟踪项目问题的系统。
变更控制：控制范围变更意味着评估潜在变更的影响、重要性、成本、对商业论证的影响以及由管理层做出的是否将它们包含在内的决定。
　　对于PMBOK用户来说，上述各要素都不陌生——PRINCE2只是强调了这些往往不受项目经理重视但对项目取得成功至关重要的要素。PRINCE2方法论将这些要素组织成一个流程模型，认识到流程和关系对于成功使用要素（和知识领域）中确定的概念是至关重要的。

　　PRINCE2流程概述

　　PRINCE2阶段

　　为了在正确的项目水平上提供恰当的决策关口，PRINCE2项目分解为多个Stage（阶段），跟PMBOK流程模型中的Phase（阶段）类似。PRINCE2提倡在任何工作开展之前，把项目作为一个整体来进行决策。PRINCE2将整体项目划分出开始、规划和收尾（“项目准备”、“项目启动”、“项目收尾”）并将它们与每个阶段的开始和结束活动（“阶段边界管理”）区分开来。

　　通过“阶段控制”和“产品交付管理”，开发工作的实际执行和控制（从可行性或要求开始）在每个阶段显露出来。通过“项目指导”（来自项目委员会的），项目监督贯穿整个项目。“规划”是普遍存在的流程，在项目的任何级别都按需采纳。

　　　“项目准备”能够在受控条件下开始项目。它在项目周期中只出现一次，为项目管理、监督以及可行性评估提供基础。这个流程将产生项目委员会并确保资源要求被了解，并用于第一个阶段——“项目启动”。

　　“项目指导”贯穿整个项目，确定了项目委员会在项目监督方面应履行的责任。正如它在流程模型图中的位置一样，它位于很多其他流程的上方并与之进行互动。它为项目授权、每个阶段完成后批准项目继续进行和批准项目完成（都以商业论证为基础）提供了一种机制。“项目指导”是一个为项目经理提供输入、接收来自项目经理的信息和协助请求、并进行决策的结构。这是项目委员会发挥作用的唯一流程（除“项目准备”流程外，项目委员会在该流程中成立。）所有其他流程都在项目经理和小组经理的指导下进行。

　　“项目启动”在项目周期中只出现一次。它显示了如何管理整体项目，并将其放到一个叫做“项目启动文件”(PID)“合同”中。PID的目的是为项目的关键要素提供一份理解共识（类似于PMBOK规划流程产生的结果）。“项目启动”也要求项目委员会对项目的第一开发阶段做出资源承诺。

　　“规划”是PRINCE2其他几个流程的通用流程。通过确定项目所要求的交付成果、为制造这些交付成果所必需的活动和资源以及管理和质量要求，制定计划——所有这些都要与PID中所定义的控制要求相一致。对通用模块的使用，凸显了所有规划一致、连贯的理念。

　　“阶段控制”为项目经理对项目的日常管理提供了指导。它包括：工作授权和工作接收；问题和变更管理；状态收集、分析和报告；可行性因素；纠正措施；以及向项目委员会的升级汇报和其他资源问题。“控制阶段”是不断重复的，在项目的每个发展阶段都会重复出现。

　　“产品交付管理”是PRINCE2工作授权系统的一部分。它是技术工作人员（小组、个人和承包商）就需要执行的工作达成共识、报告工作进展、完工和交还的机制。每当进行工作包授权，它就会出现。

　　“阶段边界管理”对一个工作阶段结束到下一个阶段开始之间的工作移交进行管理。它包括确保项目工作已按规定完成，向项目委员会提供信息供其评估项目的持续可行性（在“项目指导”流程中完成），为下一个阶段的工作制定计划并获得授权，记录经验教训。

　　“项目收尾”是一种将项目移交回组织的机制。它终止项目——无论是因工作完成还是提前终止。无论怎样，“收尾”都会为组织提供项目教训和项目经验记录。对于完成的工作来说，它的目标是确保（a）工作已经完成且令客户和管理层满意；（b）所有预期的产品都被移交给客户并通过验收；和（c）对项目产品支持和运行的安排都已到位。

　　PRINCE2没有“核心”和“促进”流程；所有要素和流程都被整合到一个单独流程中，这一流程澄清了它们之间的关系。