浅谈项目进度管理
项目进度管理的好坏与很多因素有关,项目管理过程中,最容易出问题也是最常见的问题就是进度的滞后。作为项目管理者,进度管理在某种程度上决定了项目的成败。
我在8年的项目管理生涯中,带领了大大小小的项目,不一而足。进度是最容易出现问题的一个环节。在进度管理中,也应为某些项目进度没有控制好,获得了一些经验教训,并深受启发。个人总结下来,影响进度的原因可以分为不可预见因素和可预见因素两部分:
不可预见因素:
1、来自于客户、市场等外部因素不合实际的进度要求;
2、项目在执行过程中,外部依赖条件没有按照计划来执行,比如客户没有在计划在适当的时间节点给出必要的资源支持(包括提供必要的表单、提供必要的UI素材、提供必要的办公环境、必要的服务器资源、必要的人力资源、必要的业务支持等),影响项目的正常执行;
3、其他不可抗力的外部因素(如自然灾害、项目外部环境、客户方临时计划的调整等)
4、项目执行过程中,团队关键成员因临时缺席需请假,或者因为中途离职;
5、公共资源(一个人同时可承担多个项目),临时有其他项目中途插进来,需要团队里面的某个成员参与;
6、来自客户方的临时变更;
可预见因素:
1、来自于前期对需求的把握不够明确,需求不够细化,对项目的外部依赖没有做充分的预估等,导致对项目进度的预估过于乐观,从而制定了过于乐观的进度计划;
2、制定计划时,没有考虑一些不可控或不可抗力的外部影响因素,所以没有为进度预留适当的buffer,导致一些没有预见的影响因素在发生时,没有足够的时间去处理;
3、项目经通常没有过多的耐性来对进度作出一个合理的评估,通常都只是拍脑袋;
4、编码阶段,没有统一规范的开发规范作为指导,导致不同的开发人员各行其是,最后在集成整合测试时出现各种各样的问题,花费大量的时间用来解决bug;
5、项目经理对风险项目风险预估不足,往往在项目上线阶段暴露了各种各样的问题;
以上是我在项目管理中所遇到过的一些问题,其实每个问题都有对应的解决办法,关键是,作为PM,要时时刻刻思考,方方面面思考。尽早规避影响项目进度所有可能风险因素。这样才能做到临危不惧,随机应变。
对于不可预见因素的处理办法:
怎样应对客户的不合理工期要求?我的做法通常是,你说1个月的时间完成全部开发和上线,那好,我要首先告诉你,我们项目管理的流程是什么样的,我会告诉他项目有哪几个阶段,需要做哪些方面的工作,每个阶段大概需要多久时间,说白了,咱就是拿数据说话,信不信咱看数据。好,经过这一气的说教,客户说那再给你半个月时间,然后作为项目经理,觉得这个时间有点realistic了,于是,好,这样我们也先别在这拍脑袋了,就这项工作,我们觉得这个时间还是基本合理的,不过,按照我们的项目管理过程,我们还是要做一个相对比较靠谱的进度计划出来,如果大家对计划有什么疑问,我们再调整也不迟,然后按照最后的计划来知行。客户同意,搞定。但这里要补充一点,客户的要求时间,往往存在两种情况,一种是刚性时间要求(配合某个特定时点的市场活动等,必须在活动的前一天或两天 上线),一种是弹性时间要求,这个时间也是客户拍脑袋的时间,至于基于什么理由,往往也说不出一个123,所以,客户在给我们时间要求时,我们一定要问个deadline的理由,并分析这是不是真实的deadline。
怎样应对,在项目执行过程中,客户没能按照计划时间给出必要的资源支持,作为乙方,影响到我们项目的交付。往往这样的资源可能也不是甲方对接人单方面就嫩给出的,不然,他也没有必要在这上面去拖延我们的时间,要知道,我们的共同利益是绑在一起的。所以,资源迟迟没能到位,很可能这样的资源他们也需要其他内外部的协助才能给出(可能是要走一个内部繁复的流程;可能是要依赖另一方,另一方又依赖另一方,层层依赖的情况;可能是到等到某个时点才能输出完整的数据;可能是。。。),所以,我们作为乙方在做计划时,要帮助甲方考虑这些依赖因素,并在计划中给予体现。那么我们回过头来说说,一旦这种情况发生了,我们怎么办,没办法只有邮件崔(必须,并抄送相关干系人,对方和己方的领导),并附带分析所产生的影响,最直接的影响就是项目进度,所以,对此,我们提出项目进度变更申请,获得甲方同意后,我们重新发布变更后的项目进度计划并抄送相关各方。当然,这种情况我们还是不愿意看到的,所以我们尽量能在赶早告知客户,并给予周期性的提醒,同时,帮助对方考虑替代方案(如果上线时点不能调整),比如是不是可以消减相应的功能,但保证上线的时点。
自然灾害这种情况几乎不太可能,极小极小概率事件。基本可以忽略,一旦发生,大家认命吧。
面对团队成员变动,项目开始时,项目启动会,就要问清楚,我们这个项目大概要持续到什么时候,这个时间段有没有人员请假离职(离职这事要私下了解),以便提前做好应急准备。如储备资源等;不过作为项目经理,平时要注重团队建设,尽量减少离职率吧。
面对中间插进来的项目,要把项目资源的一部分时间抽出去做其他项目,两个项目经理坐下来聊一聊,当然开始大家都会向着自己说话,都会说自己有多多困难,但最后都会有一方妥协袭来,但作为理性的自然人,妥协的前提是,在不影响自己项目的前提下。所以,双方可就公共资源所要做的工作进行细化,然后我们让开发来评估,并给出个交付时间承诺,如果评估下来一个人在指定的时间不能完成这两件事,那么,作为项目经理,就需要将问题上升,寻找更高级别管理人员的资源支持了。
来自客户方的临时变更,首先乙方项目来对变更进行分析和论证(分析变更的合理性,基于的背景和所要达到的目的),项目经理评估变更可能带来的影响并告知客户及相关干系人,如用户放弃变更则结束变更申请,如用户坚持,请客户给出变更申请邮件(抄送客户方相关干系人并得到客户方批准人同意),项目经理提交变更走内部变更流程,或直接邮件变更事项及影响,如内部相关干系人无异议则接受变更,同时更新项目进度计划。
对于可预见因素的处理办法:
项目经理在制作进度计划时:
第一,要明确项目范围,并在此基础上制作WBS,这是合理的范围保证项目不镀金,项目只做它该做的事情;
第二,要充分预估项目的外部依赖,并给这些外部依赖预留相应的时间;
第三,对于不可预见的因素,要留有适当的buffer,合理的buffer以应对不时之需。给团队留有缓冲的时间;
第四,项目经理在评估工时时要基于多种方法和工具,如有历史经验,可依据历史经验,如无,则可采用三点估算法或专家估算法;
第五,避免返工,这就要求项目经理在项目执行过程中做好质量预防和质量控制,从需求到设计到编码到最后的测试都要层层把关。每个关卡可指定不同的责任人来监管,并向项目经理汇报;
第六,对项目风险做充分预估,并定期评估(通常是每周)项目可能存在的风险,并提前做好风险预防和准备。关键路径上存在的风险更需要注意(比如服务器环境,域名,账号等资源);
第七:建立项目看板制度,有条件的,可以在白班上每天写下每个人的工作任务,以及当天完成的任务,没有条件的,可以建立每日汇报机制,每个开发人员依据计划汇报自己当天工作完成情况,项目经理依据看板来跟踪项目进度,并适时发起控制策略;