项目管理程序
作者: 来源: 文字大小:[大][中][小]
项目管理是一种综合性的工作--在某一工作区域内采取行动或不采取行动都会对另一个工作区域产生影响。这种内在的相互作用可能是很明确的，可以把握的，也可能是不确定的、难以把握的。比如，项目范围的变动几乎总是会影响项目的成本，但是这是否会影响工作组的士气决心或者产品的质量就不一定了。
由于存在这种内在的相互作用所以需要我们对各种项目目标进行权衡--在一个工作区域加强工作力度就可能需要减少在另一个工作区域的工作力度，成功的项目管理要求能有效的控制这些内在的相互作用。
为了帮助大家理解项目管理的综合性，以及强调这种综合的重要性，本文就项目程序的构成及其它们的相互作用作了阐述，本章把项目管理分解为许多相互连接的程序，为大家理解4-12章有关程序的理论提供了必要的基础，本章的内容包括：
3.1项目程序
3.2程序组
3.3程序内部的相互作用
3.4按顾客需求制定项目程序
3.1项目程序
项目由一个一个的程序组成，一个程序是"为实现某一个结果的一系列行动"，项目的程序是由人来完成的并且大致可以分为两类：
项目管理程序注重对项目工作进行描述和组织。项目管理的程序在大多数时候对多数项目都是适用的，本章对此只作了简要的阐述，我们将在4-12章中再作进一步讨论。
产品导向型程序注重对项目产品进行具体说明并进行制造。产品导向型程序常常是通过项目生命周期来进行定义（见第2章第1节），并且在不同的应用领域会有所不同（见附录F）。
项目管理程序和产品导向型程序在整个项目中会相互迭用、相互作用。比如，如果缺乏对如何制造产品的基本了解，我们就无法确定项目的范围。
3.2程序块
项目管理程序可以被分为五块，每块有一个或多个程序组成：
起始程序块--确定一个项目或一个阶段可以开始了，并要求着手实行。
计划程序块--进行计划并且保持一份可操作的进度安排，确保实现项目的既定商业目标。
执行程序块--协调人力和其它资源，执行计划。
控制程序块--通过监督和检测过程确保项目达到目标，必要时采取一些修正措施。
结束程序块--取得项目或阶段的正式认可并且有序地结束该项目或阶段。
程序块通过各程序块的结果进行连接--个程序块的结果或输出是另一个程序块的输入。在核心程序块间，程序块反复进行连接--计划在开始时为执行提供了一份书面的项目计划，随后又给项目计划提供一份更新的书面文件，以示项目的进程。图3-1表示了这种联系，另外，项目管理程序块不是相互分立的、一次性的事件；在整个项目的每一个阶段它们都会不同程度的相互交迭，图3-2表示了程序块是如何交迭的，在一个阶段内这种交迭会怎样变化。
项目管理程序 最后，程序块的相互作用也会跨越阶段；一个阶段的结束作为下一个阶段开始的输入。比如，结束一个设计阶段要求顾客接受认可设计文稿。类似的，设计文稿为实施阶段提供了产品说明。这种内部作用如图3-3所示。
在每一个阶段开始时重复起始程序确保项目不会偏离既定的商业要求，也帮助确保当商业要求已不存在或项目已不可能满足这种要求时中止这一项目。在第5章第1节"起始"部分会进一步详细讨论商业要求。
尽管图3-3表示的是分立的阶段和分立的程序块，但在实际项目中它们可能会有相互交迭。比如，计划程序不仅为成功地完成项目提供了本阶段所需做的工作的细节，并且可能为下一个阶段所需做的工作提供前期的说明。这种项目计划的推进式细节说明常常被称为"滚动计划"。
3.3程序的相互影响
在每一个程序块中，各个程序通过它们的输入、输出进行连接。如果将注意力集中于这些连接上，我们可以这样描述程序：
输入--书面文件或书面表述的工作，下达开始工作的指令。
工具和技巧--运用各种输入得到输出。
输出--书面文件或书面表述的工作，它们是每个程序结束后得出的结果。
在下文我们列出了对于大多数应用领域中的大多数项目都普遍适用的项目管理程序，在4-12章我们会详细讲解。程序名后括弧中的数字指明了在哪一章节会作进一步阐述。在这里阐述的程序内部的相互作用同样也是对大多数应用领域的大多数项目适用的。在第3章第4节我们讨论按顾客要求确定有关程序说明和相互作用的问题。
3.3.1起始程序块
图3-4表示了在这一程序块中单个的一个程序。
起始（5.1）--指示组织开始项目下一个阶段的工作。
3.3.2计划程序块
计划对于一个项目是非常重要的，因为项目涉及许多以前从末做过的工作，因此在这一部分有相对较多的程序。但是，程序的数量并不代表计划是项目管理中最主要的部分--计划的工作量应与项目的范围和还有信息的实用性相匹配。
图3-5表示了项目计划程序块中程序的相互关系（这是图3-1中椭圆形"计划程序块"的扩充）。这些程序是在计划完成之前反复运作的程序标题。比如，如果开始设定的完成日期是不能被接受的，那么项目资源、成本，或者甚至是范围都可能需要重新制定。另外，计划并不是一门精确的科学--两个不同的工作组可能会为同一个项目制定出区别很大的计划。
核心程序 一些计划程序间有很明确的关联性，这使得它们在多数项目中需要按相同的次序来实施，比如，在对活动进行进度安排和成本核算前首先需要对活动本身进行界定。这些核心计划程序可能会在一个项目的任何一个阶段，被反复实施好几次。核心计划程序包括：
范围计划(5.2)--制定一份书面的范围表述，作为将来需要作项目决定时的基础。
范围界定(5.2)--将主要的项目工作步骤细分为更小、更易管理的构成单元。
活动定义(6.1)--确认具体的活动，这些活动的实施对于完成项目各阶段的工作成果是必须的。
活动顺序安排(6.2)--明确并用书面形式表述活动内部的关联性。
活动持续时间估计--估计为完成各个活动所需的工作时间。
进度安排(6.4)--分析活动顺序、活动持续时间和资源需求，制定项目进度。
资源规划(7.1)--确定实施项目活动所需的资源（人力、装备、原料）及相应的数量。
成本估计(7.2)--估计实施项目活动所需的资源成本。
成本预算(7.3)--将总体成本估计分配到各项工作上。
项目计划研究(4.1)--将其它计划程序的结果纳入到一份稳定、连贯的文件中。
辅助程序 在其它的项目计划程序中的内部相互关系比核心过程更有赖于项目的性质。比如，有一些项目几乎没有或没有可识别的风险，一直到大部分的计划已经被实施且工作组认识到成本和进度安排受到了严重的挑战时才出现很大的风险，尽管在项目计划期间，这些辅助程序断断续续地按需要被实施，但它们不是可以自由选择的。辅助程序包括：
质量规划(8.1)--明确哪一些质量标准是与本项目相关的，决定怎样去满足这些标准。
管理规划(9.1)--确定、记录并分配项目职责和报告关系。
人员组织(9.2)--组织项目工作所需的人力资源。
沟通规划(10.1)--识别项目涉及人员所需的信息和沟通需求。谁需要什么信息、何时需要、以及怎样传递给他们。
风险认别(11.1)--识别可能会影响项目的风险，并且说明每种风险的特征。
风险量化(11.2)--进行风险评估，并且分析风险间的相互作用，确定一系列可能的项目结果。
风险对策研究(11.3)--确定进行机会选择和危险应对的步骤。
采购计划(12.1)--确定购买什么，何 购买。
征集申请书计划(12.2)--以书面形式表述产品需求和识别潜在的来源。
3.3.3执行程序块
和第3章第2节的第2部分中的计划程序块一样，执行程序程块也包括核心程序和辅助程序。图3-6表示了下列程序是如何相互作用的：
项目计划的执行(4.2)--通过实施计划内的活动来执行计划。
范围核实(5.4)--项目范围的正式验收。
质量保证(8.2)--有规律的对所有项目工作进行评估，确保项目达到相关的质量标准。
团队建设(9.3)--开发个人及团队的工作技能，以便提高实施项目工作的水平。
信息传递(10.2)--定期向项目涉及人员传递他们所需的信息。
征集申请书(12.3)--求征适当的报价。
货源选择(12.4)--从潜在的卖方中进行选择。
合同管理(12.5)--处理与卖方的关系。
3.3.4控制程序块
必需有规律的评测项目工作，以便知道实施情况与计划间存在的差异。各工作区域中存在的差异都被纳入控制程序块中，一旦发现出现了重大差异(如对项目目标构成威胁的差异)就需要重新正确实施计划程序，对计划加以调整。比如，一项活动延误了，就需要根据所延误的时间，或根据对成本预算及进度安排权衡并调整目前的人员规划。控制也包括对可能发生的问题预先采取防范措施。控制程序块同样也包括核心程序和辅助程序，图3-7表示以下程序的相互作用：
全程变化控制(4.3)--协调整个项目中出现的变化。
范围变化控制(5.5)--控制对项目范围的改变。
进程控制(6.5)--控制对项目进程的改变。
成本控制(7.4)--控制对成本预算的改变。
质量控制(8.3)--监测具体项目结果，判断它们是否达到了相关的质量标准，确定消除导致不满意实施状况的成因的方法。
实施情况报告(10.3)--收集和发送实施情况的信息，包括情形报告、进程检测及预测。
风险对策实施控制(11.4)--在项目进行中对风险进行应变。
3.3.5结束程序块
图3-8表示了以下程序的相互作用：
行政收尾(10.4)--产出、收集、发放阶段或项目正式结束的信息。
合同收尾(12.6)--合同完成，及对赊销的清偿。
3.4按顾客需求制定项目程序
在第3章中确定的程序及图示的内部相互关系满足了总体可行性检测的需要--它们在大多数时候对大多数项目适用，但是并不是所有项目都需要有这些所有的程序，也并不是所有的内部相互关系都适用所有的项目。比如：
一个大量使用分包商的组织会在项目计划程序中，对每一次采购程序都加以明确的说明。
缺少某一个程序并不意味着这个程序不应该被实施。项目管理工作组应该确认并且管理所有确保项目成功的程序。
依赖于某种独一无二的资源的项目(商业软件开发)可能会在范围界定之前先确定工作人员及职责，因为所能获得的人才决定了所能进行的工作。
有些程序输出可能预先确定控制的因素。如管理需要确定一个目标完成期限，而不是任由进程计划决定。
较大型项目相对需要更多细节。如风险识别就需要分别对风险成本、计划风险、技术风险以及质量风险等进行细致分析。
对干一些子项目和小项目来说，则不需付出太多努力在已经被限定于项目水平上的程序（如：谈判小组的成员就可以忽略谈判小组组长所承担的风险）或提供不重要功能的程序（如四人的项目就不必制定正规沟通计划了）。
当需要变化时，则变化应清晰界定，仔细权衡和极积应对。