Entry is the first contact with the client system. Contracting is the explicit agreement about what the work is, who is involved, what access you have, and how it ends. Peter Block's Flawless Consulting is the standard treatment.

Contracting is the stage practitioners most often skip and most often regret skipping. Nearly every stalled OD effort can be traced back to a contract that was never made explicit.

Evidence: Weak as research, strong as practitioner consensus. No controlled studies show that explicit contracting improves outcomes. It is nonetheless endorsed near-unanimously across the practitioner literature, and the failure mode it prevents — a diagnosis that implicates a sponsor who never agreed to be examined — is well documented in case reports. Use it because the downside of skipping it is severe and the cost is ten minutes.

Use when: starting any OD engagement, internal or external.

Do not use when: never. Even a two-week internal effort deserves ten minutes of explicit contracting.

What a contract must settle

  • The presenting problem vs. the real problem: write down the presenting problem verbatim, then state your own early hypothesis separately. Revisit both after diagnosis.

  • Sponsor and client are different roles: the sponsor pays and authorizes; the client system is the group whose behavior must change. If the sponsor is not part of the client system, the diagnosis will eventually implicate someone who never agreed to be examined.

  • Scope and boundaries: what is in, what is explicitly out, and what happens if diagnosis points outside the boundary. It usually does.

  • Access: who you may interview, what data you may see, whether you may observe meetings, and whether you may talk to customers or patients.

  • Confidentiality: what is attributable, what is aggregated, and what the sponsor will and will not be told. Say this to every interviewee, every time.

  • Decision rights: who decides which interventions proceed. If the answer is "we will see", the answer is "nobody".

  • Your role: expert, pair of hands, or collaborator. Block's three modes. Most OD work should be collaborative; most clients initially want a pair of hands; most consultants default to expert.

  • Success criteria and measures: agreed before diagnosis, refined after.

  • Exit: what conditions end the engagement, including the condition that the work is not working.

Wants and offers

A usable contracting conversation is two lists, spoken aloud:

  • What I want from you: access, time, candor, a decision forum, an executive who will act on unwelcome findings.
  • What you can expect from me: a diagnosis you may not like, feedback to participants before leadership, no surprises in public, and an honest statement when an intervention has failed.

Red flags at entry

  • The sponsor names the intervention before the diagnosis: "we want a culture workshop", "we want to reorganize into squads".
  • The sponsor excludes themselves from the scope.
  • The sponsor requires that a specific conclusion not be reached.
  • The real decision-maker will not meet you.
  • The timeline is set by an external announcement already made.
  • You are asked to provide external validation for a decision already taken.

Examples by audience

  • Health care: contracting must name the clinical governance route, the information governance rules for patient data, and whether findings that touch patient safety can be withheld. They cannot; say so at entry.

  • Software: contracting should settle whether you may read the issue tracker, the deployment telemetry, and the incident history. This data is usually more honest than the interviews.

  • Executive: when the client system is the executive team itself, the contract must state that the CEO's own behavior is in scope, and how feedback to the CEO will be delivered. Agree this before you hear anything.

See also

Organizational Development — a comprehensive practitioner's guide to OD for health care professionals, software engineers, and senior executives. Every framework says what the evidence is, and where it is weak.

Source and contributions: github.com/organizational-development. Built with the Lily Design System™.