软考-信息管理——学习笔记_证

前言：学习方法：应该达到： 按照一级标题进行默写罗列，再默写二级标题默写罗列，最后按三级标题及知识点进行罗列。

合同和法律篇：

• 中标通知书发送30天内需签订合同
• 标底保密
• 招标文件发布起到截止日不得少于20天
• 不用招标的场景：
  • 需要采用不可代替的专利\技术
  • 采购人可以自己生产、建设
  • 通过招标选投资人的生产、建设的
  • 需要从原招标人处采购配套的

        合同类型：

1. 看到范围清楚择选总价合同;
2. 看到范围不清楚择选成本补偿合同;
3. 看到没有范围(无法定义SOW)就选工料合同;
4. 成本加激励费用合同与成本补偿合同意义相同
    

• 涉及保密的也应该招标，但是是 邀请招标
• 竞争招标的场景：（目标有点模糊，通过多家比较才能知道）
  • 没有供应商投标、或没合格企业来
  • 技术复杂或特殊的
  • 招标时间不能满足用户的紧急需要（比较特别,不可预见的紧急情况不属于该方式）
  • 不能事先计算总额
• 单一来源招标的场景：
  • 只能从唯一的供应商处采购
  • 发生了不可遇见的紧急情况
  • 保证原有项目的一致性或配套，但总金额不得超过原合同金额的10%
• 邀请招标的场景：
  • 具有特殊性，只能从有限范围的供应商处采购的;
  • 采用公开招标方式的费用占政府采购项目总价值的比例过大的。
• 中标人的保证金不用退，未被选中的供应商在确定供应商后需要退
• 履约保证金不能超过中标合同金额10%。
   
• 采购人采购纳入集中采购目录的政府采购项目，必须委托集中采购机构代理采购;
• 采购未纳入集中采购目录的政府采购项目，可以自行采购，也可以委托代理采购。
   
• 投标人报价受价格限制，不能低于成本报价
• 委托开发完成的发明创造，除当事人另有约定，申请专利的权利属于受托者，即：归完成者。
• 招标人对已发出的招标文件进行必要的澄清或者修改的,应当在招标文件要求提交投标文件截止时间至少15天前，以书面形式通知所有招标文件收受人。
• 中标人可以放弃中标项目,但是担责
• 国家重点项目货地方重点项目不适宜公开招标的，需国务院或省、自治区、直辖人民政府批准，进行邀请招标
• 作者的署名权、修改权、保护作品完整权的保护期不受限制。
   
• 软件著作保护权，作者终身+死后50年（50年的第12.30日）
• 采购文件要保存15年
• 索赔28天要答复

---

单价合同：看到范围不是很清楚 （工时材料合同）：工作规模或不明确的项目，，外包采用此方法

成本补偿：看不清楚范围不清楚成本 、买方承担风险、买卖双方有稳定合作关系，支付实际成本外，再给一点钱作为卖方利润

总价合同：看得清楚范围

1.  作为合作开发的软件，软件作品的开发者身份为全体开发者，软件作品的发表权也应由全体开发者共同行使

• 委托开发完成的发明创造，除当事人另有约定的以外，申请专利的权利属于受托者，也就是完成者

中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。但可以约定或经招标人同意，将部分非主体、非关键性的工作分包给别人做，别人不准再次分包。

改编、翻译、注释、整理已有作品而产生的作品，其著作权由改编、翻译、注释、整理人享有，但行使著作权时不得侵犯原作品的著作权

---

软件篇

版本控制：

• X.Y正式发布
• X.YZ修改状态
• 0.YZ草稿状态
• 版本号：X.Y 正式发布，一般只增大Y,改动很大才允许增大X

• GB 是国家强制标准，GB/T是国家推荐标准

• ---

  信息安全等级：

  • 1、既不损害社会，也不损害国家。适用于普通内联网

  • 2、损害社会，但不损害国家。适用于内联网

  • 3、损害国家。适用于：地方机关、金融、邮电

  • 4、严重损害国家。适用于：国家机关、广播电视

  • 5、特别严重损害国家。适用国防部门

---

审计：是否符合软件需求，独立检查

验证：是否达到上一阶段的需求

确认：评价是否和需求一致

测试：看有无bug

鉴定：正式、是否符合规格说明

走查：静态分析，组员检查（评审）你的代码

发布管理与交付包含:存储、复制、打包、交付、重建

---

配置项分为：：

基线配置项：设计文档和源程序

非基线配置项：各类计划、报告

---

网络知识：

交换机的三层：

1. 接入层：用户接入网络的层。特点：低成本，接口高密度
2. 汇聚层：用于网络控制、寻址、数据加工、过滤
3. 核心层： 优化网络间传输

FTP：文件传输协议，通过TCP连接，端口20

TFTP：简单的文件传输协议，通过UDP，端口21

SMTP：简单的邮件传输协议，通过TCP,端口25

POP3:邮件接受协议110，通过TCP, 端口110

DNS:使用UDP，端口53

物理层：传透明比特流，标准又RS232、v.35、RJ.46(网线头)、FDDI

数据链路层：将数据封装成帧，协议：IEEE802.3/2、HDLC、PPP、ATM

网络层：路由选择。IP-》物理地址层。协议：IP、ICMP、IPX、APR、RARP

传输层：端到端的传输。确保数据传输。TCP、UPD、SPX。

会话层：两个节点的会话管理

表示层：解密加密、数据转换，格式和文本压缩。JPEG、GI

应用层：Http、FTP、TFPT、Telnet

---

泛化：一般到特殊

组合：对象连接 

依赖：一个事务影响另一个事务

类图：描述接口、协议之间的关系

对象图：描述一组对象的关系

构件图：内嵌的构建和连接的构成的内部结构

组合结构图：结构化类与其他系统的交互图

用例图：用例与参与者之间的关系       

顺序图：发送消息、时间次序的交互图

通讯图：收发消息、组织结构

定时图：跨越不同对象、不仅仅关系消息相对顺序

状态图：状态、转移、时间

活动图：展示计算内部一步步控制流和数据流

问题分析图（PAD）：自上而下、从左主干开始

质量工具的相关图：

因果图（鱼骨图）：追溯问题来源、识别和问题分析、可能出现的问题和潜在的原因

流程图：一个或多个输入转换成一个或多个输入

核查表：对（账）清单

帕累托图：圈定大多数、几个问题、缺陷的少数主要原因，以测量频率为后果

直方图：不考虑内部变化，描述趋势、分散

控制图：寻址数据规律、分析是否（超出边界）异常、是否稳定

散点图：变量之间的关系

质量规划：输出过程改进计划,作用：通过进度基准和成本基准指定测量指标。

质量保证：通过①按计划做事②给大家信心、增加信心③改进计划、过程

质量控制：通过①进行纠偏、提建议②确认可交付成功，及时签字③对已批准的缺陷实施情况进行检测

质量保证着重：改进、按计划行事，关注项目执行过程的质量。

质量控制着重：监控、核对，强调可交付成果，能检测查并发现出缺陷

质量审计：目的：识别最佳实践、识别违规和不足、分享实践经验

---

定性风险分析：对风险排序，以便深入分析，评估、概率和影响、矩阵，再采取适当的措施（分类、评估、概率）

定量风险分析：访谈、专家判断、灵敏度分析、期望货币价值分析、决策树分析、建模和仿真（度量、值）  

• 风险评估是量化后进行的
•  未知风险不能管理，只能预防
• 风险识别贯彻始终
• 蒙特卡洛技术是建模和仿真、模拟
• 投机和纯粹风险一定情况下可以互相转换
• 系统或过流程图：分析要要素之间的互相联系、因果传到。（政策、气候、运输）

直接损失：员工受伤、医疗、工资、设备

间接损失：停工、灭火

---

组织矩阵P/O：人事和职位

 资源数据矩阵R/D：资源和数据

CU矩阵：表中含C或U

---

 集成技术：

1. 表示集成：黑盒集成，屏幕截取、输入模拟，屏蔽数据内部
2. 数据集成：白盒集成
3. 控制集成：黑盒集成，业务逻辑、使用api
4. 业务流程集成：过程集成，由标准、统一格式的工作流组成。

---

网络存储技术：

DAS：不易扩展

NAS: 很nb，通过NFs和CIFS进行访问，支持UDP、TCP

SAN： 使用快级存储

工作的设备：

网络层：路由器

物理层：调制解调器、集线器

数据链路层：以太网交换机

---

需求分析：（壮行（状行）、e数（E-数）、数功）

E-R ：用来表示数据模型

状态转换图： 用来表示行为模型

数据流程图：用来标识功能模型

---

 战略组织模式：

1. 文化型：动员全体成员
2. 变革型：主题展开
3. 合作型：发挥集体智慧
4. 增长型：积极主动着眼战略制定和实施

战略实施4个阶段：

1. 战略启动
2. 战略实施
3. 战略运作
4. 控制与评估

---

---

强矩阵组织： 一个员工，纵横上都有人进行管理，横向是项目经理管理，如下图

职能型矩阵：横向联系薄弱，部分协调难度大。

 

---

Iaas:基础能力，提供计算、存储能力

Pass:平台能力，提供系统、数据库、web应用服务

Sass:软件服务，提供办公软件，组件

---

软件5种风格：

数据流风格：批量处理序列、管理或过滤

返回调用风格：主程序/子程序、数据抽象、面向对象、层次结构

独立构件风格：通信和事件驱动

虚拟机风格：解释器和基于规则

仓库风格：数据库和黑板

---

---

成本：

非一次性支出：软硬件的租金、节日福利、水电费、工资

一次性支出：培训费、差旅费

---

软件生存周期：主要3个部分：

1、主要过程：各种合同、设计、编码、维护（开发团队干的）

2、支持过程：各种质量保证、配置、审核（项目管理的人干的）

3、组织过程：各种管理、评价、人力、评估（hr干的）

---

---

• 软件质量：6大特征：功能靠用小护翼

（功能性—功能、可靠性一靠、可用性一用、效率—小、可维护性一护、可移植性一翼)
 

---

 项目组合管理：项目集和项目对资源需求之间的冲突进行平衡

项目集：大项目分解成几个相互关联的子项目进行管理

---

 软件文档分类：开发文档、产品文档、管理文档 （注：没有技术文档和支持文档）

软件文档质量分类：

1级：个人看的，适合低于1人量每月

2级：团队看的，有注释，帮助用户安装和使用

3级：同一个单位的人看的，可能被其他单位看的

4级：正式发版，供行业参考的

---

能够画出单代号图、双代号图：

单代号就是以项目节点为节点：如

双代号就是 用 ①②③④。。。为节点

单代号网络图与双代号网络图的区别是什么？ - 知乎 (zhihu.com)

 总时差=本工作的最晚结束时间-本工作的最早完成时间=EF-LF=ES-LS,就是 当前节点能耽误多久，也不影响到整体

自由时差= 下一个节点的最早开始时间-当前节点最早完成时间= 下一节点的LF-LS      注：

如果当前节点只有一个后续节点，且该后续节点只有这一个节点作为前驱，那该节点的自由时差=0

 上边LS、LF是 取该节点的前面节点 LF的最大值，

下边ES、EF的取该节点的后面节点EF的最小值

关键路径上的节点的总时差都是0

下图，从前向后取最大（毕竟是找关键路径），从后向前取最小

单代号网络图

时序图：

（数字最后标记，即：活动历时，一个节点有多个前驱节点时，用虚线箭头表示）

再算 算时差、画波线（X节点前 必须要等Y完成 那就是画直线，如②->③  ，但是②->④和②->⑤ 各花的时间 都小于 ②->③ 的  说明 他们可以偷懒，画 波线并标注可以偷懒几天），最终如下：

概率分布：三个关键的值要记住：99%、95%、68.3%

三点估算 (A+4*B+C)/6=平均值。   方差： =(C-A)/6

(A最好，C最坏情况，B最可能)

加快进度、压缩工期的方法：

1、快速跟进（适合：成本超、进度慢）

2、加班

3、加有经验的人（增加资源）

4、加强沟通，避免变更。

5、加强控制，避免返工

6、提高资源利用率

 7、外包和缩小项目范围

---

SWOT是Strengths（优势）、Weaknesses（劣势）、Opportunities（机会）和Threats（威胁） 

---

资源平滑：不会改变关键路径，可能没优化效果

资源平衡：往往导致关键路径变化（延长），（快记：衡变）

---

权力大利益少的，少打扰他

利益大权力小的，要随时报告情况。

权力、利益都小的，他不太上心，监督一下就像。

---

螺旋模型它是将瀑布模型和快速原型模型结合起来，强调了风险分析，特别适合于大型复杂的系统。

快速原型：需求不确定、开发快、用户参加和决策、简化项目、但质量可能低。

瀑布模型：分阶段干、过程不可逆。适合需求变化不大的系统

瀑布模型

v模型：面向客户、效率高

 wifi协议：IEE802.11

(局域网)以太网协议：IEE802.3

回归测试：修改代码后，测测有没有问题

集成测试：组装子系统，进行测试

冒烟测试：正式测试的版本，确认正常

商业智能：3个关键技术：数据仓库、OLAP、数据挖掘

信息系统生命周期：

系统规划：分析和预测、考虑约束

系统分析：提出新系统的逻辑模型

系统设计：具体设计实现逻辑模型的技术方案，新系统的物理模型

系统实施：买设备、安装、调试、写代码、培训、写报告

---

类比估算：未掌握详细信息，自上而下估算.

成本估算步骤：自下而上

                1、识别和分析构成科目。

                2估算科目成本

                3、分析成本估算结果，寻址代替方案，协调比例

参数估算：掌握详细信息、用历史数据或其他变量进行估算。

应急储备：应付 已知+未知风险，不需要批准就能使用

管理储备：应付：已未知+未知风险，不属于成本基准，使用需要审批。但是项目预算的一部分

项目预算=成本基准+管理储备。  应急储备属于成本基准的一部分

---

简答题：

找茬：一般答案参考：（一条就是一分）

• 没走变更控制流程
• WBS分解有问题
• 范围控制不到位
• 没有编写XX计划、没有让人评审
• 一个人编写了计划
• 没有详细的需求收集过程
• XX意识不足

干系人找茬：

(1) 未编制沟通管理计划:
(2) 独自编制干系人清单不妥
(3) 识别干系人不全面，部分人员未及时开展有效沟通
(4) 干系人沟通方式单一，只采用电子邮件方式:
(5) 管理沟通不力，对于员工的诉求，应私下解决问题，不应在大会上公开说:
(6) 控制沟通不力，采取强迫手段中止张伟的诉求，导致后续的冲突升级
(7) 与高层沟通不力，未得到高层领导的认同。
(8) 周报内容不全:
(9) 月度例会粒度太粗
(10) 制定工作计划时，没考虑资源日历，导致有冲突。

配置管理找茬：

(1)没有编制配置管理计划
(2) 项目经理老王兼任配置管理员，没有专职的配置管理人员
(3)老王给项目组成员开放了全部操作权限
(4) 对于新出现bug没有及时的发现问题并给与解决措施.
(5)没有遵循基于配置库的变更控制流程
(6)没有做好配置审计
(7)沟通管理不到位.
 

立项找茬

(1)未编写项目建议书
(2)看见初步 想，未进行详细可行性研究
(3)未进行项目评估.
(4)招标未公示
(5)招标专家团队人员配置不合理，专家不能少于2/3
(6) 中标候选人不能超过3个
(7) 中标公示结果不能少于3天。

人力资源找茬

(1) 质量工程师编写项目人力资源管理计划是不对的;
(2) 人力资源管理计划应该各干系人参与，而且还需要经过评审
(3) 缺乏合理且有激励性的考核方案;
(4) 进度落后，项目进度计划不合理
(5) 绩效奖金分配不合理
(6)小刘没有即时采取有效的解决方法大家的不满。
(7) 没做好激励，导致员工士气低落和离职。
(8) 没做好沟通管理
(9) 组建、建设团队可能不合理，考虑不充分，导致需要远程办公。
 

万金油找茬

• 1、看到人手紧张，说明人力资源没规划好
• 2、看到技术到管理，说明没管理经验，需要培训
• 3、看到兼任，说明身兼多职，精力不够
• 4、看到有变更直接修改，说明没走变更控制流程
• 5、看到客户的问题似乎不断，说明需求、范围蔓延
• 6、看到老提之前已经提出过的问题，说明没做好文档配置管理
• 7、看到成员开始争吵，说明团队建设没做好，没做好沟通
• 8、看到简单的写了几条合同内容，说明签订管理没做好，必须写详细
• 9、看到某某离职，说明必须要注意团队激励，注意AB角色配置
• 10、看到返工，说明质量不行，也会导致成本、进度的问题
• 11、看到开会时人员从来没到齐，说明项目经理没权力权威
• 12、看到员工汇报言过其实，说明没明确的考核机制
• 13、看到直到什么时候才发现问题，说明监控不力
• 14、看到新毕业，说明没经验
• 15、看到根据自己的经验编写什么东西，都说需要根据项目实际情况
• 16、看到做计划时倒推日期，都说这是最迟时间，风险很大
• 17、看到第一次看到X计划，说明编写计划时，大家没参与
• 18、看到改了若干错别字，匆忙的通过计划，说明在走过场。
•  19、看到需求文件，必须要记得评审，需要甲方签字或提修改意见
• 20、看到xX是老客户，后面一般会出问题了....
• 21、看到分几个小组分别开发，一定要注意沟通协调
• 22、看到并行施工，说明会增加风险
• 23、看到参考别的项目写了XX东西，一定要说还要结合本项目
• 24、看到项目经理亲自动手做技术就说项目经理主要是管理，不做技术
• 25、看到项目经理发布项目章程，肯定说不对
• 26、看到一个人写了XX计划，一般是不对
• 27、看到背景里比较详细的罗列了XX东西包含XX东西，一般说明这东西不全
• 28、看到口头通知，说明需要书面
• 29、看到马上去做，说明需要先确认
• 30、看到有XX文档，一般来说，都是需要经过评审的
• 31、看到有外包商，一定要看看平时多交流沟通没
• 32、看到初步了解什么东西，都要说详细了解
• 33、看到时间安排的非常紧张，就说明没冗余
• 34、看到取消每日（周）例会，说明监控粒度粗了
• 35、看到必须严格按照XX计划进行，说明不现实，不可能没偏差
• 36、看到版本很多，不知道如何对应，说明文档配置没做好
• 37、看到一个人做了风险识别，需要知道风险识别需要全员做，需要反复做。
• 38、看到CCB成了作业机构都是不对的，它是决策机构
• 39、看到项目经理同意（拒绝）变更，都是不对的，需要CCB。
• 40、看到开发人员做测试，说最好是专业的测试人员，至少也是交叉检查。
• 41、看到重新招聘人员，说明人力不够，还要注意新人员的磨合，还要注意培训
• 42、看到因为工期紧张，取消一些流程都是不对的，都需要完整的走流程
• 43、看到签订了xX合同，一定要看看条件，能不能签订这样的合同
• 44、看到招标文件，看看是否应该是投标文件;反之，亦然。
• 45、看到国外的公司，一定要注意其产品是否符合国家政策，是否会跑路
• 46、看到做了初步可行性研究，一定要看看有没做详细可行性研究
• 47、看到配置库，一定要看看是不是分了3个库，库的权限是否正确
• 48、看到简单的编写了XX计划，需要说尽力编写详细的计划
• 49、看到成员怕项目经理不高兴，不敢提意见，说明项目经理平时是×理论，氛围太死板
• 50、看到项目建议书，一定要看是谁写的，报谁审批的
• 51、看到项目经理怕甲方不高兴，不敢如实汇报项目情况，说明沟通不畅
• 52、看到计划跟不上实际项目情况，说明没对计划进行更新
• 53、看到政府采购，一定要注意采购的方式是否正确，比如追加的时候超过10%没
• 54、看到分包，一定要注意是否符合分包的条件，比如经过同意、非主体、非关键、资质、再次分包等。
• 55、看到全权让别人做什么事情都不对，要你项目经理干嘛的?
•  56、看到采用了比如瀑布模型，看看这模型是不是对的?可能应该是用别的模型
• 57、看到投标人会议、踏勘项目现场等，一定要注意是否应该是全部潜在供应商。
• 58、看到招投标法、政府采购法，一定要注意一些数字是否正确。
• 59、看到项目经理不知道怎么办，很迷茫、困惑，都是没PMO，没公司高层的支持和帮助。
• 60、看到团队成员不知道怎么办，不会做什么，说明没经过培训，没这方面的意识。
• 61、看到联合体投标，一定要注意联合体的资质是否满足要求
• 62、看到有冲突，没解决好，导致事情停滞不前，都要说明冲突管理没做好。
• 63、看到一些沟通方式、沟通频率，一定要注意方式、频率对不对?
• 64、看到罗列了一些干系人，一定要注意干系人全了没?
• 65、看到删除了旧版本，一定是不对的，另外，一定要注意文档的积累。
• 66、看到团队成员消极怠工，说明没做好建设和激励
• 67、看到虚拟团队，一定要说下缺点，说需要多沟通
• 68、看到wBS 分解，一定要注意分解的时候有没遵循相关的原则和注意事项
• 69、看到选择报价最低的供应商，一般是不对的，选择标准可能不对，后期也可能出问题
• 70、看到与甲方争吵，都是沟通管理、干系人管理没做好
• 71、看到自学了XX东西，都要说经过系统的培训。
• 72、看到在做xX过程时，采用了xx工具，一般可以说采用的工具比较单一。
• 73、看到根据员工是否闲着、兴趣来组建团队，一定要说需要根据项目实际情况来选人。
• 74、看到奖励，一定要注意有没惩罚，要奖惩分明。
• 75、看到为了方便而怎么做，一般大概率是错的。
• 76、看到新技术，一定要说注意风险，要沟通
• 77、看到有人对项目不满意，一定要多沟通交流。
• 78、看到推诿扯皮等，就说是职责不清，沟通没做好
• 79、看到多头汇报，就说项目经理权利不够，或者是组织结构不对。
• 80、看到过渡承诺，说明没注意实际情况，没考虑风险等。

---

案例分析题：

1、可行性研究的分类（下面有）

2、项目章程的内容（下面有）

3、项目管理计划的内容（下面有）

4、范围说明书的内容

（说清楚描述，还有衡量标准，才能说确定的成果，以及不可预见的责任）

①产品范围描述

②验收的标准

③可交付的成果

④项目除外的责任

5、WBS的分解步骤：

（先看到底有多少，再选择核实的分解方法，拆解划分标号，核实对不对）

①识别和分析可交付的成果

②确定WBS的编排方法和结构

③自上而下逐层细化分解

④为WBS组成部分制定和分配标识编码

⑤核实可交付成果分解的程度是否恰当

6、WBS分解的注意事项（下面有）

①必须是面向可交付的成果

②一般分解4-6层

③每个工作包有明确的责任人，而且只有一个人负责

④每个工作包不超过80小时

⑤wbs的分解需要所有（主要）干系人人参与

⑥wbs并非一成不变

7、缩短工期的办法

加有经验的人、加强质量控制避免返工、优化施工方案提高效率、加强沟通、加强管理

8、4种依赖关系

1. 强制性依赖关系：活动有先后，不能调整
2. 选择性依赖关系：多种方式来完成目标，可以调整
3. 外部依赖：基于经验或建议，通常可以调整
4. 内部依赖

9、资源平衡和资源平滑的区别

资源平衡：（着眼大局，影响关键路径）充分利用和调度资源，避免某个资源过度占用而导致其他活动资源短缺，

资源平衡：（着眼个别活动，可能影响关键路径）适当调整，调整的是个别活动。

10、成本估算的步骤

11、成本预算的步骤

12、管理储备、应急储备

成本基准包括应急储备，但不包括管理储备，

13、质量管理的工具和技术

14、质量审计的目的 
15、团队的5个阶段

形成、震荡、规范、发挥、解散。

以上可以跳过或回退到某个阶段

16、马斯洛、X、Y

①生理需求、②安全需求、③社交需求、④尊重需求、⑤自我实现需求

X理论认为人是善，Y理论认为人恶

赫茨伯格双因素理论：激励因素、保健因素

期望理论：目标+期望。

17、冲突的解决办法

撤退/回避、妥协/协调、强迫/命令、合作/解决、包容/缓和

18、5个权力 

专家、职位、参照、奖励、惩罚

19、三种沟通方法

推送、拉式、互动

20、权力利益方格

权力大利益小 让它满意，权力小利益大随时告知
21、干系人参与评估矩阵

22、配置管理的6个活动

23、功能配置审计
24、物理配置审计 
25、变更管理的角色和职责 
26、变更的流程
27、风险管理的各工具和技术 

风险登记册内容：已识别风险清单、潜在风险责任人、潜在风险应对措施

风险报告内容：风险来源、已识别单个项目风险的概述报告

针对威胁5种策略：

1. 上报
2. 规避
3. 转移
4. 减轻
5. 接受

针对机会5种策略：

1. 上报
2. 开拓
3. 分享
4. 提高
5. 接受

28、招投标法、政府采购法的一些数字 
 

配置库变更流程：

基于配置管理的变更控制流程:
(1）将要升级的基线从产品库，取出，放入受控库（主库）;

(2）程序员将欲修改的代码段从受控库检出，放入自己的开发库中进行修改;
(3）程序员将开发库中修改好的代码段检入受控库;
(4）软件产品的升级修改工作全部完成后将受控库中的新基线存入产品库。

 总结严格程度：产品库>受控库>开发库

质量审计的目标是:
(1）识别全部正在实施的良好及最佳实践。

(2）识别全部违规做法、差距及不足。
(3）分享所在组织或行业中类似项目的良好实践。
(4)积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率。

(5）强调每次审计都应对组织经验教训的积累做出贡献
 

项目建议书的内容：

记忆（二遇二逼）（说明为什么要创项目、分析当前市场、预期、可行性     ）

1、逼：必要： 项目必要性

2、逼：必需：项目建设必需条件

3、遇：预测：项目市场预测

4、遇：产品方案或服务市场预测

可行性研究步骤：

分类有：技术可行性、经济可行性、社会可行性。

鬼舅新导就变焦 -》规旧新导荐编交

(规模、旧缺点、新优点、评价、选择方案、写报告、提交)
1)规--》规模--》确定项目规模和目标。
2) 1旧--》旧系统--》研究正在运行的旧系统。
3)新--》新系统-》建立新系统的逻辑模型。
4)导--》导出--》导出和评价各种方案。
5)荐--》推荐--》推荐可行性方案。
6)编--》编写--》编写可行性研究报告。
7) 交--》 递交--》递交可行性研究报告。

可行性内容：

投机风，才阻社稷->投技风财组社济

1)投-》投--》投资--》投资必要性。
2)机-》技-》技术-》技术的可行性。
3)风-》风-》风险-》风险因素及对策。
4)才》财-》财务》财务可行性。
5)阻-》组--》组织-》组织可行性。
6)社-》社》社会-》社会可行性。
7)稷-》济-》经济--》经济可行性。.

项目管理计划编写流程：

1、定目前目标

2、成立项目团队

3、工作准备和信息收集

4、依据模板、标准编写初步的概要项目计划

5、将计划纳入项目继续、再进行综合平衡、优化

6、项目经理负责编写项目计划

7、写完计划让评审和批准

8、获取批准后成为基准计划

把每个小标题的 作用、 输入、输出、意义 引入论文中，作为一个小标题的自己的语言描述和解释即完成论文。

目录

论文：

开头模板：

2021年6月，我作为项目经理参与了某医院的医院信息管理系统项目的建设。该项目总投资900万人民币，建设工期1年。该项目是项目型组织结构。该项目规划为大型综合三甲医院，该医院拥有57个临床科室，15个医技科室，1600 余张展开床位，日门诊量接近5000 人次。近5000人次。项目总投资人民币600万元，建设工期为1年。通过该项目的建设帮助医院实现了全方位、全过程、全对象的总体目标，实现了医院办公的无纸化、无片化。该系统以财务信息、物资信息和病人信息为主线，通过对信息的搜集、存储、传递、统计、分析、报表输出和信息共享等为医院领导及各部门管理人员提供全面精准的各种数据。系统分为六大板块:门诊管理系统，住院管理系统，药房管理系统，药库管理系统，院长查询系统和系统管理系统。本系统突出实用性，保证可靠性，兼顾先进性，具备扩展性。以.net技术作为开发平台，采用c/s 和 b/s混合架构。对于如住院收费、药品摆放等实效性要求高的模块采用c/s架构;对于如医务统计、数值分析等重复操作要求低的模块采用b/s 架构。项目采用unix+Oracle 12c作为数据库平台，thinkserver作为应用服务器。

该项目通过java语言实现。使用javaee+springcloud+mysql+linux等作为软件实现，使用的架构是B/S。

由于本项目涉及到业务考核，因此，在本项目中，xx管理显得尤为重要，在本项目中，我作为项目经理对其余管理领域恪尽职守管理外，特别对XXXX管理从一下几个方面进行管理：XXXXXX。

中间部分：

根据XXX业务外围接口多,业务逻辑复杂的特点,我们意识到规XXXX管理的重要性。
 

结尾模板：

  经过我和我团队的不懈努力，历时1年，最终在2022年6月，通过了业务方组织的验收，为用户解决了XXX问题，达成了XX目的，得到了业主和领导的一致好评。本项目的成功得益于我的XXX成功管理。当然在本项目中还存在一些问题，在项目施工后期有1名队员因为自身原因离职，经过我对项目监控和资源调配，及时纠正了项目进度，没有对项目产生什么影响。在后续的学习和工作中，我将不断充电和学习，多向同行交流和学习，提升自身的业务和管理水平，力争为我国信息化建设做出自己的努力。

结尾模板： 

项目管理： 

①制定项目章程

②制定项目管理计划

③指导与管理项目执行

④监控项目

⑤实施整体性项目变更控制

⑥结束项目

范围管理：

 ①规划项目范围管理

②收集需求

③定义范围

④创建WBS

⑤确认范围

⑥控制范围

项目进度管理 

①规划项目进度管理

②定义活动

③排列活动排序

④ 估算活动资源

⑤估算活动持续时间

⑥制定进度计划

⑦控制监督

项目成本管理： 

 ①规划项目成本管理

②估算成本

③制定预算

④控制成本

 项目质量管理：

①规划项目质量管理

②实施质量保证

③控制质量

项目人力管理

①规划人力资源管理

②组建项目团队

③建设项目团队

④管理项目团队

项目风险管理

①规划风险管理

②识别风险

③实施风险定性分析

④实施风险定量分析

⑤规划风险应付

（新版⑥实施风险应对）

⑥控制风险

项目沟通管理

①规划沟通管理

②管理沟通

③控制沟通

项目干系人管理

①识别干系人

②规范干系人管理

③管理干系人参与

④控制干系人参与

项目采购管理

①规划采购管理

②实施采购

③控制采购

④结束采购

项目资源管理

        ① 规划资源管理

        ②估算活动资源

        ③获取资源

        ④建设团队

        ⑤管理团队

        ⑥控制资源

---

计算题:

概念：

项目总资金预算=管理储备+成本基准

                         =管理储备+ 应急储备 + 成本估算

PV、AC、EV、CV、SV、CPI、SPI、BAC、ETC、EAC

EV=计划值*完成的百分比=PV*X%  =  已经干了多少

PV：计划值 plan value ，计划干多少任务

AC：实际值 Actual Cost，实际干了多少任务= 实际成本（实际花了多少钱）

EV：完成了多少预计的的任务

SV： 进度偏差= EV-PV        S为Schedules

CV:   成本偏差=EV-AC          C为Cost

SPI: 进度绩效指标 = EV/PV        >1 :干快了，<1 :干慢了

CPI: 成本绩效指标 =EV/AC        >1  :节省了，<1:超指了

措施：

超支 又慢，换效率高的人、并行施工

超支 但不满   换高效的人、并行施工

没超支，但慢    加人、

不超支、不慢   维持现状、检查一下质量

非典型的：（余下的工作量按计划的效率、）

Estimate To Complete  完工尚需 估算   （To 为了完成，算还有多少活没干）

ETC= BAC-EV

完工估算Estimate at completion)   （at 完成 完整，算干完活估计实际花费多少钱）

EAC=AC+（BAC-EV）=AC+ETC

典型的（没什么干预，照目前发展的话、按此进度、情况一直持续下去”“这样的绩效会延续下去）

ETC=(BAC-EV)/CPI

EAC=AC+（BAC-EV)/CPI

完工偏差(完工预算与完工估算只差)

VAC=BAC-EAC

概率分布：贝塔：99%、95%、68.3% 

按照目前的方案下去，算总预算：（预算和实际成本总是有差别的，所以引入BAC、EAC）

BAC：完工预算成本(Budget cost at completion):按照原计划，完成所有工作所需的预算成本

         BAC值题目一般直接给出

EAC：完工估算(Estimate at completion)：(全部工作的成本是多少

EAC：完工估算成本=AC+(BAC-EV)=AC+CV= 实际干的+ 成本偏差

完工尚需估算ETC(Estimate (or Estimated) To Complete)：还需要多少钱才能完工

文章参考：（必学一下）

PV、EV、AC、CV、SV、CPI、SPI、BAC、ETC、EAC - 简书 (jianshu.com)

凡是：控制环节：

输入：均含  工作绩效数据、批准的变更请求

输出：变更请求、工作绩效信息

项目整体管理： 

（章、制计划、指导、监控、实施变更、结束）

①制定项目章程

输入：项目合同、项目工作说明书、商业论证、事业环境因素、组织过程资产

输出：项目章程

扩展知识点：

1）、项目章程的内容：

目标总描 风进、预审职

1. 项目目的或批准项目的原因
2. 可测量的项目目标和相关成功标准
3. 项目的总体要求
4. 概括性的项目描述
5. 项目的主要风险
6. 总体里程碑进度计划
7. 总体预算
8. 项目审批要求
9. 委派的项目经理及其职责和职权
10. 发起人或者其他批准项目章程的人员姓名职权

 主要内容：把项目章程内容写上去，并章程指定我为项目经理、方便我调取项目资源

②制定项目管理计划

输入：项目章程、（招标说明书、项目合同等）

输出：项目管理计划 、配置管理系统、变更控制系统

注意点：计划记得要评审

意义：它确定了执行、监控和结束项目的方式和方法，包括项目需要执行的过程、 项目生命周期 、里程碑和阶段划分等全局性内容。 项目管理计划是其它各子计划制定的依据和基础，它从整体上指导项目工作的有序进行。 项目管理计划是一个用于协调所有 项目计划 的文件，可以帮助指导项目的执行和控制。

主要内容：喊骨干开会、按照公司模板制定概要项目管理计划、再通过讨论细节、子计划平衡到总计划总，形成项目管理计划，并经过CCB审批，成为基准计划。

扩展：

1）、 项目管理计划的内容（背景、分任务、解决方案、、实现目标、预算）

1. 项目背景
2. 项目组织及项目职责分配
3. 项目的总体技术解决方案
4. 项目总体目标
5. 项目预算
6. 变更流程和变更控制委员会

③指导与管理项目执行

输入：项目管理计划、批准变更的请求

输出： 可交付的成果、变更请求、工作绩效

工具：会议、专家判断、项目管理信息系统

主要内容:培训员工、熟悉项目、明确职责、团队协作/建设

④监控项目

输入： 项目管理计划、工作绩效、进度预测、成本预测

输出：变更请求

主要内容：对项目进行跟踪、纠偏、定期开周会，定期向高层、客户报告

⑤实施整体性变更控制

输入：项目管理计划、变更请求 、工作绩效报告

输出：批准的变更请求、变更日志

主要内容：有人私下更改了功能，你通过责任分配矩阵找到责任人，强调变更重要性，让他正式提交变更申请、审核、论证、报CCB审批、实施

扩展：变更审批的流程：

1. 提出与接受变更申请
2. 对变更的初审
3. 变更方案论证
4. 项目管理委员会审查
5. 发出变更通知并组织实施
6. 变更实施的监控
7. 变更效果的评估
8. 判断发生变更后的项目是否已纳入正常轨道

⑥结束项目

输入：项目管理计划、验收可交付的成果

输出：最终产品、服务或可移交的成果、组织过程资产更新

主要内容：资料、文档、成果、吸取教训和经验、履行合同、喊领导开会、奖励员工 

范文模板： 

---

范围管理：

（）

 ①规划项目范围管理

 输入：项目章程、项目管理计划

输出：范围管理计划、需求管理计划

主要内容：说明范围管理的重要性：业务复杂，容易导致业务蔓延，完不成项目等，然后开会讨论、查找公司组织过程资产，依据模板、项目章程，制定初步的范围管理计划、再通过专家分析，制定详细管理计划

②收集需求

输入：范围管理计划、项目章程、需求管理计划、干系人登记册、干系人管理计划

输出：需求规格说明书、需求跟踪矩阵

主要内容：带领团队走访调研客户需求，采用访谈的方式一对一采集需求并整理后，与干系人开展引导式研讨会，挖掘需求、消除歧义、达成一致，形成需求规格说明书和需求跟踪矩阵

扩展：与干系人的调查手段：

• 1、访谈：走访
• 2、焦点小组.
• 3、引导式研讨会
• 4、群体创新技术：头脑风暴（得到综合的风险清单）、德尔菲技术（组织专家拿结论，免得被带偏）、名义小组（分小组，每人提创意，直至足够多）
• 5、群体决策技术.
• 6、问卷调查
• 7、观察
• 8、标杆对照：参考、借鉴类似的项目

③定义范围

 输入：范围管理计划、项目章程、需求文件

输出：项目范围说明书

方法：引导式研讨会、产品分析、备选方案生成、专家判断

主要内容：与主要干系人开会讨论，确定需求，并让客户负责人签字确认。最终确定项目范围说明书，再解释说明书的内容，（最好结合本身项目说）

扩展：范围说明书的内容：（必记）

1. 产品范围描述（老忘）
2. 验收标准
3. 可交付成果
4. 项目的除外责任
5. 制约因素
6. 假设条件

④创建WBS

输入：范围管理计划、项目范围说明书、需求文件

输出：范围基准、项目文件更新

主要内容：基于范围说明书，让主要骨干都参与到项目的分解，阐述分解规则，再说根据自己的项目，按子系统划分、

扩展：分解规则：

1. 各层次上保证项目的完整性（按模块列出，避免遗漏）
2. 一个工作单位只属于某个上层单元
3. 相同层次的工作单元应有相同的性质
4. 工作单元应能分不同的责任人和不同的工作内容
5. 工作单元一般不超过80个小时（一般最小>8）

扩展考点：

WBS必须指定有且只有一个 负责人，即时实际干活的有多个人

工作包应小于80

WBS最好分4-6层，（大项目可以超过6层）

应该喊多个人来分解（需要主要干系人参加、团队成员参加），不能自己去分解

外包出去的模块记得算上（完整性）

WBS:

分解什么：识别和分享可交付成果和工作

怎么分解：确定WBS的结果和编排方法，分5层

分解：自上而下，逐层细化，逐渐清晰

⑤确认范围

输入：需求文件、需求跟踪矩阵、核实可交付的成果、项目管理计划、工作绩效数据

输出：验收的可交付成果、变更请求

方法：检查、群体决策技术

主要内容：（确定时间、哪有哪些投入、正式被接受标准和要素、确认会议的组织步骤、会议）分阶段的里程碑邀请干系人、客户、监理参与评测，签字确认，非里程碑的任务多沟通

 存在歧义的，可以提交正式的变更流程，经过变更管理委员会批准。

⑥控制范围

输入：工作绩效数据、需求文件、需求跟踪矩阵、项目管理计划

输出：工作绩效信息、变更请求、项目管理计划更新

方法：偏差分析

主要内容：分析工作绩效数据、对照范围基准，进行纠偏。阐述：变更申请的流程。举例说有人修改了某个功能，自己根据责任分配矩阵找到该模块负责人，强调变更流程的重要性，让其提交正式变更。

扩展：

变更的原因：（政策、客户刁蛮、自己倒闭、技术不行、计划错误）

1、政府政策原因

2、计划不够周密、有缺陷漏洞

3、出现了新技术、方案

4、客户对项目提出了变更

5、项目执行组织发生了变化

---

项目进度管理

（规、定、排、估资、估时、制计划、控制）

①规划项目进度管理

输入：项目管理计划、项目章程

输出：进度管理计划

主要内容：多次召集甲方、监理的负责人会议、专家判断制定进度计划。

②定义活动

输入：进度管理计划、范围基准

输出：活动清单、活动属性、里程碑清单

方法：分解、滚动时规划

主要内容：是为了识别和记录完成项目可交付成果而采取的具体行为的过程。在进度管理计划、范围基准的指导下，采用滚动式规划的方法，我和组员对WBS最近要完成的工作进行分解，得到具体要完成活动，形成活动清单

③排列活动排序

输入：进度管理计划、活动清单、活动属性、项目范围说明书

输出：项目进度网络图

方法：紧前关系绘图法、确定依赖关系

主要内容：依据活动清单、确定依赖关系，制定项目进度网络图。举例说明模块谁前谁后，最终反复调整得到较为合理的网络图

④ 估算活动资源

输入：进度管理计划、活动清单、资源日历、风险登记册、活动成本估算

输出：活动资源需求、资源分解结构

方法：自下而上估算、发布的估算数据、备选方案分析

主要内容：估算执行各项活动所需的材料、人员、设备、用品种类或数量的过程。我们使用专家判断和历史项目类比的方法进行。对活动清单的工作量进行估算、资源依赖关系、考虑风险因素、依据劳动生产率推出资源数量

⑤估算活动持续时间

输入：进度管理计划、活动清单、资源日历、项目范围说明书、风险登记册、资源分解结构

输出：活动持续时间估算

使用评估手段：三点估算法、类比估算、参数估算、群体决策技术、储备分析

主要内容：依据经验、考虑资源和时间的约束，平衡好活动的资源和时间要求，一般使用三点估算法估计。

⑥制定进度计划

输入：进度管理计划、活动清单、活动属性、项目进度网络图、活动资源需求、活动持续时间估算、项目范围说明书、项目人员分解、资源分解结构

输出：进度基准、项目进度计划

主要内容：运用资源平衡和模拟，绘制进度甘特图、时间表

⑦控制进度

输入：项目管理计划、进度计划、工作绩效数据

输出：工作绩效信息、进度预测、变更请求

主要内容：每日跟踪，召开周例会，汇报进展，每2周进行一次挣值分析，计算进度偏差和趋势分析。对重要里程碑，依据当前绩效，对完工时间进行预测。并写入绩效报告、通知客户和干系人。

扩展：进度控制措施： 

1. 加班
2. 增加人力资源
3. 用有经验的人
4. 用高效的技术

---

缩短工期的方法：

1、加班、赶工

2、投入更多资源

3、减少活动范围、降低活动要求

3、快速根据。（并行施工）

4、用nb的人

5、用nb高效的技术

6、加强管理，减少返工、加强沟通减少变更

项目管理成本： 

 ①规划项目成本管理

 输入：项目管理计划、项目章程

输出：成本管理计划

②估算成本

输入：成本管理计划、人力资源管理计划、范围基准、项目进度计划、风险登记册

输出：活动成本估算

方法：专家判断、类比估算、参数估算、自下而上估算、三点估算、储备分析、质量成本、群体决策

质量成本：

分为 ：

一致性成本：（开发完成前）

        预防成本：培训、设备、文化（质量保证）

        评价成本：测试、破坏损失、检查

非一致性成本：（开发完成后）

        内部失败成本：废品、返工

        外部失败成本：责任、保修、业务流失

③制定预算

输入：成本管理计划、范围基准、活动成本估算、估算依据、项目进度计划、资源日历、风险登记册

输出：成本基准

方法：成本汇总、储备分析、专家判断

④控制成本

输入：项目管理计划、项目资金需求

输出：成本预测、工作绩效信息、变更请求

方法：挣值管理、预测、绩效审查

主要内容：

1、对造成成本基准变更的因素施加影响

2、确保变更请求获得同意
3、当变更发生时，管理这些实际的变更
4、保证潜在的成本超支不超过授权的项目阶段资金和总体资金

5、监督成本执行，找出与成本基准的偏差
6、准确记录所有的与成本基准的偏差
7、防止错误的，不恰当的或未获批准的变更纳入成本或资源使用报告中

8、就审定的变更，通知项目干系人
9、采取措施,将预期的成本超支控制在可接受的范围内
 

 项目质量管理：

①规划项目质量管理

输入：项目管理计划、关系人登记册、风险登记册、需求文件

输出：质量管理计划、过程改进计划、质量测评指标、质量核对单、项目文件更新

方法：成本效益分析、质量成本、七种基本质量工具、实验设计、统计抽样

②实施质量保证

输入：质量管理计划、过程改进计划、质量测量指标、质量控制测量结果

输出：变更请求

方法：质量管理与控制工具、质量审计、过程分析

③控制质量

输入：项目管理计划、质量策略指标、质量核对单、工作绩效数据、批准的变更请求

输出：质量控制测量结果、确认的变更、核实的可交付成果、变更请求、工作绩效信息

项目人力管理

①规划人力资源管理

输入：项目管理计划、活动资源需求

输入：人力资源管理计划

工具：组织图和职位描述

②组建项目团队

输入：人力资源管理计划

输出：项目人员分派、资源日历、项目管理计划更新

方法：预分派、谈判、招募、虚拟团队、多标准决策分析

③建设项目团队

输入：日历资源管理计划、项目人员分派

输出：团队绩效评价

方法：培训、团建活动、基本规则、集中办公、奖励、人事测评工具

④管理项目团队

输入：日历资源管理计划、项目人员分派、绩效评价、问题日志

输出：变更请求、项目管理计划更新

方法：观察和交谈、项目绩效评估、冲突管理

扩展知识点：

1、形成阶段：个体变队员，认识和了解，知道自己的职责

2、震荡阶段：指责、怀疑

3、规范阶段：协同工作

4、发挥阶段：由荣誉感、协调工作

5、解散阶段：解散

不管什么阶段增加一人都从形成阶段开始

职权：

1、职位权力

2、专家权力：个人专业技能

3、奖励权力

4、惩罚权力

5、参照权力：榜样的力量

解决团队矛盾的方法：（策反 妥合强（撤、缓、妥、合、强））

• 撤退/回避(lose-lose)

                不处置，不作为

• 缓和/包容(lose-win)

                强调一致而非差异，求同存异，异的部分未解决

• 妥协/调解(lose-lose)

                各退一步，可能导致初衷都未实现

• 强迫/命令(win-lose)

                通常用来解决紧急问题

• 合作/解决(win-win)（面对）

        合作的态度&开放式对话

项目风险管理

①规划风险管理

输入：项目管理计划、项目章程、干系人登记册

输出：风险管理计划

②识别风险

输入：风险管理计划、成本管理计划、质量管理计划、质量管理计划、人力资源管理计划、范围基准、活动成本估算、活动持续时间估算、干系人登记册、采购文件

输出：风险登记册

方法：文档生茶、信息收集技术、核对单分析、假设分析、swot分析

知识点扩展：

风险要是要反复识别的！

SWOT:优势（Strengths）、劣势（Weaknesses）、外部竞争上的机会（Opportunities）和威胁（Threats）

③实施风险定性分析

输入：风险管理计划、范围基准、风险登记册

输出：项目文件更新

方法：风险概率和影响评估、概率和影响矩阵、风险数据质量评估、风险分类

④实施风险定量分析

输入：风险管理计划、成本管理计划、进度管理计划、风险登记册

输出：项目文件更新

方法：数据收集和展示技术、定了风险分析和建模技术、专家判断

⑤规划风险应付

输入：风险管理计划、风险登记册

输出：项目管理计划更新、项目文件更新

方法：消极风险威胁的应对策略、积极风险或机会的应对策略

知识点扩展：

应对风险措施：

1. 回避:将有情绪风险的人员调离项目组
2. 转移:技术风险通过采用外包方式
3. 开拓:通过培训学习新的安全管理技术
4. 接受:对非预期事件造成的风险采用应急储备来进行应对
5. 减轻:加强部门沟通，建立协调机制
    

 ⑥（（新版⑥实施风险应对））

风险措施：

⑥控制风险（监督风险？）

输入：

输出：

在风险监控中，要跟踪已识别的风险、监督残余风险、识别新风险，并对有效性进行评估。
 

项目沟通管理

①规划沟通管理

输入：项目管理计划、关系人登记册

输出：沟通管理计划

方法：沟通需求分析、沟通技术、沟通模型、沟通方法

②管理沟通

输入：沟通管理计划、工作绩效报告

输出：项目沟通

方法：技术、模型、方法、报告绩效

③控制沟通

输入：项目管理计划、项目沟通、问题日志

输出：工作绩效信息、变更请求

---

项目干系人管理

①识别干系人

输入：项目章程、项目管理计划

输出：干系人登记册、变更请求

方法：关系人分析、专家判断、文件分析

②规范干系人管理

输入：项目管理计划、干系人登记册

输出：干系人参与计划

方法：专家判断、数据收集（标杆对照）、思维导图

③管理干系人参与

输入：干系人管理计划、沟通管理计划、变更日志

输出：问题日志、变更请求

方法：沟通方法

④控制干系人参与

输入：项目管理计划、问题日志、工作绩效数据

输出：工作绩效信息、变更的请求

---

项目采购管理

①规划采购管理

输入：立项管理文件、项目章程、项目管理计划、项目文件

方法：专家判断、数据收集（市场调研）

输出：采购管理计划、采购策略、招标文件、采购工作说明书

②实施采购

输入：范围、需求、沟通、风险、采购 计划，成本基准

方法：专家判断、投标人会议

输出:选定卖方、协议、变更请求、（更新）项目管理计划

③控制采购

输入：项目管理计划、项目文件、采购文档、工作绩效数据、批准的变更请求

方法:专家判断、索赔管理、检查、审计

输出：采购关闭、更新采购文档、工作绩效信息、更新项目管理计划

④结束采购

项目资源管理

 ① 规划资源管理

依据项目类型和复杂度确定项目资源管理的方法和管理程度

 ②估算活动资源

估算项目所需的团队资源、材料、设备、用品的类型和数据量

 ③获取资源

获取项目所需的团队资源、材料、设备、用品的类型和数据量

  ④建设团队

提高工作效率、团队互动、改善氛围，减少摩擦，激励员工

  ⑤管理团队

跟踪成员工作表现、反馈、解决问题，优化绩效。

  ⑥控制资源

 确保按计划分配资源，监督实际情况，及时纠偏

十大范文参考：

项目整体管理：

    2016年5月，我作为项目经理参与了某医院的医院信息管理系统项目的建设。该项目规划为大型综合三甲医院。拥有57个临床科室，15个医技科室，1600余张展开床位，日门诊量接近5000人次。项目总投资人民币 600万元，建设工期为1年。通过该项目的建设帮助医院实现了全方位、全过程、全对象的总体目标，实现了医院办公的无纸化、无片化。该系统以财务信息、物资信息和病人信息为主线，通过对信息的搜集、存储、传递、统计、分析、报表输出和信息共享等为医院领导及各部门管理人员提供全面精准的各种数据。系统分为六大板块:门诊管理系统，住院管理系统，药房管理系统，药库管理系统，院长查询系统和系统管理系统。本系统突出实用性，保证可靠性，兼顾先进性，具备扩展性。以.net 技术作为开发平台，采用c/s 和 b/s混合架构。对于如住院收费、药品摆放等实效性要求高的模块采用c/s 架构;对于如医务统计、数值分析等重复操作要求低的模块采用bl/s架构。项目采用unix+Oracle 12c作为数据库平台，thinkserver作为应用服务器。
        由于本项目的顺利上线涉及到业务考核，因此，在本项目中整体管理尤为重要。作为项目经理，我除了对其他领域恪尽职守外，特别对整体管理从如下几个方面进行了管理。

        1、制定项目章程
        项目章程是正式批准一个项目的文档，我公司在项目中标以后，便依据项目合同，项目工作说明书等编制了项目章程。内容包括项目的目的和项目批准的原因，可测量的项目目标及相关成功的标准，项目的总体要求，总体预算，概括性的项目描述及主要风险和总体里程碑进度计划等。并任命我为该项目的项目经理。有了公司的授权与正式任命，我就可以调取与项目有关的资源，为日后项目工作提供了良好的保证。

2、制定项目管理计划
项目管理计划确定了执行，监督，控制和结束项目的方式方法等全局性的内容。项目管理计划是其他各子计划的依据和基础，制定一份合理的计划是保证项目顺利实施并取得成功的关键。
        在本项目中，我组织项目骨干人员根据项目章程，招投标文件以及项目范围说明书，依照公司模板制定出概要的项目计划，然后编写相关子计划并纳入到总计划中进行平衡优化，最后编写出一份完整的项目管理计划。内容包括项目的背景，项目组织及职责分配，项目总体的技术解决方案，完成过程的技术和工具的描述，项目的最终目标，进度计划，项目预算变更流程和变更控制委员会等，此计划经过评审后成为基准计划。

3、指导与管理项目执行
        指导与管理项目执行是通过各种行动来执行项目管理计划，以完成项目范围说明书中定义的各项工作并提交项目合格交付物的过程。项目管理计划及其子计划解决如何做的问题，而指导与管理项目执行是解决做的好的问题。
在本项目中，我们首先高度重视计划的宣传贯彻和执行，组织项目所有成员认真学习项目管理计划，要求他们从全局上了解项目的总体计划，清楚自己在计划中的位置和作用;其次，我特别注意培养团队协作文化;再次，在项目执行过程中我努力将管事和管人相结合，一方面用我丰富的项目经验为大家做好工作提供力所能及的指导，同时也注意观察项目成员的思想动态，发现工作表现深层次的原因，力争治标治本。
4、监控项目工作
        监督与控制项目工作就是将项目的执行情况和计划进行比较，若有偏差就纠偏的过程。在项目实施过程中，一定要不断的监控，进行对比分析，做好项目的纠偏控制。在此项目中，我充分重视对项目进行定期的跟踪，及时了解项目的进展情况，如成本，进度等是否存在偏差，及时分析偏差产生的原因并采取必要的纠正措施。通过周例会，项目周报的形式定期与客户，公司高层等干系人进行有效的沟通，这是保证项目实施顺利的重要条件。
例如，在项目中期的时候，我们进行了一次绩效测量，发现 cpi的值为1，spi的值为0.98，发现进度落后。经分析，一个员工对关键技术掌握不够熟练导致进度停留。我及时向公司申请支援，然后赶工，逐步追上进度，使成本和进度都达到计划要求。此后，我们每周例会监控，在例会上汇报工作完成情况，有问题就分析问题，提出解决方案形成会议纪要并安排专人监督跟踪落实。通过这些方法的综合运用，有效保证项目工作的可控。

 5、实施整体性变更控制
        整体变更控制是审查主要可交付成果，组织过程资产，项目文件和项目管理计划的变更请求。变更控制贯穿于项目的始终，变更是不可避免的。

        在本项目门诊管理系统实施过程中，发现门诊管理系统下的挂号系统增加了一个功能，手机支付。我查阅产品范围说明书和变更日志，均没有发现这条功能的记录。于是我按照责任分配矩阵，找到该模块的负责人，询问原因，原来这个功能是员工自行添加的。针对这种情况，我再次强调变更流程的重要性,其次我要求相关人员提交正式的变更申请,走正式的变更流程。先提交变更申请，然后变更审核，论证，报CCB审批，审批后才能实施，并且要变更验证和存档。作为项目经理的我深知，变更流程是多么重要，批准或否决的变更都要纳入到基准计划中去。只有遵守严格的变更控制流程才能防止项目随意变更，防止需求蔓延和镀金行为的发生。 

6、项目收尾
        结束项目或阶段是完结所有项目管理过程组的所有活动，正式结束项目或阶段的过程，本过程主要作用是总结经验教训，正式结束项目，为开展新工作释放组织资源。在本项目中，我们切实进行了项目收尾的相关工作，包括资料、维护工作移交到我公司售后部门，对售后人员进行培训，组织项目组成员评估项目完成情况，撰写项目经验教训总结，履行合同涉及的条款，召开完工会并请领导参加，对表现优秀的员工进行表扬和奖励。
        该项目经过全体成员1年的努力，在2017年5月，通过了业主验收，在项目验收会上得到客户和公司高层的一致好评。回顾而言，项目的成功很大程度上得益于我成功的整体管理。启动阶段引入整体管理的理念和方法，对项目进行科学规范的整体管理，使项目所有组成部分在适当的时间充分结合在一起，极大提高项目实施的效率。当然，在项目中也有些不尽人意的地方，比如团队震荡阶段的管理等。在以后的工作中，我一定不断充电，努力学习，我相信通过不断的积累和不懈的努力，我的信息系统项目管理能力会不断提高。

---

范围管理:

        2018年1月，我作为项目经理参加了某银行票据管理系统的项目建设，该项目投资共600万元，建设工期为1年。该银行是一家地方性城市商业银行，近几年随着业务的发展，票据业务利息收入逐年攀升，最高年份能达到公司利息收入总额的35%左右，该银行本着提高收益、提高票据流转效率、降低交易成本方面考虑，决定进行票据管理系统项目的建设。该银行原有票据业务一直是手工进行操作，2015年行内信贷管理系统上线后，票据审批与登记功能在信贷管理系统里进行管理，但十分有限，所以要求新建设的票据管理信息系统具备以下功能:通过票据系统审批，将审批结果通过实时接口传递的方式传递到信贷管理系统中去;票据流转涉及到相关账户资金变动的，通过实时接口调用传递到核心系统，完成核心系统自动账务处理，并将结果传递给票据管理系统。

        该系统采用c/s 架构,服务端应有采用J2EE+oracle 的模式开发,服务器采用HP的580G7，操作系统为Red hat 企业版Linux5.4，数据库使用Oracle 11g R2并做RAC，中间件采用IBM的Websphere并做集群。终端应用基于Microsoft的window CE平台，采用C#语言开发;运行于PDA 上。项目采用矩阵型组织结构，从各职能部门抽调主干成员，组成专门的项目团队，其中需求小组5人，开发小组10人，测试小组5人，实施小组9人，质量小组3人，商务和外协支持5人。

 一、规划范围管理
        根据票据业务外围接口多,业务逻辑复杂的特点,我们意识到规范项目范围管理的重要性。规范范围管理就是编制范围管理计划，具体描述如何定义，确认和控制项目范围的一个过程。如果范围管理计划做不好，可能就会导致范围定义不清、范围蔓延，甚至无法完成项目。
        因此，在该项目中，我们考虑到我们公司曾经做过类似的票据系统项目，有一些业务和技术方面的骨干成员，我们采用专家判断法来制定范围管理计划。但由于该项目本身的特殊性、系统接口过多和业务逻辑的复杂性，使得专家判断法的局限性在该项目中被放大，所以我们仍然查找了公司的组织过程资产，找出制定范围管理计划的模板和标准，并结合该项目的项目章程，作为专家判断法的一个补充，制订了一份初步的范围管理计划，然后召集项目团队成员讨论，对项目进行修改和完善，最终在全体参与下，最终完成一份详细的、科学的范围管理计划，用于指导项目如何定义、确认和控制范围。
二、收集需求
        从事多年的项目管理的我深知收集需求的重要性，收集需求看上去简单，做起来却很难。实际上收集需求就是记录和管理干系人（比如该银行的票据业务经办岗）的需求的过程，但是有时干系人无法完整描述需求，而且也不可能考虑到系统的全貌。因此，收集需求只有通过与干系人有效合作才能成功。在项目的早期阶段，我带领团队成员到客户现场收集需求，我们组织了票据管理部、信贷管理部、营业网点经办岗、营运管理部、印章管理部等部门，采用访谈的方式一对一收集需求。在收集需求的时候，客户对需求描述的不是很清楚，而且各部门之间的需求差异还比较大。针对这种情况，我们将采用访谈方式收集到的需求进行整理后，邀请各干系人和我们各小组成员参加引导式研讨会，进一步发掘用户需求，消除大家对需求的歧义，几经讨论，最终形成该项目的软件需求规格说明书和需求跟踪矩阵。
三、定义范围
        我们团队以范围管理计划和软件规格需求说明书等需求文件为基础，召集项目的主要干系人进行开会讨论，同时邀请了系统的最终的用户代表（包括银行的票据经办岗位、信贷审批岗等）对系统功能做出评价，通过用户角度，去改进系统功能，最终制定出完整的项目范围说明书，并由该银行相关负责人签字确认。范围说明书内容包括: 1、产品范围描述(包括票据签发、票据兑付、贴现等）2、项目的可交付物（用户文档、应用系统等）3、系统验收标准(功能满足需求、系统运行稳定、相关文档齐全等)4、项目的除外责任（该项目涉及的机房环境改造、强电、弱电改造不包含在该项目范围中)5、制约因素(之前的系统设计只针对现有的票据类型，如果扩展新的票据种类，必须追加投入并延长项目时间)6、假设条件（假设项目涉及的票据业务流程优化、人员业务能力提高可以配合票据系统进行持续改进;假设该银行的其他业务系统可以满足票据系统上线后给其增加的负载)。

 四、创建WBS
        基于项目范围说明书和需求文件，我和我的团队开始对票据管理系统和项目管理的工作进行分解，分解为更小的、更易管理的工作单元，使得原来看起来非常笼统、模糊的项目目标一下子清晰起来，使得项目管理有依据，项目团队的工作目标变清晰。由于WBS分解涉及到将要开展的具体工作，我让各小组的组长、骨于成员和银行相关人员都参与到WBS的分解中。我们进行wBS分解时制定了如下原则:在各层次上都保证项目的完整性;一个工作单元只从属于一个上层工作单元，比如基本界面设计这一工作单元只能从属于它上层工作单元程序设计，不能从属于其他上层工作单元，例如软件测试;相同层次的工作包应有相同性质;工作包一般不大于80小时。我们按照项目的生命周期的各个阶段作为分解的第二层，产品和可交付物作为第三层来分解wBS。第二层包括需求调研、分析设计、程序设计、软件测试;第三层是对第二层的进一步细化，比如需求调研包括用户调研、需求分析、用户确认，软件测试包括单元测试、集成测试、系统测试等。对于wBS中工作单元的细节信息，我们在WBS字典中加以描述。WBS分解工作完成后，项目范围基准就确定了。
五、范围确认
        项目可交付成果、子功能比如票据签发功能和票据再贴现功能被开发出来之后，我们项目组内部先对其进行评审和测试，通过后，把这些成果交付给用户，和用户一起按范围基准、质量标准等要求进行确认范围（即验收)。由于该项目范围广、功能点多，我们找客户进行局部确认范围的频次较高，在里程碑点一般举行较为正式的会议，非里程碑点一般通过当面交流的方式，虽然这样做增加了不少工作量，但对于最后一次性通过竣工验收非常有利。在确认范围时，对于局部确认范围，我们主要是邀请客户方、监理方参与评审和测试;对于全局确认范围，主要是由客户方邀请第三方进行评审。

六、范围控制
        控制范围就是监督项目的范围状态，管理范围变更的过程。其主要作用是在整个项目期间保持对范围基准的维护。对项目范围进行控制，就必须确保所有请求的变更都经过实施整体变更控制过程的处理。因该项目比较复杂,,所以项目一开始我就高度重视范围的控制工作。例如，在项目进行过程中，票据经办岗人员要求增加一个批量导入回购票据的功能，通过变更流程提交到cCB后，此时项目已经进入试用阶段，如果同意修改，必然会影响项目进度，最后考虑到项目的实施风险等因素，得出的结论是，暂时不实施变更，该功能等到项目结束后作为一个维护项目来进行实施。事实证明，启动变更控制委员会，严格执行变更控制流程，可有效的进行范围控制，防止需求蔓延。 
        经过我们团队的不懈努力，历时1年，该项目终于于2019年1月，通过了该银行组织的验收，将该银行纸质票据业务从手工操作的繁重工作中解放出来，实现了票据业务的信息化管理，得到了业主的好评。本项目的成功得益于我成功的范围管理。当然，在本项目中，还有一些不足之处，比如项目的团队成员有时为设计争吵，导致团队建设出现一些小问题，再比如，与该银行的项目支持者（票据业务部总经理）缺少沟通，导致一些不必要的理解偏差。不过，经过我后期的纠偏，并没有对项目产生什么影响。在后续的学习和工作中，我将不断的充电，和同行进行交流，提升自己的业务和管理水平，力争为我国信息化建设做出自己的努力。

进度管理

        2017年7月，我作为项目经理，参与了国内某港口散货码头信息化系统项目的建设工作，该项目总投资800 万，建设工期为1年。通过该项目的建设，实现了港口现场管理信息化的扩展，提高了港口装卸效率，减少了工作中人为因素的影响，各部门之间步调一致，简化了工作程序。在充分调研国内外散杂货理货业务最新作业模式的基础上，结合港口的实际情况，实现码头现场电子理货生产作业。该项目建设分三部分:散货装卸管理系统改造部分、无线理货系统部分、其他部分。散货装卸管理系统包括调度管理，商务管理，理货管理，库场港存管理，统计系统等几个主要模块，负责装卸现场的作业计划，调度,管理，统计分析等工作;无线理货系统部分是这次项目建设的主要工作，实现模式:电子理货系统通过中间层服务，获取作业任务和配工调度信息，并以内存数据库形式存储。现场使用手持终端，完成现场的业务操作，通过多线程运行，利用4G网络自动上传到电子理货中间层，同时将理货指令中行驶指示传递到倒运车辆GPS终端设备，指示倒运司机前往指定目的地,并且同步其他相关指令到理货其他环节如计量、外理等系统中并执行指令完整性校验;其他部分包括计量系统及各系统之间接口等，根据理货指令，独立执行计量后信息自动传送到中间服务层。
        由于该项目的顺利上线涉及到业务考核，因此，在本项目组中进度管理尤为重要，在本项目中，我作为项目经理除了对其余管理领域进行恪尽职守的管理外，特别对进度管理从如下几个方面进行了管理。

        一、规划进度管理
        作为项目经理的我深知规划进度管理的重要性，在项目初期，我和我的团队，通过现场走访港口的装卸人员，了解了他们对该信息系统的一些看法，并多次召集甲方的IT部门，监控部门，现场调度部门的主要负责人及管理人员一起，通过会议、专家判断，制定了进度管理计划，进度管理计划规定了该项目进度的模型、准确度、计量单位等。保证了实施过程中的进度控制。
二、定义活动
        定义活动是为识别和记录为完成项目可交付成果而采取的具体行动的过程。在进度管理计划、范围基准的指导下，开始着手定义活动。充分的了解项目的需求及项目的范围;然后，我们以详细的项目范围说明书、工作分解结构等相关文档为依据,结合项目活动清单模板及以往项目经验,采用分解技术将项目规划、蓝图设计、系统分析、系统设计、系统实施、数据收集、系统上线等阶段的工作分解为具体、更容易管理的活动，同时将这些详细的活动记录在项目活动清单中，以便团队的每个成员能清楚有多少工作需要完成。我和我的项目组团队成员，本着谁负责谁分解的原则,对WBS项目近期要完成的工作进行分解,得到可以具体要完成的活动,然后汇总成文档，随着项目的进展，项目活动清单也逐步清晰完善。
三、排列活动顺序
        有了活动清单，通过紧前关系绘图法，确定依赖关系，提前量与滞后量等工具与技术，制定出了项目进度网络图。在这一过程中最关键的就是确定各个活动之间的相互关系，能并列的则并列，不能并列的要确定活动之间前后依赖关系和约束关系，有了合理的活动网络图，才能制定出合理的进度计划。例如，在本项目中，无线理货系统WEB部分与GPS终端部分的模块小组所进行的活动既相互独立又相互依赖，因而可以并行进行，但在某些时间点上又存在约束关系，一些在手机上实现的功能要等WEB系统完成后才能进行，我们经过几次反复调整之后才得到较为合理的网络图。
四、估算活动资源
        估算活动资源是估算执行各项活动所需材料、人员、设备或用品的种类或数量的过程。我们主要是通过专家判断和历史项目类比的方法进行的。对于活动清单中的活动，我们组织项目组内有经验的人员参考公司以往项目的数据，先对其工作量进行估算，再根据总工期依据项目网络图中的相互依赖关系，并考虑风险因素，倒推出活动需要的时间，再根据人员的劳动生产率，计算出活动需要的资源数量，并记录在活动资源需求中。
五、估算活动持续时间
        估算活动持续时间是根据资源估算的结果，估算完成单项活动所需的工期。根据我们项目实践经验，它与活动资源估算常常是结合在一起进行的，在进行估算的时候，需要综合考虑时间的限制和资源的限制，平衡好活动的资源需求和时间要求。比如，当时间要求已确定的时候，就要更多考虑的资源的需求;当资源是给定的时候，就要估算时间需求;当二者都是限定的时候，就要考虑赶工等方法，以保证时间要求。所以，活动需要的时间和活动需要的资源是相互依赖的关系，需要在实践中根据实际情况灵活加以考虑。当然，在活动的工作量和资源都确定的情况下,活动需要的时间仍然存在不确定性,我们一般通过活动历时的三点估算法进行估计，以求得尽量符合实际的活动历时，并记录在项目活动历时估算中。

六、制定进度计划 
          进度计划就是根据项目的工作分解情况，结合各活动的先后顺序，参考各活动的历时估算，确定项目中各活动的开始时间和完成时间。项目进度计划是项目的基础，是项目团队后续工作的指南，一个完整的进度计划是最大限度的保证项目在预定的时间内平稳、顺利的进行。在编制进度计划时，我们以项目详细范围说明书、项目管理计划、项目活动清单、项目计划网络图、项目活动资源需求、项目活动历时估算等相关文档为依据，通过以下步骤编制出科学、详细、可行的进度计划:

        (1)根据已识别的活动清单，结合活动的顺序与依赖关系，参照活动的资源估算，活动的历时估算，采用关键链路法编制出初步的进度计划;

        (2）采用资源平衡、进度压缩等技术对进度计划进行重新调整;

        (3）汇总各子项目进度计划，形成项目总进度计划;

        (4)分析项目总进度计划中存在的问题，要求各子项目经理调整各子项目进度计划，直到项目总进度计划合理、可行为止;

        (5)组织相关人员对进度计划进行评审，形成进度基准。
。

七、控制进度。
        控制进度是监督项目活动状态、更新项目进展、管理进度基准变更，以实现计划的过程。在本项目中，对进度进行有效控制是我感觉困难的又一个问题，通过不折不扣地运用前人总结出来的看起来很繁琐的需要日复一日重复做的工作一—跟踪甘特图法和挣值分析法，较好地解决了该问题.我要求每个小组内部所有成员,每日下班前将工作完成情况汇报给本小组负责人，由小组负责人整理出当日小组的整体工作完成情况，画出跟踪甘特图（在原计划甘特图横线下方画出实际进展的横线)，并邮件发送给我，我每日进行跟踪。每周我们召开一次周例会，各小组汇报本周工作进展，也用跟踪甘特图进行展示。每两周我们进行一次挣值分析，将PV(计划值)、AC（实际值）和EV(挣值）绘制成“S曲线”，并根据PV、AC和EV及其它相关信息进行项目偏差分析和趋势分析，根据偏差情况及时采取相应的进度控制措施。本项目我们采用过的进度控制措施有加班、调整人力资源、实施技能培训和选用更高效的技术等。当然，如果确属计划制定不够合理，我们会通过变更控制流程申请对进度基线的变更，以保证进度基线始终对进度的控制具有指导作用，本项目我们共计进行了二次进度基线的变更。另外，对于一些重要的里程碑或阶段，我们都会根据项目当前的绩效，对完工时间进行预测，并写入绩效报告中及时通知干系人，以利于获取他们的支持。由此可见，进度控制也并不难，难的是日复一日地坚持做。
        经过我们团队的不懈努力，历时1年，本项目终于于2018年8月，通过了业主方组织的验收，实现了港口现场管理信息化的扩展，提高了港口装卸效率，减少了工作中人为因素的影响，各部门之间步调一致，简化了工作程序。得到了业主的好评。本项目的成功，得益于我的进度管理。当然，在本项目中，还有一些不足处，比如，在项目的实施过程中，对用户提出的部分变更，未与客户确认即进行了变更，不过，经过我后期的纠偏，并没有对项目产生什么影响。在后续的工作和学习中，我将不断的充电和学习，和同行进行交流，提升自己的业务和管理水平，力争为我国信息化建设做出自己的努力。

成本管理

开头 略。。。。

一、制订项目成本管理计划
        作为项目经理的我深知，项目成本管理计划是后续项目开展过程中的指南和纲领，要确保在批准的项目预算内完成项目，防止成本失控,科学规划成本管理至关重要。在该项目一开始，我将主要时间和精力用在项目成本管理计划的制定上，我组织项目骨干成员、Xxx物流公司业务员、项目对接人等共同探讨，根据项目章程、项目管理计划，编写了《项目成本管理计划》(初稿)，对估算项目成本、制定成本预算，控制成本等进行了规划。我们反复了几次，才理顺了整个项目计划各个部分之间的一致性和合理性。经过几次调整，第一版《项目成本管理计划》终于制定完毕。《项目成本管理计划》规定了项目成本的计量单位、精确度、准确度、报告格式、过程描述、控制临界值等内容，在本项目中，成本估算采用向上或向下取整（例如995.87元取整为996元，100.45元取整为100元)。
二、项目成本估算
制定项目成本管理计划后，需要对完成项目所需资金进行近似估算。在项目初期，由于对项目相关信息掌握得不够，我根据成本管理计划、人力资源管理计划、范围基准、风险登记册、项目进度计划等，按照类比估算的方法对项目成本进行估算，得到项目成本估算。

        第一步，识别并分析项目成本的构成科目。该项目中，条形码的识别需要用到RFID技术，需要熟练掌握传感器技术的技术人员参与，需要传感器设备，需要搭建识别并追踪物流流转信息的平台;        

        第二步，根据已识别的成本构成科目，估算每一科目的成本大小。我所在的项目团队之前为Xx物流公司做过类似的项目，根据过往的经验和数据，估算出了每个科目的成本大小:

        第三步，根据成本估算的结果，找出各种可相互替代的成本，并协调各成本间的比例关系。在本项目中，在传感器的选择上，项目团队成员对市面上的传感器进行分析对比,最终选择了性价比最高的一款，满足了XX物流公司日常运作的需要。
三、项目成本预算
完成项目成本估算后，项目团队成员对项目所需成本进行进一步的细化。根据项目成本管理计划、活动成本估算、范围基准、风险登记册等，        

        第一步，将项目成本分摊到工作分解结构中的每一个工作包上;

        第二步，将每一个工作包的成本分摊到对应的活动上;

        第三步，确定项目成本预算支出的时间计划和项目成本预算计划。在制定项目预算的过程中，运用储备分析，用应急储备应对“已知-未知”风险，纳入成本基准中;管理储备应对“未知-未知”风险，不纳入成本基准。最终，得到成本基准，即经批准的按时间段分配的成本预算，但不包括管理储备。
四、项目成本控制
        要使项目实际发生的成本控制在预算范围之内，需要在项目全过程监控项目成本，分析成本偏差，并采取相应措施纠偏，避免后期出现成本失控，影响项目进展和成效，降低客户满意度。根据项目成本管理计划、项目资金需求、工作绩效数据，运用挣值管理技术，分析每一监控点的计划价值(PV)、挣值（EV)、实际成本(AC)、成本偏差(CV)，对完工时的估算(EAC)，完工尚需成本估算（ETC）进行计算，对引起成本基准变化的因素施加影响，确保变更请求得到及时响应，若发生成本超支，将成本超支控制在可以接受的范围内，定期向项目干系人汇报成本支出情况，最终得到成本预测和工作绩效信息。在选择项目所需的传感器时，由于前期市场调研工作存在漏洞，技术人员对设备适配性未进行全面细致的考量，导致所采购的传感器与开发的项目存在兼容问题，现有技术人员无法通过技术手段解决兼容性问题。若聘请外部专家，需要进行团队成员磨合，解决兼容性问题所需时间不确定，可能影响项目进度，而市面价格更高的另一款传感器设备可以与所开发系统兼容，其稳定性、可靠性更高。经与XX物流公司项目对接人协商，最终决定选购另一款传感器设备。

结尾 略。。。。

质量管理

开通略

一、规划质量管理

        做好质量管理的首要任务必须做好质量管理规划，才能为后续的质量管理活动提供科学、合理、可操作性强的指导，确保质量管理各项工作有章可循、有据可查。我组织项目组根据项目管理计划、干系人登记册、需求文件、公司质量手册、程序文件、作业文件等并结合当前行业政策、各类标准等事业环境因素，通过成本效益分析、流程图、因果图等基本质量工具等工具和技术，于2018年3月15日完成了质量管理计划的编制初稿，并与3月16日进行了项目组内部评审，于3月17日进行了修改完善，对如何实施质量保证、控制质量进行了明确。项目组一致认为具备组织甲方等人员进行评审条件后，于3月20日组织甲方相关领导、项目负责人等一起进行了评审，并及时根据会上专家意见进行了完善，最终形成了定稿的质量管理计划、过程改进计划和质量核对单。有了上述文件，实施质量保证、质量控制等各项质量管理工作就有了基本依据。

二、实施质量保证
       质量保证重点关注于项目的各项过程和活动本身，确保其按照各方面的规划，正确的被执行。因此质量保证贯穿于项目的始终，而且应该在项目经理的带动下全员参与。其目的一方面是按照 PDCA（PDCA是计划（Plan）、实施（Do）、检查（Check）、行动（Act）的循环不断的改进过程、优化过程，而更重要的一方面是让团队成员、公司领导和客户树立对本项目的信心，让所有干系人共同推动项目的顺利进行。另外一点要说明的是，质量保证和质量控制是相互迭代的过程，质量保证为成功的进行质量控制进行了保障，而质量控制的结果也成为了质量保证的依据。因此我以质量管理计划、质量测量指标、工作绩效信息和质量控制测量结果为依据，带领项目团队和公司的QA部门，进行了质量审计和过程分析。首先把重点放在团队成员在项目的执行过程中，是否严格按照流程图中的规定执行各个流程。在项目执行的初期，为了引导成员的正确理解和执行，我投入较多的精力放在各阶段固定的检查审计工作中，而随着成员对流程不断熟悉、步入正轨，我把固定检查改为随机抽查的形式，取得了更好的效果。另外我根据质量控制中信息的反馈，发现有些过程的质量测量指标不太稳定，我按照计划-执行-检查-纠偏的顺序提出变更请求，进行过程的改进，最终提高了这些指标的稳定性。

三、控制质量
        项目质量管理过程中，质量控制环节是重中之重，质量控制做得不好，将可能导致不合格产品或服务流出从而影响组织的声誉，带来重大损失。为了做好质量控制，我组织质检人员严格按照验收技术规范和质量核对单，通过抽样检查、过程质量控制图等方式对各阶段输出进行了检验、核对，确保各阶段交付成果满足要求，尽量避免因不合格产品输出导致返修、返工等损失。9月上旬，质检员在对室外监控探头进行检验时发现，监控画面偶尔存在画面抖动、噪点明显等现象，硬件组及时组织进行原因排查，一开始认为是接插件接触不稳定所致，对接插件进行逐一排查加固后，问题仍没有解决。后来，硬件组技术骨干李某提出是不是电磁干扰所致，硬件组立马组织进行周边电磁环境监测发现强度确实超标，于是采取了加强电磁屏蔽和设备接地等措施，最终解决了这一问题。
经过我和我的团队的齐心协力，该项目于2018年12月中旬成功进行了试运行，并于12月下旬顺利通过甲方验收小组的最终验收。自运用该监测系统后，建筑工地周边环境状况得到明显好转，受到甲方及周边居民的一致好评。该项目的最终顺利完成得益于我在项目管理中实施了有效的质量管理，注重质量目标的确定、严格按照公司质量管理体系编写了该项目的质量

结尾略