项目计划模版<br />（项目名称）<br />项目综合计划 <br />（项目经理姓名和/或关键小组成员）<br />修改号：<br />修改日期：<br />编写人：<br />日期：<br />审批人：<br />日期：<br />审批人：<br />日期：<br />修改号：<br />修改日期：<br />编写人：<br />日期：<br />审批人：<br />日期：<br />审批人：<br />日期：<br /><br />项目计划大纲<br />1.0 引言<br />作为项目起源的问题/机会陈述。<br />2.0 项目概述和章程<br />此处包括项目的总体描述。即关键目标、长度，以及主要的风险和收益。还包括一个项目章程。项目章程规定了项目的目的、影响说明书和与外部组织的接口。<br />3.0 目标和目的<br />项目目标和目的应该包括项目成功应该满足的可衡量标准（成本、进度和质量）。<br />初步的项目成本/收益分析（ROI、NPV、回收期等等）的结果，当存在时，应该被包含在此章中。本章所描述的目标和目的将用来：<br />● 指导项目执行，记录项目计划编制的假定，以及有关项目方案的选择决策。<br />● 促进干系人之间的沟通，协助关键的管理审查。<br />● 提供项目进展衡量和项目控制的基线。<br />4.0 工作分解结构<br />工作分解结构（WBS）是以可交付成果为导向的项目元素的分组，它组织和定义了项目的总体范围。它用来建立或确认对范围的共同的理解，层次越低，对项目元素的描述越详细。WBS的每一细目都被分配了独特的编码，并且在WBS字典可以描述每个控制帐户；即分配给单个组织/个人的，用来管理范围、进度和成本的可管理的工作块。它的编码方式还可以包括成本帐户结构。<br />5.0 工作说明和范围要求<br />● 范围说明，（有时被称为工作说明（SOW））,是对已知的整体工作范围的叙述性描述，它因该反映成功完成项目所必需的所有工作。<br />● 范围说明应该使用与工作分解结构相同的结构，由段落和子段落组成。范围说明通常是写在WBS的高层和/或中层；如控制帐户及其以上的层次。<br />● 特征和功能要求应该加以明确规定，因为他们定义了项目应该包括和不应该包括的内容。<br />● 范围说明或工作说明的编写使干系人对于项目范围有了共同的理解。它应该包括：<br />A. 项目产品－产品描述摘要<br />B. 项目可交付成果－将项目范围的主要部分分为更小的更好管理的部分。可能时应该规定排除在可交付成果之外的情况。<br />6.0 进度<br />这一章描述了保证项目及时完成的进度过程。以下时对项目进度计划编制主要过程的概述。<br />● 活动/任务/子任务定义－识别出得到项目各种可交付成果所需的具体活动。还识别出与项目进展和结果相关的主要里程碑。<br />● 活动/任务/子任务排序－识别活动间的依赖关系、关键可交付成果和约束条件。<br />● 活动/任务/子任务历时－估算完成每个活动所需的历时。<br />● 进度计划编制－分析所收集的数据，将数据输入进度计划，分析活动顺序、历时和资源要求。<br />7.0 项目人员安排<br />利用范围说明或工作说明（SOW）以及项目工作分解结构识别必需的技能，应该选择和通过谈判获得人员组成一个项目小组，从而能够完成项目范围中的具体任务和子任务。项目小组的结构应该与项目WBS的结构匹配，采取职责矩阵的形式。项目职责矩阵应该记录小组的职责和任务。<br />8.0 预算/资源要求<br />预算/资源要求包括了四个主要过程，以保证项目在批准的预算内完成。这些过程共同建立和维持了一个综合的项目范围、进度和成本基线（也成为成本基线）。这一基线应该包括在本章节当中。<br />成本预算-考虑了各种成本核算选择方案之后做出的对完成工作所需的资源成本的估算。<br />成本预算-以工作范围为基础，将成本总估算分配给个别的工作细目，从而建立项目成本基线。而此项目成本基线将用来衡量和监测成本绩效。<br />资源计划编制-确定完成工作所需的资源，包括编制规定团体成员的职责的职责分配矩阵，目的是，并且建立项目的必要沟通网络。<br />成本控制=这包括控制改变项目成本基线（综合的范围、进度、成本基线）的因素的行为。此部分应该包括对项目所运用的挣值管理技术的描述。<br />9.0 假定<br />在所有领域，特别是不存在明确定义的领域，必须设定和使用假定。一个假定的成败对其在项目中目前的未来的运用是至关重要的，假定应该在整个初期计划阶段被规定，并记录在本部分当中，用于所有的范围/质量、成本和进度计划。<br />对假定的详细记录包括识别与项目计划所有组成相对应的假定。项目控制账户的关键假定可以记录在wbs字典中。其他假定应该随着所有其他范围<br />质量、进度和成本计划的编制加以记录。<br />10.0风险<br />风险管理包括在项目全过程中管理风险所使用的程序。本部分将对下列主要过程进行概述。<br />风险管理计划编制-重点是编制风险管理计划。<br />风险识别-可能影响项目的风险。<br />风险评估-评价风险和风险的相互作用，从而评估可能的后果。必要时同时使用定性和定量的分析方法。<br />风险应对计划编制-定义把握计划的步骤和应对威胁的方法，包括具体的应对选择方案和行动界限。<br />风险监测/控制-跟踪风险和风险的影响，跟踪缓解计划的编制和执行产生的影响，寻找新的风险。参见以下的11.0<br />风险分析工作表的作用是纪录风险识别、定性分析、应对措施和控制/报告。<br /><br />11.0项目报告和控制<br />报告-再项目整个生命周期中，应该定期对项目成本、进度和技术绩效进行报告。这应该包括有报告内容的规定，如分发列表、管理审查和纠正措施。经常性的项目审查会议也应加以计划，并包括在本章当中。<br />控制-对项目状况的管理审查、缓解项目绩效问题的纠正措施计划编制和实施。控制的重点应该是如下四个领域：<br />工作范围和技术应用-评价正在完成的工作是否符合经批准的项目范围，并且评价相关技术是否满足项目目标。本部分应该记录挣值管理技术的方法和应用。<br />成本控制-按照项目基线监测项目进度绩效，以保证以最低成本完成经批准的项目范围。<br />进度控制-按照项目基线监测项目进度绩效，以保证及时完成。<br />风险应对控制-评价个别的绩效问题如何影响项目的所有目标：范围、进度和成本。必要时进行综合的风险缓解跟踪。参见以上的10.0。<br />12.0变更控制<br />全面的变更控制包括（a）影响导致变更的因素：(<!--emo&B)--><img src='style_emoticons/default/cool.gif' border='0' style='vertical-align:middle' alt='cool.gif' /><!--endemo-->确定变更是否发生；（c）变更发生时管理变更。这要求：<br />维持健全的绩效测量基线。<br />保证产品范围的变更被包含并且反映在项目范围定义中。变更指令日志是纪录所有变更申请处理情况的文档。<br />协调跨知识领域的变更。（进度变更常常影响成本、风险、质量和人员安排）<br />保证对项目基线变更进行明确的变更识别，管理审批，和正式实施。<br />13.0约束条件<br />约束条件对项目可能产生正面或者负面的影响。在尽可能的情况下，每个项目都要识别约束条件（内部或者外部），约束条件的类型可能包括（还有其他泪向）：<br />项目里程碑<br />资源可得性<br />交付日期<br />监管机构或法律问题<br />14.0 沟通计划编制<br />项目沟通计划编制包括保证项目信息及时并且适当地生成、收集、散布、储存和最终处理所必需的过程。它是项目成功所必需的人员、想法和信息之间的关键连接。此处应该适当的记录并且由项目经理及其小组遵循的主要过程如下。<br />沟通计划编制－－确定干系人的信息和沟通需求：睡需要什么信息；他们何时需要；如何将信息传达给他们。应该包括所有重复进行的项目会议计划编制。<br />信息分发－－使项目干系人及时获得所需信息。<br />绩效报告－－收集和散布绩效信息。这包括状态报告、进展衡量和预测。适当参考本项目计划的11.0、17.0和其他有关章节。<br />管理收尾－－生成、收集和散布信息，从而正是结束项目阶段或项目。<br />15.0 质量计划编制<br />项目质量计划编制包括保证项目满足其预定需求所必需的过程。这包括确定质量政策、目标和责任的所有活动。<br />此处应该适当记录并且由项目经理及其小组所遵循的主要过程如下。<br />质量计划编制－－识别与项目相关的质量标准并且确定如何满足这些标准。<br />质量保证－－定期评价项目总体绩效，从而保证项目将满足相关的质量标准。<br />质量控制－－检测具体项目结果，从而确定它们是否符合相关质量标准，并且设法消除造成不满意绩效的原因。<br />16.0 合同和采购计划编制<br />项目合同和采购计划编制包括从执行组织外部获取货物和服务所必需的过程。这些货物和服务，或“产品”，是通过六个过程获取的。<br />此处应该适当记录并且由项目经理及其小组所遵循的主要过程如下。<br />合同采购/计划编制－确定采购什么，何时采购，包括需提前很长时间定购的货品。<br />询价计划编制－记录产品要求和识别潜在供方。<br />询价－获取适当的报价、出价、发盘或建议书。<br />供方选择－从潜在卖方中选择。<br />合同/采购管理－管理与卖方的关系。<br />合同/采购收尾－合同/采购的完成和解决，包括任何未决事项的解决。<br />可能的话，主要的分包商、咨询顾问和供应商应该在此或在本计划的第7.0章确定。<br />17.0项目完成<br />在项目生命周期的早期阶段做好项目完成计划将保证所有必要的项目完成可交付成果被捕捉。这些可交付成果可以作为未来项目的参考和/或用于审计目的。<br />项目完成可交付成果可以包括，但不局限于，如下内容：<br />可交付成果 初期 末期 所有<br />项目计划 x x <br />工作范围 x x <br />估算e x x <br />成本文件s x x <br />变更指令申请 x<br />进度 x x <br />月度状态报告 x<br />工程设计图纸 x <br />规格 x <br />可交付成果摘要 x<br />项目文档索引和关键项目函件，以及外部文档 x<br />经验教训 x<br />其它项目细节 <br />变更指令日志 x x <br />又见有关项目沟通计划编制的第14.0章的管理收尾，作为相互参照。<br />18.0附属的与项目相关的计划<br />范围计划<br />进度计划<br />成本计划<br />质量计划<br />人员获取计划<br />沟通计划<br />风险管理计划<br />风险应对计划<br />采购计划<br />其它计划可能也属于项目计划编制，这取决与项目的需求以及客户和项目母公司的政策。

讲的不错，但除WBS外，还有CWBS（即合同WBS），能否说说两者之间的关系？<br />另外，WBS的分解不是一次到底的，通常只分解到3－5级，请问分解详细程度的依据和方法是什么？

占个位先 <!--emo&:D--><img src='style_emoticons/default/laugh.gif' border='0' style='vertical-align:middle' alt='laugh.gif' /><!--endemo-->

学习。。。。

<!--QuoteBegin-无双+2004-09-16 01:04:36--><div class='quotetop'>QUOTE(无双 @ 2004-09-16 01:04:36)</div><div class='quotemain'><!--QuoteEBegin-->占个位先 <!--emo&:D--><img src='style_emoticons/default/laugh.gif' border='0' style='vertical-align:middle' alt='laugh.gif' /><!--endemo--><br />[right][snapback]389562[/snapback][/right]<br /><!--QuoteEnd--></div><!--QuoteEEnd--><br /><!--emo&:o--><img src='style_emoticons/default/ohmy.gif' border='0' style='vertical-align:middle' alt='ohmy.gif' /><!--endemo-->  占位干吗？ 偶等着你讲呢~

怎么没人回答？

合同的东西我没见过<br />也无法具体说了  可能对于外包中比较正式的会使用到这样的合同吧<br /><br />下面是google到的结果<br /><br />契约性的WBS（CWBS），它是用于界定销售者提供给购买者的产品报告级别的。通常CWBS包括的内容要比WBS的少，它用于卖方管理买方的工作环境中。<br /><br />下面这篇文章介绍的不错<br /><br /><a href='http://www.leadge.com/PMknowledgedatabase/knowledgearea/pmbok5.3.htm' target='_blank'>http://www.leadge.com/PMknowledgedatabase/...ea/pmbok5.3.htm</a><br /><br /><br />这些合同主要是确定目标与项目进展 <br />但是 以前呆的公司 在项目进展这方面 都是由自己公司内部决定的 也就是 只保证最后的结果 而不保证中间的过程 足间到什么阶段完成什么模块这并不要求 <br /><br />自己感觉这样的更适合那些建筑项目 <br /><br />软件项目开发过程中 每一个模块都紧密关联 修改一个模块其它的模块都会受到影响 <br />这样 可能其中一个模块的bug 或是功能的完善 会影响到其它的模块 <br /><br />所以 觉得这种不是很合适

感谢楼上提供的资料。<br />本人初识项目管理，有说的不对的地方还请大家指点迷津。<br />就个人感觉，“CWBS用于买方管理卖方的工作环境”是不是更合适一些？<br />而且，这里的买卖双方倒不一定必然指公司内外，展开一个项目过程中，外包是一方面，与内部的IPT组之间也可以逐级的签订开发合同，这样可以更好的进行绩效的管理。<br />软件项目的开发过程中，如果同级的每一个模块之间关联得太紧密，可能这样的分解本身就是不合理的（或者说是开发方式不合理？），应该从顶层开始就尽量按照模块化的方式进行分解，避免模块之间过于复杂的关系。模块之间的关联关系有时是不可避免的，这时就要控制好模块之间的接口（定义ICD－－接口控制文件）。<br />项目工作的分解其实在很大程度上是对需求的逐级分解，大的软件开发要有需求管理（DOORS/ERS是国外用的比较多的需求管理软件，可惜国内用的好像不多）。一个项目的工作最基本的目的说白了就是满足客户的需求，如果一个工作的目的不是服务于项目最终能满足用户的需求，不能起到提高用户满意度的作用，那么这项工作就不要有，这样可以更好的控制项目的成本。客户的需求也不是提一个就必须满足一个，大的关键的需求一定要满足，细节的需求就要论证其合理性和开发难度（这样同时既能提高用户的水平和满意度，也能控制项目成本）。需求管理中对需求的更改要有更改控制，在进行每一项更改批准前都要衡量满足此需求的必要性和成本增加量，好的需求管理可以尽量减小开发过程中成本膨胀。<br />讲了这么多需求管理，只是觉得需求管理和WBS分解是密切相关的。有什么错误，欢迎指正。

避免模块之间过于复杂的关系<br />理论上是这个样子的 但事实上 软件设计一开始时需求就不很明确 <br />很多问题都是在开发的过程中才发现 或是模块或结构需要重改 <br />所以 才提出很多种软件工程理论 如XP方法<br /><br />所以对于软件设计中 只要求最后的产品规格与功能就可以 具体的中间的实现难以细化 这应该是开发详自己的事情<br /><br />也就是 双方只需要明确客户的需求 然后提供出这样的系统 而系统的什么实现 对客户来说 签合同的时候可能并不知道<br /><br />当然我没有这方面经验 可能会误导你

谈谈我的看法，不一定对，还望指教，其实我的经验也很浅。<br />单从自身来讲：面对客户时，应该将客户的需求进行逐级的分解，同时分解好自己的工作；对于需要外包的工作，只要定义好自己对承包商的要求就可以了，具体的需求和工作的分解自然是承包商自己的事情。在这里，对于内部IPT和子承包商的需求和工作分解是有些差别的。在承担软件开发时，对于工作和需求的分解还是应该尽量清楚（尤其是ICD的定义），这样既有利于软件测试和用户手册的编写，也有利于后期的维护。

刚学项目管理，无双兄有软件项目的WBS标准参考模板吗？