数字化项目的成功实施对于任何企业来说都是一个复杂的过程，充满了各种挑战和潜在的陷阱。本文总结了数字化项目中的10大雷区，这些雷区可能会对项目的成功造成严重影响，甚至导致项目彻底失败。

我在公司负责营销数字化部门，近三年从我部门立了20余个实施半年以上的数字化项目；同时，我还作为公司项目组核心成员，参与了多个重大业务变革项目或数字化转型项目。

在做项目的过程中，我作为操盘手踩过一些雷，曾一筹莫展，手足无措；也看到别人掉过一些坑，也非常茫然。

我基于过去做项目的得失，总结了数字化项目的10大雷区。

这些雷，踩中一个就要半条老命了，踩中两个，项目可能就直接崩盘了。

今天，我毫无保留的分享给大家，同时也欢迎大家积极探讨，互通有无。

01 指令式定义项目，接活儿即启

不知如下场景，你是否曾似相识？董事长在开会的时候，提到现在回款逾期率太高，让财务牵头抓紧搞个改进项目，并且现场把这个活派给了财务总监。

财务总监很负责，下会后随即召集销售、商务、财务、IT等上下游相关部门，抓紧召开了启动会。

其实，启动会后，大家除了知道这是董事长的指令，回款很重要，财务牵头，这事儿要抓紧弄之外，还是一头雾水。

因为搞不清整体目标是什么？核心策略是什么？整体项目范围是什么？整体计划是什么？有多少个里程碑？每个人的项目角色是什么？大家怎么分工协作？

接下来，财务召集第二次、第三次会，还有人去。

当召集第四次会的时候，大家就开始应付了，不是这个人有会，就是那个人从部门随便派一个人来了，要么就是不来了。

当让大家写点材料，准备点数据的时候，更是困难。要么应付，要么迟迟交不上来。

过了两个月，董事长问起这事儿的进度，财务总监说我们召集相关部门开了三次会，做了些讨论，整理了一些问题正在改进，但是没有完成，还在继续。

这次，简单把董事长糊弄过去了。

又过了一段时间，董事长又问，财务总监说我们经过前几次讨论，确实发现了一些问题，我们都在改。

有些流程该调的，已经开始调了；有些规则该改的，已经开始改了。

董事长清楚，回款的事儿，不是一日之功；知道财务总监手上事儿多，非常忙，过段时间再看看成果。

实际上，改的东西，仅是一个部门能搞定的，不需要跨部门协作的，非常浅层面的问题或流程。

财务总监也清楚，董事长交代给我了，我只能是往前推，但是又推不动。

推不动，只能是面子上搞一搞。

过了两个月，回款逾期率又回升了，甚至对公司现金流有影响了。

董事长恼火了，在经营分析会上对财务总监说，你们之前不是优化了吗？怎么搞的钱还是回不来？怎么还是那么多逾期？

不行，你们要继续弄。

其实，这种接到指令即启动的项目，从一开始就失败了。

这种项目失败的最大原因，不是因为指令式定义项目，而是在于接活儿即启动。

缺乏项目的策划、充分调研和精心立项，缺乏对项目的敬畏。

财务总监应该接到指令后，召集相关部门分管领导，先进行调研。

明确项目目标、范围、价值，找到核心问题，明确方案思路，正式成立项目组织，明确各方职责，共识项目计划；与项目组核心成员给董事长汇报后，召开正式立项评审会。

通过正式立项评审会，董事长也清楚财务总监计划怎么带着大家干了，心里就踏实了。

这样，大家心中的各种疑虑就都被打消了，目标与价值明确了，干的就不迷茫了；职责与计划明确了，就知道自己在什么时间点该干什么事儿了，就不会开会不来了，也不能应付了。

后续，每个里程碑节点，财务总监联合项目组其它部门，及时给董事长汇报进度与情况。

这样搞项目，才有把握，也不用等着董事长问，董事长也不会恼火，各个部门也会配合。

02 浅共识、假共识，有了方向即启动

在公司，经常遇到跨部门互怼互喷的情况。

销售跟研发互怼，销售说产品不行，研发说销售胡吹产品价值；售前与交付相互拉扯，交付说售前挖坑，售前说交付能力不行。

基于这种互怼互喷，老板说，请流程部门搞个内部协同项目，把跨部门断点打通，减少抱怨，消除误解，提升协同。

流程部门认真做了调研，收集了跨部门的核心问题，并且跟销售、研发、交付等各部门的领导进行了共识，并一起给董事长约了会议，进行汇报。

在会上，董事长说，不错，你们发现的这些问题，我觉得都很重要，你们赶紧看看，应该怎么推进，我都支持。

流程团队，就认为这些问题都跟业务部门共识了，董事长也认同；这个项目可以启动了，具体怎么做，那是实施阶段的问题。

启动后，发现这个项目基本上是流程团队自己的活儿，自己在调研、自己写报告，很郁闷。

每次给董事长汇报，也是流程团队在汇报。

让各个业务部门出人，和上面财务牵头的回款项目是一样的，开始前几次有人参与，后面大家慢慢就不怎么配合了，想让他们写个报告，也是踹一脚动一下，提供的东西根本没法直接用。

其实，前面共识的仅是方向；方向共识，和项目要开战的共识，完全是两回事儿。

在方向共识和正式启动项目中间，需要有一个项目策划阶段，需要详细的做好项目可行性规划。

但是，流程部门把这个阶段给吃掉了。

在策划阶段，识别出核心问题后，要对相关方进行调研。

要分析根因是什么？如果要优化，大概思路是什么？本次的目标是什么？发现的问题是全部搞，还是聚焦在某几个问题上？解决这些问题分几个步骤，需要多少里程碑，需要哪些人一定参与，需要参与多长时间，是集中办公还是在各自工位办公？是全职还是每天抽半天做这个事情？项目有没有什么风险？项目要不要建立激励机制？激励的指标是什么？激励的标准是什么？等等。

这些统一都要论证清楚，与相关方取得共识，一起上会汇报给董事长，进行正式的立项审批。

这，才是真正的共识；仅识别出问题，让相关方和董事长认这个事儿，是浅共识，仅是共识的方向，是项目启动的假共识。

03 项目调研不充分，就启动

不知大家是否熟悉这个场景？

数字化项目进入实施阶段开战一个月了，大家还在讨论到底哪个问题更重要，到底先解决哪个问题，要不要解决某个问题；甚至还在考虑目标是啥，价值是啥，计划怎么定。

其实，这些都是补策划阶段调研不充分的功课。

你可能说，调研不是实施阶段的事儿吗？策划阶段和项目实施的调研，目的是不一样。

你调研哪怕是同一个人，你问的问题也是不一样。策划的时候调研的目的是什么？你的目的是论证这个事儿，大家认为是不是问题，认为是不是有价值，认为是不是重要且紧急。

这个事儿，是需要多大的范围，多大的目标，多大的组织，多大的资源去支撑？策划调研时，核心是问这些问题。

项目实施阶段，再去调研的时候，更多是问需求细节，探讨到底怎么优化，你花更多的时间是探讨落地解决方案。

策划阶段调研，是判断能不能成事，能不能立项。实施阶段的调研，是要出落地解决方案。

哪怕访谈同一个人，你问的问题都不一样，深浅也不一样。

那你说，我前面拉下功课了，实施阶段补补，不就是时间延长一点吗？

关键有时候，你没有机会补。

别人一看你这项目稀里哗啦，像小孩过家家似的，成不了事儿，对你就失去信任了，不陪你玩了。

反正是你操盘的项目，公司批的时候也是批你，别人也没啥影响。

别人就给你打上不靠谱的标签了，你以后还怎么做项目呢？

如果说啥事情都可以补功课，那启动越早越好。

前面提到的两个雷，听到指令就启动，有了方向就启动，也不是雷了。

所以，策划调研一定要充分。

在正式开战之前，很多工作是需要通过调研弄清楚的。

有些重大数字化项目，光调研、策划、论证，至少半年。

要遵守客观规律，该花时间的地方就得花时间，不能糊弄自己。

有些人为什么成长不了，原因就在于此，看不懂事物的本质规律，糊弄了别人，坑掉了自己。

04 把项目命运交给外部咨询公司

数字化转型项目，涉及业务变革在前，然后通过数字化落地，因此需要从业务变革做起。

有些企业自己没有业务变革经验，希望请外部咨询公司帮助做业务变革，以实现“管理咨询+IT”的落地。

比如营销数字化转型项目，一般先做LTC（Leads to Cash）业务变革。

如果从外部找了咨询公司讲讲他们的成功案例，讲讲LTC业务变革该怎么做；给咨询公司讲讲自己的想法后，就催着咨询公司抓紧入场。

说咨询公司是专家，要让专业的人做专业的事儿，这样踏实。

如果这样搞，大概率会掉坑里了。

哪怕找外部咨询公司，项目策划的调研，一点儿也不能省。

因为，大多数咨询公司会想，你们付费那我就入场呗。

结果“蜜月期”还没过，突然发现双方理解不一致啊。

这个时候，企业与咨询公司就互相埋怨。

企业埋怨咨询公司，你们这咨询公司太垃圾了，啥也不会，只讲空的，也不落地，也不这也不那。

企业骂咨询公司，咨询公司也开始骂企业。

这企业啥也不懂，连基本概念就不懂。自己要啥，想不清，这也要，那也要。心里没点儿数，一共就四个月的时间，这也要搞，那也要搞。

最后，只能是双方不欢而散。

其实，这种自己不了解LTC业务变革该怎么干，有哪些关键步骤，先干啥后干啥，具备什么条件才能干，该怎么定义LTC业务变革的范围、深度、策略、切入点、资源投入等等，而是直接找咨询公司开工。

开工之后，没有分歧才怪呢？

相当于自己啥也没想清楚，把项目的命运直接交给了外部咨询公司，这种是万万要不得的。

咨询公司虽然专业，但是，自己该学习的还是要学习，自己项目该要啥，也是需要策划，需要详细的可行性研究，这个过程一点儿也不能省。

就是自己家里搞装修，你也有一个学习、了解的过程，也要和设计师充分沟通、甚至参观几个样板间后，再开工；而不是找了设计师，简单聊聊就出图，叮呤咣啷的砸墙开干。

为什么企业请了咨询公司，就可以这么仓促呢？道理是相同的呀。

其实，正确的姿势是通过看书、学习课程，还是去标杆那里学习，都是方法。或者让咨询公司找他的做过LTC变革的客户，去考察考察，学习学习。看看人家走了多少年，走了哪几步，遇到什么坑，有什么经验，第一步先做什么，切入点是什么？

通过这个过程，不是要自己成为LTC专家，而是去了解一下这个事儿，应该怎么干，怎么干才好，不要被咨询公司骗了，自己的命运握在自己手里，把项目策划调研做充分、做扎实。

变革是自家的事儿，不是咨询公司的事儿，咨询公司是你的资源，是为你服务的。

自己可以借助咨询公司的专业能力，先花个小钱儿，搞搞工作坊，让咨询公司给补补课，拉拉共识，出出项目策划方案。

通过这种方式，自己要先摸清风险在哪里？到底分几个阶段？采用什么策略好？采用什么切入点好？摸清诸如此类的问题后，目标清晰了、思路务实了，项目规划完整了，再启动也不迟。

所以，我们自己要具备变革的策划、风险识别能力，这也是我们的责任。

哪怕找外部咨询公司，项目策划过程也不能省。

否则，就把我们的命运交出去了，你不成为待宰的羔羊，谁还是呢？

05 项目目标假大空

数字化项目，很多时候是公司级项目的一部分，或者说是其中一个子项目。

鉴于这个原因，我经常思考公司级项目目标，清晰吗？

在这个公司级项目中，哪个目标是我数字化部分的北极星目标？

我经常找不到，因为看到的是假大空的整体项目目标；比如“实现以客户为中心的战略转型”，再比如“进行流程型组织变革，打好高质量发展的关键一战”。

这些话，作为一些外部会议的主题，或者作为标语、作为愿景还行。

但是，这种一百年都对的话，是目标吗？

项目目标，虽然需要有挑战，但不是喊高大上的口号；要符合SMART原则，需要具体、可衡量、可实现、有相关性，并且还要有明确的时间周期。

正确的姿势，是把项目目标拆解清楚，做到清晰、明确、无歧义，能明确看到项目价值。把董事长或公司高层想要的东西解码清楚，做透项目策划，圈定一个边界，圈定一个价值交付物，再给董事长核对清楚。

在前期把目标拆解清楚，看似耗一些时间，此时的慢就是快。

否则，就忘了为啥而出发？要去哪里？成了无头的苍蝇。

06 项目范围过大

正常的数字化项目，策划加实施整个周期不宜跨年，在公司做业务变革类的项目，也是这个建议。

因为，很多公司每年都会有组织架构的一些调整，或者人事调动。

如果项目跨年了，上任业务方负责人拍屁股走人了，下任跟上任的思路一致还好，若不一致呢？

若下任负责人不认同前任负责的这个项目，是不是就有烂尾风险了？

烂尾这个锅，是不是就得摁在数字化部门头上了？

所以，若项目范围过大，可以拆成子项目，可以拆成多期，每期不超六个月。干完一期，再弄一期。

业务项目也类似，项目范围过大，不好控制，不好收场。

我参与公司的业务变革项目，在项目规划阶段是八大流程一起规划，涉及战略、市场、研发、营销、交付、服务等核心业务环节。

在正式启动的时候，我们就拆开了，整体规划分步实施。

先弄营销的LTC，并且在LTC里面，又按子流程拆分成不同的项目，串行搞，也不是盘子喝水一漫子来。

先搞线索、再搞商机立项、再搞解决方案评审，按照流程顺序完结一个启动一个。

每个子项目周期控制在六个月左右，根据上期项目效果，在下期还能适当做些策略优化。

这种节奏就非常合适，看到效果的同时，大家也能一张一弛，项目风险也可控。

07 项目组织责任夯实不到位

在我的工作经历中，发现很多数字化项目的组织责任落实，存在严重的问题，都给项目质量带来很多潜在风险。

总结下来，如下三种情况，尤为常见。

一是，项目领导组，形同虚设。

项目领导组，都是挂个名，既不参与项目日常工作，又不参与关键评审，就是给派了他部门的一个人，甚至在启动会也看不到人影。

除资源协调外，项目领导组，需要参与项目启动、关键节点的评审、关键里程碑成果的汇报等事项。

这样，他才能了解项目的进度、质量、成果。

否则，说明这项目不重要，或者太形式主义，搞了一堆挂名的领导。

这样搞法，项目组成员也都成杨白劳了，做啥事儿领导不关心。

二是，数字化项目策划方案，全部由数字化部门完成。

数字化是解决业务问题，为业务服务的。项目策划的方案、可行性研究方案，里面的业务问题、业务价值、业务解决方案，都是数字化部门写，汇报也是数字化部门去汇报，这样对吗？

数字化部门与业务部门是合作伙伴，不是保姆。再者，业务的解决方案，你也写不透，应该回归给业务部门去写，你们共同完成项目策划方案，一起给评审委员会做立项汇报。

这样做的好处是，让业务部门能够把业务问题、业务价值、业务解决方案，想清楚；而不是为了做项目而做项目，让项目因价值而存在。

任何一个数字化项目，都是业务项目，只是通过数字化手段落地支撑而已。

数字化项目不是数字化团队的交钥匙工程，是跟业务方通力配合的结果。

大家一定要有这种认识，否则，数字化项目的业务价值，如何衡量？

三是，由供应商实施的项目，内部数字化人员成了甩手掌柜的。

有些公司，会外包出去一些项目，或者直接外购供应商的软件产品，并由其完成实施、二开交付。

在这个时候，有些公司内部的数字化接口人，成了甩手掌柜的，或者一个传话筒。

在开业务调研会的时候，不参与讨论；在落地方案评审时，完全让业务部门把关；在测试时，自己不亲自过一遍；在上线培训时，自己也不听。

纯粹是没有负起责，等项目一上线，问题都来了。

业务想做些策略微调，对不起，落地方案里面没提参数化配置，供应商在代码里写死了。

业务提出个别地方交互太复杂，对不起，测试阶段没提，现在需要单独谈费用，加人天。

供应商撤场了，业务方有个系统问题想请教，数字化人员因参与不深，自己搞不定，又打电话找供应商。

业务部门想，我要你啥用啊？就是用来传话的吗？给我电话，我自己打不行吗？你还说不清业务问题。

08 项目计划粗放

我们看到的50%以上的项目只有大颗粒度的时间点，并且非常粗放，仅列出来这个月做什么事儿，下个月做什么事。

哪怕有双周计划，跟大颗粒度时间点，也对应不上。

这种计划，说明实施思路与实现路径不清晰；在执行中，要么发现太激进，要么发生大量的“意外”和“突发”；导致项目一再延迟，质量无法控制。

真正的项目计划是一个立体的计划体系，里面至少包括里程碑计划、项目总计划、双周滚动计划、专项任务计划。

我以项目总计计划为例，里面需要包括项目阶段，每个阶段有什么事项，每个事项的计划起止时间，每个事项的责任人，每个事项涉及的人员，每个事项是否在关键路径上，是否是里程碑节点，每个事项的交付物等。

尤其是是关键路径，非常重要，能看出它是否是其它事项的前置条件，是否是瓶颈依赖；以免执行中，因它而影响其它事项的进度。

未执行的关键路径，在项目计划变更时，也是重点调整对象。

项目变更是一件很严肃的事情，项目计划粗放，经常会导致项目计划变更。

久而久之会造成变更非常随意，大家也就不拿计划当回事儿了，也会失去对项目负责人的信任，项目拖拖拉拉，不延期才怪呢？

09 项目风险管理不系统

项目风险管理是一个立体体系，而经常看到的现象是，要么不提前识别风险，要么识别不出风险，要么识别了风险不重视，要么识别了风险没预案。

导致拿风险暴雷当意外，大家都不担责，都推责，最后毁掉的是项目。

从项目策划调研开始，项目经理就要识别风险，把识别的风险，写清影响，写清预计解决时间，写清解决预案，在立项评审会上，明确给大家。

在项目实施阶段，发现了项目风险，也是随时反映在周报和例会上，管理方法同样是按影响、预计解决时间、解决预案、消除状态来管理。

其实，在风险管理中，最核心的两点是没能力识别风险和思想麻痹不重视风险管理。

没能力识别风险，是需要靠主动思考、多沟通、多复盘，逐渐去提升。

而不重视风险管理的问题，可以立马行动，当下解决，也是有立竿见影效果的。

10 没把业务计划统一管理

数字化项目是价值导向，不是上线导向。

而我经常看到，项目发布到上线了，没人用；或者业务部门还没做宣贯、培训、推广，甚至业务上不具备启用条件，需要再等半年，业务成熟后再使用。

你这发到线上没人用，叫上线吗？顶多算，系统具备了试用状态。

我还经常看到，整个数字化项目计划里，都是数字化部门在主导，没有业务部门主责的事儿，妥妥的成了一个数字化部门的交钥匙工程。

除系统实现外，业务的整体的解决方案是什么？有什么配套的管理机制？推广前有没有试跑计划？推广前宣贯计划怎么做？培训计划怎么做？上线后有什么业务运营计划？

数字化同学，这些事情难道也是你来搞定吗？

你甚至连业务部门什么时候正式使用就不关心，你做这项目的意义难道就是为了拿工资吗？

没有正式用起来的数字化项目成果，不是成果，仅是成本的浪费。

因此，数字化项目是业务部门与数字化部门联合的事儿，需要把业务计划与数字化落地计划，统一制定，一起排上，整体推进。

项目发布到线上，不是大活儿干完了，用起来才是，发挥出价值才是。

11 总结

如上是我总结的数字化项目的10大雷区，同时也适用于公司业务变革项目。

10个雷区难以面面俱到，而是抛砖引玉，比如没有谈及项目激励与考核的雷区。

项目激励不仅是激励过去，还有倡导什么、鼓励什么的价值所在。

项目考核，不是要加新的考核指标，而是如何把项目和现在每个人的KPI关联起来，如何有助于现在KPI的达成，项目是达成现在KPI的手段和方法。

但是，很多项目的考核，侧重增加新的考核指标，整的项目成员非常反感，逆反，甚至不希望项目能成。这就是项目激励考核的雷区。

最后，借一个词儿，项目需要“谋定而后动，知止而有得”，与大家共勉。