MoSCoW - To The Target

The MoSCoW Method and the Power of “Won’t Have”: The Scope Guillotine for Enterprise Deliverables

How to Eliminate Requirements Inflation, Anchor Contractual Definition of Done, and Deploy the 60/20/20 Iron Rule for Guaranteed On-Time Delivery

The most frequent cause of project failure is neither a lack of capital nor technical incompetence.

It is an insidious, chronic pathology known as Scope Creep (Requirements Inflation):

A project launches with a clear objective, a fixed budget, and an agreed three-month delivery schedule;
Two weeks in, the Sales Director approaches the team: “It would be fantastic if we could include Feature X—it would help us close enterprise deals!”;
One month in, Marketing requests an automated analytics dashboard, and Legal demands three additional compliance layers;
Everyone nods approvingly in the boardroom: “Yes, this is critical; we absolutely must have all of them!”.

When the delivery milestone arrives, reality detonates: nothing is ready on schedule, the budget has doubled, the engineering team is burned out, and the deliverable has devolved into an unmaintainable software or industrial chimera that satisfies no one.

Why does this recur across modern enterprise?

Because when confronted with an unvetted list of requirements, the untrained human brain refuses to make trade-offs. To an insecure, inexperienced, or politically timid manager, everything is “essential” and everything is “urgent”.

This is where the MoSCoW Method intervenes—engineered in 1994 by British software development expert Dai Clegg within the Dynamic Systems Development Method (DSDM / Rapid Application Development).

MoSCoW is not a simplistic checklist; it is a surgical scalpel of operational arbitration, engineered to compel decision-makers to answer one uncomfortable question:

“If we collide with an unexpected wall and resources are depleted, what can we sacrifice without killing the enterprise?”.

The Four Filtering Criteria of the MoSCoW Method

The framework operates as a mnemonic acronym formed from the consonants of four discrete classification tiers, separated by lowercase “o”s for phonetic cadence:

1. M — MUST HAVE (The Vital Core / The Survival Ticket)

Represents the non-negotiable operational baseline of the deliverable.

The Iron Rule: If this requirement is absent, the deliverable is legally null, technically unsafe, or fundamentally unusable for the client.
If a bank launches a mobile banking application, the client’s ability to authenticate securely and execute fund transfers is a Must Have. Without it, the application does not exist.
The Executive Litmus Test: “Can we deploy legally and operationally without this component?” If the answer is “No, the firm risks regulatory penalties, lawsuits, or immediate shutdown”, it is an authentic Must Have.

2. S — SHOULD HAVE (Critical Requirements with an Operational Workaround)

These are high-value commercial components of critical operational importance, possessing one vital distinction: a viable interim workaround exists.

These are features leadership urgently seeks to deploy, but if the final deadline is threatened by an unexpected technical bottleneck, the enterprise can survive the initial 30 days using a manual workflow, a dedicated spreadsheet, or specialized support triage.
The Executive Litmus Test: “If this module is not automated at launch, can we absorb the process manually or via temporary procedures for a few weeks without hemorrhaging clients?” If the answer is “Yes, it incurs manual overtime, but the enterprise survives”, the requirement is formally categorized as a Should Have.

3. C — COULD HAVE (Comfort Options / Opportunistic Enhancements)

Desirable, beneficial optimizations that enhance user experience (Nice-to-Have).

They carry zero direct impact on foundational product mechanics. They are engineered strictly if surplus time and capital remain, without endangering a single millimeter of the Must or Should categories.
They operate as the project’s primary shock absorber: the second unforeseen technical friction strikes, Could Have items are amputated first, without hesitation.

4. W — WON’T HAVE (THIS TIME AROUND) (The Scope Guillotine / The Budget Shield)

This is the most misunderstood, intellectually demanding, and powerful category within the architecture.

The letter “W” does not mean “We will never build this”. It strictly means: “NOT IN THIS PHASE / NOT IN THIS QUARTER” (Won’t have this time around).
It represents the official, signed ledger of viable ideas, seductive features, and commercial requests that are deliberately ring-fenced outside the active delivery perimeter.
The Won’t Have category dismantles the universal psychological fear of permanent loss. When you inform a sales director or enterprise client: “Your concept is brilliant, officially approved, but placed into the Won’t Have register for Version 1.0 and prioritized as item number one for Version 2.0 in six months”, you disarm political warfare without detonating the active budget.

The Pathology of “Must Have Inflation”: How the Tool Is Sabotaged

The most widespread corporate failure is degrading the MoSCoW framework into a political theater:

During quarterly planning, department heads fight to protect departmental vanity;
Sales claims all 20 of their requests are Must Have;
Marketing claims their 15 ideas are Must Have;
Engineering insists that 10 architectural refactorings are “absolutely vital”.

The result? A project backlog where 90% of requests are categorized as Must Have!

At that moment, the MoSCoW method is assassinated. If everything is Must Have, nothing is prioritized. You have recreated the exact chaos you sought to escape, and when ground friction hits, the system collapses.

The 60 / 20 / 20 Iron Rule of Systems Engineering

To halt requirements inflation, DSDM standards enforce an unyielding mathematical boundary:

No project plan is permitted to allocate more than 60% of total engineering capacity and capital to the MUST HAVE category!

Here is how resources are distributed across an armored roadmap:

Maximum 60% Effort represents MUST HAVE (The Vital Core): Guarantees the product ships stable, compliant, and functional. If an operational crisis strikes, this 60% core can be delivered on schedule even under severe duress.
Approximately 20% Effort represents SHOULD HAVE (The Value Margin): The competitive differentiators that make the product commercially attractive and operationally scalable.
Approximately 20% Effort represents COULD HAVE (The Contingency Shock Absorber): These 20% are not decorative luxuries; they are your contingency insurance. If Hofstadter’s Law or the Planning Fallacy strikes and tasks demand 30% more time than estimated, you do not slip the delivery date or request emergency bank lines; you simply amputate the Could Have items and reallocate engineering cycles to complete the Must and Should categories on schedule.
Beyond the Perimeter stands WON’T HAVE (The Defensive Wall): Everything exceeding resource constraints is frozen in writing.

The 60% Arbitration: Who Controls the Envelope and the “One In, One Out” Rule

The 60% mathematical ceiling limits volume, but does not eliminate internal political competition. How do you prevent department heads from fighting over who claims the limited 60% space?

An elite executive committee does not decide via democratic consensus. It deploys three objective arbitration mechanisms:

1. The Binary Fiduciary Criterion (The Attorney’s Scalpel)

A requirement qualifies for the 60% envelope strictly if answering affirmatively to at least one of these three inquiries:

Do we face regulatory fines, criminal liability, or operational license revocation without this on Day 1?
Does the technical architecture physically collapse (the database refuses to mount, the engine stalls)?
Does its absence directly forfeit over 30% of projected Q1 top-line turnover?

If negative, the request is automatically demoted to Should Have or Could Have, regardless of internal seniority or executive pressure.

2. The Zero-Sum Law: “One In, One Out”

The 60% envelope is not an elastic balloon; it is a rigid steel container measured in verifiable engineering hours.
When a stakeholder insists that an eleventh-hour commercial feature “must be a Must Have”, leadership does not debate opinions. Hand them a marker:

“We agree. Your feature is placed inside the Must Have envelope. But the container is fixed. Specify precisely which existing Must Have item from your division we remove and reassign to Won’t Have to clear the capacity.”

In 90% of cases, the enthusiasm evaporates instantly. When an executive is forced to finance a new request using their own departmental currency (sacrificing an existing deliverable), they realize the new whim was never truly “vital”.

3. The Supreme Arbiter: The Single-A Mandate (Accountable Owner)

Final arbitration does not belong to the committee; it belongs to the individual with their neck in the noose for the project’s P&L (Product Owner or COO). They listen to consultative advice, but exercise unilateral authority to draw the 60% line.

Commercial Psychology: Order Qualifiers vs. Order Winners

Here lies the most dangerous trap in commercial execution: the distinction between what makes the project work versus what caused the project to be purchased.

In industrial manufacturing strategy, codified by Professor Terry Hill of London Business School, two contrasting market forces govern transactions:

Order Qualifiers (Baseline Criteria): The mandatory baseline table stakes required simply to compete in the market. In banking, it is transactional security; in automobiles, it is braking systems; in software, it is database integrity. These are classified naturally as Must Have. The operational trap? Nobody falls in love with them! The client assumes them by default: “Of course it functions, that is why I am paying you!”.
Order Winners (The Purchase Catalyst): The dazzling differentiator that won the commercial contract over direct competitors. It is the real-time tablet executive dashboard, the interactive telematics filter, or the visual flourish that ignited the executive committee’s eyes during the final pitch.

The Fatal Error of the Naive Engineer

When technical friction strikes, an engineer lacking commercial instincts reviews the MoSCoW matrix with cold literalism:
“The database engine is Must Have; the executive dashboard is just a cosmetic surface, making it a Could Have. Cut it so we deliver on time!”.

The team deploys an immaculate technical backend on schedule without the dashboard. Engineering pops champagne.
What does the client experience? Absolute betrayal.
In their mind, they purchased a sleek red sports car with cream leather seating; you delivered a bare gray tractor chassis, announcing proudly: “Be thrilled, the transmission purrs!”.

The Broken Psychological Contract and the Retaliation Trap

Professor Denise Rousseau of Carnegie Mellon University proved the power of The Psychological Contract: beneath formal legal documents exists an unwritten ledger of emotional expectations and mutual assumptions.

When you amputate the client’s Order Winner, they may not sue you if the initial technical SLA did not explicitly guarantee it in Batch 1.

Instead, they transform overnight into an institutional adversary across the remainder of the contract:

They become aggressively pedantic;
They reject formal handovers over microscopic formatting variations or punctuation;
They freeze payments and demand 15 audit reports for trivial 50 USD inquiries;
They never voice the real reason: they are punishing you through every legal lever available because you murdered their prized feature without warning!

How to Commercially Arm MoSCoW: The Three Shielding Rules

An elite executive does not plan projects ignoring the client’s commercial vanity. Deploy three operational rules:

Rule 1: An “Order Winner” Is NEVER Classified as a Could Have!

If a feature won the commercial contract during the sales pitch, it is an irrevocable Must Have inside the psychological contract.
You cannot place it inside Could Have, knowing it will be the first item sacrificed when friction emerges!

If you must clear capacity inside the 60% envelope, cut complexity from the invisible backend: deploy an off-the-shelf database, execute an interim manual script behind the scenes for the opening month, but do not touch the feature that closed the sale!

Rule 2: Staged Delivery (Two-Wave Contracting)

If resources cannot safely deliver the heavy backend engine and the dazzling frontend feature simultaneously, do not bundle them into a single ambiguous milestone:

Sell the phased architecture upfront during negotiations:
“To guarantee absolute enterprise security, deployment executes across two formal contractual phases:
Wave 1 (Date X): We deploy the transactional core, compliance, and security infrastructure (Order Qualifiers).
Wave 2 (Date X + 30 Days): We deploy the executive dashboard and predictive analytics suite (Your Order Winner).”
The client is aligned: Wave 1 delivers institutional security, and Wave 2 delivers their prized visual capability guaranteed in writing, with zero sense of betrayal.

Rule 3: The Contractual Definition of Done (DoD) Shield

The fastest route to commercial disaster is accepting vague contractual clauses such as: “By November 15, contractor will present user interface for client approval”.
The client will invariably state: “I don’t like it! Change it!”, and “I don’t like it” is not an engineering unit of measurement.

Every Must Have requirement is paired within the contract with Quantifiable Acceptance Criteria (Contractual DoD):

Interface developed matching approved wireframes in Annex 1, utilizing HEX color palettes from the Corporate Brand Guidelines, formatted at 600px resolution, with a maximum of one cosmetic review cycle that does not alter layout architecture.
When a client demands an eleventh-hour subjective whim, do not debate opinions. Present the contract:

“The deliverable complies 100% with the Acceptance Criteria in Annex 2 of the signed agreement. This new feature is exceptional, but constitutes a formal Scope Change.

Under our operational protocol, we have logged it as priority number one in the Won’t Have (This Time Around) register for Wave 2 delivery in 60 days.

If your executive strategy mandates this feature go live this Friday, we issue a formal Scope Change Addendum: adding 3 weeks to delivery schedules and a 15,000 USD adjustment for supplemental engineering hours.”

You have returned the decision and the capital burden to the client’s desk. If it was merely an informal whim, it evaporates within 30 seconds. The client recognizes they are partnering with a serious executive firm, not an unhedged contractor working for free.

The Crisis De-escalation Protocol: Descending the MoSCoW Ladder

When a project is mid-execution and a major technical roadblock strikes, do not push the deadline and do not burn out your personnel on all-nighters.

Deploy the Ladder Descent Protocol:

Delivery Deadlines and Capital Budgets are FIXED and NON-NEGOTIABLE;
The only dynamic variable is SCOPE (What is delivered)!
Descend the ladder in reverse:
1. Step 1: Instantly eliminate remaining Could Have items and reallocate liberated engineering hours to clear the critical path;
2. Step 2: If the bottleneck persists, identify the affected Should Have component, officially demote it to Won’t Have (This Time), and activate the pre-planned manual workaround;
3. Step 3: The 60% Must Have core deploys on the exact committed day and hour.

Leadership and clients receive a stable, functional asset on schedule, while the deferred component is scheduled for the subsequent iteration.

Executive Conclusions

The Exhausted Sycophant: Promises everything to everyone, permits the 60% envelope to explode out of political cowardice, signs ambiguous contracts lacking acceptance criteria, cuts the exact feature that closed the sale, and transforms the client into an internal adversary who blocks invoices.
The Scope Guillotine Leader: Masters the commercial psychology of the client. Insulates the features that won the contract (Order Winners), enforces zero-sum discipline across the 60% envelope, anchors requirements using quantifiable contractual DoD, and deploys the Won’t Have category to defend team sanity and cashflow health.

Do not measure the success of a plan by how many wishes you promised on paper. Measure it by the courage to draw the line beyond which you state: “Not on our capital, and not on our sanity!”.

If you liked this article, you’ll love what’s inside. This tool is forged and battle-tested inside our playbooks: