这世界并不陌生的项目下火海。事实上,人都有艰难的乐趣,参与一个失败的努力可能感觉到它灭亡之前上线日期。第六感是宝贵的在竞争激烈的领域,但是只有行动迅速和专业。
(项目管理:10缺少成功的关键]
是否你想避免被负担无用或引导一个注定推出沟里,你必须能够认识到即将失败的迹象之前一个项目来瓦解。它可以是一个career-saver。
我们已经收集了11红旗寻找健康状况评估IT项目。主动当你遇到一个,或者如果可以,简单地走开。你职业生涯取决于它。
红旗一号:项目已经启动了没有高层的支持
想反正项目失败吗?挖掘前顶级的支持。
的:它通常发生强烈的个性在公司里有一个绝对“很棒”的想法或解决方案,并开始计划会议和分配资源没有等着看高级管理人员同意。许多这些项目继续进行,直到真正的钱必须花;然后他们完全崩溃。通常每个人都在这个项目,除了它的发起者,甚至不知道这个项目还没有被批准,也没有预算尚未分配。
为了避免这样一个项目所带来的负担,总是问谁在高级管理层是赞助商和预算分配。不接受答案声称没有分配预算,因为人们不知道这是什么成本,直到项目正在进行。
如果你是一个顾问被拖入这个项目,确保重要的预算被分配在你参加第二次会议。你不需要知道最终的预算数字,但你需要知道,高级管理层严重支持该项目,并对最终成本有一些线索。我已经在大型项目,显然要花费数百万美元来解决,但管理更多想到的是几个上千美元的范围。不要困在研究这个项目。
红旗2号:没有详细的项目计划的存在
项目规划软件可以使用复杂和令人沮丧。我唯一讨厌超过设计一个详细的项目计划是参与一个项目,该项目没有一个。正式的项目计划迫使项目经理,每个人都参与,考虑所有必要的阶段和步骤,顺序进行。套用一个经常被引用的行,“失败的计划正计划失败。”
任何项目,估计时间超过两周应该有一个坚实的,详细的项目计划。如果你不面对一个项目,创建你自己的。除了迫使每个人都考虑的所有任务和策略,这样做会迫使他们想出可行的时间表。一个详细的项目计划远比你的“猜测”或直觉。
红旗3:会议已经安排不关心团队成员的可用性
当一个项目或团队领导随意安排会议,与其他重要的冲突,已经站立会议,你知道你的项目是注定要失败的。这样做可以确保重要的团队成员将会缺席,从而削弱了你的会议的目的和效果。
解决方法很简单:花点时间安排项目会议学习当前日历的重要参与者。更重要的是,找到一些常见的可用性,选择一个时隙。不要走得太远多个每天播发或者刊登之间允许参与者投票——这可能导致不好的感觉从那些提议被拒绝每天播发或者刊登。相反,是权威和选择一个时间你知道每个人都可以忍受。你可以调整之后,如果有必要的话)。也要宣传您的团队的常务会议时间,这样其他人就不会安排。
聪明的同时,提示:安排会议在午餐之前,如果可能的话。人们通常更有效率,更有可能出现在当天早些时候。会议午餐后常常不得不对抗slugglishness满肚子和竞争的优先级和戏剧上半年收入。会议刚刚结束午餐或最后的工作日至少可以参加和最富有成效。
红旗4号:用户几乎没有(没有)早期介入
甚至每个人都在一个基本的类在大学教时涉及用户早推出任何项目或决策过程。这就是为什么它是如此的令人惊讶的看到大而复杂的项目几乎完全之前完成用户提供他们的建议。我见过许多大型发展项目完全出轨因为用户告诉领导,一个特定的过程还没有完成,很长一段时间,新流程并不奏效。
确保真实用户,或者他们的主张,被邀请项目从一开始。你不能让他们过早。从用户参与越多,你成功的机会就越大。如果你的项目涵盖多个部门,确保用户从每个部门代表。一定的用户也被邀请参加对项目的目标和开放感觉他们可以表达他们的真实意见。涉及用户通常导致更快和更好的接受如果早些时候问题开发或不受欢迎的过程变化是必要的。
红旗5号:项目目标的最小规格
项目成功杀死最喜欢购买的最低限度的硬件。
供应商而臭名昭著试图降低项目的成本,低价销售所需的硬件优化的结果。供应商通常提供一个“最低限度”的规范和推荐的硬件购买。智能项目负责人将超越甚至推荐的硬件规格;如果发生,至少在供应商和客户不会手指指向捡了芝麻,丢了西瓜的购买决策。另外,确保所有购买硬件和软件相互兼容和测试。你不希望任何一方指责早期如果出现错误。
有时魔鬼在于细节时,采购技术。例如,如果一个供应商说它很有经验MySQL运行在Linux上,小心要求MySQL在Windows上运行。供应商可能会说他们能做它,但是可能没有太多经验。如果你偏离供应商推荐什么,确保你得到供应商的书面认可。另外,它永远不会伤害过去与客户共享一个相似的配置检查学习情况的好与坏,如果他们倾斜,哪怕是轻微的,从推荐的规格。
红旗6:测试是马后炮
测试对项目的成功至关重要。无论是单元测试(测试系统)的一个方面或集成测试(测试所有组件,包括现有接口系统),测试应由当前的员工以及一个测试脚本。测试脚本应该包含所有输入,一步一步,测试人员应。提前和你应该细节,,所有的输出应该是什么样子的。
测试数据和流程应审查所有场景,包括好的和坏的数据。有时结果已知错误数据更有趣比期望的结果。测试应包括负载测试的系统和网络响应下沉重的利用率。测试人员应该理解预期成果和报告所有偏差。
红旗7号:没有恢复计划是在失败的事件
尽管我们尽了最大努力,计划并不总是如预期的那样。每个项目领导人需要知道上线成功是什么样子,什么时候承认失败,重新开始新的一天。每个项目应该有一个上线后备计划,以防失败成为唯一的选择。
太多的生活事件是由相信“没有什么可以出错。”Leaders of these projects often fail to make sure good backups are taken and verified. They don't develop protocols for defining success, nor outline what a failure looks like ahead of time. They don't prepare the team for what to do in the event of a go-live crash. Many brand-new projects hit a fatal stumbling block only to find out they can't go backward. This is poor planning.
除了少数例外,项目应该计划失败,当痛苦太多,允许失败回到旧体制。当然,失败是令人尴尬的,没有人想要它的计划。但不能恢复在一个扩展服务中断通常是之作。
让高级管理人员知道你有一个备份计划并跟踪它的三通粪便的粉丝是一种赢得赞誉。让一个长时间停机事件继续下去你向管理层解释,没有办法后退和前进的道路是一个完全不同的谈话看起来不是那么漂亮。计划成功,但有一个计划的失败。
红旗8号:专家建议已经回绝了没有测试结果
有些人征求专家的意见,听着,然后选择一条不同的道路,每一次。然后他们抱怨时不正确的工作。
不要被这个人。不要让那个人在你的团队做重大决定。没关系,征求专家的意见,只做些不同的事情。这是人类的本性,通常是一个好的领导者的标志。不要只是一味的强制。更重要的是,如果你对建议和结果不起作用,不怪顾问。
偏离供应商或顾问的建议意味着测试上线之前所做更改的结果。即使供应商或顾问同意你异常的建议,确保测试的变化。许多项目失败了,因为项目负责人做了一些小修改,让供应商和顾问在后台摇头。你会惊讶有多少专家保持沉默面对一个非常强大的客户似乎知道比经验丰富的顾问。每个人都想成为朋友。每个人都希望它的工作原理。
不希望。测试。大部分时间和听你的专家。
红旗9:上线日期是周末或假日
许多项目领导人计划上线活动周末或假日,因为较低的员工或客户服务中断的机会。虽然值得称赞,但这些窗户也往往是技术支持更难实现的时候。你可能有你的主要供应商现场,但第三方技术支持可能关闭或打电话(而不是返回调用及时),和你的团队可能也是如此。在电话里跟你最好的数据库解决纠纷者,他和他的家人度假从来都不是最优的。
红旗10号:预期尚未设置
当一个新系统将取代旧的系统,对每个人都很有帮助理解新的期望。新系统将如何行动?交易和交易时间有何不同?最终用户电话是否有问题?多长时间上线故障排除团队现场?一个新系统将永远挫败的人,但如果你设定切合实际的期望,给人们加速支持选项,问题往往消失更快最后得到更满意的顾客。
红旗11:节省培训
我不能告诉你有多少项目领导人将被盗的培训预算当面对预算超支。通常是沾沾自喜,supersmart领袖自称系统非常简单,用户并不需要所有的培训。如果你听到,“见鬼,我们的火车每隔一人一半的类和他们彼此可以训练,”或“我们的用户很擅长找出事情;他们可以在几天内解决这个新系统,“你知道你的失败。这不仅仅是用户需要培训,但项目领导人,来,和服务台的工作人员。可以推迟这个项目如果没有得到适当的培训。
这个故事,“11 IT项目是注定要失败的迹象”最初发表的信息世界 。