ExistBefore
IT

Professional

How to protect a proprietary consulting methodology

Your methodology is your true product, even when you call it a "framework" to sound more elegant. If you want to prevent it being reused with a different name and larger logo, you must document it well and methodically. Start immediately: what is in your head today, tomorrow could be in someone else's presentation.

4 min read

1. How it usually happens

Every consultant has a methodology. At first it's a set of slides, checklists, and insights gathered over years of work. Then it takes shape: a name, phases, maybe a circular diagram looking straight out of a strategy manual.

The problem arises when this methodology leaves your perimeter.

Classic scenario:

presentation to client → workshop → sharing materials → access to operational documents.

A few months later:

client internalises process

or changes supplier

or, in the most creative case, someone "gets inspired"

A frequent industry anecdote: a consultant finds their own framework, with slightly changed names, in a tender they participate in as a competitor. Same phases, same order, same outputs. Only font was different.

There are also less obvious dynamics:

  • a collaborator reusing methodology parts in other projects
  • a client integrating it into own processes without distinguishing what was developed internally and what wasn't
  • a preliminary version shared too early becoming someone else's working base

Methodology is by nature "transmittable". And that is precisely the critical point.

2. What you need to prove

This is not about protecting an abstract idea, but documenting concrete and structured existence of your methodology at a certain moment.

In practice, you must be able to prove:

  • that methodology already existed in defined form
  • how it was structured (phases, logic, tools)
  • what elements composed it
  • how it was presented and used
  • any evolutions over time
  • what was shared with third parties and when

If someone uses something very similar, the question becomes:

"Was this structure already formalised before?"

3. What to collect

Here you need to collect both the "form" and concrete use of methodology.

Key materials:

  • descriptive methodology documents (PDF, Word, Notion export)
  • presentation slides
  • diagrams, canvas, visual frameworks
  • operational manuals or playbooks
  • templates used in projects (e.g., reports, checklists, workshop canvas)
  • intermediate methodology versions
  • emails where methodology is sent or explained
  • screenshots of platforms where it's shared
  • recordings of calls or workshops where it's illustrated
  • contracts or offers referencing it

An often-underestimated detail:

even "working" files (drafts, mind maps, messy versions) tell how methodology was formed.

4. How to proceed

Protection starts with order.

First phase: consolidate

  • gather all materials describing methodology
  • create a clear and readable version (even synthetic)
  • assign a coherent name to methodology and its components
  • organise files logically

Second phase: versioning

  • save a complete "base" version
  • assign a name with date (e.g., "Method_X_v1_2026-05")
  • keep subsequent versions without overwriting

Third phase: contextualise

  • link each version to a real context (presentation, project, proposal)
  • keep emails or chats where it is shared
  • note when and with whom it was used

Fourth phase: timestamp

  • create coherent packages (e.g., methodology + slides + sending email)
  • timestamp these materials in the state they exist
  • repeat process when methodology evolves significantly

Fifth phase: discipline sharing

  • when sharing methodology, do it traceably
  • avoid "on the fly" sending of un-versioned files
  • maintain consistency between what you show and what you archive

Over time, build a clear timeline:

idea → formalisation → usage → evolution

5. Mistakes to avoid

Many problems stem from daily habits.

  • keeping methodology only in your head or scattered files
  • continuously updating same document without version track
  • sharing incomplete or unidentifiable materials
  • using generic names like "framework_final.pptx"
  • never linking methodology to contexts where it was used

There is also a cultural mistake:

considering methodology as something "obvious", thus hardly needing documentation.

In reality, it is your main asset.

Useful precautions besides timestamping:

  • always insert a clear header in documents (name, version, date)
  • explicitly describe phases and logic, avoiding only graphic schemes
  • maintain consistency between commercial and operational materials

Orderly documentation makes reconstructing facts much easier. Free timestamping adds a precise time reference to materials you organised.

6. After documenting

When your methodology is well documented:

  • you can share it with greater control
  • you can better clarify what is included in projects
  • you can handle any improper uses with solider bases

If you suspect unauthorised or ambiguous use:

  • gather concrete examples of usage
  • compare them with your documented versions
  • prepare a clear timeline

At that point you can:

  • open direct confrontation with client or involved subject
  • involve a more structured corporate referent
  • ask a specialised consultant's opinion

Having orderly materials changes the conversation tone.

It moves from "looks similar to me" to "this structure already existed in this form on this date".