PMP标准确认了在大多时候都被大多数项目视作良好实践的过程
- 所谓“普遍认可”，是指这些知识和做法在大多数时候适用于大多数项目，并且其价值和有效性已获得一致认可
- 通用的项目管理知识，不针对具体的行业
- 只针对单一的项目，而不针对项目集和项目组合
- 所谓“良好实践”，则指人们普遍认为，在项目管理过程中使用这些知识、技能、工具和技术，能够达成预期的商业价值和成果，从而提高很多项目成功的可能性
- 比较成熟的项目管理知识，不包括尚不成熟的部分
A 涉及书籍
- 高效通过PMP考试 - 汪博士解读PMP考试 - 成功通过PMP：对PMBOK的梳理以便于理解
- PMBOK第五版：PMI指定用书；考试教材；实际运用的指导，不见得完全照搬；项目管理的全球标准；是针对单个项目的管理；
- 一通读不求甚解
- 二读懂基本理解
- 三读精加深理解
- 四读透延伸发散
- 五读薄融汇贯通
- 六看目录理框架
- 西游记PMP备考奇书 - 题解PMBOK指南
B 话
- 万事皆项目
- “以正合，以奇胜” 正道描述事物应该遵循的基本规律，而制胜往往需要结合正道加以具体的运用，以奇制胜
读题时候的一些思路：
- 一定要看清楚问题，一定要看清楚问题，一定要看清楚问题！
- 一定要分析清楚问的对应的问题点！一定要分析清楚问的对应的问题点！一定要分析清楚问的对应的问题点！
- 选择显得积极的答案！选择显得积极的答案！选择显得积极的答案！
- 不要推脱个人的责任！不要推脱个人的责任！不要推脱个人的责任！
- 问 做什么 就是紧接着要做什么
- 如果选项既有抽象的又有具体的，选具体
- 方法论，选择通用的方案、战略层的，因为PMP就是针对 通用的解决方法论
- 别人不专业，但是PM一定要专业；
- 一切为了实现项目目标；
- 如果是问 “怎么 防止|预防 某种情况”，一定要记得往前边的阶段去思考
- 涉及过程基本概念考核时，譬如“该使用什么工具？”，应该多思考和回忆 该过程涉及的 输入输出 和 工具技术
- 排除法之后还有多个答案，要分析其先后顺序 意识先行，规划，分类，执行，监控:
PMI的一些思路：
- 不要随便麻烦别人，除非它是pmo
- 不该管的不要管，但是项目内的责任都是项目经理的
- 不可以汇报发起人的情景有哪些
- 团队管理的问题，如冲突，技能低，业绩差，人员离职等。
- 沟通问题，如相关方抱怨信息问题，无效的会议等。
- 与管理相关的绩效问题，如进度落后，成本超支，技术困难，范围变更。应该先分析原因和影响，制定解决方案。
- 相关方的问题，项目经理首先要自己去面对，而不是求助于发起人。
- 供应商的问题，风险发生，质量问题等都不是首先汇报给发起人。
- 可以汇报发起人的情景有哪些
- 如果和商业文件、项目章程有关的，就要想想去找发起人；尤其是发现理解有误时，找发起人确认
- 批准项目计划，批准发布章程，此时选择“请求，说服发起人”而不是“向发起人汇报”
- 项目经理谎报业绩，破坏环境等职业道德问题，可以向发起人汇报。
- 项目面临终止或是否要继续做下去的时候，如大量资源被调离，预算明显不够，公司将被收购。
- 项目经理反复努力，但仍然未能解决问题
- 对待错误
- 对于不符合规定的情况，不论自己如何主观上认为正确的，都应该报告+解决
- 团队成员意识到项目存在问题时，也应该主动的推荐 预防措施，并且上报PM
- 对待错误的态度，绝对不是调整标准，而是拒绝、解决和改正
- 对变更
- 项目只做对项目有益的工作，如果是确认无益处且浪费项目资源的工作，哪怕是相关方的需求，PM也有权说no
- 对于客户或者重要相关方的需求，不能简单的拒绝，，，除非是浪费资源而完全无意义的要求
- 刚接手项目的时候，PM是可以做下分析报告，给管理层，告知当前的偏差和困难的
- 西方职业道德：夫妻或者亲属不要在同一个项目中工作，以避免问题串扰
- 强调共赢，不能因项目的利益，肆意侵占任何团队成员或者相关方的利益，或者忽视其要求
- 合作共赢，要把对方往人性的真善美方面想，并促进整体的真善美
- 规章制度的制定，要先于具体的执行。也就是，如果题中有多个正确答案，要选择规章制度的先行
- 审查往往意味着，对某种已经执行过了的工作进行回顾
- 注意有一些选项的权限问题，PM可能不具备一些看似正确答案对应的权限能力:
- 项目经理必须尊重职能经理的权威
- 需要定期更新的管理计划只有两个，沟通管理计划+相关方管理计划。其他管理计划仅在出问题时更新。 需要定期更新的项目文件：风险登记册 + 相关方登记册
- 开踢会议得到相关方的一致承诺遵循项目管理计划，确保有一致共识； WBS确保相关方就范围达成共识，有助于管理相关方期望；相关方管理计划用于管理相关方的期望
- PMI基本假设项目中的所有问题，都应该是风险登记册中已经识别了的风险，如果有执行风险应对计划，记得选这个:
B.0 整合管理
- 商业文件中有关于项目的成本效益分析
- 涉及项目章程，就想到发起人或者高层管理层:
- 项目章程和项目管理计划都是很神圣的，一定要明确和取得一致共识
- 出现了专家判断选项的题，如果不确定答案，就注意这个选项:
- PMIS很少作为选项答案：凡正式向相关方汇报项目情况的文件，都称为绩效报告；PMIS用于收集和发布信息，制定好绩效报告:
- 经验教训手册通过知识管理系统进行记录，而且应该是实时的记录，定期的总结
- 变更管理
- 看到不知道变更找谁，选变更管理计划
- 额外的资源 或者额外的什么 表示不在计划内 选择变更管理计划:
- 整体变更控制关键在于整体，如果题中说分析对成本或进度的影响，往往是不对的，违背了综合的分析
- 变更请求一定是先书面请求，再全面分析，再将报告和变更请求递交CCB….先更新计划，最后更新变更日志+通知相关方:
- 变更请求审批通过后记得更新变更日志，并通知所有相关方
- 有一些变更不用分析影响，必须执行，譬如 范围遗漏、可交付成果缺陷等
- 变更请求通常发生在项目工作完成时，但是不见得就会产生额外的费用
- 问题解决
- 问题的解决一定是 更新问题日志—> 先确认和查看是什么问题 —-> 分析问题(因果分析+开会等)—>找到解决方案—>提交变更请求去实施—>更新经验教训:
- 问题解决中更新问题日志，问题解决后或者发现根本原因在解决时更新经验教训登记册
- 十大知识领域中，质量和采购往往是有成立专门的质量管理团队和采购团队这样的外部团队去辅助的
- 在正常预算下，项目经理可以通过消减范围来避免消减范围，但是不能消减质量
PM控制项目，可能控制预算，或者部分控制预算，可能控制资源
“最终进度和成本估算也已完成”表示项目管理计划已完成:
- 收尾要果断，该收尾就收尾
- 项目相关方应该为项目成功发挥各自的作用。管理层不支持、项目管理太差是项目失败最常见的两种原因。
B.1 范围管理
- 项目管理计划的制定是渐进明细的，根据项目的制约因素和特点决定。
- 首先明确需求，然后确认范围，最后分解至工作包。
- 看到工作内容和制约因素，想到范围说明书
- 看到制约因素：找项目章程，范围说明书，需求文件。
- 可交付成果或需求遗漏，查看需求跟踪矩阵； 可交付成果不满足要求或者期望，看范围说明书的验收标准；
- 关注可交付成果则看范围说明书，关注需求则看需求跟踪矩阵，关注需求和其他因素的关系也关注跟踪矩阵
- 看到验收选确定范围，看到验证选质量控制。
- 最终验收未通过，问如何避免或什么问题？一般选确认范围，即局部验收没有做好导致。
- 客户认为可交付成果不合格，问项目经理首先如何？一般选对比范围说明书或范围基准，查看质量测量也可以。
- 项目移交后，运营期间出现问题，项目经理应该首先查看验收文件收尾文件，来证明移交的东西没有问题
- 质量变更（如颜色尺寸规格变更）都按范围变更来处理。
- 可交付成果不合格，需要提交变更请求
B.2 进度管理
- 关键路径不唯一，是历时最长的。总时差为零的是关键路径。关键路径上的活动浮动时间为零。
- 关键路径的求答，可以直接通过判断最长路径来确定，不见得一步一步计算
- 看到资源数量有限，或只在特定时间可用，或资源负载太重，用资源平衡。
- 看到如果…就…则选择假设情景分析。
- 进度压缩:看到并行和成本是首要制约因素选快速跟进，其他都是赶工。CPI大于1而SPI小于1，然后CPI小于1，SPI大于1，问发生了什么事，选赶工。
- 进度网络图中可以显示活动之间的路径汇聚。如果不考虑事实上存“的路径汇聚，就会低估项目风险
- 赶工 ！= 加班，一般要求加班的做法都是错误的
成本管理
- 进度估算由执行人估算，成本估算由熟悉的人估算
- 对于免费使用的资源，也要按合理的数字计算其成本。如果不计算免费资源的成本，就会使成本估算数字失真，无法供以后类似活动或工作包参考（不会总有免费资源）
- 对免费资源，随后在计算项目资金需求时就无须考虑
- 粗略量级估算 -25%+75% 预算估算 -10%+25% 确定性估算 -5%+10%
- 只凭SPI大于1，不能判断项目进度是提前的。 因为还要考虑关键路径是否延迟
B.3 质量管理
- 质量是设计的，应用 def工具
- 看到规格，是质量测量指标
- 质量规划是制定标准，成本效益，质量成本，标杆对照，实验设计是专用。
- 测试与评估文件用于在控制质量过程中评估质量是否满足。核对单、测试计划、控制图或者需求跟踪矩阵，都可以用在这里
- 定时或随机使用，查看变更的效果，用质量审计。
- 看到过程改进，选质量保证
- 看到过程稳定有无失控，改进效果如何，选控制图。
- 找根本原因选鱼骨图，石川图，因果图
- 找两个变量之间的关系，看有无关系选散点图。
- 看到质量标准选质量规划。
- 当客户或发起人对项目担心的时候，制定或出示质量管理计划。
- 看到批量可交付成果出现问题，或错误重出现时，选管理质量。
- 看到确保，避免，防止，改进时，选管理质量
- 检查具体可交付成果部件时，选控制质量
- 修复可交付成果或部件的缺陷选质量控制。
B.4 资源管理
- 看到项目还没有开始就有人了，这是预分配，项目人员确保要谈判。
- 团队建设五阶段：争吵选震荡，开始建立信任选规范阶段，像一个有序的单位：成熟阶段。
- 冲突管理5方法:看到有人撤选撤退，看到互相进退选妥协，看到解决选面对，紧要关头选强制。
- 团队成员离职或请假
- 首先更新资源日历，更新项目资源管理计划。
- 也可视为风险识别而非风险发生，按照风险识别，选更新风险登记册，分析影响
- 风险发生则选查看风险登记册中的应对措施
- *目前更多不是作为风险，选更新或查看项目资源管理计划
- 资源问题在项目内项目经理解决，直到真的无法解决了再找资源经理寻求新的资源
- RACI记录成员的权责，项目章程记录项目经理的权责
- 人员没到位，选项有与职能经理协商优先选这个，没有就选执行风险应对计划
- 宗教信仰一定要尊重，但是个人喜欢或惯例，要看合同
B.5 沟通管理
- 看到有人对沟通不满意，出现争议的显现时，首先审查沟通管理计划，如果没有制定沟通管理计划。
- 有情绪相关的沟通，往往使用面对面，尤其是负面情绪的
- 团队成员的负面行为只有通过面对面的沟通交流效果才是最好的
- 询问重要干系人信息可以面对面，也可以用发信函或其他书面方式
B.6 相关方管理
- 相关方管理计划要去除敏感信息。
- 看到有责任不清，选责任分配矩阵。
- 相关方对结果不满意，选管理相关方期望（管理相关方参与），这时问依据是什么，选相关方管理策略。
- 有相关方的任何变化，首先要更新相关方登记册。
- 有人离开了，应该执行相关方分析；有人加入了团队，应该使用相关方参与评估， 争取相关方的支持(即便是发起人替换了，也不需要进行项目章程的再次审批，但是应该获取新的发起人的支持)**
- 不同干系人，或者太多干系人，会导致对项目的需求不同，存在竞争性的需求，增加管理难度，需要意识到这点和重点关注
B.7 采购管理
- 看到计算结果的统计方法，选择预期货币价值分析。
- 看到采购中甲方希望风险小，选择总价合同。看到没有范围选择工料合同。
- 看到完全消除风险选回避，看到风险合同选转移，看到降低概率选减轻。
- 看到卖方不清楚，选投标人大会。
- 采购变更用合同控制变更系统，避免卖方低绩效用卖方绩效审查。（采购绩效审查）
- 看到对采购过程的得失，或为未来采购，选（采购绩效审查）。
- 虽然PM考试，经常将自身定义为买方，但是也需要留意题目，到底是投标还是招标
- 在合同收尾的时候对未决争议可通过诉讼程序解决，合同可关闭，项目可正常关闭
- 单一来源，意味着只有一个看得上眼的供应商； 独有来源，是市场上只有这一家满足要求的供应商
B.8风险管理
- 风险要走流程，就是识别，定性，定量分析和应对。
- 看到决策建模，敏感性分析，选定量风险分析。
- 看到概率和影响相关的，优先排序的选择定性风险分析。
- 新风险用风险再评估(监督风险)，风险是否有效选风险审计，风险应对找风险管理员（责任人）。
- 高风险不能“转移”给别人； 财务风险一般使用转移
- 积极风险：提高数量，开拓质量
- 人员不到位的，要多考虑下风险应对计划
- 风险与相关方
- 风险管理计划中没有应对措施，但是相关方管理计划里反而有相关方的管理策略和参与程度
- 风险登记册里应对措施，但是相关方登记册没有管理策略；
- 识别相关方一定是启动过程组，但是识别风险可能是启动、监控；
- 制定权变措施，需要参考经验教训
- 风险与变更
- 风险登记册的应对措施是已经经过审批通过了的，如果风险发生，可以直接实施。
- 权变措施，属于纠正措施，一定要经过整体变更控制过程。
- 应急应对计划，是需要某个信号达到时，才应该启用。
C. 数值
- 三点估算 68.26 95.46 99.73
- WBS一般 4-6 层，工作包一般在40-80个小时内完成
- 质量责任，管理层85%，员工15%
- 质量成本应该占总项目成本的3%-5%
- 控制图中， 中心线或者均值3个标准差的区域往往作为控制变动范围
- PM沟通的时间占75%-90%
- 沟通中的55%信息都是通过“非口头语言”传播的
- 语言本身在信息构成中占的比例 7%，声音占38%，视觉占55%
- 项目一般到15%-20%以后，CPI就趋于稳定，可以为总体预测提供参照
- Scrum的理想团队成员个数在5-9人
- Sprint是一个固定的时间周期，长度可以是1周到四周，但越短越好
- 用户故事不要超过2-3周的人工量
- 所有的Scrum sprint会议都是限定时⻓的。 Sprint计划会议推荐时⻓是Sprint中的每一周对应两个时或者更少
- 所有Scrum 每日立会都是限定时⻓的。每日Scrum通常不超过15分钟
537
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
