Over the years, I have worked on several technical assistance programs in Cambodia, alongside government institutions, development partners, private-sector organizations and consultants.
One thing I have learned is that what looks straightforward in a project document can be very different in practice.
Technical assistance is not only about good experts and good reports. It is about adapting to reality, working with institutions, managing different stakeholders and, ultimately, leaving behind something that can continue after the project ends.
Here are some lessons I have picked up along the way.
A good technical solution is not always a practical solution
International experts can bring excellent knowledge and experience from other countries. But what works elsewhere may not work exactly the same way in Cambodia. A new policy, guideline or system needs to fit Cambodia’s laws, institutions and way of working. Sometimes a technically strong document needs to be adapted, simplified or rewritten, localized with the help of national experts before it can really be used.
So, one important lesson is: Don’t measure success by whether a good document has been produced. Measure it by whether people can actually use it.
Some technical understanding is important
One lesson I have learned is that managing a technical assistance project is not just about coordination. If you are directly involved in implementation, you need to understand the subject you are working on. If not, learn through. You do not need to be the technical expert. That is what the consultants are for. But you need enough knowledge to understand the issues, ask the right questions, and make good decisions.
This is especially important when working on policy or regulatory issues. If you only focus on meetings, timelines and budgets, you may miss whether the technical work is actually solving the right problem. In my experience, knowing the technical side helps you work better with experts, spot problems early, connect different pieces of work and know when an activity needs to be adjusted.
Again, you don’t have to know everything. But if you are managing technical work, you should understand enough to manage the work, not just the process.
Government consultation takes time and for good reason
One of the realities of technical assistance is that preparing a technical product can be much faster than getting it adopted. A draft law or guideline may be prepared relatively quickly, but then comes consultation, comments, revisions, inter-ministerial discussion and approval.
This can sometimes look like a delay from the project perspective. But consultation is also what creates ownership. I have therefore learned that we need to distinguish between: producing something → getting agreement → adopting it → actually using it. They are not the same thing.
A project needs room to adapt
The original project document is a starting point, not a script. By the time implementation begins, circumstances may have changed. Government priorities may shift, a new regulation may emerge, a counterpart may undergo structural changes or need more time, or an activity may turn out to require a different approach.
Project therefore requires a balance between staying focused on the agreed results and being flexible about how those results are achieved.
I have found that projects work better when the implementation team has enough room to adjust activities and sequencing, while keeping the overall objectives and accountability clear.
Donor oversight is important. Projects need accountability and proper controls. But implementation also needs some flexibility. Government priorities change. Consultation takes longer than expected. A new issue emerges. An opportunity suddenly appears.
If every small adjustment requires several levels of approval, the project can become slow and less responsive.
Too much flexibility can make a project lose focus. But too much rigidity can make it difficult to respond to reality. The skill is knowing what should remain fixed and what can change. The balance should be clear direction and accountability at the top, with enough room for the implementation team to make day-to-day decisions.
Coordination is more than meetings
Another lesson is that coordination is easy to confuse with simply having more meetings. Most large TA projects have team meetings, partner meetings, steering committees and regular reporting. These are necessary, but they do not automatically create good coordination.
Good coordination should help answer practical questions: Who is doing what? Where are the bottlenecks? Are two teams doing similar things? What does the government counterpart actually need? What needs a decision, and who can make it?
I have found that regular communication works best when it leads to clear decisions and follow-up actions, rather than simply producing another set of meeting minutes.
Avoid working in silos
This becomes especially important when several components are working on related issues. Trade facilitation, digitalization, private-sector development, policy reform and market access are often closely connected.
If teams work only within their own components, opportunities for complementarity can easily be missed. Good cross-component coordination can help connect these pieces, avoid duplication and make the overall program more effective.
Don’t just train people. Build people who can train others.
Another lesson is that training alone does not guarantee sustainability. If a project brings in international experts every time training is needed, what happens when the project ends?
This is why I particularly like the Training-of-Trainers approach. Instead of only training end-users, a project can help create a pool of national resources who can continue sharing the knowledge after the project is over.
That is a much stronger investment in long-term capacity.
The log-frame does not always tell the whole story
This is probably one of the biggest challenges I have seen. Projects need indicators. Donors need reporting. Log-frames are important. But sometimes the indicators tell us more about what the project delivered than what actually changed.
It is easy to say: 10 workshops were organized, 200 people were trained, and 5 guidelines were produced. But the more important questions are: Did the institution actually use the new knowledge? Did a policy change? Did businesses change their practices? Did the new system reduce the time or cost of doing business?
These changes are harder to measure, but they are much closer to the real purpose of technical assistance. I would therefore prefer fewer, better indicators, supported by good qualitative evidence, rather than simply adding more indicators.
The real test comes after the project ends
For me, that is the real value of technical assistance.
It is not the number of workshops held or reports produced. It is whether, after the consultants have left, institutions continue using what was developed, businesses continue benefiting from it, and local people have the capacity to take the work forward.
That is when technical assistance becomes more than a project. It becomes lasting capacity.
The analysis and views presented are intended to provide policy and technical insights, based on the author’s knowledge base and professional experience developed through various assignments supporting government agencies, development partners, and regional initiatives in Cambodia. It does not necessarily reflect the official positions of any affiliated institutions or partners. Featured images are generated by AI.