How to Build a Book Around Your Proven Methodology

Open your last proposal and turn to the page headed “Our approach”. Four boxes with arrows between them, a week count under each, a list of deliverables. That page is your methodology, and it is the thing your clients actually sign for.

It is also the hardest thing to put in a book. Expand that page and you get a manual: accurate, dull, and a free kit for a prospect’s internal team. Hold it back and you get opinions with “contact us” where the method should be.

The middle route starts with being precise about what your method is.

A methodology is a process clients pay you to run

A framework is a model for thinking: a 2x2, five factors, a maturity ladder. A reader can use it in a meeting the day they read it. A methodology is a sequence of work with inputs, outputs, decisions and time attached. Diagnose, design, implement, review. Clients do not buy it to think with. They buy it to have it done.

So a methodology book has to show work moving: what happens first, what must be true before the next phase starts, and where the work usually breaks. If what you have is a model rather than a process, read how to turn a framework into a book instead. If you have neither yet, start with how to create a framework for a book.

	Framework	Methodology
What it is	A model for seeing a problem	A sequence of work that changes it
Natural chapter unit	One element of the model	One phase of the work
Where the book’s value sits	Applying the lens to varied cases	The decisions inside each phase
Main risk on the page	A clever diagram with no depth	A manual, or a brochure

If your method has a timeline and deliverables in your proposals, it is a methodology, so write it as one. We think squeezing it into a five-letter acronym to look like a framework throws away its most useful property, which is the order of the work.

Where to draw the line: the what, the why and one cycle of the how

Our rule: the book teaches what each phase is for and why it works, plus enough of the how for a capable reader to run one cycle, once, on a small problem. The engagement sells everything after that: scale, calibration to the client’s data, the politics, and adapting when phase two shows that phase one got the brief wrong.

A reader who has run one small cycle believes the method works and has seen how much judgement the full version takes. In our view that makes them a far better prospect than someone who only read a description. That is a judgement, not a finding, and some advisers would tell you to give away less.

Hiding the method protects less than most authors assume. The US Copyright Office’s Circular 33 restates the rule in 17 U.S.C. § 102(b) that copyright does not cover any “idea, procedure, process, system, method of operation”. Its own example is a book explaining a new system: copyright protects the text and illustrations, but “does not give the author the right to prevent others from employing the system”. What protects your income is the judgement a book can describe but not transfer. (General information on US law, not legal advice; if part of your method may be patentable or a trade secret, see a lawyer before publishing.)

Element	In the book	Kept for engagements
Phase names, purpose and sequence	In full	Nothing held back
Decision rules at each fork	Most of them	Rare edge cases
Diagnostic	A short version readers can score themselves on	The full, calibrated version
Templates, scoring models, facilitation scripts	Described, perhaps one sample	The full set
Rollout across a large organisation	Named, with signs you need help	The paid work

Show the forks, not only the steps

Your competitors’ approach pages look a lot like yours. What differs is what happens at the forks: the moment in phase two when you decide the brief was wrong, or the signal that tells you to stop a pilot early.

A book that lists steps without forks reads like a process document. One that shows them reads like sitting beside you in an engagement. Write a phase card for each phase before you draft a single chapter. If the forks are hard to see because you make them on instinct, the main-site guide to turning expertise into a book framework shows how to build a decision map from your hardest cases.

Give failure modes more space than feels comfortable. Your buyers have lived through a project that died at exactly the point your phase three is designed for, and an honest account of how it goes wrong earns more trust than another success story.

Credit the public standards; claim only what is yours

Most methodologies sit on public foundations. A process-improvement method may borrow the DMAIC cycle. A delivery method may run in Scrum sprints. A compliance method may follow an ISO management-system standard. Buyers who know these will ask what is different. Name the lineage, then claim only your additions: the changed sequence, the extra decision point, the diagnostic. We think that is also the more persuasive version.

The terms matter once you quote rather than describe.

• Openly licensed methods. The November 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland is offered under CC BY-SA 4.0, which requires credit, a link to the licence and a note of changes, and anything built on the material must go out under the same licence. Describing Scrum in your own words and citing the guide is cleaner for a commercial book.
• Copyrighted standards. ISO and IEC hold the copyright in their standards. Their joint guide, How to best use IEC and ISO Standards (2017), says including extracts “is encouraged” with correct acknowledgement, but asks you to contact IEC or ISO for authorisation.
• Other consultants’ methods. The IMC USA code of ethics asks members to honour the rights of fellow consultants and firms and not to use “their proprietary information or methodologies without permission” (Article 12.0). Read the licence on any certification toolkit you use too. Ownership of methods built while employed is covered in how to write a book as a consultant.

Where the element comes from	Example	What to do in the book
An openly licensed public method	Scrum Guide	Describe and credit; reuse text only on the licence’s terms
A copyrighted standard	An ISO management-system standard	Cite by number, paraphrase, get authorisation before quoting
A widely taught technique	DMAIC, weighted scoring	Describe in your words; do not present it as yours
Another consultant’s or firm’s proprietary method	A former firm’s diagnostic	Leave it out unless you have written permission
Your own addition	Your decision rules, your changed sequence	Name it, claim it, show the evidence

Choose the chapter architecture, then fix the order inside each chapter

One chapter per phase is the obvious shape and usually the right one, but not the only one.

Architecture	Shape	Best when	Main risk
Phase by phase	Problem chapters, one chapter per phase, then running it for real	The sequence is stable and order matters	Reads like a manual if chapters only list steps
Fork by fork	Chapters built around the five or six biggest decisions	Your value is judgement and phases vary by client	Readers lose the sequence
One engagement, start to finish	A single anonymised or composite engagement followed through every phase	The method is easier shown than told	Hard to disguise; one case cannot show the range

We would use phase by phase for most consulting methodology books, borrowing one thing from the third row: thread a single example, labelled hypothetical or composite, through every phase chapter, so the reader watches one problem move instead of meeting a new case every twenty pages.

Then give every phase chapter the same internal order, so readers learn where to look:

1. The moment. What is going wrong for a typical client at this point.
2. What the phase settles, and why it works.
3. How the alternatives handle it. Hiring, software, a standard method, or doing nothing.
4. The forks. Straight from the phase card.
5. The running example, one cycle further on.
6. How it goes wrong.
7. The exit check, and one thing the reader can do this week.

Point three is where most methodology books turn into sales copy. If a standard method is good enough for a simple case, say so; readers with complicated cases will trust you more for it. For the wider book shape around these chapters, see how to structure a business book.

Evidence: tag each engagement to a phase and a fork

Permission and anonymisation are covered in client stories and case studies in a book. A methodology book needs one extra step: tag every anonymised engagement with the phase and the fork it illustrates.

Lay it out as a grid, engagements down the side and phases across the top. Empty columns are claims you cannot yet support. Crowded ones are usually where your real expertise sits and may deserve two chapters. Include at least one engagement where the method failed or you changed it afterwards. To an experienced buyer, a method that has never been revised sounds untested, not proven.

Pattern claims need a count: “in nine of fourteen”, with the fourteen written down, beats “in most”.

Software can help here. WritebookAI runs a source analysis on the PDF, Word and text files you upload, such as anonymised proposals, decks and reports, and shows what the material covers and what is missing, so an empty phase is visible before chapter planning. A verification interview resolves gaps, and the chapter plan comes with beat sheets. Chapters are drafted from your material; when a client result or statistic is missing, the draft leaves it out and asks you rather than inventing it, and you approve every chapter. It will not set your give-away line or check a standard’s licence. If your archive is small, a spreadsheet does the tagging just as well.

Worked example (hypothetical): a software-selection consultant

Imagine an independent consultant who helps 50-to-300-person companies choose and contract business software such as a CRM. Her approach page has four phases: Diagnose, Design the evaluation, Trial, and Decide and contract.

Lineage. Weighted scoring and reference checks are standard procurement practice, and her book says so in chapter three. Her additions are three decision rules:

• Trial the client’s three ugliest real workflows, not the vendor’s demo script.
• If the top two vendors score within five points, decide on the cost and difficulty of leaving, not on features.
• If more than a third of the must-have requirements came from one department, go back to Diagnose.

Give-away line. The book has the four phases, those rules, a twelve-question diagnostic and a one-cycle walk-through in which a fictional 80-person distributor chooses a CRM. Her 300-line requirements library, negotiation playbook and workshop scripts stay in engagements.

Chapters:

1. Why software choices go wrong after the contract is signed
2. What firms try instead: the RFP template, the analyst report, the reseller’s advice
3. The method on one page, and where it comes from
4. Diagnose: finding the requirements that matter
5. Design the evaluation: turning requirements into a test
6. Trial: the three ugliest workflows
7. Decide and contract: when the scores are close
8. When the method failed: an engagement that skipped Diagnose
9. Running it in a larger organisation
10. Doing it alone or getting help: an honest test

A reader could run one small purchase from chapters four to seven. A 200-person firm facing a six-figure ERP decision would still want her in the room, which is the point.

Before you outline: four cards and a colleague

Take the approach page from your latest proposal and write a one-sheet phase card for each phase. Give the cards to a colleague in a different field and ask: could you run this once, on something small, with only these pages?

Where they say no, the book needs more how. Where they could run your whole engagement, you have written the manual; move the delivery assets back out. Once every phase sits between the two, fill in the lineage table, tag your engagements to the cards, and only then open a blank chapter plan.