如何进行项目估算

PMP里项目估算是道数学题,套用公式就可以得到答案。

对于明确需求的项目做估算并不陌生,考虑到项目中的风险和不确定性,三点估算是相对比较靠谱的估算方法

该方法起源于计划评审技术(Project Evaluation and Review Technique – PERT),将整个项目自上而下拆分成多个小任务,再对每个小任务分别按照最乐观,最悲观以及最有可能的情况进行估算,通过加权平均的方式估算活动持续时间的近似值。

见下列公式:

这是PMP书本上的官方做法。之所以说是靠谱方法,原因在于估算活动的持续时间是一种概率分布——正态分布。而根据正态分布的特性,即,

落在横轴区间(μ-3σ,μ+3σ)的概率为99.7%

而方差σ的公式为:

正因为通过三点估算,可以将活动持续时间的估算近似到(μ-3σ,μ+3σ)的区间范围之内。即直观,又有效直接,从而被业界作为标准而使用。

好了数学课暂时讲到这里,事实上,要让一份项目预算有说服力,这只是第一步。接下去的几步,直接关系到客户是不是认可这份估算。

法律题:你的估算是否够客观?

每个人对于技能的掌握程度不同,正所谓术业有专攻,同一个任务,资深开发半天就能搞定,初级开发估计要3人天的工时。

在估算时,如何规避此类问题呢?

为了规避不同水平开发对于任务估算的影响,所有任务的估算都是基于一个中级开发所需要的时间。

逻辑题:你的任务分解的是否全面?

任务分解的关键是恰到好处的分解,不能过于粗略,也不能过于细致。

过于粗略产生的误差在上下50%以上,除了难以让人信服,也有可能忽略细节导致低估。

过于细致会造成估算偏多的情况。影响最终报价。

那么恰到好处是的分解是什么尺度呢?

莫斯的建议是每个任务控制在2天以内 (敏捷类项目除外)。多于16小时的任务显然是太粗太大了需要再次分解的。

认知题:相似任务的学习成本是否已经考虑在内?

如果预算上超出了客户心里所想,客户会下意识的细读每一项任务。这个时候是关键,因为客户只要找到一项不合理,就可以推翻整个估算

而很多时候,就单独一个任务来看,是合理的。但是类似任务是存在熟练度的,随着熟练度的加强,学习成本会降低。

如果无差别的估算相似任务,就会大大增加客户指出的机率。

项目经理小伟,初当项目经理的时候,就犯过类似错误,他的项目是在两个不同地区搭建同一套系统,于是他把两个地区分开估算最后合并了写到一份估算里。

如果是分开单独看每一个任务,都没有问题。

但是合在一起,问题来了。

既然是一模一样的系统,为什么有了第一个地方搭建的经验,在第二个地方还是需要同样的时间?

记得当时客户就抓住了这个问题,直接推翻了小伟的估算。造成小伟团队与这个项目失之交臂。

情商题:如何面对客户的质疑?

这已经是最后一步,如果到这一步,证明对于项目估算,客户已经没有疑问,并且认可了。

只是客户还想再打压下价格。往往此时会对过往团队表扬一番,然后问,你们团队表现那么好,是不是只需要估算的三分之二时间即可。

这不,还是小伟,就遇到过如此情况。

那个时候,小伟团队接到一个小任务,并对任务做了估算,乐观估计3天,悲观估计12天,一般情况在7天左右。根据三点估算的公式,得出的结果是7.2 人天。

客户对于任务细分和每一个任务都没有过多的异议。

然后问了小伟一个问题:鉴于团队之前几次的估算,都是真实实施时间小于估算时间2天左右。这个项目估算是7.2人天,我能不能认为5天就可以完成了。

当年小伟经验尚浅,以为这是客户对于团队的夸奖,想都没细想就答应了。

结果那次有多个任务出现状况,最后完成花销是7.1人天。虽然没有超过小伟原本估算,客户却非常不满。

原因是当时客户只按照5人天做了预算申请,对于多出来2.1人天,客户只能想其他办法。

而小伟团队在经过努力工作之后,顺利按时完成任务后客户非但没有肯定,反倒是职责消耗了过多的预算。最终搞得双方都非常不满意。

其实遇到此类情况,有经验的项目经理会在最初客户这么问的时候,就和客户进行解释。

项目经理给与客户的数字,是一种估算,可能低于估算,也可能超过。但是偏差可控(正负3西格玛)。如果在申请项目预算时,就根据历史数据减少预算,势必大大增加项目风险。

届时,项目如果顺利进行还好说,如果超过预算,如小伟那样,客户需要重新申请预算,有损客户在客户上级的形象,而小伟团队的积极性也是一种打击。可谓是两败俱伤。

项目经理在面对质疑时,要有自己的立场,并且站在客户角度解释。切莫认定客户永远是对的。勇于解释,据理力争,既可以拉近客户的距离,增加项目经理在客户心中的专业感,还可以从根本上保护项目顺利进行。

相关文章