Scoping Policy

April 27, 2026

- - - Scoping That Protects Delivery, Cost, and Working Relationships

Clearly and tightly defined scopes protect all stakeholders and contributors. Clarity in "Scope of Implementation" and "Scope of Care" improve deliverability, increase precision, and protect relationships.

Clear scoping does more than fight scope creep. It defines what we are building, what we are supporting, what changes require a formal expansion of scope, and which parts of a project remain with the project if it ever moves to another provider.

At Ehven Consultants, scoping is not paperwork theater. It is one of the main instruments we use to protect delivery quality, control costs, reduce confusion, preserve portability where applicable, and keep provider/client relationships healthy.

Whether the work sits primarily in Web, AI, DO/IT, Marketing, Product Management, or Coaching, the same principle applies: define the work clearly, define the boundaries clearly, and define the next-step process before confusion becomes expense.

Two Scopes, Not One

Most serious projects involve two distinct scope layers.

Implementation Scope defines what is being built, configured, written, designed, integrated, or otherwise delivered into the project or engagement itself.

Care Scope defines what is being supported, monitored, updated, tested, reported on, reviewed, or otherwise maintained over time after implementation.

This distinction matters because not all project value lives in the same place.

Some deliverables are integrated directly into the project and remain with it. Other capabilities are delivered through ongoing care systems, internal tooling, managed environments, reporting layers, monitoring layers, and provider-operated processes. Those care capabilities can be extremely valuable, but they are not the same thing as implementation deliverables, and they do not always move with the project by default.

That is why we scope implementation and care separately whenever both apply.

What Scope Covers, and What It Does Not

A written scope should answer three basic questions:

What is included right now
What is not included right now
What kind of change requires a formal Change Request

A Change Request is typically required when a request materially changes one or more of the following:

feature set
requirements
integrations
design depth or design system
content volume or content model
data structures
testing burden
delivery sequence with meaningful effort impact
launch targets
support obligations
governance, compliance, privacy, or security posture

Not every refinement requires a Change Request. Reasonable adjustments inside an approved scope are normal. But once a request expands the work, the risk, the operational load, or the ongoing support burden in a meaningful way, it should be rescoped formally rather than absorbed casually.

That protects both sides.

Why We Scope by Features Instead of Vague Phases

We scope work in terms of Features because Features are easier to define, price, explain, test, document, approve, and maintain than broad delivery “phases” that quietly hide multiple obligations inside them.

Every project or engagement we deliver is assembled from one or more Features. Those Features may come from Web, AI, DO/IT, Marketing, Product Management, or Coaching, depending on what the work actually requires. That cross-discipline reality is normal. Serious projects often depend on more than one operational lane, even when one area is clearly primary.

This approach gives scoping sharper edges:

what is included by default
what is optional
what is core
what expands or supercharges the baseline
what belongs to implementation
what belongs to ongoing care
what remains portable
what depends upon a managed ecosystem

In short, Feature-based scoping produces cleaner proposals, cleaner delivery, cleaner invoices, and fewer surprises.

Good Scopes Define More Than Deliverables

A serious scope does not merely list what we owe. It also defines the roles, responsibilities, approvals, and dependencies required for success.

That includes matters such as:

who supplies content
who supplies access
who approves strategy, copy, design, or functional changes
who is authorized to expand scope
what third-party dependencies exist
what must happen before later steps can begin
what delays may result from incomplete or late inputs
what assumptions were used in scoping the work in the first place

This is not bureaucracy for its own sake. It is how good teams avoid preventable confusion, rework, false urgency, and relationship damage.

When responsibilities are not named clearly, projects tend to drift. Drift becomes friction. Friction becomes cost. We prefer to intercept that earlier.

Support Boundaries Matter

We stand behind the work we scope, select, implement, and support within the agreed delivery and support model. That does not mean we offer a blanket warranty over every inherited component, every third-party modification, every client-supplied asset, or every outside-provider decision.

Risk tends to increase when a project depends upon:

code, content, or configuration supplied by outside providers
plugins, services, or components selected outside our process
direct changes made by staff or third parties after delivery
unsupported hosting or unsupported operating conditions
legacy work that has not yet been evaluated, stabilized, or rebuilt within a defined scope

That does not mean such work cannot be supported. It means the support boundary must be defined honestly.

When needed, we can separately scope evaluation, stabilization, migration, replacement, hardening, supervised coexistence, or limited support around inherited or third-party work. What we do not do is quietly pretend that unsupported variables are risk-free.

Schedules Depend on Scope Discipline

Target dates only mean something when scope, approvals, inputs, and dependencies are being managed realistically.

Projects slow down when requests multiply without review, when approvals are delayed, when required materials arrive late, when external dependencies change, or when teams are asked to absorb new work under old assumptions.

We do not treat schedule changes casually. At the same time, we also do not pretend that every shift means failure. Sometimes the right response is resequencing. Sometimes it is a Change Request. Sometimes it is a pause pending missing prerequisites. Sometimes it is a deliberate reduction in scope to preserve a deadline.

What matters is that these tradeoffs be made visibly, responsibly, and early enough to be useful.

Some Things Travel with the Project. Some Do Not.

One of the most important distinctions in our scoping model is the difference between integrated implementation deliverables and provider-dependent care capabilities.

Implementation Features are integrated into the project or engagement itself. Those deliverables generally remain with the project, even if it later moves to another provider.

Care Features are different. Many ongoing support behaviors depend upon managed environments, internal tooling, reporting systems, monitoring systems, automation layers, operational controls, and provider-run processes. Those capabilities often remain tied to the care model under which they are actually delivered.

Some exit, transition, or portability support may be available through separately scoped work. In some cases, project-specific modifications are required to reproduce certain capabilities outside our ecosystem.

That is why portability should be discussed during scoping, not during an exit conversation when everyone is already annoyed and suddenly pretending to love documentation.

A Few Plain-English Examples

Here are a few examples of changes that often require formal scope review:

“Can we add a new integration?”
Usually yes, but it often changes requirements, testing, security, and support scope.

“Can the same site now support memberships, gated content, or another department?”
Possibly, but that is typically an expansion of feature scope, workflow scope, and user-management scope.

“Can this AI assistant now use private internal documents?”
Possibly, but that may change governance, retrieval, permissions, logging, and ongoing care requirements.

“Can you support the plugin or service another provider selected?”
Sometimes. But that depends on technical fit, supportability, and whether the component can be brought inside a responsible scope boundary.

“Can we keep the deadline and also add these new requirements?”
Sometimes. But usually only by expanding budget, reducing other scope, changing sequence, or changing expectations.

“If we move the project later, what stays with us?”
Implementation deliverables generally remain with the project. Managed care behaviors do not automatically do so.

The important thing is not whether the answer is always yes. The important thing is that the answer be real.

Define the Scope Before the Work Defines You

If you are planning a new project, stabilizing an inherited one, expanding an existing stack, or trying to bring order to recurring change traffic, we can help you define a scope that supports quality, predictability, portability where appropriate, and future growth without turning the project into a pricing fog machine.