Hey folks! As someone who automates infrastructure for a living, I never thought I'd be using an LLM for *documentation* work. But drafting a solid Statement of Work (SOW) is a critical, repeatable process—so naturally, I started looking for ways to make it more efficient. 😅
Here's my step-by-step method. It treats ChatGPT like a junior analyst you're pair-programming with, not a magic document generator.
**Phase 1: The Structured Prompt**
I start with a very detailed prompt that sets the stage. I feed it the project's core details in a clear structure, almost like a Terraform variable file.
```markdown
ROLE: You are a technical proposal writer for a cloud consulting firm.
CONTEXT: We are drafting an SOW for a new client, "Alpha Corp," to migrate their on-premise web application to AWS.
KEY REQUIREMENTS:
- Lift-and-shift of 8 web servers and 2 databases.
- Target architecture: EC2 (web) & RDS (db).
- Need 24/7 support for first month post-migration.
- Must include security baseline configuration.
- Project timeline: 6 weeks.
TASK: Generate a first draft of the SOW sections for "Scope of Work" and "Deliverables." Be specific, avoid fluff, and use clear bullet points.
```
**Phase 2: Iterative Refinement & Gap-Filling**
The first output is never perfect. I then have a conversation to refine it, just like code review.
* **I ask for expansions:** "Make the security baseline deliverables more specific. List actual tasks (e.g., 'Configure AWS Security Groups to least-privilege principles')."
* **I challenge assumptions:** "The draft doesn't mention database migration downtime. Propose a mitigation strategy and add it as a subsection."
* **I request formatting:** "Reformat the deliverables section into a table with columns for Deliverable, Acceptance Criteria, and Estimated Completion Week."
**Phase 3: The "Terraform Check" for Consistency**
Finally, I use a trick from our IaC world. I copy a key section (like the deliverables list) and ask:
>"Review the following list for consistency in verb tense, specificity, and measurable outcomes. Flag any items that are vague."
This catches things like "implement monitoring" vs. "configure CloudWatch dashboards for CPU, memory, and disk utilization" – the second is much better for an SOW.
The key is to never accept the first draft. Treat it as a scaffold you build upon with precise, iterative prompts. It saves me hours of staring at a blank page and lets me focus on the high-value negotiation and architectural specifics.
Has anyone else tried a similar structured approach for non-code documents? Would love to swap prompt templates!
~CloudOps
Infrastructure as code is the only way
That's a solid framework! I've used a similar approach for drafting monitoring sections in SOWs. Where I always double-check the AI's work is on the technical specifics - the "Deliverables" list.
For example, if it spits out "Implement comprehensive APM," I'll make it concrete:
- Instrumentation of 8 web servers with Datadog APM agents
- Setup of 5 custom dashboards for transaction latency and error rates
- Configuration of 3 critical business transaction alerts
The LLM gives you the bones, but you've gotta add the exact observability muscle. Makes the SOW way more valuable and sets clear expectations.
Dashboards or it didn't happen.
Good structured prompt. I've found this approach works well for data pipeline SOWs too, but you have to be even more precise with volume metrics. For a migration, "lift-and-shift of 2 databases" is vague. I'd amend the prompt to specify:
- Source database sizes (e.g., 500 GB PostgreSQL, 2 TB MySQL)
- Required hourly throughput (e.g., 50k events/sec from Kafka)
- Target SLAs for data freshness post-migration
That forces the draft to include tangible engineering constraints, which shapes the deliverables and timeline more accurately than generic server counts.
Yes, being specific on the volumes. That's the only way an SOW has any real teeth.
But listing those technical constraints in the prompt is still just a prompt. The real risk is the LLM generates a deliverable like "Migrate 2 TB MySQL database" without any of the acceptance criteria. You still have to manually insert the validation steps.
For a data pipeline, that means defining the verification process: pre and post row counts, checksum validation, and the specific monitoring dashboards you'll use to prove the SLA was met. Without that, you've just listed specs, not a deliverable.
If it's not a retention curve, I don't care.
That's a good point about volume metrics shaping the timeline. I've seen vague SOWs cause billing disputes later when the effort for a "2 TB migration" was underestimated. Do you find adding the source hardware specs, like the existing server's IOPS capacity, helps the draft estimate man-hours more realistically?
Yeah, specifying hardware specs in the prompt helps a ton. It makes the AI draft a more realistic timeline, not just a guess based on data size.
For example, adding "source: 5k IOPS, 1Gbit link" to the prompt steers it towards including extra time for throttled transfers. It once saved me from underbidding because the draft outlined a longer, staged migration.
How do you handle it when the source specs are unknown? I usually have the AI add a discovery phase as the first deliverable.
Absolutely, and this is where the LLM's draft must be treated as a structural scaffold, not a final deliverable. The acceptance criteria you mention - row counts, checksums - are contractual verification points. They belong in a separate, explicitly defined section of the SOW, often titled "Validation and Acceptance."
I prompt for this structure directly: "Include a 'Validation' subsection for each major deliverable, outlining the exact metrics, tools, and process for client sign-off." This forces the draft to contain placeholders for those criteria. You still populate them, but the framework reminds you not to omit them. Without that structural prompt, the output is just a feature list, not a binding document.
show me the SLA