¿Qué Es Declaración de Trabajo
Un anexo detallado que describe el cronograma, los hitos y la aceptación de un acuerdo.
Explicación Detallada
Generalmente se adjunta a un MSA. Los disparadores de pago deben coincidir con los calendarios de facturación.
Ejemplo
La Fase 2 de la DDT factura tras la aprobación de UAT según la tabla de hitos.
Por Qué Es Importante
Alinea las obligaciones legales con lo que facturas.
Datos clave
- 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.
Cómo se aplica en la práctica
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.
Errores comunes
- 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.
Preguntas frecuentes
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.
Recursos Relacionados
Última verificación: May 2026
Términos Relacionados en
Consejos de facturación que realmente ayudan
Únete a más de 5,000 freelancers y propietarios de pequeñas empresas. Un correo por semana con consejos prácticos de facturación, tips fiscales y novedades del producto.
Sin spam, nunca. Cancela cuando quieras.