While a good portion of our team are software architects, a critical backbone of our company is the relentless pursuit of excellence in project management. This newsletter is for everyone because we are a team and teams need to know the roles of other people to understand why they do what they do. I encourage all team members to read this carefully.

In the past, project management has not been a tight process at Intoria. As we work to make foundational changes so Intoria can scale, our Client Change Policy is an evolving document that sets expectations, guides decisions, and allows for more profitable projects. Here is what I’ve been working on to contribute to the responsible action we all balance: providing benchmark results in customer satisfaction while ensuring strong profit for business health and growth.

Please notice our values of Responsibility, Generosity, Craftsmanship, and Speed in the following and feel free to reply if you have suggestions for adds or edits as this will end up being in all project Statements of Work going forward.

Client Change Policy

Purpose

We want you to get a great outcome, not a stressful project. This policy exists to keep delivery clear, quality high, and budgets predictable. It also keeps the relationship clean. No surprise invoices and no surprise scope creep.

Our Promise

We will be generous with clarity, care, and problem-solving. We will not be generous with hidden scope. That is not fair to you, and it is not sustainable for us.

Core idea

We deliver what is written in the Statement of Work (SOW). During delivery, we will also uncover good ideas and needed adjustments. When that happens, we capture them, price them fairly, and decide with you what to do next.

What counts as a “change”

A change is any request or expectation that alters one or more of these:

1. Scope: new features, new fields, new screens, new reports, new workflows, new roles, new integrations, new data rules, new environments, or anything not already described in the SOW.
2. Timeline: additional work that would push milestones or the final date.
3. Risk: increased complexity, security exposure, performance requirements, or testing requirements.

Some things feel “small” in the moment but still change scope. Those small changes are exactly where budgets leak if we are not disciplined.

What is included without extra cost

These are included as part of normal delivery:

1. Clarifications that match the written scope. If something is already in the SOW but needs a clearer explanation or a small adjustment to align with the original intent, we treat it as in-scope.
2. Bug fixes. If something we delivered does not meet the acceptance criteria in the SOW, we fix it.
3. Normal polish. We will not ship sloppy work. Reasonable refinements that improve usability, stability, or clarity are part of craftsmanship, as long as they do not add net-new capability.

What is not included without a decision

These are not included unless we agree to a swap or an add:

1. New capability. “Can it also do…” is usually new scope.
2. Extra variations. New report versions, new dashboard layouts, new export formats, extra notification rules, extra user roles, extra permissions logic, extra workflow branches.
3. Data cleanup or backfill beyond what was agreed.
4. New integrations or expanded integration behavior.
5. Extra rounds of revisions beyond what is agreed for a deliverable.

How we handle changes

When a change request comes up, we will do three things quickly and clearly:

1. Capture it. We write it down in the “Change List” so nothing gets lost and you can see it.
2. Classify it. We will label it as one of these: a) Clarification (already in scope) b) Swap (in-scope if something else is removed) c) Add (new scope that needs more budget or time)
3. Price it. If it is a Swap or Add, we will tell you the impact before work begins. That includes cost and timing.

The rule

If a request changes scope, timeline, or risk, it becomes a written change decision. We do not start the work until you approve the tradeoff (swap) or the added budget/time (add).

Swaps vs Adds

Swap means: we can do it, but something of similar effort comes out. Same budget. Same delivery window, as long as the swap is agreed quickly. Add means: we can do it, but it increases the budget and or extends the timeline. We provide a short change quote and you choose whether to proceed.

Change Bank

Whenever possible, we include a small, pre-approved pool of time or budget for reasonable tweaks discovered during delivery. If your SOW includes a Change Bank:

1. We will track remaining balance in your weekly update.
2. We will only use it with your awareness.
3. When it is used up, all further changes become Swap or Add.

How we handle “But I expected…”

When you say “but I expected…”, we treat it as a signal to get aligned fast, not a conflict.

We will respond like this:

1. “I hear the expectation.”
2. “Here is what the SOW and acceptance criteria say.”
3. “Here are the options: clarification, swap, or add.”
4. “Which tradeoff do you want?”

This protects you from runaway cost. It protects us from hidden work. It protects quality for both sides.

Client responsibilities that prevent surprises

These items reduce rework and change churn:

1. Timely feedback. We will request feedback by specific dates. Delayed feedback can affect timeline.
2. Decision-making. When options are presented, choosing one quickly keeps momentum and cost down.
3. Named owner. One person on your side should have authority to approve swaps and change requests.

Communication cadence

We will keep this simple:

1. Weekly update that includes: progress, next steps, risks, and the Change List.
2. Any change request is summarized in writing with impact and options.

Thoughts?