在项目的实施过程中,进度失控可以算是最常见的现象了,因为进度是最直接,最明显的表现,也最容易测量,所以,很多人在学习项目管理的时候,都会优先选择学习进度管理,都或多或少的会有一种希望,这样,是不是进度失控就会少一些?确实可能会少一些,但遗憾的是,只学进度管理,恐怕对失控并不会带来质的改变!
先来做个自我检测
1、为了应对客户变更,你会在估算进度时增加多少余量?
2、假设客户不变更,你的项目计划中的工作包有多少会发生变化?
3、如果项目是多系统协调的开发任务,协调工作的工期是否会被计算?
4、项目执行过程中的进度状态信息是定性的还是定量的?
5、如果同公司内其他项目出现了延期,你会不会担心影响自己的项目?
怎么样?自测结果大家觉得如何?会不会觉得,有点不怎么好回答?
比如:
第1题,为了预防客户变更,加进项目进度中的余量,实在是一个不好控制的数据,毕竟,谁都很难精准预测,客户到底会产生多少变更。
再比如:
第5题,如果在一个组织内,执行相同性质的项目,那么,其他项目的延期,作为项目经理,你是需要关注的,因为,很有可能,公司就会做出调用其他项目资源来完成延期项目的决策,而作为项目经理,你恐怕就会碰上一次来自组织内部的资源变更了。
仔细分析完这些题,我们会发现:为什么项目进度大家都会关注?因为进度的拖延非常明显!
为什么项目进度很难真正控制?因为进度管理失控的原因是一个系统问题!
通常,在学习进度管理的时候,我们学的最多的是如下内容:
1、项目进度管理中的常用工具(CPM网络、PERT网络)
2、项目进度计划体系的建立
3、进度管理中的PDCA到底怎么执行
再回顾一下:
1、在我们的项目中,用到了哪些工具?
2、工具是否符合项目实际?
3、工具是否能控制项目进度?
如果第二个、第三个问题的答案是“NO”,那我们确实得考虑一下,造成你项目进度失控的到底是什么原因?是工具没学好么?
首先,必须说明的是,通过工具方法学习,通过建立体系制度就能改善的进度问题,恐怕是项目进度管理中最简单的部分了。
其次,对于进度失控,我们必须清楚:进度的失控从来不是一个孤立的问题,同时,造成失控的原因来自很多方面。
1、过于乐观的态度
当项目进展顺利时,我们会忘掉“墨菲定理”。虽然80%的项目工作可以在20%的时间内完成,然而需要80%时间的剩余的20%项目工作,有可能都会分布在项目后期。而过于乐观的态度,会导致项目经理或企业管理者做出如下行为:
抽调不那么必要的资源到其他项目上;
弱化进度监控;
降低对变更的警惕性;
……
而这些决策,都有可能导致项目在最后20%的工作中,最终功亏一篑,进度延期。
2、技术完美主义
在知识输出为主的项目中,如软件开发项目,如研发项目,技术完美主义也会带来进度延期。
在这里,不是说技术完美主义会自主拖延工期,而是说,在很多时候,技术完美主义在面对客户的变更要求、质量提升时,总会习惯考虑“我能”!
而这种对范围、质量因素的不重视,最终会将影响反射到项目的进度上!
3、客户的变更
基本上,只要是做乙方项目经理的,恐怕,最怕的事情就是:
客户要变更!
但这一点,又是永远也不可能回避的事实,也不要妄图去执行一个永远不会发生客户变更的项目!因为,这种愿望,本身就违背了项目实施的一个基本逻辑:
项目是对未来执行工作的预测管理,有预测,就必然会不准,必然会有变更
因此,合理的态度是:
变,才是项目的常态
我们做的一切努力,不是为了回避变更,而是为了快速、积极、科学的应对变更
4、资源预算的变化
资源,最主要的还是人力资源:
某方面的人员不够到位;
在多个项目的情况下某方面的人员中途被抽到其他项目;
身兼多个项目;
在别的项目不能自拔无法投入本项目;
……
等等,诸如此类的问题,也是进度失控的原因!
5、低估技术难度
低估技术难度实际上也就是高估人的能力,认为或希望项目会按照已经制定的乐观项目计划顺利地实施,而实际则不然。
例如,以软件开发项目为例,项目的高技术特点本身说明其实施中会有很多技术的难度,除了需要高水平的技术人员来实施外,还要考虑为解决某些性能问题而进行科研攻关和项目实验;
6、低估协调难度
低估了协调复杂度,也低估了多个项目团队参加项目时工作协调上的困难。很多软件开发,或者研发项目团队成员比较强调个人的智慧、强调个性,这给项目工作协调带来更多的复杂度。
而当一个大项目由很多子项目组成时,不仅会增加相互之间充分沟通交流的困难,更会增加项目协调和进度控制上的困难。
7、除此之外,还有大量的管理原因:
计划的弹性问题;
控制的及时性;
末端循环工作的应对;
……
要彻底控制进度,只学习进度管理根本不可能。要学的不仅是项目管理的完整知识体系,还要真正能很企业的实践有效关联,还要明白两大控制原则:对可控领域要强化控制,对不可控领域要提高预防。进度控制不是项目经理一个人能够实现的。
需要的同学可以先点关注在私信我哦!!!