How to Communicate Project Delays To Your Filipino Remote Team Asynchronously

When something goes wrong, your instinct is probably to jump on a call.

Get everyone together. Explain what happened. Answer questions in real time.

Seems logical.

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.

Even if you do coordinate schedules, most people need time to process bad news and think through their response.

A meeting forces immediate reactions. Usually not the best ones.

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.

No one forgets. No one misremembers. No confusion.

Philippine Legal Requirements for Communicating Project Delays

Here’s something most people don’t know. Even if this does not directly apply to your operations.

If you’re working on government contracts in the Philippines, there are actual laws about how you have to communicate delays.

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.

The Government Procurement Policy Board has a whole manual about this. Pages of requirements.

US federal contracts have similar rules. Immediate written notification. Timestamped records. Audit trails proving when you told everyone.

Now, you’re probably not working on government contracts.

But these standards exist for a reason. They force clear, thorough communication that protects everyone if things go wrong later.

Even for regular projects, it’s smart to follow the same approach.

Figure Out What Actually Happened First

Never send a delay notification before you understand what caused the problem.

Sounds obvious. But most people rush.

They send something vague like “We’re experiencing technical difficulties” or “Unforeseen circumstances have caused a delay.”

That tells people nothing. And when you have to send corrections later, you look disorganized.

Take time to actually investigate.

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.

This serves two purposes.

One, you can explain the situation accurately. Two, you understand what you can actually fix going forward.

Write the Message Clearly

Start with a subject line that says exactly what this is.

Then lead with the actual news. Don’t bury it.

Be Direct. Clear. No buildup. After that, explain why. Be specific. 

Then explain the impact. Which milestones are affected? Are there other parts of the project that depend on this? Will costs change?

After that, explain what you’re doing about it.

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

End with when you’ll update everyone next.

Best Tools to Send The Message From

Email is still the standard for formal delay notifications. It creates a record. It’s timestamped. Everyone checks it.

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

Whatever you use, make sure it creates a permanent, searchable record.

Slack or similar tools are fine for quick follow-ups. But they shouldn’t replace the formal notification.

Write Project Updates That Can Be Understood Quickly

When your team is in different countries, you can’t assume everyone has the same context.

Avoid idioms. “We dropped the ball” might confuse someone whose first language isn’t English. Just say “We missed the deadline.”

Be explicit about dates and times. Always include the time zone.

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

Spell out acronyms the first time. What’s obvious to you might mean nothing to someone else.

Use short sentences and simple words..

Break up paragraphs.

Like how I wrote this blog..

Include Everything They Need

Your notification should be complete.

Don’t make people hunt through old messages to understand what’s happening.

Attach or link to anything relevant. Updated timelines, resource changes, documentation of what went wrong.

If there are compliance issues, reference the specific contract sections or regulations. 

Include a revised timeline as a clear document. A simple table showing old dates versus new dates for each milestone helps everyone understand immediately.

If the delay affects payment schedules or billing, say that explicitly.

Handle the Questions That Come Next

After you send your notification, people will have questions.

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

Set a response timeframe. When you answer questions, make the answers visible to everyone.

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.

Keep Updating Everyone Until It’s Done

One notification isn’t enough. Commit to regular updates and stick to that schedule. Even if nothing’s changed.

Weekly updates work for most projects. 

Daily might be needed if things are really urgent. 

Monthly is too long unless your project spans years.

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

This rhythm creates predictability. People stop worrying because they know they’ll hear from you.

When you finally deliver the delayed project, say so explicitly. Close the loop. Thank people for their patience.

Document what you learned for next time.

Save and Document Everything

Every delay notification needs to be archived properly.

This isn’t just good practice. For some projects it’s legally required.

Philippine government contracts require complete documentation of all delay communications and how they were resolved. US federal contracts are similar.

Even for private projects, keeping records protects you if disputes come up later about who knew what when.

Use your project management system’s archiving if it has it. These usually timestamp everything automatically.

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

Document not just what you said but how people responded.

Did they acknowledge? Approve your revised timeline? Object? All of that goes in the permanent record.

Templates Speed Things Up

Create a standard template for delay notifications..

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.

Standardization doesn’t mean every notification reads the same. It simply means you have structure..

Build a Culture That Talks About The Problems

How you handle delay notifications reflects how you handle everything.

Teams that communicate delays well usually communicate everything well.

Encourage people to report potential delays before they become actual delays.

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

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

Thank people who surface issues early, even uncomfortable ones.

“Thanks for flagging this dependency risk” reinforces the behavior you want.

After projects finish, review how your delay communications went. What worked? What confused people? What would you do differently?

This learning process improves every future notification.