lm2new项目计划,WBS

2创建项目计划2.1项目计划与范围管理2.2MicrosoftProject制定项目计划的流程2.3定义项目的基本信息2.4创建项目任务分解结构(WBS)2.5建立任务的链接关系2.6完善项目计划创建项目计划创建项目计划是项目管理的第一步,几乎项目管理的所有环节、内容都与项目计划密切相关在MicrosoftProject的帮助下，管理者创建项目计划的工作将会变得更加得心应手2.1项目计划与范围管理项目管理者可能会有过这种经历：一个项目做了很久，却感觉总也做不完，就像一个“无底洞”。实际上，这主要是项目的“范围管理”没有到位。项目的范围管理主要在项目计划中体现出来，在制定和执行项目计划时又必须以范围管理为指导。因此在使用MicrosoftProject编制项目计划之前，必须先对范围管理有初步了解。2.1.1关于“范围”在项目中，我们必须知道客户需要什么、项目最终要做什么，这是项目成功的基础。这就是所谓的“范围”。通常先确定产品的范围、再确定项目的范围。范围管理要防止两方面失误：该做的工作没有完成，或者没有按照预定的要求完成，可以概括为“漏做”和“少做”，其中也应包含“错做”的情况。不该做的工作进入了项目范畴，可以概括为“多做”。2.1.2范围管理的过程与项目管理过程相对应，范围管理包括如下几个过程：启动、范围计划、范围分解定义、范围核实与范围变更控制2.1.2范围管理的过程1．启动项目的启动阶段是项目管理的第一个过程，主要回答下面两个根本问题：项目要做什么？项目是否值得去做？以下是启动过程中较为关键的几个环节：（1）确定详细的项目需求——首先要确定最终产品或服务的具体特征，即产品描述，再确定项目的需求。通常产品需求与项目需求是基本一致的。2.1.2范围管理的过程（2）项目章程：启动阶段的主要输出。项目章程要从总体上对项目的目标、范围做出界定，后续的项目计划都是根据项目章程确定的。项目章程应包含如下几个部分：项目的背景说明：包括机会与机遇的说明。项目目标：产品/服务描述。商业需求：为什么要做这个项目。项目可用的资源2.1.2范围管理的过程（3）项目约束与条件，例如：工期限制、预算要求、资源的限制、产品必须满足的技术标准等。（4）项目团队：包括项目经理和项目成员。2.1.2范围管理的过程编制范围计划就是将项目范围（即项目工作内容）渐进明确和归档的过程。这一过程需要参考很多信息，比如产品描述、项目章程、项目合同等。通常业主和项目管理者已经对项目范围有了初步的约定，然后再在此基础上进一步深入和细化，输出范围管理计划、范围说明（如下图）。2.1.2范围管理的过程2．范围计划本阶段的输出包含如下内容：范围说明：当项目干系人对项目范围达成共识时，将它编制成范围说明，作为未来决策的基础。范围说明中至少要说明项目论证、项目产品、项目可交付成果和项目目标。项目可交付成果一般要列一个子产品概括表，例如一个软件开发项目的可交付成果可能包括：程序代码、工作手册、人机交互学习程序等。范围管理计划：描述项目范围如何管理。它应包括项目范围变化的预期（比如范围可能如何变化、变化频率如何、变化了多少），如何确定范围发生了变化，变化的种类等。2.1.2范围管理的过程3．范围分解定义由于项目往往是一个复杂的过程，只有范围说明和范围管理计划还离项目实施有一定距离，需要采取分解任务的手段把项目任务分成更容易管理的单元，最终得出项目的工作分解结构（WorkBreakdownStructure，简称WBS）。WBS对项目成功十分关键，是指导项目实践的重要依据。编制项目的WBS通常有3种方法：按照项目生命周期分解、按照产品功能分解和按照组织职能分解。2.1.2范围管理的过程【例】软件开发项目的WBS（按照项目生命周期分解）软件工程学认为软件具有明确的生命周期，软件要按照一定程序开发，分别是：需求分析、系统分析与设计、编码与实现、软件测试和使用维护共5个阶段。2.1.2范围管理的过程【例】研制手机项目的WBS（按照产品功能分解）根据产品的功能将项目的内容由粗到细逐步分解、细化，形成WBS。在研制手机的项目中，将最终产品——手机从功能上划分成几组大的部件，最后再集成起来。这样原来一个大而复杂的问题就划分成若干个小问题。然后针对每个部件，分别提出解决方案（可能是多个方案，从中选择一个），最好再将所有部件集成到一起。【例】商业住宅开发项目的WBS（按照组织职能分解）根据公司内部的职能部门（有时也会根据地域），将项目任务逐步分解细化、形成WBS。住宅项目是多工种协作的系统工程，要涉及到房屋设计、土建、设备、材料供应等多方单位。虽然每一方都有必要组织项目管理，但作为项目的发起人和投资者，开发商的项目管理才是整个项目管理的核心，它必须协调所有部门和单位的行动，保证各方始终朝着既定的项目目标前进而不能偏离。4．范围核实范围核实是取得项目干系人（客户、投资人、公司领导等）对项目范围正式认可的过程。范围核实过程要求项目组成员核查项目范围、可交付成果，其他干系人（如客户）核查最终产品，确保提交的项目成果正确无误且令人满意，核查的重点是对工作结果是否认可。如果项目提前终止，则范围核实过程还应确认与记载项目已经完成的水平与程度。5．范围变更在制定项目计划时，管理者对项目的外部环境有一个预期或估计。但在项目实施过程中，环境总是不断变化的。所以，即使一个项目的计划制订的再完善，也难免会遇到意想不到的情况（例如，客户需求的变化、可用资源的减少、资源市场价格的变化等等）。范围变更在项目实施过程中是在所难免的。项目管理者必须通过有效的监督和分析预测及时发现变更，并提出解决方案。范围变更会使项目风险增加，所以在项目管理体系中，必须包含一套严格、高效的变更管理程序，这对项目的成功与否至关重要。2.2MicrosoftProject制定项目计划的流程2.2.1流程概述MicrosoftProject的向导功能提供了非常详细、系统的管理流程，供用户参考。制定项目计划主要和项目向导中的“任务向导”相关。单击向导工具栏的任务按钮，出现任务向导窗口，其中列出了制定项目计划的详细步骤Project制定项目计划的流程1．定义项目制定项目计划的第一步工作不应是录入任务，而是定义项目。首先，定义项目的基本信息，包括项目预计开始日期、项目组协作方式及其它附加信息。其次，定义项目的常规工作时间，就是明确哪些是工作时间、哪些是休息时间。用户可以选择一个模板日历作为项目的常规工作时间，也可以根据实际情况自定义工作时间。另外还包括设置节假日和倒休、定义时间单位换算关系。然后，定义项目的其它基本信息，例如：项目日程的排定方式（工作日程是从前往后排、还是从后往前倒推）、任务优先级设定等。以上定义的是项目最基本的信息，对后续工作影响重大。改变了这些内容，会对项目任务和执行产生根本性的影响，所以必须在项目一开始就确定下来。2．创建WBS（任务分解结构）定义好项目的基本信息后，可以开始创建项目的WBS。规划WBS要遵循由粗到精的原逐步进行：第1步，列出项目各阶段的主要任务，再将粗线条的阶段任务细化为详细的分解任务。如果有必要，还可对详细任务继续分解，直至满足实际需求。创建WBS不是一次便能成功的，往往需要反复修改和不断完善。这步完成后，得到的是一个包含所有项目任务的任务列表，但此时所有任务不分级别，也没有先后次序和依赖关系。第2步，将任务按照阶段，设定好从属关系和任务级别，形成一个分阶段和级别、有层次的任务列表。第3步，设置任务的链接关系。3．完善项目计划初步的项目计划往往还需要润色和完善。例如，部分任务包含附加的说明信息或者相关的重要文档，能否将这些信息整合到项目计划中有序管理呢？有些任务具有期限的限制，如何在项目计划中体现出来呢？另外，还需对项目风险作出预测，把风险信息整合到计划中，以便日后进行风险管理。经过修改和润色，项目计划确定以后，应该保存为比较基准。因为这份项目计划就是以后项目实施的蓝图，以后还要将实施状况记录到计划中来，并经常对比计划和实际的差异，发现实施过程中的问题。4．发布项目计划项目计划一旦确定之后，就应以合适的渠道发布给项目干系人（如项目团队、客户、公司领导等）。发布的形式多种多样，可以通过可以电子邮件、计划文档形式发布，也可发布到MicrosoftProjectServer上。2.3定义项目的基本信息2.3.1定义项目保证“任务向导”窗口处于打开状态，单击第一条超链接“定义项目”，进入“定义项目”向导。该向导共分3步，主要内容是定义项目的开始时间和设置项目协作方式。在向导窗口的底部，显示有向导共有几步、当前处于第几步的提示信息，还有前往下一步和退往前一步的超链接。在向导窗口的主体部分，除了有帮助客户完成本步操作的输入框和选择框外，还有关于操作的提示信息。第1步，定义项目的估计开始日期。输入框内默认显示的是系统的当前日期，用户可以点击右侧的向下三角按钮，选择需要的项目开始日期2.3.1定义项目第2步，定义项目工作组。用户选择当前项目文件是否要使用ProjectServer和ProjectWebAccess。如果选择“是”，用户就能够在ProjectServer上发布、查看、更新项目信息，便于项目成员和其他干系人进行协作。如果选择“否”，则意味着用户暂时不与ProjectServer相连，如果用户以后需要使用ProjectServer，可以在“跟踪向导”的“准备跟踪项目进度”中设置。选择“是”与“否”要考虑如下因素：首先，是否存在已经搭建好的ProjectServer，包括硬件环境（服务器、局域网）和软件环境（服务器上要安装好ProjectServer，并做好相应配置）。其次，还要考虑项目是否有必要使用ProjectServer。例如有的小型项目管理人员很少，只有项目经理制定、修改、更新项目计划，其它人只要查看项目计划，这时就没有必要设置ProjectServer。另外，项目组成员的协作方式并非只有ProjectServer一条，我们还可以选择其它途径，例如电子邮件，项目文件拷贝等。2.3.1定义项目第3步，输入附加信息，这一步没有什么实质性的操作，用户可以直接单击窗口底部的“保存并完成”完成项目定义。2.3.2定义常规工作时间完成了“任务向导”的第一项工作——“定义项目”之后，按照任务向导的安排，接下来就该“定义常规工作时间”。单击向导窗口中这项任务，进入“定义常规工作时间”向导.该向导共分5步，它的功能是帮助用户完成项目工作日历的设置。例如，有些单位遵循周一至周五上班、周六周日休息的制度，也有的单位是每周工作5天半。此外各个单位和项目中关于节假日、倒休的规定都不一样。所以要为项目量身定做一套工作日历。2.3.2定义常规工作时间第1步，定义项目的常规工作时间。为你的任务选择一个日历模板。Project为了方便用户设置项目工作时间，提供了4种常用的日历模板，分别是：标准、行政日历、24小时和夜班。这4种日历都是以工作周为单位设定的。用户可以直接选用这4种日历，也可以在它们的基础上做适当修改。这里用户可以根据项目的实际情况选择一种最相近的模板作为底板，再对它加以修改。2.3.2定义常规工作时间日历模板每周工作时间节假日适用情况标准周一至周五为工作日，每天工作时间为8:00－12:00,13:00－17:00(中午休息1小时)；周六、周日休息无一般单位的人员、设备（有时需要修改每天工作时间和节假日）行政周一至周五为工作日，每天工作时间为8:00－12:00,13:00－17:00(中午休息1小时)；周六、周日休息（同“标准”日历）国家法定假日休息，例如：五一节、国庆节、春节休息3天（不含周末）一般单位的人员、设备（有时需要修改每天工作时间）24小时一周工作7天，每天工作24小时无需要24小时流水作业的机械设备夜班周二至周六为工作日，每天工作时间为0:00－3:00,4:00