项目计划制定方法总结（1500字）.doc

项目计划制定方法总结（1500字） 方法总结 项目的特殊性决定了项目中必然包含种种相互关联的任务和不可预知的风险，所以项目的首要任务就是“计划，计划，计划”。项目计划确定项目的范围和实施路径，其输出结果是项目计划书，项目计划书包含项目WBS、计划、任务分配表、项目里程碑的标识、风险标识以及范围变更管理流程。一、的步骤明确目标必须符合SMART原则，即目标必须明确、可行、具体和可以度量 制定项目工作范围对照目标，将需要完成的工作进行分析和梳理，列出一份完成目标所需要进行的所有活动一览表，这就构成了项目的工作范围。有两种办法：对于较小的项目，利用“头脑风暴”对于稍大一些的项目，更好的方法是使用WBS来生成一份全面的清单在项目组内分配任务职责责任矩阵（Responsibility Matrix）是完成这一任务的最好选择 统筹规划项目间活动的关联该步骤确定各项目活动所需要的时间、人力、物力，明确各项活动之间的先后逻辑关系，通常通过网络图工具来完成完成以上个步骤后，项目经理还可以为项目计划添加一些支持性文档以及备注等信息，所有这些信息将使得项目计划成为项目的信息中心。二、制定项目计划的原则不应过分拘泥于细节，此阶段的主要目的是制定出一份能够获得干系人批准、总体结构准确且具有指导意义的项目计划书。计划的完善是一项贯穿于整个项目生命周期的持续改进过程。短期计划和长期计划相结合，短期计划需要做出周密的规划，长期计划只需要给出指导性规划即可。项目计划的确定可以采用目标管理法，强调上下交互来制定项目的目标和任务，首先由项目经理根据项目的章程把项目的整体计划制定出来，然后由项目成员根据项目的整体计划来指导个人任务，通过协商式、小规模的群体讨论来确定个人的任务。这种参与能够增加团队成员的责任感，有利于项目工作的开展。不可忽视的重要信息组织架构图、各部门的职能、各关键部门的经理和部分成员。项目经理可以通过翻阅流程文件了解各个部门之间的业务依赖关系和配合方式。 历时经验制约因素（包括成本制约，人力资源制约）项目实施中的假设信息项目干系人的要求在项目初期阶段往往是模糊的，不同的干系人之间对项目的期望往往不尽相同甚至是相互矛盾的。作为项目经理在制定项目计划的时候要充分认识到这一点，从一开始就要清晰地定义项目，并注意平衡不同的项目关键干系人之间的需求。制定的项目计划书一定要得到项目关键干系人的正式书面批准。三、项目计划的工具工作分解结构（WBS）WBS将项目的“交付物”自顶向下逐层分解到易于管理的若干元素，以此结构化地组织和定义了项目的工作范围。工作细目（WORK ITEM），工作包（WORK PACKAGE）WBS的制定没有固定的方法，但一般可以参考以下原则：确保能把完成每个底层工作包的职责明确地赋予一个成员、一组成员或者一个组织单元，同时考虑尽量使一个工作细目容易让具有相同技能的一类人承担。根据小时的原则，工作包的时间跨度不要超过周时间，否则会给项目控制带来一些困难；同时控制的粒度不能太细，否则往往会影响项目成员的积极性可以将项目生命周期的各个阶段做为第一层，将每个阶段的交付物做为第二层。如果有的交付物组成复杂，则将交付物的组成元素放在第三曾。分解时要考虑项目管理本身也是工作范围的一部分，可以单独做为一个细目。对一些各个阶段中都存在的共性工作可以提取出来，例如人员培训作为独立的细目确保能够进行进度和成本估算。四、项目计划的工具责任矩阵表责任矩阵是以表格形式表示完成工作分解结构中工作细目的个人责任方法。 第二篇：项目计划制定方法总结 3200字 项目的特殊性决定了项目中必然包含种种相互关联的任务和不可预知的风险，所以项目的首要任务就是“计划，计划，计划”。确定项目的范围和实施路径，其输出结果是项目计划书，项目计划书包含项目WBS、计划、任务分配表、项目里程碑的标识、风险标识以及范围变更管理流程。一、的步骤明确目标必须符合SMART原则，即目标必须明确、可行、具体和可以度量制定项目工作范围对照目标，将需要完成的工作进行分析和梳理，列出一份完成目标所需要进行的所有活动一览表，这就构成了项目的工作范围。有两种办法：对于较小的项目，利用“头脑风暴”对于稍大一些的项目，更好的方法是使用WBS来生成一份全面的清单 在项目组内分配任务职责责任矩阵（Responsibility Matrix）是完成这一任务的最好选择统筹规划项目间活动的关联该步骤确定各项目活动所需要的时间、人力、物力，明确各项活动之间的先后逻辑关系，通常通过网络图工具来完成完成以上个步骤后，项目经理还可以为项目计划添加一些支持性文档以及备注等信息，所有这些信息将使得项目计划成为项目的信息中心。 二、制定项目计划的原则不应过分拘泥于细节，此阶段的主要目的是制定出一份能够获得干系人批准、总体结构准确且具有指导意义的项目计划书。计划的完善是一项贯穿于整个项目生命周期的持续改进过程。短期计划和长期计划相结合，短期计划需要做出周密的规划，长期计划只需要给出指导性规划即可。项目计划的确定可以采用目标管理法，强调上下交互来制定项目的目标和任务，首先由项目经理根据项目的章程把项目的整体计划制定出来，然后由项目成员根据项目的整体计划来指导个人任务，通过协商式、小规模的群体讨论来确定个人的任务。这种参与能够增加团队成员的责任感，有利于项目工作的开展。不可忽视的重要信息组织架构图、各部门的职能、各关键部门的经理和部分成员。项目经理可以通过翻阅流程文件了解各个部门之间的业务依赖关系和配合方式。历时经验制约因素（包括成本制约，人力资源制约）项目实施中的假设信息 项目干系人的要求在项目初期阶段往往是模糊的，不同的干系人之间对项目的期望往往不尽相同甚至是相互矛盾的。作为项目经理在制定项目计划的时候要充分认识到这一点，从一开始就要清晰地定义项目，并注意平衡不同的项目关键干系人之间的需求。制定的项目计划书一定要得到项目关键干系人的正式书面批准。 三、项目计划的工具工作分解结构（WBS）WBS将项目的“交付物”自顶向下逐层分解到易于管理的若干元素，以此结构化地组织和定义了项目的工作范围。工作细目（WORK ITEM），工作包（WORK PACKAGE）WBS的制定没有固定的方法，但一般可以参考以下原则：确保能把完成每个底层工作包的职责明确地赋予一个成员、一组成员或者一个组织单元，同时考虑尽量使一个工作细目容易让具有相同技能的一类人承担。根据小时的原则，工作包的时间跨度不要超过周时间，否则会给项目控制带来一些困难；同时控制的粒度不能太细，否则往往会影响项目成员的积极性可以将项目生命周期的各个阶段做为第一层，将每个阶段的交付物做为第二层。如果有的交付物组成复杂，则将交付物的组成元素放在第三曾。分解时要考虑项目管理本身也是工作范围的一部分，可以单独做为一个细目。 对一些各个阶段中都存在的共性工作可以提取出来，例如人员培训作为独立的细目 确保能够进行进度和成本估算。 四、项目计划的工具责任矩阵表责任矩阵是以表格形式表示完成工作分解结构中工作细目的个人责任方法。 从就餐座位看团队建设公司为员工提供两顿正餐，但并没有硬性规定每位员工的就餐座位，由大家自由搭配。有意思的是，时间长了，每个人的座位就在无形中固定了下来，于是出现了以下几种情况： 当出现同一个部门人员同桌时，是沟通和协调的最好时机，平时工作上无法处理的事情，可能在饭桌上就可轻易解决。有的时候，非正式沟通比正式沟通能更快达成共识；平时一些小矛盾，也可以借助饭桌上的轻松气氛一一化解。但有一个缺陷就是始终拘束在一个小圈子内，无法与其它部门同事进行有效沟通，信息无法互通有无。当出现多部门人员同桌时，有两种情况，一种是两个部门人员同桌时，另一种是三个或三个以上部门人员同桌时。两个部门人员同桌时，如果是平时在工作上就已经达成了良好合作伙伴关系的，这个时候是进一步增进感情的良机；如果是平时工作上有矛盾的，或者是态度观点一直无法达成共识的，一种可能是利用工作之外的进餐时间好好改善，促进双方的关系往好的方面发展；另一种可能就是继续将矛盾激化，即使在饭桌上也寸步不让。不过相信这种情况并比较少，毕竟坐在一张桌子上，还是能够保持最起码的礼貌的。但无法是哪种可能，这一桌的圈子已经扩大了一倍，了解到的信息也多了一倍。出现三个或三个以上部门人员同桌这种情况时，一般每个部门人数都不多，甚至只有一个。这样，相当于每个人都是“孤胆英雄”，虽然部门最多，却有可能得到的信息是最少的，或者是最片面的。或许每一个人都只是闷头吃饭，或许说些场面上的话互相应酬一下，如果就一个话题谈论起来，恐怕各人有各人的理，搅了吃饭的兴致。在一个团队中，如果所有的团队成员的思维模式都是一样的，那么他们一定能够很平稳、标准地完成任务；如果团队成员有多个思维模式，但每一个模式都与其它的模式有或多或少的冲突，如果最终不能达成共识的话，这个团队在无形中已经解散了，根本无法完成任务；如果团队成员有多个思维模式，但是最终他们能够意识到团队的最终目的，那么他们会将不同的思维模式按照需要进行合理整合，用一种打破传统的方法完成任务。相比之下，哪个更好呢？我还注意到另外一个现象，当有新人加入时，他可能会不小心坐错了他人的座位，这时可能有人会提醒他。如果提醒的那个人是那个座位原来的主人，那么可以说明，原主人是一个循规蹈矩的人，一个很认真的人。这种人可以做一些原则性很强的工作，比如掌管公司各类机密文件的机要人员；如果是财务人员的话，公司不用担心账目会出问题；但是这类人不适合需要团队合作的工作，因为他不具备包容心。如果是另一个人提醒那位新人坐错了座位。那么可以这样说，现在这个团队已经有了很强的凝聚力，每一个团队成员在他人眼里，都是独一无二，不可替代的。但在提醒之后，也会出现两种情况，一种是提醒新人坐错了座位，然后大家挤出一个座位让这位新人坐进来，使其成为其中的一员。可以看出，这是一个活力十足的团队，他们懂得补充新鲜血液，懂得包容，并且热情；另一种情况是提醒之后并不替新人做安排，完全将新人拒之千里。这是一个保守的团队，不愿意因为外来的因素打破原有的状态，虽然他们也会意识到接受一个新人可能会让整个团队更臻完善，但是他们更害怕承担风险。在工作上，这会是一个四平八稳的团队，但有可能不具备创新精神。新人被拒绝之后，大家也大多各就各位了，他可能会再选择一张人数较少的桌子询问是否可以加入，如果不幸再一次被提示有人，或者干脆被拒绝，而此时他又发现一张空桌子时，那么他一定不会再继续询问，而是选择一个人就餐。此后不断有新人加入这张新桌子，渐渐地就又形成了一个新的团队，这个新团队的成员由于都曾经受到冷落，所以团队内部有更强的凝聚力，但是也有可能他们会成为一个孤立的团队，如何让团队更强，是他们迫切需要解决的问题。他们也许会采取与其它团队合作的方式，与其它团队组成伙伴关系，但他们有很大可能不会与曾经拒绝过他们的团队合作，而选择他们不曾打过交道的团队。这样无形中就会孤立了曾经拒绝过这个新团队成员的那些团队。仅仅就进餐而言，并无大碍，如果放在工作中，就值得思考了。而对于这个新团队来说，目前最重要的不是孤立其它团队，而是如何让自己变得强大，所以更要注重团队内部的建设，提高团队中各个成员的战斗力和合作精神。团队是组织内一个较为简单的群体，只有优秀的团队才能组成优秀的组织，所以，团队的产生和发展都是我们需要关注的问题，认真分析每一个团队是促进团队发展的首要条件。 第三篇：论软件项目计划的制定 3000字 信息系统项目管理师论文范例2：论软件的制定摘要本文讨论了一个作者参与的的制订的若干问题项目所开发的产品是一种智能电子教学设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上，并可以保存、编辑、打印用户输入的数据，联网的计算机也可以实时观看用户的书写过程，并且用户还可以通过投影在硬件端的PC机画面交互操作PC机作者是该项目的软件开发组负责人兼软件架构师作者针对项目计划的制定采取了：分而治之，逐步求精，经验数据三个主要策略，从而得到较好的效果正文20xx年x月，作者所在公司启动了一个项目，该项目开发出来的产品是一种智能教学设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上，用户可以保存、编辑、打印通过硬件端输入到计算机的书写内容，联网的计算机也可以实时观看用户的书写过程另外，用户还可以通过投影在硬件端的PC机显示画面交互地操作PC机作者有幸全程参与该项目的开发，并且担任了项目PC机软件开发组的负责人兼软件构架师的角色对于这种实时通信且具有联网功能的，我认为首先需要制定一个良好的项目计划，才可以保证项目开发的成功总结这次项目的经验，我认为行之有效的策略有三个，分别是分而治之、逐步求精、经验数据。下面就结合这三个策略详细讨论本次项目计划的制订。一、分而治之将一个过于复杂的问题分解成若干复杂度不那么高的小间题来依次解诀，这种方法人类已经采用了几千年这里我们也可以用于项目计划的制定因为整个考虑项目的方方面面来制定计划其复杂度已经超过了人类处理问题的能力为了解决这个问题，可以将整个项目分解为一些更小的组织体，逐一进行处理，这项工作也就是项目管理中的WBS（工作分解结构）。 比如针对这次项目中采取的RUP开发过程模型，我在完成需求管理计划时我就将计划内容分解成初始、细化、构建、移交四个阶段来分别制定，最后合到一块儿就是完整的需求管理计划除了按时间段分解的角度来制定项目计划，我制订软件开发计划时同时按照了RUP过程方法的工作流的概念来分解项目计划的制定工作，根据每个工作流在四个阶段业界通用的工作量估计来制定计划，安排工作人员以及相应的软件资源。因为软件开发计划涉及到多个工作流，我认为以这种方式分解是合理的同时因为本项目的特点，我省略了业务建模工作流，这是因为这次的产品是以硬件为主，软件为辅的消费类产品，所以业务建模不是那么必要了以不同的方式分解项目，可以从多个不同的角度来制定整个项目计划，有利于全面、深入地了解项目，避免“瞎子摸象”的情况发生二、逐步求精计划工作其实是一种管理未来、管理未知的工作，而未来是变化莫测的，还存在许多自身无法掌握的因素，因此存在很大的难度而解决这一困难的法宝就是逐步求精按照先框架后细节，先粗后细地进行项目的计划。比如在这个项目中，在接受这个项目后就开始了做了一个初步计划，这个计划的内容主要是做出时间上的安排因为打算在20xx年的月需要用这个项目的产品申请国家中小企业创新基金的支持，所以完成时间就定在了20xx年x月，预留一个月用于写申请报告总的时间进度确定后，大概分配了三个时间段：系统工程分析、软件开发模型确定、软件产品制造时间段、项目总结等到确定这改项目后的RUP 开发模型后，就可以继续对项目计划进行第二改求精了。其实RUP 过程中出体现了逐步求精的理念，比如在初始与细化两个阶段都要产生出项目计划的制品这样我就可以在这个两个阶段对项目计划逐步求精，比如在初始阶段只是将我需要完成的项目计划分为了需求管理计划、软件开发计划、实施计划，然后在细化阶段我再具体地制定每类计划的详细内容比如在初始阶段时架构设计考虑以MFC为平台，根据这个决定软件开发计划的制定是比较粗略的，在细化阶段架构设计进一步详细，这时已经清楚各个模块和MFC的Doc/View主结构的接口定义，以及各模块之间的接口定义，这时我就可以根据所需开发的模块制定计划。比如这时我就计划了特效界面模块开发分两次迭代，第一次迭代计划一个月时间，第二次迭代两周时间，第一次迭代需要完成放大和缩小、树形选择、缩略显示等主要的界面效果，第二次迭代的主要任务是根据用户反馈进行修改调整。三、经验数据要制定一个良好的计划离不开精确的估算不过项目计划是在项目开发的早期制定的，而在早期要完成精确的估算是非常困难的要解决这个问题的关键就在于“经验数据”由于整个软件产业都还十分年轻，经验数据的积累都普遍不足，才导致这一现象的出现。 但是因为这次项目开发的产品在国内还没有开发过，再加上公司没有积累深厚系统的项目历史数据针对面临的困难，我选用了FP功能点分析作为项目主要的估算方法因为FP方法中有大量项目经验数据可以从网络上获得，同时其数据功能TLF、EIF，以及事务功能EI、EO、EQ的计算对经验数据依赖不强，只需对概念理解正确一般就可以正确估算了在估算成本的时候，因为公司以前的生产率数据是以LOC为单位的，我利用软件工程书籍中的“逆火”经验数据，将LOC转换为功能点单位，当然，这里必然导致一些误差。为了降低估算误差，最后使用Delphi专家分析法对估算结果进行了调整。Delphi方法是一种集策法，也就是通过多名专家对估计值的不断校正的方法当然，请专家增加了项目成本，不过最后得到高质量的项目计划还是值得的比如，在某专家的建议下我们改变了自行开发网络层组件的计划，而是采购现有的完全可以解决项目需求的成熟的中间件产品，这个策略的调整在后来证明是正确的一开始犯错误的原因是由于我们网络开发经验不足把用户需求想复杂了。最后谈一下使用的工具软件在制定项目计划过程中我采用了Microsoft的Project 20xx绘制甘特图因为项目的进度安排是和项目中每个人都是息息相关的，所以在做甘特图前我首先征集了大家对文字和条形图效果的意见，然后按大家的意见进行了美化，比如用鲜艳的颜色标识关键任务，放大任务摘要信息，突出里程碑信息等这在有些项目管理者看来似乎是小事，不过我认为一个赏心悦目的甘特图可以带给观看者好的心情，而好的心情可以大大提高工作效率。同时，考虑创新基金支持的项目在交互期限上有很大压力，所以在定义甘特图任务的依赖关系时我采取了业界惯用的“时间盒”的技术，也就是在每个任务的任务信息对话框中“前置任务”一栏中的“延隔时间”我填入5%-