Consulting and recruiting
Documenting proprietary methodologies before you sell a consulting firm
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
To document a consulting methodology before a sale, write down its name, scope, inputs, steps, artifacts, decision rules and worked examples, then check who owns every artifact. A buyer values a method that is written, reused across engagements and clearly owned by the firm, not one that lives in a founder's slides and memory.
Key takeaways
- A documented method reduces key-person risk because the firm can deliver it without its author.
- Decision rules, written in plain words, matter more than the list of steps, because judgment is what makes a method distinct.
- Run a who-owns-it check on every template, tool and example before a buyer's counsel does.
- Worked examples must be de-identified so client confidential information never enters the method file.
- Tagged project codes, training records and engagements led by others prove the method is real.
Why document a methodology before selling the firm?#
Documenting a methodology before a sale turns a founder's judgment into an asset the buyer can keep. Buyers discount value that depends on people who may leave, and an undocumented method is exactly that kind of value.
Documentation also surfaces ownership questions early. Writing a method down forces the firm to list its templates, tools and examples, and that list is what a buyer's counsel will ask about. It is better to find the contractor-built model with no IP assignment now than in a data room.
The work pays off even if no sale happens. A written method shortens the time it takes new managers to lead engagements, makes quality reviews consistent across partners and gives the firm a stable base for training, proposals and any later decision about licensing its records.
What a methodology document should contain#
A methodology document should let a capable manager who did not create the method run it on a new engagement. That standard keeps the document practical and stops it from turning into a brochure.
Decision rules deserve the most space. Steps are often similar across firms; the judgment about when to escalate, which root causes to test first or how to frame a recommendation is what makes a method yours.
- Method name and scope: the problem it addresses, for which clients, and when not to use it.
- Inputs: the client data, interviews and documents needed before work starts.
- Steps in sequence, with the purpose of each step.
- Artifacts produced at each step: templates, models, workshop materials and report sections.
- Decision rules: how the team chooses between options, in plain words.
- Quality checks and review points, including who signs off.
- Roles: which work a partner, manager or analyst does.
- Worked examples from real engagements, fully de-identified.
- Version history, authors and the date each section was last reviewed.
The who-owns-it check for each artifact#
The who-owns-it check asks, for every artifact in the method, whether the firm owns it outright, shares it or uses it under someone else's rights. The answer usually depends on who created the artifact, in what role and under which agreement.
Close gaps before a sale where you can: obtain written assignments from contractors, rebuild borrowed material in the firm's own form, and drop examples you cannot de-identify. Counsel should confirm the position on anything uncertain.
| Artifact | Usual starting point | What to check |
|---|---|---|
| Templates and guides written by employees | Usually firm-owned when created as part of the job | Employment agreements include an IP assignment for work outside the core role |
| Material written by partners or owners | Depends on the partnership or operating agreement, since owners are not always employees | An IP clause assigning partner-created work to the firm |
| Models and tools built by contractors | May belong to the contractor | A written assignment of rights to the firm |
| Frameworks a partner brought from a prior employer | May belong to the prior employer | Prior employment terms and how much was rebuilt |
| Text and diagrams adapted from published frameworks or books | The wording and graphics belong to the author or publisher; general ideas usually do not | What was copied verbatim, attribution and permitted use |
| Materials co-developed with a client | Often shared or client-owned | The engagement letter's IP clause |
| Final client deliverables | Often client-owned | The engagement letter; use only as de-identified patterns, if at all |
| Scripts and software | Firm code plus third-party components | Open-source licenses and contractor terms |
How to capture a method that lives in partners' heads#
A method that lives in partners' heads is best captured from recent engagements rather than from a blank page. Start with real project folders and reconstruct what the team actually did, then ask the partner why.
- Pick a few recent engagements where the method worked well, plus one where it struggled.
- Reconstruct the sequence from project folders, timesheets and review comments.
- Interview the partner who led each one, focusing on decisions and the reasons behind them.
- Draft the document against the outline above.
- Have a manager who did not build the method run it on a live or mock engagement using only the document.
- Fix the gaps that test exposes, then version the document and store it in a controlled location.
Keeping client confidential information out of the method#
Client confidential information has no place in a methodology document, even in examples. Engagement letters typically restrict how client information is used, and a method file that buyers, new hires or licensees will read is the wrong place for it.
De-identify examples by removing client names, distinctive figures, locations and details that would let a reader recognize the client. Where an example cannot be made anonymous without losing its point, describe the pattern in general terms instead. Keep original engagement files under their normal retention and access rules, separate from the method.
Evidence that the method is real#
Evidence that a method is real comes from the firm's records, not from the document alone. A buyer will ask whether the method was actually used, whether it produces consistent work and whether people other than its author can run it.
| Claim | Evidence a buyer can test |
|---|---|
| The method is used widely | Project codes or tags showing which engagements used it |
| It produces consistent work | Quality reviews and project reviews across engagements |
| Others can deliver it | Training records and engagements led by people other than its author |
| The firm owns it | IP assignments, version history and authorship records |
| It wins work | Proposals that reference it, with win and loss outcomes |
Illustrative: a supply chain consultancy codifies its network review#
Illustrative: a fictional supply chain consulting firm sells a distribution network review that its founder developed and still reviews personally. Ahead of a possible sale, the managing partner asks senior managers to document it from recent engagements.
The ownership check finds that a contractor built the core cost model without a written assignment, and that one worked example uses a client's real site list. The firm obtains an assignment from the contractor, replaces the example with a de-identified pattern and tags past projects that used the review. When a buyer later asks how the method survives the founder's departure, the firm shows the document, the tagged projects and engagements led by other partners.
How SourceX treats documented methods and the records behind them#
SourceX treats a documented method as context for the records behind it rather than as something to license on its own. The engagement records that show a method in use, such as proposals, project reviews and partner comments, are the record families SourceX evaluates, with client-confidential material removed.
Each package follows the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The SourceX Evidence Packet records provenance and licensing rights, which is where the who-owns-it work above pays off a second time.
Frequently asked questions
Should we patent or trademark our methodology?
Trademarks can protect a method's name, but the method itself is usually protected through confidentiality and trade secret practices rather than patents. The right mix depends on the method and your market, so talk to IP counsel before filing anything or publishing details.
Does documenting the method make it easier to copy?
It can if the document is handled carelessly. Treat it as confidential: limit access, mark it, require confidentiality agreements from anyone who reads it and track who holds copies. Those steps also support trade secret protection, which generally depends on reasonable measures to keep information secret.
How long should a methodology document be?
Long enough for a capable manager to run the method without its author, and no longer. Most of the length should go to decision rules and examples rather than the firm's philosophy. A concise document with clear rules is more convincing in diligence than a thick manual.
Who should write it?
A senior manager or partner who uses the method but did not invent it is often the best writer, with the original author reviewing. That pairing produces a document others can follow and tests whether the method transfers beyond its creator.
Can we document a method we developed during a client engagement?
Possibly, but read the engagement letter first. Some agreements give clients ownership of work developed for them, while others let the firm keep general know-how and pre-existing tools. Counsel can tell you which parts of the method are the firm's to document and reuse.
When should we start documenting before a sale?
Start before any buyer conversation, because the document is most convincing when engagements led by people other than its author already exist. That takes real projects, not a writing sprint. Firms that begin early can also fix ownership gaps calmly instead of negotiating them under diligence pressure.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.