-项目管理过程之计划和预算.docVIP

项目管理过程之计划和预算 1.2?项目计划和预算（一）? 　　上期我们讨论了如何定义清楚项目的目标，这期开始讨论目标确定后如何制定计划和预算。? 　　因为项目具有唯一性，决定了项目中必然有我们从未做过的事情，所以项目的首要任务就是“计划、计划、计划”。强调计划的重要性并非说明项目管理的主要任务就是编制计划，而是指计划是一项贯穿于整个项目生命周期的持续不断的过程，实际工作中恰恰要注意计划的详细程度与项目的实际规模匹配。? 　　项目计划包括主计划和辅助计划。主计划的编制有清晰的步骤，大多数项目都可以按相同的顺序进行，一般包括范围定义、活动定义、活动估算、活动排序（网络分析）、进度计划、资源计划、成本估算和成本预算等步骤。辅计划的编制则可以陆续或单独进行，与具体项目的特点也有比较密切的联系。辅助计划包括质量计划、组织计划、沟通计划、风险管理计划、变更控制计划等。 　　本期讨论主计划的范围和活动定义部分，后面将陆续介绍活动估算和网络分析以及进度/资源计划、项目预算等内容。讨论的重点不是具体的过程，而是一些实用的工具和方法，通过介绍工具的使用方法贯穿制定计划的过程。 　　1.2.1范围和活动定义 　　项目计划的第一步是项目范围定义，进而定义项目需要进行的活动、角色、责任以及项目组的结构。 　　范围定义一般使用WBS（Work?Breakdown?Structure）。WBS将项目的“交付物”自顶向下逐层分解成易于管理的若干元素（这些元素组成一个树型图），因此结构化地组织和定义了项目的工作范围。WBS每细分一层都是对项目元素更细致的描述，细分的元素称为工作细目，其中最低层的工作细目（树型图的叶节点）叫工作包。为了方便分层统计和识别，WBS中的每个元素都被指定一个唯一的标识符，并分层表示。 　　WBS是项目管理的起点，但WBS没有固定的分解方法，也没有唯一正确的答案，甚至需要分解到什么层次也没有统一的规定。这里根据笔者的经验提供IT领域WBS分解的几个参考原则： ★?可以将项目生命周??的各个阶段做为第一层，将每个阶段的交付物作为第二层；如果有的交付物组成复杂，则将交付物的组成元素放在第三层； ★?分解时要考虑项目管理本身也是工作范围的一部分，可以单独作为一个细目； ★?对一些各个阶段中都存在的共性的工作可以提取出来，例如人员培训作为独立的细目； ★?分解时应考虑尽量使一个工作细目容易让具有相同技能的一类人承担； ★?分解的层次应确保工作包的工期、成本易于估算，同时结果易于验证和度量。 　　确定了工作范围后，就要考虑按什么步骤做才能获得这些成果，这称为活动定义，其结果是《活动清单》。《活动清单》与WBS不同，《活动清单》的元素是“动作”，一般是一个动宾词或主谓词，如“制定定单”、“安装设备”；而WBS的元素是?“交付物（有形产品）”，一般是一个名词，如“硬件设备”。但WBS是《活动清单》的基础，一般《活动清单》依据WBS顺序进行。但在IT领域中，“活动”和“交付物”关系比较直接，所以《活动清单》与WBS同步进行反而比较方便。这里向大家介绍一个实用的《活动清单》模板。（见表1） ★?第一栏是活动列表，根据各阶段和主要交付物分层次列出项目需要进行的所有活动； ★?第二栏是责任矩阵，顶端列出完成工作所需要的各类角色；角色和活动的交叉部分定义了每项活动由哪个角色负责，还可以记录某角色在该活动中投入的工作量； ★?第三栏是估算栏，记录完成每个活动需要的总工作量以及总工期； ★?第四栏是前置活动，记录活动之间的关系，即填写哪些完成之后该活动才可以启动； ★?第五栏是费用预算，记录除人力成本和采购成本外的投入的专项费用； ★?第六栏是交付记录，列出每项任务完成后应该提交的过程记录或证明文件。 　　如果使用表1的《活动清单》模板，则前面讨论的范围和活动定义工作可以看成是填表的1区和6区过程，从而确定了所有的“事”和完成后的“证明”。接下来要考虑则是由谁来做这些事，这可以通过填写2区的责任矩阵完成。 　　责任矩阵表头部分填写项目需要的各种人员角色，而与活动交叉的部分则填写每个角色对每个活动的责任关系，从而建立“人”和“事”的关联。不同的责任可以用不同的符号表示。例如P（Principal）表示负责人；S（Support）表示支持者或参与者；R（Review）表示审核者。用责任矩阵可以非常方便地进行检查责任检查：横向检查可以确保每个活动有人负责，纵向检查可以确保每个人至少负责一件“事”。在完成后续讨论的估算工作后，还可以横向统计每个活动的总工作量，纵向统计每个角色的投入的总工作量。 　　确定了所有的角色之后，依据与“活动清单”的责任关系可以非常自然地建立项目组的组织结构