项目管理报告课件

1、项目管理软件开发项目第三项目组项目经理:张禄成员:时黎 朱小钢 苏清泉 王悦 李富春 团队文化:以人为本,科学管理,团结协作,争创一流。精神:团结拼搏,务实求新,追求卓越,持续改进。目 录 项目组工作安排第1部分 项目目标、工作描述表第2部分 项目组织机构安排第3部分 项目里程碑计划第4部分 项目工作分解结构第5部分 项目责任分配矩阵第6部分 项目网络计划图第7部分 项目人力资源计划第8部分 项目费用分解第9部分 项目费用及费用、进度控制第10部分 项目风险分析及应对计划第11部分 项目的沟通管理第一部分 工作描述及组织机构设计报告人:张禄序号姓名职务负责工作1张禄项目经理目标描述、团队分工、

2、项目管理组织机构设计2李富春项目成员拟定项目重大里程碑计划、分解工作分解结构3时黎项目成员确定工作先后关系、估计执行时间、编制项目甘特图和网络计划图、确定关键工作4苏清泉项目成员制定人力与资源使用计划、进行费用分解和分析5王 悦项目成员分析项目实施过程中的风险、提出应对计划6朱小钢项目成员分析项目实施过程中的信息、冲突、沟通等问题并提出具体操作方案团队分工项目背景分析 某企业由于业务发展的需要，决定采用项目管理的方式进行管理，为了更有效地对项目的执行过程进行控制，决定开发一套项目管理软件以满足这一需求。该企业准备投入100万元，时间要求2025周，该软件项目的计划开始日期为2002年1月1日，

3、企业要求该软件正式验收前要试运行4周以上的时间，并根据试运行情况进行适当修改。项目管理组织结构 假设该企业一直采用项目管理的形式，主要的职能部门有人力资源部、财务部、设计部、研发部、采购部、质检部等。由于项目的开发需要企业各部门的通力合作，为此，企业领导决定采用项目管理的模式进行管理，委托一位项目经理全权负责该项目的开发，同时成立企业项目管理软件开发项目管理办公室。 对于项目管理软件开发的组织管理结构，可能采取的组织形式有只能式、矩阵式、项目式。职能式组织结构适用于规模较小、偏重于技术的项目，而不适应与项目环境的变化较大的项目。同职能式组织结构相比，在对付不稳定的环境时，项目组织结构显示出了自

4、己的长处，既来自于项目团队的整体性和各类人才的紧密合作。同前两种组织结构相比，矩阵式组织结构在充分利用企业资源上显出了巨大的优势。它融合了前两种组织结构的优点，在进行技术复杂、规模较大的项目管理时显出了明显的优势。的难度，以及原有企业智能型组织的特点，为了保证项目的顺利进行，企业决定采用强矩阵 基于项目实施的特点，即技术方面的复杂性和组织协调方面组织结构的形式，如下图所示。 该组织结构的特点和项目办直接归总经理领导，以保证项目的开发成功，也说明了企业领导对该开发项目的重视程度。项目办通过横向的职能机构协调利用企业现有资源，各职能部门在项目办的协调下相互协作，使得项目的开发中各职能部门的作用井井

5、有条。由于矩阵式组织结构形式的特点是将按职能划分的纵向部门与按照项目划分的横向部门结合起来，以构成类是矩阵的管理系统，这与本项目的特点是吻合的。组织机构选择 组织结构影响因素职能式矩阵式项目式本项目特点不确定性低高高高所用技术标准复杂新复杂复杂程度低中等高高持续时间短中等长长规模小中等大中等重要性低中等高高客户类型各种各样中等单一单一对内部依赖性弱中等强中等对外部依赖性强中等强强时间限制性弱中等强强 9 项目组织结构图 项目管理办公项目组组织机构 第二部分 项目里程碑确 工作分解 责任分配矩阵报告人:李富春项目的里程碑是项目实施过程中，对项目实施进度有重要影响的关键事件。它对进度状态检查有重要

6、意义。根据本项目特点，我们确定了里程碑事件。里程碑计划图如下：序号任务名称月份123456678910111213141617181920212223241需求分析完成2方案设计完成3开发结束4集成测试结束5试运行结束6验收完成 项目的里程碑计划项目工作分解结构（WBS） 目的 为保证项目结构的完整性，让相关方了解项目过程，将目标分解到单元便于、人力资源计划安排、责任分配、费用预算和检查、控制。分解过程 以项目范围和目标为主导，由上而下，由粗到细进行分解。形成树型结构，直到具体明确。子项目一般要有一定的整体性和独立性。分解层次 根据项目的特点和性质，本项目的工作分解结构按照项目管理软件开发的流

7、程进行分解和编码，如图下所示软件开发项目工作分解结构（WBS)责任矩阵的编制方法责任矩阵的作用：将WBS分解得到的工作任务落实到项目有关部门和个人，从而明确他们在组织工作中的关系、责任和地位。编制方法：以组织单元为行，工作单元为列，形成责任矩阵。责任矩阵可以应用于WBS的任何层次。下面是以最末层WBS分解结果建立的责任矩阵图。 20 项目的责任分配矩阵编号任务名称项目经理设计组开发组财务组采购组质检组市场组110需求分析PF CXXXC120方案设计PFCXXCC121系统设计FCXXCC122功能设计FCXXCC130开发131项目 信息录入模块CC FXX CC132项目网络计划绘制模块C

8、C FXX CC133时间计划安排模块CC FXX CC134项目甘特图模块CC FXX CC135执行信息录入模块CC FXX CC136报表输出模块CC FXX CC140测试141分模块测试CCFXXXX142集成测试CCFXXXX150试运行151初试运行FCCCCCC152系统完善CCFX X CC160验收PFCXCCC170项目管理FXXXXXX图例：P-批准 F-负责C-参与 X-协作 参与项目各方的责任一般通过责任分析矩阵的形式进行表达，这种表达形式的优点是直观地将项目责任方的责任和权利完整地表达了出来，便于项目各方进行有效的协调，每项工作都有负责、有协作。责任分配的依据是项

9、目组织机构及工作分解结构。 第三部分 网络计划及甘特图报告人:时黎网络计划工作表网络计划图项目管理软件开发项目第四部分 人力资源及费用计划分析报告人:苏清泉责任矩阵的编制方法责任矩阵的作用：将WBS分解得到的工作任务落实到项目有关部门和个人，从而明确他们在组织工作中的关系、责任和地位。编制方法：以组织单元为行，工作单元为列，形成责任矩阵。责任矩阵可以应用于WBS的任何层次。下面是以最末层WBS分解结果建立的责任矩阵图。 20 人力资源计划表每周按5工作日算人力资源负荷图费用估计目标额度投资额人力费用其它费用总费用预留软件开发633800266200900000100000说明：预留费用用于意外

10、开支和保质期的开支编号任务名称资源名称工作量(工时)数量(人)工期(日)人力费用其它费用总费用费用/23周100项目管理软件开发115110需求分析设计师80254800190002380023800120方案设计200121系统设计设计师24031021600240004560022800122功能设计设计师24031021600240004560022800130开发550131项目信息录入模块工程师5602352240021000434006200132时间计划安排模块工程师1120435896002100011060015800133项目网络计划模块工程师720245288002160

11、0504005600134甘特图计划模块工程师14404451152002250013770015300135执行信息录入模块工程师16004501280003000015800015800136报表输出模块工程师17604551408002200016280014800140测试100141分模块测试工程师80253200200002320023200142集成测试工程师80253200200002320023200150试运行200151初步试运行管理人员36031516200156003180010600152系统完善工程师80253200320003520035200160验收工程师8

12、0253200550087008700合计601800298200900000资源费率：设计师=30元/工时；工程师=20元/工时；管理人员=15元/工时项目管理软件开发项目费用分解表项目管理软件开发项目预算曲线表项目管理软件项目费用累计曲线项目管理软件开发项目挣值分析曲线项目管理软件开发项目挣得值分析挣得值分析图是对项目执行到第13周得费用执行情况得统计。从图中可以看出BCWPACWP,说明费用有节余。第五部分 风险分析报告人:王悦项目风险管理 本项目是一个项目管理软件开发项目，根据项目的特点决定了项目存在的风险较多，项目风险管理的成败直接影响到项目实施的成败。通过头脑风暴法和专家评判法，项

13、目组认为在众多的风险因素中关键技术人员变动、核心技术开发难度大、项目总成本的有效控制、进度控制等因素是项目风险的主要因素应特别予以重视并采取相应的应对措施。 43 项目风险管理流程风险监控风险评估跟踪修订变更计划风险识别风险量化风险应对措施 45 项目风险管理我们可以根据风险控制与项目事件发生的时间将风险管理划分为三个部分：事前控制风险管理规划事中控制风险管理方法事后控制风险管理报告 项目风险规划 将风险管理的手段贯穿于项目实施生命周期的全过程。如在项目概念阶段成立风险评审委员会对项目潜在的风险进行评审等。 在该项目的费用预算中提取一定比例的风险准备金。 根据项目的各里程碑制定项目实施的备用方

14、案。 采用项目风险管理的工具及方法进行风险分析。 建立利益相关方应对风险的快速处理机制。 44 项目风险管理-风险识别 本项目为项目管理软件编制项目，针对项目特点，我们项目部全体人员在收集资料、了解项目的所有前提、假设制约因素，类比了同类项目档案后，采用头脑风暴法和经验法对所有潜在的风险可能进行了识别分类，共识别出该项目风险有：技术风险、时间风险、人员风险、管理风险、市场风险、费用风险和组织结构风险等项目风险管理项目风险包括： 技术风险：核心技术开发难度大、需求分析不明确、软件功能不齐全、设计是否合理等存在着风险，设计缺陷，后备措施不足 费用风险：费用分配合理性、成本的控制、项目总成本的有效控

15、制、工作效率的控制。 时间风险：软件需求定义书无法按期拿出、软件检测试阶段不能正常完成、进度控制。 人力风险：选人不当、关键人离开、个性差异、团队意识、技术观念差异、各项目组衔接不及时。 管理风险：核心技术的控制问题及产权保护、机制不适应、决策失误、过程控制不严、合同管理不当、信息录入不当。 市场风险：定价太高、新产品替代、定位不准项目风险管理-风险评估 在以上分析得出的潜在风险中，我们按各种因素出现的概率和对项目造成的危害程度两方面进行排序，得出主要风险有：技术风险、时间风险、人员风险、管理风险、市场风险和费用风险。项目风险管理-风险控制 项目管理过程中，对风险进行识别、评估的目的就是为了降

16、低项目风险的负面效应制定风险应对策略和技术手段，本项目经过项目部全体成员研究，对可能存在的潜在风险采取应对措施如下：风险控制制定应对风险的程序和方法主要有以下四种： 规避。通过变更项目计划消除风险或风险的触发条件，使目标免受影响。这是一种事前的风险应对策略。例如，采用更熟悉的工作方法、澄清不明确的需求、增加资源和时间、减少项目工作范围、避免不熟悉的分包商等。 转移。不消除风险，而是将项目风险的结果连同应对的权力转移给第三方（第三方应该知道这是风险并有承受能力）。这也是一种事前的应对策略，例如，签订不同种类的合同，或签订补偿性合同。 弱化。将风险事件的概率或结果降低到一个可以接受的程度，当然降低

17、概率更为有效。例如，选择更简单的流程、进行更多的实验、建造原型系统、增加备份设计等。 接受。不改变项目计划（或没有合适的策略应付风险），而考虑发生后如何应对。例如制定应急计划或退却计划、甚至仅仅进行应急储备和监控，待发生时随机应变。项目风险评估与处治（表1）来源内容影响结果危险识别解决措施处置方法技术风险需求分析不明确软件不符合市场要求A加强客户沟通与市场调研减少设计缺陷软件功能不齐全A配备好的技术人员接受时间风险软件需求定义书无法按期拿出影响后续工作的进行A加快工作节奏减少软件检测试阶段不能正常完成进度无法按时B软件测试阶段安排充足时间接受人员风险代码编制量较大，人力资源不足工期拖延B集中力

18、量，保证重点工作正常进行接受技术观念工作效率C加强培训工作回避关键人物离开项目项目延误或失败A配备良好条件回避市场风险定价太高项目失败C严格控制项目成本减少新产品替代项目失败B加快研制步伐减少定位不准项目失败A加强概念期工作减少项目风险评估与处治（表2）来源内容影响结果危险识别解决措施处置方法管理风险合同项目失败A加强管理回避各项目组衔接不及时时间拖延C加强管理回避费用风险费用分配不合理影响工作的效率B优化费用分配减少成本控制直接导致产品定价上涨A加强管理，控制费用减少项目风险管理-风险监控 我们项目组对可能存在的风险进行了有效的识别和合理分析，并制定了一系列相应的措施进行规避风险。但仅有这些

19、还不够，还需要在风险事件发生时跟踪识别旧风险，再识别剩余风险和新出现的风险，及时发现新风险，保证风险计划的顺利实施并实现项目风险管理循环过程。风险监控的目的一是监视风险的状况，例如风险是已经发生、仍然存在还是已经消失；二是检查风险的对策是否有效，监控机制是否在运行；三是不断识别新的风险并制定对策。 风险监控常用的方法 风险审计：专人检查监控机制是否得到执行。并定期作风险审核，例如在大的阶段点重新识别风险并进行分析，对没有预计到的风险制定新的应对计划。 偏差分析：与基准计划比较，分析成本和时间上的偏差。例如，未能按期完工、超出预算等都是潜在的问题，主要是挣值费用分析技术指标：比较原定技术指标和实

20、际技术指标差异。例如，测试未能达到性能要求，缺陷数大大超过预期等。 第六部分 沟通管理报告人:朱小钢沟通管理 本项目中，我们认为：对于成功，威胁最大的就是沟通的失败。本项目成功的三个主要因素分别为：某企业的积极参与，明确的需求表达，企业管理层的大力支持。而这三要素全部依赖于良好的沟通技巧，特别是非信息技术人员。沟通管理的目标是及时并适当地创建、收集、发送、储存和处理管理软件项目的信息，标准的项目沟通包含沟通计划、信息传递、实施情况报告、管理收尾共四个过程。沟通计划 沟通信息类型 ：会议广播文件陈述合时性 ：项目干系人：项目发起人：项目经理：项目小组）：测试小组：结构管理小组）：技术小组 采用轮

21、式沟通方式沟通计划的方法 对于不同部门采用不同语言文字沟通注意对各部门的双向沟通和沟通方式注意非正式渠道沟通头脑风暴专家访谈 历史资料 检查表 评估表 沟通计划工作汇报方式明确表达项目组成员对项目经理或项目经理对上级和相干人员的工作汇报方式，明确什么时间，什么形式。项目组成员每周五对项目经理张总通过EMAIL发送周报，每周一上午项目经理与业务经理沟通后完成项目周报，下午1：30召开项目组例会，会后由项目经理向高层经理提交项目周报 张总对直接客户和公司每月一号通过EMAIL发月报的方式紧急汇报通过电话及时沟通；每两周项目组进行一次当前工作沟通会议；每周同客户和上级进行一次口头汇报。 沟通计划文件

22、保存方式首先在公司服务器里划分专门的存储空间保存信息、信息读写分为不同的权限，明确划分用户信件储存区域、会议记录储存区域、工作报告储存区域、项目文档（需求、设计、编码、发布程序等）储存区域、辅助文档等的存放位置，及相应的读写权力。收集和保存不同类型的信息，遵循公司项目实施规章制度，将与项目有关的重要工作建档。沟通计划联系方式设立专用于项目管理中所有的相关的人员的联系方式的小册子和文档，其中如项目组成员、项目组上级领导、行政部人员、技术支持人员、出差定房订票等系统中相关的人员，座机、手机、职能等等，相应的一一列上，做到简洁又要明了，特殊人员标上细小的标注，能够做到在一打开小册子的同时就能将所有的

23、相关人员的资料了然于胸，正所谓知已知彼，这样一来，很多在平时大费周章的事，就能在养成的良好的习惯中，轻松做到。沟通计划其他统一项目文件格式：制订项目本身统一的文件模板，是正规管理的一部分，所以必须统一各种文件模板，并提供编写指南。设立沟通计划维护人：由项目组朱小钢担任，本计划在发行变化时，由该同志进行修订，并对相关人员发送。信息问题信息主要为项目每个阶段服务信息类型：内部外部历史信息的收集和传播；书面谈话集体技术形采用线路的方式信息发送 沟通是一种感知 沟通是一种期望 沟通产生要求 信息不是沟通 沟通是一种感知 沟通一定是双向，必须保证信息被接收者接到了。所有的沟通方式，必须有回馈机制，保证接

24、收者接收到。电子邮件进行沟通，无论是接收者简单回复“已收到、OK”等，还是电话回答收到，但必须保证接收者收到信息，并回应信息已经接收到。信息收到必须保证理解是正确的，很多事情信息收到了，但被错误的理解了，很多信息是传达到了，但却被错误理解了。发送方的正确表达、接收者的正确理解是非常重要的。要求发送者进行信息发送，接收者进行理解后进行细化并进行回复邮件表达，这种表达却是在确认自己理解了的同时去转叙或者执行的结果，而不是复述。沟通是一种期望在软件项目管理中，项目不同干系人是有不同的沟通需要的。项目组成员在具体的工作安排中他想明白那个职位是否符合他的意愿等等，上级要了解接收者的期望，向下属传达工作安

25、排的同时还要了解他的意愿取向的问题，再采取相应的方法，调起其在工作上的热情，从而促使其在工作的高效付出，在项目管理中如让下属有反抗情绪的产生或者低效的工作，则是一个项目经理在沟通上不得法的一个失败实例。项目经理的上级和客户更加关心是进度的问题：时间是否会延期、是否要添加成本、质量是否有保障等等。这对于项目经理来说，就应即时的反馈这些时间，特别是将会有延期、将添加项目成本、质量将会有问题的苗头等等，更加必须提早汇报，使项目经理的上级和客户能及时并适时调整工作计划。沟通产生要求沟通是双向的，沟通必须能够符合接收者的利益，那样才有说服力。这就要求双方都要有良好的沟通方式，特别是良好的沟通又能达到双赢

26、的目的，一致的沟通有助于组织促进项目更新。口头的沟通能力同时似乎又是职位提升的关键因素。于是，沟通又必然的产生要求职位上成功，项目的早日完成，对问题作出恰当的回应，小到假期薪金等等都要沟通来达到目的。 信息不是沟通分清哪些是沟通哪些是信息，对于用于沟通的信息必须明确简练、醒目，避免沉没于信息之海中。 信息也可用于沟通，但信息过于的生搬硬套，一个文字性的文件是并不能起到沟通的作用的，项目经理并不是想集中于信息中而是想了解项目里工作的人员，并与之建立起相互信任的关系。实施情况报告 定期报告 阶段评审 紧急报告 实施情况报告定期报告在某一里程碑的时间内将所完成的工作量向上级汇报。某一特定的时间内将所完成的工作量向上级汇报。主要涉及项目成员周进展报告和项目周报前者由项目组成员上报项目经理；后者是对前者的总结，由项目经理上报高层经理；需写明当前状态、进度完成情况、当前问题和下周计划等。 项目定期报告的主要内容就包括：当前是什么状态？在什么