在规划阶段,可以投入更多的时间做准备,细化需求并根据可能存在风险做好应对方案。前期的多次讨论比后期的一次修改要节约更多的资源。今天我们来谈一谈进度规划中的估算项目活动的持续时间。时间估算有很多方法,在实际操作中通常是各个项目经理根据自己的经验进行初步估算,得出各项目活动的持续时间后再安排会议与具体执行某个活动或工作包的组员进行讨论敲定。在估算的时候非常建议把下列因素考虑在内:
- 预留一定的时间攻克某些功能的技术难点。
- 公司系统定期维护及更新而导致对项目工作的影响。
- 节假日及项目成员的个人原因的休假安排。
- 项目会议用于某些讨论决策的时间。
【案例】
在罗宾阐述了项目各阶段内容后,PMO开始组织大家分组讨论,让团队各自进行工作包所包含的活动,以及各活动的顺序和估算耗时。PMO告知各组可以在上午讨论,下午开始形成各自的估算;第二天的会议进行大汇总,各组成员对任务进行评估,以形成项目进度网络图。
之前8A公司在线下教育领域布局多年,积累了一定的经验,所以这次在估算项目活动时间开始前,大家都不约而同地想到找公司里的“大咖”取经,毕竟他们多年的项目或产品的经验是非常难得的财富。项目组快速地分成三个小组:软件产品、硬件、网络组。他们立刻找到PMO,向PMO申请邀请公司这三方面的资深同事,例如项目总监、资深架构师来参加他们的项目讨论。项目组的运气还真的算不错,PMO在下班前答复了项目组他们打算邀请的专家都很乐意地接收了他们的邀请。
第二天上午,各位专家和各分小组成员迅速展开了热烈的讨论,这些大咖们一上来就问了如下硬核问题:
目前这个新产品和之前开发的哪个产品最相似。
项目组是不是已经列出新产品大致的项目进度。
项目组是否对项目进展中的风险和卡点有大致的预估。
项目组是否对项目活动的资源有大致的预估。
各个小组根据大咖们的提问,迅速对标到之前的一些项目或者产品,同时充分借鉴大咖的意见,对这个新项目的活动时间预估进行了实践。但是在各个组都把作业交上来的时候,大家发现项目好像比心里预计的要长,原来大家在预估各自的项目活动持续时间和整体进度时候,都自觉给自己留了一些buffer(缓冲时间)。这时候罗宾站出来说,我们来给项目时间一起做个“瘦身”吧,因为现在的时间里“水分”太大,大家有点保守,让我们把各自手里预留的buffer(缓冲时间)都砍掉一半,同时再把我们的buffer(缓冲时间)集中起来,大家在执行时候先尽全力推进,如果项目有遇到延迟的风险,大家可以和我申请。大家第一次听到这么新颖的做法,感觉挺不错的,就愉快地在团队内部达成一致,敲定了项目的活动时间预估,同时根据活动之间的顺序排了一版项目进度表。
【案例分析】
8A公司的咨询项目在项目活动时间预估中,进一步了解了项目活动时间预估的几种常见的手段和方法,并各自采取了一些方法对8A项目活动时间预估进行了实践。
第一种:总结经验,建立基准,类比估算。类比估算以过去类似项目的参数值为基础,来估算未来项目的同类参数或指标。这是一种相对粗略的估算方法,有时需要根据项目复杂性方面的已知差异进行调整。比如拿过去项目类似的功能开发时间作为基准,如一个页面的开发时间是多少,一个接口开发时间是多少,同时也考虑与基准比较一下难度是否增加等,得出此次项目的相对准确的时间估算。
第二种:邀请专家参与,开展专家判断。我们可以寻找项目涉及的应用领域、知识领域、学科和行业等的专家参与项目进度的预估。往往这些专家对各自的领域有较深厚的专业知识的积累,不论是专业学历、知识、技能还是经验或培训经历,通过他们对当前活动进行合理的判断,可以帮助我们获得比较好的预估。
第三种:自下而上汇总WBS,得到项目估算。如果无法以合理的可信度对活动持续时间进行估算,则应将活动中的工作进一步细化,然后估算具体的持续时间,接着再汇总这些资源需求估算,得到每个活动的持续时间。例如按照经验,每个功能开发的最大单位控制在2天,如果超过2天要接着拆分,不要让开发留太多储备。
第四种:时间倒推法。比如定好最后上线时间,可以召集全员(产品、UI、开发、测试),讨论上线产品范围,倒排所有时间,让各方互相商讨,开发的关注点不再是项目经理说你行你上,而是产品什么时候出原型,如何迭代,每个迭代版本做什么,能充分平衡各方利益。
根据之前定义的不同项目活动之间的关系,还需要再次对整体的项目活动排序进行审查,最终确定一个合理的排序,使得这些活动在项目推进的过程中,即便受到内外部因素的制约,也可以获得最高的效率和最大的产出。通常这一步完成的时候,我们会整理出一份“项目进度网络图”,帮助我们更好地识别顺序关系。绘制项目进度网络图,我们可以使用到比较专业的软件,例如微软的Project,可以绘制出甘特图,这样可以更好的显示活动进度,相互关系等。其实,现实中也常用Excel 来绘制这样的进度网络图。
表3-1 进度网络图样例