Explaining the handover process for a client switching agencies (from the receiving side)

I've also been on the handing-over side, so let me add two points from there.

1. Handovers happen at the worst moment of the relationship and are therefore usually done badly. If a "handover procedure" clause is added to the contract, the emotional part decreases: what, to whom, and within how many days will be written from the start.

2. Let me also say something to the handing-over agency: a proper handover is the best marketing. Two clients we handed over properly came back for other work two years later. Those who slammed the door don't come back.

Here's how it went for us: when taking over, we held a single handover meeting with the old agency and it helped a lot.

Two hours, recorded, just Q&A. Our team prepared beforehand and wrote down questions. We couldn't have learned in two weeks on our own what we learned in those two hours.

The client had put this meeting in the contract, otherwise it wouldn't have happened. I recommend it.

As a small agency, let me add: don't change anything in the project you take over in the first month just because it's "ugly."

That's the first reflex of every taking-over team, ours was too. Then we learned that there's usually a reason behind that ugly-looking solution, and cleaning up without learning that reason means breaking something that works.

Answer the question "why was it done this way" before changing it. Even if there's no answer, the fact that you looked is what protects you, not what slows you down.

Exactly, and not many people know this. Hasty decisions become decisions you have to fix six months later.

Correct me if I'm wrong.

Theres one point Im curious about. If scope grows either time or budget must grow. There is no third option.

That's all, sorry if I went on too long.

Let me speak from the other side; I'm on the supplier side. When you try to change everything at once, nothing settles.

Most time waste accumulates in tasks waiting for approval. Good luck with that.

I'm writing this so you don't make the same mistake... Just because everyone does it doesn't mean it's right.

I'd say don't rush. If code ownership isn't in the contract, you have no bargaining power when leaving.

Proven by experience.

The answer above hits the nail on the head. Most time waste accumulates in tasks waiting for approval.

Of course, it varies if your situation is different.

Let's separate the concepts, they're getting mixed up. Hasty decisions become decisions you have to fix six months later.

Most time waste accumulates in tasks waiting for approval. Hope this helps.

To get into the details: Solutions that work at a small scale collapse when you grow; I learned this late.

Good luck with that.

Thanks, this was very helpful. Don't hesitate to ask; those who don't ask always pay more.

I'm also curious if anyone does it differently.

Same here. If you don't write this down from the start it leads to arguments later.

Of course it varies if your situation is different.

Following. The real issue isnt the number but what its based on.

Thanks that was the answer I was looking for. anyway code without setup documentation isnt yours, even if you have it.

Implementing a change request process doesn't slow things down, it speeds them up. Proven by experience.

You're right, I've been down that road too. Processes without records never improve, because you don't know what to fix.

We got stuck at the same point for a while. Payment schedules should be tied to project phases, not calendar dates.

When we decide without measuring, we always end up in the same place. I'm also curious if anyone does it differently.

There's also a measurement aspect to this. When making a decision, first look at what data you have on hand.

Proven by experience.