指导与管理项目工作

指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作,并实施已批准变更的过程。
本过程的主要作用是,对项目工作和可交付成果开展综合管理,以提高项目成功的可能性。
本过程需要在整个项目期间开展。

指导与管理项目工作包括执行计划的项目活动,以完成项目可交付成果并达成既定目标。
本过程需要分配可用资源并管理其有效使用,也需要执行因分析工作绩效数据和信息而提出的项目计划变更。
指导与管理项目工作过程会受项目所在应用领域的直接影响,按项目管理计划中的规定,开展相关过程,完成项目工作,并产出可交付成果。

项目经理与项目管理团队一起指导实施已计划好的项目活动,并管理项目内的各种技术接口和组织接口。
指导与管理项目工作还要求回顾所有项目变更的影响,并实施已批准的变更,包括纠正措施、预防措施和(或)缺陷补救。

在项目执行过程中,收集工作绩效数据并传达给合适的控制过程做进一步分析。
通过分析工作绩效数据,得到关于可交付成果的完成情况以及与项目绩效相关的其他细节,工作绩效数据也用作监控过程组的输入,并可作为反馈输入到经验教训库,以改善未来工作包的绩效。

问题日志

在整个项目生命周期中,项目经理通常会遇到问题、差距、不一致或意外冲突。

项目经理需要采取某些行动加以处理,以免影响项目绩效。

问题日志是一种记录和跟进所有问题的项目文件,所需记录和跟进的内容可能包括:

  • 问题类型;

  • 问题提出者和提出时间;

  • 问题描述;

  • 问题优先级;

  • 由谁负责解决问题;

  • 目标解决日期;

  • 问题状态;

  • 最终解决情况。

问题日志可以帮助项目经理有效跟进和管理问题,确保它们得到调查和解决。

作为本过程的输出,问题日志被首次创建,尽管在项目期间任何时候都可能发生问题。

在整个项目生命周期应该随同监控活动更新问题日志。

项目管理信息系统

PMIS 提供信息技术 (IT) 软件工具,例如进度计划软件工具、工作授权系统、配置管理系统、信息收集与发布系统,以及进入其他在线自动化系统(如公司知识库)的界面。
自动收集和报告关键绩效指标(KPI)可以是本系统的一项功能。

管理项目知识

管理项目知识是使用现有知识并生成新知识,以实现项目目标,并且帮助组织学习的过程。
本过程的主要作用是,利用已有的组织知识来创造或改进项目成果,并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。
本过程需要在整个项目期间开展。

知识通常分为“显性知识”(易使用文字、图片和数字进行编撰的知识)和“隐性知识”(个体知识以及难以明确表达的知识,如信念、洞察力、经验和“诀窍”)两种。
知识管理指管理显性和隐性知识,旨在重复使用现有知识并生成新知识。
有助于达成这两个目的的关键活动是知识分享和知识集成(不同领域的知识、情境知识和项目管理知识)。

一个常见误解是,知识管理只是将知识记录下来用于分享;
另一种常见误解是,知识管理只是在项目结束时总结经验教训,以供未来项目使用。
这样的话,只有经编撰的显性知识可以得到分享。

因为显性知识缺乏情境,可作不同解读,所以,虽易分享,但无法确保正确理解或应用。
隐性知识虽蕴含情境,却很难编撰。它存在于专家个人的思想中,或者存在于社会团体和情境中,通常经由人际交流和互动来分享。

从组织的角度来看,知识管理指的是确保项目团队和其他相关方的技能、经验和专业知识在项目开始之前、开展期间和结束之后得到运用。
因为知识存在于人们的思想中,且无法强迫人们分享自己的知识或关注他人的知识,所以,知识管理最重要的环节就是营造一种相互信任的氛围,激励人们分享知识或关注他人的知识。
如果不激励人们分享知识或关注他人的知识,即便最好的知识管理工具和技术也无法发挥作用。
在实践中,联合使用知识管理工具和技术(用于人际互动)以及信息管理工具和技术(用于编撰显性知识)来分享知识。

经验教训登记册

经验教训登记册可以包含情况的类别和描述,经验教训登记册还可包括与情况相关的影响、建议和行动方案。
经验教训登记册可以记录遇到的挑战、问题、意识到的风险和机会,或其他适用的内容。

经验教训登记册在项目早期创建,作为本过程的输出。
因此,在整个项目期间,它可以作为很多过程的输入,也可以作为输出而不断更新。
参与工作的个人和团队也参与记录经验教训。
可以通过视频、图片、音频或其他合适的方式记录知识,确保有效吸取经验教训。

在项目或阶段结束时,把相关信息归入经验教训知识库,成为组织过程资产的一部分。

最终报告

用最终报告总结项目绩效,其中可包含诸如以下信息:

  • 项目或阶段的概述;
  • 范围目标、范围的评估标准,以及证明达到完工标准的证据;
  • 质量目标、项目和产品质量的评估标准、相关核实信息和实际里程碑交付日期以及偏差原因;
  • 成本目标,包括可接受的成本区间、实际成本,以及产生任何偏差的原因;
  • 最终产品、服务或成果的确认信息的总结。
  • 进度计划目标包括成果是否实现项目所预期的效益。如果在项目结束时未能实现效益,则指出效益实现程度并预计未来实现情况。
  • 关于最终产品、服务或成果如何满足商业计划所述业务需求的概述。如果在项目结束时未能满足业务需求,则指出需求满足程度并预计业务需求何时能够得到满足。
  • 关于项目过程中发生的风险或问题及其解决情况的概述。

组织过程资产更新

需要更新的组织过程资产包括(但不限于):

  • 项目文件。在项目活动中产生的各种文件,例如项目管理计划,范围文件、成本文件、进度文件和项目日历,以及变更管理文件。
  • 运营和支持文件。组织维护、运营和支持项目交付的产品或服务时所需的文件。可包括新生成的文件,或对已有文件的更新。
  • 项目或阶段收尾文件。项目或阶段收尾文件包括表明项目或阶段完工的正式文件,以及用来将完成的项目或阶段可交付成果移交给他人(如运营部门或下一阶段)的正式文件。在项目收尾期间,项目经理应该回顾以往的阶段文件,确认范围过程(见 5.5 节)所产生的客户验收文件,以及合同协议(如果有的话),以确保在达到全部项目要求之后才正式关闭项目。

如果项目在完工前提前终止,则需要在正式的收尾文件中说明项目终止的原因,并规定正式程序,把该项目的已完成和未完成的可交付成果移交他人。

  • 经验教训知识库。将在整个项目期间获得的经验教训和知识归入经验教训知识库,供未来项目使用。

结束项目或阶段

结束项目或阶段是终结项目、阶段或合同的所有活动的过程。
本过程的主要作用是,存档项目或阶段信息,完成计划的工作,释放组织团队资源以展开新的工作。
它仅开展一次或仅在项目的预定义点开展。

在结束项目时,项目经理需要回顾项目管理计划,确保所有项目工作都已完成以及项目目标均已实现。
项目或阶段行政收尾所需的必要活动包括(但不限于):

  • 为达到阶段或项目的完工或退出标准所必须的行动和活动,例如:
  • 确保所有文件和可交付成果都已是最新版本,且所有问题都已得到解决;
  • 确认可交付成果已交付给客户并已获得客户的正式验收;
  • 确保所有成本都已记入项目成本账;
  • 关闭项目账户;
  • 重新分配人员;
  • 处理多余的项目材料;
  • 重新分配项目设施、设备和其他资源;
  • 根据组织政策编制详尽的最终项目报告。

为关闭项目合同协议或项目阶段合同协议所必须开展的活动,例如

  • 确认卖方的工作已通过正式验收;
  • 最终处置未决索赔;
  • 更新记录以反映最后的结果;
  • 存档相关信息供未来使用。
  • 为完成下列工作所必须开展的活动:
  • 收集项目或阶段记录;
  • 审计项目成败;
  • 管理知识分享和传递;
  • 总结经验教训;
  • 存档项目信息以供组织未来使用。

为向下一个阶段,或者向生产和(或)运营部门移交项目的产品、服务或成果所必须开展的行动和活动。
收集关于改进或更新组织政策和程序的建议,并将它们发送给相应的组织部门。
测量相关方的满意程度。
如果项目在完工前就提前终止,结束项目或阶段过程还需要制定程序,来调查和记录提前终止的原因。
为了实现上述目的,项目经理应该引导所有合适的相关方参与本过程。

变更控制工具

为了便于开展配置和变更管理,可以使用一些手动或自动化的工具。
配置控制重点关注可交付成果及各个过程的技术规范,而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。

工具的选择应基于项目相关方的需要,包括考虑组织和环境情况和(或)制约因素。
工具应支持以下配置管理活动:

  • 识别配置项。识别与选择配置项,从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
  • 记录并报告配置项状态。关于各个配置项的信息记录和报告。
  • 进行配置项核实与审计。通过配置核实与审计,确保项目的配置项组成的正确性,以及相应的变更都被登记、评估、批准、跟踪和正确实施,从而确保配置文件所规定的功能要求都已实现。

工具还应支持以下变更管理活动:

  • 识别变更。识别并选择过程或项目文件的变更项。
  • 记录变更。将变更记录为合适的变更请求。
    做出变更决定。审查变更,批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。
  • 跟踪变更。确认变更被登记、评估、批准、跟踪并向相关方传达最终结果。
    也可以使用工具来管理变更请求和后续的决策,同时还要格外关注沟通,以帮助变更控制委员会的成员履行职责,以及向相关方传达决定。

实施整体变更控制

实施整体变更控制是审查所有变更请求、批准变更,管理对可交付成果、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。
本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求,并决定对变更请求的处置方案。
本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更,往往会加剧整体项目风险。
本过程需要在整个项目期间开展。

实施整体变更控制过程贯穿项目始终,项目经理对此承担最终责任。
变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。
在整个项目生命周期的任何时间,参与项目的任何相关方都可以提出变更请求。
变更控制的实施程度,取决于项目所在应用领域、项目复杂程度、合同要求,以及项目所处的背景与环境。
在基准确定之前,变更无需正式受控于实施整体变更控制过程。一旦确定了项目基准,就必须通过本过程来处理变更请求。
依照常规,每个项目的配置管理计划应规定哪些项目工件受控于配置控制程序。
对配置要素的任何变更都应该提出变更请求,并经过正式控制。

尽管也可以口头提出,但所有变更请求都必须以书面形式记录,并纳入变更管理和(或)配置管理系统中。
在批准变更之前,可能需要了解变更对进度的影响和对成本的影响。在变更请求可能影响任一项目基准的情况下,都需要开展正式的整体变更控制过程。
每项记录在案的变更请求都必须由一位责任人批准、推迟或否决,这个责任人通常是项目发起人或项目经理。
应该在项目管理计划或组织程序中指定这位责任人,必要时,应该由变更控制委员会(CCB)来开展实施整体变更控制过程。
CCB 是一个正式组成的团体,负责审查、评价、批准、推迟或否决项目变更,以及记录和传达变更处理决定。

变更请求得到批准后,可能需要新编(或修订)成本估算、活动排序、进度日期、资源需求和(或)风险应对方案分析,这些变更可能要求调整项目管理计划和其他项目文件。
某些特定的变更请求,在 CCB 批准之后,可能还需要得到客户或发起人的批准,除非他们本身就是 CCB 的成员。