Project Proposal

Write concise project proposals that help stakeholders decide whether to invest engineering resources. In agile, proposals are lightweight — enough to make an informed decision, not a 50-page waterfall spec.

When to Write a Proposal

Not every task needs a proposal. Use this skill when:

• Budget approval is needed (anything over a few days of work)
• Multiple stakeholders need to agree before starting
• Opportunity cost is significant (this means NOT doing something else)
• Risk is non-trivial (new technology, external dependencies, data migration)
• The idea needs defending — someone will ask "why should we do this?"

For small features that are already in the approved roadmap, skip this and go straight to feature-planning.

Workflow

Step 1: Define the Problem

First check that a proposal is what's wanted. When the budget or go-ahead is already settled and the user wants a technical choice (which broker, which database, which framework), say so: the approval is in hand, so no proposal is needed, and the choice is a costly-to-reverse architecture decision that belongs in an ADR via architecture-design. Then make the technical call as a plain technical answer, not in this skill's proposal format (business case, ROI, alternatives table, decision requested).

Before proposing a solution, clearly articulate the problem:

• Who has this problem? (Users, internal team, business)
• What is the impact of NOT solving it? (Revenue loss, churn, engineering time wasted, compliance risk)
• How do we know this is a real problem? (Data, user feedback, support tickets, competitive analysis)
• Is this urgent or important? Urgent means it gets worse over time. Important means it has high value when solved. Both means it's a priority.

If the user can't articulate the problem, help them clarify before proceeding. A solution without a clear problem is a feature request, not a project proposal.

Step 2: Propose the Solution

Describe what you intend to build, at a high level:

• Approach: What will be built and how (1-2 paragraphs, not a detailed design)
• Scope: What's included and what's explicitly excluded
• Alternatives considered: Why this approach over 2-3 alternatives (including "do nothing"). When a vendor product could deliver the capability, buying it is one of them — hand a deep comparison to build-vs-buy
• Dependencies: What does this project need that doesn't exist yet?

Step 3: Estimate Cost and Timeline

Provide order-of-magnitude estimates (not precise):

• Team size: How many engineers, designers, product people?
• Duration: In weeks or sprints (ranges are fine: "4-6 weeks")
• Infrastructure cost: New services, third-party tools, cloud resources
• Ongoing cost: Maintenance, monitoring, support after launch

Use the effort-estimation skill for detailed estimation methodology. At the proposal stage, rough ranges are appropriate.

Step 4: Assess Risks

For each significant risk, document:

Lead with the risk that belongs to what is being built — for a real-time feature, the infrastructure (connection scaling, delivery guarantees, reconnects); for a migration, data loss — before the generic categories:

• Technical: Unproven technology, complex integration, performance concerns
• Scope: Requirements likely to change, stakeholder alignment gaps
• Dependencies: External teams, third-party APIs, vendor timelines
• People: Key-person dependency, skill gaps, team availability
• Timeline: Hard deadlines, competing priorities, seasonal constraints

Step 5: Define Success Criteria

How will you know this project succeeded? Define measurable criteria:

• Outcome metrics: What business or user metric improves? (Conversion rate, response time, support tickets reduced)
• Output metrics: What gets delivered? (Feature shipped, migration completed, performance target hit)
• Timeline: When should we evaluate success? (30 days after launch, end of quarter)

Link to metrics-and-okrs skill for deeper metric design.

Step 6: Produce the Proposal

Output using the template at templates/proposal.md. Keep it to 1-2 pages. If it needs more, the scope is probably too large — consider splitting.

End with the questions the proposal can't answer without the user, asked directly next to the draft, not instead of it: the evidence of demand behind the problem (usage data, customer requests, churn), and — when a vendor could cover it — whether they lean build or buy.

Principles Applied

• KISS: Proposals should be 1-2 pages. If you can't explain the value concisely, the project scope is too broad.
• YAGNI: Propose the minimum viable project. Nice-to-haves go in a "future considerations" section, not in the scope.
• Data over opinions: Support the business case with numbers — user count, revenue impact, time savings, error rates.