IT项目同传统项目的区别 传统的项目需要经历的时间长,使用的是有形资源,项目成果是通过对资源的消耗与形态的转化来逐步实现的。IT项目的实质是“知识转移”, 项目是以无形的智力产品为项目目标。典型的IT项目是IT系统的建造(如系统集成)和软件开发项目。 因此说,IT项目的实质是“知识转移”,而建造项目的实质是“资源消耗”。当然,并非说IT项目中不存在“资源消耗”,也不是说传统项目中没有“知识转移”。这一点应该得到辨证的理解。
不要找借口 有时候一个项目失败后,大家都遮遮掩掩的,没有人出来解释项目怎么出的岔子和失败的原因。如果是你负责这个项目,应该站出来收拾烂摊子,承担责任,不要找诸如 “采购部门未能完成对项目申请文件的审批和签字”之类的借口, 注意项目早期出现的失败征兆 从表面上看,很多项目都在顺利运行,但仔细一点深入地查一下就会知道项目进行得并不顺利。精明的项目经理能感觉到一个项目可能失败。他们会注意项目里的工作人员出现压力过大的情况和项目任务出现了不应该出项的延迟等迹象。他们看到这些先兆后会立即介入。通常情况下,项目经理可以扭转项目失败的颓势,但有时候也会回天乏术。及早地确认一个项目可能会失败,提前采取必要行动,就可以有效地减轻该失败项目的影响。 要有及时叫停的勇气 大多数项目经理都是乐天派,能想出不少好点子,是解决问题的能手,他们能找到办法成功地完成几乎每一个项目。但事情也有不好的一面:同样是这些项目经理,他们面对一个失败的项目时会誓不言败。这些人拥有绝不言败的基因,他们无法明白某个项目是没有指望成功的。承认一个项目的失败不是件容易的事,但一旦你确切地知道一个项目必然会失败后,就要拿出勇气来,快刀斩乱麻叫停项目,避免更多的浪费。 事后分析 这个项目到底为什么会失败呢?一个项目失败后,多数人都不愿提起,想忘了这事,此为人之常情。作为项目经理,要反其道而行之——并且要求你的员工反其道而行之。项目取消后要进行详细的分析,要在大家还记得细节时开展讨论。与团队成员开会讨论时要营造一个理解的、轻松的、友善的环境,这一点也很重要。 变弊为利 烂掉的项目也有利用的价值。这些价值可能是一些出自该项目的优良业务规则,这些规则可以用在以后的项目里,或是某个员工在该项目里表现优异,可以在以后的项目里赋以重任发挥其特长。在做项目分析时,要和团队成员一起找到这些“好东西”,让他们了解到尽管项目失败了、没有达到主要目标,但也产生了价值,这对他们来说是一个不错的经历。 检讨各种得失因素 项目经理应该评估自己一方(和其他方)在项目里的表现。虽然项目的重点是具体的东西,多数项目经理也知道政治因素也会影响到项目的进行。不同的因素都可能导致项目失败,如用户不合作,或是有内讧,或是IT人员之间不合作,或者外部供应商没有跟上。由于这些原因,项目经理应仔细检讨各个玩家以及各种政治因素的得失(自己做,不是与团队成员一起做)。 设置返回点 处理失败的项目有点像驾驶一架战斗机。应该时时知道项目在什么时候撤退,要带好降落伞。应该在项目启动前预先与团队和利益相关者一起设定一些检查点。这些检查点的形式通常是项目周期里的评估分数,项目团队和利益相关者可以根据检查点对应的评估分数,有必要时决定是否需要叫停一个项目。在项目里设置这些检查点可以保证开放的沟通、保证各方参与项目的评估、减少出现不愉快的可能性。 制定备用方案 因为无他计可施而要放弃一个项目肯定叫人不爽。因此要准备好一个备用方案,有必要时用上备用方案,不会影响到项目的势头。例如,你想建个私有云,但项目进度有些跟不上,或许可以换个思路,找个IaaS(Information-as-a-service信息即服务的缩写)供应商设置所需的云环境。 为项目和预算规划不同的阶段 在设定项目检查点的同时,应该按段开发项目,按段设定相应的预算。应该将一个项目分成更小的、更易于管理的阶段,分段做出相应的预算分配。这样做以后,要叫停一个花了几百万美元、一年多人工的项目就会容易得多。 Tips:搜索 IT项目 可以获得更多内容 CIO之家-践行,见未来
|
|
来自: victor1208 > 《IT技术文档》