项目管理培训
- 1. 项目管理
- 2. 项目定义在一定的时间、成本、品质、范围限制下，（短时期的）努力以创造特定产品或服务
- 3. 项目管理成功的因素必须就下列因素取得平衡： 范围、时间、成本、品质时间成本品质范围
- 4. 没有项目管理的特征项目总是落后，或不能达到要求 技术与处理过程没有标准 管理都是被动的，看不出价值 管理所需的资源、时间都不在计划中 项目似乎还都算“成功”，只是压力大，加班多
- 5. 为什么不用“项目管理”没有规划的习惯，不愿先期投资 公司、客户文化重视“执行”，而不是“管理” 知道要管理，不知如何管理 认为项目管理只是工具，不是体系
- 6. 为什么不用“项目管理”被项目管理的繁琐要求吓到 成员怕被控制，失去创造乐趣 高层怕因授权而失去控制 建立项目管理体系，成本太高
- 7. 项目管理将知识、技巧、工具、技术应用在项目的各种行动上，以获得令人满意或超出期望的项目成就 构成期望的两因素 项目应交付的成果 项目管理的方法体系
- 8. 项目管理的目的项目管理的主要目的是有效运用下列资源： 人力 设备、设施 物资、金钱 资讯/技术/通讯 外界资源供应
- 9. 项目管理的目的在下列条件下达到项目设定的目标 预算内 按时 客户预期的质量 能被客户认可、接受 合乎公司管理要求 满足客户其他的期望
- 10. 项目管理的优势更快地解决问题 不在项目范围外耗资源 防范未来的风险 更有效地与客户、成员、相关人士沟通，并能管理“期望” 在第一次就产出高品质的成果
- 11. 项目管理常见的问题项目各有特性，管理方法不尽相同 对项目管理不了解，不愿投资于培训 不注重项目管理的公司将逐渐被淘汰 上层领导没时间管项目，又不肯授权 直线层级核准，常导致项目进度落后
- 12. 项目管理常见的问题项目被项目成员的部门耽搁 项目成员局限一处，公司内了解该项目管理的，并知道管理成就的只有少数 项目管理经验累积不足，传递不顺
- 13. 成熟的项目管理特征采用一套系统管理项目，贯彻使用 建立“追求成熟的项目管理”公司文化，并传达给每位员工 项目一开始，就决心订定有效的计划 制定合乎现实的目标，以减少项目内容的变动
- 14. 成熟的项目管理特征明了成本管理与进度管理是密不可分的 选择适当的项目经理 为上层提供项目赞助者的利益讯息，而不是项目管理的细节 加强参与，支持一线经理
- 15. 成熟的项目管理特征管理重点在“应交付的成果”而非“资源的争取” 建立有效的沟通、合作和信任以加速项目管理的成熟度 与基层管理及所有队员分享成果 屏除无效益的会议
- 16. 成熟的项目管理特征尽早确认问题，迅速有效解决 定期检讨进度 采用项目管理软件为工具，但不能以此替代规划及人际管理技巧 正式建立所有员工培训制度，并定期检讨更新
- 17. 项目管理的方法体系自行发展 外购： 瀑布式、RAD、Agile，等 外购再个性化 不论何种方法体系，都管理九大领域
- 18. PMBOK项目管理五大阶段启动 意识到必须开始一个项目，并愿意给予承诺 计划 （开展） 为项目预定达成的企业目标订出可行的行动计划和时间表 执行（实施） 协调相关人员及资源将计划逐步实行
- 19. PMBOK项目管理五大阶段控制 对执行过程实行监控及评测，必要加以纠正，以确保项目目标的达成 收尾 正式总结项目、接受成果
- 20. 项目生命周期依据管理控制的需要，罗列的连续的项目阶段 Reference PMBOK Guide, 1996 Glossary
- 21. 项目阶段举例制造业 成型 加强 制造 淘汰 审计
- 22. 项目阶段举例电脑软件业 概念形成 测试概念 规划 定义、设计 实施 修改
- 23. 项目阶段举例工程/建筑业 计划、收集资料 研究及基础设计 审查 细部设计 细部设计可行性确认 建造 验收与使用
- 24. 各阶段注意事项每一阶段都像项目，有自己的生命周期 阶段间有品质确认把关，确保应有成果能按要求交付 确知是谁在控制生命周期 公司内应将生命周期标准化
- 25. PMBOK项目管理九大领域
- 26. 项目管理十大步骤明确各种工作的定义 制定工作计划 工作计划管理 外控难题管理 范围管理
- 27. 项目管理十大步骤沟通管理 风险管理 文档管理 质量管理 规律管理
- 28. 项目与步骤（程序）项目：该做的事 步骤：如何做到
- 29. 项目的大小大小工时小型1-250小时中型251-2500小时大型2500小时以上步骤调整因素：重要性、经验、各阶段的需求。。。
- 30. 1。明确各种工作的定义
- 31. 工作定义的好处基于项目的定义，对于项目的目的、成果、范围、风险、成本、方法等，都有一致的认识，并获得同意 可以复查项目对企业是否仍然有意义 确认资源可以及时供应 有可供参考的盈亏标准 及早与客户共同熟悉项目管理程序
- 32. 需要清楚定义的工作项目成立的明确核准：尤其是未列入企业计划的 项目的定义：目标、范围、需求、假设、成果、预算等 企业明确核准项目正式开始：由项目保障人签字，确认项目定义
- 33. 需要清楚定义的工作项目工作计划：包含检查点，以确保项目可以适当继续 项目管理的程序：处理外控难题、沟通、风险、品质等程序 项目团队：所需人数、时间、技术
- 34. 项目的特征项目不是例行工作 项目有定义的起始日、终止日 每个项目有其特点 有范围、预算、特定成果、特定资源等限制
- 35. 项目经理的素养弹性、变通 主动、进取 善于沟通 有整合能力 敢做决定 能解决问题全盘认识 鼓舞人心 谈判协商 解决外控难题 以身教导 革新开放
- 36. 项目经理的素养善于规划、积极乐观、永不言败 销售大师、心理导师。。。 专业知识、技术与人际关系技术的平衡
- 37. 项目经理是项目综合管理的焦点 对项目成败负具体责任 献身于项目而非部门 负责部门间的协调 必须善于运用跨部门的综合计划及综合控制 PMI认为项目经理对所有的事负责
- 38. 项目经理的主要责任在一定的时间、成本、品质/技术要求下，产出该交付的成果， 负责管理预算、工作计划及所有项目程序（范围、风险、难题等） 作出所有必要的决定，包括变通方案或终止项目 对项目损益（盈亏）的责任
- 39. 项目经理的主要责任是客户、高层、部门沟通的中心 负责与各相关部门商讨“纪律” 尽可能解决所有外控难题 建立团队鼓舞士气 为项目成员设定合理、有挑战性的目标
- 40. 项目经理的困扰对跨部门成员没有权威 无权核准预算、费用 人微言轻，无法决策 政治斗争，非战之罪。。。 为项目经理责任下定义！ 要知道谁有权、什么程序能有行动
- 41. 项目保障人的责任 对外推展及谈判的主要人物 建立、维持与高层的关系、沟通主要问题 保障项目的资金、核准项目交付成果 对项目范围变更予否有决定权 协助项目经理进行规划、招募工作 协助项目经理找出并解决主要问题
- 42. 项目保障人的责任 对项目主要活动进展保持高度了解 参加项目指导委员会 处理合约主要事项 派定项目目标优先顺序 为项目经理阐释公司政策
- 43. 项目保障人的困扰有项目管理经验的项目保障人，常亲自参与细节，以致干扰其他成员工作 没有项目管理经验的项目保障人，可能有强的专门的技术或政治背景，常见树不见林
- 44. 为其他角色责任下定义项目团队队员： 明白要做的工作 将分配的任务细节规划出来 在期限内，预算中完成合乎品质要求的交付任务 随时向项目经理报告外控难题、变动和质量问题 主动沟通进度和期望
- 45. 为其他角色责任下定义客户：项目的直接受益人、团体 客户项目经理 部门经理 综合方案经理 项目总监、经理
- 46. 为其他角色责任下定义项目相关人士 项目审查委员会 项目指导委员会 使用者、专家、顾问
- 47. 为项目管理的组织结构下定义功能、部门结构 项目成员由同一部门构成，不足 纯项目结构 不同功能人员组成，重复 矩阵式结构 专业的“项目管理中心”
- 48. 矩阵式结构项目管理管理结构（报告结构）复杂 项目成员必须很懂“时间管理” 很多矛盾 成员时间分配、优先顺序、政治、情绪 解决同样的问题，需要更多人、部门、资源参与 需要主动的、高超的沟通技巧维护成员
- 49. 矩阵式结构项目管理在定义项目、分配资源时，取得支援部门领导书面承诺 将《项目定义书》、《工作计划》事先送达队员的部门领导 亲自与对方领导对话，确认资源会按时到达 再度提醒对方领导
- 50. 矩阵式结构项目管理敏锐觉察是否有延误迹象 及时向项目保障人提出排序升级要求 必要时，按程序提出“外控难题” 即时拟订、实行应变方案，以减少影响
- 51. 矩阵式结构项目管理确定单一沟通人、程序 一视同仁，重要活动不可遗漏 正确掌握项目进展，注意借口 与对方部门领导主动联系，多赞扬 工作计划、定义必须更清楚、灵活 面对现实，及早修正
- 52. 矩阵式结构项目成员你不可能同时做所有老板们的事 有组织地排定优先顺序，集中火力 按期限、公司内部的重要性 与其他领导打招呼 取得部门领导支持
- 53. 矩阵式结构项目成员与项目经理单独面对面会议，弄清要求及问题 减少猜测、改正时间浪费 不可因不明白而不理、不开始 与所有老板一同开会 可以组合、解决矛盾 不当传话人
- 54. 提高士气授权与支持 外控、范围、政治、更改承诺、增加风险 及早参与项目重要决定 一起进餐、笑、闹、埋怨 偶尔出去一起活动，老板出钱 诚实对待员工
- 55. 提高士气在外开会，要求队员每人提出赶上进度4-5对策 提供资讯，明白项目目标及地位 注意人员变动的影响 注意个人关系变动对士气的影响 不在外面批评队员
- 56. 提高士气不批评竞争对手（尤其是内部的） 队员共同制定纪律 维持纪律 提高队员的技术水平 给队员个人成功及受表扬的机会 奖、惩要及时
- 57. 提高士气增加工作挑战性 增加学习新技术机会 环境、设备、待遇、工作时间、方式的改进 建立对项目的共识 停止指责，定义成功、职责，转移焦点
- 58. 提高士气经常与每位队员个别交流 确认队员明白任务及期限 每月至少一次 在“中性”的地点 要有准备： 记录、改进事项、期望、下次复审的时间 下次要谈的改进事项
- 59. 提高士气经常与每位队员个别交流 留一半时间给队员发泄 不谈项目经理的难处，不谈公司大事 让队员多说
- 60. 提高士气换项目经理 解释、保卫、指责的邮件增多 里程碑没有按时达到 越来越多的小会议 项目进度报告不清，更新不勤
- 61. 纪律纪律是保障项目成功的重要条件 纪律是团队的灵魂 纪律的目的是在鼓励正当行为 对目标有益的纪律才值得推行
- 62. 如何建立纪律设定实际的目标 对遵守纪律许下个人承诺 有跟踪并严格执行的纪律 强制承诺，从上到下，贯彻纪律
- 63. 为项目下定义的程序从以前相关项目的成果、客户的可行性分析、成本/利益概算等报告、邮件、等收集资料 从项目保障人、领导那里了解核准《项目定义》的流程 会见所有对项目有影响力的经理、客户，以了解他们的看法和定义
- 64. 为项目下定义的程序写出《项目定义》草稿，特别描述“读者” 而非“项目经理”的利益 准备《项目工作计划》草稿，尽量详细 书面记录各种《项目管理程序》 将《项目定义》与《项目管理程序》发出，征求反馈、求得共识
- 65. 为项目下定义的程序根据反馈更新文档 如时间允许，再一次送出已更新文档，征求意见，并再次依反馈更新 依照已定义的核准程序寻求核准 将核准的《项目定义》与《项目管理程序》发到每一位有关人员 项目即将正式开始
- 66. 为项目下定义的技巧《项目工作计划》与《项目定义》是互补的 将大项目分割成许多小项目 技术、环境变化，假设也跟着变化 越大、越远，越无法清楚描述 太长的延误，有失去公司支持的风险
- 67. 为项目下定义的技巧以“综合方案” （Program）的方式管理相关的小项目 明确项目组织架构所有角色的责任
- 68. 为项目下定义的技巧规划适当行动以加速正式取得核准 必须取得项目保障人、主要参与人的书面核准 其他相关人士，可以设定期限，取得默许 明白告诉其他关切本项目人士，文件只供参考
- 69. 为项目下定义的技巧客户可能无法提供足够资料 只定义你现在所能确定的项目 剩下的由下一个项目去定义
- 70. 为项目的成果下定义项目目的简介：什么、为何 范围：尽量详细 所需时间估算：包含估算方法、假设 成本估算：人工、及其他费用 完成日期估算：启始日、完成日
- 71. 为项目的应交付成果下定义主要假设 主要风险 主要方法 所需核准人名单 项目管理程序
- 72. 为项目的目标下定义主要目标（Goal） 宏观描述项目想要得到的成就 可能需要很大改动才能成功 应该与企业利益结合 难测量 综合多个项目应该可以达成
- 73. 为项目的目标下定义一般目标（Objectives）合乎SMART Specific-simple：简单、明确 Measurable：量化、可量 Achievable：实际可行 Reward-related：与赏罚有关 Time-bounded：与时间捆绑
- 74. 2。制定工作计划
- 75. 制定工作计划的程序细读《项目定义》确实了解各项要求、条件 采用WBS（Work Breakdown Structure）将工作逐层分解： 从大块工作着手，顺序目前不重要，可以用任何合理估算基准 检查所有细块，试着估算。有超过基准的，再分解
- 76. 制定工作计划的程序继续分解至没有任何工作细目超过估算基准 估算所有工作细目的工作量 产生网络分析图（工作顺序图） 在工作细目中，大致排序 检查排序，找出逻辑关联重新排序
- 77. 制定工作计划的程序将所有活动及依存度录入软件 结束-开始：活动B开始前活动A必须结束 买了硬件、安装软件； 开始-结束：活动B结束前活动A必须开始 很少；连续的烟火；新产品与旧产品生命周期 开始-开始：活动B开始前活动A必须开始 空中与地面攻击； 结束-结束：活动B结束前活动A必须结束 客人结帐、餐厅打烊
- 78. 制定工作计划的程序录入已知日期限制 分派资源 就已知工作量、资源及性质条件，由软件计算项目总体时间表 检查每人工作量，尽量将工作量平均分派 计算项目完成日期、人工成本
- 79. 制定工作计划的程序调整各项变数，以期准时完工 订定里程碑 如果满意，保存这份工作计划为日后对照基础 决定是否跟踪实际工时
- 80. 估算工作计划开始前： 清楚了解所要估算的工作，避免估算不懂的工作 找当事人、有经验的人帮忙 找出所有的限制、条件 用至少两种方法估算、验算
- 81. 估算工作量：越精确的估算，需要越多的工作细节 应用估算方法做出初算 如果确知某资源价钱，用实际数目 单独另条加上不确定因素的缓冲时间（10-50%）
- 82. 估算工作量：单独另条加上项目管理时间（15%） 别忘了加上间接帮手的时间 考虑重做的时间 将上述所有工作量相加 太高？太低？调整。。。 将所有假设记录留底
- 83. 估算工作期：描述工作期必须加上完成目标日 估算每日有效工时 检查人数，注意加人与效率的衰退 祛除假期、培训等事先可知的日子
- 84. 估算工作期：检查兼职人员时间素质 计入延迟、等待时间 找出所有可同时进行的工作，调用资源 将所有假设记录留底
- 85. 估算人工成本：工作量乘钟点工钱，找出公司政策 计入其他费用：软、硬件、出差、培训、设施、团队建设、维护（15%）、客户支持等 将所有假设记录留底
- 86. 估算WBS基准：没有硬性标准，将工作细分至有意义的最小单位是起目的 大型项目中，工作细目不该超过80小时，中型项目40小时，小型20 对长期将来的工作可能无法估计，分成数个连续项目，实在不行，可以大过WBS基准，但增加了风险
- 87. 估算WBS基准：将工作细分至小单位能帮助成员了解任务 工作细目的工期不应超出项目工作报告的周期
- 88. 估算方法历史经验：最好的方法 类比：接近的方法，包括比率计算 专家意见：常得到行业内其他同业的资料 专家群意见：多位专家的意见，试者找出一致性 WBS：细目容易估算
- 89. 估算方法PERT（Program Evaluation and Review Technique）：最好的、最差的以及最可能的估算，加权平均 （P+4M+O）/6 参数模型法：参照模式变动参数加以计算
- 90. 估算的其他考虑分阶段估算 变动成本与固定成本 时间限制型、资源限制型 会议及管理 以范围或不准度表示 加权风险：蒙地卡罗模型
- 91. 估算的其他考虑团队变动时，要复算 是否加上客户的成本、工时？ 不可期望一切都会顺利 客户说你估的太高 有无我不知的因素 功能及需求可以降低吗 不确定因素降低了吗 有更多细节可以精确估算了吗
- 92. 估算的其他考虑除数字外，给客户完整的估算报告 你所了解的工作内容 你的估算程序 用的方法 估算的实际工作量、工作期、成本 详细的估算资料 所有的假设 不确定因素（风险）程度、加成范围
- 93. 撰写项目简介项目简介是《项目定义书》里必要的一章 为没时间、或不了解项目的人描述《项目工作计划》 可以从组织、环境对项目的影响说起，序时介绍项目有关里程碑的活动 将内容与读者的利益绑在一起
- 94. 撰写项目简介可以讨论公司其他战略对本项目的影响 表出预算、工作量、时间、品质等的限制对本项目的影响 指出任何会影响本项目的公司标准 说明任何公司或行业的优秀实践对本项目的影响 说明在许多方案中，你为何选中本方案
- 95. 撰写项目简介说明将来如何维护、客户支持，又是如何将这些考虑在项目中 讨论其他相关的已完成、正进行或暂停的项目与本项目的关系 指出任何新科技的应用及进展 说明任何外界资源的需要及应用情形
- 96. 3。工作计划管理
- 97. 工作计划管理程序每星期检讨《工作计划》一次 在管理软件上更新完成的活动、成本、时间 检查、记录该完成却未完成的活动，与责任人确认原因及对策，修正相关《工作计划》 执行软件检查是否仍能按时完成项目
- 98. 工作计划管理程序检查有无其他原因影响进度，将更新版《工作计划》与原始版比较，检查导致不同的原因 检查预算耗用与项目进度的关系，有无计划外的活动在进行 检查有无其他不好的迹象： 项目早期就出现超支、进度落后 有变数在项目早期就异常，而且加大
- 99. 工作计划管理程序检查有无其他不好的迹象： 有已完成的活动还在进行 需要加班才能赶上进度 士气逐渐低落 应交付成果或服务品质下降 品管、测试、管理时间缩水 交到“风险管理”程序处理
- 100. 工作计划管理程序检查项目PERT关键路径，找出任何影响关键路径的活动，迅速制定对策 调整其他活动《工作计划》，确保项目执行遵循原有估算 对无法遵循的估算作好修正的准备，立即与客户、保障人、领导沟通，准备应变 每月至少一次，修正《工作计划》，给予更多细节和接近事实的估算
- 101. 将进度拉回正轨更多地加班 增加关键路径资源 重新检查所有活动的依存性 检查受限于时间的活动 调换人力、资源 改进流程
- 102. 将进度拉回正轨增加总体资源 改变设计，增加并行活动 严格拒绝增加、改变范围 鼓舞队员，重新振作 提高士气 缩减范围
- 103. 控制费用不再支付加班费 换低成本资源 减少其他花费 改善流程 严格拒绝增加、改变范围 鼓舞队员，重新振作 启用备用预算
- 104. 交付任务活动名称 说明 开始及完成的日期 估算的工时 估算的成本 应交付的成果 与其他活动的依存 其他资源的协调
- 105. 队员抗拒《工作计划》管理程序笨拙，影响个人工作 怕因报告坏消息而受处罚 不认为《工作计划》管理的有效 对任何“控制”，出于自然的抗拒 程序不完整，无意义，别人不重视 项目经理自己不遵守 没有处罚或不良后果
- 106. 《工作计划》管理的依据依据完成百分比管理 问“什么时候完成” 依据要求完成日管理 成本是否按小时计算 按里程碑管理 可以整体对照进度，找出问题
- 107. 突发任务突发任务（Action Item）： 不在规划内的、需要跟踪的工作 没有必要修改《项目定义》
- 108. 突发任务管理任何队员都可提出 项目经理或指定责任人列入记录 分派给队员，简单估算工作量，同意后连同承诺完成日列入记录 如果发现需要许多工作，立即知会项目经理 在项目会议中追踪
- 109. 4。外控难题管理
- 110. 外控难题外控难题（Issue）： 是项目管理出现的重大问题 不解决会伤害项目的进行 必须借团队及项目经理以外的力量才能解决
- 111. 外控难题管理鼓励任何对项目有关人员都可提出，包括潜在的外控难题都要书面提出 项目经理或指定责任人列入正式记录 分派给队员调查，提出各种解决方案对项目预算、时间表的影响，如果解决问题需要变更项目范围，关闭此案，另行提交范围管理程序
- 112. 外控难题管理将外控难题、各种解决方案、对项目预算、时间表的影响一并提交项目保障人及其他适当人，寻求解决 记录解决方案或方向列入记录 对《工作计划》、预算、《项目定义》做必要调整 透过沟通管道与队员及有关人士告知处理状态
- 113. 外控难题管理技巧尽快处理以降低影响 项目经理或责任人必须负责寻求解决到底 难以解决常是因为难得到允许或难做取舍 延迟解决可能造成比找更好方案更大损失 根除原因，而不只解决现象 鼓励队员提出难题时，也提出个人解决建议
- 114. 外控难题管理技巧按程序处理，尽早让客户参与 设法将非常大的难题分割 难题常接踵而至，如相关，先解决看似祸根的；如不相关，则先解决负面影响大的
- 115. 分析难题的技巧鱼骨图分析法 以箭头画出不同类别原因 思维冲击创出许多原因 找出或投票选出最可能的原因 祸根分析法 一直问“为什么” Pareto法 统计发生次数用以决定顺序
- 116. 5。范围管理
- 117. 范围描述项目疆界 定义项目将交付什么，不交付什么 大项目，范围还定义所有受影响的组织、交易、资料形态等
- 118. 范围管理项目失败的两大原因： 没有作好《范围管理》 没有作好《项目定义》 就算项目经理做好了《项目定义》，难的是“把项目管成那个范围”
- 119. 范围管理如果《项目定义》没作好，绝对无法作好《范围管理》 如果《项目定义》模糊，或需要再解释，客户会认为“改变”在范围内，项目经理很难拒绝 《范围管理》意在“保护”现有经大家同意的《项目定义》
- 120. 范围管理通常项目经理认为《范围管理》就是对客户说“不” 有效的《范围管理》是让项目保障人说“不”
- 121. 范围管理的程序鼓励任何对项目有关人员书面提出可能需要的、潜在的范围变动 项目经理列入正式《范围变动记录》 派队员研究“调查变动所需时间” 如果所需时间会耽误原定时间表，则这调查必须先由项目保障人核准 如果项目保障人不准，则记录、结案
- 122. 范围管理的程序如果“调查变动所需时间”不超过WBS基准，且项目仍可在原定成本、工作量、工期内完成，则项目经理即可以核准 如果项目经理不准，则呈给项目保障人审核，依第4点处理 记录解决方案或方向列入记录 对《工作计划》、预算、《项目定义》做必要调整 透过沟通管道与队员及有关人士告知处理状态
- 123. 定义范围如果不清楚要交付什么，不知项目的界限，则根本无机会成功 范围管理是项目管理中最重要的一步 定义越多方面越好
- 124. 定义范围应交付的成果与不在内的举例（企业需求、现状评估） 在内的与不在内的，各程序的主要生命周期（分析、设计、测试） 在内的与不在内的资料种类（财务、销售、员工）
- 125. 定义范围在内的与不在内的资料来源或资料库（帐务、会计、薪资） 在内的与不在内的组织（人力资源部、制造商、供应商） 在内的与不在内的主要功能（决策支持、资料录入、管理报表）
- 126. 定义范围项目得到资金时，必有一些定义了的目标、成果 从项目保障人处寻求资料 定义“在内的”然后从最相关的定义“不在内的” 定义受影响的、需要的、允许的。。
- 127. 范围管理的技巧累积小变动，一起提出 项目经理来决定小的范围变动要求 不可用备用估算的资源来应允范围变动 适时冻结范围变动的请求 是项目保障人核准而不是客户核准
- 128. 范围管理的技巧老答应客户范围变动要求并不是“注重客户” 项目保障人对说“不”通常没有问题 范围管理，人人有责，杜绝徇私 可以设立范围变动管理中心
- 129. 6。沟通管理
- 130. 什么是沟通让对方明白自己的意思 让自己明白对方的意思 确定对方明白自己，并达到自己设定的目的 确定自己明白对方，并充分明白对方设定的目的
- 131. 沟通的重要沟通不良造成期望不同 产生矛盾常由于沟通不足，而非事件本身 所有项目沟通都要了解进度、状态 项目状态沟通以进度会议、进度报告为主
- 132. 沟通管理的程序进度会议： 客户应派代表出席 采用标准会议议程 是交换进度状态情报 不是解决问题的地方 每星期或两星期依次 每次不超过一小时
- 133. 沟通管理的程序进度状态报告： 每月项目经理应送进度状态报告给客户及相关人士 内容应包括财务现状 队员应每周或每双周交项目经理状态报告 通常星期一、二开进度会，星期五上午交状态报告
- 134. 沟通计划种类公司或法律规定的： 进度状态报告 进度状态语音信箱式报告 进度状态会议 项目指导委员会会议 财务报表 政府要求的各种报表
- 135. 沟通计划种类参考消息： 说明会 自由索取的项目说明资料 网上的项目说明资料
- 136. 沟通计划种类市场公关式的沟通： 项目新闻信 与重要相关人士的一对一会议 路演式的说明会 比赛节目、倒数计时 庆祝活动
- 137. 为项目打出名声创造项目品牌形象： 为项目取正面的响亮的名称 设计、创造一个“商标”图案 将名称、图案以纪念品方式推广 面对面、一对一的会议 午餐会、广告辞、客户答谢。。。
- 138. 沟通管理技巧进度状态会议要切题，讨论状态、外控难题、范围、风险 会议的重要目的是 肯定个人、团队成果 表扬特殊贡献 维护纪律 让队员互相了解现况 不是解决问题的地方
- 139. 掌握项目状态会议要素有议程，事先发给参会人员 有主席、召集人 事先通知参会人员需要带到的资料或准备 只邀请有关人员 准时开始、结束
- 140. 掌握项目状态会议要素主持人明确说明开会目的及期望结果 依照议程，注意时间控制，不要遗漏 有会议记录 结束前，总结所有任务分派，包括内容、负责人、期限
- 141. 沟通管理技巧使用标准格式报表、标准时间表 进度状态报告，报告期间内发生的： 根据《工作计划》完成的成绩 说明该完成而未完成工作的原因 遭遇的困难、影响及对应措施 变更范围的要求、新证实的风险 其他对读者有用的资料、讯息 不要烦琐、冗长
- 142. 沟通管理技巧使用附件说明细节，只发给有兴趣的人 越向高层报告，越少细节 项目经理综合队员报告，提出概要 选用最佳中介工具 创造鼓励报告真实状态的环境
- 143. 沟通管理技巧使用状态指示警示符号 管理沟通就是管理期望 明定完成沟通的期限日 选造项目品牌
- 144. 管理期望技巧建立共识 管理范围变动 照共识的期望交付成果 主动、防范未然的沟通 避免“意外”出现 情愿先告诉客户，不要客户先告诉你
- 145. 管理期望技巧定期检讨表现 必要时，调整期望，重新建立共识 与客户一起检查，确定完成所有期望事项，协商解决不能按期作到的事项
- 146. 7。风险管理
- 147. 风险定义将来的条件或环境下，可能存在外控的，如果发生了，会对项目有不利影响的难题 是潜在的、将来的、尚未发生的 风险管理是防止潜在难题发生的艺术，目的是增加项目的成功率
- 148. 风险管理的程序在定义项目时，就做风险评估 对每项风险加上发生等级 分为高、中、低 依影响的严重性及发生的可能性综合判定 发生的可能性又分极可能、可能、和不大可能
- 149. 风险管理的程序严重性/可能性风险等级高负面影响 / 极可能高高负面影响 / 可能高高负面影响 / 极可能中 / 低中负面影响 / 极可能中中负面影响 / 可能中 / 低中负面影响 / 不太可能低低负面影响 / 极可能低
- 150. 风险管理的程序为每一项高等级的风险，制定一个防范计划 列出防范步骤、责任人、完成日、和定期检查日 对风险的五种反应： 不理、监视、避免、转移至第三者、减低风险
- 151. 风险管理的程序为每一项中等级的风险，检讨是否需要制定一个防范计划 为每一项低等级的风险，检讨是否该将其改成“假设” 将防范计划内的活动列入《项目工作计划》，并密切监督
- 152. 风险管理的程序项目经理必须监督风险防范计划，确定计划被执行而且成功，如果效果不佳，应立即加上新的防范计划 项目经理必须定期就现有状况重新评判风险，加以修正
- 153. 假设假设基本上是极低的风险 “要求的资源会在需要时到位”是假设但 有风险 容易被推翻的假设应被列为风险 低可能、负面影响的事项为假设；高可能、正面影响的，也是假设 事项没有“不定性”，则为事实或空想
- 154. 风险管理客户并不期望“零风险” 风险不可怕，是项目的天性 风险与原因及后果有别，例： 在全国各分支机构一同安装升级 全国一同安装？ 有些地方不需要？不喜欢？ 不能按时完成？ 有些地方失败？
- 155. 风险管理为“未知风险”列预算 – 5% “已知风险”的管理费用应列入原始预算内 风险识别是全体的责任 检测风险与风险对策成本孰大
- 156. 风险管理风险管理失败时可用的借口： 事先准备替罪羔羊 说明自己忙于追求成果，无心之过，寻求宽恕 证明自己不是算命的，无从预测 装作轻松：“麻烦总是会发生的，没啥好愁的”
- 157. 风险因素如果项目落入“高风险”群，不代表项目会失败 – 你必须有防范计划 风险因素只是参考，经验可以降低风险 个别公司应累积过去风险因素，提供给所有项目经理参考
- 158. 8。文档管理 （略）
- 159. 9。质量管理
- 160. 质量质量最终有客户定义，代表交付成果与客户需求、期望的接近度 最好的、无缺点的并不代表好质量 质量管理是一种程序，是过程，是心态 质量管理是尽早发现错误、缺点以避免更大损失，生产时，不是“后”
- 161. 质量控制去检测生产中交付成果是否在客户可接受的范围内的行动 是持续的努力 由全体队员及项目经理负责
- 162. 质量确保关心产生交付成果的程序是否合格 与产品无直接关系 质量确保，才能较好地控制质量 项目经理、客户、第三方负责考核
- 163. 质量管理的程序制定质量管理计划，定义应交付成果的完整及正确的标准、质量控制的行动、质量确保的实施程序，证明、验证方法 记录所有活动在《项目工作计划》内 在执行项目中，确认所有质量控制、确保的行动都付诸实施 - 做产品查核 累积质量有关程序、规律，做日后参考
- 164. 产品（应交付成果）查核组织适当人选参加 定义查核阶段的完整及正确标准 如果可能，会前先送样品给查核员 执行查核 控制在一小时内 查核员应多问问题、关切和提建议
- 165. 产品《应交付成果》查核执行查核 情况复杂时，另会讨论，不必在此寻求共识 查核产品，不是查核人 如果生产程序或人有问题，另案讨论 记录突发任务
- 166. 产品（应交付成果）查核做结论 通过 – 合乎所有标准或虽有小瑕疵，可以改正而不需要复检 不通过 – 不合标准，无法接受，需要改正而且复检。记录并加入《项目工作计划》追踪。安排复检 将结果与所有有关人士沟通
- 167. 质量管理对事不对人 质量是习惯、信念，不是事件 质量是每个人的事
- 168. 质量控制技巧举例产品《应交付成果》抽查 同僚检查 / 技术检讨 / 细则检查 重用验证过的软件 完整彻底的测试（单元、系统、整合、验收测试） 制订标准、方法体系
- 169. 10。规律管理（略）
- 170. 11。项目的开幕大会
- 171. 项目的开幕大会项目正式开始前，已有许多活动 有关人员还未正式见面、讨论，关系甚至暧昧，人人对项目认知不同 项目经理利用开幕大会 统一步调、口径 显示上层意志、意义、支持 定义规则、建立团队。。。
- 172. 项目的开幕大会大会应包含的内容： 介绍参会人员 概要介绍《项目定义》 项目目的、范围、主要“应交付成果”、成果验收标准、风险、假设、估算的工作量、预算、期限、项目成功标准
- 173. 项目的开幕大会各种角色与责任、义务介绍 介绍项目准备工作进展、近期的项目展开工作时间表 对团队的期望、管理理念（规则、纪律另会讨论） 问题与解答 明确宣布项目正式开始
- 174. 12。项目的结束
- 175. 项目结束的工作项目经理应把项目结束工作在《项目工作规划》里订好 结束工作包括： 评价项目成功或失败 – 按项目开始时订的标准，先自行评定，征求客户、项目保障人、相关人士的意见
- 176. 项目结束的工作举行项目总结大会，全体队员、项目保障人、相关人士参加，正式宣布结论： 项目记录回顾 正确与错的事件、教训 项目及项目管理的强项与弱点 最佳、最差技术、程序
- 177. 项目结束的工作转移到产品（客户）支持阶段 支持工作是持续的 知识的转移 培训支持人员，应包含在工作计划内 交出所有文档 队员考核 队伍解散
- 178. 队员考核考核系统通常作用不好，原因： 考核系统设计不佳，说明不清 项目经理与项目队员相处不佳 项目经理不注重管理 双方都无书面记录 没有实行目标管理
- 179. 队员考核考核间隔太长 受“指标”限制，考核成了轮流坐庄 奖励办法粗糙，成为变相补贴 惩罚是政治、人情游戏 没有KPI（Key Performance Indicators）
- 180. 队员考核项目的总结成绩对每一队员考核都有影响 应配合MBO、KPI才有具体标准 双向考核与360度全方位考核 考核为了进步，跟踪更重要
- 181. 队员考核考核系统要素： （从MBO来）个人具体的目标、以及评判成功的标准 为达到目标，领导所需提供的协助 实际表现与目标的对照 订定下一季度的目标
- 182. 问题与解答联络方法： patduan@solomonpros.com patrickduan@hotmail.com 0139-0653-4980
该用户的其他文档
相关PPT