先说结论，可能会得罪人
2021年我跟过一个项目，合同上写的是45人天，交付完结算的时候实际投入67人天，超支48%。复盘会上项目经理在PPT里写了四个字：需求蔓延。
我不同意。需求没蔓延，是我们在售前阶段就把话说满了。
那是一家做汽车零部件的厂子，年营收7亿左右，上了某国产ERP的旗舰版。售前我跟销售跑了客户两趟，客户IT部长问了三个问题：多组织能不能支持？批次管理能不能细到工单？跟现有的MES怎么对接？销售原话是「标准功能，配置一下就能出来」。
就这一句「配置一下」，后来变成了15个人天。客户要的所谓多组织，是6个法人主体、12个利润中心、跨主体调拨自动生成内部交易凭证。标准产品里确实有这功能，但它默认的组织模型是集团-公司-工厂三层，客户想要的是集团-事业部-公司-工厂-车间五层。往上加一层，权限模型要重配，核算体系要重配，报表口径全部要跟着改。
所以第一个结论：实施延期的根子，大部分埋在签合同之前。 而实施顾问是这个链条上最没话语权的人——你进场的时候，合同签了，钱收了，销售已经在下一个项目上了。
数据迁移这块，被低估得最厉害
大多数甲方在预算里给数据迁移留的时间是「一周」。我做过最麻烦的一次，历史工单2300万条，来自一套跑了11年的老系统，SQL Server 2008，字符集GBK。新系统是MySQL 5.7，UTF8MB4。
听起来只是换个字符集对吧。实际操作里冒出来的是这些东西：
老系统的客户名称里有全角空格、半角空格，还有看不见的零宽字符，同一个客户在库里有7个不同的写法；日期字段有一部分存的是字符串，格式混着 YYYY-MM-DD、YYYY/MM/DD、YYYYMMDD 三种，还有大概4万条是 1900-01-01；业务员编码在新系统里必须是工号，老系统里是姓名拼音，同拼音重名的有3个人。
这些都不是什么技术难题，是必须一条一条看的活。最后我们用Kettle加了一段Python做清洗，跑完一轮17个小时，中间回滚了三次，第四次才过。
给个粗糙的经验值吧：历史数据超过500万条，或者老系统上线超过8年，清洗和迁移的工时大约等于主数据表数量乘以1.5人天。 这个数不准，但比拍脑袋说一周搞定靠谱。
真正决定项目死活的，是甲方内部谁说了算
这一段有点绕，但我觉得是这行里最没人愿意写出来的东西。
我服务过的甲方基本都有两个部门：IT部和业务部。IT部关心系统稳不稳、好不好维护、能不能少改；业务部关心我这单能不能今天录完、报表能不能自动出、月底能不能不加班。
这俩诉求经常是打架的。
举个具体的：业务部要求销售订单可以随时改价格，IT部要求任何修改必须留下审批痕迹。产品的标准功能是可以改、但要走审批流。业务部嫌审批慢，IT部觉得不走审批就是审计风险，两边在会上吵了两轮，最后是客户一位副总拍板——5万以下订单免审批。
这种决策实施顾问是推不动的。你能做的就是把选项摆清楚，让他好拍板。所以我后来的做法是，进场第一周不做任何配置，先干一件事：画一张甲方内部的决策地图。谁是最终签字的，谁的意见可以忽略，谁的反对会让项目直接停摆。这张图不会写进任何交付物里，但它比需求规格说明书有用得多。
如果你正准备上系统，这几条是我的私货
不保证对，我自己踩过而已。
一，合同里别写「按需定制」，要写清楚哪些改、哪些不改。 定制清单具体到字段和按钮级别，模棱两可的一律按不改处理，真要改的单独报价。
二，人天估算乘个1.6的系数再报预算。 不是坑你，是因为调研阶段你根本不知道自己不知道什么。真正要命的东西都是UAT的时候才冒出来的。
三，割接窗口留双倍时间。 我们有一次计划周五22点停机、周日6点上线，实际到周日14点才恢复业务。原因是财务月结的数据没跑完，硬切会导致期初余额对不上。后来改成双跑一个月，两边并行录单，人累，但稳。
四，让业务部门出一个人全职跟项目。 不兼职。这人不用懂技术，但要在业务部门里说得上话，能拍板说这个字段我们不要了。没有这个人，你所有的需求确认书都是一张废纸，因为三个月后他会说「我当时不知道是这个意思」。
最后说我自己的一个判断
这几年SaaS化、低代码这些概念起来之后，不少人判断传统实施要没了。
我的看法是反的。软件实施这个活，本质不是把软件装上去，是把一群人的工作习惯重新排一遍。 只要组织还在变、人还在换、流程还在改，这事就一直存在。
变的只是形态。以前是驻场三个月，现在是远程加标准化交付包；以前卖人天，以后可能卖上线后第一个月的稳定性。但那个最脏最累最不体面的部分——跟客户吵字段、清洗脏数据、半夜割接——不会消失。
它只是换了个名字，现在叫客户成功。