项目管理报告

项目管理软件开发项目 第三项目组 项目经理 :张禄 成员 :时黎 朱小钢 苏清泉 王悦 李富春 团队文化 : 以人为本 ,科学管理 , 团结协作 ,争创一流。 精神 : 团结拼搏 ,务实求新 , 追求卓越 ,持续改进。 目 录 项目组工作安排 第 1部分 项目目标、工作描述表 第 2部分 项目组织机构安排 第 3部分 项目里程碑计划 第 4部分 项目工作分解结构 第 5部分 项目责任分配矩阵 第 6部分 项目网络计划图 第 7部分 项目人力资源计划 第 8部分 项目费用分解 第 9部分 项目费用及费用、进度控制 第 10部分 项目风险分析及应对计划 第 11部分 项目的沟通管理 第一部分 工作描述及组织机构设计 报告人 :张禄 序号 姓名 职务 负责工作 1 张禄 项目经理 目标描述、团队分工、项目管理组织机构设计 2 李富春 项目成员 拟定项目重大里程碑计划、分解工作分解结构 3 时黎 项目成员 确定工作先后关系、估计执行时间、编制项目甘特图和网络计划图、确定关键工作 4 苏清泉 项目成员 制定人力与资源使用计划、进行费用分解和分析 5 王 悦 项目成员 分析项目实施过程中的风险、提出应对计划 6 朱小钢 项目成员 分析项目实施过程中的信息、冲突、沟通等问题并提出具体操作方案 团队分工 项目背景分析 某企业由于业务发展的需要，决定采用项目管 理的方式进行管理，为了更有效地对项目的执 行过程进行控制，决定开发一套项目管理软件 以满足这一需求。该企业准备投入 100万元， 时间要求 2025 周，该软件项目的计划开始日 期为 2002年 1月 1日，企业要求该软件正式验收 前要试运行 4周以上的时间，并根据试运行情 况进行适当修改。 项目管理组织结构 假设该企业一直采用项目管理的形式，主要的职能部门有人力资源部、财务部、 设计部、研发部、采购部、质检部等。由于项目的开发需要企业各部门的通力合作， 为此，企业领导决定采用项目管理的模式进行管理，委托一位项目经理全权负责该项 目的开发，同时成立企业项目管理软件开发项目管理办公室。 对于项目管理软件开发的组织管理结构，可能采取的组织形式有只能式、矩阵式 、项目式。职能式组织结构适用于规模较小、偏重于技术的项目，而不适应与项目环 境的变化较大的项目。同职能式组织结构相比，在对付不稳定的环境时，项目组织结 构显示出了自己的长处，既来自于项目团队的整体性和各类人才的紧密合作。同前两 种组织结构相比，矩阵式组织结构在充分利用企业资源上显出了巨大的优势。它融合 了前两种组织结构的优点，在进行技术复杂、规模较大的项目管理时显出了明显的优 势。的难度，以及原有企业智能型组织的特点，为了保证项目的顺利进行，企业决定 采用强矩阵 基于项目实施的特点，即技术方面的复杂性和组织协调方面组织结构的形式，如 下图所示。 该组织结构的特点和项目办直接归总经理领导，以保证项目的开发成功，也说明了 企业领导对该开发项目的重视程度。项目办通过横向的职能机构协调利用企业现有资 源，各职能部门在项目办的协调下相互协作，使得项目的开发中各职能部门的作用井 井有条。由于矩阵式组织结构形式的特点是将按职能划分的纵向部门与按照项目划分 的横向部门结合起来，以构成类是矩阵的管理系统，这与本项目的特点是吻合的。 组织机构选择 组织结构 影响因素 职能式 矩阵式 项目式 本项目特点 不确定性 低 高 高 高 所用技术 标准 复杂 新 复杂 复杂程度 低 中等 高 高 持续时间 短 中等 长 长 规模 小 中等 大 中等 重要性 低 中等 高 高 客户类型 各种各样 中等 单一 单一 对内部依赖性 弱 中等 强 中等 对外部依赖性 强 中等 强 强 时间限制性 弱 中等 强 强 9 n 项目组织结构图 总经理 人力资源部 采购部研发部财务部设计部 职 员 职 员 职 员 职 员 职 员 职 员 职 员 职 员 职 员 职 员 职 员 职 员 职 员 职 员 职 员 职 员 质量部 项目经理 职员 职员 职员 职员 项目管理办公 n项目组组织机构 项目经理 设计组 开发组 财务组 采购组 市场组质检组 第二部分 项目里程碑确 工作分解 责任分配矩阵 报告人 :李富春 项目的里程碑是项目实施过程中，对项目实施进度有重要影响的关键事件。它对进度状态检查 有重要意义。根据本项目特点，我们确定了里程碑事件。里程碑计划图如下： 序 号 任务名称 月份 1 2 3 4 5 6 6 7 8 9 10 11 12 13 14 16 17 18 19 20 21 22 23 24 1 需求分析完成 2 方案设计完成 3 开发结束 4 集成测试结束 5 试运行结束 6 验收完成 n 项目的里程碑计划 n项目工作分解结构（ WBS） 目的 为保证项目结构的完整性，让相关方了解项目过程，将目标分解到单 元便于、人力资源计划安排、责任分配、费用预算和检查、控制。 分解过程 以项目范围和目标为主导，由上而下，由粗到细进行分解。形成树型 结构，直到具体明确。子项目一般要有一定的整体性和独立性。 分解层次 根据项目的特点和性质，本项目的工作分解结构按照项目管理软件开 发的流程进行分解和编码，如图下所示 n软件开发项目工作分解结构（ WBS) 100 项目管理软件开发 110 需求分析 120 方案设计 130 开发 140 测试 170 项目管理 121 系统设计 122 功能设计 131 项目信息录入模块 133 项目网络计划绘制模块 134 项目甘特图模块 135 执行信息录入模块 141 分模块测试 142 集成测试 160 验收 150 试运动这行 136 报表输出模块 151 初试运行 152 系统完善 132 项目时间计划安排模块 责任矩阵的编制方法 责任矩阵的作用： 将 WBS分解得到的工作任务落实到项目有关部门和个人， 从而明确他们在组织工作中的关系、责任和地位。 编制方法： 以组织单元为行，工作单元为列，形成责任矩阵。 责任矩阵可以应用于 WBS的任何层次。 下面是以最末层 WBS分解结果建立的责任矩阵图。 20 项目的责任分配矩阵 编号 任务名称 项目经理 设计组 开发组 财务组 采购组 质检组 市场组 110 需求分析 P F C X X X C 120 方案设计 P F C X X C C 121 系统设计 F C X X C C 122 功能设计 F C X X C C 130 开发 131 项目 信息录入模块 C C F X X C C 132 项目网络计划绘制模块 C C F X X C C 133 时间计划安排模块 C C F X X C C 134 项目甘特图模块 C C F X X C C 135 执行信息录入模块 C C F X X C C 136 报表输出模块 C C F X X C C 140 测试 141 分模块测试 C C F X X X X 142 集成测试 C C F X X X X 150 试运行 151 初试运行 F C C C C C C 152 系统完善 C C F X X C C 160 验收 P F C X C C C 170 项目管理 F X X X X X X 图例： P-批准 F-负责 C-参与 X-协作 参与项目各方的责任一般通过责任分析矩阵的形式进行表达，这种表达形式的优点是直观地将项目责任方的责任 和权利完整地表达了出来，便于项目各方进行有效的协调，每项工作都有负责、有协作。责任分配的依据是项目 组织机构及工作分解结构。 第三部分 网络计划及甘特图 报告人 :时黎 网络计划工作表 网络计划图 项目管理软件开发项目 第四部分 人力资源及费用计划分析 报告人 :苏清泉 责任矩阵的编制方法 责任矩阵的作用： 将 WBS分解得到的工作任务落实到项目有关部门和个人， 从而明确他们在组织工作中的关系、责任和地位。 编制方法： 以组织单元为行，工作单元为列，形成责任矩阵。 责任矩阵可以应用于 WBS的任何层次。 下面是以最末层 WBS分解结果建立的责任矩阵图。 20 人力资源计划表 每周按 5工作日算 人力资源负荷图 费用估计目标 额度 投资额 人力费用 其它费用 总费用 预留 软件开发 1000000 633800 266200 900000 100000 说明： 预留费用用于意外开支和保质期的开支 编 号 任务名称 资源名称 工作量 (工 时 ) 数量 (人 ) 工期 (日 ) 人力费用 其它费用 总费用 费用 /23周 100 项目管理软件开发 115 110 需求分析 设计师 80 2 5 4800 19000 23800 23800 120 方案设计 20 0 121 系统设计 设计师 240 3 10 21600 24000 45600 22800 122 功能设计 设计师 240 3 10 21600 24000 45600 22800 130 开发 55 0 131 项目信息录入模块 工程师 560 2 35 22400 21000 43400 6200 132 时间计划安排模块 工程师 1120 4 35 89600 21000 110600 15800 133 项目网络计划模块 工程师 720 2 45 28800 21600 50400 5600 134 甘特图计划模块 工程师 1440 4 45 115200 22500 137700 15300 135 执行信息录入模块 工程师 1600 4 50 128000 30000 158000 15800 136 报表输出模块 工程师 1760 4 55 140800 22000 162800 14800 140 测试 10 0 141 分模块测试 工程师 80 2 5 3200 20000 23200 23200 142 集成测试 工程师 80 2 5 3200 20000 23200 23200 150 试运行 20 0 151 初步试运行 管理人员 360 3 15 16200 15600 31800 10600 152 系统完善 工程师 80 2 5 3200 32000 35200 35200 160 验收 工程师 80 2 5 3200 5500 8700 8700 合 计 601800 298200 900000 资源费率：设计师 =30元 /工时；工程师 =20元 /工时；管理人员 =15元 /工时 项目管理软件开发项目费用分解表 项目管理软件开发项目预算曲线表 项目管理软件项目费用累计曲线 项目管理软件开发项目挣值分析曲线 项目管理软件开发项目挣得值分析 挣得值分析图是对项目执行到第 13周得 费用执行情况得统计。 从图中可以看出 BCWPACWP,说明费用有节余。 第五部分 风险分析 报告人 :王悦 项目风险管理 本项目是一个项目管理软件开发项目，根据 项目的特点决定了项目存在的风险较多，项目风 险管理的成败直接影响到项目实施的成败。 通过 头脑风暴法和专家评判法，项目组认为在众多的 风险因素中关键技术人员变动、核心技术开发难 度大、项目总成本的有效控制、进度控制等因素 是项目风险的主要因素应特别予以重视并采取相 应的应对措施。 43 项目风险管理流程 风险监控 风险评估跟踪修订 变更 计划 风险识别 风险量化 风险应对措施 45 项目风险管理 我们可以根据风险控制与项目事件发生 的时间将风险管理划分为三个部分： 事前控制 风险管理规划 事中控制 风险管理方法 事后控制 风险管理报告 项目风险规划 将风险管理的手段贯穿于项目实施生命周期的全过 程。如在项目概念阶段成立风险评审委员会对项目潜 在的风险进行评审等。 在该项目的费用预算中提取一定比例的风险准备金 。 根据项目的各里程碑制定项目实施的备用方案。 采用项目风险管理的工具及方法进行风险分析。 建立利益相关方应对风险的快速处理机制。 44 项目风险管理 -风险识别 本项目为项目管理软件编制项目，针对 项目特点，我们项目部全体人员在收集 资料、了解项目的所有前提、假设制约 因素，类比了同类项目档案后，采用头 脑风暴法和经验法对所有潜在的风险可 能进行了识别分类，共识别出该项目风 险有：技术风险、时间风险、人员风险 、管理风险、市场风险、费用风险和组 织结构风险等 项目风险管理 项目风险包括 ： 技术风险 ：核心技术开发难度大、需求分析不明确、软件功 能不齐全、设计是否合理等存在着风险，设计缺陷，后备措施 不足 费用风险 ：费用分配合理性、成本的控制、项目总成本的有 效控制、工作效率的控制。 时间风险 ：软件需求定义书无法按期拿出、软件检测试阶段 不能正常完成、进度控制。 人力风险 ：选人不当、关键人离开、个性差异、团队意识、 技术观念差异、各项目组衔接不及时。 管理风险 ：核心技术的控制问题及产权保护、机制不适应、 决策失误、过程控制不严、合同管理不当、信息录入不当。 市场风险 ：定价太高、 新产品替代、定位不准新产品替代、定位不准 项目风险管理 -风险评估 在以上分析得出的潜在风险中，我们按 各种因素出现的概率和对项目造成的危 害程度两方面进行排序，得出主要风险 有：技术风险、时间风险、人员风险、 管理风险、市场风险和费用风险。 项目风险管理 -风险控制 项目管理过程中，对风险进行识别、评 估的目的就是为了降低项目风险的负面 效应制定风险应对策略和技术手段，本 项目经过项目部全体成员研究，对可能 存在的潜在风险采取应对措施如下： 风险控制 制定应对风险的程序和方法主要有以下四种： 规避。通过变更项目计划消除风险或风险的触发条件，使目标免 受影响。这是一种事前的风险应对策略。例如，采用更熟悉的工 作方法、澄清不明确的需求、增加资源和时间、减少项目工作范 围、避免不熟悉的分包商等。 转移。不消除风险，而是将项目风险的结果连同应对的权力转移 给第三方（第三方应该知道这是风险并有承受能力）。这也是一 种事前的应对策略，例如，签订不同种类的合同，或签订补偿性 合同。 弱化。将风险事件的概率或结果降低到一个可以接受的程度，当 然降低概率更为有效。例如，选择更简单的流程、进行更多的实 验、建造原型系统、增加备份设计等。 接受。不改变项目计划（或没有合适的策略应付风险），而考虑 发生后如何应对。例如制定应急计划或退却计划、甚至仅仅进行 应急储备和监控，待发生时随机应变。 项目风险评估与处治（表 1） 来源来源 内容内容 影响结果影响结果 危险识别危险识别 解决措施解决措施 处置方法处置方法 技术技术 风险风险 需求分析不明确需求分析不明确 软件不符合市场要软件不符合市场要 求求 A 加强客户沟通与市加强客户沟通与市 场调研场调研 减少减少 设计缺陷设计缺陷 软件功能不齐全软件功能不齐全 A 配备好的技术人员配备好的技术人员 接受接受 时间时间 风险风险 软件需求定义书无法按期拿软件需求定义书无法按期拿 出出 影响后续工作的进影响后续工作的进 行行 A 加快工作节奏加快工作节奏 减少减少 软件检测试阶段不能正常完软件检测试阶段不能正常完 成成 进度无法按时进度无法按时 B 软件测试阶段安排软件测试阶段安排 充足时间充足时间 接受接受 人员人员 风险风险 代码编制量较大，人力资源代码编制量较大，人力资源 不足不足 工期拖延工期拖延 B 集中力量，保证重集中力量，保证重 点工作正常进行点工作正常进行 接受接受 技术观念技术观念 工作效率工作效率 C 加强培训工作加强培训工作 回避回避 关键人物离开项目关键人物离开项目 项目延误或失败项目延误或失败 A 配备良好条件配备良好条件 回避回避 市场市场 风险风险 定价太高定价太高 项目失败项目失败 C 严格控制项目成本严格控制项目成本 减少减少 新产品替代新产品替代 项目失败项目失败 B 加快研制步伐加快研制步伐 减少减少 定位不准定位不准 项目失败项目失败 A 加强概念期工作加强概念期工作 减少减少 项目风险评估与处治（表 2） 来源来源 内容内容 影响结果影响结果 危险识别危险识别 解决措施解决措施 处置方法处置方法 管理管理 风险风险 合同合同 项目失败项目失败 A 加强管理加强管理 回避回避 各项目组衔接不及时各项目组衔接不及时 时间拖延时间拖延 C 加强管理加强管理 回避回避 费用费用 风险风险 费用分配不合理费用分配不合理 影响工作的效率影响工作的效率 B 优化费用分配优化费用分配 减少减少 成本控制成本控制 直接导致产品定直接导致产品定 价上涨价上涨 A 加强管理，控制加强管理，控制 费用费用 减少减少 项目风险管理 -风险监控 我们项目组对可能存在的风险进行了有效的识 别和合理分析，并制定了一系列相应的措施进 行规避风险。但仅有这些还不够，还需要在风 险事件发生时跟踪识别旧风险，再识别剩余风 险和新出现的风险，及时发现新风险，保证风 险计划的顺利实施并实现项目风险管理循环过 程。 风险监控的目的 一是监视风险的状况，例如风险是已经 发生、仍然存在还是已经消失； 二是检查风险的对策是否有效，监控机 制是否在运行； 三是不断识别新的风险并制定对策。 风险监控常用的方法 风险审计：专人检查监控机制是否得到执行。 并定期作风险审核，例如在大的阶段点重新识 别风险并进行分析，对没有预计到的风险制定 新的应对计划。 偏差分析：与基准计划比较，分析成本和时间 上的偏差。例如，未能按期完工、超出预算等 都是潜在的问题，主要是挣值费用分析 技术指标：比较原定技术指标和实际技术指标 差异。例如，测试未能达到性能要求，缺陷数 大大超过预期等。 第六部分 沟通管理 报告人 :朱小钢 沟通管理 本项目中，我们认为：对于成功，威胁最大的就 是沟通的失败。 本项目成功的三个主要因素分别为：某企业的 积极参与，明确的需求表达，企业管理层的大 力支持。而这三要素全部依赖于良好的沟通技 巧，特别是非信息技术人员。 沟通管理的目标是及时并适当地创建、收集、 发送、储存和处理管理软件项目的信息，标准 的项目沟通包含沟通计划、信息传递、实施情 况报告、管理收尾共四个过程。 沟通计划 沟通信息类型 ：会议广播文件陈述 合时性 ：项目干系人：项目发起人：项目经理：项目 小组）：测试小组：结构管理小组）：技术小组 采用轮式沟通方式 沟通计划的方法 对于不同部门采用不同语言文字沟通 注意对各部门的双向沟通和沟通方式 注意非正式渠道沟通 头脑风暴专家访谈 历史资料 检查 表 评估表 沟通计划工作汇报方式 明确表达项目组成员对项目经理或项目经理对上级和 相干人员的工作汇报方式，明确什么时间，什么形式 。 项目组成员每周五对项目经理张总通过 EMAIL发送周 报，每周一上午项目经理与业务经理沟通后完成项目 周报，下午 1： 30召开项目组例会，会后由项目经理向 高层经理提交项目周报 张总对直接客户和公司每月一号通过 EMAIL发月报的 方式 紧急汇报通过电话及时沟通；每两周项目组进行一次 当前工作沟通会议；每周同客户和上级进行一次口头 汇报。 沟通计划文件保存方式 首先在公司服务器里划分专门的存储空间保存 信息、信息读写分为不同的权限，明确划分用 户信件储存区域、会议记录储存区域、工作报 告储存区域、项目文档（需求、设计、编码、 发布程序等）储存区域、辅助文档等的存放位 置，及相应的读写权力。 收集和保存不同类型的信息，遵循公司项目实 施规章制度，将与项目有关的重要工作建档。 沟通计划联系方式 设立专用于项目管理中所有的相关的人员的联系方式 的小册子和文档，其中如项目组成员、项目组上级领 导、行政部人员、技术支持人员、出差定房订票等系 统中相关的人员，座机、手机、职能等等 ，相应的一一列上，做到简洁又要明了，特殊人员标 上细小的标注，能够做到在一打开小册子的同时就能 将所有的相关人员的资料了然于胸，正所谓知已知彼 ，这样一来，很多在平时大费周章的事，就能在养成 的良好的习惯中，轻松做到。 沟通计划其他 统一项目文件格式：制订项目本身统一的文件 模板，是正规管理的一部分，所以必须统一各 种文件模板，并提供编写指南。 设立 沟通计划 维护人：由项目组朱小钢担 任，本计划在发行变化时，由该同志进行修订 ，并对相关人员 发送。 信息问题 信息主要为项目每个阶段服务 信息类型：内部外部历史 信息的收集和传播；书面谈话集体 技术形 采用线路的方式 信息发送 沟通是一种感知 沟通是一种期望 沟通产生要求 信息不是沟通 沟通是一种感知 沟通一定是双向，必须保证信息被接收者接到了。所有的沟通方式，必 须有回馈机制，保证接收者接收到。 电子邮件进行沟通，无论是接收者简单回复 “已收到、 OK”等，还是电话 回答收到，但必须保证接收者收到信息，并回应信息已经接收到。 信息收到必须保证理解是正确的，很多事情信息收到了，但被错误的理 解了，很多信息是传达到了，但却被错误理解了。 发送方的正确表达、接收者的正确理解是非常重要的。要求发送者进行 信息发送，接收者进行理解后进行细化并进行回复邮件表达，这种表达 却是在确认自己理解了的同时去转叙或者执行的结果，而不是复述。 沟通是一种期望 在软件项目管理中，项目不同干系人是有不同的沟通需要的。 项目组成员在具体的工作安排中他想明白那个职位是否符合他的 意愿等等，上级要了解接收者的期望，向下属传达工作安排的同 时还要了解他的意愿取向的问题，再采取相应的方法，调起其在 工作上的热情，从而促使其在工作的高效付出，在项目管理中如 让下属有反抗情绪的产生或者低效的工作，则是一个项目经理在 沟通上不得法的一个失败实例。 项目经理的上级和客户更加关心是进度的问题：时间是否会延期 、是否要添加成本、质量是否有保障等等。这对于项目经理来说 ，就应即时的反馈这些时间，特别是将会有延期、将添加项目成 本、质量将会有问题的苗头等等，更加必须提早汇报，使项目经 理的上级和客户能及时并适时调整工作计划。 沟通产生要求 沟通是双向的，沟通必须能够符合接收者的利益，那 样才有说服力。这就要求双方都要有良好的沟通方式 ，特别是良好的沟通又能达到双赢的目的，一致的沟 通有助于组织促进项目更新。 口头的沟通能力同时似乎又是职位提升的关键因素。 于是，沟通又必然的产生要求 职位上成功，项目的早日完成，对问题作出恰当的回 应，小到假期薪金等等都要沟通来达到目的。 信息不是沟通 分清哪些是沟通哪些是信息，对于用于沟通的 信息必须明确简练、醒目，避免沉没于信息之 海中。 信息也可用于沟通，但信息过于的生搬硬套， 一个文字性的文件是并不能起到沟通的作用的 ，项目经理并不是想集中于信息中而是想了解 项目里工作的人员，并与之建立 起相互信任 的关系。 实施情况报告 定期报告 阶段评审 紧急报告 实施情况报告 定期报告 在某一里程碑的时间内将所完成的工作量向上 级汇报。某一特定的时间内将所完成的工作量 向上级汇报。主要