Intro
@tigress , @june , and @puncar-dev would like to present our suggestions for the standardization of our project/task management process within GitcoinDAO. We genuinely believe that flexibility within workstreams and initiatives is essential, but we should all speak the same language. Here weâll focus only on core principles and keep space for specific workstream needs.
This initial proposal is a request for comments â we would appreciate your view on this so we can prepare a final recommendation for the DAO (CSDO).
Problem statement
The Action Items DB (Notion Database (Link)) is the centerpiece of all our project and/or task management activities at GitcoinDAO.
This database should contain all the tasks and projects we are executing on. For this reason, this database must be in good shape and well maintained in terms of structure and content. Currently, every workstream uses it slightly differently, increasing the databaseâs complexity and making it harder to set up individual instances.
Therefore, we need to find an alignment between workstreams to use the database similarly and ensure consistency in the naming (the same word should mean the same across the workstreams), but keep the flexibility to ensure that the database works well for each workstream.
From the DAOops perspective, all initiatives need to be able to record their tasks and projects on their board and then report on successful project completion on weekly DAOops calls. But MMM might need something slightly different; thus, we must find a flexible solution for everyone.
Project Management Structure
Through analyzing the project management systems at DAOops, FDD, and MMM, we have concluded that there are two general workflows: the execution workflow, and the reporting workflow. The execution workflow refers to actions for completing work, and the reporting workflow refers to how the completed work relates to achieving objectives and key results.
We suggest using the Action Items DB and the Initiatives DB (Notion Database (Link)) to manage these two workflows. Below is the overall structure:
The Action Items DB will contain tasks, projects, and key results. The Initiatives DB will contain initiatives and their related objectives, and are also directly linked to projects and key results from the Action Items DB.
Itâs up to each workstream to decide how many steps they want to have in their project management process, and if they want to introduce a new tag or subcategory. However, it is vital to keep alignment on the basic structure.
Action Items DB
Action Item
An Action Item is the centerpiece of the Action Items DB. This field can be used to represent tasks, projects, or both â this distinction will vary across workstreams.
If used to represent a project, the field can still be used to incorporate tasks as another level of granularity. Using this field for both projects and tasks is possible by making use of filters and establishing clear relations between tasks and projects.
Or, the Action Item field can be used mainly as tasks, and bundled together into projects.
Alternatively Action Items can also directly relate to an Initiative. There is a lot of flexibility for WorkStreams but its important to keep the same flow:
- Key Results - represents what Initiatives promised to accomplish for the budget they have been given, usually a seasonal initiative
- Project - break down of key results to a smaller initiatives that takes couple of weeks to complete
- Task - smallest piece of work that doesnt take more than couple days to complete
Templates
The templates we have created will represent the various ways that Action Items can be used in the Action Items DB. Currently, there are three templates that can be used when creating an Action Item:
- Project Template
A project is an Action Item within the Action Items DB that represents a multiple-week effort to be achieved. A project can contribute to successfully completing a Key Result of an Initiative. Additionally, some projects may also stand on their own (e.g. research projects), thus enabling autonomy within workstreams.
Projects may contain multiple tasks; therefore, the project template enables seamless task creation from within it.
- Task Template
A Task functions like a Project, but is used as an additional level of granularity. A Task can roll up and relate to a separate, larger Action Item. This can be done by marking Tasks as dependencies on a Project or Key Result.
A task can be created from a projectâs Notion page or separately in the Action Items DB and then tagged to a project.
- Key Results Template
A Key Result is the third type besides Tasks and Projects for which the Action Items DB can be used. The set of Key Results represents what Initiatives promised to accomplish for the budget they have been given and always relates to an objective. Itâs important to keep that in mind when executing on projects or tasks. Majority projects should contribute partially or fully to accomplishing those key results.
All initiative leads should create the key results at the beginning of the season and then they can track all projects and tasks there on top of there.
Initiatives DB
Initiatives
An Initiative is a structure in the Initiatives DB. It represents a grouping element to gather a group of people (=squad or team) around a specific objective and set of key results. An initiative has a âlead personâ which is the Initiative Owner, and others are contributors. Large initiatives are executed as a set of projects to achieve key results. Smaller initiatives might not use projects to bundle tasks and instead directly execute tasks to achieve the key results.
Below, you can see an example of an initiative wide view divided by projects.
Objective
An objective is a precise sentence describing what we intend to achieve by the end of the season for a given Initiative(s), and the overarching goal for an initiative. To realize and deliver option the objective a set of key results is defined.
Gitcoin Essential Intent (EI)
The Gitcoin EI is situated at DAO level and represents long term â30 yearâ objectives. The EI outlineswhat we are all trying to accomplish together as a DAO, and all our activities should directly or indirectly contribute to that.
Recommendation for project & task workflow
Every project or task can be in various stages, and to align on naming conventions, June and the MMM team have prepared this great workflow. FDD also uses this workflow.
It is highly recommended to use these same statuses when dealing with projects and tasks, even though you might not use all of them. Creating additional statuses for a single initiative or project can create confusion in the DAO and add up to increase complexity of the Notion databases, which is to be refrained from!
Happy Path
Unhappy Path
Status | Description |
---|---|
Future | Backlog for all projects or tasks related to the initiative(s) |
Next up | Prioritized projects/tasks to be started within the next two weeks |
In progress | Projects/Tasks that are actively being worked on |
In review | Projects/Tasks being reviewed (optional, only if project requires review) |
Blocked | Projects/Tasks that are currently blocked |
On hold | Deprioritized Projects/Tasks before they get back to âfutureâ or dropped to âwonât doâ |
Done | Completed Projects/Tasks (woo!) |
Wonât do | Dropped Projects/Tasks |
We would leave this proposal up whole next week for discussion and then propose a final version in about 2 weeks from now to CSDO. If ratified we would like to work with workstreams during October to incorporate those standards.
Please let us know if there is anything unclear from this proposal or if you would suggest any modifications.