项目延期后,先别急着追问“谁拖了后腿”。更有效的做法是把延期拆成三类可核对的事实:哪些交付物没有按约定时间出现、卡住时缺少谁的确认、以及这个确认是否在项目开始时就写清楚了。下面用一个假设例子说明怎么定位。
假设某网站制作项目约定第10个工作日交付首页设计稿,第20个工作日交付内页模板,第30个工作日进入测试。实际到第18天首页才定稿。此时不能直接说“设计慢”,而要逐项回看:需求确认单是否在第3天前签字、文案和图片是否在第5天前给齐、设计稿每次修改后由谁在多久内回复。
如果记录显示:需求确认单第6天才签字,文案第9天才给全,那么延期的主因是输入延迟,不是设计执行慢。如果输入按时到位,但设计稿发出后48小时内没有收到任何反馈,则属于确认环节停滞。两种原因的整改动作完全不同。
多人协作时,最常见的错误是把“没人回复”当成“默认通过”。一旦默认通过,后续返工就会吃掉后面的工期,表面上看是开发慢,实际是确认规则没定。
可以按下面格式做一张简表,每个节点只填四项:约定日期、实际日期、等待对象、缺失材料。填完后,延期最集中的那一行就是优先处理对象。
例如:
首页设计稿 | 约定第10天 | 实际第18天 | 等待对象:客户市场负责人 | 缺失材料:产品卖点确认
这张表的作用不是追责,而是把“延期”从模糊感受变成可核对的时间差。判断结果只有三种:输入问题、确认问题、范围问题。对应动作分别是补资料、定回复时限、走变更流程。
适用条件是:项目已有基本的需求清单和排期表。如果连排期都没有,先补一页节点表,否则无法定位原因。判断结果是:能说清每个延期的等待对象和缺失材料,就说明定位有效;仍只能回答“就是慢了”,说明记录粒度不够。
拿当前正在进行的项目,把最近一次延期按“约定日期、实际日期、等待对象、缺失材料”四项填一遍。填不出来的那一项,就是接下来要补的管理动作。