How to write a transformation brief that an outside partner can actually price
Vague briefs produce vague quotes. A five-section transformation brief gives outside partners what they need to price the work accurately and catch scope problems before the project starts.
McKinsey and Oxford University found that large IT projects run 45% over budget and deliver 56% less value than predicted, on average. Scope creep is the leading cause, and scope creep almost always starts before the project does, in a brief that was too vague to constrain what the project was actually supposed to be.
A good brief is not just a description of what you want. It is the document that makes it possible for someone else to price the work accurately and assess whether it can be done.
Why most briefs fail to produce useful quotes
The briefs WAYF receives that produce unusable quotes share a common structure: three to five pages describing the desired outcome, the company background, and a list of aspirations. “We want a modern, scalable content platform that supports our growth.” “We need to migrate off our legacy CMS and build something that serves our editorial team better.” “We want to be AI-ready.”
These are goals, not briefs. They describe a destination without describing the starting point, the constraints, or the decisions that have already been made. The outside partner who receives this kind of brief has two options: ask the questions the brief should have answered, which delays the process, or make assumptions and price against those assumptions, which produces a quote that bears no reliable relationship to what the project will actually cost.
Projects routinely exceed their budgets because of scope creep and inaccurate forecasting. These projects are not failing because the engineering work was harder than expected. They are failing because the scope was never defined precisely enough for the cost to be estimated accurately. The brief is where scope definition either happens or does not happen.
A brief that produces an accurate, actionable quote has five sections. Each section answers a specific question an outside partner needs answered before they can price the work.
Section 1: What exists today
The starting point is an honest inventory of what exists, not a vision of the future.
This section should contain the current platform or platforms in use (name, version, hosting arrangement), how many content types or data objects the platform manages, how many people use it and in what roles, what integrations connect to other systems, what does not work (specific, named problems: not “it’s slow” but “publishing takes 45 minutes and requires a developer to push manually”), and what technical documentation exists and what does not.
Every quote for a content platform migration, a CMS rebuild, or a technology modernisation is a function of the complexity of the thing being replaced. A partner who does not know the integration inventory will not quote for integration work. A partner who does not know the documentation gap will not quote for discovery work. These are the line items that produce budget overruns when they are discovered mid-project.
The honest inventory also prevents a common failure mode: the organisation describes its situation more generously than it actually is, receives a quote based on that description, and then watches the quote expand when reality surfaces. An outside partner who discovers undisclosed complexity mid-project is not wrong to charge for it. The brief is the place to surface it.
We have built content platforms for organisations ranging from Ingersoll Rand to the Council of Europe Development Bank. The single biggest predictor of whether a project prices accurately at the start is how honestly Section 1 was filled out.
Section 2: What needs to be true when the project is done
This section describes outcomes, not features: what needs to be true about the organisation’s capabilities at the end of the engagement, not what you want to build to get there.
This section should contain specific, testable outcomes (“Editors can publish a new page without developer involvement.” “The CMS serves content to both the web application and the React Native mobile app from a single source.” “The platform is hosted in an EU data centre and meets GDPR data residency requirements.”), the surfaces the new system needs to serve, the workflows that need to work, the compliance or security requirements that apply, and what success looks like at 30, 90, and 365 days after launch.
Outcomes and features are not the same thing. “We want Payload CMS” is a feature. “Editors can publish a new product page without raising a ticket” is an outcome. An outside partner can design multiple technical paths to an outcome. They can only build one specific feature.
Outcome-framing also produces a more honest conversation about what is achievable in a defined scope. When the outcomes are specific, the partner can tell you which are addressable in phase one and which require phase two. When they are aspirational, the partner cannot make that distinction, and the aspirational outcome not addressed in phase one becomes the source of scope creep in phase two.
For teams evaluating Payload CMS specifically, our Payload partnership page covers the implementation patterns we use and where the platform performs best.
Section 3: What has already been decided
Every project brief arrives with decisions already made. Sometimes those decisions are explicit. More often they are implicit, assumed by the team writing the brief but not visible to the partner reading it.
This section should contain technology decisions that are fixed (if the organisation has standardised on AWS, or the engineering team works in TypeScript and will not take on PHP, those are constraints), vendor selections that are made (if Payload has already been selected, the quote is for implementation, not platform evaluation), timeline constraints that are real (if there is a hard deadline driven by a contract expiration, a product launch, or a board commitment, name it), budget constraints that exist (if the ceiling is €150,000, the partner needs to know that before spending two weeks designing a €400,000 solution), and what is not negotiable.
Partners spend significant time on proposals that turn out to be constrained by decisions the brief did not mention. A partner who does not know the timeline is fixed will propose a phased approach. One who does not know the budget ceiling will not flag that the scope exceeds it. Revealing constraints in the brief produces a useful response.
Cost overruns are common on IT projects, and many of them originate in briefs that withheld constraints the outside partner would have used to scope the project differently.
Section 4: What the team looks like
The outside partner’s scope and approach depend significantly on what internal capability exists and what does not.
This section should contain the internal engineering team size and their primary technologies, whether the internal team will be involved in the build or just in handoff and maintenance, whether there is internal project management capacity or whether the partner is expected to own it, whether there is a technical lead who can make architectural decisions or whether architectural decision-making is part of what the partner is being asked to provide, and how decisions get made (who approves scope changes, who is the final decision-maker).
An engagement where the outside partner provides pure execution against a defined architecture is priced differently from one where the partner is also responsible for architecture, project management, and stakeholder communication. Both are legitimate scopes, but they are not the same quote.
The absence of internal technical oversight is a risk signal that a good partner will flag. Organisations that run agency engagements without internal senior technical oversight are in a structurally vulnerable position. The brief is the place to be honest about what oversight capacity exists.
Section 5: What good looks like at each decision point
A project with no defined decision points runs until something goes wrong, at which point everyone argues about whose fault it is. Defined decision points give the outside partner and the organisation regular opportunities to confirm the project is on track and make adjustments before a course correction becomes a crisis.
This section should contain the phase structure the organisation expects (discovery, design, build, migration, launch), what is produced at the end of each phase (a technical specification, a prototype, a migrated dataset, a live environment), what decision the organisation needs to make at the end of each phase before the next one begins, and how the organisation will evaluate whether the phase output meets the brief.
A partner quoting against a single deliverable is quoting against maximum uncertainty. A phased structure with defined outputs at each phase gives partners a defined scope increment to price against. McKinsey’s large IT project research found that each additional year spent on a project increases cost overruns by 15%. The phase structure is the mechanism by which the organisation finds out what is going wrong before 15% has compounded into 45%.
The brief template
The five sections above map to a brief that runs four to eight pages in practice. The skeleton below is the starting point. The level of specificity is proportional to the usefulness of the quotes you receive.
TRANSFORMATION BRIEF
Project: [Name]
Date: [Date]
Submitted by: [Name, role]
Response requested by: [Date]
---
SECTION 1: CURRENT STATE
Platform(s) in use:
Hosting arrangement:
Content volume (items, types, pages):
Editorial team size and roles:
Developer team size and primary stack:
Active integrations:
Known problems (specific, named):
Documentation status:
---
SECTION 2: DESIRED OUTCOMES
By the end of this engagement, the following must be true:
[ ] Outcome 1 (specific, testable)
[ ] Outcome 2
[ ] Outcome 3
Surfaces to be served: [web / mobile / portal / internal / other]
Compliance requirements: [GDPR / HIPAA / SOC 2 / other]
Workflow requirements: [who creates, reviews, approves, publishes]
Success metrics at 30 / 90 / 365 days:
---
SECTION 3: CONSTRAINTS AND DECISIONS ALREADY MADE
Fixed technology decisions:
Fixed vendor selections:
Hard deadline (date and reason):
Budget ceiling (if applicable):
What is not negotiable:
---
SECTION 4: THE TEAM
Internal engineering capacity available for this project:
Internal project management capacity:
Internal technical lead / architectural decision-maker: [yes/no, name]
Key stakeholders and decision-making authority:
Point of contact for the engagement:
---
SECTION 5: PHASE STRUCTURE
Phase 1: [Name]
Expected output:
Decision required at end of phase:
Phase 2: [Name]
Expected output:
Decision required at end of phase:
[Continue for each phase]
Evaluation criteria: how will we know each phase output meets this brief?What to do with the brief once it exists
Sharing the brief with three or more outside partners produces quotes built on the same understanding of the problem. The variation between those quotes is informative: large variation means the partners interpreted the brief differently, which means either the brief has ambiguity that needs to be resolved, or the partners have fundamentally different approaches to the problem. Sharing it with only one partner produces a quote based on a single interpretation. For a trusted relationship where the partner’s approach is already known, that is fine. For a first engagement or significant scope, competitive responses produce better outcomes.
The brief is also a negotiating document. When a partner proposes a scope that exceeds the budget ceiling in Section 3, the brief gives you the basis for a descoping conversation: “Given the budget constraint, which outcomes in Section 2 can be delivered in phase one, and which should move to phase two?” This is a more productive conversation than “your quote is too high.”
When scope discussions arise mid-project, and they will, the brief is the document that establishes what was agreed at the start. The partner who says “that requirement was not in the brief” may be correctly noting that the project has grown beyond what was scoped. The brief is what makes that distinction legible.
FAQ
-
How long should a transformation brief be?
Four to eight pages for a mid-market technology project. Long enough to answer the five sections completely, short enough that an outside partner can read it in twenty minutes and understand what is being asked. Longer briefs containing aspirational language and background not directly relevant to scope produce longer responses that answer the wrong questions. Shorter briefs that skip sections produce quotes built on assumptions the organisation has not validated.
-
Should you reveal your budget in a brief?
Yes. The instinct to withhold the budget assumes that revealing it will cause partners to inflate their proposals to match it. In practice, partners who do not know the budget cannot tell you whether your scope fits within it. They quote against the scope as described, and the organisation discovers the mismatch at the proposal stage, after both parties have invested time. Revealing the budget ceiling produces a scope proposal that fits the constraint, with a clear view of what is included and what would require additional budget.
-
How specific do the desired outcomes need to be?
Specific enough to be testable. "We want a better editorial experience" is not testable. "Editors can create and publish a new product page without raising a ticket, with a draft-review-publish workflow that does not require developer involvement" is testable. The test: can you describe, in one sentence, how you will know at launch whether the outcome was achieved? If not, the outcome needs more definition.
-
What if you do not know what technology decisions have been made?
Write that explicitly in Section 3: "No technology decisions have been made; we are seeking input from partners on the recommended stack." This is a legitimate scope, it means the partner is being asked to recommend as well as price, and the quote will reflect that. Problems arise when implicit technology decisions are not surfaced, such as a strong engineering preference for TypeScript or an internal platform team that has already selected a hosting environment, and the partner prices against a different assumption.
-
How do you evaluate the quotes you receive?
Three criteria. First: does the proposal demonstrate that the partner understood the brief? Does their proposed scope address the outcomes in Section 2 and work within the constraints in Section 3? Partners who propose solutions that bypass the brief are signalling something about how they will handle the project once it is underway. Second: is the phasing structure aligned with what Section 5 described? Third: are the people described in the proposal the people who will actually work on the project, not a senior team assembled for the pitch that will be replaced by junior staff at build time?
-
Is a brief different from an RFP?
A brief is the internal document that defines what the organisation needs. An RFP (Request for Proposal) is the formal document sent to partners, which may include procurement requirements, evaluation criteria, terms and conditions, and selection process details in addition to the brief content. For mid-market technology projects, the formal RFP structure is often unnecessary and can slow procurement. In our experience, a well-structured brief sent directly to a few partners often produces better outcomes in less time than a formal RFP process for mid-market scopes.
Sources
We're booking content platform
engagements for 2026.
Twenty-five minutes to walk through the work and decide if we're the right team for it. Scoping and a fixed price come after.