“项目管理系统成熟度模型”白皮书

本白皮书是我们的“一线快报”系列文章的一部分。 本文介绍随着公司的成长成熟,如何才能提高项目管理系统的使用效率。 本文说明了选择仅在可以接受的范围内使用新项目管理系统的某些方面为何可以帮助公司提高效率 - 即使他们迫切希望使用所有可用功能。 随着公司继续成熟,公司会需要更得心应手地利用更先进的功能。

若要下载本白皮书的 Word 版本,请参阅项目管理系统成熟度模型:白皮书

若要阅读更多白皮书,请参阅“一线快报”白皮书

项目管理系统成熟度模型

项目管理系统成熟度 (PMM) 模型是当前的讨论热点。 帮助组织评估“项目成熟度水平”的顾问越来越多,生意也越来越好,这种成熟度水平几乎始终采用分层显示的形式,成熟度总是越高越好。 这一理念的拥护者声称 PMM 模型能够展示组织的项目管理能力。 关于组织如何提高有效性的论题已经有太多讨论,我并不保证项目管理成熟度模型必然能帮您实现这个目标。 这个主题将留待以后探讨。 无论您是否是 PMM 模型的拥趸,我都曾见过使用项目管理系统的组织采用过其他类型的成熟度模型。

我们与部署项目管理系统的组织合作时,常常会发现这些组织希望如供应商演示的那样,充分利用新系统中的每一个元素。 客户看着那些曾几何时只存在于梦中的报告、屏幕和工作流程,幻想所有功能都能如同销售演示中那样,在其组织中顺畅运行。 客户通常都不明白一点:演示的那些演示数据和演示配置是精心制作而成,其目的在于展示尽可能多的产品优势。 在 Microsoft Project 和 Project Server 的案例中,这可能超出了单个产品的范畴,也许会包含整个技术堆栈。

客户会看到从 Windows SharePoint Services 或 Microsoft Office SharePoint Server 启动的屏幕。 他们会看到涉及 Active Directory 或 SQL Server Reporting Services 的功能。 他们可能会看到来自 BizTalk Server 或 Windows Workflow Foundation 的工作流程以及来自 PerformancePoint 的显示画面。 数据流可能会遵照某个演示脚本或用例场景,这些资源可帮助客户轻松理解产品的潜在优势,但却难以理解基础技术。

在真正着手交付客户感兴趣的功能时,我们需要充分考虑客户的渴望,但也要核实现状,说服客户不要奢求立即部署所有功能。 客户需要确定其希望采用的业务开展方式,然后我们才能考虑配置此类功能,并思考产品是否已提供相应的现成功能,或是要通过配置或自定义调整才能实现此类功能。 有些客户会坚持部署其设想的所有功能,会做好充分准备以深入研究和开展此类解决方案的设计、培训、学习和开发,也会找到必要的时间和资金来进行部署,但这些组织只是少数而已。

更常见的情况是, 客户会根据能令自身感到满意的程度来选择部署全新项目管理系统的某些功能。 随着组织对于系统及基础业务流程的熟悉,它会需要越来越多的系统功能;随着自身的进步而变得更加“成熟”。 这是一种自然的演进。

对于可自动化的项目管理流程,组织的理解在发生演变的同时,其对于这种自动化的需求也在随之演变。 这种自然的演进与项目管理或能力成熟度模型类似。 在得知组织很有可能会沿着这些方向演变后,我们可以非常有效地找到让组织变得更加高效的方法。 在掌握了组织的项目系统成熟度的情况下,我们倾向于关注那些已知具备更高采用几率以及可带来投资回报的项目系统领域。 当然,每个组织都不尽相同,因此将这种知识书写成范本并不是一个好的方案。 这只是我们通过与许多公司的合作经历而得出的可能性最高的演进方式。

根据我们的经验,项目管理系统的用法的自然演变分为五个基本领域,尽管由于技术带来的关键影响,这些领域的排序在近年来发生了改变。 我们首先来谈谈这五个基本领域,我会在本文临将结束时介绍过去几年观察到的一些新的转变。

项目管理系统的 5 个主要方面

1 - 计划   。 我们总是会将计划排在首位。 一些组织从未超越这一阶段。 他们制定基本的日程计划,装裱甘特图,然后将它挂在项目团队办公室的墙上。 当员工想起临到项目启动前日程计划展现的美妙状态时,他们才会抱着怀旧的心态去不时查看这张板子。

我对于那些仅仅把昂贵的项目管理软件用于制作横线计划图表的人有点不爽,但这种做法也不是没有价值。 创建一份组织有序的日程计划容易让项目参与者思考应以何种方式将各种工作整合到一起,这种做法比什么都不做或仅仅制作一张电子表格清单要有效得多。

2 - 跟踪   。 按照我们的经验,下一步通常都是跟踪。 在项目管理系统的使用方面略微“成熟”的组织不会仅仅满足于规划,他们会跟踪自己的日程计划,然后根据最新的进度来定期推进计划,甚至还会随着计划的演进,通过预计日程计划来展望未来。 对于许多组织而言,止步于此便已足够。 他们在项目管理系统中制定计划,然后通过定期更新来推进计划,甚至还可以为管理层提供有用的报告。

3 - 资源管理   。 在制定计划和跟踪后,组织倾向于查找资源管理问题并思考如何使用项目管理系统来解决这些问题。 正如我之前谈到的那样,资源可能具备多个方面,但从最基本的层面来考虑,资源分配(将工作分配到资源)是一个重要步骤,接下来是某种类型的资源分析。

4 - 成本管理   。 成本管理是第四个典型的领域,许多组织从未到达这一阶段。 从基本层面来看,要进行成本核算,最好首先按阶段(按任务更好)对成本估算进行细分。 下一步,则是按时间或资金来跟踪实际成本。

5 - 高级   。 我将“高级”主题划归于第五个领域,这一分类下可能涵盖了我迄今为止 在其他分类下没有涉及的广泛主题。 这并不代表它们就不重要,而是说,当您到达组织演进的第五阶段时,可以选择许多不同的演进方向。 因此,我将风险分析、文档管理和自动化工作流程划归于这一领域。 前文介绍的其他四个领域中同样也存在着高级领域。

我在前文介绍过的每个元素都可以进一步扩展,而这种情况往往伴随着组织项目成熟度的提升以及对于项目管理环境的自动化元素的理解加深。

对于“计划”,可演变为多项目综合日程计划,在其中采用项目间链接或带有子项目的计划管理。

对于“跟踪”,组织通常会从简单的百分比完成进度(这往往都是最低质量的跟踪数据)演进为剩余持续时间。 “跟踪”还可扩展为时间表,从而针对员工个人的原始计划给出准确的工时数。

在“资源”领域,我们会看到组织从“仅将任务分配到资源”演变为“跟踪资源进度(通常会用到时间表)”,然后演变为组织最希望 EPM 提供的功能 - 资源产能规划。 对于某些组织,还可以在此领域下应用“关键链”,从而将资源和日程计划信息合并到单个高级算法中。

对于“成本”,我们通常从基本的预算编制演进为“跟踪实际成本、工时与时间”以了解预算以及实际偏差,然后再演进为“挣值”跟踪,正如国防与航空行业做的那样。

即便是“高级”领域也拥有自己的高级主题。 其中最流行的是“蒙特卡罗风险分析”和综合项目管理方法(尤其是在 IT 领域)。

项目管理系统的“基本”和“高级”区域

大多数组织都是从上图左侧的这五个基本元素出发,按照我在前文中描述的顺序逐步演进到高级领域。 有些组织发现,要解决其面临的特定项目管理挑战,就必须给予其中某个元素更高的关注。 极为困难且罕有成功的做法是,尝试达到超越自身水平的成熟度。

举例来讲,这种现象对于希望实现“资源产能规划”的组织来说非常常见,当您审视组织中的技能和经验时,您会发现缺少创建资源产能规划系统所需的构建元素。 我经常以产能规划的例子来说明为什么认清您在项目管理系统成熟度模型中的位置是如此重要。 在我的经验中,这是组织最希望 EPM 系统提供的一项优势,然而也几乎是我能提供的最后一项优势。 这是因为,要实现资源产能规划,就必须首先搞定太多其他元素。 为了协调预计的资源要求与可用性,我们首先需要:

  • 我们可以依赖的项目计划

  • 准确的项目进度跟踪

  • 所有任务均分配到资源

  • 完整而准确的资源可用性

  • 对所有非项目工作进行量化和跟踪

  • 项目经理和部门经理在已完成工作、预计工作和资源更改方面完全遵守规章制度。

哎呀! 这可不是一份简短的清单,若要符合此类环境要求,企业文化通常会要求进行大规模的更改管理。 那么,我们回头看看项目管理系统成熟度模型,客户可以就其需要完成的目标制定一张路线图。

当然,这并不是完整清单。 我们可以轻松创作第三篇和第四篇专栏文章,但我并没有这么做,因为从这里开始,我们并没有明确找到最常见的演进方式。 每个 组织的项目管理要求决定了其在特定领域进行演进的兴趣。

在前文中,我曾承诺讨论过去几年发生的改变。 上文介绍的模型已存在了很长时间,但在过去几年,IT 行业围绕“协作”这一核心理念出现了另一个方向的重大转变。

曾经,项目管理软件行业是以算法为中心。 我们曾以为一切都源于关键路径进度表。 然而,过去几年发生了一些变化。 首先,互联网和电话技术的普及大大提高了人员的可用性,让项目团队的组建与沟通变得更加轻松。 这改变了项目管理团队的人员组成。 曾经,我们以为项目团队成员都是些深藏在组织内部的员工,大家在一间小小的、没有窗户的房间里工作,办公桌围绕着一个大型绘图仪摆放,而现在,我们认为项目团队成员可能遍布整个组织。

团队成员包括相关工作人员(这是肯定的),但也可能包括高管支持者、部门资源经理、用户和营销部门。 现在经常可以看到,项目团队成员范围扩展到了公司大楼和组织以外,还可能涵盖分包商、总承包商乃至客户。 分包商可能不在同一时区,甚至不在同一国家/地区。 而这些因素使得通信成为了多种不同行业的项目取得成功的关键要素。

而这导致行业中的某些组织(例如研发和 IT)开始寻求使用演进方式各有不同的项目管理系统成熟度模型:

记录的项目管理系统的元素

这些组织的第一要务是创建一套通信计划,而通信几乎始终是基于 SharePoint Server 等协作技术。 这些组织发现,从集中化的角度来看,通过支持扩大的项目管理团队开展协作和通信,可以获得比实施集中式计划更多的利益。 SharePoint Server 的突然流行反映出组织是多么希望帮助员工开展协作。

基础通信计划通常会演进为文档管理 - 这些文档可能包括项目日程计划。 这完全改变了传统企业项目管理的发展方向,但同时也可以看到,这对于一些组织极具吸引力。 有效管理合同、文档、电子邮件、会议和其他通信,效率就会出现高速增长。 如果没法有效管理通信,组织效率可能严重受阻。

从文档管理过渡到问题管理和更改管理 - 对于 IT 和研发组织而言,这意味着管理最有可能损及项目的一个因素 - 只需一个简短的步骤。

下一步是时间表,这或许有几分出人意料 实际上,时间表有时甚至会实施得更早。 当我们的组织首次启动时间表业务、推出 TimeControl 产品时,我们非常确信,需要此类时间表的组织一定是那些拥有足够成熟的计划和跟踪流程的组织,他们必然能够充分利用这些流程。 我们发现,许多组织都希望在部署企业项目管理系统前首先部署企业时间表,您可以想象我们当时是多么惊讶。 当您审视每家组织遇到的更改管理挑战时,上述现象的原因也就一目了然了。 对于时间表,大多数用户虽然接受起来比较勉强,但接受速度很快。 让 1000 人规模的组织接受集中式时间表系统只需大约数周时间。 让这同样的 1000 名用户接受集中式项目 管理系统则可能耗费数月到数年时间。 因此,即便没有建立集中式计划,组织仍然可以通过集中式时间表数据获得巨大的优势。

最后,这些组织会将注意力投向核心项目计划工作。 这并不代表他们先前没有开展过项目计划,只是没有做到高度集中化。

就像第一个项目管理系统成熟度模型那样,其中每个元素也可能有对应的深层次主题。

通信计划通常会演进为更加集成的通信系统,包括即时消息、电子邮件集成和其他功能。

文档管理通常会演进为工作流程管理和论坛集成。

问题管理通常会演进为对各种类型的列表进行管理以及综合更改管理流程。

时间表会从任务时间表演进为与财务、薪资、HR 之间的链接,并最终链接回企业项目管理系统以提供可审计的跟踪数据。

计划和资源管理倾向于像传统项目管理系统成熟度模型那样演进。

关于您对项目管理系统的使用,并不存在所谓“正确的”演进方法,也不存在“错误的”方法。 正如我在此前的专栏文章中说过的那样,最重要的一点在于,您要首先了解自己需要实现的目标,如此方可提高组织的效率,然后再针对相关挑战设计解决方案。 重要的是,在开始构建更加高级的系统时,您要确定自己已经通过基本元素掌握了相关的构建模块。 我常听人说,在成为项目管理博士之前,我们需要参加项目管理 101 培训。

请记住,使用项目管理系统只是一种可行解决方案的一个方面,您要确定您的组织应达到的成熟水平以及演进的领域,以此保证项目管理更加切实有效。

关于作者

Chris Vandersluis 是加拿大蒙特利尔的 HMS Software(Microsoft 认证合作伙伴)的总裁及创始人。 他拥有 McGill 大学的经济学学位,在项目控制系统自动化领域有着三十余年的丰富经验。 他是项目管理委员会 (PMI) 的长期成员,帮助创办了 Microsoft Project 用户组 (MPUG) 的蒙特利尔、多伦多和魁北克分会。 Chris 撰文的期刊包括《财富》、《Heavy Construction News》、《Computing Canada》杂志和 PMI 的 PMNetwork,他也是《Project Times》的专栏作者。 他在 McGill 大学讲授高级项目管理课程,经常在北美和全球各地发表有关项目管理联盟职能的演讲。 HMS Software 是面向项目的时间记录系统 TimeControl 的发布商,自 1995 年起成为 Microsoft Project 解决方案合作伙伴。

可以通过电子邮件联络 Chris Vandersluis:chris.vandersluis@hms.ca

如果您希望阅读 Chris Vandersluis 撰写的更多 EPM 相关文章,请访问 HMS 的 EPM Guidance 网站 (http://www.epmguidance.com/?page_id=39)。

扩展你的技能
了解培训
抢先获得新功能
加入 Office 预览体验计划

此信息是否有帮助?

谢谢您的反馈!

谢谢你的反馈! 可能需要转接到 Office 支持专员。

×