把付款争议提交 adjudication

查看这份存在争议的申请的时间线:各项日期、实际送达的通知、遗漏或逾期送达的通知,以及系统推导出的已通知金额。按打印出来的推导过程直接采用,不要用自己的话去转述改写。

原因: 大多数英国付款争议是按程序顺序而不是按估价结果来裁定的。是否送达了付款通知、少付通知是否说明了依据,以及两者是否在时限内送达,通常在任何人审视工作本身之前就已经决定了金额,所以这是做对成本最低、做错代价最高的一环。

从原始记录构建证据包:通知、往来函件、信息请求、审批、变更记录以及任何延误分析。排序方式是确定性的,证据包还带有内容摘要值,因此即便按不同顺序输入同样的记录,得到的仍是同一份文件包。

原因: 负责 adjudication 的人要在短时间内读大量文件,而有条理的文件包读起来和一堆附件夹是完全不同的体验。摘要值还能确保对方手上不会拿到一份和裁决人手中略有出入的文件包,这是一场争议里谁都不需要的次生争议。

通过往来函件登记表发出 adjudication 通知:发给正确的一方,送到合同指定用于送达的地址,说明争议的性质、所主张的内容以及寻求的救济。登记表会一并保存送达的日期和方式。

原因: 送达正是一份本来站得住脚的提交文件夭折的地方。通知发给了集团内错误的实体,或发到了合同并不认可的电子邮箱,都可能在任何人审视是非曲直之前就在管辖权问题上遭到挑战,而提交前的那七天并不会因为解决这个问题而暂停。

把提交文件及其附件放进项目文件里,与通知放在一起,形成一套带版本号、注明日期的档案。答辩、答复和裁决随到随存放在同一位置,而不是存在恰好收到它们的那个人手里。

原因: 一次 adjudication 会在二十八天内产生大量文件,涉及好几个人,通常还是在项目仍在推进的情况下。把这些文件保存在项目里而不是某一个人的邮箱里,才能让下一步——无论是强制执行、第二次 adjudication 还是和解——从记录出发,而不是从事后拼凑出发。

记录裁决内容及其带来的变化:应付金额、应付日期,以及对进度计划的任何影响。裁决人的决定在争议最终裁定之前对双方具有约束力,所以从那天起项目就按这个数字来运行。

原因: adjudication 结束后最常见的失败情形,是裁决结果留在商务团队手里,而计价工作却照旧继续,和之前一模一样。把结果反馈进项目,才能让裁决真正发挥作用,也能为下一个项目留下一份诚实的记录,说明这类争议在时间和精力上到底付出了多大代价。