项目管理之时间管理

项目时间管理是管理项目按时完成的过程中时间安排。在软件工程中,项目的时间安排是按照项目的生命周期进行安排的。然而,在项目时间管理过程中,这些活动是怎么么安排的呢?欲知何事,请看下文:

定义活动

定义活动是识别为完成项目可交付成果而需采取的具体行动的过程。活动是开展估算、编制进度计划以及执行和监控项目工作的基础。从工作粒度上讲,活动是工作分解结构底层可交付成果的子类,即工作包的子类。

排列活动顺序

排列活动顺序是识别和记录项目活动间逻辑关系的过程。活动按逻辑关系排序。为了让项目进度变的现实和可行,需要在活动间加入时间提前量或滞后量。

估算活动资源

估算活动资源是估算每项活动所需材料、人员、设备或用品的种类和数量的过程。估算活动资源与估算活动成本紧密相连。

估算活动持续时间

估算活动持续时间是根据资源估算的结果,估算完成单项活动所需工作时段数的过程。

制定进度计划

控制进度计划是分析活动顺序、持续时间、资源需求和进度约束,编制项目进度计划的过程。编制可行的项目计划,往往是一个反复进行的过程。这一过程的目的是确定项目活动的计划开始日期和结束日期,并确定相应的里程碑。当然,如果计划发生了变更,也需要严格的变更复审过程,来修正进度计划。

控制进度

控制进度是监督项目状态以更新项目进展、管理进度基准变更的过程。控制进度需要判断项目进度的当前状态;对引起进度变更的因素施加影响;确定项目进度是否已经发生变更;在变更实际发生时对其进行管理。

尽管本篇文章的主旨是在讲项目时间管理,但从始至终本文的描述从未离开过项目范围,所有的时间管理都是基于项目的某个范围内而展开的。在学习本篇文档的同时,应联想到上篇项目范围的管理。学习的过程是一个织网的过程,对于项目管理知识的学习要能够从点到线,由线及面,最终达到这些知识为我们所用。

项目管理之项目整合管理

PMP项目整合管理包括为识别、定义、组合、统一与协调项目管理过程组的各过程及项目管理活动而进行的各种过程和活动。项目整合管理需要选择资源分配方案、平衡相互竞争的目标和方案,以及管理项目管理知识领域之间的依赖关系。虽然各项目管理过程通常以剑仙分明、相互独立的形式出现,但在实践中它们会相互交叠、相互作用。

项目整合管理过程,包括六个过程,具体如下:

一、制定项目章程

制定项目章程是制定一份正式批准项目或阶段的文件,并记录能反映干系人需要和期望的初步要求的过程。它在项目执行组织与发起组织之间建立起合作伙伴关系。项目章程的批准,标识着项目的正式启动。

制定项目章程的输入包括项目工作说明书、商业论证、合同、事业环境因素和组织过程资产,而评估制定项目章程的输入通常是专家判断,制定项目章程的输出毫无疑问就是项目章程。根据公司的性质不同,项目所属行业不同,使用的项目章程模板不同。但项目章程的内容大体相同,通常包括业务需要、对客户需求的理解,以及需要交付的新产品、服务或成果。

二、制定项目管理计划

制定项目管理计划是对定义、编制、整合和协调所有子计划所必需的行动进行记录的过程。项目管理计划确定项目的执行、监控和收尾方式,其内容会因项目的复杂性和所在应用领域而异。编制项目管理计划,需要整合一系列相关过程,而且要持续到项目结尾。本过程的输出就是一份项目管理计划。

从项目整合管理的角度来讲,该过程的输入仅需一份项目章程即可。但是从整个项目的角度来说,该过程输入还包含很多其它规划过程的输出,由于篇幅和纲要原因,本节在此略过。不过事业环境因素和组织过程资产作为公共性的输入内容,也是本过程输入的一部分。

本过程的输出项目管理计划可以是概括性的或详细的,也可以包括一个或多个子管理计划。如范围管理计划,需求管理计划,进度管理计划等。每个子计划的详细程度取决于具体项目的要求。项目管理计划一旦确定下来,成为基准,就只有在提出变更请求并经实施整体变更控制过程批准后,才能变更。

三、指导与与管理项目执行

指导与管理项目执行是为实现项目目标而执行项目管理计划中所确定的工作的过程。包括开展活动来实现项目要求;创造项目的可交付成果;提出变更请求,并根据项目范围、计划和环境来实施批准的变更等。

在项目执行过程中,除了实施相关工程来完成项目管理计划中的工作,产出相应的可交付成果外,还需要收集工作绩效信息,并提交给绩效报告过程,作为监控过程组的输入。

本过程的输入包括项目管理计划、批准的变更请求、事业环境因素和组织过程资产。本过程依然使用专家判断的方式评估“指导与管理项目执行”的输入,但是采用项目管理信息系统管理项目执行。本过程的输出有可交付成果、工作绩效信息、变更请求、项目管理计划(更新)和项目文件(更新)。

四、监控项目工作

监控项目工作是跟踪、审查和调整项目进展,以实现项目管理计划中确定的绩效目标的过程。监督是贯穿于整个项目周期的项目管理活动之一,它包括收集、测量和发布绩效信息,分析测量结果和预测趋势,以便推动过程改进。

本过程的输入包括项目管理计划、绩效报告、事业环境因素和组织过程资产。同样,本过程采用专家判断的方式,来解读监控过程中提供的信息。本过程的输出是变更请求、项目管理计划(更新)和项目文件(更新)。

五、实施整体变更控制

实施整体变更控制是审查所有变更请求,批准变更,并管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更的过程。实施整体变更控制过程包括以下变更管理活动:

对规避整体变更控制的因素施加影响,确保只有经批准的变更才能付诸执行;

迅速地审查、分析和批准变更请求;

管理已批准的变更;

仅允许经批准的变更纳入项目管理计划和项目文件中,以此维护基准的严肃性;

审查已推荐的全部纠正措施和预防措施,并加以批准或否决;

协调整个项目中的各种变更;

完整地记录变更请求的影响。

本过程的输入包括项目管理计划、工作绩效信息、变更请求、事业环境因素和组织过程资产。实施整体变更控制的工具与技术包括专家判断和变更控制会。本过程的输出为变更请求状态(更新)、项目管理计划(更新)和项目文件(更新)。

六、结束项目或阶段

结束项目或阶段时完结所有项目管理过程组的所有活动以正式结束项目或阶段的过程。在结束项目时,项目经理需要审查以前各阶段的收尾信息,确保所有项目工作都已完成,确保项目目标已经实现。

结束项目或阶段的输入包括项目管理计划、验收的可交付成果和组织过程资产;结束项目或阶段的工具是专家判断;最后的输出包括最终产品、服务或成果移交和组织过程资产(更新)。

项目管理之项目成本管理

谈到PMP项目成本,很多职工都是误把人工成本当做了项目的整个成本,其实人工成本仅仅只是项目成本支出的一部分,像材料、设备、服务等支出,都是项目成本的一部分。项目成本管理就是要识别这些成本,并对这些成本进行估算,制定预算,然后控制成本,最终确保项目在批准的预算内完工。下面一起看看项目成本管理的过程:

估算成本

估算成本是对完成项目活动所需资金进行近似估算的过程。当一个项目确定下来时,我们能够根据已知的信息对项目进行成本估算。并不是项目确定袭来了,估算随便走走样子就行了。要知道,估算与风险同行。一个项目,可能有好几种估算方案,并伴随着不同种类的风险,我们要做的就是选择最好的方案,优化项目成本。
影响项目估算的因素有很多,比如人工、材料、设备、服务、设施以及一些特殊的成本种类,如通货膨胀或应急成本等等。当我们进行项目估算时,就应该把这些因素作为基准考虑进去,从而确定项目成本的边界。此外,项目的开发周期也会对项目成本产生重要的影响,所以在估算成本时应把项目进度计划和人力资源计划考虑进去。综上所述,估算成本的输入文档应包括范围基准、项目进度计划、人力资源计划和风险登记册。
估算成本的方法有很多,常用的有专家判断、类比估算、参数估算、自下而上估算、三点估算、储备分析、质量成本、项目管理估算软件和卖方投标分析等。你可以根据自己项目的成本和现有资源,选择合适的方案进行成本估算。

估算成本是对完成项目活动所需资金进行近似估算的过程。当一个项目确定下来时,我们能够根据已知的信息对项目进行成本估算。并不是项目确定袭来了,估算随便走走样子就行了。要知道,估算与风险同行。一个项目,可能有好几种估算方案,并伴随着不同种类的风险,我们要做的就是选择最好的方案,优化项目成本。
影响项目估算的因素有很多,比如人工、材料、设备、服务、设施以及一些特殊的成本种类,如通货膨胀或应急成本等等。当我们进行项目估算时,就应该把这些因素作为基准考虑进去,从而确定项目成本的边界。此外,项目的开发周期也会对项目成本产生重要的影响,所以在估算成本时应把项目进度计划和人力资源计划考虑进去。综上所述,估算成本的输入文档应包括范围基准、项目进度计划、人力资源计划和风险登记册。
估算成本的方法有很多,常用的有专家判断、类比估算、参数估算、自下而上估算、三点估算、储备分析、质量成本、项目管理估算软件和卖方投标分析等。你可以根据自己项目的成本和现有资源,选择合适的方案进行成本估算。

估算成本输出的文档就是活动成本估算、估算依据和项目文件(更新)。

制定预算

制定预算是汇总所有单个活动或工作包的估算成本,建立一个经批准的成本基准的过程。成本基准包括所有经批准的预算,但不包括管理储备。
在上面,我们通过估算成本对项目的总成本有了一个大体的概念,下面我们就要根据估算成本,制定预算计划,确保项目在合适的地方花费只支出必要的成本。制定预算的依据除了估算成本过程产生的文档之外,还包括一些项目因素。这些依据有活动成本估算、估算依据、范围基准、项目进度计划、资源日历、合同和组织过程资产。
通常,制定预算的方法有成本汇总、储备分析、专家判断、历史关系和资金限制平衡。其中,成本汇总的方法比较准确,但是这种方法耗时也最长。专家判断是常用的一种方法,也是比较简单和快速的方法,但是准确度较低。

制定预算的输出有成本绩效基准、项目资金需求和项目文件(更新)。其中比较难理解的是成本绩效基准,这里简单解释一下,它是经过批准且按时间段分配资金的完工预算,用于测量、监督和控制项目的总体成本绩效。

控制成本

为了让实际贴近计划,我们要监督项目状态,并更新项目预算,管理成本基准变更。在项目实际运行过程中,支出难免与预算有出入,我们应重点分析项目资金支出与相应完成的实体工作之间的关系,并可根据实际情况调整预算方案与成本支出。切记不可为了不超出资金限制,而将工作的价值抛于脑后。
影响控制成本的因素有项目管理计划、项目资金需求、工作绩效信息和组织过程资产。其中,项目管理计划又包括成本绩效基准和成本管理计划。
控制成本的方法有挣值管理、预测、完工尚需绩效指数、绩效审查和偏差分析。为达到真正的控制成本,我们可能采取其中的一种或几种方案,同时并使用合适的项目管理软件,进行成本控制。
控制成本的输出有工作绩效测量结果、成本预测、组织过程资产(更新)、变更请求、项目管理计划(更新)和项目文件(更新)。

尽管项目成本是很多职工都接触不到的内容,但我相信读了本文之后,您一定会对项目成本有很多的认识,您也一定开始计算自己项目的成本,并考虑自己在整个项目成本中的比重。

项目管理技术:关键路线法

尽管关键路线法与关键路线不同,但在了解关键路线法之前了解关键路线的含义还是非常必要的,关键路线的概念在上面已提及。对于一个项目而言,只有项目网络图中的最长的或耗时最多的活动路线完成之后,项目才能结束,这条最长的活动路线就叫做关键路线(critical path)。

根据关键路线的含义,关键路线具有以下特点:

a、关键路线上的活动的持续时间决定项目的工期,关键路线上所有活动的持续时间加起来就是项目的工期。

b、关键路线上的任何一个活动都是关键活动,其中任何一个活动的延迟都会导致整个项目完成时间的延迟。

c、关键路线是从始点到终点的项目路线中耗时最长的路线,因此要想缩短项目的工期,必须在关键路线上想办法,反之,若关键路线耗时延长,则整个项目的完工期就会延长。

d、关键路线的耗时是可以完成项目的最短的时间量。

e、关键路线上的活动是总时差最小的活动。

关键路线法(critical path method,cpm)是一种通过分析哪个活动序列(哪条路线)进度安排的灵活性(总时差)最少来预测项目工期的网络分析技术。具体而言,该方法依赖于项目网络图和活动持续时间估计,通过正推法计算活动的最早时间,通过逆推法计算活动的最迟时间,在此基础上确定关键路线,并对关键路线进行调整和优化,从而使项目工期最短,使项目进度计划最优。

关键路线法的关键是确定项目网络图的关键路线,这一工作需要依赖于活动清单、项目网络图及活动持续时间估计等,如果这些文档已具备,借助于项目管理软件,关键路线的计算可以自动完成,如果采用手工计算,可以遵循以下步骤:

(1)把所有的项目活动及活动的持续时间估计反映到一张工作表中,如表5-3所示。

(2)计算每项活动的最早开始时间和最早结束时间,计算公式为ef=es 活动持续时间估计。

(3)计算每项活动的最迟结束时间和最迟开始时间,计算公式为ls=lf-活动持续时间估计。

(4)计算每项活动的总时差,计算公式为ts=ls-es=lf-ef.

(5)找出总时差最小的活动,这些活动就构成关键路线。

项目实施–如何进行项目数据管理

1. 数据管理的组织机构的建立

为了更好的进行软件系统的数据管理,应该从组织机构角度来做考虑,建立单独的组织机构来管理数据相关工作,或者在实施小组里面专人总负责。

软件开发商和客户核心的业务骨干一起制定数据规范,客户提供符合规范的业务数据,只有符合规范的数据才能进入系统。

2. 数据管理的原则

强调客户和软件开发商的2方项目组成员做到“不能有‘我以为’的思想”,一旦有如此思想,很容易陷入闭门造车,项目需求很容易走样,因为客户à所有的客户,也是在‘我以为 ’。项目组要想做到控制住需求,一定要抛开自己的设想。所以任何一个项目组成员,第一句话就告诉他,不要有“我以为”的想法。把‘我以为’变成‘客户认为 ’(最好是客户和软件提供商一致认为),这才是最重要的。

呵呵,这又回到了项目管理上。我在这里实际上只是想从数据管理这个更具体的角度来阐述问题。

3. 数据入口的单一性

同一数据必须一次、一处进入系统,保证其准确性,及时性和完整性和入口的单一性。管理控制一体化是系统的目的,如果一个数据在多个地方存储,很容易造成数据的不一致。

4. 数据副本管理/数据版本管理

虽然上面提到了数据存储的单一性,但是有些时候也需要存储副本数据。存储这些副本数据的目的就是为了在使用数据副本的地方不受到数据源的变化的影响。

例如:数据1在业务A进入系统,业务B使用到了数据1,但是为了避免在业务B使用了数据1后,业务A又把数据1的修改影响到业务B,那就需要业务B在使用数据1时候保存副本。

比如:城市拆迁资源计划系统的拆迁合同在使用房源业务录入的房源房屋面积信息时,就使用了副本机制,在合同使用房屋面积时候,把面积信息存储下来,当合同构筑完成时候,如果相应的房屋面积信息发生了变动,就用另外的业务来处理这个数据变动的相应处理(比如,使用房源的差价款合同来处理)。

有朋友建议用配置管理系统,把数据版本机制引入了业务数据里面。做过J2EE的项目,都知道很多地方可以通过配置来进行管理。其实这个思想延伸到数据库模型的设计时候,就体现出来了业务数据的配置管理的思想的使用。

我们其实也有是用这个思想,但是主要体现在 在基于数据表级别上用数据级别+历史编号 来识别有效的数据。1个很简单的例子:一个员工的姓名原来 是aa, 后来改委bb,可以通过历史编号 找到原来 的信息是bb通过数据级别识别现在的有效数据是aa,我们把数据版本控制更多的是采用‘数据级别’加‘历史编号’另外还加上了一个‘生效日期’, ‘截止日期’这2个时间戳另外,实际软件系统的历史业务数据进入系统就比较烦,可能需要使用版本管理机制来处理才行得通。

5.建立数据等级制度

软件项目实施中业务规则经常会陷入一个两难的境地,如果业务规则加强,很多数据数据达不到规范化的要求,无法入机;如果放宽控制,很多垃圾数据就进入了,大家都明白一个道理,对于软件系统,垃圾数据进去,肯定是垃圾数据出来,统计查询结果肯定是这样的。

供应链式项目管理

最近我们重新规划和设计敏捷项目总体流程,对需求伊始直至项目上线的目标、指标、时间节点和责任人都做了定义。但当我们制定更详细的计划时,发现一个严重的问题:这是一个“梦幻日程计划”。在项目生命周期管理的探索与实践上,我们经历过瀑布式、迭代式、增量式以及混合的Scrum敏捷式,如果只针对项目管理而言,我相信在一个Sprint周期内,做到“一切尽在掌握”是可行的,但放眼至一个季度甚至半年的最终目标上,梦幻计划的完美主义的思想又成为了另一个极端。
为了让计划更加务实,我们需要采用尽可能短的时间盒管理项目,2周是一个理想并充满挑战的周期,但我们相信只要控制好Sprin就t可以实现它。
项目自始至终周期过长,会造成心理放松,对于项目危机感缺失,以至于造成前期浪费时间,后期加班赶时间的窘相。所以我们需要通过不断地迭代,在一次次循环中完成可交付的增量,基于事实的决策远比前端预测型决策更为有效。——Reinhardt
从远期看,我们的产品上线目标和最终运营目标都充满挑战,并且时间只剩半年。为了让不可能的任务更有说服力,我尝试着制定整整6个月的计划,但计划刚刚开始我就结束了这个愚蠢的想法 ——未来的Idea充满了未知。虽然scrum敏捷能带给我们更强的控制力,但从产品创建的生命周期看,2周时间盒显然给需求的产出带来了极大的困扰:如果需求的定义仅限2周,只有鬼知道这两周的量能否满足下一个项目Sprint的胃口,这还没有考虑不同功能和需求的大小。一个用户体验改 进与一个成长体系的需求量,放在两个同样长度的时间盒显然是不公平的,更何况产品经理还需要对页面设计、制作进行协调以及参与Spring周期结束时的部署验收。
在一个复杂又充满挑战的项目中,为了避免这个问题,同时又发挥Scrum敏捷式项目管理的优点,可以采取“供应链管式项目管理”方法。
在传统制造业企业中,为了保证生产的稳定,制造商会有一定的原材料库存。但随着供应链管理思想的深入发展,越来越多的制造商整合供应链资源,与供应商共同管理库存,以确保在生产最经济的情况下满足市场的变化,即“柔性供应链”。
在互联网项目管理中,可以简单的抽象需求、设计、页面制作为供应商,总设、开发、测试为制造商,库存即“待开发需求池”。与传统制造业不同的是, 互联网项目团队可以简化为2个供应链中的节点,供应商为制造商提供生产原材料,制造商将其加工测试后交付给市场。
相比Scrum敏捷式项目管理,供应链式项目管理强调了“库存”的价值,产品需要在下一个时间盒开始前保持“待开发需求池”的水量;开发需要确保能够及时消耗掉库存中的Backlog。 这使得团队成员的注意力更容易集中在最重要的部分(设计或者开发),而不是无效率的沟通。换句话说,传统的Scrum项目管理的流程更像是一条大河,上游需要确保充足稳定的水量以确保下游的承受能力;下游需要保持足够的消化能力以避免洪水泛滥或者干涸。供应链式的项目管理就是在河道上建起了一座大坝,只要保证水库中的水在安全范围以内,无论洪峰还是大旱(需求暴增或需求锐减),下游生产都可以确保 安全与效率。管理的焦点可以集中在“待开发需求池”的安全范围以及优先级。
供应链式项目管理是更宏观的管理,它阐述了产品管理与项目管理的上下游关系。纯粹的Scrum可能更适合老外那种程序员也是产品经理的创业作风,我看过几乎所有被奉为圣经的项目管理书籍都将定义需求作为一个项目的起始,这表面看起来无比正确,却如同鸡肋般既没有说清楚如何定义需求,又给国内的项目经理和程序员造成了困扰。
产品(供应商):
产品从“需求池”到“待开发需求池Backlog”,需要经历线框图、需求文档、页面设计、页面制作4个环节,产品设计的迭代由产品经理全权负责,在需求池挑选高优先级的目标,设计并交付最终完整需求至待开发需求池中,需求需要以“情景故事”为单位打包,并区分优先级;需求包的优先级需要满足正态分布曲线,如水库在每个Spring开始前,安全范围为5-15个情景故事,当有10个故事时,2个优先级为1,6个优先级为2,2个优先级为3。
技术(制造商):
技术在下一个时间盒迭代开始前一周,由项目经理根据团队承受能力与产品共同确认Sprint Backlog,并立即进行需求和用例评审。一旦范围确定,即可立即展开项目(在需求线框图出来后,测试与架构师就可以介入开展前期工作了),并用燃尽图等工具进行监控。后面只需要保持好节奏,相信掌控项目的感觉会让你身心舒畅。
我并不清楚供应链式项目管理思想是否有人进行过类似尝试,它的本质是对敏捷项目时间盒内的需求与开发进行解耦,需要需求提前至少一个时间盒完成并冗余在待开发需求池内,把为了增强项目控制力而压缩的2周Sprint还给项目程序员和测试工程师。它的困难在于,需求为了保证待开发需求池的安全范围而必须承担足够的压力,还好我相信这种压力是我们可以承受的。

评估项目集/项目管理过程的成熟度

就在几年前,“成熟度”的概念还很少用来描述一个组织在有效地执行某些任务的状态。今天,我们发现这个成熟度的概念被越来越多地用于制定提高组织服务的合理方法。

现有的能力成熟度模型起源于软件行业。软件开发工作通常比许多其他类型的项目要包含更多的变量、未知数和无形因素。由于这种复杂性,所以获得可预测的结果确实变得很有挑战性。正因如此,才有大量政府资助的研究,探究如何衡量和发展一个组织在软件开发中的有效性,这才产生了软件工程研究所(Software Engineering Institute,SEI)的能力成熟度模型。

在任何组织中,应用项目管理概念与软件开发中的复杂性和无形资产有许多相似之处。项目管理的发展通常落后于公司内其他能力的发展。直到对项目管理的需求变得至关重要时,组织才会注重改进其组织内的项目管理技能。缺乏远见常常会造成这样一个情形,即没有项目管理系统和基础设施来为组织的战略计划需求提供支持。最后,还应当主动审查改进项目和项目管理能力所必需的基础设施。简而言之,项目管理的需求变得如此之大,组织必须对不断增长的业务压力作出反应。

任何被选中用来衡量项目管理成熟度的模型,都必须指出前进发展的逻辑路径。知道你的组织成熟度只有“2级”并不重要,重要的是需要实施什么具体行动来推动组织前进。改进项目管理是一系列较小的步骤,并非巨大的飞跃,而许多组织的成熟度永远也不需要达到5级。在到达可重复过程级别的位置后,许多组织都将获得显著收益。事实上,一个好的项目管理成熟度衡量模型能为组织创建一个推动项目管理不断前进的战略计划。

项目管理办公室的职责与功能

项目管理办公室(PMO)出现于20世纪90年代初期。当时PMO仅提供了很少的服务和支持工作,而更多被企业用来“管制”项目经理,而不是为他们提供项目管理的方向和指导。在90年代后期,对于企业领导来说,将项目放到整个企业的运作中统一管理的需要变得越来越明显,PMO随之大量地出现。不论是对于项目经理还是企业主管人员来说,PMO都被证明是理想的选择。因为公司需要建立一个可以执行商业策略的理想环境,PMO实现了这一点,它对每一个项目根据商业策略进行评估和排序,然后对他们进行恰当的资源分配。

具体来说建立项目管理办公室的是为了满足两方面的需要:

 一、满足商业竞争的需要

早期建立PMO的一个重要原因是失败的项目给企业所带来的痛苦感受。而现代商业社会竞争的残酷性,使得任何企业都有可能因为个别项目的失败而陷入困境。项目的成败在当今社会已经和企业的成败密不可分了,由此产生了对PMO的迫切需求。

一个成功的中大型企业必然有许多的项目在进行,是否有优秀的项目管理技术人才,成为是否能够在有限的时间及成本条件下,完成客户需求的关键。但是,再优秀的人才都不可避免的有各种局限,况且一个企业所能拥有的优秀人才是有限的。大量项目的实施过程中,必然要求企业有一个对项目工作提供强大支持的机构,来协助项目经理和项目团队及时、有效地克服各种困难,高质量、高绩效的完成项目。为了让项目管理技术和经验能够成为企业的组织财富,最终能改善项目团队的整体生产力和提高企业的获利能力,在企业内部建立PMO就有其必然性和紧迫性。

一旦项目开工,PMO就持续地对每一个项目的变化进行监控,提供各种项目经理和项目团队的所需要的支持与服务。这里我要强调的一个关键就是随着企业战略的变化,任何一个项目的状况也要跟着发生变化。PMO通过对项目进行修正,加速,终止或是优先权的排序,实现了项目向适应企业战略变化的方向调整,以满足商业竞争的需要。

 二、满足合理配置资源的需要

要想获得PMO所带来的好处,企业的大小首先要达到一定的级别。如果一个企业每年只有一个项目,那就不要在PMO上浪费有限的资源了。对于一个有众多项目的企业来说,你会发现项目经理相当多,每一个都具有不同的技能和经验。这些项目经理经常不会意识到其他项目的成功,甚至不知道其他人在做什么。如果出现类似的情况的话,就应该建立PMO了。任何一个PMO的运转都需要资金和人员的投入。但是投入PMO的时间和资金将会是物有所值的,它让项目经理能够在企业中更好、更快、更节省地执行项目工作。因为PMO是在整个企业运作的高度而不是单个项目的高度将企业有限的资源进行合理分配,同时为项目经理和项目团队提供各种支持,确保符合企业战略的项目成功实施。

集中化的PMO就可以保证所有的项目经理具有核心的项目管理技能,使用共同的方法,处理过程和模板,并得到企业最高层的支持。PMO组织的简单性使得每个人都可以建立这样的办公室。但是PMO人员配置是非常重要而复杂的工作。为了具有在各方面提供支持和配置资源的能力,PMO应该包括企业的高层主管、项目经理、各类专项专家、项目协调人员等角色。

PMO通常具有如下的责任与功能:

1. 为项目经理和项目团队提供行政支援,如项目各种报表的产生;

2. 最大限度的集中项目管理专家,提供项目管理的咨询与顾问服务;

3. 将企业的项目管理实践和专家知识整理成适合于本企业的一套方法论,提供在企业内传播和重用;

4. 在企业内提供项目管理相关技能的培训;

5. PMO可以配置部分项目经理,有需要时,可以直接参与具体项目,对重点项目给与重点支持。

虽然,一个成熟的项目管理办公室的作用与功能非常强大。但是,路要一步一步走,在没有PMO运作经验的情况下,我个人认为在PMO成立的初期,其工作应该集中在如下几个方面:

1. 为项目经理制定发展计划,并推动其实施

人力资源部、部门主管和PMO共同主导项目经理的发展计划。同时,由部门主管、项目经理及未来的项目经理,组成企业内部的项目管理协作组织(或称为项目管理俱乐部)。项目管理协作组织通过形式多样的讨论与交流,总结分享各自的经验。PMO要根据项目管理协作组织的需求和企业内项目经理发展计划,开设各种培训班提供专业化的培训和面对面的交流。

2. 收集和整理项目经验,提供给其它项目分享

通过参与各个项目的会议,总结和分享不同领域的相关知识、技术及经验,形成可再利用的支持能力,让知识管理在日常运作中能被落实。

3. 项目投入的工期和成本的分析

建立和推行一套工具,记录每个项目所花费的人力、时间,经过整理产生可供项目经理和主管参考的项目管理报表。

4. 制定项目建议书、项目计划、项目总结报告等模版,提供给项目经理和项目团队参考使用。

由于项目经理和项目团队在进行具体项目时,往往会面对以前没有遇到的问题和情况。但是,这些问题和情况在企业内部可能已经遇到或实施过,因此PMO能通过对其它项目的总结,提供出标准的解决方案,并以文档模版的形式提供。这样,可以使项目团队的工作总是在企业过去积累的基础上向前发展,而不是简单的低水平重复。

总之,在一个以项目为基础开展工作的企业内部,PMO的建立是势在必行的。但是,如何成功设立PMO,更重要的是如何成功运作PMO是一项非常复杂和专业的工作,需要企业和其员工长期努力。

PMC(项目管理承包)模式

一、 PMC 模式与总承包模式的比较

PMC模式最早起源于美国,这种模式随着时代的进步也在不断的演变着,现在,在国内,这种模式也很流行。PMC模式即项目管理承包模式,简单的说就是通过一些诸如招标的方式,在经过了规定程序后,择优选择专业的项目管理的单位以及建设单位具体的建设计划,从而将项目的投资、工期以及质量严格把握,在项目竣工后交给使用单位。在我国,通用的项目管理建设模式大致可以归分为三种。

第一种是项目管理的服务模式,也就是工程的管理单位在接受委托单位的委托后,运用科学管理的思想、手段以及方法,为业主答疑解惑,此类模式大致有DDB模式、CM模式以及PM模式。

第二种是项目承包的服务模式,大体就是承包工程的项目管理的单位依照合同上的规定,把工程承包,但是项目的管理单位统称只是负责该项目的过程的管理,却把工程的施工以及设计等部分承包给别的单位,这种模式大致也是三种,即BOT模式、CM模式以及PMC模式。

第三种是带减震与承包制,这种方式在国际上是通用的工程建设的实施组织方式,在我们国家也是较为流行的,在这其中,又有DB模式、EPC模式两种模式。

显而易见,不同的项目管理的模式各有其利与弊。在这其中,代建制指委托单位在以委托专业的项目管理的公司为代建的单位后将建设单位和使用单位的利益关系完全隔断的管理项目的方法。总承包制就是总承包的单位从委托单位那儿承包与工程相关的探测、工程设计以及施工等各个项目的承包模式。这两种现代的项目管理的模式在广泛的运用中还存在着差异。

首先是单位性质的不同。

代建单位在承包工程后拥有法人的地位,即既要承担相关责任也有相关的权利,为工程提供相应的顾问或者关于质询方面的一些服务。工程的总承包企业的性质也就是承包商,对工程的全部或者某些部分进行承包,但是它不具有法人的地位,相应的也就无法拥有相关的权利以及义务。

其次是他们工作性质的不同。

PMC模式的工作性质是企业项目的管理,全程代管建设的费用;而工程承包是总承包的工作性质,只是整体承包工程的造价。再者是单位的要求不尽相同。PMC模式对管理方的资金要求不高,更加偏重于其对管理与技术的要求。相反的,总承包的要求是实施方有雄厚的财力支持。最后就是他们承担的责任风险不相同。在PMC模式里,代建单位的风险主要来自于收益和赔偿不合理以及制度这两方面的问题。与之相比,总承包商的李云要达的多,但是风险也相对更大,不仅自然条件的风险由总承包商承担,而且由其余的问题英法的损失总承包商也难咎其责。

二、 PMC 模式和医院建设关系的分析

很久以来,我们国家的卫生建设项目的管理模式相对比较落后,大多数是医院自行建设自行使用的分散管理方式,这种方式的缺点主要表现为投资超额、质量不过关以及工期太长等问题。现在,PMC模式在我们国家的非盈利投资里逐渐的推广,这种模式比较适用于一些对技术和管理要求比较高,有可靠的经济来源以及委托方参与程度不高的工程项目,大部分是一些大的巩固设施的建设以及政府的一些工程项目,比如公路地铁等,这种模式在医院建设里也得到了应用。

在某些地方,运用PMC模式实施医院建设的项目很多。其主要就是,现在的大多数医院对工程的建设程序与制度不是很了解,从而既缺少专业的技术人员与管理的经验又缺少专业的知识。此外,医院的建设有他们自身的特点以及要求,及要求在建筑的规划与布局上能够瞒住病人的要求,又能节约建设成本并有自己的特色与风格。

所以,我们需要勇于探索PMC模式作为政府的投资项目的管理方式的革新,以便加快PMC模式在医院工程建设中的相关应用。而为了便于PMC模式在医院工程中的应用,有几点需要我们注意。首先需要的必备保证措施是建立健全的组织系统让项目管理的目标能够实现。为了能更好的在医院的建设中推行PMC模式,不可缺少的是发展代建的市场范围,用公开招标从代建单位中择优选择,然后再和医院派出的管理人员共同组织项目管理的组织体系,二期可以更具不同的分工设立财务部门、工程项目部门、设计部门等等各个部门,共同负责医院工程建设的进行。

前程是要划分职责与权力,以此明确代建方的地位。对于PMC模式我们国家还没有一个标准而完善的管理方法,导致不同的地方PMC模式的管理权力的划分也都不是一样。而且,代建单位也没有一个正式的法律地位,使之与委托方的责任关系还不是很明确。所以,在进行医院建设的工程项目时,为了能实现投资方、建设方、使用方的相互分离,我们需要合理的安排投资方、代建人以及使用单位也就是医疗机构的义务与责任。在MPC模式里,各方要明确自己的责任。

政府部门的责任是负责督促代建公司的建设管理状况,检验建设的规模以及标准是否满足合约的规定标准,核查工程建设所花费的资金,参与或者组织工程的验收。代建单位的责任是负责对项目建设进行各个方面的管理,对项目的质量与工期进行控制,而且要接受使用方与投资方的监督,以此保证项目的建设按照要求顺利的实施。

医疗机构的责任是负责在项目设计时提出相关的要求以及具体的具有实际意义的建议,此外也有权利有义务监督代建方的行为是否合乎要求。此外,完善的规章制度也是保证代建方的代建任务能够正常顺利实施的重要前提条件。

如何为项目订立质量标准

每个人都认同质量很重要,都希望能生产高品质的产品。但是,在软件领域,“质量”并没有通用的定义。关于“足够好”的软件的观点和关于质量的传统观点经常展开激烈的交锋。为了帮助团队迈向成功,你需要花一些时间与团队成员以及客户沟通,明确他们对质量的要求。

这两个群体对质量的定义往往并不统一,所以在工作时经常会发生误解。对于经理来说,他比较关心产品的交付时间。因此工程师想严格地检查每一行代码,经理也许就会显得不耐烦。对于客户来说,产品的可靠性是最重要的,他肯定不愿意使用一个附带大量很少使用的功能同时又有很多缺陷的产品。一个全新的漂亮的用户界面,可能会令已经熟练使用旧版本产品的用户感到厌烦。

为了更好地理解客户对软件质量的看法,我在柯达公司工作时,我的小组曾经邀请客户(全部是公司雇员)以及他们的经理参加一个公开论坛来讨论这个题目。这个论坛的价值在于,它让我们意识到我们小组所倡导的质量理念与使用我们产品的客户对质量的看法原来是大相径庭的。

知道了差别,你就可以将精力投入到为客户创造最大价值的地方,而不是在最大地满足开发人员的需求方面。

按照传统的理论,软件质量包括符合规范的程度、满足客户需求的情况,低的缺陷率以及为用户提供的价值。时下流行的“六西格玛质量体系”为缺陷密度和失败频度指标设立了很高的标准,但是它不能涵盖质量的全部方面,例如还有快速的产品交付、可用性、丰富的功能以及实现与价格相匹配的价值。虽然我们非常期望所创造和使用的产品遵循大而全的质量标准,但是平衡取舍是不可避免的。

在项目的需求分析阶段,我们列出了10个对用户非常重要的质量特征属性(例如效率、交互性、正确性以及易于学习等)。我们邀请一组主要的客户代表对这些特征属性按照1-5分进行评分。当找出了最重要的特征属性后,我们将以此为依据设计应用程序以满足客户的需求。如果你不花时间来研究客户对质量的要求,而只是按照自己的意愿设计质量标准,最后要真能达到客户所期待的质量水平,那只能算你走运。

在我所听过的各种关于质量定义的说法中,最实用的一个说法就是“客户会再回来,但是产品不会”。要与客户和开发团队密切合作,一同为每个产品定义适当的质量目标。一旦确立了这些质量目标,就以毫无争议的最高优先级实现这些目标。为了起到表率作用,你必须对自身的工作质量设定高的标准要求。记住这句格言:“力求完美,追求卓越。”