信息系统项目管理师高级学习笔记Word文档下载推荐.docx
《信息系统项目管理师高级学习笔记Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《信息系统项目管理师高级学习笔记Word文档下载推荐.docx(70页珍藏版)》请在冰豆网上搜索。
![信息系统项目管理师高级学习笔记Word文档下载推荐.docx](https://file1.bdocx.com/fileroot1/2023-1/12/872032f2-614c-4f31-9c5f-c0ff295d29e1/872032f2-614c-4f31-9c5f-c0ff295d29e11.gif)
有不同的优先级、具有层次性、多目标性
1.1.5项目的三重约束
质量、时间、成本共同约束范围
【注】范围是第四种约束
1.1.6集成项目
•【定义】集成项目的产品是一个满足需求、支持用户业务的信息系统
•【指导方法】总体规划、分步实施
•【特点】
♦以满足客户和用户需要为根本出发点
♦客户需求常含混多变,因此需要加强需求变更管理以控制风险
♦不求最好,但求合适
♦高技术与高技术集成,风险比较高
♦系统工程,需要多方协作
♦团队年轻,流动率高
♦沟通很重要(PM的工作)
1.1.7对项目经理的一般要求
•足够的知识
•丰富的项目管理经验
•良好的协调和沟通能力
•良好的职业道德
•一定的领导和管理能力
♦领导能力:
订立方向、协调思想、奖励和鼓舞★
♦管理能力:
持续不断的为项目干系人创造他们所期望的主要成果★
1.1.8优秀项目经理的必要条件
•真正理解项目经理角色
•领导并管理项目团队
•合理制定项目计划(PM和团队),监控计划执行,管理好变更
•真正理解“一把手工程”
•注重客户和用户的参与
1.1.9项目的三种生命周期★
•【技术方面】需求分析、系统设计、系统构建、运行
•【管理方面】启动、计划、执行(监控)、收尾
•【软件开发】可行性分析、需求分析、设计(概要、详细)、编码(单元测试)、测试、运维
1.1.10项目阶段特征
•项目各个阶段的收尾时通常进行阶段评审:
对可交付成果和项目执行情况进行检查,即:
阶段出口、阶段验收
•【阶段评审目的】
♦评审本阶段的任务是否已经完成
♦判断当前阶段是否满足结束标准并进入下一个阶段
♦发现当前阶段中存在的问题和错误—缺陷放大或缺陷预防
•【阶段评审内容】
♦当前阶段的交付物
♦当前阶段的项目执行情况(范围、成本、进度、质量等)
1.3项目组织结构
1.2.1组织结构类型
职能型、项目型、矩阵型(弱、平衡、强)
组织结构基本信息对比表★
结构类型
职能型
矩阵型
项目型
弱
平衡
强
PM权限
很少或没有
有限
小到中等
中等到大
很高甚至全权
人员比例
几乎没有
0~25%
15~60%
50~95%
85~100%
PM任务
兼职
全职
主要应用
•由一个部门完成
•技术较成熟
•前提:
用在管理规范、分工明确的公司
•一般用作跨职能部门的项目
•开拓型、风险较大的项目
•进度、成本、质量等指标有严格要求的项目
职能型优缺点
优点
•强大的技术支持,便于知识、技能和经验的交流;
•清晰的职业生涯晋升路线;
•直线沟通、交流简单、责任和权限清晰;
•有利于重复性工作为主的过程管理;
•项目组成员在事业上有连续性和报障,不担心项目结束后的去留。
缺点
•职能利益优于项目,具有狭隘性;
•职能横向之间联系薄弱,部门间协调难度大;
•项目经理极少或缺少权利和权威;
•项目管理发展方面方向不明,缺少项目基准等;
•调配给项目的人员,积极性往往不是很高.
项目型优缺点
•结构单一,权责分明,利于统一指挥;
•目标明确单一;
•沟通简洁、方便;
•决策快。
•管理成本高,资源配置效率低;
•项目环境封闭,不利于沟通、共享知识和经验;
•项目成员忙闲不均;
•容易造成公司规章制度上的不一致性;
•项目成员缺乏一种事业的连续性和报障。
矩阵型优缺点
•项目经理负责制,有明确的项目目标;
•改善了项目经理对整体资源的控制;
•及时响应;
•获得职能组织更多的支持;
•最大限度的利用公司的稀缺资源;
•改善了跨职能部门协作;
•使质量、成本、进度等制约因素得到更好的平衡;
•团队成员有归属感,士气高,问题少;
•出现冲突少,且容易解决.
•管理成本增加;
•多头领导,违反了命令单一性的原则;
•难以监测和控制;
•资源分配与项目优先问题产生冲突;
•权利难以保持平衡.
1.2.2项目管理办公室(PMO)(部分高项)
PMO是在所辖范围内集中、协调的管理项目的组织单元.
•日常性职责(高项)
♦监理组织内项目管理的支撑环境
♦提供项目管理的咨询和指导
♦培养项目管理人员
♦组织内多项目的管理和监控
•战略性职责(高项)
♦项目组合管理
♦提高组织项目的管理能力
项目管理办公室(PMO)
项目经理(PM)
目标
企业整体
项目本身
范围
全组织内
特定项目的制约范围内提交具体成果
重点
重要的计划范围变更
特地项目的目标
控制资源
共享的组织资源
分配到项目的资源
内容
整体风险、机会、项目之间关系
具体工作包括范围、进度、成本和质量
汇报内容
从整体角度考虑对项目的看法
具体项目的绩效、项目信息
1.4大型复杂项目管理(高项)
⏹量变而非质变
⏹项目型的组织结构
⏹项目经理的职责更集中于管理
⏹间接管理而非直接管理--最大收益就是解决了管理幅度问题
⏹必须建立以过程为基础的管理系统;
确立了项目过程后,再进行项目计划
2.九大知识领域
2.1立项管理
2.1.1立项管理的内容
•需求分析
【特点】开发与客户沟通困难;
需求动态变化;
变更代价非线性增长
•项目建议书
•可行性研究报告
【特点★】预见性,公正性,可靠性,可信性
2.1.2项目建议书内容(甲方负责编写)
•项目的必要性
•项目的市场预测
•产品方案或服务的市场预测
•项目建设必须的条件
【注】项目建议书中的内容并不包含风险信息,并且是可研的依据
2.1.3可行性研究报告内容★背
•投资必要性
•技术可行性
•财务可行性
•组织可行性
•经济可行性
•社会可行性
•风险因素及对策★
【注】可行性报告中的内容包含风险信息
2.1.4项目的可行性研究★
•机会研究(项目建议书)
•初步可行性研究
•详细可行性研究
•项目论证
•项目评估
•可研报告编写与申请获批
【注】小项目中机会研究和初步可行性研究可以去除
项目的可行性研究★背
阶段
工作内容
费用
误差控制
项目建议书(机会研究)
寻求投资机会,鉴别投资方向
0。
2~1%
±
30%
初步可行性研究
初步判断项目是否有生命力,能否盈利
25~1.5%
20%
详细可行性研究
详细技术经济论证,多方案比较选择最优方案
0.2~3%
10%
【注】项目可研和项目论证等费用属于立项前的工作费用,不计入项目的总投资之内
2.1.5初步可行性研究★背、考
•【目的】分析项目是否有前途;
有无关键问题需要解决;
必须要做哪些辅助研究
•【内容】市场和生产能力;
物料投入分析;
厂址;
项目设计;
进度安排;
成本估算
•【作用】是作为项目取舍的依据
•【结果】肯定,立即实施;
肯定,转入详细可研;
展开专题研究;
否定,项目取消★
2.1.6详细可信性研究★背、考(下午的题目)
•【方法】
♦经济评价法(财务评价和国民经济评价)
♦市场预测法
♦投资估算法
♦增量效益法
•【内容★】
♦概述
♦需求确定
♦现有资源分析
♦设计技术方法
♦进度计划
♦投资估算和资金筹措计划
♦组织及人力安排
♦经济和社会效益分析
♦合作/协作方式
【注】从甲方角度是不考虑风险的,从乙方角度是需要考虑风险的
2.1.7项目论证
•【定义】对项目技术上的先进性和适用性,经济上的合理性和盈利性,实施上的可能性,风险可控性等进行全面科学的综合分析,为项目决策提供客观依据的技术经济研究活动
•【作用】确定项目是否实施;
筹措资金的依据;
编制计划配置资源的依据;
防范风险提高效率的保证
•【原则★】合规;
政策、技术、经济结合;
重视数据;
科学预测;
宏观、微观结合;
定性与定量分析结合
•【内容】
♦甲方角度:
财务评价;
国民经济评价;
环境影响评价;
社会影响评价
♦乙方角度:
技术;
人力安排/资源;
其他投标人分析;
风险
【注】只要是论证,都是自己做
2.1.8项目评估★
•【执行】由第三方来进行评估
♦项目评估法:
仅评估项目本身费用效益,用于简单项目★
♦全局评估法:
还要评价项目对组织带来的效益,用于复杂项目★
♦总量评估法:
采用总量数据,简单,侧重经济效果,无法衡量增加效益
♦增量评估法:
比较追加投资效果差异,分前后法和有无法(常用)
♦费用效益分析法:
项目对社会的贡献程度,效益与费用比必须大于1★
♦成本效益分析法:
比较单位效用的成本:
成本相同选效用高;
效用相同选低成本;
效用增加时单位成本低★
♦多目标系统分析法:
从整体角度分析项目的效用与成本,效益与费用,计算出净收益和成本效用比★
2.1.9可研报告编写与申请获批★
•【执行】项目建设单位根据项目建议书批复,选择有资质的咨询机构(第三方)编制可研报告,报送审批部门,审批部门委托有资质的咨询机构(第三方)评估后审核批复
•【依据】审批部门对项目的建议书,可研报告,初步设计方案和投资概算的批复,是项目建设的主要依据
•【重批的条件★】
♦项目投资超过批复金额的10%的,须重新报批
✧建议书和可研报告有问题的,重批建议书
✧可研报告、初步设计方案和投资估算报告有问题的,重批可研报告
✧建议书、可研报告、初步设计方案和投资估算报告有问题的,重批建议书
♦项目投资未超过批复金额的10%的,调整并进行补充说明
✧建议书和可研报告需要调整并进行补充的,调整并补充可研报告
✧可研报告、初步设计方案和投资估算报告需要调整并进行补充的,调整并补充初步设计方案和投资估算报告
✧建议书、可研报告、初步设计方案和投资估算报告需要调整并进行补充的,调整并补充初步设计方案和投资估算报告
2.1.10签订合同
•【日期】中标通知书发出后的30天内签订合同
2.2整体管理
项目整体管理定义
项目选择的方法:
收益测量法、约束优化法
概念:
现值、净现值、投资回收期、回报率、内部收益率
项目章程:
Who、When、Why、What
项目计划的内容(项目章程、项目范围、项目组织结构、角色和责任、WBS、进度计划、成本估算和预算、项目风险和沟通管理)
项目计划的执行和监控
变更控制委员会(CCB);
批准或否决基线变更
配置管理
变更控制系统
2.2.1工作说明书(SOW)
•【定义】对项目所需交付的产品或服务的叙述性说明
•【内容】业务要求、产品范围描述、战略计划
2.2.2项目章程
•【定义】记录业务需要、对客户需求的理解,以及需要交付的新产品、服务或成果
♦项目目的或理由
♦可测量的项目目标和相关的成功标准
♦总体要求★
♦概括性的项目描述、产品特性★
♦总体里程碑进度计划★
♦总体预算★
♦项目审批要求(用什么标准评价项目成功,由谁对项目成功下结论,由谁来签署项目结束)
♦委派的项目经理及其职责和职权★
♦批准项目章程的人员的姓名和职责
【注】给PM授权要在制定项目章程之前或过程中,但不能在之后进行
2.2.3初步范围说明书
♦产品范围描述(渐进明细)★
♦项目可交付成果★
♦产品用户验收标准★
♦项目边界★
♦项目制约因素
♦项目假设条件
♦最初的项目组织
♦最初定义的风险★
♦进度里程碑★
♦对项目工作的初步分解
♦初步的量级成本估算★
♦项目配置管理的需求
♦审批要求
2.2.4项目管理计划★
•【定义】项目管理计划整合了其他各规划过程所输出的所有子计划和基准;
项目管理计划确定项目的执行和监控方式,计划一旦被批准,成为项目基准(如果要变就需要走变更流程);
•【绩效测量基准★】范围、进度和成本基准合并为一个绩效测量基准,作为项目的整体基准,以便据此测量项目的整体绩效
2.2.5项目计划编制工作★背、考
•【基本原则】
♦全局性原则
♦全过程原则
♦人员与资源的统一组织与管理原则
♦技术工作与管理工作协调的原则
♦技术工作与管理工作的统一
2.2.6变更管理★背、考
•【变更请求(产生原因)】纠偏措施、预防措施、缺陷补救、更新
•【流程】变更发起→影响分析(提交给监理或乙方PM)→CCB批准→更新计划→变更执行→变更验证→记录存档否↓↓
拒绝干系人沟通
•【变更控制系统★考】
♦【定义】是定义范围变更的有关流程
♦【内容】包括必要的书面文件(如变更申请单)、纠正行动、跟踪系统和授权变更的批准等级
•【变更控制委员会】
♦【简称】CCB
♦【定义】是项目的临时性组织,不必面面俱到,对于小项目CCB可能只有一人(项目经理),甚至是兼职
2.2.7变更初审的目的★
•确认变更的必要性,确保变更是有价值的
•格式校验,完整性校验,确保评估所需信息准备充分
•在干系人间就提出供评估的变更信息达成共识
•【常见方式】变更申请文档的审核流转
2.2.8变更方案论证
•对变更请求是否可实现进行论证,如果可能实现,则将变更请求由技术要求转化为资源需求,以供CCB决策
•【常见的方案内容】技术评估(评估需求如何转化为成果);
经济评估(评估价值和风险)
2.2.9整体变更的目的★背、考
•对造成变更的因素施加影响,以确保这些变更得到一致的认可
•确认变更是否已经发生
•当变更发生时,对实际的变更进行管理
•对造成整体变更的因素施加影响,确保只有经批准的变更才能付诸执行★
•变更控制的对象就是项目基线★
2.2.10项目变更管理的工作内容(第16章)★背、考
•【大项目】规范化,分批处理,分优先级
•【小项目】对变更因素施加影响,防止不必要的变更;
对变更的确认应正式化;
变更操作过程应规范化
2.2.11整体变更控制过程的配置管理活动
•【三个活动】配置识别、配置状态统计、配置验证和审核★
♦配置识别:
为产品配置的定义和验证、产品的标识和归档;
变更的管理及其责任提供了基础
♦配置状态统计:
收集、存储和访问配置信息,以维护产品的有效性
♦配置验证和审核:
如有关的功能需求已经被设计文档实现,而且设计文档已纳入配置管理系统
2.2.12收尾阶段
•【内容】包括管理(项目)收尾和合同收尾★
♦管理(项目)收尾:
包括项目正式验收,总结经验教训,准备合同收尾,评估项目等.
♦合同收尾:
完成和结算所有合同,解决所有遗漏问题
2.2.13项目收尾管理
•【工作内容】项目验收、项目总结和项目评估审计
•对信息系统的后续工作的支持
•项目团队人员的转移
2.2.14项目验收
•【验收内容】验收项目产品、文档及已经完成的交付成果
•【依据】验收需要正式的验收报告。
系统集成项目需要正式的验收测试工作.可以由业主和承建单位共同进行,也可以由第三方公司进行,但无论哪种方式都需要双方认可的正式文档为依据进行验收测试
•【标志】验收正式通过,则标志着项目验收的完成。
验收合格需经双方签字认可。
•【步骤】系统测试、系统的试运行、系统的文档验收、项目的最终验收报告(终验报告)
【注】系统测试和系统的文档验收可以省略;
系统测试和项目的最终验收报告可以一起执行
•【验收文档】
♦项目介绍
♦项目最终报告
♦系统说明手册
♦系统维护手册
♦软硬件产品说明书、质量保证书等
•【终验报告】由双方的项目组撰写验收报告提交双方工作主管认可
2.2.15项目总结
•【定义】项目总结属于项目收尾的管理(行政)收尾。
•【意义】
♦了解项目全过程的工作情况及相关团队成员的绩效状况
♦总结经验教训
♦形成组织过程资产
2.2.16项目总结会★考
•【准备】
♦收集整理项目过程文档和经验教训
♦经验教训的收集和形成项目总结会的讨论稿
♦项目绩效
♦技术绩效
♦成本绩效
♦进度计划绩效
♦项目的沟通
♦识别问题和解决问题
♦意见和建议
2.2.17项目评估
•【依据】盈利要求、客户满意度要求、后续项目指标要求、内部满意度要求
2.2.18项目审计★
•【主要工作】进行财务审计
2.2.19团队人员转移
•【流程】
♦项目团队成员的管理计划,也就是项目人力资源管理计划中描述所说的人员转移条件已经触发
♦项目团队成员所承担的任务已完成,提交了经过确认的可交付物并已完成工作交接
♦项目经理与项目团队成员确认该成员的工作衔接已经告一段落或者已经完成
♦项目经理签发项目团队成员转移确认文件
♦项目经理签发项目团队成员的绩效考核文件
♦项目经理通知所有相关的干系人
♦若是项目收尾全体项目成员结束项目工作,应召开项目总结表彰大会(在项目结束前完成),肯定项目成绩、团队成员的业绩,同时总结项目的经验教训
2.3范围管理
2.3.1项目范围★
•【定义】为交付具有规定特性与功能的产品、服务或成果而必须完成的工作
•【完成情况】依据项目管理计划
2.3.2产品范围★
•【定义】某项产品、服务或成果所具有的特性和功能
•【完成情况】依据产品需求
2.3.3详细范围说明书★考
•【作用】在所有项目干系人之间建立了一个对项目范围的共同理解
•【内容★考】
♦项目目标
♦产品范围描述
♦项目的可交付物
♦项目边界
♦产品验收标准
♦项目的约束条件
♦项目的假定
2.3.4工作分解结构(WBS)★考
•【展现形式】列表式、组织结构图式、鱼骨图式或其他方式
♦列表式
✧优点:
能够描述项目的全过程;
可以借助计算机工具帮助完成
✧缺点:
直观性差
【注】一般用在大项目中
♦组织结构图式
直观,层次性,结构性强
不易被修改;
不能描述项目的全过程
【注】一般用在小项目中
•【分解形式★背、考】
♦把项目生命周期的各阶段作为第一层,再把项目可交付物作为第二层
♦把重要可交付物作为第一层
【注】项目管理可以作为一个单独的重要可交付物进行展现,且项目管理必须要有
♦把子项目作为第一层,再分解子项目的WBS
【注】WBS要包括外包出去的部分
•【最小单位】工作包
♦工作包是定义工作范围、定义项目组织、设定项目产品的质量和规格、估算和控制费用、估算时间周期和安排进度的基础(也是精准估算的基础)
•【工具及技术】分解
•【分解原则★背、考】
♦在各层次上保持项目的完整性,避免遗漏必要的组成部分
♦一个工作单元只能从属于某个上层单元,不能变叉从属
♦相同层次的工作单元应有相同性质
♦工作单元应能分开不同的责任者和不同工作内容
♦便于项目管理进行计划和控制的管理需要
♦最底层工作应该具有可比性,可管理的,可定量检查的
♦应包括项目管理工作,还要包括分包出去的工作
♦一个项目的WBS是否分解到工作包,跟项目的阶段、负责程度和规模有关,一般来说早期,或复杂,或大规模的项目,其WBS的分解颗粒要大一些,粗一些
2.3.5范围基准
•【定义】是项目管理计划的组成部分
•【内容】项目范围说明书、WBS、WBS词典
2.3.6范围核实(范围确认)
•【作用】正式接受已完成的项目范围的过程,确保可交付成果已圆满完成,并获得客户或发起人的正式验收。
•【生命周期】范围核实贯穿项目的始终,从WBS的确认到项目验收时范围的检验
2.3.7范围核实(确认)与质量控制的区别
•范围核实(确认)是有关工作结果的接收问题,而质量控制是有关工作结果正确与否
•质量控制一般在范围确认之前完成,当然也可以并行进行
【注】质量控制>
=范围确认
2.4进度管理
估算活动资源、估算活动持续时间的工具和技术★背、考
2.4.1检查点、里程碑和基线
•【定义】重要的检查点是里程碑,重要的里程碑(需要客户确认的)就是基线
2.4.2网络图分析
•【依赖关系★】
♦强制依赖关系:
活动性质中固有的依赖关系,常常是某些客观限制条件,也称硬逻辑关系(如:
先开发后测试)
♦外部依赖关系:
项目活动与非项目活动之间的依赖关系,往往不在项目团队的控制范围内。
(如:
项目组与独立的测试组之间的关系)
♦选择性依赖关系:
通常是资源上的制约,也称软逻辑关系(优先逻辑关系、弹性依赖关系、自由依赖关系)
•【类型】
♦前导图法PDM(单代号网络法AON)
✧活动依赖关系:
结束-开始(FS)、开始-结束(SF)、开始—开始(SS)、结束-结束(FF)
♦箭头图法ADM(双代号网络法AOA)
✧特点:
有虚活动(虚线表示)
✧基本原则:
事件代号唯一,不能重复代号;
任两项活动的紧前和紧随事件代号至少有一个不相同,节点代号沿箭线方向由小到大;
流入(或流出)同一节点的活动,均有共同的后续(或前序)活动
♦关键路径法CPM★
✧作用:
确定关键路径;
项目的周期(项目所需的最短时间);
时差(浮动时间,包括总时差和自由时差)
✧特点★:
每个项目中都有一条或多条关键路径;
所有路径中最长的路径;
具有最小浮动时间(时差的路径),小于或等于零;
完成项目的最短时间;
关键路径越多风险越大;
压缩关键路径可以缩短项目工期
✧非关键路径:
时差(浮动时间)大于零的路径;
压缩非关键路径不能缩短项目工期
2.4.3总时差(总浮动)★
•【定义】不影响项目总工期的前提下,某任务可以推迟开始的最大时间量
•【公式】本任务的最迟完成时间–本任务的最早完成时间=总时差/总浮动(或最迟开始–最早开始)
•【作用】总时差决定进度安排的灵活性
2.4.4自由时差(自由浮动)★
•【定义】不影响后续任务的最早开始时间的前提下,某任务可以推迟开始的最大时间量
•【公式】后续任务最早开始时间的最小值–本任务最早完成时间=自由时差/自由浮动
•【作用】自由时差决定后续活动安排的灵活性
2.4.5历时估算技术
•【技术】专