{"id":256,"date":"2025-12-11T19:15:48","date_gmt":"2025-12-11T23:15:48","guid":{"rendered":"https:\/\/manageph.com\/blog\/?p=256"},"modified":"2025-12-11T19:15:48","modified_gmt":"2025-12-11T23:15:48","slug":"how-to-communicate-project-delays-asynchronously","status":"publish","type":"post","link":"https:\/\/manageph.com\/blog\/how-to-communicate-project-delays-asynchronously\/","title":{"rendered":"How to Communicate Project Delays To Your Filipino Remote Team Asynchronously"},"content":{"rendered":"\n

When something goes wrong, your instinct is probably to jump on a call.<\/p>\n\n\n\n

Get everyone together. Explain what happened. Answer questions in real time.<\/p>\n\n\n\n

Seems logical.<\/p>\n\n\n\n

But when you’re managing people in the Philippines and you’re in the US or Australia or the UK, meetings are a nightmare. Your morning is their midnight. Their afternoon is your 2 AM.<\/p>\n\n\n\n

Even if you do coordinate schedules, most people need time to process bad news and think through their response.<\/p>\n\n\n\n

A meeting forces immediate reactions. Usually not the best ones.<\/p>\n\n\n\n

Written updates are better. Everyone reads on their own time. They can think before responding. And you have a permanent record of exactly what was said.<\/p>\n\n\n\n

No one forgets. No one misremembers. No confusion.<\/p>\n\n\n\n

\n
\n <\/svg> <\/div>\n
\n

See The Early Warning Signs with Recaps<\/h4>\n

When your team shares what they’re working on and what’s blocking them every day, you catch potential delays before they become actual disaster.<\/p>\n <\/div>\n

\n \n Get Started <\/a>\n <\/div>\n<\/div>\n\n\n\n

Philippine Legal Requirements for Communicating Project Delays<\/strong><\/h2>\n\n\n\n

Here’s something most people don’t know. Even if this does not directly apply to your operations.<\/p>\n\n\n\n

If you’re working on government contracts in the Philippines, there are actual laws about how you have to communicate delays.<\/p>\n\n\n\n

Republic Act No. 9184 requires written notices to everyone involved. You need to explain what caused the delay, how long it’ll last, and what you’re doing about it.<\/p>\n\n\n\n

The Government Procurement Policy Board has a whole manual about this. Pages of requirements.<\/p>\n\n\n\n

US federal contracts have similar rules. Immediate written notification. Timestamped records. Audit trails proving when you told everyone.<\/p>\n\n\n\n

Now, you’re probably not working on government contracts.<\/p>\n\n\n\n

But these standards exist for a reason. They force clear, thorough communication that protects everyone if things go wrong later.<\/p>\n\n\n\n

Even for regular projects, it’s smart to follow the same approach.<\/p>\n\n\n\n

Figure Out What Actually Happened First<\/strong><\/h2>\n\n\n\n

Never send a delay notification before you understand what caused the problem.<\/p>\n\n\n\n

Sounds obvious. But most people rush.<\/p>\n\n\n\n

They send something vague like “We’re experiencing technical difficulties” or “Unforeseen circumstances have caused a delay.”<\/p>\n\n\n\n

That tells people nothing. And when you have to send corrections later, you look disorganized.<\/p>\n\n\n\n

Take time to actually investigate.<\/p>\n\n\n\n

Talk to the people closest to the issue. Look at timelines. Check dependencies. Figure out if this was something you could control or if it was external factors.<\/p>\n\n\n\n

This serves two purposes.<\/p>\n\n\n\n

One, you can explain the situation accurately. Two, you understand what you can actually fix going forward.<\/p>\n\n\n\n

Write the Message Clearly<\/strong><\/h2>\n\n\n\n

Start with a subject line that says exactly what this is.<\/p>\n\n\n\n

Then lead with the actual news. Don’t bury it.<\/p>\n\n\n\n

Be Direct. Clear. No buildup. After that, explain why. Be specific. <\/p>\n\n\n\n

Then explain the impact. Which milestones are affected? Are there other parts of the project that depend on this? Will costs change?<\/p>\n\n\n\n

After that, explain what you’re doing about it.<\/p>\n\n\n\n

This is the most important part. Don’t just tell people there’s a problem. Tell them how you’re fixing it.<\/p>\n\n\n\n

End with when you’ll update everyone next.<\/p>\n\n\n\n

Best Tools to Send The Message From<\/strong><\/h2>\n\n\n\n

Email is still the standard for formal delay notifications. It creates a record. It’s timestamped. Everyone checks it.<\/p>\n\n\n\n

For ongoing updates and less formal stuff, project management tools work well. Especially if they have comment threads where people can ask questions.<\/p>\n\n\n\n

Whatever you use, make sure it creates a permanent, searchable record.<\/p>\n\n\n\n

Slack or similar tools are fine for quick follow-ups. But they shouldn’t replace the formal notification.<\/p>\n\n\n\n

Write Project Updates That Can Be Understood Quickly<\/strong><\/h2>\n\n\n\n

When your team is in different countries, you can’t assume everyone has the same context.<\/p>\n\n\n\n

Avoid idioms. “We dropped the ball” might confuse someone whose first language isn’t English. Just say “We missed the deadline.”<\/p>\n\n\n\n

Be explicit about dates and times. Always include the time zone.<\/p>\n\n\n\n

“March 1” could mean different things depending on where you are. “March 1, 2024, 5:00 PM Philippine Standard Time” removes all confusion.<\/p>\n\n\n\n

Spell out acronyms the first time. What’s obvious to you might mean nothing to someone else.<\/p>\n\n\n\n

Use short sentences and simple words..<\/p>\n\n\n\n

Break up paragraphs.<\/p>\n\n\n\n

Like how I wrote this blog..<\/p>\n\n\n\n

Include Everything They Need<\/strong><\/h2>\n\n\n\n

Your notification should be complete.<\/p>\n\n\n\n

Don’t make people hunt through old messages to understand what’s happening.<\/p>\n\n\n\n

Attach or link to anything relevant. Updated timelines, resource changes, documentation of what went wrong.<\/p>\n\n\n\n

If there are compliance issues, reference the specific contract sections or regulations. <\/p>\n\n\n\n

Include a revised timeline as a clear document. A simple table showing old dates versus new dates for each milestone helps everyone understand immediately.<\/p>\n\n\n\n

If the delay affects payment schedules or billing, say that explicitly.<\/p>\n\n\n\n

Handle the Questions That Come Next<\/strong><\/h2>\n\n\n\n

After you send your notification, people will have questions.<\/p>\n\n\n\n

Create one place for Q&A. Don’t let questions scatter across email, Slack, and comments. Pick one spot and direct everyone there.<\/p>\n\n\n\n

Set a response timeframe. When you answer questions, make the answers visible to everyone.<\/p>\n\n\n\n

If you get questions that show your original notification missed something important, don’t just answer individually. Send a follow-up to everyone with the clarification.<\/p>\n\n\n\n

\n
\n <\/svg> <\/div>\n
\n

Collect Team Updates in One Place<\/h4>\n

Create recaps and standups of what everyone knew and when. Makes it way easier to piece together timelines when you need to explain delays later.<\/p>\n <\/div>\n

\n \n Get Started <\/a>\n <\/div>\n<\/div>\n\n\n\n

Keep Updating Everyone Until It’s Done<\/strong><\/h2>\n\n\n\n

One notification isn’t enough. Commit to regular updates and stick to that schedule. Even if nothing’s changed.<\/p>\n\n\n\n

Weekly updates work for most projects. <\/p>\n\n\n\n

Daily might be needed if things are really urgent. <\/p>\n\n\n\n

Monthly is too long unless your project spans years.<\/p>\n\n\n\n

Each update should include: where things stand now, progress since last time, any new concerns, confirmation of when the next update is.<\/p>\n\n\n\n

This rhythm creates predictability. People stop worrying because they know they’ll hear from you.<\/p>\n\n\n\n

When you finally deliver the delayed project, say so explicitly. Close the loop. Thank people for their patience.<\/p>\n\n\n\n

Document what you learned for next time.<\/p>\n\n\n\n

Save and Document Everything<\/strong><\/h2>\n\n\n\n

Every delay notification needs to be archived properly.<\/p>\n\n\n\n

This isn’t just good practice. For some projects it’s legally required.<\/p>\n\n\n\n

Philippine government contracts require complete documentation of all delay communications and how they were resolved. US federal contracts are similar.<\/p>\n\n\n\n

Even for private projects, keeping records protects you if disputes come up later about who knew what when.<\/p>\n\n\n\n

Use your project management system’s archiving if it has it. These usually timestamp everything automatically.<\/p>\n\n\n\n

For emails, create a clear filing system. Project-specific folders. Good tags. Make sure you can find this stuff months later.<\/p>\n\n\n\n

Document not just what you said but how people responded.<\/p>\n\n\n\n

Did they acknowledge? Approve your revised timeline? Object? All of that goes in the permanent record.<\/p>\n\n\n\n

Templates Speed Things Up<\/strong><\/h2>\n\n\n\n

Create a standard template for delay notifications..<\/p>\n\n\n\n

Your template should have sections for: cause of delay, impact, revised timeline, what you’re doing about it, next steps, how to reach you with questions.<\/p>\n\n\n\n

Standardization doesn’t mean every notification reads the same. It simply means you have structure..<\/p>\n\n\n\n

Build a Culture That Talks About The Problems<\/strong><\/h2>\n\n\n\n

How you handle delay notifications reflects how you handle everything.<\/p>\n\n\n\n

Teams that communicate delays well usually communicate everything well.<\/p>\n\n\n\n

Encourage people to report potential delays before they become actual delays.<\/p>\n\n\n\n

If your team is afraid to mention problems, you’ll only hear about things after it’s too late to fix them.<\/p>\n\n\n\n

This is especially important with Filipino remote workers. In many cultures, admitting problems feels risky. You need to create explicit safety around this.<\/p>\n\n\n\n

Thank people who surface issues early, even uncomfortable ones.<\/p>\n\n\n\n

“Thanks for flagging this dependency risk” reinforces the behavior you want.<\/p>\n\n\n\n

After projects finish, review how your delay communications went. What worked? What confused people? What would you do differently?<\/p>\n\n\n\n

This learning process improves every future notification.<\/p>\n","protected":false},"excerpt":{"rendered":"

When you’re managing remote teams across the Philippines, US, UK, and Australia, you can’t always jump on a call when projects get delayed. Here’s what works instead<\/p>\n","protected":false},"author":2,"featured_media":139,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-256","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-for-employers"],"_links":{"self":[{"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/posts\/256","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/comments?post=256"}],"version-history":[{"count":3,"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/posts\/256\/revisions"}],"predecessor-version":[{"id":471,"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/posts\/256\/revisions\/471"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/media\/139"}],"wp:attachment":[{"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/media?parent=256"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/categories?post=256"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/manageph.com\/blog\/wp-json\/wp\/v2\/tags?post=256"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}