Hundreds of thousands more and six months late, because the client changed leaders

Several hundred thousand RMB in extra development fees, paid by the client. Delivery pushed back 6 months.

The cause wasn’t that the plan failed on the floor. The client got a new leader.

I was the project manager on that project. This post covers why a signed blueprint didn’t hold, and the two things I’d now settle first, at kickoff and at sign-off.

1. The blueprint was signed and development under way; the new leader wanted his own way

When it happened, the blueprint had already been signed. Development had started against it.

The client’s new leader took over, went through the plan from the top, and concluded that the process didn’t fit his management philosophy. He wanted fewer people and more automation, done the way things were done in the field he knew.

The trouble was that he came from a different industry.

What worked there didn’t necessarily fit here: the business habits were different, and so was the nature of the industry.

What he wanted to overturn was a few process flows in the system. The hardware wasn’t touched.

Once the rework was laid out, the list was long: revise the design, revise the blueprint, review and sign again, rebuild the features already in development against the new blueprint, and finally re-estimate the cost. Had this come up before the blueprint, it would have been a few pages of paper.

2. A clash of philosophies ends up as a negotiation over money and time

Of all the changes I’ve dealt with, this kind is the hardest to negotiate.

When something doesn’t work on the floor, everyone agrees it has to change. When it’s a difference in philosophy, there’s no clear right or wrong. The original plan hadn’t failed; a new person simply brought a new set of ideas.

The blueprint was signed. But a signature covers the plan itself. It doesn’t cover what happens when someone new wants to change it.

The negotiation dragged. Requirements were changed, then changed back, and each time the schedule had to be recalculated.

What finally settled it was the client’s own frontline operations team. A new requirement only counted once they had confirmed it. However good the planners’ ideas were, they had to respect how the floor actually worked.

While making the changes, we held one line: optimize and update on top of the original plan, without overturning the main process flow.

In the end, the system functions were changed according to the confirmed requirements, and we, the vendor, agreed to redevelop them. The client paid several hundred thousand RMB in development fees. Delivery came 6 months late.

Fewer people and more automation sounds reasonable. But after the revised flows went live, the floor spent a long time adjusting before it could just about cope. How much to automate depends on what the floor can absorb.

3. A signature can’t stop a change of leader; agree “how changes are handled” first

Looking back, what actually settled the plan wasn’t the signed blueprint. It was the frontline team’s sign-off.

This time the client did end up paying, but that outcome had to be negotiated back and forth. Write it down up front, and when a change comes you follow the terms instead of negotiating from scratch every time.

If I did it again, I’d settle two things first.

At kickoff, agree how problems will be handled. A change of leader or a change of plan counts as a change too; write that in.

At blueprint sign-off, have the leader who can actually make the call sign as well, and have everyone accept one rule: once it’s signed, any change from anyone is a formal change, and requirements, cost and schedule get re-estimated.

There’s also one signal I now watch closely: the client replaces the person who makes the decisions. At the handover, I ask one more question: do you accept the existing plan?

In the previous series, the post on acceptance listed three traps that keep acceptance from closing; one was the business changing its top leader and the requirements changing again. This is a case of it, except that the new leader arrived during development.

---

When the client changed leaders and wanted to overturn a signed blueprint, how did your project handle it?