Govrn Project Planning Process

--- tags: library --- # Govrn Project Planning Process ###### tags: `library` [TOC] **This document's goal is outlining the Govrn Project and Operations Methadology. Inspired by [Do-ist](https://blog.doist.com/doist-objectives)** ## Goal While we all have expertise, we're remote. So, we want to eliminate decision dependencies from people that might not be working at the same time. A strong process enables autonomy, empowers decisions, and leverages unique strengths for running projects at Govrn. Additionally, different types of projects require different types of workflows / processes. Trying to force every project or team to use the same process reduces any nuance or specifics a project might require. We want to push teams toward an umbrella method; where people are able to make decisions that are best for themself and the project, through time. The team decides, together. ***Note on our async/remote culture:** we believe top down directives are the biggest potential for mis-alignment of processes. While our goal is too reduce meetings to enable deep work as much as possible, we don't want to overcorrect to the hinderance of the team. Those doing the work for the project are in best position to determine their process. This umbrella is designed for each team to evaluate what needs to be done for the project and create an flexible process accordingly. That might mean the project starts with daily check ins or 3 days of multi-hour whiteboarding/brainstorming sessions. That could also mean no meetings are needed because everyone is on the same page async.* ## Principles: 1. Everything is a project. Product features are projects. Growth intiatives/experiments are a project. Interview processes for a role is a project. Everything we do is a project or a task of a bigger project. ([link to how Ideas become Projects](#How-does-an-idea-become-a-project)) 2. Projects require four components: - **Goal:** What is the goal of the project? What problem is it trying to solve? - **Scope:** What types of input work should be considered? What functional areas are required? - **Completion Criteria:** What is the intended output of the project? What will we point to at the end to say "complete"? *Start here and work backwards to determine the proper timeline and scope* - **Timeline:** What is the timeline for the project and the different phases? 3. All projects can be thought of as unique, but here are common ones we can use as templates: - **[Agile] Projects:** - Starts with a general goal and requirements. Gives lots of freedom to team. Generally long projects (multiple cycles) - These will have v1 or v2 naming conventions. - Examples: Building a DAO portal or DAO level functionality. - **[Bundle] Projects:** - Packages together smaller improvements or initiatives into a bigger project and timeboxes them for urgency. - A very defined set of requirements - Examples: v1 Improvements, Onboarding new cohort of similar DAOs. - **[Exploratory] Projects:** - Big, open ended projects where solution is unclear. - Goal is exploration and discovery rather than implementation - Time box them towards outcomes, even as simple as documentation. - Examples: Exploring the contribution graph v0 - **[Internal] Projects:** - Projects that happen within a single team, often by just one person. - Included to increase transparency and accountability and more accurate resource planning - Examples: Context Refactoring, Fundraising 4. Each project has **a lead**. This doesn't mean they make all the decisions, but they - Schedule any required meetings or touchpoints (async) - Makes sure the project is on schedule, on pause, or at risk - Manages the project board - Checks in and unblocks the team members. 5. Since we default to two week cycles, projects should have a maximum timeline of 6 weeks. If a project is projected to be longer then 6 weeks, set a 6 week milestone and change the type. 6. The target number of projects for each person to be on is 3. **Everyone is self responsible to make sure they are not being assigned to too many projects or if they are over capacity.** It's not currently realistic for one person to track everyone else's commitments, so you need to be accountable to yourself to speak up when you're overextended. - If you find midway through a cycle that you have free time, this is OK. If this happens, spend time on personal projects, reading through the project updates and boards of other projects to offer help or idea if you can, and explore the moonshot ideas you have in your personal backlog. ## Cadence Moving projects into the Govrn-app-stack (product) usually follows this pattern: 1. **Wednesday Project Planning:** Every week, we have a Project Planning Meeting on Wednesday. There are two types of Project Planning Meetings: Voting (1) and Round Table(2). While both calls start with 10 minutes of team leads writing async project updates, they have very different purposes and goals. - Voting: Voting calls is where we go through the backlog, explain and explore ideas as a team, and do rough prioritization of projects we want to take on next. These meetings occur the **Wednesday before the next sprint cycle starts**. - Round Table: Round table is where we deep dive into the projects that were voted on to be moved to "planned" during the previous week. This gives the project team to get alignment on the more flushed out project details and get feedback from the rest of the team. These meetings occur the **Wednesday in the middle of the sprint cycle**. 2. **Project Assembly:** For each project, as we decide if we want to do it, we assemble teams around the project. The first priority should be understanding the required resources and ensuring we have the essential people on the project. This team should be the minimum amount of people needed to deliver the project or complete it's phases. Any person can raise their hand to be on any project. (**Note:** What about a situation where someone wants to be consulted or informed, but not accountable? If you want to be consulted, you should also join the project as a member and take on additional responosibilities (no free opinions), but if you're just interested in being informed, subscribe yourself to the project and use any free time you have to read make an effort to personally read the project updates/cards and add your comments.) 3. **Kick Off Meeting:** Once projects and teams are assembled, each team can operate autonomously. Each team can decide they're own workflow, if they want standups, meeting cadence (if they even want to meet), and generally how they want too communicate. We recommend having at least 1 kick off meeting at the beginning of the project to get everyone on the same page. THis helps determine which phase the project falls under, it's urgency/priorty, and how it balances against the teams time/things in motion. Then up to the team if they want to keep a regular meeting time as well or operate as async as possible. During the meeting, the team lead should create (if not already created, review if already created) a v0 of the project plan. The project plan includes: - **Goal:** What is the goal of the project? What company objective does this algn with? - **Scope:** What is the expected output of the project? - **Timeline:** What are the timeline of any phases of the project? - While total project timelines should be no longer then 6 weeks, this section refers to the inter project timeline (schedule out design time, build time, etc) - [Here is a link to the Project Plan Template](/NKq3HWAPSfK_gxo26XB7YA) Additionally, we recommend that the team lead uses this time to create an initial set of tickets in the project linear board and assign them to team members with some timeline associated. [Workflow](https://hackmd.io/@Govrn/SJ-Cm5Bnq/%2Fok5Jn9ThT_qYUwXaIg4GKg) 5. **Project Channel:** In addition to the kick off meeting, each team lead is responsible for creating a dedicated project channel in the Govrn Discord. The first message of the channel should contain: 1. A link to the project plan (Goal, Scope, Completion Criteria, Timeline) 2. A link to the Linear Project Board, and 3. Any additional notes or docs created during the kick off call. This message should be pinned to the channel so all can reference it. 4. **Project Grooming:** You need to make sure the project stays clear. Throughout the project, both the team lead and members should responsibily update tickets and add new ones. Pick a cadence upfront. ## How does an idea become a project? Whenever someone has a new idea for a project, that should go into the Backlog and the submitter should fill out the `Idea` section of the [Project Plan Template](/NKq3HWAPSfK_gxo26XB7YA). - This should take no more then 15 minutes to fill out. - We want it to be easy to document the idea, providing the minimum amount of information for presentation. - More context during the project planning meeting from the submittooor. ::: success For a deep dive on how this process affects all team stakeholders and the routes it can go, [check out the product lifecycle doc](https://hackmd.io/TZ39SHnoTMWmW-hOsYbPEw#). ::: During Round Table Project Planning Meetings, each person who submits an idea will get a turn to explain/pitch the idea to the team. **Note:** If the project is an internal project, there is no deliberation needed. That is an internal team decision and this process should be seen as an announcment/information post. Assuming the project being pitched is a product or cross team project, the project will be pitched, and the team will vote on their top projects to be done. At the end of the meeting, we will total up the votes and the projects with the most votes will be queued up for exection. ## What about bugs? - We do QA on Mondays and Fridays. Staging and new features monday and production happy hour on Friday. - If we do find a bug async, the bug needs to be documented via Bird Eats Bug or Loom video, and added to the Protocol Board with the tag `Bug`. Protocol team will attach priority and change priority once assessed. Examples: - Urgent = This must be fixed ASAP. The app is not working or it must be merged as soon as we can. - High = This should be fixed within a week. This has a negative user experience but the app still works - Med = This should be fixed in two weeks. It's a hinderance but not end of the world. - Low = This is an afterthought, would be good to fix. Once you create the task, tag Tim and Keating in the issue. The two of them will work to figure out who to assign the bug to, if it needs to be fixed as a one off in the current cycle, if there are enough similar bugs to roll them into a bundle project next cycle, or enough that have the same root cause that a bigger platform level upgrade project is warranted. Balancing bug fixes against project being delivered on time should be done on a case by case basis by Tim and Keating. :::spoiler Living questions ## Open Questions/Thoughts + Decisions - Do we want to keep 2 week cycles or should we do 4 week cycles with project planning meetings every other week? - If we did do 4 week cycles, would say maybe keep sprint planning meetings by teams every other week and let projects come up with their own meeting cadence - **Current Decision:** Keep Cycles on 2 Weeks - Should we include how an idea becomes a projects, or rather, how a one pager becomes a project. High level this is what i'm thinking: - Idea = A Creative/Fun way of describing the idea (i.e. a meme). This is what needs to be done to add identity to something in a backlog. - Historically, this would be [the one pager. ](https://hackmd.io/@Govrn/SJ-Cm5Bnq/https%3A%2F%2Fhackmd.io%2F%40Govrn%2FB1fCcWu09%2F). - Now you have two tools that feed into each other. One page => Project plan. - Spec = The Goal, Scope, and Timeline. This is created by the team and only done once we choose to move a project forward - The Bible = A living notes section that includes all discussions, notes, decisions, ideas, and considerations that went into the project. - **Current Decision:** Added a section on this. - Is it better to have projects have dedicated threads within a team or a dedicated channel? - **Current Decision:** Dedicated Channels - Should we use Wednesday Meeting times for general project updates as well or keep them product/cross team project focused? - **Current Decision:** Moving general team updates to Monday All Hands and keeping these calls dedicated on product/cross team updates. ## Implementation Details: - [x] Find a way to tag projects with the type of project it is. - Add [type] of project to name (lead will update as it goes) - [x] Label our project planning meetings with appropriate title - [x] Create Discord channels for current projects - [ ] ~~Airtable integration for mvp on scoring projects~~ - [ ] Auto archive and creating channels > this is the forums thing [name=tim] - [ ] Better interface to see projects with more metadata :::