# Project management best practices

We’ve built Neo.Tax to handle your data no matter how messy it is.

We’ve built Neo.Tax to handle your data no matter how messy it is. Our system can work even better by following a few simple practices.

This guide can help you improve ticket management practices to produce more accurate projects and time allocations in Neo.Tax.

**The three top tips:**

1. **Epic/Project names should describe the actual goal**

   1. "Banking - New 1099 Filing Features" not "Banking Work"
1. **Ticket titles should explain what you're building** 

   "Move MongoAuthProcess into driver source tree to increase stability" not "Auth fixes"
1. **Always move tickets to "In Progress" when you start work** 

   1. Skipping this step makes your team look less productive than they are and breaks time tracking

For more specific tips, check out the relevant section below.

---

### 1. Team/Project Organization

#### Core Principles

- **Use Projects (JIRA) / Teams (Linear)** to organize work by team boundaries
- **Rationale**: Clean team separation leads to better project outcomes and clearer ownership
- **Scale appropriately**: Companies with 20+ engineers should maintain multiple projects/teams that grow with organizational size
- **Align with business structure**: For R&D teams, map projects to actual business products or product groups when possible

---

### 2. Epic/Project Naming & Structure

#### Structure and Naming

- **Avoid cross-team epics/projects** - keep ownership boundaries clear
- **Always create child tickets** for epics/projects - avoid empty containers
- **Use descriptive, goal-oriented names** that clearly communicate the feature or objective

  - Separate and identify Maintenance/Ops work from New Feature work

#### Naming Convention Examples

**Excellent Examples** ✅

- `[CloudHosting] ABC 3.2 Improve Abstract Class Base Design`
- `Make New ECS Services Easy to Bootstrap`
- `TaxWorkflows: Automated 1099 Filing Feature `
- `1099 Filing (Maintenance/Bugs)`
- `OED App: New Feature Development`

**Acceptable Examples** ⚠️

- `ABC 3.2 Improve Abstract Class Base Design`
- `OED Improvements`
- `1099 Filing Implementation`

**Poor Examples** ❌

- `ABC 3.2`
- `Cycle 5'25`
- `General Improvements`

#### Best Practices

- **Create focused epics** rather than maintaining large, multi-quarter projects
- **Separate work types** in naming (e.g., "Maintenance," "New Features," "Bug Fixes")
- **Reference higher-level products** in epic/project names when applicable
- **Minimize work outside of organized projects**

---

### 3. Create Tickets for Senior-Level Work

Create tickets for more senior engineering activities such as:

- Technical investigations and research
- Proof of concepts and prototypes
- Architecture design and documentation
- Other strategic work that might typically go untracked

These activities often don’t have a ticket, leading to senior engineers work being undercounted.

---

### 4. Ticket Titles

#### Requirements

Titles must clearly describe the specific goal and deliverable of the work.

#### Title Examples

**Excellent Titles** ✅

- `Move MongoAuthProcess into driver source tree to increase stability`
- `Support parsing $uuid as extended JSON representation for subtype 4 binary`
- `Create sections in Draftcard module to support performance optimization`

**Acceptable Titles** ⚠️

- `Update MongoAuthProcess for stability`
- `Support parsing $uuid extended JSON`
- `Create performance sections in Draftcard module`

**Poor Titles** ❌

- `Auth fixes`
- `Parse UUID`
- `Draftcard sections`

---

### 5. Ticket Description Guidelines

#### Content Standards

- **Provide 1-2 detailed sentences** explaining what's being built/solved and key technical elements
- **Include context and rationale** for the work
- **Acceptable variation** in format, but avoid empty or minimal descriptions

#### Description Examples

**Strong Descriptions** ✅

> The external MongoAuthProcess library has caused production instability due to version mismatches and separate release cycles from the main driver. This ticket involves refactoring the authentication process code to be included directly in the driver codebase, reducing the attack surface and improving reliability.

> Create a complete vendor API evaluation document that assesses each candidate's REST API capabilities, including endpoint coverage, request/response formats, SDK availability, and documentation quality. This evaluation will serve as the primary decision-making artifact for the procurement team and should include scoring matrices and implementation effort estimates.

**Inadequate Descriptions** ❌

- Empty/null descriptions
- `Move auth thing`
- `The authentication isn't working well so we need to fix it by moving some stuff around`
- Overly technical jargon without context: `Migrate AUTH-PROC-7734 from EXT-DEP-991 to DRIVER-CORE-v4.8 following patterns in RFC-AUTH-2023`

---

### 6. Ticket Lifecycle Management

#### Status Updates

- **Always update to "In Progress"** when beginning work
- **Avoid direct "To Do" → "Done" transitions** as this reduces time tracking accuracy
- **Create new tickets** for additional work rather than reopening closed tickets
- **Err on the side of creating more tickets** for better granularity and tracking

---

### 7. Ticket Assignment Standards

#### Assignment Requirements

- **Assign every ticket to a specific person** - unassigned work cannot be properly attributed
- **Assign to the actual worker** - avoid assigning all tickets to managers when others perform the work
- **Avoid ticket rotation** between multiple assignees - instead, split work into separate tickets for each contributor