Leistungsbeschreibung

Ausführliche Erklärung

Wird häufig unter einem Rahmenvertrag (MSA) angefügt. Zahlungsauslöser sollten mit den Rechnungsplänen übereinstimmen.

Beispiel

Phase 2 der Leistungsbeschreibung wird bei UAT-Freigabe gemäß Meilensteintabelle abgerechnet.

Warum Es Wichtig Ist

Gleicht rechtliche Verpflichtungen mit dem ab, was Sie in Rechnung stellen.

Wichtige Fakten

A statement of work (SOW) is a formal document that defines project specifics: scope, deliverables, timeline, milestones, acceptance criteria, and pricing.
Typically used alongside or in place of a contract for project-based engagements — common in consulting, software development, professional services, and construction.
Standard SOW components: project objectives, scope (what's in AND what's out), deliverables, timeline/milestones, payment terms, acceptance criteria, change-order process, assumptions, and signatures.
Master Service Agreement (MSA) + multiple SOWs is a common structure: the MSA covers legal terms once, individual SOWs cover specific projects.
A well-written SOW is the primary defense against scope creep — vague scope language is the #1 cause of project disputes and unprofitable engagements.

Wie es in der Praxis aussieht

A boutique web agency signs an MSA with a client in January. For a homepage redesign in March, they sign SOW #003-2026: deliverables (3 design concepts, 1 final design, responsive HTML/CSS), milestones (concepts March 10, design March 25, build April 15), pricing ($14,500 with 50% deposit + 50% on launch), assumptions (client provides copy, 2 revision rounds included), and acceptance (client signs off within 7 days of delivery or auto-acceptance). When the client requests 4 additional revisions in April, the SOW makes the change-order conversation easy.

Häufige Fehler

Vague scope language ('improve the website') instead of specific ('design and build a 5-page responsive marketing site with X, Y, Z features').
Failing to define what's OUT of scope — explicit exclusions prevent assumptions.
No change-order process — every small request becomes a free addition.
Missing acceptance criteria — projects drag on because 'done' is ambiguous.
Not requiring written signatures — verbal agreements are unenforceable in disputes.

Häufig gestellte Fragen

What's the difference between an SOW and a contract?

A contract typically covers the legal relationship (terms, IP, liability, dispute resolution). An SOW covers project specifics (scope, deliverables, timeline, price). Many engagements use an MSA (master contract) plus SOWs (per-project specifics).

Do I need an SOW if I have a proposal?

A proposal is typically pre-sale; an SOW is the formal post-sale agreement. The proposal can become an SOW with minor edits and signatures, or you can write a separate SOW after proposal acceptance.

What's the most important section of an SOW?

Scope and deliverables — they define what you're committing to deliver and what's out of bounds. Acceptance criteria comes second — it defines when 'done' is officially achieved (and final payment is triggered).

How do I handle scope changes mid-project?

Issue a change order: a brief amendment to the SOW that adds the new scope, new pricing, and new (if needed) timeline, signed by the client BEFORE doing the work. Don't fold extra scope into existing pricing.

Can a single SOW cover multiple projects?

Generally no — each distinct project should have its own SOW for clear scoping and acceptance. Multi-project arrangements use one MSA + multiple SOWs.

Was Ist Leistungsbeschreibung