Sow Pws Builder

SOW/PWS Builder

Overview

This skill walks a program office (or analyst acting on their behalf) through structured scope decisions and assembles the answers into a properly formatted SOW or PWS. The core insight: the program office doesn't need to know FTE counts or cost estimates up front — they need to make scope decisions, and staffing falls out as a derived output.

Outputs (TWO SEPARATE ARTIFACTS — never combined):

1. A .docx SOW or PWS with standard federal sections — the contract file deliverable. This document contains NO staffing table, NO FTE counts, NO labor category counts, NO SOC codes, NO hours-per-year estimates, and NO IGCE-related content. FAR 37.102(d) requires the requirement to be described in terms of results, not hours or number of people performing the work. The one narrow exception is T&M/LH contracts, which get a Labor Category Ceiling Hours table in Section 5 per FAR 16.601(c)(2) — see Phase 2 Section 5 for details.

1. A staffing handoff table — an internal government workpaper presented in chat output only at the end of the skill run. This is the data handoff to the IGCE Builder skills (FFP, LH/T&M, CR). It is NEVER embedded in the SOW/PWS document. It is NEVER saved as a companion .docx or any other file. It exists solely as a markdown/code-block table in the conversation so the user can review it and the downstream IGCE Builder can consume it.

No external APIs required. This is a decision tree + document generation skill.

Regulatory basis: FAR 37.102(d) (describe work in terms of results, not hours or number of people), FAR 37.602 (performance-based acquisition), FAR 46.401 (quality assurance), FAR 7.105 (written acquisition plans — requirement description), FAR 16.601(c)(2) (T&M/LH ceiling price mechanism).

Workflow Selection

Workflow A: Full Build (Default)

User needs a SOW/PWS from scratch or from a rough concept. Execute all three phases. Triggers: "write a SOW," "build a PWS," "I need a work statement for..."

Workflow B: SOO Conversion

User has an existing SOO and needs it developed into a SOW/PWS. Start with Phase 0 (SOO intake), then Phases 1–3. Triggers: "convert this SOO to a SOW," "develop this SOO into a PWS," "we have a SOO and need a work statement."

Workflow C: Scope Reduction

User has an existing SOW/PWS or IGCE output that exceeds budget. Walk through scope decision tree to identify what to cut, then produce a revised document. Triggers: "this is too expensive, what can we cut," "reduce scope to fit budget," "need to descope."

Acquisition Strategy Intake

Before diving into the scope decision tree, collect three framing decisions that shape everything that follows. Ask these up front, in a single pass, before Block 1. These are the acquisition strategy context — they determine document type, pricing structure, and FAR Part applicability.

Intake Question 1: SOW or PWS?

| | SOW | PWS | |---|---|---| | Prescribes | Tasks and methods (how) | Outcomes and standards (what) | | Contractor flexibility | Low — government directs approach | High — contractor proposes approach | | Best for | Well-understood, repeatable work | Complex or innovative requirements | | QASP focus | Task completion | Performance metrics | | FAR preference | — | FAR 37.602 prefers PBA/PWS |

If the user is unsure, default to PWS — it's the FAR-preferred approach for services and gives the contractor room to propose efficient solutions. The decision tree is identical either way; only the output language changes.

Intake Question 2: Contract Type?

FFP | T&M | LH | CR | Hybrid (specify)

This is asked up front (not in Block 5) because contract type frames the rest of the scope decisions:

• FFP pairs naturally with PWS (outcomes + performance standards). Contractor owns labor mix risk. No labor info in the document body.
• T&M and LH require Labor Category Ceiling Hours in Section 5 per FAR 16.601(c)(2). The SOW/PWS must tell offerors what LCATs to propose rates against and the ceiling hours per period.
• CR (cost-reimbursement) pairs with either SOW or PWS. No labor info in the document body. Requires approved accounting system findings before award per FAR 16.301-3.
• Hybrid — identify which CLINs are which type; apply the rules per CLIN.

If the user says "unsure," recommend FFP for well-defined services, T&M for requirements where level of effort is unknown, and CR for R&D or high-uncertainty work. FAR Part 16 analysis is the contracting officer's call — this skill accepts the user's decision; it does not advise on contract type selection.

Intake Question 3: Commercial or Non-Commercial?

Commercial service (FAR Part 12) | Non-commercial (FAR Part 15) | Unsure — flag for Contracting Officer

• Commercial service = routinely sold to the general public in the course of normal business operations, per FAR 2.101 commercial product/service definition. Help desk services, facility maintenance, COTS software support, training, staff augmentation for standard skills are typically commercial.
• Non-commercial = government-unique work such as classified, research, weapon systems development, or work performed using specialized government processes not available in the commercial marketplace.
• When commercial, FAR Part 12 governs. FAR 52.212-4 terms apply in Section I of the solicitation; full Section I/L buildout is not required. Contract type is typically FFP per FAR 12.207. Performance-based description is preferred per FAR 12.102(g). CLIN structure (emitted in the Phase 3 chat-only handoff, not the PWS body) should accommodate commercial item pricing.
• When non-commercial, FAR Part 15 governs. Full Section I/L clause buildout applies. All contract types available.
• If the user is unsure, note "Commercial item determination pending — flag for Contracting Officer" in Section 14 Constraints and Assumptions and proceed with Phase 1.

Why these three questions come first

The issue a requirement writer faces: the same scope decisions produce different document language, different clause references, and different FAR Part applicability depending on these three framing choices. Collecting them up front means Phase 1 can frame its questions accordingly (e.g., for a commercial FFP PWS, skip Phase 1 questions about Government-unique processes; for a T&M SOW, ask more detail about labor categories and ceilings). It also means the generated document in Phase 2 can reference the correct FAR sections and clauses without a retrofit.

Phase 0: SOO Intake (Workflow B Only)

When the user provides an existing SOO:

1. Read and extract. Parse the SOO for: background, objectives, constraints, performance location, period of performance, known systems, volume data, key personnel, security requirements, and any appendix data.

1. Gap identification. Flag what the SOO provides vs. what a SOW/PWS needs:

• ✅ Typically present in SOO: background, high-level objectives, constraints, PoP, location
• ❌ Typically missing from SOO: task decomposition, staffing, deliverables with acceptance criteria, CLIN structure, QASP metrics, reporting cadence, transition details
• ⚠️ If the SOO's scope implies a standard it doesn't explicitly state (availability for high-volume systems, security for PII/FISMA systems, continuity for mission-critical systems), add the implied objective and flag it in Section 14 as a derived objective.

1. Decision bridge. Present the gaps as the questions Phase 1 will answer. Frame it as: "The SOO tells us what the agency wants to achieve. Phase 1 asks the questions that turn objectives into executable requirements."

1. Carry forward. Pre-populate Phase 1 answers with anything the SOO already decided (location, PoP, known constraints). Don't re-ask settled questions.

Phase 1: Scope Decision Tree

Ask questions in this sequence. Each decision narrows scope and implies staffing. Present as structured choices, not open-ended questions. Collect in a single pass where possible.

Phase 1 execution: On platforms that expose a structured multi-choice prompt tool (claude.ai web chat provides AskUserQuestion), use it for Acquisition Strategy Intake and Blocks 1-6. Batch 3-4 related questions per prompt block. Reserve prose for genuinely open-ended answers (ticket volume, system names, incumbent details). Every multi-choice question must include an "Other" / "Something else" free-text escape.

Anti-redundancy: Before asking any framing or scope question, check whether the user's initial prompt already answers it. Do not re-ask explicit answers; confirm silently and proceed.

Block 1: Mission and Service Model

1. What is the core service? (Provide options based on context, or ask open-ended if starting from scratch)
2. Service delivery model: Government FTEs with contractor augmentation | Fully contracted service | Hybrid (specify which functions are FTE vs. contractor)
3. Coverage model: Business hours (M-F 8-5) | Extended hours (specify) | 24/7/365 | Seasonal/surge
4. Geographic scope: Single site | Multi-site (how many?) | Virtual/remote | Hybrid

Block 2: Technical Scope

1. Build vs. Buy: Custom development | COTS/SaaS configuration | Hybrid (custom integrations on COTS platform)
2. Systems in scope: List all systems the contractor will build, configure, integrate with, or maintain. For each: new build vs. existing system.
3. Integration complexity: Standalone | Integrates with 1-3 systems | Integrates with 4+ systems | Enterprise-wide integration
4. Data migration: No legacy data | Migrate from 1-2 sources | Migrate from 3+ sources | Complex multi-system consolidation
5. AI/automation: None | Basic automation (IVR, rules-based routing) | AI-assisted (NLP, ML classification) | Advanced AI (chatbots, predictive analytics)

Block 3: Scale and Volume

1. Transaction/contact volume: Provide numbers if known, or characterize as low/medium/high
2. User population: Internal users (how many?) | External/public-facing | Both
3. Concurrent user requirements: If applicable
4. Growth expectations: Stable | Moderate growth (10-25%/yr) | High growth (>25%/yr) | Unknown

Block 4: Organizational Scope

1. How many organizational units? (offices, centers, divisions served)
2. Phasing: All at once | Phased rollout (how many phases?) | Pilot then expand
3. Stakeholder complexity: Single program office | Multiple offices, single agency | Cross-agency

Block 5: Contract Structure

Contract type is already captured in the Acquisition Strategy Intake above; do not re-ask it here.

1. Period of performance: Base year + option years (how many?)
2. Base year scope: Full performance from day 1 | Ramp-up/transition-in period (how long?) | Design/development only, production in options
3. CLIN structure preference (for Section B handoff, NOT the PWS body): By period (CLINs = base year, OY1, OY2...) | By function (CLINs = development, operations, maintenance, training) | By deliverable | Unsure (skill will recommend). This preference is emitted as a chat-only CLIN Handoff Table in Phase 3 for the CO to paste into Section B of the solicitation. It does NOT go into the SOW/PWS document body.
4. Transition requirements: Transition-in from incumbent? | Transition-out plan required? | Both

Block 6: Quality and Oversight

1. Acceptable quality level (AQL): For key performance metrics — e.g., 95% first-call resolution, 99.95% uptime, 50 FTEs, >$75M, or span >3 distinct technical domains, flag that this may need to be broken into multiple contracts. Suggest logical break points (e.g., development vs. operations, platform vs. contact center staffing).

User wants to skip Phase 1: Don't let them. The decision tree is the value. If they say "just write the SOW from this SOO," explain: "The SOO describes objectives, but a SOW requires decisions the SOO intentionally leaves open — like staffing model, build vs. buy, phasing, and CLIN structure. These take about 10 minutes to walk through, and they're what make the SOW defensible."

Budget-constrained scope reduction (Workflow C): When reducing scope to fit budget, work backwards: identify the highest-cost labor categories from the IGCE, map them to tasks/objectives, and present trade-offs: "Removing 24/7 coverage saves ~$X by eliminating night-shift agents, but means no live response outside business hours. Replacing custom AI with COTS chatbot saves ~$Y in developer FTEs but limits NLP accuracy." Let the user choose which scope reductions are acceptable, then regenerate affected SOW/PWS sections.

What This Skill Does NOT Cover

• Pricing or cost estimates — use IGCE Builder skills (FFP, LH/T&M, CR)
• Source selection criteria — separate document, though CLIN structure informs it
• J&A or sole source justification — separate document
• Full QASP — this skill includes a QASP summary table; a detailed QASP with surveillance schedules is a separate deliverable
• Clause selection (Section I/L) — requires contracting officer determination per FAR Parts 12, 15, 16, 52
• Contract type determination — this skill accepts the user's contract type decision; it does not advise on which type to select (that's a FAR 16 analysis)

---

MIT © James Jenrette / 1102tools. Source: github.com/1102tools/federal-contracting-skills

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: 1102tools
• Source: 1102tools/federal-contracting-skills
• License: MIT
• Homepage: https://1102tools.com

Install and usage instructions live in the source repository linked above.