Delay Communication

Project thực tế luôn có uncertainty: dependency trễ, scope đổi, assumption sai, bug lớn hơn dự kiến.

Vấn đề là cách team phản ứng với delay.

Nếu stakeholder chỉ biết project trễ khi deadline đã tới, họ mất quyền lựa chọn.

Báo sớm giúp họ điều chỉnh plan, resource hoặc expectation.

Delay — phần nào đang trễ và so với baseline nào?

Cause — nguyên nhân chính là gì?

Impact — milestone, scope, cost hoặc dependency nào bị ảnh hưởng?

Recovery — team đang làm gì để giảm tác động?

New Expectation — timeline hoặc checkpoint mới là gì?

Một cause tốt giúp hiểu system issue.

Nó không đổ lỗi vòng quanh cho stakeholder, vendor hay hoàn cảnh.

“Có thể trễ nhẹ” không đủ.

Hãy nói milestone nào dịch chuyển, khoảng bao lâu và downstream effect là gì.

Có thể parallel work, giảm scope, thêm resource, đổi sequence hoặc tạo workaround.

Không phải recovery nào cũng đưa timeline về như cũ, nhưng nó cho thấy team đang chủ động.

Đừng bù một deadline trễ bằng một deadline mới quá lạc quan.

Expectation mới phải dựa trên information đã cập nhật.

Xin lỗi có giá trị, nhưng stakeholder cần biết ai đang giữ trách nhiệm và ai sẽ update tiếp.

Forwork có thể có Delay Block: Delayed Item, Original Baseline, Cause, Impact, Recovery Actions, Owner, Revised Date, Confidence Level, Next Update.

Delay sau đó được nối vào Milestone, Blocker và Timeline.

Đừng hỏi chỉ: “Chúng ta có cần xin lỗi vì trễ không?”

Hãy hỏi: “Stakeholder có đủ information để hiểu điều gì thay đổi, chúng ta đang làm gì và expectation mới là gì chưa?”

Delay → Cause → Impact → Recovery → New Expectation.