Let’s imagine a very realistic situation.
The project has been running for several months. The structure, design, and technical specification have been approved. Part of the functionality is already complete.
And then the client-side PM changes.
The new person opens the mockups and says: “I would build this differently.”
And yes, sometimes a fresh perspective really does reveal solutions the team may have overlooked or nuances that were not fully considered.
As one of the characters in the well-known comedy Shelmenko the Orderly put it:
“I’m saying the same thing, and it’s all true — only somehow, just a little, not quite so.”
The problem starts elsewhere: when “I would do it differently” automatically turns into “let’s rebuild it.”
In our practice, there was a project where three client-side managers changed over the course of development: an executive director, a marketer, and a commercial director.
And each of them, quite logically, looked at the system from the perspective of their own role.
The marketer wanted more promotional tools.
The commercial director wanted the website to be more closely aligned with sales.
The executive director focused on processes.
All three perspectives may be valid. But if the project is rebuilt after every change of manager, the business starts paying not for the development of the system, but for changing management viewpoints.
That is why, when a new PM joins, we recommend making a freeze-frame first.
Start by recording:
- what has already been approved;
- why those decisions were made;
- what has already been implemented and paid for;
- what is currently in progress;
- what dependencies the proposed change may affect.
Only after that should the new vision be discussed.
For example, the request to “slightly change the way the catalog looks” may be a local task. Or it may affect the catalog itself, product pages, filters, the mobile version, and the already implemented ordering logic.
On screen, both scenarios may start with the same words: “Let’s just rework this part.”
In the estimate, they look very different.
A new PM has every right to challenge previous decisions. But the right to review them is not the same as a reason to write off the work that has already been done.
First, the context. Then, the impact assessment. Only then — the changes.
When a good PM takes the project in the wrong direction
There is a less obvious problem than simply changing requirements.
A new PM may be a strong professional: able to justify decisions well, respond quickly, stay active, and remain fully engaged in the project.
And at the same time, gradually move the project away from the reason why the business owner invested in it in the first place.
An executive director looks at operational processes.
A marketer looks at acquisition and content.
A commercial director looks at sales.
There is nothing unusual about that.
The problem begins when a person’s job title effectively starts defining the strategy of the entire system.
For example, the marketer proposes more landing pages, promotional blocks, and campaign mechanics. From their perspective, this is perfectly logical.
But the owner expected the new website to reduce the workload on the sales department first and foremost: clients would be able to receive documents themselves, see their own prices, check order statuses, and review their transaction history.
And after a few months, the company may end up with a very decent website.
Just not the one the business intended to pay for.
That is why, in long-term projects, the following relationship is not enough:
Client PM ↔ Contractor PM
There needs to be one more control point — a person on the business side who is responsible not for a single department, but for the ultimate business goal of the project.
This is often the Owner or a project sponsor.
And that does not mean the owner should discuss every button.
Quite the opposite.
The owner needs to approve a different level of decisions:
- what business problem are we solving;
- which processes must definitely change after launch;
- which fundamental changes are acceptable;
- where the PM’s authority ends and the owner’s decisions on budget and priorities begin.
This alignment becomes especially important when a new proposal changes not a UI detail, but the logic of the project itself.
An extra button is a working-level PM issue.
But turning a corporate website into a B2B system — or, on the contrary, dropping part of the planned automation — is already a business decision.
A good PM should not be merely a “transmitter of the owner’s wishes.” They need enough freedom to do their job.
But the strategic direction of the project should not quietly change every time the name in the Zoom meeting changes.
Giving access is not the same as handing over the project
The worst-case scenario when the PM changes is to send the new person a link to the specification, open the necessary access, and say: “Everything is there. You’ll figure it out.”
Because the documents usually explain what was approved.
But why another option was rejected, where the team had already made a compromise, who insisted on a certain decision, and what the owner considered critical — all of that often remains buried in email threads, calls, and the previous PM’s memory.
That is why project handover has to be controlled.
1. Record the current state
Not “the website is 70% complete,” but specifically:
- what has been completed and accepted;
- what is currently under development;
- what has not yet been started.
2. Gather the key decisions in one place
For example, in Jira, Confluence, or another system used by the team.
It should contain:
- the current technical specification;
- designs and prototypes;
- the estimate;
- approved changes;
- minutes or recordings of important meetings.
It is especially important to preserve decisions that have already led to actual development work.
3. Hand over not only the decisions, but also the context
“We made the catalog this way” is not enough.
Better: “We considered three options. We chose this one because of these constraints and these business requirements.”
This significantly reduces the risk of reinventing a wheel that the team already considered and rejected before.
4. Put new requests on a separate list
Do not mix them with bugs or unfinished work.
If something does not match the approved specification, that is one issue.
If the new PM simply wants it done differently, that is a scope change and should be assessed separately in terms of budget, timeline, and impact on already completed parts of the system.
This distinction is important.
Otherwise, the new manager’s wishes can very quickly turn into “the contractor’s unfinished work,” even though the team actually implemented exactly what had been approved before.
5. Hold one joint meeting
The ideal setup is:
previous PM + new PM + contractor representative + the person responsible for the business outcome.
Document the outcome in writing.
Not for the sake of bureaucracy.
Two months later, phrases like “I thought we agreed on something else” cost much more than one proper meeting record.
Do you need to stop the entire project when the PM changes?
No. A PM change does not automatically mean the whole team should pause everything.
If the developers are working on an independent, long-approved block that the new vision does not affect, there is little sense in creating downtime.
What should be paused is the work that may actually be reconsidered.
That is the difference between a controlled project handover and a panic-driven restart.
Changes are a normal part of long-term IT projects. Especially when development lasts several months and the market, company processes, team, and business priorities evolve.
The goal is not to prevent a new PM from proposing their own solutions.
The goal is to make sure that, at every such point, the business clearly understands:
- what exactly we are changing;
- why it is necessary;
- how much it will cost;
- how the timeline will change;
- and what has already been built will need to be reconsidered together with the new decision.
At Molfar, we believe this is the healthier model for managing long-term web projects.
Not: “The previous PM said so, therefore we are not changing anything.”
And not: “A new PM has arrived, so let’s start everything over.”
But a normal, controlled change process — with context, impact assessment, and a clear understanding of what exactly the business is paying for.