定义流程

总论

该流程管理项目或项目群生命周期的定义阶段。它的目标是:

  • 开发项目或项目群详细图景;
  • 决定工作是否有合理正当的理由;
  • 描述工作如何来管理的治理政策;
  • 获得发起人对于交付阶段的授权。

经授权的概述文件定义计划将触发该流程。无论决定工作是作为项目还是项目群来加以治理,这个流程都是一样的。该流程的产出,是一套描述工作所有方面的文件,包括工作内容、以及为适应情境而各不相同的细节。

 

如要获得更多细节,请在图表要素上点击。

 

定义流程将计划工作的管理与交付。将汇总的计划呈现给发起人以获得对交付阶段的授权。尽管要到定义流程结束的时候才显示正式的授权申请,但项目经理与发起人应该在整个过程中定期进行沟通。

最终做出正式的授权申请时,发起人应该对提议有了较好的了解。当一些授权前工作可能需要发起人同意的时候,这就更为重要。

规划如何对工作进行管理,包括为所有要运用的相关功能开发政策和程序。至于什么构成“相关功能”则取决于工作情境

规划如何交付工作,要求定义团队要在所有相关功能方面都有能力。作为结果的交付文件,定义项目或项目群以及如何执行。一旦获得授权,它们就成为基线,为监督与控制进展提供起点。

Thamhain 与 Wilemon冲突来源理论识别出,冲突通常在生命周期的这个阶段达到其最高点。如果再结合这一事实,即团队仍处整合期、可能在Tuckman团队发展阶段模型的“风暴”阶段,那么显然项目或项目群经理必须对冲突具有高度的敏感性,而且具备领导力冲突管理影响力的技能。

执行得很好的定义流程,为成功的交付流程奠定基础。

 

任命定义团队

在规模较小的项目中,识别团队可能具有足够的专业度与能力,来继续与实施全部的定义。对于规模较大的项目与项目群,可能需要提供充分具有所需能力的资源,对识别团队加以补充。建筑项目可能需要招募额外的专家例如结构工程师或机械与电子(M&E)工程师;IT或业务变革项目群可能需要招募额外的商业分析师或系统架构师。

这些技术角色聚焦于定义工作范围,较少参与项目或项目群的交付阶段。准备管理计划、高层面的范围文件与启动交付文件,通常由继续形成管理交付阶段的团队的那些角色来承担。

 

回到图表

 

定义范围

在范围管理功能中描述的程序,将用于捕捉利益相关方要求、编制解决方案与定义合适的收益。一些项目的范围就是围绕产出,而其他的项目则包含收益。项目群的范围是围绕收益、常常包含实现这些收益需要进行的重大商业变革。

适合于项目或项目群的文件可以包括:

范围文件的类别范围与包括的细节,也受到所选择生命周期的影响。与并行生命周期相比,在串行生命周期里,目标(产出或收益)通常在该阶段定义得更详细些。并行方法(例如敏捷)在生命周期中持续地开发范围,因此起始定义要比较高层面和灵活。

 

回到图表

 

授权前的工作

调集或开始交付工作之前,结束所有规划工作,经常是不大现实的。可能需要的专业材料或设备需要较长的订货到交货时间;通过竞争性招投标产生的供应商采购,可能需要早些开始;申请法规或监管部门的批准,可能很花费时间。

与规划并行,管理团队应该识别任何需要在完全定义或授权之前就做完的授权前工作。为物资安排临 时订单或启动招投标流程的优势,必须针对项目或项目群下个阶段没有获得授权这个风险进行权衡。

授权前工作的实施,应该进行规划并得到发起人的同意。这项工作的完成必须在计划中加以反映,但授权前工作已经完成这个事实,在提出授权申请时,不应该成为判断商业论证是否可持续的影响因素。

 

回到图表

 

准备治理文件

治理文档包括内部创建的管理计划与任何相关的外部政策文件。可以为很多功能创建管理计划,每个功能程序开始于“计划”步骤。有一些计划,例如利益相关方管理计划风险管理计划是具普遍性的,因为管理利益相关方与风险的需要适用所有项目与项目群。其他计划,例如收益管理计划或采购管理计划,只有在工作范围覆盖收益的交付、或使用外部供应商的时候,才具有相关性。

在Praxis中,项目与项目群独立创建管理计划,是能力成熟度第二级的属性。

创建中央控制的管理计划,并根据每个项目与项目群的情境适当调整,是能力成熟度第三级的属性。

基于工作范围,定义团队要决定哪些功能需要管理计划。在比较成熟的组织里,其标准管理计划可以根据特定的工作情境加以调整。而在不那么成熟的组织里,需要为每个新项目或项目群重新创建管理计划。

管理计划不应该独立地进行准备。每个计划都会受到交付文件与其他管理计划的影响。例如,如果利益相关方地图识别出有潜在的对工作的反对,则风险管理计划必须确保对这种风险进行足够的管理。

 

回到图表

 

计划交付

计划交付活动的内容与程度,对每个项目或项目群都是独特的。各种规划文件强调不同的方面。典型的例子包括:

尽管这些工具与技术是分别罗列的,它们之间都是相互作用的。因此按顺序依次准备是不可能的。流程是重复迭代的,例如第一稿利益相关方地图为第一稿风险登记单提供信息,随之,风险登记单可能影响最初的投资评估

为整个项目或项目群做详细的计划,通常是没有必要的,或甚至是不可取的。在项目中,对第一阶段详细地加以计划,但余下的工作会进行高层面的计划。在项目群中,相比后续的工作,第一阶段的计划更为详细。这就是所谓的滚动式规划。交付文档因此具有两个部分,即整体交付计划与项目或项目群第一阶段的详细交付计划。

一旦项目或项目群获得授权,这些文件就成为“基线”文件。在交付阶段期间,要监督进展、并与基线文件进行比较。

 

回到图表

 

汇总定义文档

在定义流程结束的时候,要向项目或项目群发起人递交授权申请。是否继续进行交付阶段,要在对相关文档进行评审之后做出决定。如果获得了授权,下个步骤就是为项目或项目群交付阶段的第一阶段调集资源。如果没有获得授权,就要实施最简易版本的收尾流程,解散定义团队并保存信息。

尽管向上递交什么文件以获得批准,根据情境具有差异,但通常会提供三个文件:

  • 项目或项目群管理计划
  • 这个文件总结概括所有项目或项目群的管理计划,或者将这些文件加以汇总。它可能是一个单独、自我包含的文件,对每个相关功能都有一个部分,或是那些单独管理计划的汇总。

  • 在其项目与项目群组合里具有标准管理计划的成熟组织里,总体管理计划只需要参考这些标准计划、参照当前的工作情境进行调整。熟悉这些组织标准的发起人,只需要考虑做好调整,以再确保工作具有必需的治理。

  • 商业论证
  • 商业论证解释了工作的正当合理性。它对范围进行概括并与达成范围所要求的成本和风险进行平衡。它将参考更详细的交付和内容文档,例如规格要求、预算、风险登记单等。

  • 项目或项目群交付计划
  • 交付计划显示目标将如何实现。它概括交付文件,并包括总体进度、资源要求、现金流与组织架构。该计划可能覆盖要执行的所有工作,或者它可能参考更加详细的项目或项目群阶段、或功能方面的计划,例如沟通、风险或质量。

 

回到图表

 

调集

一旦获得授权,项目或项目群就能调集资源了。将所需的设备、设施与其他资源调集到位,以交付目标。

 

回到图表

 

项目与项目群

对于小规模项目,定义活动可能由项目经理进行管理与实施,但最低要求就是要有一位独立的发起人和一位项目经理的组合。也有可能把识别与定义阶段组合成单一的流程。

该流程创建很多文档。但太多文本与太少文本一样,都会对工作的成功带来潜在的损害。Praxis 的文档部分,不应该被视为是需要创建的文档,而应该是能够使用的文档范围。该流程一个重要部分,就是决定最适合每个项目或项目群的规模和复杂度的特定文件。

该流程一个重要要素,是决定什么构成相关文档以满足申请授权的目的。对于规模较小的项目,文档可能被提炼成给发起人的演讲中的关键要点。对于规模较大的项目或项目群,治理与交付文件可能经总结概括后提供给发起人考虑,在要求的时候有更详细的文件可供检查。

在有些情境中,定义流程可能由客户组织加以实施中心。定义文档可能就交给计划了交付的承包商组织。定义流程随后就划分为项目客户方与承包商方之间进行。

在规模更大些的项目群里,定义流程可能本身就是一个小项目。它可以作为项目来运作,项目产出为项目群的定义文档和交付计划。流程模型的所有方面都是可扩缩的,较小版本可以嵌套入较大版本里。

 

 

 

 

 

 

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Back to top