If you searched “why offshore development fails” and you are now three or four articles in, you have probably noticed something. They all say roughly the same thing.
I am not going to tell you that list is wrong. The opposite, actually. I think the list is right. And projects keep failing anyway, so the problem must be somewhere else.
Here is where I land. The difference is not in what the fixes are. It is in whether someone is watching that they are still being done.
A boring answer, I know. But when I write down what my company actually does every week, that is where it ends up.
Some context on where I am writing from: I run a software development company in Ho Chi Minh City, and we build systems for Japanese companies. So I sit on the vendor side of this problem.
What everyone says you should do
The usual advice comes down to four things. Hold a weekly meeting on a fixed day. Write minutes for every decision, with an owner and a next action.
Keep those decisions somewhere online that everyone involved can open at any time. And agree in writing on what “done” means before the work starts, then keep that one source of truth updated at least twice a week.
None of this is new to me. For a software company it is basic, and for any company that works remotely, it is basic too.
The weekly meeting exists to close the gap between the client and the people building. Nothing more, nothing less.
I believe it saves someone every single week. Without it, projects simply don’t move. We didn’t invent any of it, either. There is probably someone in your company already saying the same things.
The fixes are known. On-time delivery is still going down
Let me show you one piece of public data. Every year, the Japan Users Association of Information Systems (JUAS) publishes an IT trends survey of Japanese companies, supervised by the Ministry of Economy, Trade and Industry. The 2025 edition covers fiscal 2024, with 981 companies responding, and it tracks how often system development projects finish on schedule.
In fiscal 2024, the share of projects “completed on schedule” was 31.0% for projects under 100 person-months. For projects of 500 person-months or more, it was 11.0%. The report’s own heading says, in my translation: “Over the ten years from FY2015 to FY2024, the share of projects completed on schedule has been trending down at every project size, and FY2024 shows no sign of improvement.”
To be clear, these numbers are not about offshore work. They cover all system development, domestic included. But weekly meetings and written minutes are the same fixes at home and abroad, so this is a fair base for one question: are projects failing because people don’t know the fixes?
I’ll add just one reading of it. Weekly meetings, minutes, task tools: not one of them was invented in the last ten years. And “on schedule” kept going down anyway.
Ten years is more than enough time for the knowledge to spread. So it seems unlikely to me that not knowing is the cause.
So what is actually hard?
This is the part I care about most.
We write minutes. We create tasks. Anyone can.
The hard part is checking them. How well was it actually done? That is where you can fudge things if you want to.
Minutes can be accurate and still leave out what didn’t get decided. A task never goes overdue if you keep pushing the deadline. A definition of done, agreed while it is still vague, can be read any way you like.
When people are busy, this happens on its own. So in the end it becomes partly a matter of culture and personal responsibility, and how high people set the bar will differ from person to person.
New team members have the hardest time picking up that bar. And honestly, that is less their problem than mine: I was expecting them to hit a line I had never put into words.
So the first few months start with exactly that. Putting the line into words.
Put simply: someone is actually looking
When it got done, you say it got done. When it didn’t, you say it didn’t. You give feedback.
Written down, that is all it is. Not exciting, but I think it matters a great deal.
The system part, frankly, can be copied. Putting a weekly slot on the calendar and handing out a minutes template takes a day.
But “telling someone, on the spot this week, what they didn’t get done last week” only exists if you do it every week. And if the person doesn’t accept the feedback, it won’t carry into the next week. This is the one part a template can’t multiply.
If it needs someone watching, doesn’t it break when you grow?
This is usually where people push back. If you need someone watching everything, that depends on one person, and it falls apart the moment headcount grows. Fair point.
Right now I handle it by adding more people who watch. I can’t look at everything myself. So each leader looks at how well their own team is doing, and I look at how the leaders are looking.
I pass it on and keep turning people into leaders. Whether it still works as we grow is something we have yet to find out.
One thing does bother me. “Look carefully and give feedback” spends a person’s time on one person. I have a habit of not being able to leave a struggling person alone, and I think of that as a bad habit for someone running a company.
So I set one rule for myself. Don’t rescue people one by one; hand over the way of looking, and let it be passed on. If I step outside that, it is my bad habit talking.
Still, a standard gets diluted if you leave it alone. The first generation of leaders knows my standard directly. The second generation receives the first generation’s interpretation of it. Like a message passed down a line of people, it wears down a little at a time, with nobody meaning any harm.
What I do against that is write things down and bring them to our all-hands meeting. I put “this is how we do things here” into blog posts and documents. Then we go over them in the all-hands and raise the floor, point by point.
The leaders understand it better there too. The second and third generations may not get all of it, and that is where the leaders follow up. Whether that is enough, I don’t know yet.
One example. In June I wrote A Bug Can Be Fixed. Hiding It Breaks Trust. To me it is a post about being honest.
Separately from the all-hands, I talked it through in a meeting with our project managers, four of us in total. Being honest with the client, as a project manager. And being honest with the boss.
Once we talked it through, being honest turned out to be harder than I expected. Pretending you can do something, or not mentioning a failure, can happen without the person feeling they are lying at all.
Even so, I think they felt this much: pretending and hiding failures is not a good look, and the boss won’t let it slide.
It doesn’t change overnight. With training, it has been getting better, bit by bit. That is what handing out a standard really means: slow, unglamorous work.
I’ll admit this works on me too. There are times I want to look good in front of a client. But as long as I am telling everyone else this, I can never lie to a client myself. I think that side effect is a big one.
I’m not saying skills don’t matter
The same JUAS report also explains why schedules and quality are getting worse. In my translation: “As system development becomes more difficult, it is getting harder to secure people who can handle it, and this is affecting the deterioration of QCD.” (QCD is quality, cost and delivery.)
So technical skill and hiring are still very real factors. It is not true that anyone gets the same result as long as the process runs. Skipping over that and saying “it’s all about the system” would be sloppy.
With that said, if I have to pick one, I still pick watching and giving feedback. The reason is simple: skill gaps are visible. You can see them to some degree in interviews, in code, in a résumé. And what you can see, you can act on.
But “this week’s level is slightly lower than last week’s” goes by unseen unless someone is looking. The trouble is usually in the part nobody sees. So that is where my time has to go. That is my conclusion for now.
If you are the one hiring, what should you check?
If you are choosing an offshore vendor right now, I think the place to look shifts a little. Ask “Do you hold weekly meetings?” or “Will we get minutes?” and almost every vendor will say yes. No difference shows up there.
Try asking this instead: “Last week, something didn’t get done. In this week’s meeting, who dealt with it, and how?”
I won’t claim this settles it. But unlike asking whether meetings or minutes exist, the way someone answers this shows how they actually run things. If all you get back is a general answer, it is worth digging further.
One more practical move: start small, with a one- or two-month engagement, see what happens inside the weekly meetings, and then expand.
I wrote about how we stopped blaming failures on “chemistry” or “country” in Why Offshore Development Fails — and How to De-risk Vendor Selection. What actually happens in our weekly meetings is in What Does a Software Vendor Actually Sell? And how we set up dedicated teams and project work is on our Vietnam offshore development page.
The checklist is right. The difference comes after it
So the checklist is right, and we do the same things. That part makes no difference. What makes the difference, I think, is whether those basics are still running next week and the week after, and whether someone is checking how well they are actually being done.
All we do is say “done” or “not done” on the spot. Nothing flashy. Honestly, keeping that going every single week is about all we can manage.
FAQ
Where should we start to prevent offshore development failure?
The basics are four things: a weekly meeting, minutes with a clear owner, decisions shared online, and an agreed definition of done before work starts. But most companies already have these four. As a first step, I would take one thing that didn’t get done last week and deal with it in this week’s meeting, on the spot. Checking whether the system you already have is still running comes before adding more system.
Can we tell before signing whether a vendor actually runs their process?
Try asking: “Last week, something didn’t get done. In this week’s meeting, who dealt with it, and how?” Asking whether they hold meetings or write minutes shows no difference, because everyone says yes. This question needs a real scene. Whether you get a general answer or one actual case tells you a lot. The other option is to start with a small one- or two-month engagement and look inside the weekly meetings before expanding.
Isn’t offshore failure really about differences in technical skill?
Skill is a factor. The JUAS IT Trends Survey 2025 in Japan says that as development gets harder, it is becoming difficult to secure people who can handle it, and that this is affecting quality, cost and delivery. Still, if I have to pick one, I pick checking the level of what was achieved and giving feedback. Skill gaps show up to some degree in interviews and code. A small drop in this week’s level stays invisible unless someone is looking.
“Is that process still running?” Let’s look at it together.
Whether you are still choosing an offshore vendor or something feels off in a project that is already running, we can take this article and ask how it applies to you. You should leave with at least a few things to check in your next weekly meeting. Yes, this is also how people end up hiring us. You are welcome to take the checklist and leave.
Book 30 minutes → Message us instead →
Shogo Harada原田 祥吾
CEO · Linnoedge Inc. · LinkedIn↗
Operating IT offshore development and overseas expansion support businesses across two bases: Tokyo and Vietnam. A leader who believes in “Systems over Spirit,” structuring cross-border businesses that often tend to be opaque. Committed to providing “reproducible quality” to organizations and clients rather than relying solely on individual skills.