项目计划制定方法总结_0

1、项目计划制定方法总结项目计划制定方法总结项目的特殊性决定了项目中必然包含种种相互关联的 任务和不可预知的风险， 所以项目的首要任务就是 计划，计 划，计划”项目计划确定项目的范围和实施路径，其输出结果是项 目计划书，项目计划书包含项目 WBS、项目的进度计划、 任 务分配表、项目里程碑的标识、风险标识以及范围变更管理 流程。一、制定项目计划的步骤1.明确目标必须符合SMART原则，即目标必须明确、可行、具体 和可以度量 2 .制定项目工作范围对照目标，将需要完成的工作进行分析和梳理，列出一 份完成目标所需要进行的所有活动一览表，这就构成了项目 的工作范围。有两种办法：对于较小的项目，利用 头脑

2、风暴”对于稍大一些的项目，更好的方法是使用WBS来生成一份全面的清单3 .在项目组内分配任务职责责任矩阵(Responsibility Matrix )是完成这一任务的最 好选择 4.统筹规划项目间活动的关联该步骤确定各项目活动所需要的时间、人力、物力，明 确各项活动之间的先后逻辑关系，通常通过网络图工具来完 成完成以上4个步骤后，项目经理还可以为项目计划添加 一些支持性文档以及备注等信息，所有这些信息将使得项目 计划成为项目的信息中心。二、制定项目计划的原则1.不应过分拘泥于细节，此阶段的主要目的是制定出 一份能够获得干系人批准、总体结构准确且具有指导意义的 项目计划书。计划的完善是一项贯穿

3、于整个项目生命周期的 持续改进过程。2 .短期计划和长期计划相结合，短期计划需要做出周 密的规划，长期计划只需要给出指导性规划即可。3.项目计划的确定可以采用目标管理法，强调上下交 互来制定项目的目标和任务，首先由项目经理根据项目的章 程把项目的整体计划制定出来，然后由项目成员根据项目的 整体计划来指导个人任务的制定，通过协商式、小规模的群 体讨论来确定个人的任务。这种参与能够增加团队成员的责 任感，有利于项目工作的开展。不可忽视的重要信息1.组织架构图、各部门的职能、各关键部门的经理和 部分成员。项目经理可以通过翻阅流程文件了解各个部门之 间的业务依赖关系和配合方式。2 .历时经验3 .制约

4、因素(包括成本制约，人力资源制约)4 .项目实施中的假设信息项目干系人的要求在项目初期阶段往往是模糊的，不同的干系人之间对项目的期望往往不尽相同甚至是相互矛盾的。作为项目经理在制定项目计划的时候要充分认识到这一点，从一开始就要清晰地定义项目，并 注意平衡不同的项目关键干系人之间的需求。制定的项目计 划书一定要得到项目关键干系人的正式书面批准。三、项目计划的工具工作分解结构(WBS )WBS将项目的 交付物”自顶向下逐层分解到易于管理 的若干元素，以此结构化地组织和定义了项目的工作范围。工作细目(WORK ITEM )，工作包(WORK PACKAGE )WBS的制定没有固定的方法，但一般可以参

5、考以下原则：确保能把完成每个底层工作包的职责明确地赋予一个成员、一组成员或者一个组织单元，同时考虑尽量使一个 工作细目容易让具有相同技能的一类人承担。根据8 0小时的原则，工作包的时间跨度不要超过2周时间，否则会给项目控制带来一些困难；同时控制的粒度 不能太细，否则往往会影响项目成员的积极性可以将项目生命周期的各个阶段做为第一层，将每个 阶段的交付物做为第二层。如果有的交付物组成复杂，则将 交付物的组成元素放在第三曾。分解时要考虑项目管理本身也是工作范围的一部分， 可以单独做为一个细目。对一些各个阶段中都存在的共性工作可以提取出来， 例如人员培训作为独立的细目确保能够进行进度和成本估算。四、项

6、目计划的工具一一责任矩阵表责任矩阵是以表格形式表示完成工作分解结构中工作 细目的个人责任方法。第二篇：项目计划制定方法总结 3200字项目的特殊性决定了项目中必然包含种种相互关联的任务和不可预知的风险，所以项目的首要任务就是 计划，计划，计划”。项目计划确定项目的范围和实施路径，其输出结果是项目计划书，项目计划书包含项目 WBS、项目的进度计划、 任务分配表、项目里程碑的标识、风险标识以及范围变更管理流程。一、制定项目计划的步骤1.明确目标必须符合SMART原则，即目标必须明确、可行、具体 和可以度量2 .制定项目工作范围对照目标，将需要完成的工作进行分析和梳理，列出一 份完成目标所需要进行的

7、所有活动一览表，这就构成了项目 的工作范围。有两种办法：对于较小的项目，利用头脑风暴”对于稍大一些的项目，更好的方法是使用WBS来生成一份全面的清单 3 .在项目组内分配任务职责责任矩阵(Responsibility Matrix )是完成这一任务的最 好选择4.统筹规划项目间活动的关联该步骤确定各项目活动所需要的时间、人力、物力，明 确各项活动之间的先后逻辑关系，通常通过网络图工具来完 成完成以上4个步骤后，项目经理还可以为项目计划添加 一些支持性文档以及备注等信息，所有这些信息将使得项目 计划成为项目的信息中心。二、制定项目计划的原则1.不应过分拘泥于细节，此阶段的主要目的是制定出 一份能

8、够获得干系人批准、总体结构准确且具有指导意义的 项目计划书。计划的完善是一项贯穿于整个项目生命周期的 持续改进过程。2 .短期计划和长期计划相结合，短期计划需要做出周 密的规划，长期计划只需要给出指导性规划即可。3.项目计划的确定可以采用目标管理法，强调上下交 互来制定项目的目标和任务，首先由项目经理根据项目的章 程把项目的整体计划制定出来，然后由项目成员根据项目的 整体计划来指导个人任务的制定，通过协商式、小规模的群 体讨论来确定个人的任务。这种参与能够增加团队成员的责 任感，有利于项目工作的开展。不可忽视的重要信息1 .组织架构图、各部门的职能、各关键部门的经理和 部分成员。项目经理可以通

9、过翻阅流程文件了解各个部门之 间的业务依赖关系和配合方式。2 .历时经验3 .制约因素（包括成本制约，人力资源制约）4 .项目实施中的假设信息项目干系人的要求在项目初期阶段往往是模糊的，不同的干系人之间对项目的期望往往不尽相同甚至是相互矛盾 的。作为项目经理在制定项目计划的时候要充分认识到这一点，从一开始就要清晰地定义项目，并注意平衡不同的项目 关键干系人之间的需求。制定的项目计划书一定要得到项目 关键干系人的正式书面批准。三、项目计划的工具工作分解结构(WBS )WBS将项目的 交付物”自顶向下逐层分解到易于管理的若干元素，以此结构化地组织和定义了项目的工作范围。工作细目(WORK ITEM

10、 )，工作包(WORK PACKAGE )WBS的制定没有固定的方法，但一般可以参考以下原则：确保能把完成每个底层工作包的职责明确地赋予一个成员、一组成员或者一个组织单元，同时考虑尽量使一个 工作细目容易让具有相同技能的一类人承担。根据8 0小时的原则，工作包的时间跨度不要超过2 周时间，否则会给项目控制带来一些困难；同时控制的粒度 不能太细，否则往往会影响项目成员的积极性可以将项目生命周期的各个阶段做为第一层，将每个阶段的交付物做为第二层。如果有的交付物组成复杂，则将 交付物的组成元素放在第三曾。分解时要考虑项目管理本身也是工作范围的一部分， 可以单独做为一个细目。对一些各个阶段中都存在的共

11、性工作可以提取出来，例如人员培训作为独立的细目确保能够进行进度和成本估算四、项目计划的工具一一责任矩阵表责任矩阵是以表格形式表示完成工作分解结构中工作 细目的个人责任方法。从就餐座位看团队建设公司为员工提供两顿正餐，但并没有硬性规定每位员工 的就餐座位，由大家自由搭配。有意思的是，时间长了，每 个人的座位就在无形中固定了下来，于是出现了以下几种情 况：当出现同一个部门人员同桌时，是沟通和协调的最好 时机，平时工作上无法处理的事情，可能在饭桌上就可轻易 解决。有的时候，非正式沟通比正式沟通能更快达成共识； 平时一些小矛盾，也可以借助饭桌上的轻松气氛一一化解。 但有一个缺陷就是始终拘束在一个小圈子

12、内，无法与其它部 门同事进行有效沟通，信息无法互通有无。当出现多部门人员同桌时，有两种情况，一种是两个部 门人员同桌时，另一种是三个或三个以上部门人员同桌时。两个部门人员同桌时，如果是平时在工作上就已经达成 了良好合作伙伴关系的，这个时候是进一步增进感情的良 机；如果是平时工作上有矛盾的，或者是态度观点一直无法 达成共识的，一种可能是利用工作之外的进餐时间好好改 善，促进双方的关系往好的方面发展；另一种可能就是继续 将矛盾激化，即使在饭桌上也寸步不让。不过相信这种情况 并比较少，毕竟坐在一张桌子上，还是能够保持最起码的礼 貌的。但无法是哪种可能，这一桌的圈子已经扩大了一倍， 了解到的信息也多了

13、一倍。出现三个或三个以上部门人员同桌这种情况时，一般每 个部门人数都不多，甚至只有一个。这样，相当于每个人都 是 孤胆英雄”，虽然部门最多，却有可能得到的信息是最少 的，或者是最片面的。或许每一个人都只是闷头吃饭，或许 说些场面上的话互相应酬一下，如果就一个话题谈论起来， 恐怕各人有各人的理，搅了吃饭的兴致。在一个团队中，如果所有的团队成员的思维模式都是一 样的，那么他们一定能够很平稳、标准地完成任务；如果团 队成员有多个思维模式，但每一个模式都与其它的模式有或 多或少的冲突，如果最终不能达成共识的话，这个团队在无 形中已经解散了，根本无法完成任务；如果团队成员有多个 思维模式，但是最终他们能

14、够意识到团队的最终目的，那么 他们会将不同的思维模式按照需要进行合理整合，用一种打 破传统的方法完成任务。相比之下，哪个更好呢？我还注意到另外一个现象，当有新人加入时，他可能会 不小心坐错了他人的座位，这时可能有人会提醒他。如果提醒的那个人是那个座位原来的主人，那么可以说 明，原主人是一个循规蹈矩的人，一个很认真的人。这种人 可以做一些原则性很强的工作，比如掌管公司各类机密文件 的机要人员；如果是财务人员的话，公司不用担心账目会出 问题；但是这类人不适合需要团队合作的工作，因为他不具 备包容心。如果是另一个人提醒那位新人坐错了座位。那么可以这 样说，现在这个团队已经有了很强的凝聚力，每一个团队

15、成 员在他人眼里，都是独一无二，不可替代的。但在提醒之后，也会出现两种情况，一种是提醒新人坐 错了座位，然后大家挤出一个座位让这位新人坐进来，使其 成为其中的一员。可以看出，这是一个活力十足的团队，他 们懂得补充新鲜血液，懂得包容，并且热情；另一种情况是 提醒之后并不替新人做安排，完全将新人拒之千里。这是一 个保守的团队，不愿意因为外来的因素打破原有的状态，虽 然他们也会意识到接受一个新人可能会让整个团队更臻完 善，但是他们更害怕承担风险。在工作上，这会是一个四平 八稳的团队，但有可能不具备创新精神。新人被拒绝之后，大家也大多各就各位了，他可能会再 选择一张人数较少的桌子询问是否可以加入，如果

16、不幸再一 次被提示有人，或者干脆被拒绝，而此时他又发现一张空桌 子时，那么他一定不会再继续询问，而是选择一个人就餐。此后不断有新人加入这张新桌子，渐渐地就又形成了一 个新的团队，这个新团队的成员由于都曾经受到冷落，所以 团队内部有更强的凝聚力，但是也有可能他们会成为一个孤 立的团队，如何让团队更强，是他们迫切需要解决的问题。他们也许会采取与其它团队合作的方式，与其它团队组 成伙伴关系，但他们有很大可能不会与曾经拒绝过他们的团 队合作，而选择他们不曾打过交道的团队。这样无形中就会 孤立了曾经拒绝过这个新团队成员的那些团队。仅仅就进餐 而言，并无大碍，如果放在工作中，就值得思考了。而对于这个新团队

17、来说，目前最重要的不是孤立其它团 队，而是如何让自己变得强大，所以更要注重团队内部的建 设，提高团队中各个成员的战斗力和合作精神。团队是组织内一个较为简单的群体，只有优秀的团队才 能组成优秀的组织，所以，团队的产生和发展都是我们需要 关注的问题，认真分析每一个团队是促进团队发展的首要条 件。第三篇：论软件项目计划的制定 3000字信息系统项目管理师论文范例 2:论软件项目 计划的制定摘要本文讨论了一个作者参与的软件项目的项目计划制订 的若干问题.项目所开发的产品是一种智能电子教学设备， 该设备可以实时同步地将用户在硬件端的书写内容显示在 计算机屏幕上，并可以保存、编辑、打印用户输入的数据， 联

18、网的计算机也可以实时观看用户的书写过程，并且用户还 可以通过投影在硬件端的 PC机画面交互操作PC机.作者是该项目的软件开发组负责人兼软件架构师.作者 针对项目计划的制定采取了：分而治之，逐步求精，经验数 据三个主要策略，从而得到较好的效果.正文20xx年x月，作者所在公司启动了一个项目，该项目开发出来的产品是一种智能教学设备，该设备可以实时同步地 将用户在硬件端的书写内容显示在计算机屏幕上，用户可以 保存、编辑、打印通过硬件端输入到计算机的书写内容，联 网的计算机也可以实时观看用户的书写过程.另外，用户还 可以通过投影在硬件端的PC机显示画面交互地操作PC机.作者有幸全程参与该项目的开发，并

19、且担任了项目PC机软件开发组的负责人兼软件构架师的角色.对于这种实时 通信且具有联网功能的软件项目，我认为首先需要制定一个 良好的项目计划，才可以保证项目开发的成功.总结这次项目的经验，我认为行之有效的策略有三个， 分别是分而治之、逐步求精、经验数据。下面就结合这三个 策略详细讨论本次项目计划的制订。一、分而治之将一个过于复杂的问题分解成若干复杂度不那么高的 小间题来依次解诀，这种方法人类已经采用了几千年.这里 我们也可以用于项目计划的制定.因为整个考虑项目的方方 面面来制定计划其复杂度已经超过了人类处理问题的能 力.为了解决这个问题，可以将整个项目分解为一些更小的 组织体，逐一进行处理，这项

20、工作也就是项目管理中的 WBS（工作分解结构）。 比如针对这次项目中采取的 RUP开发 过程模型，我在完成需求管理计划时我就将计划内容分解成 初始、细化、构建、移交四个阶段来分别制定，最后合到一 块儿就是完整的需求管理计划.除了按时间段分解的角度来制定项目计划，我制订软件 开发计划时同时按照了 RUP过程方法的工作流的概念来分 解项目计划的制定工作，根据每个工作流在四个阶段业界通 用的工作量估计来制定计划，安排工作人员以及相应的软件 资源。因为软件开发计划涉及到多个工作流，我认为以这种方式分解是合理的.同时因为本项 目的特点，我省略了业务建模工作流，这是因为这次的产品 是以硬件为主，软件为辅的

21、消费类产品，所以业务建模不是 那么必要了.以不同的方式分解项目，可以从多个不同的角 度来制定整个项目计划，有利于全面、深入地了解项目，避 免 瞎子摸象”的情况发生.二、逐步求精计划工作其实是一种管理未来、管理未知的工作，而未 来是变化莫测的，还存在许多自身无法掌握的因素，因此存 在很大的难度.而解决这一困难的法宝就是逐步求精.按照 先框架后细节，先粗后细地进行项目的计划。比如在这个项目中，在接受这个项目后就开始了做了一 个初步计划，这个计划的内容主要是做出时间上的安排.因 为打算在20xx年的月需要用这个项目的产品申请国家中小 企业创新基金的支持，所以完成时间就定在了20xx年x月，预留一个月

22、用于写申请报告.总的时间进度确定后，大概分 配了三个时间段：系统工程分析、软件开发模型确定、软件 产品制造时间段、项目总结.等到确定这改项目后的 RUP开发模型后，就可以继续 对项目计划进行第二改求精了。其实RUP过程中出体现了逐步求精的理念，比如在初始与细化两个阶段都要产生出项 目计划的制品.这样我就可以在这个两个阶段对项目计划逐 步求精，比如在初始阶段只是将我需要完成的项目计划分为 了需求管理计划、软件开发计划、实施计划，然后在细化阶 段我再具体地制定每类计划的详细内容.比如在初始阶段时架构设计考虑以MFC为平台，根据这个决定软件开发计划的制定是比较粗略的，在细化阶段架 构设计进一步详细，

23、这时已经清楚各个模块和MFC的Doc/View主结构的接口定义，以及各模块之间的接口定义， 这时我就可以根据所需开发的模块制定计划。比如这时我就 计划了特效界面模块开发分两次迭代，第一次迭代计划一个 月时间，第二次迭代两周时间，第一次迭代需要完成放大和 缩小、树形选择、缩略显示等主要的界面效果，第二次迭代 的主要任务是根据用户反馈进行修改调整。三、经验数据要制定一个良好的计划离不开精确的估算.不过项目计 划是在项目开发的早期制定的，而在早期要完成精确的估算 是非常困难的.要解决这个问题的关键就在于经验数据”由于整个软件产业都还十分年轻，经验数据的积累都普遍不 足，才导致这一现象的出现。但是因为

24、这次项目开发的产品在国内还没有开发过，再加上公司没有积累深厚系统的 项目历史数据.针对面临的困难，我选用了FP功能点分析作为项目主要的估算方法.因为FP方法中有大量项目经验数据可以从网络上获得，同时其数据功能TLF、EIF，以及事务功能EI、EO、EQ的计算对经验数据依赖不强，只需对概念 理解正确一般就可以正确估算了.在估算成本的时候，因为 公司以前的生产率数据是以LOC为单位的，我利用软件工程书籍中的 逆火”经验数据，将LOC转换为功能点单位，当 然，这里必然导致一些误差。为了降低估算误差，最后使用 Delphi专家分析法对估算结果进行了调整。Delphi方法是一种集策法，也就是通过多名专家对估计 值的不断校正的方法.当然，请专家增加了项目成本，不过 最后得到咼质量的项目计划还是值得的.比如，在某专家的 建议下我们改变了自行开发网络层组件的计划，而是采购现 有的完全可以解决项目需求的成熟的中间件产品，这个策略 的调整在后来证明是正确的.一开始犯错误的原因是由于我 们网络开