立项管理

大纲

1. 项目建议书
2. 项目可行性研究（项目论证、项目评估）
3. 项目审批
4. 项目招投标
5. 项目合同谈判与签订

项目建议书

• 又称 立项申请
• 是项目建设单位向上级主管部门提交项目申请时所必须的文件
• 是对拟建项目提出的框架性的总体设想
• 核心内容如下：
  1. 项目的必要性
  2. 项目的市场预测
  3. 产品方案或服务的市场预测
  4. 项目建设必需的条件

项目可行性研究-阶段

1. 机会可行性研究
2. 初步可行性研究
3. 详细可行性研究
4. 项目可行性研究报告的编写、提交和获得批准
5. 项目评估

项目可行性研究-内容

1. 投资必要性。根据市场调查及预测、有关的产业政策等因素，论证项目投资建设的必要性
2. 技术的可行性。从项目实施的技术角度，合理设计技术方案，并进行比较、选择和评价
3. 财务可行性。主要从项目及投资者的角度，设计合理财务方案，从企业理财的角度进行资本预算，评价项目的财务盈利能力，进行投资决策，并从融资主体（企业）的角度评价股东投资收益、现金流量计划及债务偿还能力
4. 组织可行性。制订进度计划、设计组织机构、选择管理人员、建立协作关系、制订培训计划等，保证项目顺利执行。
5. 经济可行性。主要是从资源配置的角度衡量项目的价值，评价项目在实现区域经济发展目标、有效配置经济资源、增加供应、创造就业、改善环境、提高人民生活等方面的效益。
6. 社会可行性。主要分析项目对社会的影响，包括政治体制、方针政策、经济结构、法律道德、宗教民族、妇女儿童及社会稳定性等
7. 风险因素及对策。主要是对项目的市场风险、技术风险、财务风险、组织风险、法律风险、经济及社会风险等因素进行评价，制定规避风险的对策，为项目全过程的风险管理提供依据

初步可行性研究

• 研究并回答下面的一些问题

  1. 项目进行投资建设的必要性
  2. 项目建设的周期
  3. 项目需要的人力、财力资源
  4. 项目的功能和目标是否可以实现
  5. 项目的经济效益、社会效益是否可以保证
  6. 项目从经济上、技术上是否是合理的

• 初步项目可行性研究的内容与详细的项目可行性研究基本相同

• 辅助（功能）研究包括项目的一个或几个方面，但不是所有方面，并且只能作为初步项目可行性研究、项目可行性研究和大规模投资建议的前提或辅助

详细可行性研究

• 详细可行性研究的方法
  1. 投资估算法（指数估算法、因子估算法、单位能力投资估算法）
  2. 增量净效益法（有无比较法）

项目论证

• “先论证，后决策”是现代项目管理的基本原则
• 项目前评价的作用主要体现在以下几个方面：
  1. 项目论证是确定项目是否实施的依据
  2. 项目论证是筹措资金、向银行贷款的依据
  3. 项目论证是编制计划、设计、采购、施工以及机构设备、资源配置的依据
  4. 项目论证是防范风险、提高项目效率的重要保证

项目评估

• 在项目可行性研究的基础上
• 由第三方（国家、银行或有关机构）根据国家颁布的政策、法规、方法、参数和条例
• 从项目（或企业）、国民经济、社会角度出发
• 对拟建项目建设的必要性、建设条件、生产条件、产品市场需求、工程技术、经济效益和社会效益等进行评价、分析和论证，进而判断其是否可行的一个评估过程

项目评估-依据

1. 项目建议书及其批准文件
2. 项目可行性研究报告
3. 报送单位的申请报告及主管部门的初申意见
4. 有关资源、配件、燃料、水、电、交通、通信、资金（包括外汇）等方面的协议文件
5. 必需的其他文件和资料

项目审批

• 对项目建议书、可行性研究报告、初步设计方案和投资概算的批复
• 是后续项目建设的主要依据
• 批复中核定的建设内容、规模、标准、总投资概算和其他控制指标原则上应严格遵守
• 可行性研究报告的内容 与 项目建议书批复内容 有重大变更的，应重新报批项目建议书
• 项目初步设计方案和投资概算报告 与 项目可行性研究报告批复内容 有重大变更或变更投资超出已批复总投资额度10%的，应重新报批可行性研究报告
• 项目初步设计方案和投资概算报告 与 项目可行性研究报告批复内容 有少量调整且其调整内容未超出已批复总投资额度10%的，需在提交项目初步设计方案和投资概算报告时以独立章节对调整部分进行补充说明

项目招投标

1. 招标
2. 投标
3. 开标与评标
4. 中标

项目合同谈判与签订

• 合同谈判的方法一般是先谈技术条款，后谈商务条款
• 技术谈判：合同技术附件内容、实施技术路线、质量评定标准、采购设备和系统报价以及人员投入开发的比重等
• 商务谈判（投标函中的基本条件）：投标价的优惠条件；质量、工期、服务违约处罚；其他需要谈判的内容

供应商项目立项

• 系统集成商进行项目内部立项主要有几方面原因：
  1. 通过项目立项方式为项目分配资源
  2. 通过项目立项方式确定合理的项目绩效目标，有助于提升人员的积极性
  3. 以项目型工作方式，提升项目实施效率
• 内部立项时一般包括的内容：项目资源估算、项目资源分配、准备项目任务书和任命项目经理

合同管理

合同的概念

• 合同必须包括的要素：
  1. 合同的成立必须要有两个（含）以上的当事人
  2. 各方当事人须互相做出意思表示
  3. 各个意思表示达成一致
• 合同的法律特征：
  1. 合同是一种民事法律行为
  2. 合同是一种双方或多方或共同的民事法律行为
  3. 合同以在当事人之间设立、变更、终止财产性的民事权利义务为目的
  4. 订立、履行合同，应当遵守相关的法律及行政法规
  5. 合同依法成立，即具有法律约束力

合同分类

按范围

• 分为：总承包合同、单项工程承包合同、分包合同
• 分包合同必须同时满足5个条件，即：
  1. 经过买方认可
  2. 分包的部分必须是项目非主体工作
  3. 只能分包部分项目，而不能转包整个项目
  4. 分包方必须具备相应的资质条件
  5. 分包方不能再次分包

按付款

总价

• 为既定产品、服务或成果的采购设定一个总价
• 也可以为达到或超过项目目标而规定财务奖励条款
• 买方需要准确定义拟采购的产品或服务
• 包括：
  1. 固定总价合同（FFP）
  2. 总价加激励费用合同（FPIF）
  3. 总价加经济价格调整合同（FP-EPA）
  4. 订购单（非大量采购标准化产品，也叫单边合同）

成本

• 向卖方支付为完成工作而发生的全部合法实际成本，外加一笔费用作为卖方的利润
• 工作范围无法准确定义/项目工作存在较高风险
• 包括：
  1. 成本加固定费用合同（CPFF）
  2. 成本加激励费用合同（CPIF）
  3. 成本加奖励费用合同（CPAF）

image.png image.png

工料

• 在不能很快编写出准确工作说明书的情况下，经常使用
• 增加人员、聘请专家和寻求其他外部支持
• 兼具成本补偿合同和总价合同的某些特点

合同类型的选择

• 如果工作范围很明确，已具备详细的细节，使用总价合同
• 范围不清楚，工作不复杂，需要快速签订，使用工料合同
• 如果工作范围尚不清楚，则使用成本补偿合同
• 双方分担风险，则使用工料合同
• 买方承担成本风险，使用成本补偿合同
• 卖方承担成本风险，使用总价合同
• 如果是购买标准产品，且数量不大，使用单边合同

项目合同的内容

1. 当事人各自权利、义务
2. 项目费用及工程款的支付方式
3. 项目变更约定
4. 违约责任

项目合同签订的注意事项

1. 当事人的法律资格
2. 质量验收标准
3. 验收时间
4. 技术支持服务
5. 损害赔偿
6. 保密约定
7. 合同附件
8. 法律公正

合同管理的主要内容

1. 合同签订管理
2. 合同履行管理
3. 合同变更管理
4. 合同档案管理（文本管理，是整个合同管理的基础）

合同索赔

• 指在项目合同的履行过程中，由于当事人一方未能履行合同所规定的义务而导致另一方遭受损失时，受损失方向过失方提出赔偿的权利要求
• 一般，将卖方向买方的索赔称为合同索赔，将买方向卖方的索赔称为合同反索赔

分类

1. 按索赔的目的分类，可分为工期索赔和费用索赔
2. 按索赔的依据分类，可分为合同规定的索赔、非合同规定的索赔
3. 按索赔的业务性质分类，可分为工程索赔和商务索赔
4. 按索赔的处理方式分类，可分为单项索赔和总索赔

流程

1. 提出索赔要求
2. 报送索赔资料
3. 监理工程师答复
4. 监理工程师逾期答复后果
5. 持续索赔
6. 仲裁与诉讼

文档和配置管理

软件文档

分类

1. 开发文档，描述开发过程本身，包括：可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息
2. 产品文档，描述开发过程的产物，包括：培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告
3. 管理文档，记录项目管理的信息，例如：每个阶段的进度和进度变更的记录、软件变更情况的记录、开发团队的职责定义、项目计划、项目阶段报告、配置管理计划

质量分级

• 遵守GB/T 8567-2006的有关规定
  1. 最低限度文档（1级文档）。开发者自用程序
  2. 内部文档（2级文档）。没有与其他用户共享的专用程序
  3. 工作文档（3级文档）。由同一单位内若干人联合开发的程序，或可被其他单位使用的程序
  4. 正式文档（4级文档）。那些要正式发行供普遍使用的软件产品、关键性程序或具有重复管理应用性质（如工资计算）的程序

文档-管理规范

信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等方面

image.png

配置管理活动

1. 制订配置管理计划
2. 配置标识
3. 配置控制
4. 配置状态报告
5. 配置审计
6. 发布管理和交付

配置项

概念

• GB/T 11457-2006：为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待
• 分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等
• 所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放

状态

• 配置项刚建立时，其状态为“草稿”
• 配置项通过评审后，其状态变为“正式”
• 此后若更改配置项，则其状态变为“修改”
• 当配置项修改完毕并重新通过评审后，状态变为“正式”

image.png

版本号

1. 草稿：格式为 0.YZ，YZ的数字范围为01～99
2. 正式：格式为 X.Y，X为主版本号，取值范围为1～9
3. 修改：格式为 X.YZ

配置基线

• 由一组配置项组成，构成一个相对稳定的逻辑实体
• 基线中的配置项被“冻结”了，不能再被任何人随意修改
• 对基线的变更必须遵循正式的变更控制程序
• 基线通常对应于开发过程中的里程碑, 一个产品可以有多个基线，也可以只有一个基线
• 交付给外部顾客的基线一般称为发行基线
• 内部开发使用的基线一般称为构造基线

配置库

• 存放配置项并记录与配置项相关的所有信息
  1. 开发库, 也称为动态库、程序员库或工作库，保存当前正在开发的配置实体，是个人工作区，开发人员自行控制
  2. 受控库, 也称为主库，包含当前的基线加上对基线的变更。库中配置项被置于完全的配置管理之下
  3. 产品库, 也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。产品完成系统测试后，作为最终产品存入，等待交付用户或现场安装

配置库的建库模式

1. 按配置项的类型分类建库，适用于通用软件的开发组织
2. 按开发任务建立相应的配置库，适合专业软件开发组织

配置管理系统

• 用来进行配置管理的软件系统
• 确定配置管理细则和提供规范的配置管理软件

• 加强信息系统开发过程的质量控制、可控性，确保配置项的完备、清晰、一致和可追踪性，以及配置项状态的可控制性

  
  image.png

基于配置库的变更控制

image.png

配置管理工具

1. 常用付费配置管理工具有：Rational ClearCase、Perforce、CA CCC、Havest Merant PVCS、Microsoft VSS, CVS。
2. 常用的开源免费的软件配置管理工具有：SVN、GIT、CVS

变更管理

变更的常见原因

• 产品范围（成果）定义的过失或者疏忽
• 项目范围（工作）定义的过失或者疏忽
• 增值变更
• 应对风险的紧急计划或回避计划
• 项目执行过程与基准要求不一致带来的被动调整
• 外部事件

变更分类

• 根据变更性质可分为：重大变更、重要变更和一般变更。通过不同审批权限控制
• 根据变更的迫切性可分为：紧急变更、非紧急变更。通过不同变更处理流程进行

变更管理原则

1. 基准管理
2. 变更控制流程化
3. 明确组织分工
4. 评估变更的可能影响
5. 妥善保存变更产生的相关文档，确保其完整、及时、准确、清晰

变更管理组织结构

• CCB（项目控制委员会或配置控制委员会）, 负责裁定接受哪些变更。是决策机构，不是作业机构。通常工作是通过评审手段来决定项目基准是否能变更，不提出变更方案
• 项目经理，响应变更提出者的需求，评估变更对项目的影响及应对方案，将需求由技术要求转化为资源需求，供授权人决策；并据评审结果实施和调整基准

变更控制工作程序

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

小项目变更

• 项目规模小，与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高效
• 小项目变更仍应注意以下几点：
  • 对变更产生的因素施加影响：防止不必要的变更，减少无谓的评估，提高必要变更的通过效率
  • 对变更的确认应当正式化
  • 变更的操作过程应当规范化

对进度变更的控制

1. 判断项目进度的当前状态
2. 对造成进度变化的因素施加影响
3. 查明进度是否已经改变
4. 在实际变化出现时对其进行管理

对成本变更的控制

1. 对造成费用基准变更的因素施加影响
2. 确保变更请求获得同意
3. 当变更发生时，管理这些实际的变更
4. 保证潜在的费用超支不超过授权的项目阶段资金和总体资金
5. 监督费用绩效，找出与费用基准的偏差
6. 准确记录所有的与费用基准的偏差
7. 防止错误的、不恰当的或未批准的变更被纳入费用或资源使用报告中
8. 就审定的变更，通知利害关系者
9. 采取措施，将预期的费用超支控制在可接受的范围内