项目管理 订阅
《项目管理》是2011年1月1日上海交通大学出版社出版的图书,作者是英特尔软件学院教材。 [1] 展开全文
《项目管理》是2011年1月1日上海交通大学出版社出版的图书,作者是英特尔软件学院教材。 [1]
信息
ISBN
9787313068675 [1]
作    者
英特尔软件学院教材 [1]
书    名
项目管理 [1]
出版时间
2011-01-01
出版社
上海交通大学出版社
项目管理内容简介
《项目管理》分9章,分别从项目管理绪论、项目管理过程、项目范围定义与计划、项目进度管理、项目费用管理、项目质量管理、项目团队管理、项目信息管理、项目风险管理几个方面,结合Intel的实际,对项目管理进行了阐述和讲解。全书深入浅出、通俗易懂。 [1-2] 
收起全文
精华内容
下载资源
问答
  • 备战2020软考系统集成项目管理工程师
  • 小任老师帮你梳理软考系统集成项目管理工程师考试重点、难点,19年下半年四个案例题成功预测正确三个题,18年下半年四个案例题成功预测正确三个题,18年上半年四个案例成功预测两题,17年下半年四个案例成功预测两题...
  • 第三版信息系统项目管理师47个过程的输入输出及工具

    一、项目整体管理

    过程名

    输入

    工具和技术

    输出

    1、制定项目章程

     

    1、项目工作说明书

    2、商业论证

    3、协议(合同,备忘录、意向及协议书)

    4、组织过程资产

    5、事业环境因素

    1、专家判断

    2、引导技术

     

    1、项目章程

     

    2、制定项目管理计划

     

    1、  项目章程

    2、  其他规划过程的输出

    3、  组织过程资产

    4、  事业环境因素

    1、 专家判断

    2、  引导技术

    1、项目管理计划

     

    3、指导与管理项目工作

    1、项目管理计划

    2、批准的变更请求

    3、组织过程资产

    4、事业环境因素

     

     

    1、  专家判断

    2、  项目管理信息系统(PMIS)

    3、  会议

    1、  可交付成果

    2、  工作绩效数据

    3、  变更请求

    4、  项目管理计划更新

    5、  项目文件更新

    4、监控项目工作

    1、  项目管理计划

    2、  进度预测

    3、  成本预测

    4、  确认的变更

    5、  工作绩效信息

    6、  组织过程资产

    7、  事业环境因素

     

    1、  分析技术

    2、  项目管理信息系统

    3、  会议

    4、  专家判断

     

    1、  变更请求

    2、  工作绩效报告

    3、  项目管理计划更新

    4、  项目文件更新

    5、实施整体变更控制

    1、  项目管理计划

    2、  工作绩效报告

    3、  变更请求

    4、  组织过程资产

    5、  事业环境因素

    1、  会议

    2、  变更控制工具

    3、  专家判断

    1、  批准的变更请求

    2、  变更日志

    3、  项目管理计划更新

    4、  项目文件更新

    结束项目或阶段

    1、  项目管理计划

    2、  验收的可交付成果

    3、  组织过程资产

    1、  分析技术

    2、  会议

    3、  专家判断

    1、  最终产品、服务或成果

    2、  组织过程资产更新

     

    二、项目范围管理

     

    过程名

    输入

    工具和技术

    输出

    1、编制范围管理计划(规划范围管理)

    1、  项目管理计划

    2、  项目章程

    3、  组织过程资产

    4、  事业环境因素

    1、  会议

    2、  专家判断

    1、范围管理计划

    2、需求管理计划

    2、收集需求

    1、  范围管理计划

    2、  需求管理计划

    3、  干系人管理计划

    4、  项目章程

    5、  干系人登记册

    1、  访谈

    2、  焦点小组

    3、  引导式研讨会

    4、  群体创新技术

    5、  群体决策技术

    6、  问卷调查

    7、  观察

    8、  原型法

    9、  标杆对照

    10、系统交付图

    11、文件分析

    1、需求文件

    2、需求跟踪矩阵

    3、定义范围

    1、  范围管理计划

    2、  项目章程

    3、  需求文件

    4、  组织过程资产

    1、  产品分析

    2、  专家判断

    3、  备选方案生成

    4、  引导式研讨会

    1、  项目范围说明书

    2、  项目文件更新

    4、创建工作分解结构(WBS)

    1、  范围管理计划

    2、  项目范围说明书

    3、  需求文件

    4、  事业环境因素

    5、  组织过程资产

    1、  分解

    2、  专家判断

    1、  范围基准

    2、  项目文件更新

    5、确认范围

    1、  项目管理计划

    2、  需求文件

    3、  需求跟踪矩阵

    4、  核实的可交付成果

    5、  工作绩效数据

    1、  检查

    2、  群体决策技术

    1、  验收的可交付成果

    2、  变更请求

    3、  工作绩效信息

    4、  项目文件更新

    6、范围控制

    1、  项目管理计划

    2、  需求文件

    3、  需求跟踪矩阵

    4、  工作绩效数据

    5、  组织过程资产

    1、偏差分析

    1、工作绩效信息

    2、变更请求

    3、项目文件更新

    4、项目管理计划更新

    5、组织过程资产更新

     

     

     

    三、项目时间管理

     

    过程名

    输入

    工具和技术

    输出

    1、规划进度管理

    1、 项目管理计划

    2、 项目章程

    3、 组织过程资产

    4、 事业环境因素

    1、 专家判断

    2、 分析技术

    3、 会议

    1、 项目进度管理计划

     

    2、定义活动

    1、 进度管理计划

    2、 范围基准

    3、 组织过程资产

    4、 事业环境因素

    1、 分解

    2、 滚动式规划

    3、 专家判断

    1、 活动清单

    2、 活动属性

    3、 里程碑清单

    3、排列活动顺序

    1、 进度管理计划

    2、 活动清单

    3、 活动属性

    4、 里程碑清单

    5、 事业环境因素

    6、 组织过程资产

    7、 项目范围说明书

    1、 前导图法

    2、 箭线图法

    3、 确定信赖关系

    4、 提前量与滞后量

    1、 项目进度网络图

    2、 项目文件更新

    4、估算活动资源

    1、 进度管理计划

    2、 活动清单

    3、 活动属性

    4、 资源日历

    5、 风险登记册

    6、 活动成本估算

    7、 事业环境因素

    8、 组织过程资产

    1、 专家判断

    2、 备选方案分析

    3、 发布的估算数据

    4、 项目管理软件

    5、 自下而上估算

    1、 活动资源需求

    2、 资源分解结构

    3、 项目文件更新

    5、估算活动持续时间

    1、 进度管理计划

    2、 活动清单

    3、 活动属性

    4、 活动资源需求

    5、 资源日历

    6、 项目范围说明书

    7、 风险登记册

    8、 资源分解结构

    9、 事业环境因素

    10、组织过程资产

    1、 专家判断

    2、 类比估算

    3、 参数估算

    4、 三点估算

    5、 群体决策技术

    6、 储备分析

    1、 活动持续时间估算

    2、 项目文件更新

    6、制定进度计划

    1、 进度管理计划

    2、 活动清单

    3、 活动属性

    4、 项目进度网络图

    5、 活动资源需求

    6、 资源日历

    7、 活动持续时间估算

    8、 项目范围说明书

    9、 风险登记册

    10、项目人员分配

    11、资源分解结构

    12、事业环境因素

    13、组织过程资产

    1、 进度网络分析法

    2、 关键路线法

    3、 关键链法

    4、 资源优化技术

    5、 建模技术

    6、 提前量和滞后量

    7、 进度压缩

    8、 进度计划编制工具

    1、 进度基准

    2、 项目进度计划

    3、 进度数据

    4、 项目日历

    5、 项目管理计划更新

    6、 项目文件更新

    7、控制进度

    1、 项目管理计划

    2、 项目进度计划

    3、 工作绩效数据

    4、 项目日历

    5、 进度数据

    6、 组织过程资产

    1、 绩效审查

    2、 项目管理软件

    3、 资源优化技术

    4、 建模技术

    5、 提前量和滞后量

    6、 进度压缩

    7、 进度计划编制工具

    1、 工作绩效信息

    2、 进度预测

    3、 变更请求

    4、 项目管理计划更新

    5、 项目文件更新

    6、 组织过程资产更新

     

     

     

    四、项目成本管理

     

    过程名

    输入

    工具和技术

    输出

    1、制定成本管理计划(规划成本)

    1、 项目管理计划

    2、 项目章程

    3、 事业环境因素

    4、 组织过程资产

    1、 专家判断

    2、 分析技术

    3、 会议

    1、成本管理计划

    2、成本估算

     

    1、 成本管理计划

    2、 人力资源管理计划

    3、 范围基准

    4、 项目进度计划

    5、 风险登记册

    6、 组织过程资产

    7、 事业环境因素

    1、 专家判断

    2、 类比估算

    3、 参数估算

    4、 自下而上估算

    5、 三点估算

    6、 储备分析

    7、 质量成本

    8、 项目管理软件

    9、 卖方投标分析

    10、群体决策技术

    1、 活动成本估算

    2、 估算依据

    3、 项目文件更新

     

    3、成本预算(制定预算)

    1、 成本管理计划

    2、 范围基准

    3、 活动成本估算

    4、 活动依据

    5、 项目进度计划

    6、 资源日历

    7、 风险登记册

    8、 协议

    9、 组织过程资产

    1、 成本汇总

    2、 储备分析

    3、 专家判断

    4、 资金限制平衡

    5、 参数模型

    1、成本基准

    2、项目资金需求

    3、项目文件更新

    4、成本控制

    1、 项目管理计划

    2、 项目资金需求

    3、 工作绩效数据

    4、 组织过程资产

    1、 挣值管理

    2、 预测

    3、 完工尚需绩效指数

    4、 绩效审查

    5、 项目管理软件(PM软件)

    6、 储备分析

    1、 工作绩效信息

    2、 成本预测

    3、 变更请求

    4、 项目文件更新

    5、 组织过程资产更新

    6、 项目管理计划更新

     

     

     

     

    五、项目质量管理

    过程名

    输入

    工具和技术

    输出

    1、规划质量管理

     

    1、 项目管理计划

    2、 干系人登记册

    3、 风险登记册

    4、 需求文件

    5、 事业环境因素

    6、 组织过程资产

    1、 成本效益分析

    2、 质量成本法

    3、 七种基本质量工具

    4、 标杆对照

    5、 实验设计

    6、 统计抽样

    7、 其他质量管理工具

    8、 会议

    1、 质量管理计划

    2、 过程改进计划

    3、 质量测量指标

    4、 质量核对单

    5、 项目文件更新

    2、实施质量保证

    1、 质量管理计划

    2、 过程改进计划

    3、 质量测量指标

    4、 质量控制测量结果

    5、 项目文件

    1、 质量审计

    2、 过程分析

    3、 质量管理与控制工具

    1、 变更请求

    2、 项目管理计划更新

    3、 项目文件更新

    4、 组织过程资产更新

    3、质量控制(控制质量)

    1、 项目管理计划

    2、 质量测量指标

    3、 质量核对单

    4、 单工作绩效数据

    5、 批准的变更请求

    6、 可交付成果

    7、 项目文件

    8、 组织过程资产

    1、 七种基本质量工具

    2、 统计抽样

    3、 检查

    4、 审查已批准的变更请求

    1、 质量控制测量结果

    2、 确认的变更

    3、 核实的可交付成果

    4、 工作绩效信息

    5、 变更请求

    6、 项目文件更新

    7、 项目管理计划更新

    8、 组织过程资产更新

     

     

     

    六、项目人力资源管理

     

    过程名称

    输入

    工具和技术

    输出

    1、编写人力资源计划(规划人力资源管理)

    1、 项目管理计划

    2、 活动资源需求

    3、 事业环境因素

    4、 组织过程资产

    1、 组织结构图和职位描述

    2、 人际交住

    3、 组织理论

    4、 专家判断

    5、 会议

    1、人力资源管理计划

    2、组建项目团队

    1、 人力资源管理计划

    2、 事业环境因素

    3、 组织过程资产

    1、 事先分派

    2、 谈判

    3、 招募

    4、 虚拟团队

    5、 多维决策分析

    1、 项目人员分配表

    2、 资源日历

    3、 项目管理计划更新

    3、建设项目团队

    1、 人力资源计划

    2、 项目人员分配表

    3、 资源日历

    1、 人际关系技能

    2、 培训

    3、 团队建设活动

    4、 基本规则

    5、 集中办公

    6、 认可与奖励

    7、 人事测评工具

    1、 团队绩效评估

    2、 事业环境因素更新

    4、管理项目团队

    1、 人力资源管理计划

    2、 项目人员分配表

    3、 团队绩效评估

    4、 问题日志

    5、 绩效报告

    6、 组织过程资产

    1、 观察和交谈

    2、 项目绩效评估

    3、 冲突管理

    4、 人际关系技能

    1、 变更请求

    2、 项目管理计划更新

    3、 项目文件更新

    4、 事业环境因素更新

    5、 组织过程资产更新

     

     

     

    七、项目沟通管理

     

    过程名称

    输入

    工具和技术

    输出

    1、制订沟通管理计划(规划沟通管理)

    1、 项目管理计划

    2、 干系人登记册

    3、 事业环境因素

    4、 组织过程资产

    1、 分析沟通需求

    2、 信息传递方法的选择

    1、 项目沟通管理计划

    2、 其他文档的更新

    2、管理沟通

     

    1、 项目沟通管理计划

    2、 工作绩效报告

    3、 组织过程资产

    4、 事业环境因素

    1、 沟通渠道的选择

    2、 信息传递方式的选择

    3、 信息管理系统

    4、 绩效报告

    1、 项目沟通

    2、 项目管理计划更新

    3、 其他项目计划更新

    4、 组织过程资产更新

    3、控制沟通

    1、 项目管理计划

    2、 项目沟通

    3、 问题日志

    4、 工作绩效数据

    5、 组织过程资产

    1、 信息管理系统

    2、 专家判断

    3、 会议

     

    1、 工作绩效信息

    2、 变更请求

    3、 项目管理计划更新

    4、 其他项目计划更新

    5、 组织过程资产更新

     

     

     

    八、项目采购管理

     

    过程名称

    输入

    工具和技术

    输出

    1、编制采购计划(规划采购)

    1、 项目管理计划

    2、 需求文档

    3、 风险登记册

    4、 活动资源要求

    5、 项目进度

    6、 活动成本估算

    7、 干系人登记册

    8、 事业环境因素

    9、 组织过程资产

    1、 自制外购分析

    2、 专家判断

    3、 市场调研

    4、 会议

    1、 采购管理计划

    2、 采购工作说明书

    3、 采购文件

    4、 供方选择标准

    5、 自制外购决策

    6、 变更申请

    7、 项目文件更新

    2、实施采购

    1、 采购管理计划

    2、 采购文件

    3、 供方选择标准

    4、 卖方建议书

    5、 项目文件

    6、 自制外购决策

    7、 采购工作说明书

    8、 组织过程资产

    1、 投标人会议

    2、 建议书评价技术

    3、 独立估算

    4、 专家判断

    5、 刊登广告

    6、 分析技术

    7、 采购谈判

    1、 选择的卖方

    2、 合同

    3、 资源日历

    4、 变更请求

    5、 项目管理计划更新

    6、 项目文件更新

    3、控制采购

    1、 项目管理计划

    2、 采购文件

    3、 合同

    4、 批准的变更请求

    5、 工作绩效报告

    6、 工作绩效数据

    1、 合同变更控制系统

    2、 检查与审计

    3、 采购绩效审查

    4、 报告绩效

    5、 支付系统

    6、 索赔管理

    7、 记录管理系统

    1、 工作绩效信息

    2、 变更请求

    3、 项目管理计划更新

    4、 项目文件更新

    5、 组织过程资产更新

    4、结束采购

    1、 合同

    2、 合同收尾程序

    3、 项目管理计划

    4、 采购文件

    1、 采购审计

    2、 采购谈判

    3、 记录管理系统

    1、 合同收尾

    2、 组织过程资产更新

     

     

    九、项目风险管理

     

    过程名称

    输入

    工具和技术

    输出

    1、规划风险管理

    1、 项目管理计划

    2、 项目章程

    3、 干系人登记册

    4、 事业环境因素

    5、 组织过程资产

    1、 分析技术

    2、 专家判断

    3、 会议

    1、风险管理计划

    2、识别风险

    1、 风险管理计划

    2、 成本管理计划

    3、 进度管理计划

    4、 质量管理计划

    5、 人力资源管理计划

    6、 范围基准

    7、 活动成本估算

    8、 活动持续时间估算

    9、 干系人登记册

    10、项目文件

    11、采购文件

    12、事业环境因素

    13、组织过程资产

    1、 文档审查

    2、 信息收集技术

    3、 核对单分析

    4、 假设分析

    5、 图解分析

    6、 SWOT分析

    7、 专家判断

     

    1、 风险登记册

    3、实施定性风险分析

    1、 风险管理计划

    2、 范围基准

    3、 风险登记册

    4、 事业环境因素

    5、 组织过程资产

    1、 风险概率和影响评价

    2、 概率和影响矩阵

    3、 风险数据质量评估

    4、 风险种类

    5、 风险紧急度评估

    6、 专家判断

    1、 风险登记册更新

    2、 假设条件日志更新

    4、实施定量风险分析

    1、 风险管理计划

    2、 成本管理计划

    3、 进度管理计划

    4、 风险登记册

    5、 事业环境因素

    6、 组织过程资产

    1、 数据收集和表示技术

    2、 定量分析和建模技术

    3、 专家判断

    1、项目的概率分布

    2、实现成本和实现目

    标的概率

    3、量化风险优先级清单

    4、定量风险结果的趋势

    5、规划风险应对

    1、 风险管理计划

    2、 风险登记册

    1、 消极风险或威胁的应对策略

    2、 积极风险或机会的应对策略

    3、 应急响应策略

    4、 专家判断

    1、项目管理计划更新

    2、项目文件更新

    6、控制风险

    1、 项目管理计划

    2、 风险登记册

    3、 工作绩效数据

    4、 工作绩效报告

    1、 风险再评估

    2、 风险审计

    3、 偏差和趋势分析

    4、 技术绩效测量

    5、 储备分析。6、会议

    1、 工作绩效信息

    2、 变更请求

    3、 项目管理计划更新

    4、 项目文件更新

    5、 组织过程资产更新

    十、项目干系人管理

    过程名称

    输入

    工具和技术

    输出

    1、识别干系人

     

    1、 项目章程

    2、 采购文件

    3、 事业环境因素

    4、 组织过程资产

    1、 会议

    2、 专家判断

    3、 干系人分析

    1、干系人登记册

    2、编制干系人管理计划(规划干系人)

    1、 项目管理计划

    2、 干系人登记册

    3、 事业环境因素

    4、 组织过程资产

    1、 会议

    2、 专家判断

    3、 分析技术

    1、 干系人管理计划

    2、 项目文件更新

    3、管理干系人参与(管理干系人)

    1、 干系人管理计划

    2、 沟通管理计划

    3、 变更日志

    4、 组织过程资产

    1、 沟通方法

    2、 人际关系技能

    3、 管理技能

    1、 问题日志

    2、 请求变更

    3、 项目管理计划更新

    4、 项目文件更新

    5、 组织过程资产更新

    4、控制干系人参与

    1、 项目管理计划

    2、 问题日志

    3、 工作绩效数据

    4、 项目文件

    1、 信息管理系统

    2、 专家判断

    3、 会议

    1、 工作绩效信息

    2、 纠正措施

    3、 变更请求

    4、 项目管理计划更新

    5、 组织过程资产更新

    6、 项目文件更新

     

    展开全文
  • 本视频教程以新的信息系统项目管理师教程(第三版)为蓝本,结合小任老师多年高校教学经验和软考培训经验录制。参加工作后,我们没有太多的时间投入到信息系统项目管理师的备考中,教程太厚、真题太难,怎样花少的...
  • 项目管理

    万次阅读 2012-07-19 22:07:17
    项目管理包含了许多内容,它是对项目管理专业知识的一个总结,正如法律、医药和会计等其它专业一样,这一知识体系也有赖于那些实践者和学者们对它加以应用和提高。整个项目管理知识体系不仅包括那些已经被求证过的...

    g

    项目管理

    项目管理包含了许多内容,它是对项目管理专业知识的一个总结,正如法律、医药和会计等其它专业一样,这一知识体系也有赖于那些实践者和学者们对它加以应用和提高。整个项目管理知识体系不仅包括那些已经被求证过的理论知识和已经被广 泛加以应用的传统经验,而且还容纳了新的理论知识以及还没有被充分应用的先进经验。

    目录

    1 绪论 7

    1.1 本文的目的 7

    1.2什么是项目 7

    1.2.1时限性 8

    1.2.2产品或服务的唯一性 8

    1.3什么是项目管理 8

    1.3.1项目管理的框架 9

    1.4与其它管理方式的联系 10

    1.5相关的工作 11

    2 项目管理环境 12

    2.1项目的阶段和项目的生命周期 12

    2.1.1项目阶段的特征 12

    2.1.2项目生命周期的特征 12

    2.1.3项目生命周期划分的典型方法 13

    2.2项目涉及人员 15

    2.3组织对项目产生的影响 16

    2.3.1组织系统 17

    2.3.2组织的文化与风格 17

    2.3.3组织结构 17

    2.4全局管理的关键方法 20

    2.4.1指导 21

    2.4.2交流 21

    2.4.3协商 21

    2.4.4解决问题 21

    2.4.5向组织施加影响 22

    2.5社会经济学的影响 22

    2.5.1标准和规定 22

    2.5.2国际化 22

    2.5.3文化影响 22

    3 项目管理程序 22

    3.1项目程序 23

    3.2程序块 23

    3.3程序的相互影响 25

    3.3.1起始程序块 25

    3.3.2计划程序块 25

    3.3.3执行程序块 26

    3.3.4控制程序块 27

    3.3.5结束程序块 28

    3.4按顾客需求制定项目程序 28

    4 项目综合管理 28

    4.1项目计划的开发 29

    4.1.1对项目计划开发的投入 29

    4.1.2为项目计划开发所采用的工具和技术 30

    4.1.3项目计划开发的成果 31

    4.2项目计划的实施 31

    4.2.1对项目计划实施的输入 31

    4.2.2项目计划实施的工具和技术 32

    4.2.3项目计划实施的结果 32

    4.3全程变化控制 32

    4.3.1对全程变化控制的输入 33

    4.3.2为全程变化控制投入的工具和技术 33

    4.3.3从全程变化控制中的输出 34

    5 项目范围管理 34

    5.1启动阶段 36

    5.1.1对启动阶段的投入 36

    5.1.2为启动阶段投入的工具和技术 37

    5.1.3启动后的成果 37

    5.2 范围规划 37

    5.2.1对范围规划的输入 38

    5.2.2为范围规划投入的工具和技术 38

    5.2.3 从范围规划中的产出 38

    5.3范围界定 39

    5.3.1为界定范围投入的工具和技术 39

    5.3.2从范围界定中的输出 40

    5. 4范围核定 42

    5.4.1对范围核定的投入 42

    5.4.2为范围核实投入的工具和技术 43

    5.4.3范围核实的输出 43

    5.5范围变化控制 43

    5.5.1对范围变化控制的输入 43

    5.5.2为范围变化控制准备的工具和技术 43

    5.2.3范围变化控制的输出 44

    6 项目时间管理 44

    6.1定义活动 46

    6.1.1定义活动过程的输入 46

    6.1.2定义活动的工具和方法 46

    6.1.3定义活动过程的输出 46

    6.2活动的排序 46

    6.2.1活动排序过程的输入 47

    6.2.2活动排序的工具和方法 47

    6.2.3活动排序过程的结果 48

    6.3活动时间估计过程 48

    6.3.1活动所需时间估计的输入 49

    6.3.2活动所需时间估计的工具和方法 49

    6.3.3活动所需时间估计的结果 50

    6.4进度编制 50

    6.4.1时间进度编制的输入 50

    6.4.2进度编制的工具和方法 51

    6.5进度控制 53

    6.5.1进度控制的输入 53

    6.5.2进度控制的工具和方法 54

    6.5.3进度控制的结果 54

    7 项目成本管理 54

    7.1资源计划 56

    7.1.1资源计划过程的输入 56

    7.1.2资料计划的工具与方法 56

    7.1.3资源计划过程的输出结果 56

    7.2成本估计 56

    7.2.1成本过程输入 57

    7.2.2成本估计的工具和方法 57

    7.2.3 成本估计的结果 58

    7.3成本预算 58

    7.3.1 成本预算的输入 58

    7.3.2 成本预算的工具和方法 59

    7.3.3 成本预算所得输出结果 59

    7.4 成本控制 59

    7.4.1 成本控制的输出 59

    7.4.2 成本控制的工具和方法 59

    7.4.3 成本控制的输出 59

    8 项目质量管理 60

    8.1质量计划 61

    8.1.1 质量计划的输入 62

    8.1.2质量计划的手段和技巧 62

    8.1.3质量计划中的输出 63

    8.2质量保证 64

    8.2.1质量保证的输入 64

    8.2.2质量保证的手段和技巧 64

    8.2.3质量保证的输出 64

    8.3质量控制 64

    8.3.1质量控制的输入 65

    8.3.2质量控制的手段和技巧 65

    8.3.3质量控制的输出 66

    9 项目人力资源管理 66

    9.1组织规划 67

    9.1.1组织规划的输入 68

    9.1.2管理规划的手段和技巧 69

    9.1.3组织规划的输出 69

    9.2人员组织 70

    9.2.1人员组织的输入 70

    9.2.2人员组织手段和技巧 70

    9.2.3人员组织的输出 71

    9.3团队发展 71

    9.3.1对团队发展的投入 71

    9.3.2团队发展的手段和技巧 71

    9.3.3团队发展的输出 72

    10 沟通管理 72

    10.1沟通计划(communication planning 73

    10.1.1沟通计划输入(inputs to communication planning 74

    10.1.2沟通计划的工具和方法(tools and techniques for communication planning 74

    10.1.3沟通计划的输出 74

    10.2 信息发送(information distribution 75

    10.2.1 信息发送的输入 75

    10.2.2 信息发送的工具和方法 75

    10.2.3 信息发送的输出 75

    10.3执行报告(performance reporting 75

    10.3.1 执行报告的输入 76

    10.3.2执行报告的工具和方法 76

    10.4行政总结(administration closure 77

    10.4.1行政总结的输入 78

    10.4.2行政总结的工具和方法 78

    10.4.3行政总结的输出 78

    11 项目风险管理 78

    11.1风险识别 78

    11.1.1对风险识别的输入 79

    11.1.2工具和方法 80

    11.1.3风险的输出 81

    11.2风险量化 81

    11.2.1对风险量化的输入 82

    11.2.2工具和方法 82

    11.2.3风险量化的产生 84

    11.3风险对策研究 84

    11.3.1对风险对策研究的输入 85

    11.3.2工具和方法 85

    11.3.3风险对策研究的输出 85

    11.4风险对策实施控制 86

    11.4.1对风险对策控制的输入项 86

    11.4.2风险对策实施控制的工具和方法 86

    11.4.3风险对策实施控制输出项 86

    12 项目采购管理 86

    12.1采购计划(procurement planning 87

    12.1.1采购计划的输入(inputs to procurement planning 87

    12.1.2采购计划的工具和方法(tools and techniques for procurement planning 88

    12.1.3 采购计划的输出(outputs from procurement planning 89

    12.2 询价计划(solicitation planning 89

    12.2.1 询价计划输入(input to solicitation planning 90

    12.2.2 询价计划的工具和方法(tools and techniques for solicitation planning 90

    12.2.3 询价计划的输出(outputs from solicitation planning 90

    12.3 询价(solicitation 91

    12.3.1 询价的输入(inputs to solicitation 91

    12.3.2询价的工具和方法(tools and techniques for solicitation 91

    12.3.3 询价的输出(output from solicitation 91

    12.4 渠道选择(source selection 91

    12.4.1 渠道选择的输入(inputs to souse selection 92

    12.4.2 渠道选择的工具和方法(tools and techniques for source selection 92

    12.4.3 渠道选择输出(outputs from source selection 92

    12.5 合同管理(contract administration 93

    12.5.1 合同管理的输入(inputs to contract administration 93

    12.5.2合同管理的工具和方法(tools and techniques for contract administration 93

    12.5.3 合同管理的输出(outputs from contract administration 94

    12.6 合同收尾(contract close-out 94

    12.6.1合同收尾的输入(inputs to contract close-out 94

    12.6.2合同收尾的工具和方法(outputs from contract close-out 94

    12.6.3合同收尾的输出(outputs from contract close-out 94

    第1章 绪论

    项目管理知识体系包含了许多内容,它是对项目管理专业知识的一个总结,正如法律、医药和会计等其它专业一样,这一知识体系也有赖于那些实践者和学者们对它加以应用和提高。整个项目管理知识体系不仅包括那些已经被求证过的理论知识和已经被广泛加以应用的传统经验,而且还容纳了新的理论知识以及还没有被充分应用的先进经验。

    1.1 本文的目的

    本文最根本的目的是要向大家介绍已经被普遍认可、接受的项目管理知识体系的基本内容。"普遍认可"意味着在此所介绍的理论和实践经验在大多数时候对于大多数项目来讲都是适用的,这意味着大家对于这些理认和实践的价值用途已达成了广泛的一致。但是,"普遍认可"并不是说这些理论和实践经验可以或者应该适用于所有的项目。什么是对项目适用的,这应该由项目管理工作组做出决定。

    作者也希望为大家探讨项目管理提供一本专业(术语)的通字典,项目管理是一个相对年轻的专业,因此在各种项目的实际运作中有大量相同类似的工作,但所使用的术语却很少相同。

    本文为任何对项目管理感兴趣的人提供了一个基本的参考,主要适用于:(当然也不局限于此) 

    项目经理和项目组的其他人员

     项目的客户和其他项目涉外人员

     项目经理的主管

     有下属参与项目工作的部门经理

     进行项目管理和相关课程教学工作的教育工作者

     项目管理及相关领域的顾问和专家

     对项目管理人员进行培训的培训师

    由于本文在内容上还不够深刻和广泛,因此仅为大家提供了一个基本的参考。附录E所讨论的是对项目管理应用的扩展,附录F给出了有关项目管理上的进一步的信息采源。

    本文也被项目管理研究院采纳,作为其学科专业发展计划的常用教材,包括:

     项目管理专业人员资格认证

     项目管理教育等级认证

    1.2什么是项目

    需要组织来实施完成的工作。所谓工作通常既包括具体的操作又包括项目本身,虽然,这两者有时候是相重叠的。但具体操作与项目有许多共同特征,比如:

     需要由人来完成

     受到有限资源的限制。

     需要计划、执行、控制。

    具体操作与项目最根本的不同在于具体操作是具有连续性和重复性的,而项目则是有时限性和唯一性的。我们因此可以根据这一显著特征对项目作这样的定义--项目是一项为了创造某一唯一的产品或服务的时限性工作。所谓时限性是指每一个项目都具有明确的开端和明确的结束;所谓唯一是指该项产品或服务与同类产品或服务相比在某些方面具有显著的不同。

    各种层次的组织都可以承担项目工作。这些组织也许只有一个人,也许包含成千上万的人;也许只需要不到100个小时就能完成项目,也许会需要上千万小时。项目有时只涉及一个组织的某一部分,有时则可能需要跨越好几个组织。通常,项目是执行组织商业战略的关键。以下的活动都是一个项目:

     开发一项新的产品或服务

       改变一个组织的结构、人员配置或组织类型

       开发一种全新的或是经修正过的信息系统

       修建一座大楼或一项设施 

       开展一次政治性的活动

       完成一项新的商业手续或程序

    1.2.1时限性

     时限性指每个项目都有明确的开端和结束。当项目的目标都已经达到时,该项目就结束了,或是当我们已经知道,已经可以确定项目的目标不可能达到时,该项目就会被中止了。时限性并不意味着持续的时间短,许多项目会持续好几年。但是,无论如何,一个项目持续的时间是确定的,项目是不具备连续性的。

     另外,由项目所创造的产品或服务通常是不受项目的时限性影响的,大多数项目的实施是为了创造一个具有延续性的成果。例如,一个竖立民族英雄纪念碑的项目就能够影响好几个世纪。

    许多工作在某种意义上说都是有时限性的。因为它们都会在某一点上结束。比如,一个自动化工厂的装配工作会有暂停的时候,这个工厂本身也会有停工的时候,项目与此有根本性的不同,因为项目是在既定目标达到后就结束了,而非项目型的工作会不断的有新的工作目标,需要不断地工作下去。

    项目的这种时限性特征也会在其它方面体现出来:

     机遇或市场行情通常是暂时的--大多数项目都需要在限定的时间框架内创造产品或服务。

     项目工作组,作为一个团队,很少会在项目结束以后继续存在--大多数项目都是由一个工作组来实施完成的,而成立这个工作组的唯一目的也就是完成这个项目,当项目完成以后,这个团体就会被解散,成员也会再被分配到其它的工作当中去。

    1.2.2产品或服务的唯一性

    项目所涉及的某些内容是以前没有被做过的,也就是说这些内容是唯一的。既使一项产品或服务属于某一大类别,它仍然可以被认为是唯一的。比方说,我们修建了成千上万的写字楼,但是每一座独立的建筑都是唯一的--它们分属于不同的业主,作了不同的设计,处于不同的位置,由不同的承包商承建等等。具有重复的要素并不能够改变其整体根本的唯一性,例如:

     一个新开发商业航线的项目可能需要提供大量的模型。 

     一个推广新药的项目可能需要大量药剂用于临床试验。

     一个房地产开发项目包括成百上千的独立单元。

    每个项目的产品都是唯一的,产品或服务的显著特征必定是逐步形成的。在项目的早期阶段,这些显著特征会被大致地作出界定,当项目工作组对产品有了更充分、更全面的认识以后,就会更为明确和细致地确定这些特征。

    应该将产品特征的逐步形成与项目范围正确的界定加以仔细地协调,特别是当项目是根据合同实施的情况下,对这一点要更加注意。当作出正确的界定以后,项目的范围--需要做的工作--既使当产品的特征是逐步形成的,范围也应该保持不变。关于产品界定与项目范围界定两者的关系,我们将在绪论到第5章中进一步地加以讨论。

    以下两个不同应用领域中的案例解释了产品特征的逐步形成过程。

    案例1,一家化学加工工厂往往首先要开始的程序是对工艺流程性质、特点的定义,这些性质、特点将用做设计主要加工环节。这种信息资料是工程设计图的基础,而工程设计图需要明确工厂布局细节、工艺流程以及辅助设备的机械特征。通过所有这些可以使我们完善工程设计草图,这个工程设计草图可以进一步被绘制成与实物等大的建筑工程图。在建造过程中,根据需要在被许可的范围内进行解释和改造。那么,对于以上性质特点的进一步完善要根据以施工现场变化而变化的图纸来得出。在测试和运转中,性质、特点的更进一步完善常常是以最后的操作调试来完成的。 

    案例一个生物制药的研究项目最初被称之为"XYZ临床试验",因为此时的试验次数和每次试验的规模都未确定。随着项目的开始进行,对于这些就有了更为明确的描述:"一阶段试验三次,二阶段试验四次,三阶段试验四次,四阶段试验两次。"为了逐步地确定产品的特性,接下来的工作将全力集中于确定第一阶段试验方案上--对多少病人进行试验,需要多少药量剂,用药的频率应该是多少。在项目的最后,第三阶段试验的内容就可以根据前两阶段收集和整理出来的信息加以明确。

    1.3什么是项目管理

    项目管理就是为了满足甚至超越项目涉及人员对项目的需求和期望而将理论知识、技能、工具和技巧应用到项目的活动中去。要想满足或超过项目涉及人员的需求和期望,我们是需要在下面这些相互间有冲突的要求中寻求平衡:

     范围、时间、成本和质量

     有不同需求和期望的项目涉及人员

     明确表示出来的要求(需求)和未明确表达的要求(期望)

    项目管理有时被描述为对连续性操作进行管理的组织方法。这种方法,更准确地应该被称为由项目实施的管理,这是将连续性操作的许多方面作为项目来对待,以便对其可以采用项目管理的方法。虽然,对于一个通过项目实施管理的组织而言,对项目管理的认识显然是非常重要的,但是如何由项目实施管理这不在本文讨论的范围之内。

    我们可以用许多方式把关于项目管理的理论知识组织起来。在本文中,我们把它分为两大部分,十二章加以阐述。

    1.3.1项目管理的框架

    1部分,项目管理框架,为理解项目管理提供一个基本的结构。

    1章 绪论,对关键术语作出定义并给出全文的梗概。
      第2章 项目管理环境,描述项目实施的环境。项目管理工作组必须了解和认识项目所处的背景、环境--对项目日常活动的管理只是取得成功必要而不充分的条件。
      第3章 项目管理过程,概括地叙述了各项目管理程序通常会产生相互作用、认识和理解这些相互作用,对于理解本文4-12章的内容是非常必要的。

    2部分,项目管理知识体系主体,根据项目管理的构成程序,讲解项目管理的理论和实践知识。这些程序在下文中被划分为九个部分,如图1-1表示。

    4章 项目综合管理,阐述了如何确保对项目的不同构成要素进行正确的协调。它包括了项目开发计划,项目执行计划,全程变化控制。
      第5章 项目范围界定管理,阐述了为了确保成功地完成项目所有需要做的工作,也是仅仅被要求做的工作。这一章包括了项目的启动,范围界定计划书,细分子项目、范围核实和范围变化控制。 
      第6章 项目时间管理,阐述确保按时完成项目的工作程序。它包括活动定义、活动排序、活动的时间估计、进度编制和进度控制。
      第7章 项目成本管理,阐述了如何在法定预算内完成项目,包括资源规划,成本计划、成本预算和成本控制。
      第8章 项目质量管理,阐述了如何确保项目达到既定的要求。包括质量规划,质量保证和质量控制。
      第9章 项目人力资源管理,阐述了如何确保最大限度地调动项目涉及人员的积极性,包括组织规划,人员组织、团队建设。 
      第10章 项目沟通管理,阐述了及时并且准确得到、收集、传送、存储及利用项目信息资源,它包括沟通计划、信息传送、实施情况报告及行政总结。

    1-1项目管理知识体系主体和项目管理过程图

      第11章 项目风险管理,阐述项目风险的确定,分析及对策。包括风险识别,风险量化、风险对策研究和风险对策实施控制。
      第12章 项目采购管理,阐述如何从执行组织外获取物资和服务。包括采购计划、征集申请书计划、征集申请书、货源选择、合同管理和行政收尾。

    1.4与其它管理方式的联系

    项目管理中许多知识都是独一无二的,或者说几乎是独一无二的(如,关键线路分析和工作分层结构)。然而项目管理知识体系与其它管理方式的确有相同之处,如图1-2表示。

    全局管理包括了企业运作的计划、组织、人事安排、实施和过程控制。全局管理还包括诸如计算机程式设计、法律、统计、可行性研究、后勤学及人事管理。项目管理知识体系与全局管理在许多领域是互相交迭的,如组织行为、财务预算、计划方式等不一一列举了。在第二章第4节对全局管理有着更详细的讨论。

    "应用领域"是一系列拥有共同要素的项目的统称。这种共同要素虽然重要但却不一定为所有项目所必需或在所有项目中呈现出来。应用领域常需用以下术语来定义:

     技术因素,如软件开发、制药技术或工程建筑。

     管理因素,如管理层构建或新产品开发决策。

     工业集团,如汽车工业、化学工业和金融服务业等。

    E对项目管理的应用领域作了更为详细的探讨。

    图表1-2 项目管理与其它管理学科的关系

    :该图仅为对象的关系示意图
    重叠部分未按比例制作

    1.5相关的工作

    还有几种与项目相关的工作,这里阐述如下:

    方案:方案是一系列以相互协调方式管理并获得利润的项目的集合,将集合内的项目进行分别管理是得不到我们所说“方案”的。许多方案还包括正在运行的要素。举例如下:

     XYZ飞机方案即包括设计和开发飞机的项目,还包括正在进行的生产制造以及对飞机的支持维护。

     许多电子企业都有经理,他们既负责每一独立产品的市场投放,又要负责众多产品市场投放的总体协调。

    方案可能会包括一系列重复的或周而复始的工作,如:

     公用事业往往会提到每年一度的市政建设方案,而这个规律性强,持续性强的方案包含了许多项目。

     许多非盈利组织都有一个筹款方案,它是一项为了寻求经济支持而进行的持续性工作,常常涉及一系列诸如发展会员或拍卖会这类无关连的许多项目。

     出版发行一种报纸或杂志也是一种方案--它们的定期性本身就是一种持续性的工作,但每一期却是独立的项目。

    在某些应用领域,方案管理与项目管理被视为同义词,而在另一些领域,项目管理被看作是方案管理的子集,在不多的情况下,方案管理被认为是项目管理的子集。这种丰富多变的内涵使任何关于方案管理与项目管理的讨论都必须首先对二者的定义有清晰、固定的共识。

    子项目:项目常常可以被分解为更易管理的单元或子项目,而子项目常常可以由外部企业承包或项目执行组织中的其它职能单位完成,以下是一些子项目的举例:

     一个单个的项目阶段(项目片断的描述见章节2.1

     在建筑项目中的水泵安装或电路铺设。

     一个软件开发项目中的程序自动测试。

     一个药物研究开发项目中提供临床检验用药的批量生产。

    然而,从实施者的角度来看,子项目常常被视做一种服务而非产品,而且这种服务是独一无二的。因此子项目也被认为是项目,并作为项目来进行管理。

    第2章 项目管理环境 

      项目和项目管理是在一个远大于项目本身的环境中实施的,项目管理人员必须明白这个大的环境--项目的日常工作管理对于项目的最终成功是必要而不充分的。本章讲解的是项目管理的几个关键问题(本文的其它部分将不再另述),这一主题包括以下几点内容:

    2.1项目的阶段和项目的生命周期

     因为项目都是些具有唯一性的工作,因此它们包含一定程度的不确定性,组织在实施项目时通常会将每个项目分解为几个项目阶段,以便更好的管理和控制,并且将执行组织正进行的工程与整个项目更好的连接起来。总的来看,项目的各个阶段构成项目的整个生命周期。

    2.1.1项目阶段的特征

     每个项目阶段都以一个或一个以上的工作成果的完成为标志,这种工作成果有形的,可鉴定的。如一份可行性研究报告、一份详尽的设计图或一个工作模型。这些中间过程,以至项目的各阶段都是总体逻辑顺序安排的一部分,制定这种逻辑顺序是为了确保我们能够正确的界定项目的产品。

     一个项目阶段的结束通常以对关键的工作成果和项目实施情况的回顾为标志,作这样的回顾有两个目的:1)决定该项目是否进入下一个阶段;2)尽可能以较小的代价查明和纠正错误。这些阶段末的回顾常被称之为阶段出口,进阶之门或是关键点。

     每个项目阶段通常都规定了一系列工作任务,设定这些工作任务使得管理控制能达到既定的水平。大多数这些工作任务都与主要的阶段工作成果有关,这些阶段通常也根据这些工作任务来命名:识别需求、设计、构建、测试、启动、运转,以及其它恬当的名称。在第2章第1节的第3个总是中我们将讨论几种具有代表性的项目生命周期。

    2.1.2项目生命周期的特征

     项目生命周期确定了项目的开端和结束。例如,当一个组织看到了一次机遇,它通常会做一次可行性研究,以便决定是否应该就此设立一个项目。对项目生命周期的设定会明确这次可行性研究是否应该作为项目的第一个阶段,还是作为一个独立的项目。 

     项目生命周期的设定也决定了在项目结束时应该包括或不包括哪些过渡措施。通过这种方式,我们可以利用项目生命周期设定来将项目和执行组织的连续性操作链接起来。

     大多数项目生命周期确定的阶段的前后顺序通常会涉及到一些技术转移或转让的,比如设计要求、操作安排、生产设计。在下阶段工作开始前,通常需要验收现阶段的工作成果。但是,有时候后继阶段也会在它的前一阶段工作成果通过验收之前就开始了。当然要在由此所引起的风险是在可接受的范围之内时才可以这样做。这种阶段的重叠在实践中常常被叫"快速跟进"。

    项目生命周期通常可以确定:

     每个阶段所需做的技术性工作(如:确定建筑师的工作是不是设计阶段的一部分,或者是执行阶段的一部分)。

     每个阶段所涉及的人(如:实时工程在识别需求和设计中需要涉及实际操作人员)。

    对于项目生命周期的说明可以是非常概括的,也可以非常详细。高度详细的说明可能会包含大量的表、图和清单,以便于确定项目生命周期的结构,并确保其稳定性。这种详细说明的方法常常被叫做项目管理方法学。

    大多数项目生命周期的说明具有以下共同的特点: 

     对成本和工作人员的需求最初比较少,在向后发展过程中需要越来越多,当项目要结束时又会剧烈的减少。

    我们可以从图2-1中看到这一变化。

    2-1生命周期的一般样板

      

     在项目开始时,成功的概率是最低的,而风险和不确定性是最高的。随着项目逐步地向前发展,成功的可能性也越来越高。 

     在项目起始阶段,项目涉及人员的能力对项目产品的最终特征和最终成本的影响力是最大的,随着项目的进行,这种影响力逐渐削弱了。这主要是由于随着项目的逐步发展,投入的成本在不断增加,而出现的错误也不断得以纠正。

    我们要注意区分项目的生命周期和产品的生命周期,比如,一个已经完成的项目将一种新型的台式电脑投放到市场,而这只是产品生命周期的一个阶段而已。

    尽管许多项目生命周期由于包含类似的工作任务而具有类似的阶段名称,但很少含有完全相同的情况,大多数项目被划分为四个至五个阶段,但也有一些全被划分为九个甚至更多的阶段。甚至在同一应用领域中项目阶段的划分都可能会明显不同--某个组织的软件开发的生命周期中也许只有一个设计阶段,而另一个组织则可能会将基本功能设计与细节设计划分为两个不同的阶段。

    项目的子项目可能也会有清晰的生命周期。比如,一家建筑公司承担了一项设计一幢新型写字楼的工作,最初,建筑公司参与了业主描述阶段的工作,在业主的实施阶段建筑公司又协助其进行建筑施工。建筑公司所承担的设计项目从构思到定稿、实施直到结束也有其自己的生命周期,建筑公司甚至可以将对写字楼的设计和对建筑施工的协助视为两个独立的项目,每个项目都具有自己的阶段划分。

    2.1.3项目生命周期划分的典型方法

    我们选择以下项目生命周期的划分方法来解释应用中所采用的方法是有所不同的。这里所给出的案例是具有代表性的,但它们既不是推荐的方法,也不是首选的方法。在每一个案例中,阶段的名称和阶段的主要工作成果是由作者自己确定的。

    防御设备的添加。美国国防部1993年2月修订的第5000.2指令明确了一系列添加防御设备的里程牌事件和阶段划分,如图2-2所示。

     导弹需求的确定--以"方案的研究许可"为结束标志。

     方案探讨和界定--以"方案的演示许可"为结束标志。

     演示和确定效力--以"开发许"为结束标志。

     设计和生产开发--以"生产许可"为结束标志。

     管理与生产开发--与连续性运作和支持重合。

    建筑。莫里斯(Morris)在图2-3中分析了一个建筑项目的生命周期。

     可行性--项目陈述,可行性研究和策略规划及许可在该阶段不需要得出对项目取舍的决定。

     规划和设计--基础设计、成本和进度、合同条款和详细设计。在该阶段末要将主要的合同分包出去。

    图2-3 建筑项目生命周期代表性划分,由莫里斯(Morris)提供

     实施--制造、运输、辅助机件、安装、测试。在该阶段来完成全部安装工作。

     启用和运转--最后测试和维修。在该阶段末全面运行该项设施。

    制药。墨菲在图2-4中解释了在美国开发一种新药品的项目生命周期。

     发现和甄别--包括基础研究和应用研究,确定可以用作预临床试验的药物。

     临床前研制--包括为了确定药物安全性和有效性所作的实验和动物试验及其准备工作,并填写新药调查申请表。

     整理注册--包括Ⅰ、Ⅱ、Ⅲ阶段的临床试验和其准备工作,填写新药申请表。 

     后续工作--包括了由于食品药物管理局对新药申请进行复查所要求做的额外工作。

    软件开发。莫切<Mvench>在图2-5中描绘了一个软件开发的螺旋型模型,在此模型中有四个循环和四个象限。

     构思求证周期--包括商业需求、确定构思求证的目标,进行概念性的系统设计、设计和构造构思、求证,制定可行性测试计划,进行风险分析以及制作与下一周期连接的接口

    图2-4 制药项目的代表性生命周期,由墨菲提供

     第一个编制周期--明确系统要求,明确第一期编制的目标,进行逻辑顺序设计,设计和完成第一期编制、制作系统测试计划,完善第一期编制以及制作与下一周期连接的接口。

     第二个编制周期--明确子系统要求,明确第二期编制的目标,进行具体内容设计、第二期编制,制作系统测试计划,完善第二期编制以及作与下一周期连接的接口。

     最后一个编制周期--满足单元要求,进行最后的设计。完成最后一期编制,执行单元,子系统,系统以及可行性测试。

    2.2项目涉及人员

    项目涉及人员是指那些积极参与该项目工作的个体和组织,或者是那些由于项目的实施或项目的成功其利益会受到正面或反面影响的个体和组织。项目管理工作组必须识别哪些个体和组织是项目的涉及人员,确定他们的需求和期望,然后设法满足和影响这些需求、期望以确保项目能够成功。对项目涉及人员的识别通常是非常困难的。比如,一个设计新产品的项目可能会影响一个装配线上的工人将来的就业,那么他是不是项目涉及人员呢? 

    每个项目的主要涉及人员有:

     项目经理--负责管理项目的个人。

     顾客--使用项目产品的个人或组织。对一个项目而言,可能会有多个层次顾客户。比如,一种新药的顾客包括了开出药方的医生、使用该药的病人以及为其承保的保险商。

     执行组织--指雇员直接从事该项目工作的企业。

     发起者--在执行组织中为该项目提供现金或其它财政支持的个人或团体。

    除此之外,还有许多不同称谓,不同类别的项目涉及人员--项目内部的和项目外部的,项目所有人和投资者,供应商和承包商,工作组成员及其家属,政府机构、媒介、个体公民、临时的或固定的疏通组织,乃至于整个社会,通过对项目涉及人员命名和分组,我们可以确认哪些个人和组织将自己视为项目涉及人员。当一家工程设计公司为其正在设计的二个工厂提了资金帮助时,作为项目涉及者,这家公司的职能就有相互重合的地方。 

    图2-5具有代表性的软件开发生命周期,由莫切提供

    想要完全满足项目涉及人员的期望可能是非常困难的,因为众多项目涉及人员的期望可能有所不同,有时甚至可能会相互冲突,比如:

     一个部门的主管可能希望新的管理信息系统运行成本低,系统的建筑师却更注重技术的完善,而项目承包商更感兴趣的可能是如何获得尽可能大的利益。

     在一家电子产品公司中,主管开发的副总裁以产品的设计工艺来判定产品的成功与否,主管生产的副总裁则以一流的生产操作判定新产品的成功与否,为主管市场的副总裁则更多的考虑的是产品新特征的数量,以此来定义产品的成功与否。

     一个房地产开发项目的业主关心的是要按时完工,地方政府则希望尽量得到更多的税收,环境保护组织要求尽可能减少对环境的负面影响,而附近的居民也许希望将该项目另迁别处。
    总的来说,要解决项目涉及人员目标的分歧还是要以顾客的期望为准。但是,这并不是意味着我们可以忽略其他项目涉及人员的要求与期望。

    对于项目管理而言,寻求一种适当的方式解决这些冲突是一项重大的挑战。

    2.3组织对项目产生的影响

      组织通常比项目本身更为庞大--公司、政府机构、卫生医疗机构、跨国集团、专业团体及其它。项目通常只是组织的一部分,有时甚至当一个项目本身就是一个组织(合资合作)时,项目仍然会受到设立该项目的一个或多个组织的影响,下面的这一部分内容阐述了这些比项目更大的组织结构中可能会对项目产生影响的关键因素。 

    2.3.1组织系统

     以项目为基础的组织是通过项目来实现运作的,这些组织可以分为两个大类:

      通过为其它组织承担项目来获取收入的组织--建筑设计公司、工程设计公司、咨询机构、建筑施工单位、政府分包商等。

     通过项目实施管理的组织(见第1章第3节)

    这些组织都偏向于建立一个便于项目管理的管理系统。比如:专门设计了能对多个项目同时进行核算、跟踪、汇报的财务系统。

    不以项目为基础的组织--生产企业、金融服务公司等--很少会设计出能够高效满足项目需求的管理系统,缺乏这种以项目为导向的系统常常会使项目管理的难度加大。某些情况下,不以项目为基础的组织会设立一些部门或其它的子单位,这些部门和子单位可以象那些以项目为基础的单位一样,采用相应的管理系统进行动作。

    项目工作组应该非常准确地知道组织系统是怎样影响项目的。比如,如果部门经理们会因为能调动员工按时完成项目而受到组织的嘉奖,那么项目管理工作组就需要监督参与项目工作的员工要高效工作。

    2.3.2组织的文化与风格

     多数的组织都已经形成了自己独特的,可描述的组织文化。这种文化在许多方面有所反映。比如在组织的价值观、行为准则、信仰、期望上;在组织的政策、程序上;在对上下级关系的观点上以及其它方面上,组织文化常常会对项目产生直接的影响。比如: 

      在一个开拓型的组织中,工作组所提出的非常规性的或高风险性的建议更容易被采纳。

     在一个等级制度严格的组织中,一个高度民主的项目经理可能容易遇到麻烦,而在一个很民主的组织中,一个注重等级的项目经理同样也会受到挑战。

    2.3.3组织结构

    执行组织的结构会对取得项目资项源的可能性有所限制,组织的结构类型从职能型到项目型跨度很大,在这两者之间,还有好几种矩阵型,在图2-6解释了几种主要的企业组织结构中与项目相关的关键特征。"项目组织"将在第9章第1节的"管理规划"中进行讨论。 

    图2-7所表示的是传统的职能型组织,这种组织具有明确的等级划分,每一个雇员都有一个明确的上级。员工高度地依各人专长进行组合,比如生产、市场、工程、会计。而工程又可能进一步细分机械和电气。职能型组织也有项目,但各部门对项目的研究范围被局限于部门的职能界限内:一个职能型组织中,工程部的工作是独立于生产部,市场部之外的。比如,当一个纯粹的职能型组织准备开发一项新产品时,设计阶段会被称为"设计项目",仅仅由工程部人员来完成,如果一旦涉及到生产方面的问题,这些问题将会被逐级地汇报到部门主管处,再由他向生产部主管咨询,然后通知工程部主管,再由工程部主管解决问题的方法逐级向下传递到项目负责人。

    图2-6组织结构对项目的影响

    图2-7职能型组织 

     

    图2-8项目型组织 

     

    与职能型相对应的另一极端是项目型组织。如图2-8所示。在一个项目型组织中,工作成员是经过搭配的。项目工作会运用到大部分的组织资源,而项目经理也有高度独立性,享有高度的权力。项目型组织中也会设立一些组织单位,这些单位也称作部门,但是这些工作组不仅要直接向某一项目经理汇报工作,还要为各个不同的项目提供服务。

    图2-9到2-11表示的是矩阵型的组织,这种组织是职能型和项目型的混合体,既具有职能型组织的特征又具项目型组织的特征。弱矩阵型保持了较多的职能型组织特征,项目负责人扮演的是协调者、协助者的角色,还算不上是一个项目经理。同样也是矩阵型,强矩阵型则具备较多的项目型组织的特征--有专职的收力很大的项目经理,有专职的项目行政管理人员。

    更为现代化的组织则不同的程度地包括以上各种组织类型的结构特点,如图2-12所示。比如,一个基本上是职能型的组织设立了专门的项目工作组去完成一个重要的项目,这个工作组具有项目型组织中项目组的许多特征:有独立于职能部门的专职项目工作人员;有自己的一套工作程序;可以在组织常规的标准、正式报告架构之外进行运作。

    图2-9弱矩阵型组织

    图2-10平衡型矩阵组织

    图2-11 强矩阵型组织

    图2-12 复合型组织


    (黑色方块表示职员参与项目活动) 项目协调

    2.4全局管理的关键方法

    全局管理涵盖面非常广泛,全局管理要处理一个连续运转企业在管理中方方面面的问题,它包括:

     财务和会计,推销和市场、研究和开发、生产和分配。

     战略性计划、战术性计划、操作性计划。

     组织结构、组织行为、人事管理、补助方式、利益分配、晋升方式。

     通过鼓励、授权、监督、团队建设、冲突管理及其它技巧处理好工作关系。

     通过个人时间管理,压力管理和其它方法实现个人管理。

    全局管理方法为项目管理奠定了基础,对项目经理而言是必须了解和掌握的,在任何一个项目中都可能要求运用一定的全局管理方法。本节要阐述的是那些很可能会对大数项目产生影响的全局管理方法。在本文的其它章节不会对此再作阐述了。

    也有许多全局管理的方法仅仅与某一类项目或某一些应用领域有关系。比如,工作成员的人身安全在所有建筑都是至关重要的,而在大多软件开发项目中就没有那么重要了。 

    2.4.1指导

     科特(KOLER)区分了指导和管理,并且强调这两者对项目而言都是不可或缺的:缺少两者中的任何一个都很能会产生不良的结果,他指出管理从根本上而言关注的是"稳定地得到项目涉及人员所期望的主要成果",而指导涉及的则是:

      确定方向--规划出对未来的构想及发展战略以便能实现这一构想。

     明确表达--实现这一构想需要很多人的协助,那么就有必要通过语言或行动让所有这些人明白这一构想。

     激发和鼓励--激励大家去努力克服在变革过程中可能会遇到的政策上的、官僚主义的,资源上的种种障碍。

     在一个项目中,尤其是在一个大的项目中,项目经理通常也被期望成为项目的指导者。但是,并非只有项目经理可以对项目进行指导,项目中众多不同的个体在各个不同的时间都有可能对项目进行指导。项目的各个层次上都需要有指导(项目指导、技术指导、团队指导)。

    2.4.2交流

     交流涉及信息的传递,信息发出者要确保信息是清晰明确,不含糊的,而且是完整的,这样才能有利于信息接收者准确接收,信息接收者则要确保接收的完整性,并且要正确地加以理解。交流是多元化的: 

     书面的和口头的,听和说。

     内部的(项目的)和外部的(与顾客、媒介、公众等)。

     正式的(报告、摘要等)和非正式的(备忘录、非正式会谈等)

     纵向的(组织上下级)和横向的(与同级同事)。

    全局管理的交流方法与项目交流管理(见第10章)有一定联系,但并不完全相同,交流本身是一门更为广博的学问,包含了丰富的知识,并不仅仅体现在项目中,如:

     发出者-接收者模式--反馈回路、沟通障碍等。

     媒介选择--何时采用书面形式、有时采用口头形式、有时采用非正式的书面备忘形式,何时采用正式的书面报告形式等。

     书写风格--主动语态、被动语态、名子结构、用词选择等。

     表达方法--形体语言、辅助的形象化设计等。

     达标管理技巧--日程安排、冲突处理等。

    项目交流管理就是将这些广义的概念运用到具体的项目需求中去,比如,决定在何时以何种形式向谁怎样汇报项目的实施情况。

    2.4.3协商

    协商是指与他人交换意见以便得出结论或达成共识,为了达成共识可能需要进行直接的协商或者通过一些辅助手段进行协商,调解和仲裁就是协商的两种辅助手段。

    项目在许多层次、许多观点上会有多次的协商,在一种典型项目的进行过程中,项目工作人员需要就以下全部或部分内容进行协商: 

     范围、成本和进度目标

     范围、成本或进度的变动

     合同条款

     任务分配

     资源

    2.4.4解决问题

     解决问题包括明确问题和制定解决方案两方面的组合。它所关注的是那些已经出现的问题。(与风险管理相反,风险管理涉及的是潜在的问题)

     明确问题要求将原因和现象进行区分,问题可能出自于内部(一个主要成员被分配到别的项目上去了),也可能来源于外部(开始工作所需得到的许可延迟了)。问题可能出在技术上(对产品设计的最佳方案有不同的观点),也可能出在管理上(一个职能部门没有按计划完成工作)或是出在内部内员(个性或办事风格有冲突)

     制定解决方案包括分析总是以便寻求可行的解决办法,以及从中作出选择。我们可以制定解决方案,我们也以从顾客、工作组或是某一部门主管那儿寻求解决方案,一旦明确了解决方案,就必须实行,解决方案是具有时间性的,--如果解决方案制定得太早或太晚,那么既使是正确的解决方案也不一定是最好的解决方案。

    2.4.5向组织施加影响

     向组织施加影响是一种"成事"的能力,这要求要了解所有项目涉及组织的正式及非正式的结构--执行组织、顾客、承包商和多的其它组织。向组织施加影响也需要了解运用势力和政治策略的一些技巧。

     在这里指的是要从积极的角度运用势力和政治策略,彼弗(PTEFFER)是这样定义势力的"一种潜在的能力,可以影响行为,改变事情的发展,可以克服阻力,还可以让人们去做他们本不愿做的事情",艾克(Eccles)也这样定义了政治"政治是要让一群可能有完全不同的利益的人产共同参与的行动,政治就是创造性的利用冲突和无序"。当然,它也有消极的一面,试图协调各种利益冲突的努力有可能导致权力之争以及组织游戏,这时会使得他们自己毫无工作效率。

    2.5社会经济学的影响

      和全局管理一样,社会经济学的影响包括一系列广泛的论题。项目管理工作组必须了解社会经济的现状和发展趋势,可能会对他们的项目产生重要的影响:社会经济中一个很小的变化在经过一段时滞以后都有可能会造成项目的重大变化,我们在许多潜在的社会经济影响中选择介绍几类经常影响项目的因素。

    2.5.1标准和规定

     国际标准认证组织区别了标准和规定:

       一项标准是一份经认证组织认证过的文本,它为产品、(生产)过程或服务预定了规则、指导或特征,这些标准具有通用性,可以反复使用。是否采纳标准是不具强制性的,从有压液体的热稳定性到计算机磁盘的尺寸,各种东西都有大量在用的标准。

     一项规定是一份对产品,过程或服务特征的计划文件,包括了适当的行政条例,要按规定行事,这是具有强制性。建筑尺码就是一种规定的例子。

    由于标准和规定有很多相互交迭之处,因此我们在讨论这两者时必须加以注意,比如:

     标准作为一种指导,说明了优先的方法和后继的方法,当它被广泛采纳时就成为了一种事实上的规定(如,对大多建筑项目进度安排使用了关键线路法)。

     标准和规定不同层次都具有强制性(如:通过政府机构要求强制执行,通过执行组织的管理强制执行,或者通过项目管理工作组强制执行)。

     对许多项目而言,对有关标准和规定(无论是如何定义的)的充分了解会在项目结果中体现出来,也有一些情况下,这种影响是看不见的或是不确定的,这必须在项目风险管理中加意注意。

    2.5.2国际化

    由于越来越多的组织从事的工作跨越了国界,因此越来越多的项目也是跨越国界的。除了对项目范围、成本、时间和质量的传统考虑外,项目工作组也必须考虑时区不同的影响、国家和民族的节日,为了面谈所需的旅行需要,电话会谈的服务工作及易变的政治分歧。

    2.5.3文化影响

     文化是"大众行为模式、艺术、信仰、风俗习惯及其它人类工作和思想成果的总称",每个项目都是在一种或多种文化形式的背景下运行的,文化影响的领域包括政治、经济、人口统计、教育、道德、种族、家教以及习题、信仰和态度,这一切影响着个人及组织相互作用的方式。

    第3章 项目管理程序 

    项目管理是一种综合性的工作--在某一工作区域内采取行动或不采取行动都会对另一个工作区域产生影响。这种内在的相互作用可能是很明确的,可以把握的,也可能是不确定的、难以把握的。比如,项目范围的变动几乎总是会影响项目的成本,但是这是否会影响工作组的士气决心或者产品的质量就不一定了。

    由于存在这种内在的相互作用所以需要我们对各种项目目标进行权衡--在一个工作区域加强工作力度就可能需要减少在另一个工作区域的工作力度,成功的项目管理要求能有效的控制这些内在的相互作用。

    为了帮助大家理解项目管理的综合性,以及强调这种综合的重要性,本文就项目程序的构成及其它们的相互作用作了阐述,本章把项目管理分解为许多相互连接的程序,为大家理解4-12章有关程序的理论提供了必要的基础,本章的内容包括:

    3.1项目程序

    项目由一个一个的程序组成,一个程序是"为实现某一个结果的一系列行动",项目的程序是由人来完成的并且大致可以分为两类:

     项目管理程序注重对项目工作进行描述和组织。项目管理的程序在大多数时候对多数项目都是适用的,本章对此只作了简要的阐述,我们将在4-12章中再作进一步讨论。

     产品导向型程序注重对项目产品进行具体说明并进行制造。产品导向型程序常常是通过项目生命周期来进行定义(见第2章第1节),并且在不同的应用领域会有所不同(见附录F)。

    项目管理程序和产品导向型程序在整个项目中会相互迭用、相互作用。比如,如果缺乏对如何制造产品的基本了解,我们就无法确定项目的范围。

    3.2程序块

    项目管理程序可以被分为五块,每块有一个或多个程序组成:

     起始程序块--确定一个项目或一个阶段可以开始了,并要求着手实行。

     计划程序块--进行计划并且保持一份可操作的进度安排,确保实现项目的既定商业目标。

     执行程序块--协调人力和其它资源,执行计划。

     控制程序块--通过监督和检测过程确保项目达到目标,必要时采取一些修正措施。

     结束程序块--取得项目或阶段的正式认可并且有序地结束该项目或阶段。

    程序块通过各程序块的结果进行连接--个程序块的结果或输出是另一个程序块的输入。在核心程序块间,程序块反复进行连接--计划在开始时为执行提供了一份书面的项目计划,随后又给项目计划提供一份更新的书面文件,以示项目的进程。图3-1表示了这种联系,另外,项目管理程序块不是相互分立的、一次性的事件;在整个项目的每一个阶段它们都会不同程度的相互交迭,图3-2表示了程序块是如何交迭的,在一个阶段内这种交迭会怎样变化。

     

    项目管理程序 最后,程序块的相互作用也会跨越阶段;一个阶段的结束作为下一个阶段开始的输入。比如,结束一个设计阶段要求顾客接受认可设计文稿。类似的,设计文稿为实施阶段提供了产品说明。这种内部作用如图3-3所示。

    在每一个阶段开始时重复起始程序确保项目不会偏离既定的商业要求,也帮助确保当商业要求已不存在或项目已不可能满足这种要求时中止这一项目。在第5章第1节"起始"部分会进一步详细讨论商业要求。



      尽管图3-3表示的是分立的阶段和分立的程序块,但在实际项目中它们可能会有相互交迭。比如,计划程序不仅为成功地完成项目提供了本阶段所需做的工作的细节,并且可能为下一个阶段所需做的工作提供前期的说明。这种项目计划的推进式细节说明常常被称为"滚动计划"。

    3.3程序的相互影响

    在每一个程序块中,各个程序通过它们的输入、输出进行连接。如果将注意力集中于这些连接上,我们可以这样描述程序:

     输入--书面文件或书面表述的工作,下达开始工作的指令。

     工具和技巧--运用各种输入得到输出。

     输出--书面文件或书面表述的工作,它们是每个程序结束后得出的结果。

    在下文我们列出了对于大多数应用领域中的大多数项目都普遍适用的项目管理程序,在4-12章我们会详细讲解。程序名后括弧中的数字指明了在哪一章节会作进一步阐述。在这里阐述的程序内部的相互作用同样也是对大多数应用领域的大多数项目适用的。在第3章第4节我们讨论按顾客要求确定有关程序说明和相互作用的问题。

    3.3.1起始程序块

    图3-4表示了在这一程序块中单个的一个程序。

     起始(5.1)--指示组织开始项目下一个阶段的工作。

    3.3.2计划程序块

    计划对于一个项目是非常重要的,因为项目涉及许多以前从末做过的工作,因此在这一部分有相对较多的程序。但是,程序的数量并不代表计划是项目管理中最主要的部分--计划的工作量应与项目的范围和还有信息的实用性相匹配。

    图3-5表示了项目计划程序块中程序的相互关系(这是图3-1中椭圆形"计划程序块"的扩充)。这些程序是在计划完成之前反复运作的程序标题。比如,如果开始设定的完成日期是不能被接受的,那么项目资源、成本,或者甚至是范围都可能需要重新制定。另外,计划并不是一门精确的科学--两个不同的工作组可能会为同一个项目制定出区别很大的计划。 

    核心程序 一些计划程序间有很明确的关联性,这使得它们在多数项目中需要按相同的次序来实施,比如,在对活动进行进度安排和成本核算前首先需要对活动本身进行界定。这些核心计划程序可能会在一个项目的任何一个阶段,被反复实施好几次。核心计划程序包括:

     范围计划(5.2)--制定一份书面的范围表述,作为将来需要作项目决定时的基础。

     范围界定(5.2)--将主要的项目工作步骤细分为更小、更易管理的构成单元。

     活动定义(6.1)--确认具体的活动,这些活动的实施对于完成项目各阶段的工作成果是必须的。

     活动顺序安排(6.2)--明确并用书面形式表述活动内部的关联性。

     活动持续时间估计--估计为完成各个活动所需的工作时间。

     进度安排(6.4)--分析活动顺序、活动持续时间和资源需求,制定项目进度。

     资源规划(7.1)--确定实施项目活动所需的资源(人力、装备、原料)及相应的数量。

     成本估计(7.2)--估计实施项目活动所需的资源成本。

     成本预算(7.3)--将总体成本估计分配到各项工作上。

     项目计划研究(4.1)--将其它计划程序的结果纳入到一份稳定、连贯的文件中。

    辅助程序 在其它的项目计划程序中的内部相互关系比核心过程更有赖于项目的性质。比如,有一些项目几乎没有或没有可识别的风险,一直到大部分的计划已经被实施且工作组认识到成本和进度安排受到了严重的挑战时才出现很大的风险,尽管在项目计划期间,这些辅助程序断断续续地按需要被实施,但它们不是可以自由选择的。辅助程序包括:

     质量规划(8.1--明确哪一些质量标准是与本项目相关的,决定怎样去满足这些标准。

     管理规划(9.1--确定、记录并分配项目职责和报告关系。

     人员组织(9.2--组织项目工作所需的人力资源。

     沟通规划(10.1--识别项目涉及人员所需的信息和沟通需求。谁需要什么信息、何时需要、以及怎样传递给他们。 

     风险认别(11.1--识别可能会影响项目的风险,并且说明每种风险的特征。

     风险量化(11.2--进行风险评估,并且分析风险间的相互作用,确定一系列可能的项目结果。

     风险对策研究(11.3--确定进行机会选择和危险应对的步骤。

     采购计划(12.1--确定购买什么,何 购买。

     征集申请书计划(12.2--以书面形式表述产品需求和识别潜在的来源。

    3.3.3执行程序块

    和第3章第2节的第2部分中的计划程序块一样,执行程序程块也包括核心程序和辅助程序。图3-6表示了下列程序是如何相互作用的:

     项目计划的执行(4.2--通过实施计划内的活动来执行计划。

     范围核实(5.4--项目范围的正式验收。

     质量保证(8.2--有规律的对所有项目工作进行评估,确保项目达到相关的质量标准。

     团队建设(9.3--开发个人及团队的工作技能,以便提高实施项目工作的水平。

     信息传递(10.2--定期向项目涉及人员传递他们所需的信息。

     征集申请书(12.3--求征适当的报价。

     货源选择(12.4--从潜在的卖方中进行选择。

     合同管理(12.5--处理与卖方的关系。 

     

    3.3.4控制程序块

    必需有规律的评测项目工作,以便知道实施情况与计划间存在的差异。各工作区域中存在的差异都被纳入控制程序块中,一旦发现出现了重大差异(如对项目目标构成威胁的差异)就需要重新正确实施计划程序,对计划加以调整。比如,一项活动延误了,就需要根据所延误的时间,或根据对成本预算及进度安排权衡并调整目前的人员规划。控制也包括对可能发生的问题预先采取防范措施。控制程序块同样也包括核心程序和辅助程序,图3-7表示以下程序的相互作用:

     全程变化控制(4.3)--协调整个项目中出现的变化。

     范围变化控制(5.5)--控制对项目范围的改变。

     进程控制(6.5)--控制对项目进程的改变。

     成本控制(7.4)--控制对成本预算的改变。

     质量控制(8.3)--监测具体项目结果,判断它们是否达到了相关的质量标准,确定消除导致不满意实施状况的成因的方法。

     实施情况报告(10.3)--收集和发送实施情况的信息,包括情形报告、进程检测及预测。

     风险对策实施控制(11.4)--在项目进行中对风险进行应变。

    3.3.5结束程序块

    3-8表示了以下程序的相互作用:

       行政收尾(10.4--产出、收集、发放阶段或项目正式结束的信息。

       合同收尾(12.6--合同完成,及对赊销的清偿。

    3.4按顾客需求制定项目程序

    在第3章中确定的程序及图示的内部相互关系满足了总体可行性检测的需要--它们在大多数时候对大多数项目适用,但是并不是所有项目都需要有这些所有的程序,也并不是所有的内部相互关系都适用所有的项目。比如:

     一个大量使用分包商的组织会在项目计划程序中,对每一次采购程序都加以明确的说明。

     缺少某一个程序并不意味着这个程序不应该被实施。项目管理工作组应该确认并且管理所有确保项目成功的程序。

     依赖于某种独一无二的资源的项目(商业软件开发)可能会在范围界定之前先确定工作人员及职责,因为所能获得的人才决定了所能进行的工作。

     有些程序输出可能预先确定控制的因素。如管理需要确定一个目标完成期限,而不是任由进程计划决定。

     较大型项目相对需要更多细节。如风险识别就需要分别对风险成本、计划风险、技术风险以及质量风险等进行细致分析。

     对干一些子项目和小项目来说,则不需付出太多努力在已经被限定于项目水平上的程序(如:谈判小组的成员就可以忽略谈判小组组长所承担的风险)或提供不重要功能的程序(如四人的项目就不必制定正规沟通计划了)。

    当需要变化时,则变化应清晰界定,仔细权衡和极积应对。

    4章 项目综合管理

    项目综合管理包括的这些程序要求确保对项目的各种要素进行正确的协调。为满足或超越项目参与者的需要和原望,它包括在相互冲突的目标和众多的任选目标中权衡得失。虽然所有的项目管理程序在某种程度上看都是一个整体,但本章所描述的这些程序是最基本的综合管理知识。图表4-1对下列主要程序进行了总述:

    这些程序彼此相互影响,同其他知识领域中的程序也互相影响。根据项目计划的需要,每个程序都包括一个或多个个体或团体的努力。在每个项目阶段,每个程序通常至少发生一次。虽然这里提到的这些程序,是作为彼此独立的因素而给予较好的界定,但是,在实践中它们是以某种方式重迭和影响的,在此就不详细讨论了。程序的互相影响在第3章进行了详细的讨论。

    这章的核心是分析用于项目综合管理过程的程序、工具和技术。例如:当为了一个临时性的计划进行的成本估算或各种人员调整带来的风险被基本确认后,项目综合管理方可进入实施状态。然而,为了能成功地完成一个项目,综合管理也会同其他领域发生一定数量的联系。例如: 

     项目的具体工作必须要同项目执行组织正在进行的具体操作结合起来。

     产品范围和项目范围必须结合起来(产品范围和项目范围是不同的,这些内容的介绍在第5章)。

     项目工作必须与不同特殊功能的子项目相结合(象工程设计项目中的工民建、电力工程和机械图纸一样)。

    4.1项目计划的开发

    项目计划的开发

    项目计划的开发是用其他计划程序的输出,创建一个内容充实、结构紧凑的文件,使它能够引导项目计划的实施和控制。这个过程几乎经常重复几次。

    例如:最初的草案可能包括一般性的方法并没有时间期限,而最终计划则要反映具体的方法和有明确的时间期限。这个项目计划用于: 

     引导项目的实施。

     编制项目规划的设想。

     记录项目计划讨论好的有关任选事宜。

     促进项目参与者之间的沟通。

     确定主要的管理问题如内容、范围和时间等。

     为进一步提高测量和控制项目的水平提供一个标准。

    4.1.1对项目计划开发的投入

       1. 其他规划的输出。其他项目规划程序在3.3中概括,这些项目规划程序的所有输出是开发这项计划的输入。其他规划的输出包括两个基本文件,即工作分析结构和辅助说明。许多项目也要求应用专门领域的输入(例如:许多建筑项目要求有资金流程预测)。

       2. 历史资料。可行性的历史资料(比如;估算记录、过去项目执行情况记录)在其他项目规划程序的制定中已经考虑到了。在项目计划的开发期间,这些资料也有参考价值,它能帮助人们证实假设的真实性和评价任意一个在项目进程中,已得到确认的资料。

       3. 组织管理政策。所有的组织包括项目管理组织在内,可能都有正式的或非正式的政策,在计划时必须考虑到它们的影响。要考虑的组织管理政策通常包括以下内容,但并不局限于此:

     质量管理--通过审计,继续改进目标。

     人事管理--雇佣和解雇标准,雇员执行任务的情况分析。

     财务监控--时间报告、要求的经费和支出情况分析、会计帐目和标准合同条款。

     4. 制约因素。制约因素是限制项目管理团队运行的因素。例如:预先确定预算被认为是影响项目团队对范围、职员人数和日程表选择的极其重要的因素。当一个项目按照合同执行时,合同条款通常是受合同制约的。

     5. 假设。为了项目规划目标的准确性,考虑到的假设因素必须有科学性、真实性和肯定性。例如,如果一个项目不能确定关键人物的到场日期,那么,项目团队可以假设一个具体的开始时间。假设通常保含着一定程度的风险。

    4.1.2为项目计划开发所采用的工具和技术

     1. 项目规划方法。在项目计划开发期间,项目规划方法是用于引导项目团队工作的一种结构分析方法。它可能是越来越简单的标准形式和图纸(不是信件就是电文,正式的或非正式的形式)或者是越来越复杂的一系列模型(比如:蒙特洛的风险分析一表)。多数项目规划方法都将项目管理的软件这种"刚性"手段和易召集的会议这种"柔性"手段结合在一起使用。

     2. 参与者的技能和知识。每个参与者所拥有的技能和知识,在项目计划开发中都能得到充分的利用。项目团队必须营造一个让参与者发挥自己才干的适当环境(看第9章第3节,团队建设)。谁奉献?他们奉献些什么?什么时候改变。例如: 

     对于按照大量的合同进行运作的建筑项目来说,专业成本工程师对制定有利的项目目标,在目标准备阶段的合同金额决定时起着主要作用。

     对一个已事先确定了人员结构的项目来说,每个参加者为制定满意的成本和进度目标,通过回顾期限和理智的估算都能做出有益的贡献。

     3. 项目管理信息系统(PMIS)。项目管理信息系统是由用于归纳、综合和传播其他项目管理程序输出的工具和技术组成。它用于提供从项目开始到项目最终完成,包括人工系统和自动系统的所有信息。

    4.1.3项目计划开发的成果

    1. 项目计划,项目计划是正式被批准的用于管理和控制项目实施的文件。它的作用在沟通管理计划中作了界定(比如:执行组织的管理,可能不要求提供详情,而承包商则要求每个问题要提供全部细节)。在一些应用领域,综合项目计划是归在这个文件中的。

    应该搞清楚项目计划和项目执行情况测量基准是有明显区别的。项目计划是一个文件或文件的汇集,当得到有关项目的进一步的信息后,它会被改动。项目绩效测量基准代表了一种管理控制,这个管理控制通常只会周期性地变化,而且通常只要对通过的范围变化作出相应的反应。

    有许多方法可以用于组织和表示项目计划,但是它的共同特征包括在以下几方面(这些项目工作在其他章节阐述的更多一些):

     项目证书。

     项目管理方法或战略的阐述(在其他章节对个人管理计划进行了总述)。

     范围阐述,包括工作细目和项目目标。

     工作分析结构(WBS),是把项目工作分解到控制系统可以操作的程度。

     成本估算、进度计划的开始日期和责任分配,一直分解到WBS的控制系统可以操作的水平。

     为进程和成本制定的绩效测量标准。

     对项目每个阶段的具有里程碑意义的事件和目标日期的记载。

     关键的或必需的人员。

     主要风险,包括制约因素和假设以及每个阶段的对应计划。

     辅助的管理计划,包括范围管理计划和进度管理计划等。

     已经公布的和悬而未决的决定。

    根据各项目的需要,其他项目规划的输出应该包含在这正式计划中。例如:为一个大的工程作的项目计划通常包括一个组织管理图表。

    2. 辅助说明。为项目计划所做的辅助说明包括:

     没有包括在这个项目计划中的其他规划程序的输出。

     在项目计划开发期间产生的附加信息和文件(比如:制约因素和假设如果事先没考虑到)。

     技术性文件、要求、特征和设计等方面的文件。

     有关标准文件。

    应该根据需要对这些材料进行组织,使它们在项目计划实施期间更易于利用。

    4.2项目计划的实施 

       项目计划执行是实施这个项目计划的主要过程--项目的巨额预算在这个执行过程中被花掉。在这个过程 ,项目经理和项目管理团队必须协调和指导项目中存在各种技术和组织问题。这是项目的应用领域最有影响的项目程序。因为项目产品是在这个过程中产生的。

    4.2.1对项目计划实施的输入

       1. 项目计划。项目计划在(1.1.3.1中阐述了)。具体项目的管理计划(范围管理计划、风险管理计划和采购管理计划等)和绩效测量基准是对项目计划实施的主要投入。

       2. 辅助说明。辅助说明在4.1.3.2中阐述了。

       3. 组织管理政策。组织管理政策在4.1.1.3中阐述。所有包括组织管理政策都在项目中有正式的和非正式的两种,它们会影响项目计划的实施。

       4. 纠正措施。纠正行为所做的是把未来项目的执行,按照人们的预期纳入与项目计划要求相一致的轨道进行运转。纠正措施是各种控制程序的一个输出--在这里作为一种输入完成反馈环,这个反馈环是为确保项目管理的有效性。

    4.2.2项目计划实施的工具和技术

       1. 普通管理技能。普通管理技能如领导艺术、信息交流和协商组织等,都对项目计划的实施产生实质性的影响。普通管理技能在第2章第4节中阐述。

       2. 生产技能和知识。项目团队必须适当地增加一系列有关项目生产的技能与知识的学习。这些必要的技能被作为项目规划(尤其是在7.1中的资源规划阐述的)的一部分得以确认,并通过人员的组织过程来获取、体现。

       3. 工作分配系统。工作分配系统是为确保批准的项目工作能按时、按序地完成而建立的正式程序。基本的方式通常是以书面委托的形式开始进行工作活动或启动工作包。 

    一个工作分配系统的设计,应该权衡实施控制收入与成本之间的关系。例如:在一些比较小的项目上,言语分配就足够了。

     4. 形势评论会。形势评论会是把握有关项目信息交流的常规会议。在许多项目中,形势分析会以各种不定期的和不同级别的形式召开(比如:项目管理团队可有周会并通过周会或月会的形式与客户沟通)。

     5. 项目管理信息系统。项目管理信息系统在4.1.2.3中阐述。

     6. 组织管理程序。项目的所有组织管理程序包括了运用在项目实施过程中的正式的和非正式的程序。

    4.2.3项目计划实施的结果

     1. 工作成果。工作成果是为完成项目工作而进行的具体活动结果。工作成果资料--工作细目的划分、工作已经完成或没有完成,满足质量标准的程度怎样,已经发生的成本或将要发生的成本是什么等等--这些资料都被收集起来,作为项目计划实施的一部分,并将其编入执行报告的程序中(看第10章,第3节对执行报告有更细的讨论)。

     2. 改变要求。改变项目要求(比如:扩大或修改项目合同范围,修改成本或进行估算等等)通常是在项目工作实施时得到确认。

    4.3全程变化控制

      全程变化控制是关于(a)影响造成项目变化的因素,并尽量使这些因素向有利的方向发展;(b)判断项目变化范围是否已经发生;(c)一旦范围变化已经发生,就要采取实际的处理措施。全程变化控制要求:

      保持绩效测量标准的一致性--所有被通过的变化应该能够反映在这个项目计划中,但是,只有项目范围界定的改变会影响绩效测量标准

     要确保产品范围的变化要在已确定了的工作范围中反映出来(产品范围和工作范围是不同的,有关这些内容的介绍在第5章)。

     协调变化过程的理论体系用图表4-2来阐明。例如,一个工作进程表的改变,通常会影响成本、风险、质量和人员调整。

    图4

    4.3.1对全程变化控制的输入

       1. 项目计划。项目计划为变化控制提供基本的参考(看4.1.3.1).

       2. 执行报告。执行报告(在第10章第3节阐述)提供的资料是项目执行中的一些情况。执行报告也能提醒项目团队公布项目未来可能出现的问题。

       3. 改变要求。改变要求有多种形式--口头的或书的、直接的或间接的、内在的或外在的原因及合法的代理或任选的。 

    4.3.2为全程变化控制投入的工具和技术

       1. 变化控制系统。变化控制系统是正式汇集资料,创建文件程序,创建的这个文件程序必须是经权威项目文件认可了发展阶段的文件。它包括书面工作、跟踪系统和必要的权威部门认可了的变化级别。

    在多数场合,项目执行组织将有一个变化控制系统,它能够通过项目,用"好象是什么"的形式被采纳。然而,如果没有一个合适的控制系统可以利用,则项目团队就需要开发一个这种系统,作为这个项目的一部分。

       许多变化控制系统都包括一个变化控制委员会(CCB),负责批准或抵制变化要求。控制委员会的权力和责任应该得到仔细地界定,并且要取得主要参与者的同意。在一些大的复杂的项目中,可能会有很多控制委员会,他们负有不同的职责。

       变化控制系统也应该包括这样一些程序,这些程序是在没有预先审议情况下通过的处理改变的程序。例如:象紧急紧急情况的处理结果。典型的例子是,一个控制系统将允许对一些确定的变化类别实行"自动放行处理"许可。这些变化必须也能被记录并让人们获得,以便在项目后期不要引发一些问题。

       2.结构管理。结构管理是编制一些文件程序,用于对技术和行政政策管理进行指导和监督:

     项目或系统的界定、文件功能和物理特征。

     对于任何会改变的特征的变化进行控制。

     记录和报告这些变化并作必要的分析。

     审计这个项目和系统的工作,检验它们是否符合要求。

    在许多应用领域,结构管理是变化控制系统的一个分支,用它是为确保项目产品说明的正确性和完整性。然而,在一些应用领域,结构管理这个词是用来描述一些精确的变化控制系统的。

     3. 绩效检测。绩效检测技术比如能帮助人们判断纠正措施是否符合计划的要求。

     4. 附加计划。项目很难按照计划的要求精确地运转。预期的变化可能要求新或修改成本估算、修改活动顺序,分析对风险的任意对策或对项目计划进行其他评判。

     5. 项目管理信息系统。项目管理信息系统在4.1.2.3中阐述。

    4.3.3从全程变化控制中的输出

       1. 项目计划的更新。项目计划的更新是对项目计划内容进行修改或辅助说明(在4.1.3.1和4.1.3.2中有反映)。根据需要适当地通知项目的参与者。

       2. 纠正措施。纠正措施在4.2.1.4中阐述。

       3. 经验总结。我们应该把各种变化的原因,纠正行为背后的理由和经验总结的其他类型编制成文件,以作为历史资料的一部分,为执行组织完成这个项目和其他项目报务。 

    5章 项目范围管理

      项目范围管理包括的程序,要求能确保该项目所覆盖的整体工作要求和单项工作要求,从而促使项目工作成功地完成。它首先涉及到界定和控制项目包括的内容。图表5-1提供了主要项目范围管理程序的总述: 


     

    同其他理论体系中的程序一样,这些程序彼此互相影响。根据项目计划的需要,每个程序可能会需要一个或多个个体或团体的努力。在每个项目阶段,每个程序通常至少发生一次。

    尽管这里提到的这些程序是作为各自独立的因素给予了明确的界定,但是,在实践中它们是以各种形式重迭和影响的。这里就不详细论述了。程序的互相影响在第3章中作了详细的讨论。

    根据项目中的上下文关系,"范围"这个词涉及到两方面内容:

     产品范围界定--产品范围的特征和功能包含在产品或服务中。

     工作范围界定--项目工作的完成为的是能交付一个有特殊的特征和功能的产品。

    本章的核心是阐述用于管理项目的程序、工具和技术。用于管理项目产品范围变化的程序、工具和技术,在不同应用领域中会有所不同,通常它们被认为是项目生命周期的一部分(项目的生命周期在2.1中阐述)。

    一般情况下,一个项目是由一个单个产品组成的,但是,这个产品可能包括几个子要素,每个子要素都彼此分离,但是在产品活动范围中又相互依存。例如:一个新的电话系统,通常包括四个子要素--硬件、软件、试运行和完成。

      产品范围的完成情况是参照客户的要求来衡量的,而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性,以确保项目的具体工作成果,能按特定的产品要求准时交付。

    5.1启动阶段

    启动阶段是正式认可一个新项目的存在,或者是对一个已经存的项目让其继续进行下一阶段工作的过程(看2.1,对项目阶段有详细的阐述)。在一些组织中,一个项目计划的正式启动,是在必要的学习、初步的计划和其他相当于划分项目开始阶段的工作完成后才进行的。有些项目形式,如特殊的内部服务项目和新产品开发项目,它们的启动不是很正规,要受到所做的工作数量的制约,目的是为项目正式启动时,职员能牢固地掌握这些工作方法。项目通常是由于以下的需要而被核准的 

     市场需求(比如:一家石油公司核准一个建立新炼油厂的项目,是对长期的汽油发展战略作出的反应)。

     商业需求(比如:一个旅游公司为了增加收入核准的项目是开辟一条新的旅游线路,以增加它们的收入)。

     客户的需求(比如:一家电力公司核准一个建一家新的发电厂的项目,为新的工业园服务)。

     工艺的进步(比如:电力公司核准一个引进音像设备的项目,是为了发展影视娱乐业)。 

     法律要求(比如:涂料生产厂家核准的项目是,建立一个处理有毒物品的生产线)。

    这些动因也可能被称为是问题、机遇或商家的要求。无论叫什么,其核心的问题是管理部门通常要做出怎样对应的决策出来。

    5.1.1对启动阶段的投入

     1. 产品说明。产品说明应该能阐明项目工作完成后,所生产出的产品或服务的特征。产品说明通常在项目工作的早期阐述少,而在项目的后期阐述的多,因为产品的特征是逐步显现出来的。

     产品说明也应该记载已生产出的产品或服务同商家的需要或别的影响因素间的关系,它会对项目产生积极的影响(看上面的清单)。尽管产品说明的形式和内容是多种多样的,但是,它应能对以后的项目规划提供详细的、充分的资料。

     许多项目都包括一个按购买者的合同进行工作的销售组织。在这种情况下,最初的产品说明通常是由购买方提供的。如果买者的工作本身就是制定项目的,则买者的产品说明就是对自己工作的一种陈述,这些将在12.1.3.2里阐述。

     2. 战略计划。所有的项目组织都应该提供项目执行组织的战略目标--在项目决策的选择中,执行组织的战略计划应该作为一个考虑的因素。

     3. 项目选择标准。项目选择标准通常是通过项目产品界定的,它涉及到管理可能包含的全部范围(如:财政收入、市场份额和公众的观念等)。

     4. 历史资料。历史资料包括以前项目选择决策的结果和以前项目执行的结果,在可获得的范围内对它们加以考虑。在项目启动阶段,就包含了对项目下一阶段工作的认可时,有关前阶段结果的信息通常是非常重要的。

    5.1.2为启动阶段投入的工具和技术

    1. 项目选择方法。项目选择方法通常是下列两种模型之一:

     利润测量方法--比较研究法、评分模型、利润贡献或经济模型。

     制约最优化方法--数学模型、用线性的、非线性的、动态的、完整的及混合目标项目规则系统。

    这些方法通常被作为决策模型来考虑。决策模型既包括常规技术(决策树、核心选择和其他),也包括特殊技术(历史进程分析、逻辑结构分析及其他)。在一个成熟模型中,对项目选择标准的应用通常被作为一个分离独立的阶段。 

    2. 专家评审。专家评审通常是要对这个项目的投入进行评估。象这种专家评价,可以通过一个组织或拥有特殊知识和受了专门培训的个人来进行,可以通过许多途径获得。包括:

     这个执行组织中的其他单位

     顾问

     专家和技术联合会

     工业集团

    5.1.3启动后的成果

    1. 项目证书。项目证书是正式认可项目存在的一个文件。它对其他文件既有直接作用,也有参考作用。

     既定的商业目标。

     产品说明书。

    项目证书应该通过管理者对项目及项目所需的条件进行客观的分析后颁发,它提供给项目经理运用、组织生产资源,进行生产活动的权力。

    当一个项目按照合同执行时,合同条款通常象项目证书一样,为销售者服务。

    2. 指定/委派的项目经理。通常,项目经理应该尽可能在项目的早期进行指定和委派是比较合适的。项目经理应该在项目计划实施开始之前被委派(这些理论的阐述在4.2中),更应该在许多项目规划完成之前就委派好(项目的规划过程在3.3.2中阐述)。

    3. 制约因素。制约因素是限制项目管理团队进行运作的要素。例如:事先确定预算是制约项目团队的操作范围、职员调配和进步计划的一个很重要的因素。 

    当一个项目按照合同执行时,合同条款通常是受合同制约的。

    4. 假设因素。为了规划目标的准确性,考虑到的假设因素必须具有科学性、真实性和确定性。例如:如果关键人物的到场日期不能落实,那么项目团队就应该设置一个具体的开始时间。假设通常包含有一定程序的风险。在此它们可能被确认或它们可能是一个风险界定的输出(在11.1进行论述)。

    5.2 范围规划

    范围规划是创立书面文件,阐述项目范围为未来项目提供基础条件的过程,特别是包括了用以确定项目或阶段是否成功完成的标准。例如:一个工程公司签订的合同是设计一个石油处理工厂,就要求在设计具体目标时,要界定好具体的工作范围。范围阐述形式的基础是通过确认项目目标和主要项目的子项目,使项目团队与项目客户之间达成一个协议。

    如果范围阐述的所有要素已经具备(如:主要项目的子项目能够反映项目目标,项目证书能证明项目目标),那么,这个过程就仅剩实质性的制定书面文件的工作了。

    5.2.1对范围规划的输入

       1. 产品说明。产品说明在5.1.1.1中讨论。

       2. 项目证书。项目证书在5.1.3.1中阐述了。

    3. 制约因素。制约因素在5.1.3.3中作了阐述。

    4. 假设条件。假设的描述在5.1.3.4中。

    5.2.2为范围规划投入的工具和技术

    1. 产品分析。产品分析意味着开发一个更好、更明确的项目产品。它包括这样一些技术,如:系统工程、价值工程、价值分析、功效分析和质量功能展示等。

    2. 利润/成本分析。利润/成本分析意味着估算各种项目选择的有形成本和元形成本(支出)与利润(收益)。然后用投资收益率或投资偿还期限等经济方法,评估这些经确认的选择方案相对优势,用任选的鉴定方式估算投入--产出情况的合意程度。

    3. 可供选择的签订方式。可供选择的鉴定方式是个包容性较大的词,描述的是完成一个项目用任何一种技术,就能产生一个不同的方案。这里常用的是一般性的各种管理技术,许多管理技术有一个共同特征:"头脑风暴"和"迂回思维方式"。

    4. 专家评审。专家评审在5.1.2.2中阐述。

    5.2.3 从范围规划中的产出

    1. 范围阐述。范围阐述是为制定未来项目决策,进一步明确或开发一个参与者之间能达成共识的项目范围提供一个纪实基础。作为项目的过程,阐述的这个范围可能需要修改或精确些,从而很好地反映项目范围的变化。这个范围阐述可以直接进行分析,也可以通过参考其他文件来得出: 

     项目调整--商家的既定目标。项目调整要为估算未来的得失提供基础。

     项目产品--产品说明的简要概况(产品说明在5.1.1.1中讨论)。

     工作细目成果--列一个子产品级别概括表,完整的、满意的这些子产品标志着项目工作的完
    成。例如:为一个软件开发项目设置的主要子项目可能包括工作所需的电脑代码、工作手册和专门的导师。当这些子产品都知道了,排除应该是确定了,任何不明显的排除都包含在这个排除中了。

     项目目标--考虑到项目的成功性,质量标准必须要满足项目的要求,项目目标至少要包括成本、进度表和质量检测。项目目标应该有标志(如:成本)、单位(如美元、英磅)和绝对的或相对的价值(如:少于150万美元等)。不可量化的目标(如:"客户的满意程度")要承担很高的风险。

    在一些应用领域,项目工作细目被称为项目的目标,而全部的项目目标被称作是评价项目成功的关键。

    2. 辅助说明。为项目范围阐述作辅助说明,应该是根据需要记录和编组一些文件,并通过其他项目管理程序,把它变成易被利用的东西。辅助说明总是包括所有已认定的假设文件和制约因素。附加说明的数量在不同的领域中会有所不同。

    3. 范围管理计划。范围管理计划是描述项目范围如何进行管理,项目范围怎样变化才能与项目要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估(比如:怎样变化、变化频率如何及变化了多少)。范围管理计划也应该包括对变化范围怎样确定,变化应归为哪一类(这特别困难--而且也因此绝对必要--当产品特征还在逐步形成中时,依然是逐步显视的)等问题的清楚描述。

    根据具体项目工作的需要,一项范围管理计划可以是正式的或非正式的、很详细的或粗略的。项目管理计划是全部项目计划(在4.1.3.1中阐述)的分支要素。

    5.3范围界定

    范围界定包括分解这个主要工作细目的子项目(象在范围阐述中界定的那样),使它变成更小、更易管理、操作的东西。目的是为了:

     提高估算成本、时间和资源的准确性。

     为绩效测量和控制确定一个基准线。

     使工作变得更易操作的,责任分工更加明确。

    正确的范围界定是项目成功的关键。"当它是一个很差劲的范围界定时,由于不可避免的变化会使最终项目成本可能会很高,因为这些不可避免的变化会破坏项目节奏,导致重复工作、增加项目运行的时间、降低生产功效和工作人员的士气"

    5.3.1对范围界定的输入

    1. 范围阐述。范围阐述在5.2.3.1中。

    2. 制约因素。制约因素的阐述在5.1.3.3中。当一个项目按照合同执行时,由合同条款定义的制约因素,在范围定义中通常是重要的考虑因素。

    3. 假设条件。假设条件的阐述在5.1.3.4中。

    4. 其他规划输出。程序的输出在其他章节。考虑到可能对当前项目范围界定的影响,应该对其他规划的输出进行回顾。

    5. 历史资料。在项目范围界定期间,应该考虑以前项目计划的有关历史资料。对于以前的项目来说,资料中的有关错误或省略的东西应该有特殊的用途。

    5.3.1为界定范围投入的工具和技术

    1. 工作分析结构样板。一个工作分析结构(WBSs,在5.3.3.1中阐述了)从以前的项目到新项目都能用,虽然每个项目是唯一的,但是,WBS经常能被"重复使用",多数项目间在某种程序上是具有相似性的。例如:从每个阶段看,许多项目中给出的组织形式都有相同或相似的生命周期和因此而形成的相同或相似的工作细目要求。

    许多应用领域都有标准或半标准的WBSs,它能当作样板用。例如:美国国防部,有界定标准的WBSs为防御材料项目服务。图表5-2中展示出的样板是这些样板中的其中一个样板的一部分。

    2. 分解。分解意味着分割主要工作细目,使它们变成更小、更易操作的要素,至到工作细目被明确详细的界定,以有助于未来项目的具体活动(规划、评估、控制和选择)的开展。分解包含着以下主要阶段:

    (1)确认项目的主要要素。通常,项目的主要要素是这个项目的工作细目和项目管理。然而,在一定时期内,这个主要要素总是根据项目的实际管理而定义的。例如:

     项目生命周期的阶段可以当作第一层次的划分,把第一层次中的项目细目在第二阶段继续进行划分。

     组织管理政策在WBSs的每个分支中可能都不一样,用图表5-4来说明。

    (2)决定是否能对开发到这种详细层次的每个要素进行充分的成本和期限估算。这里"充分的"意味着能够改变项目运行过程--工作细目的分解如果在很久的将来才能完成的话,那么这种分解也就没了确定性。对于每一个要素,如果是充分、详细的论述,就有四个阶段,否则,是三个阶段--这意味着不同的要素有不同的分解层次。

    这仅仅是WBS的图表说明形式。它不能代表任何专门项目的全部项目范围,也不意味着组建一个WBS是项目这种形式的唯一方法。

    (3)确认项目的组成要素。子项目的组成要素应该用有形的、可证实结果来描述,目的是为了绩效易检测。当我们知道了主要构成要素后,这些因素就应该用项目工作怎样开度,在实际中怎样完成形式来定义。有形的、可证实的结果既包括服务,也包括产品(比如:情形报告能够用图形来描述;对于一个工业项目,组成要素可能包括几个独立单位及对它们的综合)。

    (4)核实分解的正确性:

     为完成具体工作分解,划分更低层次的细目是否必要和充分?如果没必要,这个组成要素就必须重新修正(增加项目、削减项目或修改项目)。

     每个项目都要有明确的、完整的定义吗?如否果不是,这种描述需修正或扩充。

     是否每个项目都要有适当的日程表、预算能分配给特殊的组织单位(如:部门、团队或个人)?谁能担负起满意地完成这个项目的任务?如果没有,修正是必要的,为的是提供一个充分的管理控制。

    5.3.2从范围界定中的输出

    1. 工作分析结构。一个工作分析结构是项目要素的一个子项目定位组,是对项目总范围的组织和界定:如果这个工作不是WBS系统内的,那么,这就是项目范围以外的工作。作为范围阐述,这个WBS通常是用来开发或巩固一个达成共识的项目范围。项目的划分每降低一个层次阐述,就要增加一个项目要素的详细描述。在5.3.2.2中阐述了为开发一个WBS的许多共同方法。一个WBS的正式代表形式是象图表5-2、5-3和5-4这种图表形式。当然,WBS不应该与表述方法混淆起来。在图表中绘制一个非结构式的活动清单并没有做成一个WBS。

    这仅仅是WBS的图表形式。它不能代表任何专门项目的全部项目范围,也不意味着组建一个WBS是项目这种形式的唯一方法。

    在WBS中的每一个具体项目工作通常都指定唯一的代码,这些代码被看作是与会计代码相同的。WBS的最低层次通常是指工作包。这些工作包可能在以后再分解,把它作为活动的定义。在6.1中阐述。

    具体工作要素的阐述通常收集在WBS这个字典中。一个典型的项目分析字典,既包括了对工作包的阐述,也包括了对其他规划资料如进度表的日期、成本预算和员工分配等问题的阐述。


      

    WBS不应该与其他表示项目信息的"分析结构"混淆。在一些应用领域,通常会用到的其他一些结构包括: 

     契约性的WBS(CWBS),它是用于界定销售者提供给购买者的产品报告级别的。通常CWBS包括的内容要比WBS的少,它用于卖方管理买方的工作环境中。

     组织分析结构(OBS),它是用以展示工作要素已经分配给了具体的组织单位。

     资源分析结构(RBS),每一个RBS都是与OBS不同的,通常用于给个人分配工作要素的时候。

     材料清单(BOM),它代表了一种级别概念,表示了制成(或装配)一个工业产品所需的工具箱、零件和零部件。

     项目分析结构(PBS),它与WBS是基本相同的。PBS更广泛地应用在因WBS不能妥善表达BOM内容的领域中。 

    5. 4范围核定

    范围核定是通过参与者(倡议者、委托人和顾客等)的行为正式确定项目范围的过程。它要求回顾生产工作和生产成果,以保证所有 项目都能准确地、满意地完成。如果这个项目已提前终止,这个范围核实过程也应该证实并应以书面文件的形式把它的完成情况记录下来。范围核实与前面讲的质量控制是不同的,范围核定是有关工作结果的验收问题,而质量控制是有关工作结果正确性的问题。

    5.4.1对范围核定的投入

    1. 工作成果。工作成果--项目阶段性的交付物已经完成或部分完成,已经发生的或将要发生的成本是什么等--它是项目施实的输出(在4.2中讨论)。

    2. 生产文件。描述项目产品的生产文件,必须对项目的回顾有帮助作用。通过应用领域用生产文件描述这些文件(计划、特征、技术性文件和图纸等)的变化情况。

    5.4.2为范围核实投入的工具和技术

    1. 检验。检验包括用象测量、测验和考试等这样一系列活动去判断承担的工作任务是否符合计划的要求。检验有各种称呼:评价、产品评价、审查和走过场等;在应用领域,这些不同的词有它自己的使用范围和特定的含义。

    5.4.3范围核实的输出

    1. 正式验收。验收文件是当事人或投资者已经认可了这个项目产品或某个阶段的文件,他们必须为完成这项工作准备条件,做出努力。象这种验收可能是有条件的,尤其是在一个阶段末的时候。

    5.5范围变化控制

    范围变化控制是关于(a)影响造成项目变化的因素,并尽量使这些因素向有利的方面发展,(b)判断项目变化范围是否已经发生,(c)一旦范围变化已经发生,就要采取实际的处理措施。范围变化控制必需与其他控制管理程序(时间控制、成本控制、质量控制及其他控制在4.3中阐述)结合在一起用。

    5.5.1对范围变化控制的输入 

    1.分析结构。WBS在5.3.3.1中进行了阐述,它确定了项目的范围基准线。

    2. 执行报告。执行报告在10.3.3.1中阐述。执行质量报告是提供一个项目范围执行情况,如中间产品已经完成或没有完成的资料。执行报告也能提醒项目团队公布未来可能发生的情况。

    3. 改变要求。改变要求可以采取很多形式--口头的或书面的、直接的或间接的、从内部或外部开始及法定的(合法的)批准的或任选的。改变的可能是要求扩大项目范围或缩小范围。许多要求的改变都是这样一些情况导致的:

     一个外在事件发生了(如:政府的法规发生了变化)。

     产品范围的界定有错误或疏漏(比如:程控交换系统设计的失败,是因为它的覆盖面不够大)。

     项目范围的界定有错误或疏漏(比如:用材料清单代替了工作分析结构)

     产值增加的变化(比如:通过采用先进的技术,改变项目的发展环境,可降低成本,当环境还是原来的情况时,降低成本是不可能的)。 

    4.范围管理计划。范围管理计划在5.2.3.3中阐述。

    5.5.2为范围变化控制准备的工具和技术

    1. 范围变化控制系统。一个范围变化控制系统定义为这样一些程序,即通过它能改变项目范围。它包括工作面、跟踪系统和权威部门允许变化所需的认可标准。范围变化控制系统应该与综合管理中讲的全程变化控制系统(在4.3中论述)结合在一起用,尤其要与适合于控制产品范围的系统结合在一起。当项目按照合同执行时,范围变化控制体系必须按所有相关的合同规定执行。

    2. 绩效测量。绩效测量技术在10.3.2中阐述,绩效测量技术能帮助人们评估所发生的任何重大变化。如果变化发生后要求有纠正措施,那么,范围变化控制的一个重要部分是分析导致变化的原因是什么,并做出对应的处理决定。

    3. 附加规划。很少有项目能按合同的要求精确地运转。预期的范围变化可能要求对WBS进行修改或对其他的任选方法进行分析。

    5.2.3范围变化控制的输出

    1. 范围变化。范围变化是对已被认可的WBS所确认的项目范围的任何修改。范围变化经常要求对成本、时间、质量和其他项目目标进行判定。通过规划程序反s馈的范围变化情况,技术信息和规划文件,要根据需要进行更新,并适当地通知参与者。

    2. 纠正措施。纠正措施所做的事是把未来项目按照人们的预期,纳入项目计划所要求的轨道进行运作。 

    3. 经验总结。我们应该把各种变化的原因,纠正行为选择的背后理由,以及从范围变化控制中得出的其他形式的经验教训,当作文件记录下来,目的是把这些资料变成历史记录的一部分,为项目执行组织执行这个项目和其他项目提供参考。

    6章 项目时间管理

    项目时间管理由一些过程组成,这些过程为按时完成项目所必须,表6-1为主要过程的一个框架。

    以上过程彼此相互影响,同时也与外界的过程交互影响。根据实际情况,每一过程由专人或数人或一组人加以完成。在项目各阶段,每个过程通常至少出现一次。 

    虽然上述过程是分开叙述具有明确的分界。实际上它们也许是重迭和相互影响的。过程间相互影响在第3章详细讨论。

    有些项目,特别是一些小项目,活动排序、活动时间估计和进度安排这些过程紧密相连可视为一个过程。(例如,当这些过程可由一个人在较短时间内完成时)这里还是把这四个过程作为不同过程,因为每一过程所用工具和方法是不同的。

    当前,在项目管理领域里,活动(ACTIVIFIES)和作业(TASKS)的关系的用法并不统一。

     在许多应用领域里,活动视由作业组成,这种用法最常见。

     在其它,作业视由活动组成。

    这里重要的不是使用词的名称,而是要做的工作是否被描述清楚以及被工作人员所理解。 

    图6-1项目时间管理框

    6.1定义活动

       定义活动是一过程,它涉及确认和描述一些特定的活动,完成了这些活动意味着完成了WBS结构中的项目细目和子细目。通过定义活动这一过程可使项目标体现出来。

    6.1.1定义活动过程的输入

       1、 工作分层结构图。工作分层结构图是定义活动过程的主要输入(见节5.3.3.1关于WBS的详尽讨论)。

    2、 范围的叙述:在定义项目活动时,包含在范围陈述中的项目的必要性和项目目标必须加以考虑(见节5.2.3.1关于项目范围描述的详细讨论)。

    3、 历史的资料:在定义项目活动过程中,要考虑历史的资料(以往类似的项目包含哪些活动)。

    4、 约束因素:约束因素将限制项目管理小组的选择。

    5、 假设因素:要考虑这些假设因素的真实性、确定性,假设通常包含一定的风险,假设是对风险确认的结果(见节11.1)。

    6.1.2定义活动的工具和方法

    1. 分解 分解是把项目的组成要素加以细分为可管理的更小的部分,以便更好管理和控制。分解在节5.3.2.2已详尽讨论,但这里讲的分解和定义范围中讲的分解之间的主要区别是:这里分解的结果是活动而不是项目细目(有形的东西)。在有一些应用领域,WBS和活动目录是同时编制的。

    2. 参考样板:先前项目的活动目录(见节6.1.3.1)或活动目录的一部分常可作为新项目活动目录的参考样板。当前工程的WBS结构中的要素目录可作为今后其它类似WBS结构要素的参考样板。

    6.1.3定义活动过程的输出

    1. 活动目录 活动目录必须包括项目中所要执行的所有活动(无一遗漏)活动目录可视为WBS的一个细化。这个活动目录应是完备的,它不包含任何不在项目范围里的活动。活动目录应包括活动的具体描述,以确保项目团队成员能理解工作应如何做。

    2. 细节说明 有关活动目录的细节说明应表达清楚,以方便今后其它项目管理过程的利用。细节说明应包括对所有假设和限制条件的说明。细节的内容由应用领域不同而不同。

    3. WBS结构的修改 在利用WBS去确定哪些活动是必须的过程中,项目团队也必然能确认哪些项目细目被遗漏了或者意识到:项目细目的描述需要修改或应更清楚。任何这样的修改必须在WBS相关文件(例如,成本估计)中反映出来,以上修改通常在项目涉及新的或未被验证的技术时发生。 

    6.2活动的排序

       活动排序过程包括确认且偏制活动间的相关性。活动必须被正确地加以排序以便今后制订实现的可行的进度计划。排序可由计算机执行(利用计算机软件)或用手工排序。对于小型项目手工排序很方便,对大型项目的早期(此时项目细节了解甚少)用手工排序也是方便的,手工编制和计算机排序应结合使用。

    6.2.1活动排序过程的输入

       1. 活动目录 活动目录见节6.1.3.1

       2. 产品描述 产品的描述见节5.1.1.1,不同的产品特征常明显地影响活动的排序(例,建设中某工厂的平面布局,一个软件项目子系统的接口)同时,对产品的描述要加以核对、审查以确保活动排序的正确性。

       3. 内在的相关性:内在相关性是指所做工作中各活动间固有的依赖性,内在相关性通常由客观条件限制造成的(例如,在一个建设项目在地基完成前先进行大楼的建设是不可能的。一个电子项目只有在原型完成后才能对它进行测试。)

       4. 指定性的相关性:指定性是指由项目管理团队所规定、确定的相关性,应小心使用这种相关性并充分加以陈述。因为承认并使用这样的相关性进行排序会限制以后进度计划的选择。这种相关性通常发生在以下一些情况。

     在一个特定应用领域有一个最好的做法

     有些时候,即使有几种可接受的排序,但因某种原因一个特定的活动排序关系被偏爱

    指定性相关也可称偏好相关或软相关。

    5. 与外部相关性:外部相关性是指本项目活动与外部活动间的相关性。例如,一个软件项目的测试活动依赖于外部硬件的运到,或建设项目施工之前应先听取人们对环保的意见。

    6. 约束:在节6.1.1.4描述。

    7. 假设:在节6.1.1.5描述。

    6.2.2活动排序的工具和方法

       1. 前驱图法(PDM)这是编制项目网络图的一种方法,利用节点代表活动而用节点间箭头表示活动的相关性(见节6.2.3.1)图6.2表示一个用PDM法编制的简单网络图,这种方法也叫活动在节点法(AON)是大多数项目管理软件包所采用的方法。PDM法可用手算也可用计算机实现。

      有四种相关的前驱关系: 

     结束→开始:某活动必须结束,然后另一活动才能开始。

     结束→结束:某活动结束前,另一活动必须结束。

     开始→开始:某活动必须在另一活动开始前开始。

     开始→结束:某活动结束前另一活动必须开始。

    在PDM法,结束→开始是最常见逻辑关系,开始→结束关系极少使用。(也许只有职业进度计划工程师使用)对管理软件,如果用开始→开始、结束→结束或开始→结束关系会产生混乱的结果,因为很多管理软件编制时并没有对这三种类型的相关性加以考虑。

    2. 箭头图方法(ADM)这是项目网络图的另一种方法,箭线表示活动,用节点连结箭线以示相关性。(见节6.2.3.1)图6-3表示用ADM法做的一个简单项目网络图。这种技巧也叫箭线代表活动(AOA),虽比PDM法较少使用,但在某些应用领域仍是一种可供选择的技巧。ADM仅利用结束→开始关系以及用虚工作线表示活动间逻辑关系。ADM法可手编也可在计算机上实现。

    图6-3用箭头图画的网络逻辑图

       3. 条件图方法:如图表审评技术(GERT)和系统动力学,这些模型允许非前后排序活动的存在,诸如一个环。(例子是某试验须重复多次)或条件分技(例,一旦检查中发现错误,设计就要修改)而PDM法和ADM法均不允许和条件分技的出现。

       4. 网络参考样板:用各种标准网络可用来加速项网络图的编制。网络的一部分叫子网络,当一项目包含几个相同或几乎相同内容时,子网络特别有用。(如一个高层写字楼的地板;一个新药品研究项目的临床试验;或一个软件工程的程序模块)

    6.2.3活动排序过程的结果

       1. 项目网络图:一个项目网络图是项目所有活动以及它们之间逻辑关系(相关性)的一个图解表示。图6-26-3表示同一项目网络图的二种不同画法。网络图可手工编制也可用计算机实现。网络图应伴有一个简洁说明以描述基本排序方法。但对不平常排序应充分地加以叙述。

       项目网络图经常不正确的被称为PERT图。(计划评审技术)实际上PRET图是一类特殊类型的项目网络图,今日这种图很少应用了。

       2. 修改后的活动目录 前面已述:活动定义的过程可对WBS做修改,以几乎同样的方法,编制网络图也同样出现这样的情况(例,一个活动必须进一步分划或重新定义以画出正确的逻辑关系)。

    6.3活动时间估计过程

       活动时间估计指预计完成各活动所需时间长短,在项目团队中熟悉该活动特性的个人和小组可对活动所需时间作出估计。

       估计完成某活动所需时间长短要考虑该活动"持续"所需时间。例如,混凝土养护需要4天时间,即需要2--4天工作日,到底是几天取决于(A)活动的开始日期是星期几?(B)周未是否算工作日?

    绝大多数的计算机排序软件会自动处理这类问题。整个项目所需时间也是运用这些工具和方法加以估计的,它是作为制订项目进度计划的一个结果。(见节6.4

    图片六

       1.活动目录 1.专家判断 1.活动时间估计
       2.约束 2.类推估计 2.估计的基础
       3.假设 3.仿真 3.活动目录修改
       4.资源需求
       5.资源库质量
       6.历史资料

    6.3.1活动所需时间估计的输入

    1. 活动目录 见节6.1.3.1

    2. 约束 见节6.1.1.4

    3. 假设 见节6.1.1.5

    4. 资源需求 见节7.1.3.1

    大多数活动所需时间由相关资源多少所决定。例如,二人一起工作完成某设计活动只需一半的时间(相对一个人单独工作所需时间)。然每日只能用半天进行工作的人通常至少需要二倍的时间完成某活动(相对一个人能整天工作的所需时间)

    5. 资源质量 大多数活动所需时间与人和材料的能力(质量)有关,例如,对同一活动,设有两个人均全日能进行工作,一个高级技工所需时间少于低级技工所需时间。

    6. 历史资料 有关各类活动所需时间的历史资料是有用的,这些资料来源来自于以下情况:

     项目档案--与这个项目有关的一个或几个组织也许保留有先前项目结果的记录,而这些纪录非常详细可帮助时间估计。在许多应用领域,个别小组成员也许也保留这些记录。

     商业用的时间估计数据库--过去的一些数据往往是有价值的,当活动所需时间不能由实际工作内容推算时这些数据库特别有用(例如混凝土多少时间干、一个政府机构对某种类型申请的批复需多时间)。

     项目团队知识--项目团队的个别成员也许记得先前活动的实际或估计数。虽然这种重新回忆的方法也许有用,但比起记录的档案文件可靠性低得多。

    6.3.2活动所需时间估计的工具和方法

    1. 专家判断 专家判断见节5.1.2.2。估计所需时间经常是困难的,因为许多因素会影响所需时间(例如,资源质量的高低,劳动生产率的不同)只要可能,专家会依靠过去资料信息进行判断。如果找不到合适专家,估计结果往往是不可靠和具有较大风险(见第11章,项目风险管理)。

    2. 类推估计 类推估计意味利用一个先前类似活动的实际时间作为估计未来活动时间的基础,在以下情况下这种方法常用于估计项目活动所需时间:即只有很有限关于项目的资料和信息。(例如在早期)类推分析是专家判断的一种形式(见节6.3.2.1)以下情况下类推估计是可靠的(A)先前活动和当前活动是本质上类似而不仅仅是表面的相似。(B)专家有所需专长。

    3. 仿真 仿真是用不同的假设来计算相应的时间,最常见的是蒙特·卡罗方法。在这种方法中,假设了各活动所用时间的概率分布以用来计算整个项目完成所需时间的概率分布(见节11.2.2.3进度仿真)

    6.3.3活动所需时间估计的结果

    1. 各活动所需时间的估计 活动所需时间估计是关于完成一活动需多少时间的数量估计。

    活动所需时间估计值用某一范围表示:例如

     2周±2天,表示该活动至少需8天和不超过12天。

     超过3周的概率为15%,表示以85%概率活动将用3周或更短时间。

    第11章项目风险管理包含了关于估计不确定性的详细讨论。

    2. 估计的基础 在制订进度时所用的假设必须被确认合理可信。

    3. 活动目录修改 活动目录修改见章6.2.3.2。

    6.4进度编制

      进度编制要决定项目活动的开始和结束日期,若开始和结束日期是不现实的,项目不可能按计划完成。进度编制、时间估计、成本估计等过程交织在一起,这些过程反复多次,最后才能确定项目进度。 输入 工具和方法 输出

    6.4.1时间进度编制的输入

       1. 项目网络图 见节6.2.3.1

    2. 活动所需时间估计 见节6.3.3.1

    3. 资源需求 见节6.3.1.4

    4. 资源库描述:对进度编制而言,有关什么资源,在什么时候,以何种方法可供利用是必须知道的。例如,安排共享的资源也许是特别困难的一件事,因为这些资源的可利用性是高度可变的。

    在资源库描述中,对各资源的详细程度的要求是变化的。例如,一个咨询项目最初的进度计划编制时,仅须知道,在某一段时间内有两个咨询人员可供利用,然而在同一项目的最终进度编制时,必须确定使用那一位特定的咨询人员。

    5. 日历表 项目日历表和资源工程日历表确定了可用于工作的日期。项目日历表对所有资源有影响(例如,一些项目仅在法定的工作时间内进行,而有的项目可一日三班安排工作)各资源日历表对特定的资源有影响(例如,项目团队的成员可能正在放假接受培训;某一劳动合同可能限定工人一周的工作天数)。

    6. 约束 约束见节6.1.1.4。有三类约束在编制进度计划时必须加以考虑。

     强制性日期:某些工作细目应项目支助者(或项目顾客或其它外界因素)的要求必须在某一特定日期完成。(例如,某技术项目的市场窗口;某董事会要求在某日期前完成一个环保项目。) 

     关键事件或里程碑事件,项目支助者,项目顾客或其它项目相关人提出在某一特定日期前完成某些工作细目,一旦定下来,这些日期就很难被更改了。

    7. 假设 见节6.1.1.5。

    8. 超前与滞后 为了精确说明活动间相互关系,需对超前和滞后有一说明(例如,在订购一台设备和使用之间有二个星期间隔)。

    6.4.2进度编制的工具和方法

       1.数学分析 数学分析包括理论上计算所有活动各自的最早和最迟开始与结束日期,但计算时并没有考虑资源限制。这样算出的日期并不是实际进度,而是表示所需的时间长短,考虑活动的资源限制和其它约束条件,把活动安排在上述时间区间内,最常用的数学方法有: 

     关键路线法(CPM)--借助网络图和各活动所需时间(估计值),计算每一活动的最早或最迟开始和结束时间。CPM法的关键是计算总时差,这样可决定哪一活动有最小时间弹性。CPM算法也在其它类型的数学分析中得到应用。

     GERT(图表审评技术)--对网络结构和活动估计作概率处理(即某些活动可不执行,某些仅部分执行,某些可不只一次执行)。

     PERT(计划评审技术)--利用项目的网络图和各活动所需时间的估计值(通过加权平均得到的)去计算项目总时间。PERT不同于CPM的主要点在于PERT利用期望值而不是最可能的活动所需时间估计(在CPM法中用的)。PERT法如今很少应用,然类似PETR的估计方法常在CPM法中应用。

    2.时间压缩法 时间压缩是一种数学分析的方法。在不改变项目范围前提下(例如,满足规定的日期或满足其它计划目标),该方法寻找缩短项目计划的途径。时间压缩包括如下:

     应急法--权衡成本和进度间的得失关系,以决定如何用最小增量成本以达到最大量的时间压缩。应急法并不总是产生一个可行的方案且常常导致成本的增加。

     平行作业法--平行地做活动,这些活动通常要按前后顺序进行(例如,在设计完成前,就开始在软件项目上写出程序;或在25%的工程点被达到前,就可开始建一个炼油厂的地基)。平地作业常导致返工和增加风险。

     3.仿真 见节6.3.2.3。

     4. 资源调整尝试法 数学分析法通常产生一个初始进度计划,而实施这个计划需要的资源可能比实际拥有的更多。或要求所用资源有大幅度变化(这给管理带来困难)。尝试法(如首先把稀有资源分配到关键路线)可在资源有约束条件下制定一个进度计划。用资源调整尝试法计算出的项目完成时间一般比初始进度长。用计算机优化软件编制进度计划时尝试法叫建立在资源约束基础上的方法。

    资源有约束的进度编制是资源调整的一个特例,前者涉及的仅是可利用资源在数量上限制。

    5. 项目管理软件 项目管理软件被广泛地使用以帮助项目进度的编制。这些软件可自动进行数学计算和资源调整,可迅速地对许多方案加以考虑和选择。用这些软件,还可打印显示出计划编制的结果。

    有许多其它方法可用以显示日期信息,上图中显示了各活动的开始和结束日期

    图6-6 条形(甘特)图

    在条形图上有许多其他方法可用以显示项目信息

       6.4.3进度编制的结果

       1. 项目进度 项目进度至少要包括每一具体活动的计划开始日期和期望完成日期(注:求出的进度计划仍是初步的,一直到资源分配被确定是可行的,资源分配可行性的确认应在项目计划编制完成前做好。见节4.1)

    图6-7 里程碑图


    有许多其他方法在一里程碑图上显示项目信息

    图6-8 有时间尺度的网络图

      在有时间尺度的网络图上有许多其它可接受的表示项目信息的方法一个。

    项目进度可用简略形式或详细形式表示,虽然可用表格形式表示进度,但更常以图的形式来表示,具体有以下几种:

     有日期信息的项目网络图(见图6-5)。这些图能显示出项目间前后次序的逻辑关系,同时也显示了项目的关键路线与相应的活动。(见节6.2.3.1以了解更多关于项目网络图的内容)。

     条型图 也称甘特图(见图6-6)该图显示了活动开始和结束日期,也显示了期望活动时间,但图中显示不出相关性。条型图容易读,通常用于直观显示上。

     重大事件图(见图6-7)它类似于条型图,可出主要的工作细目的开始和完成时间。

     有时间尺度的的项目网络图(见图6-8)它是项目网络图和条型图的一种混合图。这种网络图显示了项目的前后逻辑关系、活动所需时间和进度方面信息。

    2. 详细说明 项目进度的详细说明要包括对所有假设和限制的文字叙述。其它的说明因应用领域而异。例如:

     对一建筑项目,其它的说明也许包括资源的直方图,现金流量的预测,订货与交货计划。

     对一电子工程其它的说明也许只包括资源的直方图。

    详细说明中提供的资料信息通常包括(但不是局限于):

     不同时间阶段对资源的需求,经常以资源直方图形式表现。

     替代的进度计划(在最好情况下或最坏情况下,资源可调整或不可调整情况下,有或无规定日期情况下)。

     计划进度余地或进度风险估计(见节11.3.3)

    3. 进度管理计划 一个进度管理计划是指对进度的改变应如何加以管理。根据实际需要,进度管理计划可做得非常详细也可粗框架,可用正规形式也可以非正规形式表示。它是整个项目计划的一部分。 

    4. 资源需求的修改 资源调整和活动目录的修改可能对资源的初始估计产生很大的影响。

    6.5进度控制

      进度控制是指(a)改变某些因素使进度朝有利方向改变,(b)确定原有的进度已经发生改变,(c)当实际进度发生改变时要加以控制,进度计划控制必须和其它控制过程结合(见节4.3总体改变控制)。

     

    6.5.1进度控制的输入

       1. 项目进度表 项目进度表见6.4.3.1,被认可的项目进度表(又称基准进度)是项目总计划的一部分(见节4.1.3.1)。它提供了度量和报告进度执行情况的基础。

       2. 执行情况报告 执行情况报告(见节10.3.3.1)提供进度进展方面的信息。如哪一活动如期完成了,哪能一活动未如期完成。报告中也可提醒项目团队值得注意的问题。

       3. 改变的要求 要求改变进度的形式有多种--口头或书面,直接或间接,由外部或内部因素导致的,强制性的或有多种选择的。这些具体的改变要求的结果可能是加快进度也许是进度的延长。

       4. 进度管理计划 进度管理计划见节6.4.3.3。

    6.5.2进度控制的工具和方法

       1. 进度改变控制系统 可改变进度的控制系统指一些特定过程,通过这些过程可改变项目进度。该系统包括书面工作,追踪系统以及允许的进度偏差。进度改变控制应和控制系统的总改变结合起来(见节4.3)。

       2. 执行情况测定 如节10.3.2描述的执行情况测定方法可用来评估实际与计划时间进度间差异的大小。控制进度的一个重要部分是决定进度的偏差是否需要纠正的措施。例如,在一个非关键活动的一个较大时间延误也许只对项目产生较小的影响,而在关键活动的较小延误也许就需要马上采取纠正措施。 

       3. 另外的计划 极少的项目精确地依计划进度行事。可预料到的改变需要重新对活动所需时间做估计,重新修改活动排序,或对多种进度计划作出分析。

       4. 项目管理软件 项目管理软件见6.4.2.5,项目管理软件能把计划日期和实际日期加以对比,并能预测进度改变所造成的影响。该软件是进度控制的一个有用工具。

    6.5.3进度控制的结果

       1. 进度的更新 进度更新指根据进行执行情况对计划进行调整。如有必要,必须把计划更新结果通知有关方面。进度更新有时需要对项目的其它计划进行调整。在有些情况,进度延迟十分严重以致需要提出新的基准进度,给下面的工作提供现实的数据。

       2. 纠正措施 指采取纠正措施使进度与项目计划一致。在时间管理领域中,纠正措施是指加速活动以确保活动能按时完成或尽可能减少延迟时间。

       3. 教训与经验 进度产生差异的原因,采取纠正措施的理由以及其它方面的经验教训应被记录下来,成为执行组织在本项目和今后其它项目的历史数据与资料。

    7章 项目成本管理

    项目成本管理由一些过程组成,要在预算下完成项目这些过程是必不可少的,图表7-1提供了这些过程的主要框架。

    以上四个过程相互影响、相互作用,有时也与外界的过程发生交互影响,根据项目的具体情况,每一过程由一人或数人或小组完成,在项目的每个阶段,上述过程至少出现一次。 

    以上过程是分开陈述且有明确界线的,实际上这些过程可能是重选的,相互作用的,对此我们不作详细讨论。

    项目成本管理主要与完成活动所需资源成本有关。然而,项目成本管理也考虑决策对项目产品的使用成本的影响。

    例如:减少设计方案的次数可减少产品的成本,但却增加了今后顾客的使用成本,这个广义的项目成本叫项目的生命周期成本。

    在许多应用领域,未来财务状况的预测和分析是在项目成本管理之外进行的。但有些场合,预测和分析的内容也包括在成本管理范畴,此时就得使用投资收益、有时间价值的现金流、回收期等技巧。

    项目成本管理还应考虑项目相关方对项目信息的需求--不同的相关方在不同时间以不同方式对项目成本进行度量。

    当项目成本控制与奖励挂钩时,就应分别估计和预算可控成本和不可控成本,以确保奖励能真正反映业绩。


       某些项目,特别是小项目,资源的计划、成本的估算和成本预算三者紧密相连,可把这些过程视为一个过程处理(例如,当这些过程可由一个人在短时间内完成时)。下面讨论中我们还是把这些过程分开讨论,不同的过程使用的工具和方法是不同的。

    7.1资源计划

    资源计划是确定为完成项目各活动需什么资源(人、设备、材料)和这些资源的数量。资源计划必然与成本估计紧密相关(见节7.2)。

    例如:

     建筑工程队需熟悉当地建筑方面的法规,若利用当地劳力,这些法规往往可以通过利用当地劳力获得而不需增加其它费用。若当地劳动中缺乏有专门建筑技术人才时,则获得当地建筑法规的最有效方法是雇用一名咨询人员,但这需要增加成本。

     汽车设计小组应熟悉最新的汽车装配技术,这必要知识也许得通过雇用一位咨询者,或派出一位设计人员去参加关于机器人的研讨会或吸纳某制造专家作为小组成员才能获得。

    7.1.1资源计划过程的输入

    1. 工作分解结构 工作分解结构(WBS,见节5.3.3.1)确认了项目的各项工作(完成这些工作需要资源)。WBS是资源计划过程的最基本的输入。为确保控制恰当,其它计划过程的相关结果应通过WBS作为输入。

    2. 历史资料 先前项目中类似工作需什么样资源的资料应被利用。 

    3. 范围的陈述 范围的陈述(见节5.2.3.1)饮食了项目的合理性论述和项目的目标,这两者均应在资源计划中考虑。

    4. 资源库的描述 对资源计划而言,应知道什么资源(人、设备、材料)可供利用。资源库里资源的详尽程度前后不同,例如,在一个工程设计项目的早期,资源库也许是"许多初级与高级工程师",然而,在同一工程的后期,资源库限定对这个项目有一定了解的工程师,这些工程师参加过早期的工作。

    5. 组织策略 在资源计划过程中,必须考虑执行组织关于人员或设备的租与购买方面策略。

    7.1.2资料计划的工具与方法

    1.专家判断 需要用专家判断的方法对本过程的输入进行评估。这样的专家应具有专业知识和受过专门训练,可以从许多途径获得:

     执行组织的其它部门

     咨询专家

     专业技术协会

     工业集团

    2.替代方案的确认 替代方案的确认见节5.2.2.3的讨论

    7.1.3资源计划过程的输出结果

    1.资源的需求 资源计划过程的输入出就是要讲清楚;对WBS结构下的每一工作需要什么资源以及资源的数量。这些资源可以通过人员引进或采购予以解决(见第12章)。

    7.2成本估计

    成本估计涉及计算完成项目所需各资源成本的近似值。

    当一个项目按合同进行时,应区分成本估计和定价这两不同意义的词。成本估计涉及的是对可能数量结果的估计--执行组织为提供产品或服务的化费是多少。而定价是一个商业决策--执行组织为它提供的产品或服务索取多少费用,而成本估计只是定价要考虑的因素之一。

    成本估计包括确认和考虑各种不同的成本替代议程。例如,在许多应用领域,在设计阶段增加额外工作量可减少生产阶段的成本。成本估计过程必须考虑增加的设计工作所多化的成本能否被以后的节省所抵消。

    7.2.1成本过程输入

    1WBS结构 WBS结构图见节5.3.3.1,结构图可用于成本估计以及确保所有工作均一一被估计成本了。

    2.资源需求 资源需求见节7.1.3.1

    3.资源单价 做成本估计的个人和小组必须知道每种资料单价(例如:每小时人员费用,单位体积材料价格)以计算项目成本。如果实际单价不知道,那么必须要估计单价本身。

    4.活动时间估计 活动时间估计(见节6.3)会影响项目成本估计,项目预算中包括财务费用(例如由利息引起的财务费用)。

    5.历史资料 许多有关资源成本的信息可从以下一些来源获得:

     项目档案--项目的一个或数个组织可能保留有先前项目的一些记录,这些记录相当详尽可用以成本估计。在一些应用领域,个别小组成员也许保留这样的纪录。

     商业性的成本估计数据库--历史数据经常可从市场买得到。

     项目团队知识--项目团队的个别成员也许记得先前的实际数或估计数,这样的信息资料也是有用的,但可靠性通常比档案结果要低得多。

    6.会计科目表 会计科目表是一个组织机构在总帐系统中使用的用于报告该组织财务状况的一套代码。在项目成本估计中,应把不同成本对应到不同科目上。

    7.2.2成本估计的工具和方法

    1.类比估计 类比估计是用先前类似项目的实际数据作为估计现在项目的基础。这种估计法适用于早期的成本估计,因为此时有关项目仅有少量消息可供利用。类比估计是专家判断的一种形式(见节7.1.2.1)类比估计是化费较少的一种方法,但精确性也较差。以下情况下类比估计是可靠的:(a)先前的项目不仅在表面上且在实质上和当前项目是类同的(b)作估计的个人或小组具有必要经验。

    2.参数建模 参数建模是把项目的些特征作为参数,通过建立一个数学模型预测项目成本。模型可简单(居民住房成本是以每平方尺的居住面积的成本作为参数)也可复杂(软件研制的模型涉及13个独立参数因子,每个因子有5~7子因子)。

    参数建模的成本和可靠性各不相同,参数建模法在下列情况下是可靠的:

     a) 用来建模的历史数据是精确的

     (b) 用来建模的参数容易定量化

     (c) 模型对大型项目适用,也对小型项目适用。

    3.累加估计 该技巧涉及单个工作的逐个估计,然后累加得到项目成本的总计。

    累加估计的成本和精度取决于单个工作的大小:工作划得小,则成本增加,精确性也增加。项目管理队伍必须在精确性和成本间做权衡。

    4.计算工具 有一些项目管理软件被广泛利用于成本控制。这些软件可简化上述几种方法,便于对许多成本方案的迅速考虑。

    7.2.3 成本估计的结果

    1.成本估计 成本估计是项目各活动所需资源的成本的定量估算,这些估算可以简略或详细形式表示。

    对项目所需的所有资源的成本均需加以估计,这包括(但不局限于)劳力、材料和其它内容(如考虑通货膨胀或成本余地)

    成本通常以现金单位表达(如元,法朗,美元等),以便进行项目内外的比较,也可用人*天或人*小时这样的单位(除非这样做要混淆项目成本,例不能区分具有不同成本的资源)。为便于成本的管理控制,有时成本估计要用复合单位。

    成本估计是一个不断优化的过程。随着项目的进展和相关详细资料的不断出现,应该对原有成本估计做相应的修正,在有些应用项目中提出了何时应修正成本估计,估计应达什么样精确度。例如:AACE已经确认在工程建筑成本估计的五个精度等级:数量化、粗略估计、初步估计、精确估计和成本控制。

    2.详细说明 成本估计的详细说明应该包括:

     工作范围的描述 这通常可由参考WBS获得。

     对估计的基础作确认,即确认估计是合理的,说明估计是怎样作出的。

     确认为成本估计所作的任何假设的合理性

     可能结果用一个范围表示。

    例如 $10000±$1000表示:估计成本在$9000$11000之间。不同应用领域细节的总量和种类也不同。留下甚至是粗糙的注释也常被证明是有价值的因为它能提供如何估算成本的一个较好的说明。

    3.成本管理计划 成本管理计划描述当实际成本与计划成本发生差异时如何进行管理(差异程度不同则管理力度也不同)。一个成本管理计划可以是高度详细或粗框架的;可以是正规的也可非正规的;这些取决于与项目相关人员的需要。项目管理计划是整个项目计划的一个辅助部分(在节4.1.3.1讨论)。

    7.3成本预算

      成本预算是把估算的总成本分配到各个工作细目,建立基准成本以衡量项目执行情况。

    7.3.1 成本预算的输入

    1. 成本估计 成本估计见节7.2.3.1

    2. 工作分析结构 工作分析结构(见节5.3.3.1)确认了项目的细目,而成本要分配到这些工作中
    去。

    3. 项目进度 项目进度(见节6.4.3.1)包括了项目细目的计划开始日期和预计结束日期。为了将成本分配到时间区间,进度信息是不可缺少的。

    7.3.2 成本预算的工具和方法

    1.成本估计的工具和技巧 在节7.2.2项目成本估算中所用的工具和方法同样适用于编制各项工作成本的预算。

    7.3.3 成本预算所得输出结果

    1.基准成本 基准成本是以时间为自变量的预算,被用于度量和监督项目执行成本。把预计成本按时间累加便为基准成本,可用S曲线表示(见图7-2所示)。

    许多项目(尤其大项目)可有多重基准成本以衡量成本的不同方面。例如,一个费用计划或现金流量预测是衡量支付的基准成本。

    7.4 成本控制

    成本控制与下列内容有关 (a)影响那些会使基准成本发生改变的因素朝有利方向改变 (b) 识别已经偏离基准成本 (c)对实际发生的成本改变进行管理。

    成本控制包括:

     监督成本执行情况以及对发现实际成本与计划的偏离。

     要把一些合理的改变包括在基准成本中。

     防止不正确的、不合理的、未经许可的改变包括在基准成本中。

     把合理的改变通知项目的涉及方。

    成本控制包括寻找产生正负偏差的原因。成本控制必须和其它控制过程结合(范围控制、进度控制、质量控制和其它(见节4.3))。例如,对成本偏离采取不恰当反应常会引起项目的质量或进度问题或增大风险。

    7.4.1 成本控制的输出

    1.基准成本线 基准成本线见节7.3.3.1

    2.执行报告 执行报告(见节10.3.3.1的讨论)提供了项目实施过程中成本方面的信息,例如,超预算的是哪些工作,仍在预算范围内的是哪些工作。执行报告可提醒项目团队将来可能会发生的问题。

    3.改变的要求 有关改变的要求可以有多种形式--口头或书面,直接或间接的,组织外部要求的或内部提出的,强制规定的或可选择的。实现这些改变可能要增加或减少预算。

    4.成本管理计划 见节7.2.3.3图片

    7.4.2 成本控制的工具和方法

    1.成本改变控制系统 一成本改变控制系统规定了改变基准成本的一些步骤,它包括一些书面工作、跟踪系统和经许可的可改变的成本水平。成本改变控制系统应和整体改变控制系统相结合(见节4.3讨论)。

    2.评估执行情况 评估执行情况技巧(见节10.3.2讨论)帮助估计已发生的偏离的程度。盈余量分析(见节10.3.2.4)对成本控制特别有用。成本控制的一个重要内容是确定什么原因引起偏差以及决定是否需要采取纠正措施。

    3.原计划的修改 很少项目精确按计划进行,可预见的改变可能需要对原成本估计进行修正或用其它方法估计成本。 

    4.计算工具 一些管理软件经常被用以成本控制,可进行计划成本与实际成本间的对比以及预测成本改变的后果。

    7.4.3 成本控制的输出

    1.原成本估计的修正 修改原有成本数据并通知与项目有关的涉及方。修改成本估计可能要求对整个项目计划进行调整。

    2.预算修改 预算修改是一种类形的成本修改。预算修改是对原基准成本的更改,这些数字通常在范围改变时作修改的。有时成本偏差是如些之大以至于重新制订基准成本显得必要,以便对以一步执行提供一个现实的基准成本。

    3.纠正措施 指采取措施使项目执行情况回到项目计划。

    4.完成项目所需成本估计 完成项目所需成本估计(EAC)是根据项目执行的实际执行情况为基础,对整个项目成本的一个预测。最常见的EAC有以下几种:

     EAC=实际已发生成本+对剩余的项目预算(但一般用成本执行因子对原预算进行修正见节10.3.2.4),在项目现在的偏差可视为将来偏差时,这种方法通常被利用。

     EAC=实际已发生成本+对剩余项目的一个新估计值。当过去的执行情况表明先前的成本假设有根本缺陷或由于条件改变而不再适用新的情况时,这种方法最为常见。

     EAC=实际已发生成本+剩余原预算。当现有偏差被认为是不正常的(由偶然因素引起)项目管理小组认为类似偏差不会发生时,用这种方法最为常见。

    不同的工作可选用上述方法中一种。

    5.教训 应记录下产生偏差的原因、采取纠正措施的理由和其它的成本控制方面教训,这样记录下来的教训便成为这个项目和执行组织其他项目历史数据库的一部分。

    8章 项目质量管理

    项目质量管理包含一些程序,它要求保证该项目能够兑现它的关于满足各种需求的承诺。它包括"在质量体系中,与决定质量工作的策略、目标和责任的全部管理功能有关的各种活动,并通过诸如质量计划、质量保证和质量提高等手段来完成这些活动"[1]。图8-1提供了下述主要项目质量管理过程总览表:

    这些工作程序互有影响,并且与其它知识领域中的程序之间也存在相互影响。依据项目的需要,每道程序都可能包含一个或更多的个人或由团队的努力。在每个项目阶段中,每道程序通常都会至少经历一次。

    虽然在这里列出的程序如同划分明确的独立要素,但实践中它们可能会以某些没有在此详述的方式部分重合或相互影响。工作程序的相互作用在第三章《项目管理程序》中有详述。

    这一部分论述的质量管理的基本方案旨在与国际质量标准化组织在ISO9000和ISO10000质量体系标准与指南中提出的方案相一致。同时,这种普遍性的方案应该与以下二者相适应:(a)专门性的质量管理方案,如戴明(Deming)、宋兰(Juran)、格罗斯比(Goosby)及其他人推荐的方案;(b)非专门性的方案,如整体质量管理(TQM),可持续发展等等。

    项目质量管理必须兼顾项目管理和项目生产。在任何一方面未满足质量要求都可能导致对部分或全部的项目相关人员产生严重的负面效果。例如:

     通过项目小组的超量工作来满足客户的要求,可能产生以不断上升的雇员跳槽率为形式的负面效果。

     通过加速完成列入计划的质量检验工作来满足项目进度计划目标,则当错误因未被发现而放过时,就可能产生负面效果。

    质量是"一个实体的性能总和,它可以凭借自己的能力去满足对它的明示或暗示的需求"[2]。在项目管理中,质量管理的既定方向就是通过项目范围界定管理体制(第五章中论述),必须将暗示的需求变为明示需求的必要性。

    项目管理小组必须注意,不要把质量与等级相混淆。等级是"一种具有相同使用功能,不同质量要求的实体的类别或级别"[3]。质量低通常是个问题,级别低就可能不是。例如,一个软件产品可能是高质量(没有明显问题,具备可读性较强的用户手册),低等级(数量有限的功能特点),或者是低质量(问题多,用户文件组织混乱),高等级(无数的功能特点)。决定和传达质量与等级的要求层次是项目经理和项目管理小组的责任。 图8-1项目质量管理总览

    项目质量管理

     

    项目管理小组还应该注意,现代的质量管理是现代的项目管理的补充。例如,这两种管理原则都明确了以下几点的重要性:

     满足客户--理解、管理和引导需求,从而达到或超过客户的期望。这就要求项目产品与说明书配合一致(项目必须生产它所承诺生产的产品),并且适于实用(项目提供的产品或服务必须能满足实际需要)。

     通过检验防止错误--避免错误的费用通常比纠正它们低得多。

     管理责任--成功需要团队全体成员的合作,但提供成功所需要的资源则是管理工作的职责。

     各阶段的程序--戴明(Deming)和其他人所描述的那种重复的"计划-执行-检验-行动"工作循环同第三章《项目管理程序》中记述的"不同阶段和程序之间的配合"是高度一致的。

    此外,由执行组织主动采取的质量提高措施(例如,整体质量管理,可持续发展,等等)既能够提高项目管理的质量,也能提高项目的生产质量。

    然而,项目管理小组必须明确重要的一点--项目的暂时性特征意味着在产品质量提高上的投资,尤其是缺陷的预防和鉴定评估,常常有赖于执行组织的支持,因为这种投资的效果可能在项目结束以后才得以体现。

    8.1质量计划

    质量计划包括确定哪种质量标准适合该项目并决定如何达到这些标准。在项目计划中(见3.3.2部分,规划程序),它是程序推进的主要推动力之一,应当有规律地执行并与其他项目计划程序并行。例如,对管理质量的要求可能是成本或进度计划的调节,对生产质量的要求则可能是对确定问题的详尽的风险分析。比ISO9000国际质量体系的发展更进一步的是,这里作为质量计划所描述的工作是作为质量保证的一部分而进行广泛讨论的。

    这里所讨论的质量计划技巧是在项目中最常用的那一部分。还有许多其他的质量计划技巧可能在一些特定的项目或者一些应用领域中有用。

    项目小组还应注意现代质量管理中的一项基本原则--质量在计划中确定,而非在检验中确定。 

    8.1.1 质量计划的输入

    1.质量策略。质量策略是"一个注重质量的组织的所有努力和决策,通常称为顶级管理"[4]。执行组织的质量策略经常能给项目所采用。然而,如果执行组织忽略了正式的质量策略,或者如果项目包含了多重的执行组织(合资企业),项目管理小组就需要专为这个项目而开发一次质量策略。

    不管质量策略的因由是什么,项目管理小组有责任确保项目相关人员充分意识到它。(例如:通过适当的信息发布,见10.2部分)。

    2. 范围阐述。范围阐述(见5.2.3.1部分)是对质量计划的主要输入,因为它是揭示主要的子项目和项目目标的书面文讲,后者界定了重要的项目相关人员的需求。

    3. 产品说明。虽然产品说明的因素(见5.1.1.1部分)可以在范围阐述中加以具体化,产品说明通常仍需阐明技术要点的细节和其他可能影响质量计划的因素。

    4. 标准和规则。项目管理小组必须考虑任何适用于特定领域的专门标准和规则。

    5. 其他程序的输出。除了范围阐述和产品说明,在其他知识领域中的程序也可能产生一定的结果,应当作为质量计划的一部分加以考虑。例如,采购计划(见12.1部分),可以确定应当在所有质量管理计划中反映的承包商的质量要求。


    8.1.2质量计划的手段和技巧

    1. 效益/成本分析。质量计划程序必须考虑效益/成本平衡,(见5.2.2.2部分)。达到质量标准,首先就是减少了返工,这就意味着高效率,低成本,以及提高项目相关人员的满意度。达到质量标准的首要成本是与项目质量管理活动有关的费用。毫无疑问,质量管理的原理表明,效益比成本更重要。

    2. 基本水平标准。基本水平标准包括将实际的或计划中的项目实施情况与其他项目的实施情况相比较,从而得出提高水平的思路,并提供检测项目绩效的标准。其他项目可能在执行组织的工作范围之内,也可能在执行组织的工作范围之外;可能属于同一应用领域,也可能属于别的领域。 

    3. 流程图。流程图是显示系统中各要素之间的相互关系的图表。在质量管理中常用的流程图技巧包括:

     因果图,又称Ishikawa图,用于说明各种直接原因和间接原因与所产生的潜在问题和影响之间的关系。图8-2是一种常用的因-果图示例。

     系统或程序流程图,用于显示一个系统中各组成要素之间的相互关系。图8-3是设计复查程序流程图示例。

    流程图能够帮助项目小组预测可能发生哪些质量问题,在哪个环节发生,因而有助于使解决问题手段更为高明。

    4. 试验设计。试验设计是一种分析技巧,它有助于鉴定哪些变量对整个项目的成果产生最大的影响。这种技巧最常应用于项目生产的产品(例如,汽车设计者可能希望决定哪种刹车与轮胎的组合能具有最令人满意的运行特性,而成本又比较合理)。

    但是,它也可应用于项目管理成果,如成本和进度的平衡。例如,高级发动机比低级发动机成本高,但它能用较短的时间完成所分配的工作。一项设计适当的"试验"(在此例中,就是计算项目中各种高级、低级发动机组合装置的成本和使用寿命),常常可以使人从数量有限的几种相关的情况中得出解决问题的正确决策。

    8.1.3质量计划中的输出

    1. 质量管理计划。质量管理计划应说明项目管理小组如何具体执行它的质量策略。在ISO9000的术语中,对质量体系的描述是:"组织结构、责任、工序、工作过程、及具体执行质量管理所需的资源"[5]

    质量管理计划为整个项目计划提供了输入资源(见4.1部分 项目规划发展),并必须兼顾项目的质量控制、质量保证和质量提高。

    质量管理计划可以是正式的或非正式的,高度细节化的或框架概括型的,皆以项目的需要而定。

    2. 操作性定义。操作性定义是用非常专业化的术描述各项操作规程的含义,以及如何通过质量控制程序对它们进行检测。例如,仅仅把满足计划进度时间作为管理质量的检测标准是不够的,项目管理小组还应指出是否每项工作都应准时开始,抑或只要准时结束即可;是否要检测个人的工作,抑或仅仅对特定的子项目进行检测。如果确定了这些标准,那么哪些工作或工作报告需要检测。在一些应用领域,操作性定义又称为公制标准。

    3. 审验单。审验单是一种组织管理手段,通常是工业或专门活动中的管理手段,用以证明需要执行的一系列步骤是否已经得到贯彻实施。审验单可以很简单,也可以很复杂。常用的语句有命令式("完成工作!")或询问式("你完成这项工作了吗?")。许多组织提供标准化审验单,以确保对常规工作的要求保持前后一致。在某些应用领域中,审验单还会由专业协会或商业服务机构提供。

    4. 对其他程序的输入。质量计划程序可以在其他领域提出更长远的工作要求。

    8.2质量保证

    质量保证是"为了提供信用,证明项目将会达到有关质量标准,而在质量体系中开展的有计划、有组织的工作活动"[6]。它贯穿于整个项目的始终。比ISO9000质量体系的发展更进一步的是,在质量计划部分所描述的活动从广义上说,也是质量保证的组成部分。

    质量保证通常由质量保证部门或有类似名称的组织单位提供,但也不都是如此。

    这种保证可以向项目管理小组和执行组织提供(内部质量保证),或者向客户和其他没有介入项目工作的人员提供(外部质量保证)。

    8.2.1质量保证的输入

    1. 质量管理计划。质量管理计划见8.1.3.2部分。

    2. 质量控制检测结果。质量控制检测结果是对质量控制的检测和测试以比较分析的形式作出的报告。

    3. 操作性定义。操作性定义见8.1.3.2部分。

    8.2.2质量保证的手段和技巧

    1. 质量计划的手段和技巧。在8.1.2部分中阐述的质量计划手段和技巧在质量保证中同样能适用。

    2. 质量审查。质量审查是对其他质量管理活动的结构性复查。质量审查的目的是确定所得到的经验教训,从而提高执行组织对这个项目或其他项目的执行水平。质量审查可以是有进度计划的或随机的;可以由训练有素的内部审计师进行,或者由第三方如质量体系注册代理人进行。 

    8.2.3质量保证的输出

    1.质量提高。质量提高包括采取措施提高项目的效益和效率,为项目相关人员提供更多的利益。在大多数情况下,完成提高质量的工作要求做好改变需求或采取纠正措施的准备,并按照整体变化控制的程序执行,见4.3部分。

    8.3质量控制

    质量控制包括监控特定的项目成果,以判定它们是否符合有关的质量标准,并找出方法消除造成项目成果不令人满意的原因。它应当贯穿于项目执行的全过程。项目成果包括生产成果如阶段工作报告和管理成果如成本和进度的执行。质量控制通常由质量控制部门或有类似名称的组织单位执行,当然并不是都是如此。

    项目管理小组应当具备质量控制统计方面的实际操作知识,尤其是抽样调查和可行性调查,这可以帮助他们评估质量控制成果。在其他课题中,他们应区分:

     预防(不让错误进入项目程序)和检验(不让错误进入客户手中)。

     静态调查(其结果要么一致,要么不一致)和动态调查(其结果依据衡量一致性程度的一种持续性标准而评估)。

     确定因素(非常事件)和随机因素(正态过程分布)。

     误差范围(如果其结果落入误差范围所界定的范围内,那么这个结果就是可接受的)和控制界限(如果其成果落入控制界限内。那么该项目也在控制之中。)

    8.3.1质量控制的输入

    1. 项目成果。项目成果(见4.2.3.1部分)包括程序运行结果和生产成果。关于计划的或预测的成果信息(来源于项目计划)应当同有关实际成果的信息一起被利用。 

    2. 质量管理计划。质量管理计划见8.1.3.1部分。

    3. 操作性定义。操作性定义见8.1.3.2部分。

    4. 审验单。审验单见8.1.3.3部分。

    8.3.2质量控制的手段和技巧

    1. 检验。检验包括测量、检查和测试等活动,目的是确定项目成果是否与要求相一致。检验可以在任何管理层次中开展(例如,一个单项活动的结果和整个项目的最后成果都可以检验)。检验有各种名称:复查、产品复查、审查及回顾;在一些应用领域中,这些名称有范围较窄的专门含义。 

    2. 控制表。控制表是根据时间推移对程序运行结果的一种图表展示。常用于判断程序是否"在控制中"进行(例如,程序运行结果中的差异是否因随机变量所产生?是否必须对突发事件的原因查清并纠正?)。当一个程序在控制之中时,不应对它进行调整。这个程序可能为了得到改进而有所变动,但只要它在控制范围之中,就不应人为地去调整它。

    控制表可以用来监控各种类型的变量的输出。尽管控制表常被用于跟踪重复性的活动,诸如生产事务,它还可以用于监控成本和进度的变动、容量和范围变化的频率,项目文件中的错误,或者其他管理结果,以便判断"项目管理程序"是否在控制之中。图8-4即为项目进度执行控制表。

    3. 排列图。排列图是一种直方图,由事件发生的频率组织而成,用以显示多少成果是产生于已确定的各种类型的原因的(见图8-5)。等级序列是用来指导纠错行动的--项目小组应首先采取措施去解决导致最多缺陷的问题。排列图与帕累特法则的观点有联系,后者认为相应的少数原因会导致大量的问题或缺陷。

    4. 抽样调查统计。抽样调查统计包括抽取总体中的一个部分进行检验(例如,从一份包括75张设计图纸的清单中随机抽取10张)。适当的抽样调查往往能降低质量控制成本。关于抽样调查统计有大量书面资料和规定。在一些应用领域,熟悉各种抽样调查技巧对于项目管理小组是十分必要的。

    5. 流程图。见8.1.2.3部分。质量控制中运用流程图有助于分析问题是如何发生的。

    6. 趋势分析。趋势分析指运用数字技巧,依据过去的成果预测将来的产品。趋势分析常用来监测: 

     技术上的绩效--有多少错误和缺陷已被指出,有多少仍未纠正。

     成本和进度绩效--每个阶段有多少活动的完成有明显的变动。

    8.3.3质量控制的输出

    1. 质量提高。见8.2.3.1部分。

    2. 可接受的决定。经检验后的工作结果或被接受,或被拒绝。被拒绝的工作成果可能需要返工(见8.3.3.3部分)。

    3. 返工。返工是将有缺陷的、不符合要求的产品变为符合要求和设计规格的产品的行为。返工,尤其是预料之外的返工,在大多数应用领域中是导致项目延误的常见原因。项目小组应当尽一切努力减少返工。

    4. 完成后的审验单。见8.1.3.3部分。在使用审验单时,完成之后的审验单应为项目报告的组成部分。

    5. 程序的调整。程序的调整指作为质量检测结果而随时进行的纠错和预防行为。有些情况下,程序调整可能需要依据整体变化控制(见4.3部分)的程序来实行

    9章 项目人力资源管理

      项目人力资源管理包括一些程序,要求充分发挥参与项目的人员的作用,包括所有与项目有关的人员--项目负责人、客户、为项目作出贡献的个人及其他在2.2部分阐述的人员。图9-1提供了以下主要程序的总览表:

    这些程序互相之间有影响,并且同其他知识领域中的程序相互影响。依据项目的需要,每道程序可能都包含一个或更多的个人或团队的努力。虽然这里列出的程序如同界限分明的一个个独立要素,实际上它们可能以某些没有在此详述的方式相互重合或相互影响。程序的相互影响在第三章《项目管理程序》中有详述。

    实际操作过程中,对于处理人际关系有大量的书面文件资料规定,其中包括:

     领导沟通、协商及其他在2.4部分阐述的关键性整体管理技巧。

     授权、激励士气、指导、忠告及其他与处理个人关系有关的主题。

     团队建设、解决冲突及其他与处理团队关系有关的主题。

     绩效评定、招聘、留用、劳工关系,健康与安全规则,及其他与管理人力资源功能有关的主题。

    这里绝大多数的资料直接适用于领导和管理项目成员,而项目经理和项目管理小组应当对此十分熟悉。他们还必须敏锐地认识到如何将这些知识在项目中加以运用。例如:

     项目的暂时性特征意味着个人之间和组织之间的关系总体而言是既短又新的。项目管理小组必须仔细选择适应这种短暂关系的管理技巧。

     在项目生命周期中,项目相关人员的数量和特点经常会随着项目从一个阶段进入另一个阶段而有所改变,结果使得在一个阶段中非常有效的管理技巧到了另一个阶段会失去效果。项目管理小组必须注意选用适合当前需求的管理技巧。 

     人力资源行政管理工作一般不是项目管理小组的直接责任。但是,为了深化管理力度,小组必须对行政管理的必要性有足够的重视。

    9.1组织规划

    组织规划包括确定、书面计划并分配项目任务,职责以及报告关系。任务、职责和报告关系可以分配到个人或团队。这些个人和团队可能是执行项目的组织的组成部分,也可能是项目组织外部的人员。内部团队通常和专职部门有联系。如工程部,市场部或会计部。

    在大多数项目中,组织规划主要作为项目最初阶段的一部分。但是,这一程序的结果应当在项目全过程中经常性地复查,以保证它的持续适用性。如果最初的组织规划不再有效,就应当立即修正。

    组织规划总是和沟通规划(见10.1部分)紧密联系,因为项目组织结构会对项目的沟通需求产生主要影响。

    9.1.1组织规划的输入

    1.项目层次。项目层次通常有三个方面。

     组织层面--不同的组织单位之间正式的或非正式的报告关系。组织层面可能十分复杂,也可能非常简单。例如,建设一个复杂的电讯系统可能需要花费几年时间去协调无数分包商的关系,而修正一个要装在简单地点的系统中的程序错误只需要通知用户和工作人员完成工作。

     技术层面--不同的技术规程之间的正式或非正式的报告关系。技术层面既存在于项目各阶段之中,(例如,土木工程师提出的设计方案必须与结构工程师提出的上层构造方案相匹配),也存在于项目各阶段之间(例如,当自动系统设计小组将它的工作结果交付给具有交通工具制造能力的生产小组时)。

     人际层面--在项目中工作的不同个人之间的正式的或非正式的报告关系。

    这些层面往往同时存在,例如,当一个设计公司雇用的建筑师向建筑承包商的项目管理小组解释关键性的设计思路,而该项目小组与他并无直接关系时,上述各个层面就同时存在。

    2. 人员需求。人员需求界定了在什么样的时间范围内,对什么样的个人和团体,要求具备什么样的技能。人员需求是在资源规划过程中决定的整体资源需求中的一部分(见7.1部分)。

    3. 制约因素。制约因素是限制项目小组选择自由的因素。一个项目的组织选择可以从很多方面加以制约。常用的可以制约团队如何组织的因素包括以下几点(当然不仅限于此):

     执行组织的组织结构--一个以强矩阵型为基础结构的组织,意味着它的项目经理承担着与此相关重大责任,比以弱矩阵型为基础结构的组织中的项目经理所担负的责任更为重大(见2.3.3关于组织结构更详细的阐述)。

     集体协商条款--与工会或其他雇员组织达成的合同条款可能会要求特定的任务或报告关系(实质上,雇员组织也是项目相关人员)。

     项目管理小组的偏爱--如果项目管理小组在过去运用某些特定的管理结构取得过成功,他们就可能在将来提倡使用类似的结构。

     预期的人员分配--项目的组织常受专业人员的技术和能力的影响。

    9.1.2管理规划的手段和技巧

    1. 样板法。虽然每个项目都是独一无二的,但大多数项目会在某种程度上与其他项目类似。运用一个类似项目的任务或职责的定义或报告关系能有助于加快组织规划程序的运行。 

    2. 人力资源经验。许多组织有各种政策指导和程序,在组织规划的各方面为项目管理小组提供帮助。例如,一个把经理看作"教练"的组织很可能拥有关于"教练"的任务如何执行的文件资料。

    3. 组织理论。有大量的书面规定阐述了组织能够而且应当如何构建。虽然这些书面规定中仅有一小部分是以项目组织为专门目标的,但项目管理小组仍应从总体上熟悉组织理论的主旨,以便更好地满足项目的需要。

    4. 相关人员分析。各个相关人员的需求在应得到仔细分析,保证他们的要求能得到满足。10.1.2.1部分对相关人员分析有更详细的阐述。

    9.1.3组织规划的输出

    1. 任务和职责的分配。项目任务(谁做什么)和职责(谁决定什么)必须分配到合适的项目相关人员。任务和职责可能会随时间而改变。大多数任务和职责将分配给积极参与项目工作的有关人员,例如项目经理、项目管理小组的其他成员,以及为项目作出贡献的个人。

    项目经理的任务和职责在多数项目中通常是一致的,但在不同的应用领域会有明显改变。

    项目任务和职责应当与项目的范围界定紧密相连。有一种职责分配矩阵模型(或称RAM,图9-2)常用于此目的。在大型项目中,RAM可用于各个项目层次。例如,一个应用于项目层次的RAM可以界定每一个工作障碍结构因素由哪个团队或单位负责;而应用于项目低层次的RAM用于在团队中将特定活动的任务和职责分配到专门人员。

       2. 人员管理计划。人员管理计划阐述人力资源在何时,以何种方式加入和离开项目小组。人员计划可能是正式的,也可能是非正式的,可能是十分详细的,也可能是框架概括型的,皆依项目的需要而定。它是整体项目计划中的辅助因素(见4.1部份 项目规划发展)。

    人员管理计划常包括资源直方图,如图9-3。

    应特别注意项目小组成员(个人或团体)不再为项目所需要时,他们是如何解散的。适当的再分配程序可以是:

     通过减少或消除为了填补两次再分配之间的时间空档而"制造工作"的趋势来降低成本。

     通过降低或消除对未来就业机会的不确定心理来鼓舞士气。

    3. 组织表。组织表是项目报告关系的图表展示。它可以是正式的或非正式的,十分详细的或框架概括型的,依据项目的需要而定。例如,一份关于三至四人的内部服务项目组织表不可能像一份关于三千人的原子能工厂的组织表那么严密而详细。
    项目分层结构(OBS)是一种特殊类型的组织表,它显示了哪些组织单位负责哪些工作。

    4. 详细说明。组织规划的详细说明随应用领域和项目规模的不同而改变。通常作为详细说明而提供的信息包括以下几点(当然不限于此):

     组织的影响力--哪些选择被组织工作以这种方式排除。

     职务说明--写明职务所需的技能、职员、知识、权力、物质环境,以及其它与该职务有关的素质。又称职位说明。

     培训要求--如果并不期望供分配的人员具备项目所需要的技能,则需要把培训技能作为项目的一部分。

    9.2人员组织

      人员组织包括得到所需的人力资源(个人或团队),将其分配到项目中工作。在大多数情况下,可能无法得到"最佳"的人力资源,但项目管理小组必须注意保证所利用的人力资源能符合项目的要求。

    9.2.1人员组织的输入

    1. 人员配置管理计划。人员配置管理计划在9.1.3.2中阐述。它包括了项目人员配置的要求,见9.1.1.2部分。

    2. 人员组成说明,当项目管理小组能够影响或指导人员分配时,它必须考虑可能利用的人员的素质。主要以考虑以下几点:

     工作经验--那些个人或团队以前从事过类似的或相关的工作吗?他们做得出色吗?

     个人兴趣--那些个人或团体对从事这个项目感兴趣吗?

     个性--那些个人或团体对于以团队合作的方式工作是否感兴趣?

     人员利用--能否在必要的时间内得到项目最需要的个人或团体?

    3. 吸收经验。参与项目的一个或多个组织可能拥有有关的策略,方法或指导人员分配的程序。当这些经验存在时,它们就成为人员组织程序的制约因素。

    9.2.2人员组织手段和技巧

    1. 协商。人员分配在多数项目中必须通过协商进行。例如,项目管理小组可能需要与以下人员协商:

     负有相应职责的部门经理,目的是保证在必要的时间限度内为项目组织到具有适当技能的工作 人员。

     执行组织中的其他项目管理小组,目的是适当分配难得或特殊的人力资源。

    管理小组的影响技巧(见2.9.5部分,组织中的影响)在人员分配协商中扮演着十分重要的角色,如同组织工作中的政治手段的重要性一样。例如,对一个部门经理的奖励可以是基于他对人员的使用情况。这会对经理形成一种激励,促使他们去使用那些有专长的人员,虽然他们不一定胜任项目的所有工作。

    2. 预先分配。在某些情况下,可以预先将人员分配到项目中。这些情况常常是:(1)该项目是完成一项提议的结果,而使用特定的人员是该项提议允诺的一部分,(2)该项目是一个内部服务项目,且人员的分配已在项目安排表中有规定。

    3. 临时雇用。项目采购管理(见第12章)可用于开展项目工作而取得特定个人或团队的服务。当执行组织缺少内部工作人员去完成这个项目时,就需要临时雇用人员(例如,这是有意识地决定不雇用这些人员作为正式职工,或让所有具备合适技能的人员先去从事其他项目,或其他类似情况的必然结果)。

    9.2.3人员组织的输出

    1. 项目人员分配。当适当的人选被信任地分配到项目中并为之工作时,项目人员配置就完成了。依据项目的需要,项目人员可能被分配全职工作,兼职工作或其他各种类型的工作。

    2. 项目小组名单。项目小组名单罗列了所有的项目小组成员和其他关键的项目相关人员。这个名单可以是正式的或非正式的,十分详细的或框架概括型的,皆依项目的需要而定。

    9.3团队发展

    团队发展包括提高项目相关人员作为个体做出贡献的能力和提高项目小组作为团队尽其职责的能力。个人能力的提高(管理上的和技术上的)是提高团队能力的必要基础。团队的发展是项目达标能力的关键。

    当小组成员个人对部门经理和项目经理都要负责时,项目团队的发展常常是复杂的(见2.2.3部分关于组织结构模型的讨论)。对这种双重报告关系的有效管理常常是项目最重要的成功因素,而且通常是项目经理的责任。 

    尽管团队发展在第三章是作为执行程序之一的,它仍贯穿于项目全过程。

    9.3.1对团队发展的投入

    1. 项目人员配置。项目人员配置在9.2.3.1部分已有阐述。人员安排中包含了对可用于组建项目团队的个人能力和小组能力的界定。

    2. 项目规划。项目规划见4.1.3.1部分。项目规划阐明了项目小组工作的技术内容。

    3. 人员配置管理计划。见9.1.3.2部分。

    4. 绩效报告。绩效报告(见10.3.3.1部分)为项目小组提供了关于项目计划执行情况的反馈。

    5. 外界反馈。项目小组必须定期对照项目外部人员对项目绩效的期望进行自我检测。

    9.3.2团队发展的手段和技巧

    1. 团队建设活动。团队建设活动包括专门采取的管理活动和个人行动,且首要目的是提高团队绩效。许多行动,诸如在规划过程中参加无管理层小组,或为平息和处理人际冲突制定基本规则等,其间接结果都是可以提高团队绩效。团队建设可以有多种形式:从常规情形下复查会议中五分钟的议事日程,到为了增进关键性的项目相关人员之间的人际关系而设计的广泛的,地点不固定的,专业的促进关系体验。 

    在团队建设方面有大量的书面文件资料规定。项目管理小组应从总体上熟悉各种队伍建设活动。

    2. 总体管理技巧。总体管理技巧(见2.4部分)对团队发展有特殊的重要性。 

    3. 奖励和表彰体系。奖励和表彰体系是正式的管理措施,为了鼓励和促进符合项目需要的行为。 为了达到效果,这种体系必须在绩效和奖励之间建立一种清晰、明确和易于接受的联系。例如,一个因达到项目成本目标而受奖励的项目经理应当具有相当的控制人员过度配置和聘用的决策水平。

    由于执行组织的奖励和表彰体系可能并不适用于具体项目,各项目必须拥有自己的奖励和表彰体系。例如,为了达到积极有效的进度目标而加班工作的意愿应当得到奖励或表彰,但因为计划不当而需要加班工作就不应得到奖励。

    奖励和表彰体系还必须考虑文化差异。例如,在一个崇尚个人主义的文化背景中,建立一个适当的集体奖励体系可能会十分困难。

    4. 人员安排。人员包括将大多数积极工作的项目小组中的所有(或几乎所有)成员安排在同一个工作场所,以提高他们作为一个团队执行项目的能力。人员安排广泛应用于较大型的项目中,在较小型的项目中也很有效。(例如在一个"作战室"中,团队随着项目工作的进展集中工作或解散)。

    5. 人员培训。人员培训包括为了提高项目小组的技能知识和能力水平而设计的各种活动。有些作者将培训,教育和理解加以区分,但是三者之间的差别既不明显也未得到广泛认可。培训可以是正式的(例如:课堂培训,以电脑为基础的培训)或非正式的(例如:来自其他小组成员的反馈)。关于如何提供成人培训有大量书面资料。

    如果项目小组成员缺乏必要的管理和技术方面的技能,则必须将提高此类技能作为项目的一部分,或者采取一定步骤将人员重新进行适当分配。直接或间接的培训费用通常由执行组织支付。

    9.3.3团队发展的输出

    1. 绩效提高。团队发展的首要成果就是项目绩效的提高。这种提高可能来自许多资源,并能对项目绩效的许多方面产生影响。例如:

     个人技能的提高,可以使专业人员更高效地完成所分配的活动。

     团队行为的改善(如:平息和处理冲突)可以让项目小组成员将更多的精力投入技术工作。 

     个人技能或团队能力的提高可以对确定和开发完成项目工作的更好方法起到促进作用。

    2.对绩效评定的输入。项目人员通常应当向有明显的相互关系的项目组成人员的绩效评定提供输入。

    10章 沟通管理

    项目沟通管理(project communication management)包括为了确保项目信息及时适当的产生(generation)、收集(collection)、传播(dissemination)、保存(storage)和最终配置(ultimate disposition)所必须的过程。项目沟通管理把成功所必须的因素--人(people)、想法(ideas)和信息(information)之间提供了一个关键连接。涉及项目的任何人都应准备以项目"语言"(the project language)发送和接收信息并且必须理解他们以个人身份参与的沟通怎样影响整个项目。

    图10-1描述了以下几个主要过程的纲要:

    这些过程之间以及与其他领域的过程之间相互作用。如果项目需要,每个流程可以由个人、多人或团体来完成。在每个项目阶段每个过程至少发生一次。虽然在这里列举的流程是分立的阶段并具有明确定义的分界面,事实上他们互相交织、互相作用在一起。流程的相互作用在第3章项目管理过程详细地阐述。

    沟通的通用管理技术技巧(见2.4.2部分)跟项目沟通管理有关(但并不等同)。沟通是一个更宽广的课题,包括一些重要的知识体系,它特别适用于项目的唯一知识体系。并不局限适用于项目的重要知识体系。例如:

     发送者-接收者模型(sender-receiver models)--反馈环,沟通阻碍等。

     媒体选择(choice of media)--什么时候采用书面沟通和什么时候采用口头沟通。什么时候使用非正式的备忘录和什么时候使用正式的报告。

     书写文体(writing style)--主动语态和被动语态,句子结构,词汇选择等。

     陈述技巧(presentation techniques)--肢体语言(body language),视觉辅助工具的设计(design of visual ads)等。

     会议管理技巧(meeting management techniques)--准备议程表,处理冲突。



    10.1沟通计划(communication planning)

       沟通计划包括决定项目涉及人的信息和沟通需求:谁需要什么信息;什么时候需要;怎么获得。虽然所有的项目都需要沟通项目信息,但信息需求和传播方式差别很大。确认涉及人的信息需求和决定满足需求的适当方式是项目获得成功的重要因素。

       对于大多数项目,沟通计划的大部分工作作为项目前期阶段的一部分来完成。然而本过程的结果在项目进行中应时常被复查和修订(如有需要)以确保持续的应用性。沟通计划常常与组织计划(参见9.1)紧密联系在一起,因为项目的组织结构对项目沟通要求有重大影响。

    10.1.1沟通计划输入(inputs to communication planning

    1. 沟通要求。沟通要求是项目涉及人信息需求(information requirements)的总和。需求结合信息类型和格式定义。信息的类型和格式在信息的数值分析中必须的。项目资源只有通过信息个沟通才能获得扩展,信息使项目成功,缺乏沟通会导致失败。项目的资源应当花费并且仅能花费在沟通信息上。决定项目沟通通常所需要信息有:

     项目组织和项目涉及人责任关系;

     涉及项目的纪律,行政部门、专业;

     项目所需人员的推算以及应分配的位置;

     外部信息需求(例如,同媒体的沟通)。

    2. 沟通技巧。在项目的基本单位之间来回传递信息,所能使用的技术和方法可能差异很大:从简短的谈话到长期的会议;从简单的书面文件到即时查询的在线的进度表和数据库。可能影响项目沟通的技术因素有:

     信息需求的即时性--项目的成功是取决于即时通知频繁更新的信息,还是通过定期发行的报告已足够?

     技术的有效性(the availability of technology)--已到位的系统运行良好吗?还是系统要作一些变动?

     预期的项目人员配置--计划中的沟通系统是否同项目参与方的经验和知识相兼容?还是需要大量的培训和学习?

     项目工期的长短(the length of project)--现有技术在项目结束前是否已经变化以至于必须采用更新的技术?

     制约因素。制约因素是限制项目管理小组作出选择的因素。例如,如果需要大量地采购项目资源,那么处理合同的信息就需要更多考虑。当项目按照合同执行时,特定的合同条款也会影响沟通计划。

     假设因素。对计划中的目的来说,假设因素是被认为真实的确定的因素。假设通常包含一定程度的风险。他们可在本处确定,或者他们也可是风险识别过程的输出(见11.1部分)。

    10.1.2沟通计划的工具和方法(tools and techniques for communication planning

       1. 项目涉及人分析(stakeholder analysis)。为了对项目涉及人的信息需求和信息资源形成一种系统的和符合逻辑的观点以满足需求,应对多种多样项目涉及人的信息需求加以分析。(关于项目涉及人见2.2和5.1部分),此种分析应考虑那些适合于项目且能提供所需要信息的方法和技术。应注意避免在不需要的信息和不适合的技术上浪费资源。

    10.1.3沟通计划的输出

      1. 沟通管理计划(communications management plan)。沟通管理计划是一个文件,它提供:

      收集和归档的结构(a collection and filing structure),详细规定用来收集和贮存各类信息的方法。采用的过程应涵盖对以前已公布材料更新和纠正收集和发送。

      发送结构(a distribution structure),详细的规定信息(状况报告、数据、进度、技术资料等)将流向谁那里,和使用什么方法(书面报告、会议等)来发布各类信息。此种结构必须与项目组织图表(the organization chart)定义的责任和报告关系兼容。

      被发送的信息的说明,包括格式(format)、内容(content)、详细级别(level of details)、使用的协议/定义(conventions/definitions)。

      产品进度(product schedules),显示每种类型的沟通什么时候产生。

      在排定的沟通(scheduled communications)中检索信息的方法。

      随着项目的进展,修订和提炼沟通管理计划的方法。

    根据项目的需要,沟通管理计划可以是正式的或非正式的,可以是详细的或提纲式的。沟通管理计划是整个项目计划的一个附属部分。

    10.2 信息发送(information distribution)

       信息发送是指将需要的信息及时地传送给项目涉及人,它包括实施沟通管理计划以及对突发的信息请求(request for information)作出反应。

     

    10.2.1 信息发送的输入 

       1. 工作结果(work results)。工作结果在4.2.3.1部分讨论。

       2. 沟通管理计划。沟通管理计划在10.1.3.1部分讨论。

       3. 项目计划。项目计划在4.1.3.1部分讨论。

    10.2.2 信息发送的工具和方法

       1. 沟通技巧(communication skills)。沟通技巧用来交换信息。发送者有责任使信息清晰、没有歧意和完整以便接收者能正确地接收。发送者也有责任确保信息被正确地理解。接收者有责任确保完整接收和正确地理解信息。沟通有很多类型:

      书面的和口头的,耳听的和口讲的。

      内部的(项目内)和外部的(与客户、媒体、公众的沟通)。

     正式的(报告,指示等)和非正式的(备忘录,特别安排的谈话等)。 

     垂直的(组织内上下级之间)和水平的(与同级别之间)。

       2. 信息检索系统(information retrieval systems)。小组成员可通过各种方法共享信息,这样的方法包括手工案卷系统(manual filing systems)、电子文本数据库(electronic text databases)、项目管理软件,以及可以检索技术文件资料的系统(例如工程制图)。

       3. 信息发送系统(information distribution systems)。项目信息可使用多种方法发送。包括项目会议,复印文件发送,共享的网络电子数据库,传真,电子邮件,声音邮件,以及电视会议。 

    10.2.3 信息发送的输出

       1. 项目记录(project records)。项目记录可以包括信函、备忘录、报告和说明项目的文件。应尽可能适当的有组织的维护这些信息。项目小组成员常常在项目笔记本(project notebook)中维持个人记录。

    10.3执行报告(performance reporting)

      执行报告包括收集和发布执行信息,从而向项目涉及人提供为达到项目目标如何使用资源的信息。这样的过程有:

      状况报告(status reporting--描述项目当前的状况。

      进展报告(progress reporting--描述项目小组已完成的工作。

      预测--对未来项目的状况和进展作出预计。

     执行报告一般应提供范围、进度、成本、质量等信息。许多执行报告也要提供风险和采购的信息。执行报告应写得具有综合性或针对某一特例(on an exception basis)。

    10.3.1 执行报告的输入

       1. 项目计划。项目计划在4.1.3.1部分讨论。项目计划包括了各种各样用来评估项目执行的基准。

       2. 工作结果。工作结果--已全部或部分完成的子项目(deliverables);已发生或已分担的成本等--都是项目计划执行的结果(见4.2.3.1部分)。工作结果应在沟通管理计划规定的框架内汇报。工作结果中精确一致的信息对执行报告的使用价值是很重要的。

       3. 其他项目记录。有关项目记录的论述见10.2.3.1部分。除了项目计划和项目工作结果,其他项目文件中也常常包含有关项目的信息。在评估项目执行时也应考虑到这些信息。

    10.3.2执行报告的工具和方法

       1. 执行复查(performance review)。执行复查是为评估项目状况和进展而举行的会议。执行复查一般同下面讨论的一个或多个执行报告的方法一起使用。

       2. 差异分析(variance analysis)。差异分析是指把项目的实际结果与计划或预期结果作比较。最常使用的是成本和进度偏差。但是范围、质量和风险与计划之间的偏差也同样或更加重要。

       3. 趋势分析(trend analysis)。趋势分析指检查项目结果以确定执行是改进了还是恶化了。

       4. 盈余量分析(earned value analysis)。各种形式的盈余量分析是衡量执行时最常用的方法。它把范围、成本和进度等度量标准结合在一起以帮助项目管理小组评估项目执行。对每项活动而言,盈余量分析包括计算三个主要数值:

     预算,也称为排定工作的预算成本(the budgeted cost of work scheduled:BCWS),是给定期间内计划花费在某项活动上的已被批准的成本估计部分。

     实际成本,也称之为已执行工作的实际成本(the actual cost of work performed:ACWP),是给定期间内因完成工作所花费的直接和间接成本的总和。

     盈余量(the earned value),也称为已执行工作的预算成本(the budgeted cost of work performed:BCWP),是总预算的一个百分比。此一百分比等同于实际完工工作的一个百分比。为了简化数据收集许多盈余量仅用一个百分比表示。一些盈余量只用0和100%(完工或未完工)来表示以确保执行衡量的客观性。

       这三个量一起使用提供了工作是否按计划完成的度量标准。最常使用的度量标准是成本差异(CV=BCWP-ACWP)、进度差异(SV=BCWP-BCWS)和成本执行指数(CPI=BCWP/ACWP)。累计的成本执行指数(BCWPs之和除以ACWPs之和)在预测完工时的项目成本中广泛地应用。在一些应用领域,进度执行指数(SPI=BCWP/BCWS)也被用来预测项目的完工日期。

       5. 信息发送的工具和方法。执行报告以10.2.2部分讨论的工具和方法发送。

    1. 执行报告(performance reports)。执行报告对收集的信息进行组织和总结并且提出分析结果。执行报告按照沟通管理计划的规定提供各类项目涉及人所需求的符合详细等级的信息。执行报告的通用格式包括条形图(也称为甘特图),S曲线、矩形图和表格。图10-2使用S曲线来表示累计的盈余量解析数据,而图10-3以表格表示盈余量的数据。

    2. 变更请求(change requests)。对项目执行情况的分析,常常产生对项目的某些方面作出修改的 要求。这些变更请求由各类变更控制程序处理。(例如,范围变更处理,进度控制等。)

    10.4行政总结(administration closure)

    项目或阶段在达到目标或因其他原因而终止后需要一个总结。行政总结包括对项目结果的鉴定和记录,以便由发起人、委托人或顾客正式接受项目的产品。行政总结包括项目记录的收集、确保项目记录反映最终的设计书、项目成功和效益的分析以及对此类信息的立卷以备将来之用。

    行政总结在项目进行中不应被拖延,项目的每一阶段应以适当的方式结束,以确保重要和有用的信息不会被丢失。

    10.4.1行政总结的输入

    1. 衡量执行结果的文件资料(performance measurement documentation)。为记录和分析项目的执行而产生的所有文件资料,包括为衡量执行情况而确立框架的计划文件,在行政总结期间都需进行复查。

    2. 项目产品的文件资料(documentation of the product of the project)。为说明项目产品(计划,设计书(specifications),技术文件,图纸,电子文件等--所用术语因使用的领域不同而不同)而产生的文件,在行政总结期间都需进行复查。

    3. 其他项目记录。有关项目记录讨论见10.2.3.1部分。

    10.4.2行政总结的工具和方法

    执行报告的工具和方法。执行报告的工具和方法的论述见10.3.2部分。

    10.4.3行政总结的输出

    1. 项目案卷。项目索引记录的完整汇总材料应由合适的参与者准备好以完成立卷。与项目有关的历史数据库都要被更新,当项目在合同下完成或项目涉及重大的采购之时,对金融记录(financial record)的立卷必须特别注意。

    2. 经验总结。经验总结的讨论见4.3.3.3部分。

    11章 项目风险管理

    项目风险管理是指对项目风险从识别到分析乃至采取应对措施等一系列过程,它包括将积极因素所产生的影响最大化和使消极因素产生的影响最小化两方面内容,图11-1提供了以下主要程序的总视图。

    这些程序不仅其间相互作用,而且与其它一些区域内的程序也互相影响,每个程序都可能牵涉及到基于项目本身需要的一个人甚至一组人的努力:在每个项目阶段里,这些程序都至少会出现一次。 

    尽管这些程序在这里是作为分别独立的要素被加以阐述,且其相互之间的作用也被清晰界定,但实际过程中,它们往往相互交迭,互相作用,其细节这里不再重述(程序间相互作用在第三章中已详细讨论)。

    这里所说的程序在不同的应用领域常常使用不同的名字,比如:

     风险识别及风险量化程序时常被作为一个程序,称之为风险分析或风险评估。

     风险对策研究时常被称为风险计划或风险缓冲。 

     风险对策研究和风险对策实施控制有时也被当做一个程序对待,被称为风险管理。

    11.1风险识别

    风险识别包含两方面内容:识别哪能些风险可能影响项目进展及记录具体风险的各方面特征。风险识别不是一次性行为,而应有规律的穿整个项目中。

    风险识别包括识别内在风险及外在风险。内在风险指项目工作组能加以控制和影响的风险,如人事任免和成本估计等。外在风险指超出项目工作组等控力和影响力之外的风险,如市场转向或政府行为等。

    严格来说,风险仅仅指遭受创伤和损失的可能性,但对项目而言,风险识别还牵涉机会选择(积极成本)和不利因素威胁(消极结果)。 

    项目风险识别应凭借对"因"和"果"(将会发生什么导致什么)的认定来实现,或通过对"果"和"因"(什么样的结果需要予以避免或促使其发生,以及怎样发生)的认定来完成。

    11.1.1对风险识别的输入

    1.产品说明

    在所识别的风险中,项目产品的特性起主要的决定作用。所有的产品都是这样,生产技术已经成熟完善的产品要比尚待革新和发明的产品风险低得多。与项目相关的风险常常以"产品成本"和"预期影响"来描述。

    在5.1.1.1.章节中对产品说明作了进一步的阐述。

       2.其它计划输出

      应该回顾一下在其它区域里的程序输出,它门可以用来识别可能的风险,比如:

     工作分析结构--非传统形式的结构细分往往能提供给我们高一层次分支图所不能看出来的选择机会。

     成本估计和活动时间估计--不合理的估计及仅凭有限信息做出的估计会产生更多风险。

     人事方案--确定团队成员有独特的工作技能使之难以替代,或有其它职责使成员分工细化。

     必需品采购管理方案--类似发展缓慢的地方经济这样的市场条件往往可能提供降低合同成本的选择。

     3.历史资料

    有关以前若干个项目情况的历史资料对识别目前项目的潜在风险具有特殊帮助。这种历史资料往往可以从以下渠道获得:

     项目资料文件--一个项目所牵涉的一个或更多的组织往往会保留过去项目的记录,这些记录会很详细,足以协助进行风险识别工作。实际上,某些团队的成员就保有这样的记录。

     商业数据--在很多应用领域我们可以获得商业的历史信息。 

     项目组的经验知识--项目组成员都会记得以往项目的产出和消耗情况。当然这样收集的信息可能很有用,但较之以文件资料形式记录的信息可靠性低些。

      

    11.1.2工具和方法

       1.核对表

    核对表一般根据风险要素编篡。包括项目的环境(见第2章),其它程序的输出(见11.1.1.2),项目产品或技术资料,以及内部因素如团队成员的技能(或技能的缺陷)。有些应用领域广泛应用分类图表作为风险原始资料的一部分。

     2.流量表

    流量表(在8.1.2.3中有述)能帮助项目组易于理解风险的缘由和影响。

    3.面谈

    与不同的项目涉及人员进行有关风险的面谈有助于那些在常规计划中未被识别的风险。项目前期面谈记录(这些工作往往在进行可行性研究时进行)也是可以获得的。 

    11.1.3风险的输出

    1.风险因素。风险因素是指一系列可能影响项目向好或坏的方向发展的风险事件的总和,这些因素是复杂的,也就是说,它们应包括所有已识别的条目,而不论频率、发生之可能性,盈利或损失的数量等。一般风险因素包括:

     需求的变化

     设计错误、疏漏和理解错误。

     狭隘定义或理解职务和责任。

     不充分估计。

     不胜任的技术人员。

    对风险因素的描述应包括对以下四项内容的评估:

    (a)由一个因素产生的风险事件发生的可能性

    (b)可能的结果范围

    (c)预期发生的时间

    (d)一个风险因素所产生的风险事件的发生频率

    机会和产出两者之间可以精确画出连续函数(估计成本在100,000和150,000之间)或画出离散函数(一个可能或不可能获得的专利)。除此之外,在项目前阶段对可能性和产出的评估比项目后期所做的评估的评估值范围更大。

    2.潜在的风险事件:潜在的风险事件是指如自然灾害或团队特殊人员出走等能影响项目的不连续事件。在发生这种事件或重大损失的可能相对巨大时("相对巨大"应根据具体项目而定),除风险因素外还应将潜在风险事件考虑在内。当潜在风险事件发生在不常有的特定应用领域时,常常是指如下一些事件:

     与普通项目要求不同的高新技术的发展领域,较常见于电子工业而少见于地产业的发展。
       类似风暴所造成的损失,较常见于建筑业,而不是生物科学技术领域。

    对潜在风险的描述应包括对以下四个要素的评估:

    (a)风险事件发生的可能性
      (b)可选择的可能结果
      (c)事件发生的时间
      (d)发生频率的估测(即是否会发生一次以上)

    3.风险征兆。风险征兆交有时也被称为触发引擎,是一种实际风险事件的间接显示。比如:丧失士气可能是计划被搁置的警告信号;而运作早期即产生成本超支可能又是评估粗糙的表现。

    4.对其它程序的输入。风险认定过程应在另一个相关领域中确定一个要求,以便进行进一步运作。比如:如果工作分析结构图不够细致,就无法进行充分的风险识别。风险常常被做为系统规定参数或假定值输入其它过程。

    11.2风险量化

       风险量化涉及到对风险和风险之间相互作用的评估,用这个评估分析项目可能的输出。这首先需要决定哪些风险值得反应。风险由于包括诸多因素而较复杂,这里就部分因素列举如下:

     机会和危胁能够以出乎意料的方式相互作用(比如:计划的延迟会造成不得不考虑新的战略以缩短整个项目周期)。

     一个单纯的风险事件能造成多重后果。(比如:主要零部件递送延误会造成成本超支、计划延迟、多支付薪水以及产品质量低劣等。)

     某个项目涉及人员的机会(如降成本)却往往意味着对其它项目涉及人员的威胁(不得不降低利润)。

     数学技巧往往容易使人们对精确性和可靠性产生错误印象。


    11.2.1对风险量化的输入

      1.投资者对风险的容忍度。不同的组织和个人往往对风险有着不同的容忍限度,举例如下:

      一个高利润高收益的公司也许愿意为一个10亿美元的合同花费$500,000.00制做一计划书,而一个收支     相抵的公司则不会。

      一个组织也许认为15%的误差机率是高风险的,而其它组织却认为这个机率风险很低。

      2.风险因素(见11.1.3.1)

    3.潜在风险事件(见章节11.1.3.2)

    4.成本评估(见章节7.2.3.1)

    5.运作周期评估(见章节6.3.3.1)

    11.2.2工具和方法

    1.期望资金额,期望资金额是风险的一个重要指标,它是以下两个值的函数。

     风险事件的可能性--对一个假定风险事件发生可能性的评估。
       风险事件值--风险事件发生时对所引起的盈利或损失值的评估。

    这个风险事件值要以有形资产和无形资产形式反映。比如,由于付出过高价格制定的计划书的A项目与B项目认定了损失有形资产$100,000的相同风险概率。如果A项目认定只有极少或没有造成无形资产损失,而B项目预计所产生的这么巨大的损失将使该组织不得不离开该行业,那么两种风险则不同了。

    在相同情形下,如无法将无形资产计算在内,则将高概率的小亏损同低概率的大亏损等同起来会产生巨大差异。

    如果说风险事件会独立发生也会集体发生,会并行发生也会顺序发生,那么"预期资金总额"也总是被做为一种输入值,以进一步做分析(如决策树等)。

    2.统计数加总。统计数字加总是将每个具体工作课题的估计成本加总以计算出整个项目的成本的变化范围(如章节11.2.2.3所述,从估测的工期变量来计算项目完成时的可能数据的变化范围。)

    可以用来量化项目总成本的变化范围来替代项目预算或提议价格的相对风险,表11-2说明了如何在项目变化范围评估中运用"力矩法"的技巧。

    3.模拟法。模拟法运用假定值或系统模型来分析系统行为或系统表现。较普通的模拟法模式是运用项目模型作为项目框架来制作项目日程表。大多模拟项目日程表是建立在某种形式的"蒙特洛"分析基础上的。这种技术往往由全局管理所采用,对项目"预演"多次以得出如表11-3所示计算结果的数据统计分。

    蒙特洛分析和其它形式 模拟法也可能用来估算项目成本可能的变化范围。

    4.决策树。决策树是一种便于决策者理解的,来说明不同决策之间和相关偶发事件之间的相互作用的图表。决策树的分支或代表决策(用方格表示)或代表偶发事件(用圆圈表示),如图11-5系一个典型的决策树图。


       做可能性分配统计时:

     如图示时分配偏左,则项目平均值将大大高于估计统计值。
       分配数据可任意混合和匹配,同一分支被用来做全部计算可简化本图表。 

    为统计各分支可能性总和,需计算以下变量值:

     平均值,求和(标准偏差)和对这一分支基于公式计算的每一变量的方差(如贝它、三角平面等)。
       对项目每一变量平均值求和,即项目平均值。
       对项目每一变量方差求和,即项目方差。
       对项目方差求平方根,即项目求和值(标准偏差)。

      上面的曲线显示了完成项目的案积可能性与某一时间点的关系。比如说,虚线的交叉点显示:在项目启动后145天之内完成项目的可能性为50%。项目完成期越靠左则风险愈高,反之风险愈低。

    工程1、2、3都预计耗工期12天±2天,CPM(关键路径法)计算出A至B里程所耗用工期为12天,但工程1、2、3之中任何一个工程如产生延期,实期工期都会超过12天,就算其它工期在12天内完成。

     预期资金(EMU)=产出×该产出可能性。

     某决策预期资金=该决策所有分支产出的资金总和。

     $4,000预期资金的高估日程表从选择角度显示优于$1,000预期资金的保守日程表。

    5.专家判断 专家判断往往能够代替或者附加在前面提到过的数学技巧。比如,风险事件可以被专家描述为具有高、中、低三种发生机率,和具有强烈、温和、有限三种影响。 

    11.2.3风险量化的产生

    1.需跟踪的机会,需反应的威胁。风险量化的主要产出是一个记录着应被跟踪的机会和值得注意的威胁的清单。

    2.被忽视的机会,被吸纳的威胁。风险量化过程中也应记录下如下信息(a)哪些风险来源和风险事件被项目管理队伍决定忽略或吸纳了,(b)是谁做出的该种决策。

    11.3风险对策研究

       风险对策研究包括对机会的跟踪进度和对危机的对策的定义。对危胁的对策大体分以下三点:

     避免--排除特定危胁往往靠排除危胁起源。项目管理队伍绝不可能排除所有风险,但特定的风险事件往往是可以排除的。 

     减缓--减少风险事件的预期资金投入来减低风险发生的概率(如为避免项目产出的产品报废而使用专利技术),以及减少风险事件的风险系数(如买投保),或两者双管齐下。

     吸纳--接受一切后果。这种接受可以是积极的(如制定预防性计划来防备风险事件的发生),也可以是消极的(如某些工程运营超支则接受低于预期的利润)。

    11.3.1对风险对策研究的输入

    1.需跟踪的机会,需反应的危胁。见11.2.3.1详述。

    2.被忽略的机会,被吸纳的危胁。见11.2.3.2详述。

    以上条目之所以做为风险对策研究的输入是因为它们应被记录在风险管理方案中(见11.3.3.1)。


    11.3.2工具和方法

    1.采购 采购,即从本项目组织外采购产品和服务,常常是针对某些种类风险的有效对策。比如,与使用特殊科技相关的风险就可以通过与有此种技术经验的组织签定合同减缓风险。

    采购行为往往将一种风险置换为另一种风险。比如,如果销售商不能够顺利销售,那么用制定固定价格的合同来减缓成本风险会造成项目时间进程受延误的风险。而相同情形下,将技术风险转嫁给销售商又会造成难以接受的成本风险。(详见12章项目采购管理)

    2.预防性计划 预防性计划包括对一个确认的风险事件如果发生如何制定行动步骤(见11.4.2.1工作区讨论)。

    3.替代战略 风险事件常常可以通过及时改变计划来制止或避免。比如,一个备用的工作方案可以减少在安装期和建设阶段中产生的变故。实际上在许多应用领域都有替代战略在潜在价值方面的实体文字说明。

    4.投保 保险或类似保险的操作如证券投资常常对一些风险类别是行之有效的。在不同的应用领域,险种的类别和险种的成本也相应不同。

    11.3.3风险对策研究的输出

    1.风险管理方案。在整个项目进程中都应将管理风险的程序记录在风险管理方案里。除了记录风险识别和风险量化程序的结果外,还应记录包括谁对处理各个领域里的风险负责,怎样保留初步风险识别和风险量化的输出项,预防性计划怎样实施,以及储备如何分配等。 

    一个风险管理方案可以是正式的或非正式的。可以是细致入微或框架性的,这主要依据使项目而定。它是整个项目方案的一个辅助方案(详见章节4.1)。

    2.对其它程序的输入 挑选出的或建设性的替代战略、预防性计划、预先采购、和其它有关风险的输出项都要反馈到其它知识领域中相应的过程里。

    3.预防性计划 预防性计划是一种在识别的风险事件发生时将采取的事先拟定好的行动步骤。它是风险管理方案的一部分,但有时也被做为整个项目管理方案的其它部分的组成。(比如做为区域管理方案或优质管理方案的一部分)。 

    4.储备 储备是为了减缓成本风险和(或)日程风险而在项目方案中提出的预先准备。这个词往往在前边要使用一个修饰语(如管理储备,防预性储备,日程储备)以提供细节以便阐明需要缓解的是哪类风险。这个加了定语的词组的特定含义往往跟据应用领域不同而不同。除此之外,储备的应用,以及储备应包含什么也是一个特殊的应用领域。

    5.契约 契约应囊括诸如保险、服务和其它条款用以避免和缓解危胁。合同术语与条款在降低风险系数上具有非常重大的意义和影响。

    11.4风险对策实施控制

    风险对策实施控制包括实施风险管理方案以便在项目过程中对风险事件做出回应。当变故发生时,需要重复进行风险识别,风险量化以及风险对策研究一整套基本措施。就算最彻底和最复杂的分析也不可能准确识别所有风险以及其发生概率,理解这一点是很重要的,因此控制和重复是必要的。

    11.4.1对风险对策控制的输入项

    1.风险管理方案。见章节11.3.3.1

    2.实际风险事件。有些已识别了的风险事件会发生,有些则不会。发生了的风险事件是实际风险事件或说是风险的起源,而项目管理人员应总结已发生的风险事件以便进行进一步的对策研究。

    3.附加风险识别。当项目进程受到评价和总结时(在章节10.3中有讨论),事先未被识别的潜在风险事件或风险的起源将会浮出水面。

    11.4.2风险对策实施控制的工具和方法

    1.工作区:对消极的风险事件而言,工作区是一种不列入方案的对策。所谓不列入方案是指在感觉上它并未定义在风险事件发生前。 

    2.附加风险策略研究。如果风险事件未被预料到,或后果远大于预料,那么计划的风险策略将会不充分,这时就有必要再次重复进行风险对策研究甚至风险管理程序。

    11.4.3风险对策实施控制输出项

    1.校正行为:校正行为首先包括实施已计划的风险对策(比如实施预防性计划或工作区计划)。

    2.实时调整风险管理计划。一个预料之中的风险事件发生或没发生,对实际风险事件后果的评估,对风险系数和风险机率的评估,以及风险管理方案的其它方面,都应进行实时的更新调整。

    12章 项目采购管理

    项目采购管理包括从执行组织之外获取货物和服务的过程(process)。为了简便起见,货物和服务统称为"产品"。图12-1描述了解下几个主要过程的纲要。

    这些过程之间以及与其他领域的过程之间相互作用。如果项目需要,每一过程可以由个人、多人或团体来完成。虽然在这里列举的过程是分立的阶段并具有明确定义的分界面,事实上他们是互相交织、互相作用的。过程的相互作用在第3章项目管理过程详细地阐述。

    在卖方和买方的关系中,项目采购管理是以买主的角度讨论的。卖方和买方关系可能存在于一个项目的很多阶段,在不同的阶段卖方可能被称之为合同方,卖方和供应方。

    在以下情况下卖方通常用一个项目来管理他们的工作:

     买方成为一个客户因而是卖方的主要项目涉及人(stakeholder);

     卖方的项目管理小组必须注意项目管理的所有过程,并不仅仅局限于采购这一范围;

     合同的条款与条件成为许多卖方流程的关键输入。实际上合同就可能包括了这样的输入(例如主要的工作项目交付物(deliverables),主要的里程碑事件(milestones),成本目标)或者将限制项目小组的选择(例如,在设计项目时往往需要买方批准人员配备)。

     本章假定对执行组织(performing organization)来说,卖方是个外部因素。然而大多数讨论也适用于执行组织其他单位的正式协定(formal agreement),当涉及非正式协定(informal agreement)时,在项目人力资源管理(第9章)和沟通管理(第十章)也都可能适用。

    12.1采购计划(procurement planning)

    采购计划是确定哪一项目需求可通过采购项目组织之外的商品和劳务来满足的过程,包括是否采购,怎样采购,采购什么,采购多少什么时候采购等过程。

    当项目需要执行组织之外的商品和劳务时,对每一产品和劳务都将执行一次询价计划流程。签订合同和采购时,项目管理小组将寻求专家们的支持。

    当项目不需从外界获取产品和服务时,询价计划流程就不必要执行。这种情形一般出现在研究开发项目,因为执行组织不愿同别人分享项目技术;或者发现和管理外部资源所花的成本可能超过潜在收入的许多小规模室内项目(in-house project)。

    采购管理也包括潜在子合同因素(consideration of potential subcontract),特别是买方希望对子合同签订决策施加影响的时候。

    12.1.1采购计划的输入(inputs to procurement planning

    1. 输出包括基本成本(preliminary cost)和进度估计(schedule estimates),质量管理计划(quality management plans),现金流量计划(cash flow projections),工作分层结构(the work breakdown structure),确认的风险(identified risks)和计划人员配置(planed staffing)。

    2. 制约因素(constraints)。制约因素是限制买方选择的因素,大多数项目最通常的制约因素手头的资假设因素(assumptions)。假设因素是被认为是真实的确定的因素。

    12.1.2采购计划的工具和方法(tools and techniques for procurement planning

    1. 自制和外购分析(make-or-buy analysis)。此法可用来分析某种产品由执行组织生产是否成本更低,这是很普通的管理工具。自制或是外购分析都包括间接成本和直接成本。例如,在外购分析时,应包括采购产品的成本和管理购买过程的间接费用。自制和外购分析必须反映执行组织的观点和项目的直接需求。例如,采购一项资本性支出项目(capital item)(从建筑吊车到个人电脑的任何项目)与租赁此一项目相比较,在成本上一般是不合算的,然而如执行组织对某一项目有持续需求,那么结入项目的购货成本可能比租赁来的低。

    2. 专家意见(expert judgement)。在采购计划的工具和方法中,往往需要专家意见来评估管理输入。这种专家意见可由具有专门知识,来自于多种渠道的团体和个人提供。包括:

     执行组织中的其他单位
       顾问
       专业技术团体(professional and technical associations
       实业集团(industry groups

    3. 合同类型选择(contract type selection)不同类型的采购应采用适合其特点的合同。合同一般分成三大类:

     固定价格合同(fixed price or lump sum contracts)。这类合同对一个明确定义的产品采用一个固定总价格,如果该产品没有明确定义,卖方和买方都会面临风险--买方可能得不到想要的产品,卖方为了提供产品可能花费额外的成本。固定价格合同也包括对达到或超过既定项目目标(例如进度目标等)的奖励。

     成本补偿合同(cost reimbursement contracts)。这类合同包括支付给卖方实际成本(actual cost)。成本分为直接成本和间接成本。直接成本指工程项目单独花费的成本(例如,全职员工的薪水)。间接成本指由执行组织计划归项目的管理费用(例如,公司董事的薪水)。间接成本一般按直接成本的一定百分比计算。成本补偿合同也常常包括对达到或超过既定的项目目标(例如进度目标等)的奖励。

     单价合同(unit price contracts--卖方按预先设定的单价支付一定金额(例如,1小时70美元的专业劳务或者一立方码土石方1.08美元),合同的总金额是完成项目的工作量的函数。

    12.1.3 采购计划的输出(outputs from procurement planning

    1. 采购管理计划(procurement management plan)。采购管理计划应规定剩余的采购过程将怎样被管理。例如:

     采用什么类型的合同?
       如果采用独立估计(independent estimates)作为评估标准,由谁准备?什么时候准备?
       如果需要标准采购单证(standardized procurement documents),在哪里可找到?
       怎样管理多家供应商?
       采购如何同项目的其他部分协调,例如进度和执行报告?

    一个采购管理计划可以是正式的或非正式的,详细的或框架性的,具体采用什么形式要根据项目的需要。采购管理计划在整个项目计划(见4.1项目计划规划)中是一个辅助因素。

    2. 工作明细表(statement of work)。工作明细表足够详细地规定了采购项目,以便未来的卖方决定他们是否有能力提供这些项目。"足够详细"sufficient detail)会因项目的性质,买方需求,预期的合同的格式的不同而不同。

    某些不同的领域认可不同类型的工作明细表。例如,在一些政府的辖区(government jurisdictions),工作明细表是明确指定产品和劳务的采购项目,而必须品明细表(statement of requirements)是指作为问题需解决的采购项目。

    在采购流程中,工作明细表可能需要修订,例如一个潜在的卖主可能建议一个更有效的解决方案或者成本更低的产品。每一个采购项目都需要一个独立的工作明细表,然而多项产品和劳务可能用一个工作明细表集成一个采购项目。 

    工作明细表应尽可能的清楚、完整和简洁。它应包括任何所必须的附带劳务描述,例如执行报告或前项目(post-project)对采购项目(procured item)的操作支持(operational support),在一些应用领域需具备工作明细表的特定的内容和格式。

    12.2 询价计划(solicitation planning)

      询价计划包括准备询价中所需的单证文件(documents

    12.2.1 询价计划输入(input to solicitation planning

    1. 采购管理计划。采购管理计划在12.1.3.1部分讨论

    2. 工作明细表(在12.1.3.2讨论)

    3 其他计划输出。其他计划输出(参见12.1.1.5),当它们被考虑为采购计划的一部分时,它们有可能被修改,当它们被认为是询价的一部分时,也可能再被修改。特别指出,询价计划应与项目进度十分协调。

    12.2.2 询价计划的工具和方法(tools and techniques for solicitation planning

    1. 标准表格(standard forms)。标准表格可包括标准合同(standard contracts)、标准采购项目说明(standard descriptions of procurement items)、全部或部分标准投标文件(standardized versions of all or part of the needed bid documents)(见12.2.3.1)。进行大量采购的组织应使大部分单证文件标准化。

    2. 专家意见。专家意见在12.1.2.2部分讨论。

    12.2.3 询价计划的输出(outputs from solicitation planning

    1. 采购单证文件(procurement documents)。采购单证文件被用来引诱潜在的卖方提出建议(proposals)。术语"标书"(bid)和"报价单"(quotation)一般用在渠道选择采用价格导向(price-driven)时候(如商业采购)。至于术语"意见"(proposal)一般用在技术或方法(technical skill or approach)等非资金因素(non-financial consideration)最重要的时候(如购买专业服务)。然而这些术语经常在使用中互换,因而不要想当然的认为术语按其暗含的意思使用。不同采购单证文件的通用名称包括:投标邀请函(invitation for bid)、意见请求书(request for proposal)、报价单请求书(request for quotation)、磋商邀请函(invitation for negotiation)和合同方回函(contractor initial response)等。

    采购单证文件应使用合理的结构,这样做能促进从卖方得到明确和完整的答复。采购单证文件应包括相关的工作明细表,对卖方答复形式的规定和必要的合同条款(例如格式合同,不得泄露商业秘密条款)。

    采购单证文件部分或全部内容的结构要符合法令,特别是政府机构的合同。采购单证文件应要有足够的严谨以确保卖方的答复准确完整。但也要有一定够的弹性从而允许卖方提出满足需求的更好的建议。

    2. 评估标准(evaluation of criteria)。评估标准用以给建议评价和打分。标准可是主观的(例如,项目经理应具有项目管理专业证书)或客观的(例如项目经理应具有管理相似项目的经验)评估标准往往是采购单证文件的一部分。 

    如果采购项目已经存在于一些可接受的渠道中,评估标准可限于采购价格(采购价格包括采购项目的成本和采购费用)。如采购项目还不存在,那么应制定其他标准以形成一个完整的评价制度。例如:

     对需求的理解--可由卖方建议看出。

     总周期成本或生命周期成本(overall or life cycle cost)--选出的卖方是否能生产出最低成本(采购成本加上经营成本)?

     技术水平(technical capability)--卖方是否具有,或是否有理由相信卖方得获得需要的技术和知识?

     管理方式(management approach)--卖方拥有,或有理由相信卖方拥有一套确保项目成功的管理程序?

     资金(financial capacity)--卖方是否拥有,或是否有理由相信卖方获得所需资金。

    3. 工作明细表的修订(statement of work updates)。工作明细表在12.1.3.2部分讨论。一份或多份工作明细表的修订应在询价计划期间确定。

    12.3 询价(solicitation)

      询价包括向卖方获取如何满足项目要求的信息。此过程的工作大多数由卖方做,因而对项目来说没有花费。

    12.3.1 询价的输入(inputs to solicitation

    1. 采购单证文件。采购单证文件在12.2.3.1部分讨论。

    2. 合格卖方名单(qualified seller lists)。一些组织都维持一个卖方信息名单和文件。这些名单一般都有卖方的相关经验和其他特点。

    如果这样名单不存在,项目小组就必须开拓自己的渠道。可从图书馆目录、相关的区域协会,商业目录和其他类似的渠道获得通用的信息资料。要获得特定渠道的详细信息就要付出更多的努力,例如网站访问和与前客户通讯联系。

    采购单证要文件发送给全部或一部分潜在的卖方。

    12.3.2询价的工具和方法(tools and techniques for solicitation

    1. 投标者会议(bidders conferences)。投标者会议指在提出建议前(proposal)与潜在卖方的碰头会,投标者会议来确保所有潜在卖方对采购有一个清晰、共同的理解(技术要求,合同要求等)。对问题的答复有可能作为修订条款包含到采购单证文件里去。

    2. 广告。现有的潜在卖方名单常常通过在普通出版物如报纸或专门出版物如专业刊物上作广告而得到扩充。在一些国家(government jurisdictions)某些类型的采购项目要求公开向大众做广告(public advertising),在大多数国家要求政府合同下的子合同公开向大众做广告(public advertising of subcontracts on a government contract)。

    12.3.3 询价的输出(output from solicitation

    1. 建议书(proposals)。建议书是卖方准备的文件,说明卖方提供所需产品的能力和意愿。建议书应该同相关的采购单证文件一致。

    12.4 渠道选择(source selection)

    渠道选择包括标书或建议书的接收和使用评估标准评估对供应商进行选择。这个过程很少直线前进。

     价格也许是主要决定因素。但是如果卖方不能及时应贷,最低的价格也许不是最低的成本。

     建议书可分成技术(方案)部分和商业(价格)部分。各部分应独立评估。

     对关键性产品应采用多渠道。

    下面介绍的工具和方法可单独使用或合并使用,例如加权分析法(Weighting system)可用在:

     选择出一个渠道签定格式合同。

     对所有建议排序以确定磋商次序。

    对于重要采购项目,这一过程可能要重复几次。合格卖方的名单将根据初步的建议作出选择,然后,更详细的评估根据更详细和全面的建议而开展。

    12.4.1 渠道选择的输入(inputs to souse selection

    1. 建议书(proposals),建议书在12.3.3.1部分讨论。

    2. 评估标准(evaluation criteria)。评估标准在12.2.3.2.部分讨论。

    3. 组织政策(organizational policies)。管理项目的组织都有正式和非正式和政策,该政策可能影响对建议的评估。

    12.4.2 渠道选择的工具和方法(tools and techniques for source selection

    1. 合同磋商(contract negotiation)。合同磋商是合同签订前的步骤,包括对合同结构和要求的澄清和合意(clarification and mutual agreement)。最终的合同文本应反映所有已达成的合意。合同的内容涵盖(但不局限于)责任和权利,适用的条款和法律,技术和商业管理方案,合同融资以及价格。 

    对于复杂的采购条款,合同磋商应是一个独立的过程,该过程有自己的输入(例如一个问题或公开项目表)和输出(例如备忘录)。 

    合同磋商是称为为"磋商"的通用管理技巧的一个特例。磋商工具技巧和方式在通用管理类书籍里被广泛讨论,并可以应用到合同磋商过程。

    2. 加权法(weighting system)。加权法是对定性数据的定量分析,以使尽量减小渠道选择中的人为偏见影响。方法包括:

    (1) 给每一评估标准设定一权重,

    (2) 按每一标准为卖方打分,

    (3) 权重和分数之积,

    (4) 把所有的乘积求和得到一个总分数。

    3. 筛选法(screening system)。筛选法包括为一个或几个评估标准确定最低要求。

    4. 独立评估(independent estimates)。对很多采购项目,采购组织要自己评估价格。如果评估有明显的差别可能意味着工作明细表不充分,也可能意味着卖方误解或者没能完全答复工作明细表。

    独立估计常被称为"应该花费"估计("should cost" estimates)

    12.4.3 渠道选择输出(outputs from source selection

    1. 合同(contracts)。合同是有约束力的合意。卖方有提供指定商品的义务,卖方有支付价款的义务。合同是可由法庭救济的法律关系。合同可以简单或复杂,常常(并不总是)由产品的简单或复杂决定。在众多名称中,合同也称为协议(an agreement)、子合同(a subcontract)、采购单(a purchase order)、备忘录(a memorandum of understanding)。大多数组织有成文的政策和程序,规定由谁代表组织签订合同。

    虽然所有项目文件都按照审查(review)和批准(approval)的形式,但是合同的法律约束性本质通常意味着合同将采用更广泛的批准过程。在所有情况下,审查和批准程序最注重的地方就是要确保合同文本定义的产品或劳务符合规定的要求。由公共部门(public agencies)执行项目情况下,审查程序还包括公众对合同的审查(public review of the agreement)。

    12.5 合同管理(contract administration)

    合同管理是确保卖方的执行符合合同要求的过程。对于需要多个产品和劳务供应商的大型项目,合同管理的主要方面就是管理不同供应商的界面(interfaces)。执行组织管理合同时要采取一系列行动。合同关系的法律本质性使得执行组织在管理合同时必须准确地理解行动的法律内涵。

    合同管理包括对合同关系适用适当的项目管理程序并把这些过程的输出统一到整个项目的管理中。当涉及多个卖方和多种产品的时候,在各个层次上,总是需要这种统一和协调。

    项目管理过程应用在:

     项目计划执行(project plan execution),在4.2部分讨论,在适当时候授权合同方的工作。

     执行报告(performance reporting),在10.3部分讨论,监控合同方的成本、进度和技术绩效(technical performance)。

     质量控制(quality control),在8.3部分讨论,检验合同方的产品是否合格。

     变更控制(change control),在4.3部分讨论,确保变更被正确地批准,以及需要了解情况的人知晓变更的发生。

    合同管理还包括资金管理部分(financial management component)。支付条款应在合同中规定。支付条款中,价款的支付应与取得的进展联系在一起。

    12.5.1 合同管理的输入(inputs to contract administration

    1. 合同(contract)。合同在 12.4.3.1中讨论

    2. 工作结果(work results)。卖方的工作结果--子项目(deliverables)是否完成,符合质量标准的程度,花费的成本等--都作为项目计划执行的一部分收集起来。( 4.2部分对项目计划执行做了详细的讨论)。

    3. 变更请求(change requests)。变更请示包括对合同条款的修订和对产品和劳务说明的修订。如果卖方工作不令人满意,那么终止合同的决定也作为变更请求处理。卖方和项目管理小组不能就变更的补偿达成一致的变更是争议性变更(contested change ),称之为权力主张(claim)、争端(disputes)或诉讼(appeals)。

    4. 卖方发票(seller invoices)。卖方应不断开出发票要求清偿已做的工作。开具发票的要求,包括必要的文件资料附具(supporting documentation),通常在合同中加以规定。

    12.5.2合同管理的工具和方法(tools and techniques for contract administration

    1. 合同变更控制系统(contract change control system)。合同变更控制系统定义可以变更合同的程序,包括书面工作(the paperwork)、跟踪系统(tracking system)、争端解决程序(dispute resolution procedures)和变更的批准级别(approval levels)。合同变更控制系统应被包括在总体的变更控制系统中(4.3部分讨论总体的变更控制系统)。

    2. 执行报告(performance reporting)。执行报告向管理方提供卖方是否有效地完成合同目标的信息。合同执行报告应同整个项目的执行报告(见10.3)合并在一起。

    3. 支付系统(payment system)。对卖方的支付通常由执行组织的应付账款系统(accounts payable system)处理。对于有多种或复杂的采购需求的大项目,项目应设立自己的支付系统。不管哪一种情况,支付系统都应包括项目管理小组的适当的审查和批准过程。 

    12.5.3 合同管理的输出(outputs from contract administration

    1. 信涵(correspondence)。合同条款和条件常常要求买方/卖方在某些方面的沟通以书面文件进行。例如,对执行令人不满意的合同的警告,合同变更或条款的澄清。

    2. 合同变更(contract changes)。合同变更(同意的或不同意的)是项目计划和项目采购过程的反馈。项目计划和相关的文件应做适当的更新。

    3. 支付请求(payment requests)。支付请求假定项目采用外部支付系统,如项目有自己的支付系统,在这里的输出为"支付"(payments)。

    12.6 合同收尾(contract close-out)

    合同收尾与行政总结(administrative closure)类似(10.4部分讨论),因为合同收尾包括产品核实(所有工作正确地令人满意地完成了吗?)和行政收尾(administrative close-out)(更新记录以反映最终结果和将信息立卷以备将来使用)。合同条款也可能为合同收尾规定特定的程序。提前终止合同是合同收尾的特殊情形。

    12.6.1合同收尾的输入(inputs to contract close-out

    1. 合同文件资料(contract documentation)。合同文件资料包括(但不限于)合同本身以及支持进度(supporting schedules),请来和批准的合同变更,卖方发展的技术资料(seller-developed technical documents),卖方执行报告(seller performance reports),金融证件(financial documents)(例如发票和支付记录)和与合同有关的检验结果。

    12.6.2合同收尾的工具和方法(outputs from contract close-out

    1. 采购审计(procurement audits)。采购审计是从采购计划到合同管理的采购过程的一种结构性复查(structured review)。采购审计的目标是确认成功和失败,以确保向本工程其他采购项目的转移或向执行组织内的其他项目的转移。

    12.6.3合同收尾的输出(outputs from contract close-out

    1. 合同文卷档案(contract file)。应准备一完整的索引记录设备(a complete set of indexed records)以容纳最终项目记录。

    2. 正式接收和总结(formal acceptance and closure)。负责合同管理的个人或组织提供给卖方合同已完成的正式书面通知。正式接收和总结的要求常常在合同中规定。

    展开全文
  • 项目管理复习题

    万次阅读 2020-09-18 11:54:44
    2.项目管理包括(启动过程组)、(计划过程组)、(执行过程组)、(控制过程组)、(收尾过程组)5个过程组。 二、判断题 1、搬家属于项目。(√) 2、项目是为了创造一个唯一的产品或提供一个唯一的服务而进行...

    蓝字位注释,红字为错误原因,紫字为重点

    本复习题链接:https://pan.baidu.com/s/1ZJ4l6mKxAt9dqhw0Qa58xA 
    提取码:j4jz

    笔记:https://blog.csdn.net/weixin_42139734/article/details/108661001

    第一章

    一、填空题

    1.敏捷模型包括(4)个核心价值,对应(12)个敏捷原则。

    2.项目管理包括(启动过程组)、(计划过程组)、(执行过程组)、(控制过程组)、(收尾过程组)5个过程组。

    二、判断题

    1、搬家属于项目。(√)

    2、项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的永久性的努力。(×)

    3、过程管理就是对过程进行管理,目的是要让过程能够被共享、复用,并得到持续的改进。(√)

    4、项目具有临时性的特征。(√)

    5、日常运作存在大量的变更管理,而项目基本保持连贯性的。(×)

    注释:日常工作主要是重复性、持续性工作

    6、项目开发过程中可以无限制地使用资源。(×)

    7、相比传统开发的预测性过程,敏捷开发属于自适应过程(√)

    三、选择题

    1、下列选项中不是项目与日常运作的区别的是(C)

    A. 项目是以目标为导向的,日常运作是通过效率和有效性体现的。

    B. 项目是通过项目经理及其团队工作完成的,而日常运作是职能式的线性管理。

    C.项目需要有专业知识的人来完成,而日常运作的完成无需特定专业知识。

    D.项目是一次性的,日常运作是重复性的。

    2、以下都是日常运作和项目的共同之处,除了(D)

    A.由人来做 B.受限于有限的资源

    C.需要规划、执行和控制 D.都是重复性工作

    注释:日常工作主要是重复性、持续性工作。而项目有固定的开始和结束时间

    3、下面选项中不是PMBOK的知识域的是(A)

    A.招聘管理        B.质量管理        C.范围管理        D.风险管理

    4、下列选项中属于项目的是(C)

    A.上课        B.社区保安        C.野餐活动        D.每天的卫生保洁

    5、下列选项中正确的是(C)

    A.一个项目具有明确的目标而且周期不限

    B.一个项目一旦确定就不会发生变更

    C.每个项目都有自己的独特性

    D.项目都是一次性的并由项目经理独自完成

    6、(B)是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。

    A.过程        B.项目        C.项目群        D.组合

    7、下面选项中不是《敏捷宣言》中的内容的是(C)

    A.个体和交互胜过过程和工具      

    B.可以工作的软件胜过面面俱到的文档    

    C. 敏捷开发过程是自适应的过程    

    D.响应变化胜过遵循计划

    敏捷宣言:个体和交互胜过过程和工具工作软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划

    8、下列活动中不是项目的是(C)

    A.野餐活动        B.集体婚礼        C.上课        D.开发操作系统

    9、下列选项中不是项目的特征的是(C)

    A.项目具有明确的目标        B.项目具有限定的周期        

    C.项目可以重复进行         D.项目对资源成本具有约束性

    四、问答题

    1、项目管理知识体系(PMBOK)包括哪9个知识领域?

    答:项目集成管理、项目范围管理、项目时间(进度)管理、项目成本管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理、项目采购管理

    2、请简述项目管理的5个过程组及其关系。(可简答)

    答:(1)启动过程组(2)计划过程组(3)执行过程组(4)控制过程组(5)总结过程组  关系:各个过程组通过其结果进行连接,一个过程组的结果或输出是另一个过程组的输入。其中,计划过程组、执行过程组、控制过程组是核心管理过程组。

    3、项目的特征是什么。

    答:目标性、相关性、临时性、独特性、资源约束性、不确定性

    第二章

    一、填空题

    1、项目立项之后,项目负责人会进行(自造-购买)决策,确定待开发产品的哪些部分应该采购、外包开发、自主研发等。

    2、PMI人才三角重点关注(技术项目管理)、(领导力)、(战略和商务管理)3个关键技能。

    3、在(立项)阶段,应该明确项目的目标、时间表、使用的资源和经费,而且得到项目发起人的认可。

    二、判断题

    1、项目立项可以确立项目目标、时间和资源成本,同时得到项目发起人的认可。(√)

    2、项目招标对于一个项目的开发是必需的,即便项目是内部项目。(×)

    3、make or buy决策中的make指的只是自主开发。(√)

    4、项目建议书是项目计划阶段开发的文档。(×)初始阶段

    5、项目立项需要获得项目经理的认可,但不需要项目发起人的认可。(×)

    6、项目章程是项目执行组织高层批准的确认项目存在的文件,其中不包括对项目经理的授权。(×)

    7、乙方即供方(有时也称卖方)是为顾客提供产品或服务的一方。(√)

    8、在软件项目合同中,甲方是需求方,乙方是供方。(√)

    9、敏捷项目采取的是仆人式管理方式(√)

    三、选择题

    1、下列不是项目立项过程内容的是(B)

    A.项目的目标        B.项目的风险        

    C.项目的时间表      D.项目使用的资源和经费

    2、以下哪项不包括在项目章程中?(C)

    A.对项目的确认     B.对项目经理的授权    

    C.对项目风险的分析      D.项目目标的描述

    项目风险在项目分析阶段而不是在项目章程(初始阶段)

    3、项目建议书是(C)阶段开发的文档

    A.项目执行        B.项目结尾        C.项目初始        D.项目计划

    4、下列不属于甲方招投标阶段任务的是?(A)

    A.编写建议书 乙方任务)   B.招标书定义        C.供方选择    D.合同签署

    5、下列不属于乙方招投标阶段任务的是?(D)

    A.项目分析        B.竞标        C.合同签署        D.招标书定义甲方任务)

    6、PMI人才三角不包括(B)

    A、技术项目管理 B、测试能力 C、领导力 D、战略和商务管理

    四、问答题

    1、某公司希望开发一套软件产品,如果选择自己开发软件的策略,公司需要花费30000元,根据历史信息,维护这个软件每个月需要3500元。如果选择购买软件公司产品的策略,需要18000元,同时软件公司为每个安装的软件进行维护的费用是4200元/月。该公司该如何决策?

    答:自制方案:制造费 30000元维护费 3500元/月

    购买方案:购买费 18000元维护费 4200元/月

    制造差额:30000-18000=12000元

    服务差额:4200-3500=700元

    自制方案承受月份:12000/700=17.14

    如果产品在17个月以内可以选择购买方案,如果超过17个月选择自造方案。

    2、什么是项目章程?

    答:项目章程是项目执行组织高层批准的一份以书面签署的确认项目存在的文件,包括对项目的确认对项目经理的授权项目目标的概述等。

    第三章

    一、填空题

    1.(瀑布模型)生存期模型中,要求项目所有的活动都严格按照顺序进行,一个阶段的输入时下一个阶段的输入。

    2.总体上,项目生存期模型可以是预测型或(适应型)

    3.DevOps是(Development)和(Operations)的组合

    二、判断题

    1、瀑布模型不适合短期项目。(×)

    2、增量式模型可以避免一次性投资太多带来的风险。(√)

    3、V模型适合的项目类型是需求很明确、解决方案很明确,而且对系统的性能要求比较严格的项目。(√)

    4、瀑布模型和V模型都属于预测型生存期模型(√)

    5、在瀑布生存期模型中,要求项目所有的活动都严格按照顺序执行,一个阶段的输出是下一个阶段的输入。(√)

    6、极限编程从3个层面提供了13个敏捷实践(√)

    7、敏捷包括《敏捷宣言》的价值观、12个原则,以及一些通用实践等(√)

    三、选择题

    1、对于某项目,甲方提供了详细、准确的需求文档。我们的解决方案也很明确。且安全性要求非常严格。此项目采用(C)成存期模型比较合适。

    A:瀑布模型    B:增量式模型    C:V模型    D:XP模型

    2、下面属于预测型生存期模型的是(A)

    A、瀑布模型    B、增量型生存期模型  C、Scrum模型  D、原型模型

    3、下面关于敏捷模型描述不正确是(D)

    A、与传统模型相比,敏捷模型属于自适应过程

    B、可以应对需求的不断变化

    C、Scrum模型、XP模型、DevOps模型等都属于敏捷模型

    D、敏捷型是预测型和迭代型的混合模型  scrum模型又名迭代模型

    4、XP模型的实践原则不包括以下哪一点?(D)

    A:快速反馈    B:假设简单    C:包容变化    D:详细设计

    Xp模型为极限编程模型,每阶段应用瀑布模型迭代出各阶段产品即不需要详细设计

    5、在项目初期,一个项目需求不明确的情况下,应避免采用以下哪种生存期模型?(C)

    A:快速原型模型    B:增量式模型    C:V模型    D:Scrum模型

    6、关于迭代模型,下列说法不正确的是(D)

    A、不断反馈原型  B、可以加快开发速度  C、项目需求变化大  D、不多次提交

    四、问答题

    1、写出三种你熟悉的生存期模型,并说明这些模型适用于什么情况下的项目。

    (1)瀑布模型

    适用于软件需求很明确的软件项目,即一般适用于功能明确、完成、无重大变化的软件系统的开发,即:

    1) 在项目开始前,项目的需求已经被很好的理解、也很明确,而且项目经理很熟悉为实现这一模型所需要的过程。

    2) 解决方案在项目开始前也很明确。

    3) 短期项目可采用瀑布模型。

    (2)V模型

    适用于项目需求在项目开始前很明确解决方案项目开始前也很明确,项目对系统的安全很严格,如航天飞机控制系统、公司的财务系统等。

    (3)快速原型模型

    适用于项目的需求在项目开始前不明确,需要减少项目的不确定性的时候。

    2、混合模型是什么模型?

    把几种不同模型组合成一种混合模型,它允许一个项目能沿着最有效的路径发展,这就是过程开发模型(或混合模型)

    第四章

    一、填空题

    1.需求管理包括(需求获取)、(需求分析)、(需求规格编写)、(需求验证)、(需求变更) 5个过程。

    2.敏捷项目主要采用(用户故事)描述需求

    二、判断题

    1.需求规格说明可以包括系统的运行环境。(√)

    2.数据流分析方法是一种自下而上逐步求精的分析方法。(×)自上而下

    3.需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。(×)

    4.需求是指用户对软件的功能和性能的要求,就是用户希望软件能做什么事,完成什么样的功能,达到什么性能。(√)

    5.用户故事常常写在卡片上,然后将其部署在墙上(√)

    6.软件项目系统的响应时间属于功能性需求(×)

    7.数据字典是由数据项、数据流及操作指令组成的(×)

    数据字典组成:数据项、数据结构、数据流、数据存储、处理过程、外部实体

    三、选择题

    1、下列不属于软件项目管理需求过程的是?(D)

    A:需求获取    B:需求分析    C:需求规格编写    D:需求更新

    2、下列不属于数据字典组成部分的是?(D)

    A:数据项    B:数据流    C:数据文件    D:数据库

    3、下列不属于UML需求视图的是?(A)

    A:甘特图  进度管理图  B:用例图    C:状态图    D:顺序图

    4、下列关于用户故事描述不正确的是(D)

    A.英文称:user story B.不使用技术语言来描述

    C.可以描述敏捷需求 D.一种数据结构

    5、(A)是软件项目的的一个突出特点,可以导致软件项目的蔓延。

    A:需求变更    B:暂时性    C:阶段性    C:约束性

    6、下列不属于结构化方法设计的是?(D)

    A:数据流图    B:数据字典    C:系统流程图    D:系统用例图

    7、下列不属于软件需求范畴的是?(A)

    A:软件项目采用什么样的实现技术

    B:用户需要软件能做什么样的事情

    C:用户需要软件完成什么样的功能

    D:用户需要软件达到什么样的性能

    8、敏捷项目需求一般采用下面(C)描述

    A、用户用例  B、DFD  C、用户故事  D、数据字典

    四、问答题

    1.下图是SPM项目需求规格文档中的一个用例图,请根据图中信息判断参与者是什么角色?并写出至少三个用例,如登录、注册等。

    1)参与者是课务管理系统中的学生用户

    2)登录、注册、选课

    第五章

    一、填空题

    1.任务分解是将一个项目分解为更多的工作细目或者(子项目),是项目变得更小、更易管理、更易操作。

    2.WBS的全称是(任务分解结构Work Breakdown Structure)。

    3.WBS最底层次可交付成果是(工作包work package)。

    二.判断题

    1.WBS提供了项目范围基线。(√)

    2.一个工作包可以分配给另一个项目经理去完成。(√)

    3.如果开发人员对项目比较熟悉或者对项目大局有把握,开发WBS时最好采用自底向上方法。(×)

    4.对于一个没有做过的项目,开发WBS时可以采用自底向上方法。(√)

    5.在任务分解结果中,最底层的要素必须是实现项目目标的充分必要条件。(√)

    6.一个工作包应当由唯一主题负责。(√)

    7.WBS的最高层次的可交付成果是工作包。(×)

    8.对任务的分解只能自上而下的。(×)

    9.WBS的最底层任务是能分配到一个人完成的任务。(√)

    10.敏捷项目的一个Epic还可以继续分解为一些用户故事(√)

    三.选择题

    1.WBS非常重要,因为下列原因,除了(D)

    A.帮助组织工作 B.防止遗漏工作 C.为项目估算提供依据 D.确定团队成员责任

    2.WBS中的每一个具体细目通常都指定唯一的(A)

    A.编码 B.地点 C.功能模块 D.提交截至期限

    3.下列不是创建WBS的方法的是(C)

    A.自顶向下 B.自底向上 C.控制方法 D.模板参照

    任务分解方法模版类比自上而下自下而上

    4.任务分解时,(D)方法从特殊到一般的方向进行,首先定义一些特殊的任务,然后将这些任务组织起来,形成更高级别的WBS层。

    A.模板参照 B.自顶向下 C.类比 D.自底向上

    5.下列关于WBS的说法,不正确的是(D)

    A.WBS是任务分解的结果

    B.不包括再WBS中的任务就不是该项目的工作

    C.可以采用清单或者图表的形式标石WBS的结果

    D.如果项目是一个崭新的项目,最好采用自顶向下方法开发WBS

    6.检验WBS分解结果的标准不包括以下那一项?(B)

    A.最底层的要素是否是实现目标的充分必要条件

    B.分解的层次不少于3层

    C.最底层元素是否有重复

    D.最底层要素是否有清晰完整定义

    7.WBS是对项目由粗到细的分解过程,它的结构是(B)

    A.分层的集合结构  B.分级的树形结构  C.分层的线性结构  D.分级的图状结构

    8.任务分解时,(B)方法从一般到特殊的方向进行,从项目的大局着手,然后逐步分解子细目,将项目变为更细、更完善的部分。

    A.模板参照  B.自顶向下  C.类比  D.自底向上

    四.问答题

    1、试写出任务分解的方法和步骤。

    答:任务分解的基本步骤:

    1) 确认并分解项目的组成要素(WBS编号)。

    2) 确定分解标准,按照项目实施管理的方法分解,而且分解的标准要统一。

    3) 确认分解是否详细,是否可以作为费用和时间估计的标准,明确责任。

    4) 确定项目交付成果(可以编制WBS字典)。

    5) 验证分解正确性。验证分解正确后,建立一套编号系统。

    任务分解方法:(1) 模板参照方法(2) 类比方法(3) 自上而下(4)自下而上

    2、当项目过于复杂是,可以对项目进行任务分解,这样做的好处是什么?

    答:将一个项目分解为更多的工作细目或者子项目,使项目变得更小更易管理更易操作,这样可以提高估算成本时间和资源的准确性使工作变得更易操作责任分工更加明确

    第六章

    一、填空题

    1.软件项目成本包括直接成本间接成本,一般而言,项目人力成本归属于(直接)成本。

    2.再在项目初期,一般采用的成本估算方法是(类比估算法)。

    3.功能点方法中5类功能组件的计数项是(外部输入)、(外部输出)、(外部查询)、(内部逻辑文件)、(外部接口文件)。

    4.敏捷项目一般采用(故事点)估算方法。

    5.(用例点)方法通过分析用例角色、场景和技术与环境因子等来进行软件估算。

    二.判断题

    1.故事点估算是一个相对的估算过程。(√)

    2.在软件项目估算中,估算结果是没有误差的。(×)

    3.人的劳动消耗所付出的代价是软件产品的主要成本。(√)

    4.功能点估算与项目所使用的语言和技术有关。(×)

    5.COCOMO81有3个等级的模型:有机型、嵌入型、半嵌入型。(×)半有机

    6.经验对于估算来说不重要。(×)

    7.估算时既要考虑直接成本又要考虑间接成本。(√)

    8.在进行软件估算的时候,可以直接考虑参照其他企业的模型进行项目估算。(×)

    9间接成本是与一个具体项目相关的成本。(×)

    三.选择题

    1.三点估算法选择的3种估算值不包括(D)

    A.最可能成本  B.最乐观成本  C.最悲观成本  D.项目经理估算值

    2.下面关于估算的说法,错误的是(C)

    A.估算是有误差的

    B.估算时不要太迷信数学模型

    C.经验对于估算来说不重要

    D.历史数据对于估算来说非常重要

    3.假设某项目的注册功能为3个故事点,而其中成绩录入工作量比注册功能工作量略多,如果采用Fibonacci 等级标准估算,则成绩录入功能的估算值的(A)

    A.5个故事点   B.4个故事点   C.6个故事点   D.7个故事点

    斐波那契数列(Fibonacci)f(n)=f(n-1)+f(n-2) (4-1)+(4-2)=5

    4.(B)是成本的主要因素,是成本估算的基础。

    A.计划 B.规模 C.风险 D.利润

    5.常见的成本估算方法不包括(D)

    A.代码行 B.功能点 C.类比法 D.关键路径法

    6.下列不是UFC的功能计数项是(C)

    A.外部输出 B.外部文件 C.内部输出 D.内部文件

    7.成本预算的目的是(A)

    A.生产成本基线 B.编写报告书 C.指导设计过程 D.方便进度管理

    8.下列不是软件项目规模单位的是(D)

    A.源代码长度(LOC) B.功能点(FP) C.人天、人月、人年 D.小时

    9.在成本管理过程中,每个时间段中等各个工作单元的成本是(B)

    A.估算 B.预算 C.直接成本 D.间接成本

    四.计算题

    1.项目经理正在进行一个图书馆信息查询系统的项目估算,他采用Delphi的专家估算方法,邀请了3位专家进行估算,第一位专家给出了2万元、7万元、12万元的估算值,第二位专家给出了4万元、6万元、8万元的估算值,第三位专家给出了2万元、6万元、10万元的估算值,试计算这个项目的成本估算值。

    答:专家一:Ei=(ai+4mi+bi)/6=(2+4*7+12)/6=7

    专家二:Ei=(ai+4mi+bi)/6=(4+4*6+8)/6=6

    专家三:Ei=(ai+4mi+bi)/6=(2+4*6+10)/6=6

    Ei=(7+6+6)/3=6.33(万元)

    2.如果某软件公司正在进行一个项目,预计有50KLOC的代码量,项目是中等规模的半嵌入型的项目,采用中等COCOMO模型,项目属性中只有可靠性为很高级别(即取值为1.3),其他属性为正常(书上说,正常就是1),计算项目是多少人月的规模,如果是2万元/人月,则项目的费用是多少?

    答:Effort=a*(KLOC)^b*F

    查表a=3,b=1.12,F=1

    Effort=3.0*50^1.12*1.3*1=311.82(人月)

    所以项目的费用为2* Effort=623.64万元

    3.已知某项目使用C语言完成,该项目共有85个功能点,请用IBM模型估算源代码行数、工作量、项目持续时间、人员需要量以及文档数量。

     

    答:C语言代码行与功能点的关系近似为150LOC/FP,所以,85个功能点代码行数为L85*150=12750行=12.75KLOC,则:工作量估算E=5.2*L0.91=5.2*12.750.91≈52.725(人月)

    项目时间  D=4.1*L0.36=4.1*12.75^0.36≈10.25(月)

    人员需求量S=0.54*E0.6=0.54*12.75^0.6≈5.829(人)

    文档数量  DOC=49*L1.01=49*12.75^1.01≈640.857(页)

    第七章

    一、填空题

    1. (关键路径)决定了项目在给定的金钱关系和资源条件下完成项目所需的最短时间。

    2. (时间)是一种特殊的资源,以其单向性、不可重复性、不可替代性而有别于其他资源。

    3. 在ADM网络图中,箭线表示(活动/任务)。

    4. (应急法)和(平行作业法)都是时间压缩法。

    5. 工程评估评审技术采用加权平均的公式是(PERT历时=(O+P+4M)/6),其中O是乐观值,P是悲观值,M是最可能值。

    二、判断题

    1. 一个工作也可以通过多个活动完成。(√)

    2. 在项目进行过程中,关键路径是不变的。(×)

    3. 在PDM网络图中,箭线表示的是任务之间的逻辑关系,节点表示的是活动。(√)

    4. 项目各项活动之间不存在相互联系与相互依赖关系。(×)

    5. 在资源冲突问题中,过度分配也属于资源冲突。(√)

    6. 浮动是在不增加项目成本的条件下,一个活动可以延迟的时间量。(×)

    7. 在使用应急法压缩时间时,不一定要在关键路径上选择活动来进行压缩。(×)

    8. 时间是项目规划中灵活性最小的因素。(√)

    9. 外部依赖关系又称强制性依赖关系,指的是项目活动与非项目互动之间的依赖关系。(×)

    10. 当估算某活动时间,存在很大不确定性时应采用CPM估计。(×)关键路径法CPM

    11.敏捷项目一般采用远粗近细的计划模式,敏捷的发布计划相当于远期计划,迭代计划相当于近期计划(√)

    三. 选择题

    1. 下面说法中不正确的是(D)

    A.EF=ES+duration            B.  LS=LF-duration

    C.TF=LS-ES=LF-EF            D.  EF=ES+lag

    2. “软件编码完成之后,我才可以对它进行软件测试”,这句话说明了哪种依赖关系?(A)

    A.强制性依赖关系        B.软逻辑关系        C.外部依赖关系        D.里程碑

    3. (A)可以显示任务的基本信息,使用该类图能方便的查看任务的工期、开始时间、结束时间以及资源的信息。

    A.甘特图        B.网络图            C.里程碑图        D. 资源图

    4. (C)是项目冲突的主要原因,尤其在项目后期。

    A.优先级问题        B.人力问题            C.进度问题        D. 费用问题

    5. 以下哪一项是项目计划中灵活性最小的因素?(A)

    A.时间        B.人工成本            C.管理        D. 开发

    6. 以下哪一项不是任务之间的关系?(D)

    A.结束-开始        B.开始-开始            C.结束-结束        D. 结束-开始-结束

    7. 快速跟进是指(A)

    A.采用并行执行任务,加速项目进展      B. 用一个任务取代另外的任务

    C.  如有可能,减少任务数量                D. 减轻项目风险

    8. 下面哪一项将延长项目的进度?(A)

    A.lag        B.lead            C.赶工        D.快速跟进

    9. 下面哪一项可以决定进度的灵活性?(B)

    A.PERT        B.总浮动            C.ADM        D. 赶工

    10.(B)可以表示敏捷项目的进度,并且可以表示出剩余的任务

    A.燃起图   B.燃尽图   C.里程碑图 D.网络图

    四. 问答题

    1. 对一个任务进行进度估算时,A是乐观者,估计用6天完成,B是悲观者,估计用24天完成,C是有经验者,认为最有可能用12天完成,那么这个任务的历时估算介于10天到16天的概率是多少?

    解:E=(6+24+4*12)/6=13,    δ=(24-6)/6=3   E-δ=10  E+δ=16

    所以任务历时估算介于10——16天的概率为:68.3%

    2. 请将下图所示的PDM(优先图法)网络图改画为ADM(箭线法)网络图。

    解:上图对应的ADM图如下所示:

     

    3.根据下面任务流程图和下表给出的项目历时估算值,采用PERT方法估算,求出项目在14.57天内完成的概率的近似值。

    解:E1=(2+6+4*3)/6=20/6,E2=(4+8+4*6)/6=6,E3=(3+6+4*4)/6=25/6

    任务方差、标准差分别为:

    图4

     

    所以,E= E1+ E2+ E3=13.5天,δ=1.07

    E-δ=12.43,E+δ=14.57            [12.43,14.57]的概率为:68.3%

    E-2δ=11.36,E+2δ=15.64            [11.36,15.64]的概率为:95.5%

    E-3δ=10.29,E+3δ=16.71            [10.29,16.71]的概率为:99.7%

    所以,项目在14.57天内完成的概率为:50%+68.3%/2=84.15%

    第八章

    一、填空题

    1、(审计)是对过程或产品的一次独立质量评估。

    2、质量成本包括预防成本和(缺陷成本)。

    3、(软件质量)是软件满足明确说明或者隐含的需求的程度。

    4、McCall质量模型关注的3个方面是(产品运行)、(产品转移)、(产品修改)。

    5、质量管理总是围绕着质量保证和(质量控制)过程两个方面进行。

    6、质量保证的主要活动是(项目执行过程审计)和(项目产品审计)。

    二、判断题

    1、质量是满足要求的程度,包括符合规定的要求和客户隐含的需求。(√)

    2、软件质量是软件满足明确说明或者隐含的需求的程度。(√)

    3、软件质量可以通过后期测试得以提高。(×)

    4、质量计划可以确定质量保证人员的特殊汇报渠道。(√)

    5、软件质量是代码正确的程度。(×)

    6、敏捷项目要求全程的质量审查(×)

    三、选择题

    1、下列不属于质量管理过程的是(D)

    A 质量计划 B 质量保证 C 质量控制 D 质量优化

    2、项目质量管理的目标是满足(C)的需要

    A 老板 B 项目经理 C 项目 D 组织

    1. 下列属于质量成本的是(A、D)

    A 预防成本 B 缺陷数量 C 预测成本 D 缺失成本

    4、下列不是质量计划方法的是(C)

    A 质量成本分析 B 因果分析图 C 抽样分析 D 基准对照

    5、下列不是软件质量模型的是(D)

    A Boehm质量模型  B McCall 质量模型 C ISO/IEC 9216质量模型 D Mark质量模型

    6、质量控制非常重要,但是进行质量控制也需要一定的成本,(B)可以降低质量控制的成本。

    A 进行过程分析  B 使用抽样统计 C 对全程进行监督  D 进行质量审计

    7、McCall 质量模型不包含(C)

    A 产品修改  B 产品转移  C 产品特点 D 产品运行

    8、下面(D)不是敏捷项目的质量实践

    A.结对编程  B.TDD  C.迭代评审  D.需求规格编写过程审计

    四、问答题

    1、简述质量保证的主要活动,以及质量保证的要点。

    答:质量保证的主要活动是项目执行过程审计项目产品审计

    质量保证的要点是:对项目进行评价推测能否达到质量指标、建立对项目的信心

    2、简述质量保证与质量控制的关系。

    答:质量保证(QA)是通过评价项目整体绩效,建立对质量要求的信任,提供项目和产品可视化的管理报告。这个任务本身并不能提高产品的质量,但是通过质量保证的一系列工作可以间接地提高产品的质量。质量保证一般由质量保证部门人员实施。

    质量控制(QC)是确定项目结果与质量标准是否相符,同时,确定消除不符的原因和方法,它控制产品的质量,及时纠正缺陷。这个任务本身提高产品的质量,一般由开发人员实施。

    质量保证是后期质量活动质量控制是前期质量活动。它们是有区别的:质质量保证是针对项目实施过程的管理手段,质量控制是针对项目产品的技术手段;实施质量保证是针对过程改进和审计的,强调的是过程改进和信心保证。实施质量控制是按照质量要求,检查具体可交付成果的质量,强调的是具体的可交付成果。

    第九章

    一、填空题

    1、(完整性和可跟踪性)是软件配置管理的核心功能。

    2、(基线)标志开发过程中一个阶段的结束和里程碑。

    3、 基线变更控制包括(变更请求)、(变更控制)、(变更批准/拒绝)、(变更实现)等步骤。

    4、(版本管理)、(变更管理)是配置管理的主要功能。

    5、基线变更时,需要经过(SCCB)授权。

    6、SCCB的全称是(软件配置控制委员会)。

    二、 判断题

    1、一个软件配置项可能有多个标识。(×)

    2、基线提供了软件开发阶段的一个特定点。(×)

    3、有效的项目管理能够控制变化,以最有效的手段应对变化,不断命中移动的目标。(√)

    4、 一个(些)配置项形成并通过审核,即形成基线。(√)

    5、软件配置项是项目需定义其受控于软件配置管理的款项,每个项目的配置项是相同的。(×)

    6、基线的修改不需要每次都按照正式的程序执行。(×)

    7、基线产品是不能修改的。(×)

    8、基线修改应受到控制,但不一定要经SCCB授权。(×)

    9、变更控制系统包括从项目变更申请、变更评估、变更审批到变更实施的文档化流程。(√)

    10、持续支付领域强调对项目所有的相关产物及其之间的关系都要进行有效配置管理(√)

    11、持续支付更倾向于使用基于分支的开发模式(×)

    三、 选择题

    1、 下列不属于SCCB的职责的是(D)

    A 评估变更 B 与项目管理层沟通 C 对变更进行反馈 D 提出变更申请

    2、为了更好地管理变更,需要定义项目基线,关于基线的描述,下列描述正确的是(B)

    A 不可变化

    B 可以变化,但是必须通过基线变更控制流程处理

    C 所以的项目必须定义基线

    D 基线发生变更时,必须修改需求

    3、软件配置管理无法确保以下哪种软件产品属性(A)

    A 正确性  B 完整性  C 一致性 D 可控性

    4、变更控制需要关注的是(B)

    A 阻止变更     B 标识变更,提出变更,管理变更

    C 管理SCCB     D 客户的想法

    5、以下哪项不是项目配置管理中可能遇到的问题?(B)

    A 找不到某个文件的历史版本

    B 甲方与乙方在资金调配上存在意见差异

    C 开发人员未经授权修改代码或文档

    D 因协同开发中,或者异地开发,版本变更混乱导致整个项目失败

    四、简答题

    1、 写出配置管理的基本过程。

    答:(1)配置项标识、跟踪;(2)配置管理环境建立;(3)基线变更管理;(4)配置管理审计;(5)配置状态统计;(6)配置管理计划

    2、 说明软件配置控制委员会(SCCB)的基本职责。

    答:评估变更批准变更申请在生存期内规范变更申请流程对变更进行反馈、与项目管理层沟通

    3、 写出几个常见的软件配置项。

    答:软件项目计划需求分析结果软件需求规格说明书设计规格说明书源代码清单厕所规格说明书测试计划测试用例与实验结果可执行程序用户手册维护文档

    第十章

    一、填空

    1、 可以充分发挥部门资源优势集中的组织结构为(职能型组织结构

    2、 组织结构的主要类型(职能型)、(项目型)、(矩阵型

    3、 (会议形式)沟通最有可能协助解决复杂的问题。

    4、 当项目中有20个人时,沟通渠道最多有(190)。

    二、判断

    1、项目干系人是项目计划的一部分。(√)

    2、项目型的优点是可以资源共享。(×)

    3、应尽量多建立一些沟通渠道。(×)

    4、项目沟通的基本原则是及时性、准确性、完整性和可理解性(√)

    5、在IT项目中,成功的最大威胁是沟通的失败(√)

    6、责任分配矩阵是明确项目团队成员的角色与职责的有效工具(√)

    7、口头沟通不是项目沟通的方式(×)

    8、对于紧急的信息,应该通过口头的方式沟通;对于重要的信息,应采用书面的方式沟通(√)

    9、沟通计划包括确定谁需要信息,需要什么信息,何时需要信息,以及如何接收信息等(√)

    10、敏捷团队的人员一般在3~9人,而且一般集中地在一个场地开发,可以围坐一个桌子开会(√)

    三、选择

    1、(A)以图形方式展示项目团队成员及其报告关系这样可以减少沟通渠道,减少成本

    A、项目组织图  B、甘特图   C、网络图   D、RAM图

    2、下面不是敏捷角色的是(D)

    A、产品负责人  B、团队促进者  C、跨职能团队成员  D、合同管理者

    3、在项目管理的3种组织结构中,适用于主要由一个部门完成的项目或技术比较成熟的项目组织结构是( C)

    A矩阵型组织结构  B项目型组织结构   C职能型组织结构  D都一样

    4、项目经理花在沟通上的时间是(B)

    A、20%-40%  B、75%-90%  C、60%   D、 30%-60%

    5、在(C)组织结构中,项目成员没有安全感

    A职能型 B矩阵型 C项目型 D弱矩阵型

    6、下列关于干系人的描述中,不正确的是(D)

    A影响项目决策的个人、群体或者组织

    B影响项目活动的个人、群体或者组织

    C影响项目结果的个人、群体或者组织

    D所有项目人员

    7、编制沟通计划的基础是( A)

    A沟通需求分析 B项目范围说明书 C项目管理计划    D历史资料

    8、项目团队原来有5个成员,现在人员扩充,又增加了3个成员这样沟通渠道增加了(A)

    A、2.8倍  B、两倍  C、4倍  D、1.6倍

    沟通渠道=N(N–1)/2

    9、对于项目中比较重要的通知,最好采用(B)沟通方式

    A口头 B书面 C网络方式 D电话

    10、在一个高科技公司,项目经理正在为一个新的项目选择合适的组织结构,这个项目涉及多的领域和特性,他应该选择(A)组织结构

    A矩阵型 B项目型 C职能型 D组织型

    、简答题

    1、 写出5种以上项目沟通方式

    (1)书面沟通和口头沟通

    (2)语言沟通和非语言沟通

    (3)正式沟通和非正式沟通

    (4)单向沟通和双向沟通

    (5)网络沟通

    2、 对于特别重要的内容,你认为一般采用哪些方式才能确保有效沟通  

    对于特别重要的内容,要采用多种方式进行有效沟通确保传达到位,除发送邮件外还要电话提醒、回执等,重要的内容还要通过举行各种会议进行传达

    第十一章

    一、填空题

    1.风险评估的方法包括(定性)和定量风险分析。

    2.决策树分析是一种(形象化的图表分析)方法。

    3.项目风险的三要素是(风险事件)、(风险事件发生的概率)、(风险造成的影响)。

    4.(回避)风险是指尽可能地规避可能发生的风险,采取主动放弃或者拒绝使用导致风险的方案。

    5.定量风险评估主要包括(访谈)、(盈亏平衡分析)、(决策树分析)、(模拟法)、(敏感性分析)等方法。

    二、判断题

    1.任何项目都是有风险的。(√)

    2.风险是损失发生的不确定性,是对潜在的、未来可能发生损害的一种度量。(×)

    3.风险识别、风险评估、风险规划、风险控制是风险管理的4个过程。(√)

    4.应对风险的常见策略是回避风险、转移风险、损失控制和自留风险。(√)

    5.项目的风险几乎一样。(×)

    6.购买保险是一种回避风险的应对策略(×)

    7.敏捷项目没有长期计划,这本身也是一个风险,因为存在一些无法识别的风险。(错)

    三、选择题

    1.下列不属于项目风险的三要素的是(B)。

    A.一个事件  B.事件的产生原因  C.事件发生的概率  D.事件的影响

    2.下列属于可预测风险的是(C)。

    A.不现实的交付时间  B.没有需求或软件范围的文档

    C.人员调整   D.恶略的开发环境

    3.下列不是风险管理过程的是(D)

    A.风险评估  B.风险识别  C.风险规划  D.风险收集

     

    4.下列说法错误的是(D)。

    A.项目风险的3个要素是一个事件、事件发生的概率、事件的影响

    B.风险规划的4个过程是风险识别、风险评估、风险规划、风险控制

    C.风险规划的主要策略是回避风险、转移风险、损失控制、自留风险

    D.项目风险是由风险发生的可能性决定的

    5.在一个项目的开发过程中采用了新的技术,为此,项目经理找来专家对项目组人员进行技术培训,这是什么风险应对策略?(B)。

    A.回避风险  B.损失控制  C.转移风险  D.自留风险

    6.下列不属于风险评估方法的是(D)。

    A.盈亏平衡分析  B.模拟法  C.决策树分析  D.二叉树分析

    四、问答题

    1.一个项目在进行规划的时候,碰到了一个风险问题,项目经理决定是否采用方案A。如果采用方法A需要使用一个新的开发工具,而能够掌握这个工具的概率是30%,通过使用这个工具可以获利5万元,如果采用方案A而不能掌握这个工具,将损失1万元。利用决策树分析技术说明这个项目经理是否应该采用这个方案A?(绘制决策树)

    图5

     

    通过上面分析可知,应该采用方案A。

     

    2.某企业在今年有甲乙两种产品方案可以选择,每种方案的状态、收益和概率如表11-11所示,绘制决策树时,判断哪种方案将有更大收益。

    图6~8

     

    答:

     

     

    第十二章

    一、 填空

    1. 为执行项目而从项目团队外获取产品、服务或者成果的过程称为:(采购)

    2. 合同双方当事人承担不同角色,这些角色包括:(甲方)、(乙方)

    3. 一个CPFF合同类型,估计成本是10万元,固定费用是成本1.5万元,当成本提高至20万元是,合同金额为:(21.5万元)

    二、 判断

    1. 软件项目外包的实质是软件开发过程从公司内部部分或者全部延伸到公司外部的过程(×)

    2. 对于甲方来说,风险最高的是CPCC合同类型,风险最低的是FFP合同类型,乙方则相反(√)

    3. 如果一个项目的合同类型是固定价格(FFP),合同价格是100万元,实际花费是160万元,则项目结算金额为160万元(×)

    4. 成本加激励费用(CPIF)合同居有激励机制(√)

    5.《敏捷宣言》认为“客户协作高于合同协商”(√)

    三、 选择

    1、 下列合同类型中,卖方承担的风险最大的是(D)

    A.成本加成本百分比  B.成本加固定费  C.成本加奖金  D. 固定价格

    2、 某项目采用成本加奖金的成本补偿类合同,当预算成本为20万元,利润4万元,且奖励分配为80/20时,如果实际成本降至16万元,则项目总价为(C)。

    A.24万元   B.23.2万元   C.20.8万元  D.20万元

    3、 合同是需要靠(D)约束的。

    A.双方达成的共识  B.道德   C.责任  D.相关法律法规

    4、下面哪项不是敏捷项目设计的动态特性的合同签署技术(D )

    A.多层结构   B.总结增量  C.动态范围方案   D.固定价格

     

    展开全文
  • 小任老师帮你梳理软考系统集成项目管理工程师考试重点、难点,19年下半年四个案例题成功预测正确三个题,18年下半年四个案例题成功预测正确三个题,18年上半年四个案例成功预测两题,17年下半年四个案例成功预测两题...
  • 小任老师帮你梳理软考系统集成项目管理工程师考试重点、难点并预测考试重点。2020年下半年成功预测下午案例分析四道题中的二道题。 2019年下半年成功预测下午案例分析四道题中的三道题。18年下半年四个案例题成功...
  • 接到任务后,项目经理小王开始着手编制项目管理计划,根据招标文件,小王列出了一个初步的进度计划,进度计划中的各里程碑点正好是甲方招标文件中规定的各时间节点。随后,小王估计了项目的各项开销,确定了项目预算...

    试题一

    某系统集成A公司中标了一个地铁综合监控系统项目,该项目是地铁运营公司公开招标的地铁S号线建设项目中的一个信息系统子项目,涉及信号系统、电气控制系统、广播系统、视频监控系统、通信网络系统的信息互通和集中控制,需要集成多种厂商的设备。

    接到任务后,项目经理小王开始着手编制项目管理计划,根据招标文件,小王列出了一个初步的进度计划,进度计划中的各里程碑点正好是甲方招标文件中规定的各时间节点。随后,小王估计了项目的各项开销,确定了项目预算。项目团队已由公司指派,小王召开了项目启动会,将各项任务分配给项目组成员。

    项目进行了一段时间后,由于天气原因,导致地铁土建工作的延误,因此影响到各厂商设备进场,整个项目进度滞后,监理方与建设方发布了延期通知。项目经理小王马上召开项目会议,口头通知项目组成员所以工作均推迟开展。

     

    【问题1】

    (1)请结合案例指出小王制定的初步进度计划中存在的最主要问题。

    (2)请结合案例简要叙述在制定进度计划时通常应考虑哪些主要制约问题。

     

     

     

    【问题2】

    请结合案例分析小王在项目管理过程中存在的问题。

     

     

     

     

    【问题3】

     请简要叙述项目管理计划编制工作流程。

     

     

     

     

    试题二

    系统集成商A与生产型企业B签订了一份企业MIS(管理信息系统)开发合同,合同已执行到设计和开发阶段,由于企业B内部组织结构调整,可能会影响核心业务的流程。集成商A提出建议,合同暂停执行至新的组织机构确定之后,双方经过会议协商和沟通,同意上述建议,后续工作再另行协商确定。

    6个月后,企业B组织结构基本确定,要求继续执行合同,并表示可将工期延后6个月。但集成商A原来参与项目的部分人员离职,新的项目组成员对该项目不熟悉,通过仔细阅读原来的需求文件还是无法理解MIS系统的需求。同时,由于企业B组织结构的调整导致原需求发生了较大变化,因此不得不重新进所有的需求调研。

    项目继续开展了1个月后,集成商A提出需要增加合同费用,理由是新的需求导致工作量增加,软件系统需要重新开发。但企业B认为需求变更是正常的,集成商A之所以工作量增加也是由于原来的项目文档保留不完整,并且人员更换等原因造成的。双方未就合同变更达成一致,陷入僵局。随后,企业B考虑是否使用法律手段来解决纠纷,但发现整个合同执行过程的备忘录和会议记录都没有,无法提出直接的证据材料。

     

    【问题1】

    请结合案例分析在合同管理和文档管理过程中集成商A和企业B共同存在的问题。

     

     

     

     

     

    【问题2】

    请结合案例分析集成商A在项目管理方面存在的问题。

     

     

     

     

     

     

    【问题3】

    结合案例简要叙述为使项目继续执行双方应该做的工作。

     

     

     

     

     

     

    【问题4】

    从候选答案中选择2个正确选项,将选项编号填入答题纸对应栏内。

    合同法规定的违约责任承担方式不包括       。

    A.不予承认 B.继续履行 C.采取补救措施 D.赔偿 E.支付违约金 F.终止

     

     

     

    试题三

    某项目6个月的预算如下表所示。表中按照月份和活动给出了相应的PV值,当项目进行到3月底时,项目经理组织相关人员对项目进行了绩效考评,考评结果是完成计划进度的90%。

     

    【问题1】

    请计算3月底时项目的SPI、CPI、CV、SV、值,以及表中1、2处的值(注:表中1处代表“编制计划”活动的EV的值,表中2处代表“概要设计“活动的EV值)。

     

     

     

     

    【问题2】

    (1)如果项目按照当前的绩效继续进行,请预测项目的ETC(完成时尚需估算)和EAC(完成时估算)。

    (2)请评价项目前3月的进度和成本绩效并提出调整措施。

     

     

     

    【问题3】

    假设项目按照当前的绩效进行直至项目结束,请在下图中画出从项目开始直到结束时的EV和AC的曲线,并在图中用相应的线段表明项目完成时间与计划时间的差(用“t”标注)、计划成本与实际成本的差(用“c”标注)。

     

     

    试题四

    某企业A承接了某一中心城市数字城管工程建设项目,委派小刘负责该项目的质量保证工作。在项目的执行过程中,由于数字城管建设涉及到该市的很多职能部门,互相之间的协调和沟通费时、费力,且在不同单位之间存在需求方面的不一致,导致项目质量管理活动很难开展。

    【事件1】鉴于沟通协调的困难,项目团队建议小刘暂时弱化对项目的质量管理工作,由项目开发团队先开展工作,然后等合适的时机再补充相关质量手续。小刘也考虑到目前项目成本超支、进度滞后的现状,默许了项目组这样的做法。

    【事件2】由于项目进度滞后,为了节约招标时间,项目经理决定对部分产品的采购实行竞争性谈判,通过邀请招标的方式与两家企业谈判,并确定了最终供应方。

    【事件3】企业A另委派小王负责该项目的质量管理工作,小王认为目前项目在管理方面存在很多问题,特别是团队沟通方面的问题对项目的影响不容忽视,虽然小王认为改善团队沟通不应该是他的职责,但还是提出了自己的建议。

     

    【问题1】

    在事件1中,项目组的做法是否恰当?小刘作为质量保证人员,应做好哪些工作?

     

     

     

    【问题2】

    结合事件2中的相关内容,请说明项目组的做法是否合适;并简要指出小刘作为质量保证人员在项目采购中应具体负责哪些工作。

     

     

     

    【问题3】

     结合事件3,请简要叙述小王就项目团队沟通状况可提出哪些改善建议。

    展开全文
  • 本人参加的是2017年上半年信息系统项目管理师考试,今天看到2017上半年考试的成绩合格分数为45,也算是侥幸通过,在这里写一写自己是如何备考的,供各位考友参考一下。 这里说的50天是指白天上班以业余时间备考所需...
  • 参加工作后,我们没有太多的时间投入到信息系统项目管理师的备考中,教程太厚、真题太难,怎样花少的时间顺利通过软考考试是每个人都在探索的问题。看视频,小任老师帮你把握考试重点,用短的时间,让你学到应该掌握...
  • 2009年上半年 系统集成项目管理工程师 上午试卷 (考试时间 9 : 00~11 : 30 共 150 分钟) 请按下述要求正确填写答题卡 1. 在答题卡的指定位置上正确写入你的姓名和准考证号,并用正规 2B 铅笔在你...
  • 传统项目管理 VS 敏捷项目管理

    千次阅读 2019-10-08 19:04:02
    项目管理 项目管理广泛应用于软件开发行业,完整的项目管理包含五个部分,分别是:项目启动、项目规划、项目执行、项目监控、项目收尾。 随着软件行业的发展,传统的敏捷项目管理模式,已经不适应于当前互联网行业...
  • 课程深刻的讲解了项目管理思想精髓,列举了大量生活案例以理解项目管理,大量工作运用以让项目管理和工作结合起来。通过案例讲解、快速和自己工作内容相结合,让项目管理知识快速“落地”,顺利通过PMP考试。
  • 项目管理进阶–软件开发项目中的团队组成项目经理 项目经理负责分配资源,确定优先级,协调与客户和用户之间的交往。总而言之,就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法,以确保项目...
  • 信息系统项目管理师 - 项目整体管理 信息系统项目管理师 - 项目整体管理 版权声明:转载必须注明本文转自 East196 的博客:http://blog.csdn.net/east196 ...
  • 小任老师帮你梳理软考系统集成项目管理工程师考试重点、难点并预测考试重点。2020年下半年成功预测下午案例分析四道题中的二道题。 2019年下半年成功预测下午案例分析四道题中的三道题。18年下半年四个案例题成功...
  • 信息系统项目管理--论文分析笔记

    万次阅读 2019-10-22 10:47:29
    信息系统项目管理–论文分析 (1)整体管理 制定项目章程 1.项目发起人发布了这个文件,项目启动了,我被授权了 2.项目章程的内容(6个项目,2个总体,2个其他) 制定项目管理计划 1.和大家一起制定了一个项目...
  • 组织级项目管理(Organizational Project Management,OPM)。  OPM是一种战略执行框架,通过应用项目管理、项目集管理、项目组合管理及组织驱动实践,不断地以可预见的方式取得更好的绩效、更好的结果及可持续...
  • 2015年下半年 信息系统项目管理师 下午试卷 II (考试时间 15:20~17:20 共 120 分钟) 1. 本试卷满分 75 分。 2. 在答题纸的指定位置填写你所在的省、自治区、直辖市、计划单列市的名称。 3. 在答题纸的指定...
  • 小任老师帮你梳理软考信息系统项目管理师考试重点、难点。2020年下半年成功预测案例分析三题中的二道题。 2019年下半年成功预测案例分析三题中的二道题,论文成功预测:沟通管理。  2018年下半年成功预测案例...
  • 2009年上半年 信息系统项目管理师 上午试卷 (考试时间 9 : 00~11 : 30 共 150 分钟) 1. 在答题卡的指定位置上正确写入你的姓名和准考证号,并用正规 2B 铅笔在你写入的准考证号下填涂准考证号。 2. 本试卷的...
  • 2018上半年信息系统项目管理师下午试卷I (考试时间14:00~16:30共150分钟) 1.在答题纸的指定位置填写你所在的省、自治区、直辖市、计划单列市的名称。 2.在答题纸的指定位置填写准考证号、出生年月日和姓名。 ...
  • 2011年上半年 信息系统项目管理师 上午试卷 (考试时间 9 : 00~11 : 30 共 150 分钟) 1. 在答题卡的指定位置上正确写入你的姓名和准考证号,并用正规 2B 铅笔在你写入的准考证号下填涂准考证号。 2. 本试卷的...
  • 项目管理工具】SVN 项目版本管理工具

    万次阅读 多人点赞 2018-08-02 18:05:40
    1.1 项目管理中的版本控制问题 解决代码冲突困难 容易引发bug 难于恢复至以前正确版本 无法进行权限控制 项目版本发布困难 1.2 什么是版本控制 版本控制是维护工程蓝图的标准做法,能追踪工程蓝图从诞生一致...
  • 软件开发项目管理软件 软件 类型 功能 优势 劣势 开源 confuence 协作共享 知识管理与协同 Scrum 付费 禅道 项目管理 产品管理、项目管理、质量管理、文档管理、组织管理和事务管理 Java架构、issues控制...
  • 软件项目管理案例教程 第4版 课后习题答案

    万次阅读 多人点赞 2019-11-30 01:18:05
    软件项目管理案例教程 第4版 课后习题答案 第一章 一、填空题 1.敏捷模型包括(4)个核心价值,对应(12)个敏捷原则。 2.项目管理包括(启动过程组)、(计划过程组)、(执行过程组)、(控制过程组)、(收尾...
  • 信息系统项目管理师考试辅导教程(第3版)

    千次下载 热门讨论 2013-01-29 20:12:39
    《全国计算机技术与软件专业技术资格(水平)考试用书:信息系统项目管理师考试辅导教程(第3版)》由希赛教育软考学院组织编写,作为计算机技术与软件专业资格(水平)考试中的信息系统项目管理师级别的考试辅导指定教程...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 312,352
精华内容 124,940
关键字:

项目管理