Late Descoping Is Pure Incompetence

Amateurs descope when they run out of time. Professionals descope before it's even necessary.

Have you ever worked on a project where close to the deadline where must-haves suddenly turned into won’t haves?

It’s happened to me many times over in my career and it’s a sign of pure incompetence. Late descoping is a red flag, because those must-haves were never must-haves to begin with.

Descoping late in the project is bad, because you’re descoping at a point in time when it matters the least.

Everybody has already been burdened with the unnecessary scope. You waste huge amounts of time to deliver things you no longer need. All that unnecessary scope and complexity is still lurking in your codebase ready to drag you down.

---

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

---

Amateurs descope late in the project. Professionals descope before it’s even necessary and rescope when they have more and better information at their disposal.

That may seem like a strong statement, but let me explain why.

Gall’s Law and the Folly of Late Descoping

Professionals who have suffered the wreckage of late descoping feel Gall’s law in their bones.

Gall’s Law:

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

Because of their scars of experience they can’t help but to aggressively descope early and add complexity gradually by taking into account reversibility and optionality.

You can only do this if your scope is rooted in solving a real-world problem, not a fixed functional scope decided up-front. If a stakeholder screams something is a must-have that doesn’t make it a must-have. There must be a real-world reason for it to matter.

You don’t build a complex system that works: you grow one. A working system evolves by making changes to a simple system that works.

Professionals know that excessive scope decided up-front can put your whole project at risk.

Set Internal Milestones That Focus On Early Disappointment

You should work in a way that fosters early disappointment and respect Gall’s law. The alternative, late disappointment, is extremely risky. Late disappointments is one of the biggest reasons why many projects fail.

The best and quickest projects show early and swift progress. I’ve been involved in many product rebuilds, and all of them that didn’t respect Gall’s law failed miserably.

But what if your stakeholders make everything a must-have? You’re not powerless and still have control over the early internal milestones. When your stakeholders don’t allow you to descope, you can still set internal development milestones where you do aggressively descope.

You can use the information from those internal milestones to rescope future must-have milestones they don’t want to budge on, before you run out of time.

Evolve your complex system gradually from a simple system that works. The key part is that it works.

Late scope cuts are scars of incompetence. Early scope cuts are a sign that you know what you’re doing. If it’s an option, you’re delaying important decisions to a point in time when you have a better understanding and more information.

Stop being a victim to late descoping, by doing early and gradual rescoping. Postpone what you can easily add later and delay decisions that greatly benefit from more information to the last responsible moment.

Don’t build a cathedral unless you know what makes your shed inadequate.

Once you know what makes your shed inadequate, you might no longer need a cathedral.