How To - Write Milestones Within Your Statement of Wor
Guide Overview
Submitting milestone evidence is a key part of ensuring transparency, accountability, and timely payment.
You will find links to the Milestone Acceptance Form Templates and Milestone Acceptance Form Examples at the bottom of this page.
What is Considered a Good Example?
Example
Milestone 1 – Development of Constitutional Committee candidates registration.
Delivering a secure, reliable, and user-friendly production-ready platform that allows candidates to successfully register and enables administrators to efficiently manage and verify applications in full support of the Constitutional Committee election.
Deliver registration functionalities for CC candidates, test them, and make them production ready to support the CC election.
Why is this a good example?
It is specific: The name clearly states the scope ("candidates registration") and its sequence in the project ("Milestone 1"), making it easy to understand and track.
It is outcome-based: It focuses on the creation of a tangible capability rather than a vague period of work.
It is measurable and objective: Success is defined by clear, testable actions like "candidates can successfully register" and objective qualities like "secure." These can be verified without personal opinion.
It is binary: The criteria establish a clear pass/fail state. The platform either meets these conditions or it doesn't, leaving no room for ambiguity about whether the milestone is complete.
They are tangible outputs: The deliverables are concrete results—a "production-ready" system with working "functionalities"—not just a list of ongoing tasks.
They are verifiable: A reviewer can see the delivered functionalities, check the test results, and confirm the system is ready, providing clear proof of completion.
What is Considered a Bad Example?
Example
Milestone 1 - Phase 2 Further Platform Development.
The platform's core features are mostly done and the UI is better. The system should be robust enough for some initial users to try out.
Work on the smart contracts.
Continue design of the user interface.
Investigate different integration options.
Why is this a bad example?
It's not specific: What does "Further Platform Development" include? This name is generic and provides no clear scope. Stakeholders have no idea what is actually being built.
It's not outcome-based: It describes a period of ongoing work ("Phase 2") rather than a specific outcome or achievement.
It's not measurable or objective: Words like "mostly done," "feels better," and "robust enough" are subjective and depend on opinion. What one person considers "mostly done," another might see as half-finished.
It's not binary: It cannot be answered with a simple "yes" or "no." This ambiguity leads to disputes over whether the milestone is actually complete.
They are tasks, not outputs: Phrases like "Work on," "Continue design," and "Investigate" describe ongoing activities, not finished, tangible items. It's impossible to confirm when "Work on" is actually complete.
They are not verifiable: There is no finished product to hand over. How do you deliver "Continue design"? A good deliverable would be "Finalized UI Mockups" or "Deployed Smart Contract V1 on Testnet."
Downloads and Resources
Need Templates or Supporting Documents?
Find proposal templates, guidance documents, and downloadable resources to support your submission.
Last updated