CMMI-项目监控与项目计划.doc

CMMI官方文档（1：项目监控）目的：项目监控的目的是为了能够在项目执行过程中，管理者（包括项目经理和高层经理）能及时了解项目的进展状况；当项目的进展不满足之前制定的计划时，能采取必要的措施来解决问题。简介：项目监控的基础是书面化的项目计划，有了项目计划，才能对比分析项目状况（包括成果、工作量、成本和进度等）和项目计划中的规定，发现存在的差别及其问题的严重程度。项目状态越透明，就越有助于管理者掌握项目实际状况和计划的差距，如果这些差距不及时解决会影响项目目标的实现，管理者就必须采取相应的措施；可采取的措施包括：重新制定项目计划并达成新的一致意见，在项目范围内调整项目计划。l 根据计划监控项目监控项目的成本和进度l 根据项目计划，监控项目计划已经投入的成本和实际进度的状况。监控的具体内容包括：资金的投入、工作量的投入、进度状况，以及项目中各项工作任务的范围、复杂度等可能影响项目的因素。把和项目计划相比较有偏差且会影响项目的情况都记录下来。具体的操作包括：监控项目的成本和进度了解任务和里程碑的实际完成情况对比项目计划和实际的进度情况，确定偏离的程度分析进度偏差的原因（译者注：可以是时间估计不准确，没有分解出来的任务，项目外的任务等）监控项目的开销和已经投入的工作量定期衡量已经投入的工作量、成本和人员对比项目计划中的预算、估计与实际的差别监控工作产品和任务的状况定期衡量工作产品和任务实际的规模、复杂度、以及变更情况分析比较上述内容和项目计划中估计的差别监控资源的到位和使用状况资源包括：办公设施，设计、开发、测试和操作中所需要用到的计算机、外围设备和软件，网络，安全环境，人员；以及所采用的过程监控项目成员的知识和技能定期了解项目成员的知识和技能的实际状况分析比较上述内容和项目计划中估计的差别监控项目已经做出的承诺1.2.1 定期回顾已经做出的对内或对外的承诺1.2.2 发现并记录没有做到的承诺，或者存在较大风险的承诺监控项目风险根据项目的实际状况，定期回顾更新项目风险状况，并滚动更新项目风险记录文档。需要更新风险记录的例子包括：风险发生的概率发生了变化风险优先级发生了变化之后和主要风险的干系人沟通风险状况监控配置管理监控配置管理是为了保证项目计划中配置管理的内容能得到切实实施。（译者注：配置管理指的是项目中产生的各类介质的数据和成果，如何保证有效保存、访问、保密这些数据，就是配置管理的内容，配置管理计划也是项目计划的一部分）监控项目干系人的参与项目计划中的“项目干系人参与”部分确定了关注项目的干系人，以及他们是如何参与项目中的。项目干系人对项目的参与也应被监控，以确保干系人对项目状况必要的了解和沟通会按照计划和实际需要得到落实。1定期回顾项目的执行状况项目执行过程中的回顾是非正式的，并不需要在项目计划中明确定义出来。回顾的内容包括：项目团队中的人员状况项目所需要完成的成果的进展状况，以及产品研发过程的执行情况项目中的管理状况具体操作包括：把工作进展情况定期和项目干系人沟通；可能的干系人包括：管理层、项目组成员、客户、最终用户、供应商、以及其他关注项目的人回顾为了项目控制而收集到的项目度量数据，及其分析结果，发现并记录项目中存在的问题，确定要进行的变更，把问题和变更都纳入跟踪体系，直到都被解决里程碑评审里程碑评审是项目计划时已经拟定的里程碑时进行的评审，通常是正式的评审。具体操作包括：1）评审项目的承诺、计划、状态和风险等情况2）识别和记录存在的重大问题，以及这些问题可能造成的影响3）确定要采取的对应措施和决定，并记录下来4）跟踪措施的执行，直到问题得以解决2管理纠正措施直到问题得以解决2.1分析问题收集和分析问题，当这些问题得不到解决会影响项目目标的达成时，就应采取相应措施来扭转局面。问题可以通过平时或评审来收集，具体可包括：项目实际发生值同项目计划估计值有明显偏离没有兑现的对内或对外的承诺数据在访问权限、收集方式、保密措施上存在的问题项目干系人提出的问题2.2采取纠正措施对已经发现的问题可采取的措施包括：调整工作内容和工作方式调整需求修改估计值和调整计划重新讨论之前达成的承诺增加资源调整产品研发过程滚动更新项目风险记录把这些措施记录下来，并和相关干系人讨论达成新的共识，并确定要采取的措施。2.3管理纠正措施具体包括：1）跟踪纠正措施的落实直到问题得到解决2）分析纠正措施的结果，看是否达到了预期的效果3）把预期效果和实际情况的偏差也记录下来在解决问题过程中，以及对结果的分析中学习到的经验教训可记录到“计划和风险管理”的过程文档中，以提升组织的能力。3形成组织层面的监控能力3.1确定组织层面对项目监控的策略在组织/公司层面要确定对“项目监控过程”的总策略；即组织层面对监控项目状况和管理纠正措施的要求和期望。（译者注：例如组织对待监控的总的态度，组织对监控的频率、粒度和方式的要求，组织要求的跟踪纠正措施的方式和力度等）3.2对监控过程的计划对如何执行项目监控过程的计划也是项目计划的一部分。3.3资源保证要有相应的资源保证，提供监控过程中所需要的服务，以便能顺利实施项目监控。可提供的资源的例子包括：成本跟踪系统工作量报告系统任务跟踪系统（译者注：如JIRA）项目管理和进度管理软件（译者注：如MS Office Project）3.4明确职责明确分配给执行监控过程的人相应的职责，并有明确的授权过程。3.5提供培训给执行或支撑项目监控过程的人提供必要的培训。培训的主题可以包括如下内容：项目的监控过程风险管理配置管理3.6配置管理把项目监控中产生的工作成果纳入恰当的配置管理之下。（译者注：这些成果存在的位置、可供访问的权限等要在配置管理的统一计划和管理之下，不能是随随便便的）3.7引入相关干系人在项目计划时，就应识别出项目监控过程的干系人，这些干系人要在项目监控过程中发挥应有的作用。这里所说的项目监控过程干系人和普通意义上的项目干系人是有区别的。（译者注：普通项目过程的干系人更关心的是项目的成果是否满意；而监控过程的干系人主要关心的是项目的过程是否存在问题。即前者多为项目的客户或大领导，更关注结果，而后者多为过程管理人员或直接领导，会关注过程，并帮助项目从过程中获得好的结果）监控过程的干系人介入项目的典型例子如下：参照计划评价项目现状回顾承诺和正在解决中的问题的状况回顾项目风险回顾数据管理活动回顾项目采用和执行的过程管理纠正活动直到问题解决3.8监控“项目监控过程”项目监控过程也需要根据项目计划来进行监控的，如果有偏差也需要纠正。对“监控过程”的监控的例子包括：了解纠正措施未关闭和关闭的数量回顾和评审执行的次数和类型3.9客观评价监控过程根据项目监控过程的过程描述、标准、规程来客观的评价实际中的项目监控过程的执行情况。3.10 和高层管理者共同评审项目监控的执行状况和高层管理者共同评审项目监控过程的行动、状况和结果，并解决存在的问题。3.11 把“项目监控过程”制度化3.11.1建立一个定义好的项目监控过程3.11.2收集改进的信息收集来自于项目监控的计划和执行过程中产生的工作成果、度量指标、度量结果和改进信息，以提供给后续使用，并充实到组织的过程资产中。能看懂的CMMI官方文档（2：项目计划）项目计划目的：项目计划的目的是制定和维护项目中各类活动的计划。（译者注：凡事预则立，不预则废。一个非日常化工作的、多人组成需要协作完成的项目更是如此）简介：项目计划包括如下几个方面：制定项目计划和项目干系人进行必要的沟通，并达成承诺维护已经制定的计划制定项目计划的起点是产品和项目的需求。（译者注：需求决定了项目的工作内容和成果的价值）制定项目计划通常的内容包括：估计工作产品和任务的规模和复杂度，确定所需要的资源，同客户协商并达成协议，制定进度表，识别并分析可能的风险；上述内容在制定项目计划过程中往往是交叠进行的（译者注：即没有严格的先后顺序）。为了完成已经同客户达成的协议，项目计划是执行和控制项目的基础（译者注：没有清晰的、文档化的计划，项目的执行和监控就是没有基础的，也就无法保证协议的完成）。当项目执行过程中遇到需求变更、同客户达成的协议更改、之前的估计不准确、需要采取措施以解决项目中存在的问题、和改变项目正在采用的过程时，通常需要修订项目计划。本文中会详细描述计划和重新计划的内容。CMMI中和项目计划相关的内容还包括：需求开发、需求管理、风险管理和技术方案等。1进行项目的估计进行项目的估计是要搞清楚会影响项目的各种因素，对这些因素有了充分的了解和估计，我们才有足够的信心来制定现实的、可完成项目目标的计划。影响项目的主要因素包括：项目需求，包括产品本身的需求，组织层面的需求，客户的需求，以及其他影响项目的需求项目的范围确定的任务和工作产品技术路线选用的项目生命周期模型（如：瀑布模型、增量模型、迭代模型等）工作产品和任务的规模和复杂度要求的进度表历史数据（可以把工作产品和任务的规模和复杂度转换为需要的人日和成本）计算得到所需要资源、技能、工作人日和成本的计算方法我们需要把估算理由和支撑数据等材料提供给项目干系人评审，以便能达成对项目计划的一致意见，也便于项目进展中维护项目计划（译者注：看项目执行过程中同计划估算的偏离程度，才便于进行项目的监控和重计划）。1.1估计项目范围可以通过建立高层的WBS（工作任务分解）的方法来估计项目的范围。在项目过程中，贯穿着WBS方法。在项目初期，可以用高层WBS来进行最初的项目估计。制定WBS可以把整个项目分解为相互联系的、便于管理的部分，每个部分也被称为“工作包”。WBS提供了一种用来分配工作量、制定进度表和明确工作职责的机制，以便于项目的计划、组织和控制。具体操作：1）基于产品架构进行WBS工作任务分解WBS提供了围绕要完成的工作任务来组织项目的一种机制，即可以根据用WBS分解之后的工作任务来：识别项目风险及其确定缓解措施明确交付件和项目支持的活动分析需要提供的知识和技能制定相关的计划，如配置管理计划、质量保证计划和测试计划2）高层WBS可以用来帮助计算项目所需的工作量，并进行职责的分配。WBS越是详细，就越有助于帮助项目制定更为现实的进度表，从而减少管理上预留时间的必要。3）确定需要外部提供的产品或功能组件可以参考“供应商管理”部分，了解如何从外部来源获取项目所需要的产品或功能组件。4）确定可以重用的工作产品1.2估计工作产品和任务的规模和复杂度很多估算模型都首选“规模”作为估计工作量、成本和进度的输入条件；其他条件还包括相互之间的关联性、复杂度等。可用来衡量规模的指标包括：功能点的个数源代码行数类和对象的数量需求的数量接口数量和复杂度文档的页数输入和输出的数量技术上存在的风险的数量估算应该和项目需求保持一致，这样才能确定出项目的工作量、成本和进度。每一个被估算的个体，都应该估计它的难度或复杂度。具体操作：1）确定项目的技术路线技术路线确定了产品开发的总体策略，包括在架构层面上的决策，如：采用分布式结构还是C/S结构，采用最新的还是成熟的技术，对和功能相关的安全性、人体工程学上的考虑2）用恰当的方法确定项目中各项工作的规模和复杂度，以便确定资源的需求应该用估算模型和历史数据来确定规模和复杂度。并且随着我们对产品特性理解的加深，我们对产品规模和复杂度的认识也会加深。用来确定规模和复杂度的方法包括：软件代码行或功能点的个数需求的个数和复杂度1.3确定项目的生命周期模型（即项目所采用软件开发过程）确定项目生命周期模型，也就确定了项目中计划进行评估和决策的周期和决策点，在这些决策点，我们会就下一步的资源投入以及技术路线的抉择达成一致的意见；并提供对项目进行修正的机会，以确定下一步工作的范围和需要投入的成本。项目生命周期模型的确定，取决于项目需求的范围、项目所需要资源的估计，以及项目本身的性质。大项目通常都会包括多个阶段，如概念挖掘、开发、生产、实施和部署；每个阶段还有可能包含子阶段。如开发阶段可包括需求分析、设计、编码、集成、验证等子阶段。通常要对一种或多种开发模型进行选择和提炼，才能确定项目阶段，主要是为了能体现出各阶段中项目活动相互之间的关系和顺序。根据开发策略的不同，我们可以选择的生命周期模型包括：瀑布型、原型法、增量模型和螺旋型等。对项目所采用生命周期模型的理解，能在很大程度上决定：制定项目计划的工作范围和项目初始计划完成的时间，以及项目计划调整的时间点和关键里程碑。1.4估算工作量和成本采用恰当的方法来估算项目中工作产品和任务的工作量和成本。工作量和成本的估算通常是通过使用估算模型或者参照历史数据对本项目的规模、项目活动和其他因素进行分析得出的。对这些估算的信心来自于选择的估算模型和历史数据是否恰当，是否在逻辑上合理。有时候会出现没有可用的历史数据信息，例如项目工作量巨大、前所未有，或者任务的类型不符合估算模型等等。如果开发的产品或组件是全新的，工作量在一定程度上是很难估计的。如果当前开发团队之前没有开发过类似的产品或组件，也很难估计工作量。难以估计工作量的工作就意味着更大的风险，需要更多的研究才能制定出合理的估算值，也要求在管理层面上给与更多的预留。在项目最初计划时，由于项目的独特性会做出一些假定，后续使用估算模型时要把项目的独特性记录下来，这样才能确保对这些假设和估算模型的使用达成一致的理解。（译者注：否则其他人就无法理解为什么看似项目有自己的独特性，还能使用通用的估算模型来进行估算）具体操作：1.通过选择好的估算模型和历史数据，把工作产品和任务的特性转换为工作量和成本的估算值已经有很多带有输入条件的估算模型可以辅助工作量和进度的估算。这些模型最好不要作为估算的唯一方式，因为这些模型所基于的历史数据有可能对你所在的项目是不适合的。使用多种估算模型和方法能保证估算结果的可信度。可以使用已经完成项目的历史数据，包括成本、工作量和进度等，再加上项目规模和复杂度等不同，乘以恰当的比例系数，来进行估算。2.在估算工作量和成本的时候，要考虑到项目所采用的基础支撑架构的情况基础支撑架构包括开发和未来产品维护所需要的资源，如开发环境、测试环境、生产环境、目标用户环境，以及上述环境的组合情况，这些都应在工作量和成本估算中予以考虑。（译者注：例如Linux/Unix上的编译调试等对于一般的开发团队而言，需要的工作量就会比Windows大）基础支撑架构的例子如下：关键的计算机资源，如内存、磁盘、网络带宽、外围设备、信息交流渠道等工程设计环境和工具，如原型工具、装配器、计算机辅助设计和模拟器等设施、机器和装备，如测试机床和记录设备3.使用模型和历史数据来估算工作量和成本用来进行工作量和成本估算的输入通常包括：采用专家或专家组的估算方法，如德尔菲法风险，包括难以估算的工作量的影响完成某项工作所需要的关键的人员和角色技术路线WBS工作分解工作产品的预计规模大小和预期的变更需要外部提供的产品的成本生命周期的成本估算在工程环境中用到的工具的容量（译者注：如项目只有唯一的一套联合调试环境，可同时供多少人并发使用，决定了缺陷解决的速度）管理者的技能水平，工作执行团队成员的技能水平知识、技能和培训的需要需要的设施，如办公室和会议室的空间和环境需要工程设施的需要制造过程的能力传输（译者注：可能是制造生成车间中加工品在生产线上的传输）任务、工作产品、硬件、软件、人员和工作环境的安全程度的需要符合呼叫服务中心和维修工作的要求（译者注：即可服务性需求）直接劳动和开销2制定项目计划项目计划的制定和维护是项目管理的基础。项目计划是正式的、被批准的文件，用来管理和控制项目的执行。项目计划的制定应基于项目需求和已经确定的项目估算。项目计划应该考虑到项目生命周期的所有阶段。应确保影响项目的所有领域计划都遵从于项目总体计划。2.1制定项目预算和进度表项目的预算和进度表是基于之前已完成的估算制定的，且在预算的分配、任务的复杂性、任务的依赖关系上都是经过了认真的考虑。在应对项目风险上，采用事件驱动型的进度安排在资源受限时被证明是行之有效的。事件驱动型指的是通过具体事情的开展来驱动项目进展，在某个事情启动之前要先明确要达到的效果，这样时间安排上更为灵活，也容易对具体事情的期望达成一致的理解，便于更好的了解项目当前的整体状态和项目中各项任务更为精确的状态。具体操作：1确定主要里程碑我们常常通过制定里程碑来确保在里程碑时特定的交付件能完成。里程碑可以基于事件或者基于日期来制定。如果基于日期来制定，一旦对里程碑的时间达成一致，通常就很难再改变。2确定进度安排的假定条件当一开始制定进度表时，通常都会对一些活动所需要花费的时间周期进行一些假设。尤其是当很少有估算数据能提供明确的信息时，经常会设定一些假设条件来便于进行时间估算。明确出这些假定条件，我们才能洞察整个进度表的不确定程度。3识别约束条件应尽可能早的识别出限制工作开展方式上灵活性的因素。通常考察工作产品和任务的属性（包括任务的持续时间、资源需要、输入和输出等）能把这些问题带出水面。4识别任务的依赖关系项目的任务通常可以按照一定的次序来排列，可使得项目的周期最短。这就需要识别一个任务的前置任务和后续任务，以便能优化工作次序。能够帮助决定任务活动优化次序的工具包括：关键路径法PERT法（程序评价和评审技术）资源受限的进度安排5确定预算和进度表制定和维护项目预算和进度表，通常包括以下任务：明确已经得到承诺的或者预期可提供的资源和设施把项目中的活动划分到各个阶段中确定各个子进度表的起至时间明确各项活动之间的依赖关系（前置关系或者后续关系）明确和活动的进度表以及里程碑，保证过程度量的精确性识别要把产品交付给客户的里程碑时间点确定每项活动恰当的持续时间确定里程碑的恰当时间划分根据汇总后的进度安排和预算的可信度，定义出管理上的预留使用恰当的历史数据来校验进度表记录项目的假定条件和基本原则6建立纠正措施触发的标准要制定一个触发标准，决定什么是项目计划的显著偏差；当偏差达到触发标准，就必须采取纠正措施来解决问题。为了能知道何时应采取纠正措施，有必要对事情和问题进行计量。纠正措施可以要求重新计划，包括修订原始计划达成新的一致，或者在当前计划内降低对部分活动的要求等。2.2识别项目风险可参考“风险管理”部分和“项目监控”的“监控项目风险”了解风险管理活动的更多信息。为了支持项目计划是现实可行的，我们有必要识别和分析项目中存在的风险。项目中制定各领域计划时，都应进行风险管理，并确保对风险的相关干系人进行了恰当的沟通。项目计划的风险识别、分析通常包括以下内容：识别风险分析风险以确定风险的影响程度、发生的概率，以及问题可能发生的时间段对风险进行优先级排序具体操作：1，识别风险进行风险的识别可以从潜在问题、危险、威胁、弱点以及诸如此类会对工作成果和计划产生负面影响的东西出发来发掘。识别出风险，并用大家都能理解的方式进行描述风险，以便于进行风险的分析。在识别风险的过程中，使用一种标准的方法来定义风险是一个好主意。风险识别和分析工具能提供一些帮助。风险识别和分析工具的例子如下：风险的分类体系风险的评价检查列表结构化的评审头脑风暴工作情况模型成本模型网络分析质量因素分析2，把风险记录到文档中3，和相关干系人回顾风险，并在对风险的处理上取得一致的意见4，进行恰当的风险修订已经识别的风险在下列时候需要被修订：当新的风险被识别时当风险转换为问题时当风险消除时当项目情况发生显著变化时2.3制定资料管理计划这里所讲的“资料”指的是各种类型的、用来在某领域内发挥作用的文件；领域可以包括：管理、工程、配置管理、金融、后勤、质量、安全、制造和采购等。资料的外在形式可以是任意的，包括：报告、手册、笔记、图表、图形、说明书、文件或者信件等。资料可以存储在任意介质上，既可以是打印出来的，也可以是在不同材料上绘制的，还包括照片、电子或者多媒体形式的。资料可以是需交付给客户的，如在项目合同中要求的内容，也可以是无需交付的，如非正式的文档、商务研究和分析、内部会议记录、内部设计评审文档、经验教训和行动项等。资料的分发也可以采取多种形式，包括物理介质的或电子方式的传输。项目的资料需求既要考虑要生成的资料的内容，也要考虑它的形式；应基于共同的资料需求标准。对于资料条目统一的目录和格式要求有助于促进对于资料内容的理解，以及对于资料资源的一致性管理。收集资料这项任务包括对于项目中交付件和非交付件的分析和确认，合同内外的资料需求的确认，以及客户提供的资料等。我们对于收集每一个文档的原因应该很清晰，通常存在的问题是：收集资料时并没有对如何使用这些资料有清晰的认识。资料的编写制作是昂贵的，应该只在需要时才制作并收集资料。具体操作：1，明确对资料的需求和访问程序以确保资料的隐私和安全不是每一个人有访问项目资料的明确需要。必须建立一定的程序来识别谁、在哪些时候有访问哪些资料的权限。2，建立一个机制能对资料进行存档管理，并且能访问到存档的资料被访问的资料应该以一种能理解的形式来展现，例如电子的或数据库的输出，或者以原始产生的形式展现。3，确定需要被识别、收集和发布的项目资料2.4制定项目资源计划在最初估计的基础上，确定项目对各类资源（包括劳动力、机器设备、原料等）的需要，并确定所需要的数量，通过扩展WBS能获得更为准确的数据。高层WBS的制定在早期通常作为估算工具，之后再扩展WBS，即把这些高层WBS再分解为工作包，每个工作包代表这一个独立的工作单元，也就是每个工作包都是能被独立分派的任务，并可执行和追踪。这种分解方法可以用来分解管理职责，并提供更好的管理上的控制。WBS中的每个工作包或工作产品都应有一个唯一的标识码（如数字），以便可以追踪。一个WBS可以基于需求、项目活动、工作产品或者这些内容的组合而制定出来。每个WBS都应该配备字典来描述其工作包中工作内容的含义。具体操作：1，确定对软件开发过程的要求应事先确定好用来管理项目的过程，并与所有相关干系人进行协调，以确保在项目执行过程中能高效的运作。2，确定人员需求在把项目需求分解为WBS的工作包后，通过工作包中所列出的任务、角色、责任，来确定项目需要哪些人员。人员需求必须考虑对每一个已经明确的岗位所需要的知识和技能，这些应在“需要的知识和技能计划”中定义。3，确定设施、设备等的需求通常而言，大多数项目都是独特的，需要一些独特的资源才能达成项目目标。及时的确定和获取这些资源对项目的成功非常关键。必须提前明了所需要的资源从订货到交货的时间，以便确定这些资源何时能到位。即便这些需要的资产不是独特的时，整理一个所需要的设施、设备、个人用机、软件、办公场地等需求的列表，能明确在这些方面需要投入的工作，防止被遗忘。2.5制定知识和技能的计划可以参考“组织培训”来了解更多的、项目计划中的关于知识和技能方面的内容。项目获得所需要的知识包括对项目成员进行培训和从项目外部获取两个途径。项目对人员的需求依赖于完成项目的所需要的知识和技能。（译者注：即完成项目需要一定的知识和技能，而项目所需要的人应具备这些知识和技能）具体操作：1，明确完成项目需要什么样的知识和技能2，评估目前项目已有的知识和技能3，选择获取所需要的知识和技能的方式可选择的方式包括：内部培训，包括组织提供的和项目自己提供的外部培训雇佣掌握这些知识和技能的员工从外部获取（译者注：例如请专家作为顾问指点等）选择内部培训还是外部培训来获取项目所需要的知识和技能，取决于如何确定培训老师、项目的进度安排，以及商业目的。4，把已经选定的方式纳入项目计划2.6计划项目干系人的参与我们可以从项目生命周期的各个阶段中认识到和项目相关的干系人（风险承担人），方法是：辨别需要介入项目的各类人员及职能，并描述他们同项目中具体活动的关系和相互作用的程度。可以用一个二维矩阵，一个轴表示干系人，另一轴表示项目活动，来表示干系人与项目活动之间的关联。干系人和项目阶段中具体活动的关联，通过项目活动轴和干系人轴的交叉处就体现出来了。为了使干系人的输入信息有效，我们有必要认真的选择项目干系人。对于每个主要活动，都需要识别出会受这项活动影响的人，以及有完成这项任务所需要的专门技能人来作为干系人。干系人列表可随着项目阶段的发展而改变。但是，确保在项目后期才介入的干系人对于会影响他们的需求和设计决策在早期有发言权，是非常重要的。通常在干系人介入计划中包含的材料类型有：所有相关干系人的列表干系人介入的理由相关干系人对于项目而言，在项目生命周期中的角色和职责干系人之间的关系对于项目成功而言，干系人的相对重要性确保干系人能有效参与的资源，如培训、时间和资金干系人参与分阶段的日程安排2.7完成项目计划为了能形成对项目的一致认识，达成共同承诺，并可衡量参加和支撑项目的个人、团队和组织的绩效，制定一份内容全面的书面文档是必不可少的。项目计划应包括各个项目各方面的内容，并把这些方面有机的连接在一起；具体包括：对项目生命周期的考虑，关键技术要素，管理组织结构，预算和进度表，里程碑定义，资料管理计划，风险管理，资源和技能需求，项目干系人参与计划。组织结构这部分的内容包括项目成员、管理层和支撑组织之间的责任和职权划分。对于软件工程，计划文本通常指的是下列的一个：软件开发计划软件项目计划软件计划3取得对计划的承诺建立并维护对项目计划的承诺为了使项目计划有效，制定的项目计划需要取得执行和支撑计划的责任人的承诺。3.1审查项目中的各领域计划审查影响项目中的各领域计划，以了解项目承诺。项目各领域中的计划（译者注：如质量保证计划、培训计划、风险管理计划等）是项目总体计划中的总体策略在各自职能领域的扩展，领域计划提供了各领域内的详细指导，并和项目总体计划保持一致，以明晰在不同职能领域的职权、责任和控制情况。这些对项目有影响的所有计划都应被审查以确保各领域计划对于项目成功所必须的范围、目标、角色和关系的理解能取得共识。3.2对项目中工作负荷与可提供的资源进行平衡为了使项目具备可行性，需要从相关干系人获得资源承诺，并在估计需要的资源和可获得资源之间的困难进行平衡和协调。通常可以通过以下方式取得协调一致：降低或推迟技术性能要求，商谈取得更多资源，发现提高生产力的方法，外包，提高项目成员的技能，修订影响项目或进度的领域计划。3.3取得项目所需要的承诺从各负责执行项目和支持项目的相关干系人处取得承诺。同所有项目干系人，包括项目内部和外部进行互动交流以取得对项目的承诺。做出承诺的个人或团队应该有信心：工作可以在成本、进度和绩效要求内完成。通常，可以给与一个临时的承诺以便让工作先开始进行一些探索以提高信心直到给与一个正式的承诺。具体操作：1，识别需要的支持，并同相关干系人谈判以取得承诺WBS能够被用来作为检查列表以确保所有任务都取得了承诺。“项目干系人参与”计划应识别出：承诺应该从哪些人获得。2，所有的组织承诺，包括正式的和非正式的，都应形成文字，并有相应级别的人签署承诺形成文字，才能确保大家相互理解一致，并可以追溯和维系。非正式的承诺应该被作为风险管理起来（因为它不兑现的概率比较高）。3，同相应级别的高层管理者审查内部的承诺4，同相应级别的高层管理者审查外