进度管理

一、 活动定义

活动定义是项目进度计划的基础，主要的输入有项目范围说明书、WBS、WBS字典，在活动定义过程中，需要注意一下两个问题：

（1） 活动颗粒度适中，颗粒度太粗，不利于项目精细化管理，颗粒度太细，增加分解难度和成本，不切合实际。

（2） WBS分解过程中避免丢失活动，保证全面覆盖。

针对以上问题，我们在活动定义过程中聘请相关专家和精通业务的成员参与到过程中，通过对WBS的10人天工作包进行分解，分解为2人天的活动，同时项目组成员随时检查分解过程中有无丢失的活动，最终形成了活动清单和里程碑节点。

二、 活动排序

在活动排序中，最重要的是理清已定义的活动之间的各种依赖关系以及提前量和滞后量。为了保证活动之间的业务逻辑和流程能够理清，我专门召开了项目工作会议，邀请了综合办公系统方面的专家、项目管理专家、软件方面的技术专家以及项目团队所有成员参与。在会上，业务专家与技术专家共同对业务逻辑、流程进行了分析，对分解的已定义的活动进行优先级排序，项目组相关成员做好了会议纪要，总结。会后，我依据排序讨论结果绘制了活动单代号进度网络图（PDM）。

三、 活动资源估算

项目活动分解完成后，为保证有充足的资源和时间去完成，本人组织召开了会议，会议邀请团队所有成员以及专家参与，专家对每一个具体的工作活动提出需要的资源条件，采用专家判断以及根据以往类似弱电项目的分析比较，得出每个子系统需要的资源估算，然后将所有资源进行汇总，得到活动资源估算。比如，需求分析阶段，一卡通子系统、楼宇自控子系统、安防报警子系统各需要 2人，计算机网络子系统、综合布线系统、语音系统等其他系统各需要 1人；设计阶段，各子系统需要 2人；实施阶段，一卡通、楼宇自控、安防报警子系统各需要 10人；其他子系统各需要 6人，等等。

四、 活动历时估算

在活动资源估算完成后，对每个活动进行历时估算。专家对每一个具体的工作活动采取专家判断和类比估算法估算时间，还一起讨论工作活动的风险情况，如果活动存在潜在风险，则在活动历时上加上 20%的应急储备时间作为活动的总历时。比如，弱电系统实施阶段，由于存在供应商不能及时供货的风险，如果某一系统的供货时间估算为 15天，则此活动的历时为 15+15×20%=18天。

五、 制定项目进度计划

进度计划是进度控制的基础，所有的工作都是围绕计划进行的。经过一个月的总体规划，可行性研究之后，利用甘特图法、前导图法、箭线图法、专家判断法以及类比估算等方法，把该项目分为 6个主要阶段：

 （1）项目准备阶段， 2010年 8月至 2010年 9月，历时 1个月；

（2）项目蓝图阶段， 2010年 9月到 2011年 1月，历时 5个月；

（3）系统实施阶段， 2011年 1月到 2011年 5月，历时 4个月；

（4）上线准备阶段， 2011年 5月到 2011年 7月，历时 2个月；

（5）系统切换阶段， 2011年 7月 1日上线，历时 1天；

（6）上线维护阶段， 2011年 7月到 2011年 8月，历时 1个月。

再用类似的方法为每个阶段制定详细的工作进度表，为项目设立了相应的里程碑活动。进度计划的建立，为项目的建设提供了依据和基础。

六、 进度控制

根据以往的经验，进度控制是项目管理的重点和难点之一。为了更好地控制本项目的进度，我主要采取了每日站会、每周周报、挣值技术、偏差分析的方法：

我要求各子项目负责人每天早上开个站会，会议不超过15分钟，主要回答三个问题：第一，昨天做了什么；第二，如果有工作没做完，是什么原因；第三，今天做什么。每人每天的站会都会有几句话的工作总结，每周汇总之后就成为当周周报并统一向上汇报形成绩效报告。我根据每周的绩效报告与进度计划表进行比较，便形成偏差分析，利用挣值技术计算进度的偏差情况。如果出现偏差，我会及时查找原因并及时采取纠正或预防措施。

通常来说，如果在技术层面遇到问题，大家会一起讨论协助解决；如果在工作量层面遇到问题，我会与子项目负责人协商后进行资源平衡；如果出现资源冲突、范围变更之类我个人权限无法解决的问题，我会向领导汇报并申请支持。