The MVC framework: how to scope software projects that actually get built

The scoping problem

We have reviewed dozens of project briefs over the past decade. From startups pitching their first product to enterprises modernizing legacy systems. The pattern is consistent: most arrive as freestyle descriptions that are simultaneously too vague to act on and too specific in the wrong places.

A couple of pages of narrative. An Excel spreadsheet someone wants "turned into an application." A list of buttons and screens sketched during a meeting. Occasionally, a 40-page requirements document listing every field and dropdown - but missing the fundamental question of why this system needs to exist at all.

Not every organization has a professional business analyst. And investing weeks in detailed requirements before validating whether a project is worth building is often a misallocation of effort.

The standard approaches fail in predictable ways. Vague briefs - "we need a platform for managing customer orders" - communicate nothing about what makes this organization's problem distinct from existing solutions. Over-specified documents prescribe a solution before the problem is understood. Feature lists copied from competitor products carry no indication of whether they align with actual business goals, budget, or operational reality.

Motivation, Vision, Constraints

We developed a framework that extracts more actionable information from a single page than most organizations produce in weeks of requirements gathering.

MVC: Motivation, Vision, Constraints.

Motivation answers one question: why does this need to exist? Not what the system should do. Why it matters. What problem it solves, who experiences that problem, what it costs to leave it unsolved, and why previous attempts haven't worked. A project without clear motivation is a project that shouldn't start.

The difference between useful and useless motivation is concrete. "Our field technicians log service calls on paper, then manually enter them into SAP two to three days later. This delays billing, causes missed SLA deadlines, and costs each technician four hours per week in data entry." That is actionable. "We need a mobile app for field service management" is a solution masquerading as a problem statement.

Vision describes the future state - not a feature list. What does a working day look like after this system exists? What metrics change, and by how much? What becomes possible that wasn't before? Vision framed as "technicians complete service documentation on-site in under three minutes, the office sees job status in real time, invoices go out within 24 hours" gives us a target we can measure. A list of capabilities - offline sync, GPS tracking, photo capture, SAP integration - gives us a shopping cart with no destination.

Constraints define the boundaries within which a solution must operate. Budget range, not "as cheap as possible" - an actual number. Timeline: is there a regulatory deadline, a competitive window, a season? Technical: what existing systems must this integrate with, and what cannot change? Organizational: who approves, what skills exist in-house, what is the risk tolerance? Non-negotiables: what must be true about this solution regardless of other trade-offs?

Experienced teams treat constraints as design inputs. Inexperienced teams treat them as obstacles. The difference determines whether a project stays within scope or explodes past it.

Why this works better than feature lists

When a software team receives features, they estimate each one and add them up. The result is a price. But not insight.

Features don't exist in isolation. A feature that appears simple might be expensive given specific constraints. A feature assumed essential might be irrelevant to the actual vision. And a feature that sounds impressive in a brief might be economically irrational at the scale and budget the project actually operates within.

MVC exposes these misalignments before money is spent - not after. The framework forces a conversation about ends before means. In our experience, roughly a third of features in a typical brief fail the MVC test: they don't serve the stated motivation, don't advance the defined vision, or can't be delivered within the documented constraints. Identifying them before development starts is the difference between a project that ships something useful and one that ships something complete but irrelevant.

The MVC test for feature decisions

Once MVC is documented, every proposed feature gets evaluated against three questions. Does it serve the motivation? Does it advance the vision? Does it fit within constraints?

Features that fail any of these get cut or deferred. This discipline is how organizations avoid the pattern we see most often: building 60% of what they need plus 40% of what they don't.

How to apply it

If you're initiating a project, write one page of MVC before contacting any vendor. Motivation, Vision, Constraints. This forces clarity before quotes are collected, and it gives any competent engineering team enough context to determine whether the project is feasible and what it will roughly cost.

If you're a software team receiving a brief, ask for MVC before estimating. If the client cannot articulate motivation, vision, and constraints, the project is not ready to be estimated. Producing a number at that stage is guesswork dressed as expertise.

If you're mid-project and scope discussions have become contentious, return to MVC. "Does this feature serve our motivation and advance our vision within our constraints?" resolves most arguments faster than another workshop.

One page of MVC produces better outcomes than fifty pages of feature specifications. The output isn't a bigger document. It's a project that solves the actual problem.