Project Management

Please login or join to subscribe to this thread

Has an "Approved" Change Ever Caused a Problem You Didn't See Coming?

linkedin twitter facebook   Change Management   Communications Management   Cost Management  
avatar
Syed Ashir Riaz
Community Champion
AI-Powered Social Media Strategist | Gujranwala, Pakistan

Last month, a client asked for one small feature. The budget was fine, the timeline was fine, so we approved it quickly. What we missed was that QA needed extra time to test it, and QA was already busy for two more weeks. The change looked "correctly approved," but the project still got delayed because of it.

Now, before approving any change, I ask one simple question: "Who else does this affect that we haven't checked with yet?" This small habit has already saved us from two similar problems.

Has this ever happened to you: a change that looked fine but caused a problem somewhere else?
Sort By:
avatar
Bahadirhan Cicek Dresden, Sn, Germany
Similar experience. We received the request, team evaluated after their "okay", management had approved as well. Effort was estimated and approved, schedule delay was acceptable and it was not entirely out of scope, more like a performance measure rather than a new feature implementation.

Problem was the misjudgment of complexity and dependency. Simple hardware change caused delay due to underestimated software effort and completely ignored layout effort. It was also unavoidable because of weak requirements and specifications. This is very common in small, old companies. Many processes are not formally defined. Therefore, this experience was also a good process improvement topic later.
avatar
Mouhamadou Abdoulaye Sar
Yes, and it still stings a bit.

We agreed to add one extra field to a registration form. Two days of development, nobody blinked. What nobody thought about was everything sitting downstream of that form: the user guide, the screenshots in the training deck, the translations into two other languages, and a training session already booked with sixty people. The build finished on time. The launch slipped three weeks because the documentation and translation work had never been part of the estimate.

What I learned the hard way is that we were estimating the change, not the consequences of the change. The dev effort was right. The impact assessment barely existed.

Your question is a good one. The version I use now is close to it: who has to change something because of this, and who finds out too late? I also ask the person requesting the change to name the affected teams themselves rather than guessing on their behalf, because they usually know one dependency I don't.

The other habit that helped, echoing Bahadirhan's point, is treating capacity as part of the approval and not just cost and schedule. Two days of work means nothing if the only person who can do those two days is booked for a month. A change board that looks only at budget and dates will keep approving things the organization has no room to absorb.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"It is an important and popular fact that things are not always what they seem. For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons."

- Douglas Adams

ADVERTISEMENT

Sponsors







Newsletters

Jul 22: Your AI Onboarding Problem
Jul 8: Stop Negotiating, Start Reframing
Jun 24: Acumen Is a Process, Not a Place

See all newsletters