Why does the handover often fail?
In many NGOs, one team writes the proposal and a different team delivers the project. The proposal team knows why a target was chosen, which partner was promised a role, and what the donor said on a call. The implementation team receives a PDF. Months later, someone discovers that a target was based on a number nobody can source, or that a promise was made that nobody remembers.
A handover is the moment to move that knowledge across, while the people who hold it are still available.
The cost of this gap is real. A delivery team may spend its first months learning what the proposal team already knew. A target may be too high because the writer rounded up to make the proposal look strong. A partner may expect a role that the new team has never heard of. A handover cannot remove every surprise, but it moves most of them from month six to week one.
What should the proposal team hand over?
Use a checklist so nothing depends on memory. At a minimum:
- The signed agreement and any side letters or emails with the donor that changed the terms.
- The approved budget, with notes on how each line was calculated.
- The logframe or results framework, with the source of each baseline and target.
- The work plan and the timing assumptions behind it.
- Partner details, roles and any draft agreements.
- Promises and commitments made to the donor or communities, in plain words.
- Reporting duties: what is due, when, and in what format.
- Known risks and assumptions from the design stage.
What should the handover meeting cover?
Plan half a day. Do not just present documents; walk through the logic.
- Why this project? The need, the target group, the choice of location.
- How was the budget built? Unit costs, exchange rate assumptions, staff time.
- What do the numbers mean? How each indicator is counted, and where the target came from. Our article on baselines and targets explains why this matters.
- What did we promise? Read the promises list aloud and assign an owner to each.
- What worries us? The proposal team often knows which part of the plan is weakest.
Take notes in a shared document during the meeting. Record each question that nobody can answer and give it an owner and a date. After the meeting, send the notes to all attendees within two days, and ask for corrections. These notes become the first version of your project file.
If the proposal team has already moved on to another bid, book their time before the meeting. A one-hour follow-up call a month later often answers the questions that only appear once work starts.
What should the implementation team check?
Before the first spend, the project manager should test the plan against reality.
- Can we recruit the staff in the budget, at the budgeted cost, by the planned date?
- Do the timelines work with procurement lead times and the seasons?
- Are the targets reachable with the budget and the team?
- Are partners ready to start, and are agreements signed?
- Does the finance team understand donor rules on eligible costs and approvals?
Write down every gap. A gap found in week two is a conversation with the donor. A gap found in month eight is a problem.
Share the findings with the proposal lead and the program director. Some gaps need action inside the organization, such as extra staff or a changed schedule. Others need the donor, such as a budget revision or a new start date for an activity. Our article on change requests in grant-funded projects explains how to raise these in a clear way.
Do not hide a gap to avoid an awkward talk. Donors usually respond better to an early, specific request than to a late surprise.
What should happen in the first 30 days?
Use the first month to turn the handover into a working system: assign roles, set up the project records, hold a kick-off with the whole team, agree reporting dates, and set a first review. Our article on the first 30 days of a new grant lists the steps in order.
Keep the handover pack alive. Store it in one shared place, name a person who keeps it current, and add each later decision to it. When a staff member joins in month five, they should be able to read the pack and understand why the project looks the way it does. A pack that is only used once, at the start, is a missed chance.
Where EMPOBase fits
In EMPOBase, Programs holds the project record, including the Project Charter and RACI, so the implementation team starts from a written plan and clear roles rather than a folder of files. Donors keeps donor records, and the logframe sits with the project. These records store what you enter; they do not capture the reasons behind the proposal, so someone still needs to write them down in the charter. See the platform overview for the modules involved.