Rationale and Reasoning
A project’s goals and priorities are described at its top level by a list of Milestones. The list of these milestones should serve as a guidepost to anyone who is interested in what the project is working on, what the deliverables are of that work, and how that work is going.
If you don't like "Milestone", call it whatever you want as long as it's in line with this description.
This document is an outline of how you should think about creating milestones for your project, and what information should be included in them such that the IFT Grant Process can be completed and everyone stays on the same page.
Projects work to produce things for people, and a milestone describes, plans, and tracks those things. To that end, the deliverables are the key components to reason around what a milestone is for your project. Who are you building for, what are you building for them, and why do they care? A small group of deliverables and the justified impact they have towards their targeted audience should be enough to help someone understand what a project is doing.
In effect, a given milestone is a declaration of:
- Here’s what we want to happen
- This is why this needs to happen
- Here’s how we’re going to make that happen
- This is what we need to do it
- Here’s how you can watch
- This is how confident we are that we can get it done (in time)
The scope of a given milestone is such that the total amount of work you plan for the year equates to ~4-5 individual milestones. For a small project, that’s focused and tight. For a large project, that’s cross-functional and broad. It is expected that larger projects have the appropriate project management resources to sub-divide their milestones in to sub-milestones, epics, and issues as appropriate.
We ask that the structure of the milestone is somewhat standardized across the IFT, as we have a lot of derivative and automation tasks to perform.
Here’s a list of the sections that need to be included in each milestone:
Milestone Title
A short name of the milestone that succinctly describes its aim and scope.
Estimated Delivery Date
A timeline in which the work is expected to be delivered
Description
More detail as to what you’re aiming to accomplish with this milestone and the justification for its inclusion to the project. This is the human readable encapsulation of the milestone. Someone reading it should be able to understand the general scope of the entire thing, with all other sections adding context and detail.
Resources Required
- roles and % application to it
- external services consumed (Vac/IFT)
- infrastructure
This information here, in combination with the IFT Finance team, should be enough to yield the required budget for the milestone. This allows for private financial information to stay appropriately separated while still allowing us to publish and broadcast the roadmaps (and their progress) to the broader communities.
Deliverables
What are the tangible items that are the result of this milestone’s work, and who is the targeted audience for those items?
It is important to note that we’ve included the intended audience here. Is this a research PoC to be delivered to the Engineering team? Is this a mainnet launch that we need wide community broadcasting on? Is this an SDK being delivered to another IFT project? The appropriate communication of the deliverable should be considered here.
Tracking Metrics
How we track progress on a given milestone is dependent upon what the goal of the milestone is and deliverables it aims to accomplish. As per Jarrad’s Strategy Document and mantra from previous talks, metrics around User Acquisition and Revenue Generation should be included wherever possibly appropriate. If it isn’t directly aimed at these two, its impact on how it facilitates it should be understood.
NOTE: The IFT Insights team will closely monitor all of these and provide dashboards to relevant stakeholders such that progress and status can be monitored and acted upon.
Work Breakdown
Since this is the highest level of “work package” that is considered throughout the org, a description of the way this is going to be broken up and managed should be itemized here. This section is a process of showing “this is explicitly how we plan to deliver this milestone.”
NOTE: It is recommended that the broken down work is structured similarly so it can be understood and tracked, e.g. Milestone -> Epics -> Issues by the IFT Insights team, with each layer more narrowed in scope and explicit in detail. Each project has a significant level of autonomy on how they deliver on the agreed upon milestones and the associated project management and organization that entails it.
Perceived Risks
Each milestone should include a section of what dependencies/assumptions/potential market changes there are that add risk to its completion. What factors come into play that can potentially affect the project delivery date, and how do each of them affect its delivery?