Agency's PM changed, new person doesn't know our project — how to ensure continuity?

my PM changed twice too. the second time I said 'I want to see the PM's name in the contract' and the agency agreed now we're waiting for the onboarding process.

pm change is normal. request written onboarding for the new person but have them hold a meeting.

PM Change Protocol: 1. 'Dedicated PM' written in contract 2. Change notice: min 2 weeks prior 3. Onboarding meeting: old + new PM 4. Documentation: project history file 5. Knowledge transfer: 1-2 weeks 6. Direct line: new PM's email/phone

When PM changes: 1) Make a written request to the agency ('I want to be informed if the PM changes'). 2) Update the contract. 3) Meeting with the new PM. 4) Make them hand over project documentation.

We got stuck at the same point for a while. Solutions that work at a small scale collapse when you grow; I learned this late.

There's a trap here, let me mention it. The system lives on after delivery; maintenance is a separate line item.

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

I have a question. The system lives on after delivery; maintenance is a separate line item.

Proven by experience.

You're right.

Exactly, and not many people know this. Access credentials should be opened in the company's name, not personal accounts.

Payment schedules should be tied to project phases, not calendar dates. Of course, it varies if your situation is different.

This thread is archived.

The most overlooked point about project manager changed is this: Start with a small trial; don't commit to everything at once.

Of course, it varies if your situation is different.

If you're going this route, sort this out first. People defend habits not processes. Resistance comes from there.

Everything goes well for the first three months; problems arise in the fourth.

Do you think this works at any scale? Taking notes for two weeks yields better results than a six-month estimate.

When you try to change everything at once, nothing settles. That's all, sorry if I went on too long.

Thanks, that was the answer I was looking for.

There's a trap here, let me mention it. Everything goes well for the first three months; problems arise in the fourth.

Implementing a change request process doesn't slow things down, it speeds them up. I'm also curious if anyone does it differently.

Exactly like that. In legacy systems, the most expensive thing is unknown dependencies.

Every "we'll look at it later" in a meeting means unbilled work. Correct me if I'm wrong.

Im in the same situation thats why Im asking. The real issue isnt the number but what its based on.

Of course it varies if your situation is different.

There's a common mistake people make when doing this. Everything goes well for the first three months; problems arise in the fourth.

Solutions that work at a small scale collapse when you grow; I learned this late. If you have questions, write them; I'll answer as best I can.