The Productive Playbook

A Guidebook for How OWL Makes Work Visible

Version: 1.0 Owner: Director of Finance & Ops (DFO) – with input from all Directors Audience: All OWL staff, contractors, and fellows who touch client work, internal projects, or grants Last updated: 2026-01-21

0. How to Use This Playbook

This Playbook is the one-stop, plain-language guide for how we use Productive at OWL. It is set up in the following manner:

• The main body explains the essential why and what: shared expectations, use boundaries, and daily habits that drive consistency and effectiveness.

• The appendices hold the how-to details: step-by-step SOPs, examples, and tutorials.

This Playbook is meant to be a short, concrete, easy-to-use reference for how we manage tasks, time, and projects. If it ever starts to feel too long, confusing, or unnecessary, we fix the Playbook, with crowdsourced ideas and real use cases. What we don’t do is ignore it and create a patchwork of unofficial approaches to “managing” OWL’s work. We simply can’t afford that.

When in doubt: If work matters for our mission, our money, or our commitments, it should be visible and trackable in Productive. Full stop.

Note that OWL contractors and Fellows should follow the same core Productive habits as OWL staff, per what is articulated in the scope of their ICA (even if they do not have a Productive account). The PM for the contractor in question will provide a brief overview of those requirements as part of their onboarding, pointing to the specific parts of this Playbook that are applicable to their work.

1. Why We Use Productive

1.1 Productive = OWL’s Work Ledger

Productive is the tool we use to see:

• What we’ve promised to do (projects, scopes, contracts).

• What we’re actually doing (tasks, time, progress).

• How that work connects to our money and impact (budgets, invoices, CRM).

When we use it with a high degree of operating discipline, Productive lets us protect our runway, keep promises to partners, and make routine, data-informed decisions as an agile, mission-driven team. In one sentence: if it isn’t in Productive, we can’t reliably see it, fund it, or staff it.

Why this matters for OWL

OWL is a small, mission-driven nonprofit that takes on work that is anything but simple: multi-partner projects, long-term culture shifts, and highly customized support for schools that are often under-resourced and over-stressed. As such, we can’t afford hidden work, fuzzy budgets, guesswork about capacity, or missed commitments (internal or external).

Used as intended, Productive gives us a single, shared view of:

• Whether our core initiatives (from multi-year, grant-funded projects to individual fee-for-service contracts) are on track and within budget.

• Whether our contracts and grant commitments are aligned with our financial health guardrails.

• Whether workloads are sustainable across a distributed team.

This only happens, however, when we use Productive in a way that aligns with OWL’s culture and working ethos:

• Distributed leadership: Instead of supervisors who simply direct activities, everyone on the OWL team must be able to see the work and act on it. Productive is where any team member can see the same reality and take ownership in service of our mission and their specific role and responsibilities.

• Open and transparent: We share information by default. Productive is the open window into what we’re doing, what it costs, and where we’re headed.

• Nimble and adaptive: Because the nature of OWL’s work depends on adaptive change, we must be able to quickly adjust scopes, timelines, and priorities while still delivering the quality outcomes we are known for. Productive holds the current story of our work so we can adapt without chaos.

In short, Productive is not just another piece of software! It is the platform that enables a living mission by aligning our projects, our time, our resources, and our financial health.

1.2 Guiding Principles

We use Productive in a way that matches how OWL works: distributed, open, and disciplined. The following are the core principles that sit behind every specific rule in this Playbook:

• Make work visible. Important work should never live only in someone’s head or notebook; if it matters to our mission, our money, or a commitment we’ve made, it shows up in Productive in some form.

• Keep one story of the work. Productive is the source of truth for projects, tasks, time, and budgets. If Productive says one thing and a side spreadsheet, note, or memory says another, we fix the mismatch instead of running parallel systems.

• Keep our tracking right-sized, not burdensome. Direct project and grant work is tightly linked to tasks and budgets; org-wide and micro work is captured through lighter “container” tasks. The goal is clarity and good decisions, not timesheet perfection.

• Model shared ownership, not top-down control: Because we lead through a distributed model, we expect everyone keeps their own slice of Productive accurate and current so the whole team can steer together.

• Foundational integrity & compliance: We respect funder rules, contract scopes, and our own financial guardrails. That means coding time and expenses correctly, keeping overhead separate from restricted funds, and using Productive to surface risks early rather than hiding them.

• Agility & adaptability: OWL’s work is highly customized and constantly evolving, so we aim for consistent habits, not rigid scripts. When scope, timelines, funding, or capacity change, we adjust the work and immediately update Productive so the system always matches reality.

Following these principles ensures Productive is neither a bureaucratic chore or a chaotic wish list, but remains what we need it to be: a clear, shared picture of the real work OWL is doing.

Responsibility is also shared and non-negotiable:

• Everyone who does OWL work keeps their own tasks and time entries honest, accurate, and current. If you did meaningful work, it shows up in Productive.

• Program Managers own project setup and board health for their scopes and are accountable for partnering with the DFO to keep budgets correct, visible, and in-bounds.

• The DFO designs and stewards the financial patterns in Productive (budgets, grant setups, reporting views) and leads training and quality checks so the numbers can always be trusted.

• Directors model excellent Productive habits, use views and reports to make decisions about priorities and capacity, and push for improvements when the system isn’t best serving the organization’s mission-driven work.

1.3 What Productive Is and Is Not

Productive only works if we use it for the right things.

Productive is:

• The single source of truth for OWL projects, tasks, time, and budgets.

• The shared place we look when we ask, “What are we working on?” and “How are we doing?”

• The system of record for commitments that matter to our mission, money, partners, and team.

What this specifically means in practice:

• Projects and scopes for client and grant work, plus major internal initiatives.

• Tasks that represent real work: things with owners, due dates, budgets (when applicable), and clear outcomes.

• Time entries tied to the right project and/or budget.

• Budgets and financial views that let us see health at the project, initiative, and portfolio level.

• CRM entries for active and emerging work (contracts, grants, donors) that have moved beyond the idea phase into significant work for one or more members of the OWL team.

In other words, if someone asks, “What’s on our plate?” or “Can we afford to do this?”, Productive is where we look first.

Productive is not:

• A file storage system. We use Google Drive for working documents and shared files, and GitBook/GitHub for top-level canonical policies, SOPs, and open resources.

• A private journal or idea dump. Early-stage thoughts, brainstorming, and notes go in your personal notes, a shared doc, or a meeting agenda. Tasks only appear once the work becomes concrete.

• A place for sensitive HR/legal details or confidential client notes. Tasks can reference that something needs to happen (e.g. “Follow up on HR matter – see secure file”), but details live in appropriate, access-controlled systems.

• A replacement for conversation. We still use Slack and live meetings to explore ideas, make decisions, and support each other. Productive captures the resulting work, not the whole conversation.

1.4 What Goes Where: Practical Examples

Type of thing	Productive	Slack	Google Drive	GitBook / GitHub
New client scope / grant	Project + tasks + budget + opportunity	Discuss wording, share quick updates	Proposal docs, signed contracts	(If needed) public case study or resource
Weekly priorities and workload	Tasks, board columns, time entries	Standup coordination, quick check-ins	Meeting agendas/notes	N/A
Drafting a facilitation plan or slide deck	Task pointing to file	Ask for feedback, share snippets	Actual slide deck or planning doc	Finalized, reusable templates
Policy or SOP changes	Task to update; project to track broader effort	Discuss implications, ask questions	Working draft of the policy	Final approved version
Incident or bug in a process	Task(s) to fix and follow up	“Heads up” alerts, quick triage	Incident log or notes (if needed)	Longer-term learning, if it becomes reusable
Partner-facing resource (rubric, tool, etc)	Task to develop and maintain; project if large	Share link, gather input from team	Working drafts, collaborative edits	Final public/open-source version
HR issue or sensitive personnel topic	High-level task only (e.g. “Follow up on HR action”)	Direct messages or private channel (limited group)	HR folder with restricted access	N/A

Note that the above structure matches industry best practice for modern teams:

• Work tracking lives in a project/task tool.

• Conversation lives in a communication tool.

• Content lives in document tools.

• Canon (the “official policies”) lives in a structured knowledge base.

1.5 Direct vs. Org-Wide Work: Where Time Belongs

Not all work is the same. Some of it is direct (tied to a specific grant, contract, or initiative). Some of it is indirect or org-wide (per your role as a director or steward of OWL’s mission-centered work). Here is how we manage both to keep things clean and compliant:

Direct work (project / grant / contract specific): Time that clearly advances a particular funded initiative or fee-for-service engagement should be:

• Logged to the correct project and, when relevant, the correct budget or phase, and

• Tied to specific tasks that map to deliverables, milestones, or scopes of work.

Examples:

• Designing and facilitating a WNCRP convening.

• Customizing a PD series for a specific district.

• Writing a grant-required interim report.

Org-wide / role-specific work (overhead): Time that is about running OWL as an organization belongs in internal, overhead projects (e.g. Finance & Ops, Non-WNC Portfolio Management, Outreach & Field-Building), not on grant-funded or client projects.

Examples:

• Routine bookkeeping, reconciliations, and financial forecasting.

• Managing the organization’s overall contract portfolio and pipelines.

• Networking at a STEM conference, general field-building, or exploratory partner calls that are not (yet) tied to a specific opportunity.

To keep this from getting burdensome, each person can use a small number of container tasks, either inside the relevant internal projects or as stand-alone private tasks. For example:

• “DFO – Core Finance & Compliance (Overhead)”

• “DPIV – Portfolio Management (Overhead)”

• “D-OSL – Outreach & Field-Building (Overhead)”

• “Admin & Microtasks – [Person Name]”

You log time to these containers rather than creating a new task for every email or short meeting. This keeps overhead visible without drowning everyone in administrative paperwork, and it keeps grant/client budgets clean and accurate.

Note: For grant-funded projects, the DFO and Program Manager will clarify which types of effort are allowable on the specific grant. When in doubt, log to an appropriate internal/overhead project and ask before reallocating.

1.6 Don’t Sweat the Small Stuff: What Does Not Need Its Own Task

Not every action needs its own task! Over-tracking creates noise and makes the system a bureaucratic burden.

As a rule of thumb, create a separate task in Productive when the work:

• Will take more than ~30 minutes in a single chunk, or

• Has a clear deliverable or due date, or

• Is relevant to a specific client, funder, or contract, or

• Depends on someone else or will block their work if it stalls, or

• Happens on a recurring basis (e.g. a monthly report, standing partner check-in, or repeat travel pattern), even if each instance is short, or

• You might need to report on it later (internally or externally).

Treat something as a micro-task (no separate task) when it:

• Takes only a few minutes,

• Has no real dependency on others, and

• Is truly “maintenance” work, such as:

  • Responding to a simple email.

  • Grabbing a quick piece of information.

  • Tweaking a word or slide in an existing doc.

We still want micro-tasks to be visible in the aggregate so that we don’t lose track of where time goes. Two simple patterns cover most cases:

1. Log them as part of an existing “real” task. Example: “Update slides based on feedback” includes answering the related email, adjusting a few slides, and re-sharing the deck.

2. Log them under your standing “Admin & Microtasks – [Name]” container in the relevant internal project.

Important: What we don’t do is spend more time tracking the work than doing it! Yes, direct project work gets rigorously and accurately captured in a way that we can justify and audit it for funders and partners, while org-wide and micro-work gets captured in a lighter-weight, container-based way that still respects and balances our need for transparency, compliance, and sanity. Here’s a simple test if you’re still unsure: If this didn’t happen, would someone be surprised, blocked, or out of integrity with a commitment?

• If yes → it belongs in Productive, either as its own task or clearly part of an existing one.

• If no → it probably belongs in a micro-task bucket, a note, or just gets done on the spot.

Disclaimer: Elsewhere in OWL’s policies and procedures, we use the phrase “no shadow work.” For this Playbook, that means: If work meets the criteria for a task (as described in this section) and it never shows up in Productive, either as its own task or as time on a container task, it’s considered shadow work and is not allowed. The reason is that it hides the real effort and burnout risk, the true cost of projects and grants, and early warning signs for OWL’s financial health. By contrast, micro-tasks are not shadow work when they are:

• Rolled into an existing “real” task, or

• Logged against a standing container task (e.g. “Admin & Microtasks – [Name]”).

The standard is simple: If it matters, it should be visible somewhere in Productive. Our “no shadow work” norm is about transparency and integrity, not policing every mouse-click.

2. Core Ways We Use Productive

This section defines the minimum essential uses of Productive at OWL. These are non-negotiable because if we stop doing them, our system breaks. At a high level, we use Productive to address four core areas:

1. Structure work into projects.

2. Turn projects into tasks that are connected to OWL’s Kanban flow.

3. Log time where it actually belongs.

4. Connect work to budgets and CRM* so we can see health and runway.

*Note: Note for OWL, “CRM” is our Customer/Constituent Relationship Management tool that is how our work connects to our money and impact (budgets, invoices, etc.) in the form of a probable pipeline for contracts, partners, grants, funders, and donors.

The rest of this section unpacks each of these core uses, starting with projects.

2.1 Projects: How We Structure Work

2.1.1 Purpose

Projects are how we group related work and link it to partners and clients, grants and funders, and OWL’s internal priorities and initiatives. A well-structured project:

• Makes it obvious what the work is,

• Shows who is responsible for moving it, and

• Connects that work to time and money in a clean way.

If we get projects wrong, everything built on top of them (tasks, time, budgets, reporting, etc.) gets messy. Attention to detail, especially early, really matters.

2.1.2 Types of Projects We Create

At minimum, we create three broad types of projects:

1. Client / contract projects: For each signed client contract (and or Purchase Order) that is tied to a defined scope of work (e.g. PD series, coaching engagement, lab school support, design sprint, or other fee-for-service work) we create a project that reflects that specific service agreement. This project carries the tasks, time, and budget throughout that engagement.

2. Grant / initiative projects: For each grant-funded initiative (e.g. WNCRP, a multi-year district STEM initiative, etc.) we create a project (or a small set of related projects) aligned to how the work and funding are structured over the life of the grant. Note that for complex, multi-funder efforts, we follow the initiative pattern described in Appendix C.

3. Internal / overhead projects: For major internal work that keeps OWL running (e.g. Finance & Ops, Strategy & Learning, Non-WNC Portfolio Management, Outreach and Fundraising, etc.), we create internal projects so org-wide tasks and time have a home that is not a grant or client project.

Rule of thumb: if a stream of work has recurring deliverables and recurring tasks, it likely needs a project home.

2.1.3 Using Internal Projects as Containers:

OWL uses a small number of clearly defined internal projects in Productive (e.g. Operations, Fundraising, Marketing & Outreach, Program Impact & Visibility) as intentional containers for recurring, role-based, or cross-cutting work that is not tied to a single client contract or grant.

This is by design. We do not create a new project for every internal task. An internal project is the correct home when the work:

• Is part of someone’s ongoing role responsibilities (e.g. Finance & Ops, Outreach, Program Impact),

• Supports multiple external projects or the organization as a whole,

• Is funded through general operating funds or indirect cost recovery (not a restricted grant),

• Would otherwise fragment into dozens of tiny, low-value projects.

In these cases, clarity comes from well-formed tasks and budgets, not more projects.

Examples:

• Preparing board financial reports → Operations

• Managing CRM hygiene and pipeline reviews → Fundraising

• Writing impact summaries used across multiple grants → Program Impact & Visibility

• General outreach conversations that are not yet a real opportunity → Marketing & Outreach

Note that a new Productive project must be created when work crosses any of the following thresholds:

• The work has dedicated funding (contract, grant, or approved strategic investment),

• The work has clear external deliverables owed to a partner or funder,

• The work requires its own budget, reporting, or margin visibility,

• The work is expected to last multiple months and involves multiple people,

• The work would otherwise distort the budget or time picture of an internal container project.

At that point, continuing to log work under a general internal project would create shadow work, hidden risk, or grant noncompliance, and is not allowed. Note that there are also limited, explicit exceptions where external-facing work may begin before full funding is secured. In these cases:

• The work must be set up as its own Productive project, not buried in an internal container.

• The project must be clearly labeled as a Strategic Investment.

• The project must have:

  • A defined time cap,

  • A defined dollar cap,

  • Director-level agreement on the ROI pathway,

  • A scheduled review/decision point (e.g. 30–90 days).

Internal projects are never used to quietly absorb substantial pre-funded or speculative work.

Rule of Thumb (Non-Negotiable): If someone later asks: “How much time and money did OWL invest in this effort?” …the answer should be obvious from Productive without reconstructing it from memory, Slack, or side documents. If the current project structure does not allow that, the structure needs to change.

2.1.4 When to Create a New Project

Create a new project in Productive when:

1. External work is officially approved and funded: A new client/grant project gets its own Productive project when the work is authorized to start and funded. For our purposes, a contract is considered approved when we have one of the following in hand:

   • A fully executed OWL or client-provided agreement, or

   • A client-issued Purchase Order (PO) that clearly references OWL’s proposal/scope, or

   • A proposal that the client has explicitly accepted as the contract (for example, a signed proposal or a clear email paper trail saying “we approve this scope and price”).

   Note: In addition, every approved contract must have a Scope of Work (SOW) that translates the approved amount into clear deliverables and timelines, names key roles (including any contractors/Fellows), and outlines the invoicing plan and major milestones. The Program Manager is responsible for making sure this SOW exists, is shared with the team before or at the start of service delivery, and is updated if the client requests changes.

2. A new funded initiative is launched: When OWL launches a funded initiative (for example, a regional effort like WNCRP), it gets a clear “home” in Productive, even if it will eventually have multiple funders or phases. Note that for multi-funder initiatives, we use a Project Group and separate budgets per funder/phase (see Section 2.4 and Appendix C).

3. A major internal effort begins: Some internal work is big enough to merit its own project. Create an internal project when the effort:

   • Will last more than a few months, and

   • Involves multiple people, and

   • Has visible deliverables or major decisions, such as a full revision of the Employee Handbook, a major systems migration, or designing and launching a new flagship offering.

Do not create a new project for:

• Small, one-off favors or short, informal support (these usually belong under an existing client or internal project).

• Work that is clearly a small extension of an existing project and doesn’t change the scope or deliverables (add tasks to the existing project instead).

• Personal experiments or notes (those belong in your own sandbox tools, not in Productive as a new project).

When in doubt, default to fewer projects: add tasks to an existing project unless the work needs its own budget, reporting, or decision point.

2.1.5 How to Set Up a Project: A Quick Checklist

Whenever you create a new project, follow this minimum checklist so it doesn’t become an orphan:

1. Name Precision: Use a clear, readable name that includes the partner or initiative and, where helpful, the year. Examples:

   • “Buncombe – WNCRP Coaching 2026–27”

   • “AMF Lab School – PD & Coaching 2025”

   • “Internal – Finance & Ops”

2. Client / Organization (if external): Attach the correct company/organization record so the CRM, invoicing, and reporting all line up.

3. Program Manager: The PM (usually a Director or designated lead) is who is responsible for:

   • Keeping the structure healthy and consistent with the project’s scope,

   • Making sure tasks and budgets exist and are aligned, and

   • Partnering with the DFO for financial compliance.

4. Confirm the project is using the workflow: Confirm the standard OWL Task Lists (Kanban lanes) are present: Backlog; Ready; In Progress; Needs Internal Review; Needs External Review; Blocker / On Hold; Done.

   • How to change the workflow (Project Sidebar): Open the project → open the Project Sidebar → Workflows → Change workflow → select “OWL Kanban Dec 2025 update.”

   • Note: If the project previously used an older workflow, Productive will prompt you to map old statuses to the new status set. Complete that mapping carefully (see Section 2.2.3).

5. Budget and time tracking: Ensure time tracking is enabled, and create/confirm the correct budget pattern (coordinate with the DFO if unsure):

   • Time & Materials / daily rate

   • Lump sum with internal tracking

   • Grant-funded / multi-funder structure (per budgeting appendices)

6. Links to key docs: In the project description, link to the key working docs (Drive/GitBook), including the signed contract/grant agreement and the current SOW.

7. Classification (tags or custom fields): Use OWL’s standard fields to support search and reporting, such as:

   • Strands (e.g. for WNCRP), region, or focus area

   • Internal vs external

   • Year or phase (if helpful for reporting)

   • Topic (PBL, Design Thinking, STEM, etc.)

Once these basics are in place, you can start adding tasks and assigning work. A project without an owner, budget, or task lists is not official—it’s just clutter.

2.1.6 Who Does What When a New Project Starts

To avoid dropped balls and “I thought someone else was doing that,” we follow this simple division of responsibilities:

• Director of Finance & Ops (DFO)

  • Confirms the budget structure (pattern, sections, funding sources).

  • Ensures alignment with QuickBooks and any grant requirements.

• Program Manager (PM)

  • Owns the project creation using the checklist above (per the approved Scope of Work and contract).

  • Confirms team members and basic task structure (including contractor/Fellow support, planning time, templates, etc.).

  • Partners with the DFO on monitoring budget health and reporting.

• All assigned team members

  • Add and maintain tasks within the project.

  • Log time to the correct project and budget.

  • Keep statuses and due dates current.

Rule of Thumb: When a new contract or grant is signed, think “DFO sets the money, Program Manager sets the work, team uses it per the scope.”

2.1.7 Where to Go for More Detail

Section 2.1 sets the minimum standards for setting up Productive projects. For more detailed “how-to” steps per the following:

• Appendix B – Standard Budget Setup in Productive for examples of common budget patterns.

• Appendix C – Multi-Funder / Initiative Budget Pattern for complex initiatives like WNCRP.

• Appendix D – Project Templates in Productive for how to use and maintain project templates for repeatable engagements.

Together, the above practices keep our projects from becoming a cluttered and disconnected set of task cards and turn them into a clear structure for all of OWL’s work.

2.2 Tasks & Kanban: How We Manage the Day-to-Day Work

2.2.1 Purpose

Tasks are the units of work. The Kanban board is the single, shared view of how that work is flowing within the team and across our partners. In other words, if projects are the scaffolding, tasks are the bricks, and the Kanban is how we work together to build the house. When used well, the board lets us quickly see:

• What has our attention right now,

• What’s ready to be picked up next, and

• What is stuck and needs help.

OWL’s Kanban views are grouped by Task List (not Status). Status is used as a lightweight signal of activity, not as the primary organizing structure.

Rule of thumb: If we find ourselves having to go card-by-card and tell long stories just to understand the board, something is off with how we’re using this tool.

At minimum, we:

• Treat one task = one clear, trackable piece of work.

• Use standard board columns (Task lists) across all OWL projects.

• Set and respect work-in-progress (WIP) limits so we continually finish more than we start.

• Keep task titles action-oriented, with minimum essential descriptions and clear, actionable “to-do” action steps.

• Treat due dates and status fields as real commitments: when reality changes, we update the card and let affected people know so Productive stays the first place we look for project/task status.

Refer to Appendix A – Kanban & Task Management for details, examples, and screenshots.

2.2.2 What Counts as a Task?

At OWL, Productive uses two different but complementary concepts to manage work:

• Task Lists answer: “What kind of work is this?”

• Status answers: “What is happening to this work right now?”

Keeping these concepts separate is essential to avoiding confusion, duplicate effort, and shadow workflows.

A Productive task should represent a meaningful chunk of work, not a vague topic. A good task:

• Starts with a verb and has a clear, defined outcome. For example:

  • “Draft agenda for Fall Charlotte STEM Convening”

  • “Revise Innovation Charter contract language per AP feedback”

• Has a single owner (even if others help).

• Lives in the correct project (client/grant or internal).

• Has a realistic due date if there is any time sensitivity.

• Includes a short description with key context and links (Drive, GitBook, or email), rather than a wall of pasted text.

Tasks are not:

• Whole projects (“Run the Eastern NC Resilience Network Project” is not a task).

• Vague categories (“Marketing stuff,” “Finance”).

• Every tiny action (that’s what container tasks and micro-tasks are for; see Section 1.5–1.6).

If a “task” feels too big, break it into 2–3 smaller tasks that each have a clear path to “done.”

Task Lists = Work Type (Nouns)

Task Lists represent the *type or phase of work*. They are stable, descriptive, and do not imply motion. OWL’s Kanban boards are organized by Task List and the current standard Task Lists include:

• Backlog

• Ready

• In Progress

• Needs Internal Review

• Needs External Review

• Blocker / On Hold

Rule of thumb: If you are deciding *where a task belongs on the board*, you are choosing a Task List.

Note that Task Lists should change infrequently and only when the nature of the work itself changes. For more before/after examples of well-formed tasks and how to set up cards, see Appendix A.

Note: If a piece of work spans multiple weeks, involves multiple people, or has more than a handful of substantial steps, treat the original card as an epic/parent task and create separate, linked tasks or subtasks for the main pieces of work (refer to Appendix A for when and how to use epic/parent tasks).

2.2.3 Our Standard Kanban Board

Task list = Kanban lane. Task cards are grouped by Task list (Backlog, Ready, In Progress, Needs Internal Review, Needs External Review, Blocked/On Hold, Done), so moving a task across the board means changing its Task list. See Appendix A for detailed column definitions and concrete examples of what belongs (and doesn’t) in each list.

We also keep the Status field simple (e.g. To Do, Doing, On Hold, Done). Status only indicates whether work has started or finished, while the Task list determines where the card lives on the board and how it shows up in our flow.

Important: We move tasks across lists as work actually starts, finishes, or gets blocked so that the board stays current in real time and is not just cleaned up in a batch process just before the scrum begins.

Status = Workflow State (Verbs): Statuses describe the current activity state of a task. They indicate whether work is actively happening or paused. OWL uses a deliberately simple status workflow:

• Not Started – work has not yet begun

• Active Working – someone is actively working on the task

• Paused – work is temporarily blocked or intentionally stopped

• Complete – work is finished

Rule of thumb: If you are answering “Is someone working on this right now?”, you are choosing a Status. Note that statuses are not used to describe priority, phase, or importance.

Workflow changes and legacy status mapping (important): If you change a project from an older workflow to “OWL Kanban Dec 2025 update,” Productive may require you to map old status labels (examples: Design, To Do, Doing, Urgent) into the current OWL status set:

• Not Started

• Active Working

• Paused

• Complete

Use this logic when mapping:

• Anything that meant “work hasn’t begun” → Not Started

• Anything that meant “someone is actively working” (including former “Doing”) → Active Working

• Anything that meant “waiting / blocked / deprioritized for now” → Paused

• Finished work → Complete

Important: “Urgent” is not a Status in OWL’s system. If you previously used “Urgent” as a status, map those tasks to Active Working (if truly in motion) or Not Started (if not yet begun), and then use Priority Level = URGENT (and a due date) as the priority signal.

What Status Is NOT Used For: Status is not used to represent:

• Priority (e.g. “Urgent”)

• Work phase (e.g. “Design”)

• Readiness (e.g. “Backlog” or “To Do”)

• Review type (internal vs. external)

Those concepts are expressed through Task Lists, as well as properly managed due dates, assignees, project context, and explicit notes in the task description. This separation is intentional and helps prevent double-tracking and ambiguity.

Ask this question:	Update this field:
What kind of work is this?	Task List
Where does this live on the board?	Task List
Is someone actively working on it?	Status
Is it blocked or waiting?	Status (Paused)
Is this a high priority item?	Due date, notes, or conversation (not Status)

Guardrail: If you feel tempted to create a new Status to describe work type, urgency, or phase, stop and check: “Should this be a Task List?” Or “Should this be a note, due date, or conversation instead?” When in doubt, default to fewer statuses and clearer task descriptions.

2.2.4 How Work Flows (Pull, Not Push)

We follow a pull mindset, where:

• Any new work is added to Backlog. For example, when a real, potential piece of work shows up (e.g. an ask from a partner, a likely grant, a concrete internal need, etc.) we add it to Backlog.

• When we are ready to commit to it (e.g. in a partner planning meeting, internal design sprint, market research task, etc.), we move it into Ready. Team members pull work from Ready into In Progress, instead of having work constantly pushed at them by others.

• When a task is finished from the doer’s side, it moves to Needs Review / External Review or Done, depending on what the workflow requires.

• If something gets stuck, it moves to Blocked / On Hold, which is a loud signal for help. Note: Blocked/On Hold is not the same as Urgent! Tasks temporarily tagged as urgent under Priority Level are still active and moving where blocked work is stopped until something else happens.

This pattern keeps the Kanban board from becoming a static “to-do” list of “stuff” and instead turns it into a map of how the organization’s work is actually progressing.

2.2.5 WIP Limits: Finish More Than We Start

We use work-in-progress (WIP) limits so that people are not juggling too many In Progress tasks at once, and the Kanban board is an honest picture of focus, not just wishful thinking. Use the following rules of thumb to keep the Kanban manageable per the WIP limits:

• Each team member should have no more than 2–3 tasks in In Progress at any one time (not including private tasks).

• No person should have more than one task with Priority Level = URGENT at a time. Urgent is a temporary identifier for truly time-sensitive work, not a lifestyle!

If a column regularly exceeds the above limits, the team should initiate a swarm to reprioritize or reassign items, especially before pulling in new work. In general, if you notice that a column is overflowing OR you have more than 3 tasks “In Progress” yourself, that is a cue to finish a task or move some items to Blocked/On Hold so that the team can help via a swarm to re-prioritize or re-assign, as needed.

Appendix A.3 shows concrete examples of healthy vs unhealthy WIP and how to interpret what you see on the board.

2.2.6 Using Tasks and Kanban to Support OWL’s Weekly Scrum

The Kanban board exists so our scrums and planning sessions don’t devolve into card-by-card status theater. A healthy pattern looks like this:

• Before the scrum, each person cleans up their tasks (move cards to the right column, close out Done items, remove stale tasks, tag any truly Urgent task, etc.) and makes sure In Progress reflects what they’re really doing right now.

• During the scrum, the team lets the board do the talking, focusing the conversation on:

  • What’s blocking progress (Needs Review and Blocked / On Hold).

  • Any items a team member has tagged via Priority Level = “Urgent” (especially if related to pending deadlines or commitments),

  • What we are pulling next from the Ready column.

  • Any big shifts in priority that mean we need to move work between columns or adjust what’s in In Progress.

What we do not do during the scrum:

• Tell the entire story of every card.

• Debate low-priority Backlog items in a group setting.

• Try to solve complex issues during the scrum (those are addressed in separate, offline conversations that only involve the affected parties).

The more consistently we use tasks and the board, the more scrums can stay focused on priorities, blockers, and where help is needed, instead of a weekly discussion of task status updates.

Note: We supplement the above using the #owl_scrum channel in Slack by keeping short, timely updates, especially if anyone is unable to make a scrum meeting or a task requires additional communication between meetings. Such updates should include: “Here’s where we are → here’s the gap → here’s the next step,” with a link back to the relevant task or project (vs. rewriting all the details).

See Appendix A.4 for a simple pre-scrum checklist you can use to clean up your cards before the meeting.

2.3 Time Tracking: How We See Effort and Cost

2.3.1 Purpose

Time entries help us understand the organization’s capacity in terms of daily work effort, staffing needs, and true costs to deliver the services we provide. They are not about micromanaging minutes, but they are about knowing what it actually takes to deliver our work, staying inside project and grant guardrails, and protecting our people from hidden overload. Minimum non-negotiables include:

• Logging time against the correct project and budget.

• Logging time with a cadence that is accurate enough for grants, pricing, and workload consensus and accountability (minimum = weekly).

• Treat travel days and prep/admin time in a consistent way so budgets and reports make sense (ideally logging these within 24 hours of completion).

Time tracking is one of the main ways we prevent shadow work and make sure OWL’s financial and staffing decisions are based on reality, not just vibes.

2.3.2 Where Time Belongs (Direct vs Org-Wide)

Time tracking follows the same logic as tasks and budgets in Section 1.5: some work is direct (tied to a specific grant, contract, or initiative) and some is org-wide overhead.

• Direct time = hours clearly spent on a specific funded initiative or fee-for-service contract. Log this to the correct project and, when applicable, the right budget section and task (not just the project header). Typical examples include designing and facilitating a convening, preparing and delivering PD for a particular district, or writing a grant-required interim report.

• Org-wide / overhead time = hours spent running OWL as an organization. Log this to internal projects such as Finance & Ops, Development, Strategy & Learning, Portfolio Management, etc., usually via a small number of standing container tasks (for example, “DFO – Core Finance & Compliance (Overhead)” or “Admin & Microtasks – [Name]”).

When in doubt for grant-funded work: log to an appropriate internal/overhead project first and ask the DFO or Program Manager before moving it onto a restricted grant budget. It’s always easier to move time onto a grant than to unwind mis-coded time that violated funder rules.

2.3.3 How We Log Time (Basics)

We follow these minimum-essential guidelines to keep time entries useful for the organization’s planning but not too burdensome for anyone to effectively do their work:

• When real work happens, log time to tasks as soon as possible, with a week being the backstop.

• Log the time to a task associated with that task. Note that logging time only to a project without a task is allowed on occasion as an exception, but should never be the norm!

• Use reasonable increments when logging time. We don’t track every 3-minute action as a separate time entry, but as a rule of thumb, log in 15–30 minute chunks that reflect the work that was done.

• When appropriate, add short, clear descriptions (This helps when we review unusual spikes or prepare funder reports). For example:

  • “Drafted slides for convening #2”

  • “Partner debrief + email follow-up”

The goal isn’t timesheet obsession, just an accurate picture of where our effort went so that we can be accountable to stakeholders and make better decisions in the future.

2.3.4 Travel, Prep, and Admin: Keep It Real, Keep It Bounded

Travel, planning/prep, and admin time can quietly torpedo budgets if we don’t give them clear limits. For any substantial trip, convening, or event, we must create specific tasks for travel days, prep, facilitation, and follow-up so that time entries don’t just go to generic admin. Also make sure those hours are actually funded or have explicit hour caps.

Travel: Time spent traveling specifically for a project (e.g. driving/flying to a district for a workshop) is normally logged to that project and its budget, following both the terms of the specific contract/SOW, and the OWL Travel Policy.

If a trip clearly serves multiple projects, we either:

• Split time proportionally across those projects, or

• Log time to a pre-defined internal/overhead project that already has the split baked into its budget pattern (e.g. “WNCRP Backbone – Shared Travel”).

Important: We never casually bury unfunded travel time inside unrelated projects or restricted grants just to “park” it. If the work doesn’t have a legitimate funding home, it must be treated as a strategic investment and set up that way (see 2.4.2).

Planning & Admin (Project-Specific): Time spent on planning, prep, follow-up, and routine administrative tasks that are clearly necessary for a specific project is logged to that project and its tasks. This includes:

• Designing workshop materials, slide decks, and protocols,

• Doing pre-session empathy interviews or stakeholder intake calls,

• Emailing participants, coordinating logistics, and collecting feedback,

• Updating project docs, reports, and simple data pulls tied to deliverables.

This does not include general admin that isn’t tied to one or more projects (e.g. broad email triage, calendar management, internal all-hands, generic strategy chats). Those belong in your “Admin & Microtasks – [Name]” container task or the relevant internal project (Finance & Ops, Development, Strategy & Learning, etc.).

Planning Caps & Strategic Investment Controls: Open-ended planning for an external initiative that has strategic value, but no clear pathway to funding is one of the fastest ways to burn through time and money (including seed money) with nothing concrete to show for it. To prevent that:

• Exploratory planning for new external work (early ideation, new partner initiatives, etc.) is logged initially to internal Development/Strategy projects and treated as pre-sales and never to a fake “future project.”

• Once exploratory planning for a specific initiative starts to look substantial (rough rule: more than 8–10 hours total across the core OWL team, or multiple meetings with external partners), we must make a decision:

  • Either pause and wait for clearer funding/commitment, or

  • Formalize it as a Strategic Investment with:

    • A named project in Productive (e.g. “Strategic Investment – Alt Schools NC (Discovery Phase)”),

    • An explicit time and dollar cap agreed to by Directors + DFO, and

    • A clear ROI pathway (including what proof points or relationships we’re aiming for, and by when).

Any substantial design work, co-planning, or prototyping beyond the above boundary conditions requires either a signed contract / approved grant + Estimator-backed budget or an explicit and consensus decision by all Directors to extend the strategic investment cap (with updated goals). What we never do is co-design for months on end under the radar! If we are doing serious work with an external partner, whether funded or strategic, we either give it a real project and budget with clear limits or we stop and decide what needs to be true before we invest more.

Litmus test: When we look at a project’s time log, it should read like the real work it took to deliver the service and outcomes described in the SOW, including reasonable travel, planning, prep, and admin and not an arbitrary slice of unbounded “thinking about” time, regardless of the initiative’s potential merit.

2.3.5 Frequency: Daily Where It Matters, Weekly Where It’s Stable

We work hard to balance the discipline and accountability required for accurate time management with our relatively small size as an organization by using two patterns: daily (or 24-hour) logging where accuracy really matters, and weekly summary + exceptions for stable, pre-allocated roles.

Daily / 24-hour standard: This is the default for any mixed or billable work where you are:

• Working across multiple projects or grants, and/or

• Doing billable client work, and/or

• Doing field work or travel tied to specific budgets,

In these cases, ensure time is logged to the right project/task by the end of the day, or at least within 24 hours (especially after field days and travel). This is critical to keep coding clean for timely invoicing and accountability to restricted grants and multi-project tasks.

Weekly summary + by-exception (for stable roles/weeks): For roles and/or weeks where the work done is highly stable and already earmarked (e.g. 70% of one’s salary is tied to a funded project, most work done over a week is purely OWL overhead, etc.), we use a lighter approach:

• Keep a simple scratch log during the week (notes, calendar, or a running doc) with rough time splits.

• Once per week, enter realistic lump time into Productive across the correct projects/containers, for example:

  • “16h – WNCRP tasks, 4h – CCSCR project, 4h – Portfolio Management (Overhead)”

  • “10h – Core Finance & Compliance, 6h – Ops & Systems, 4h – HR / People”

• Important: Exceptions to the above are still logged explicitly: For example, any unusual client-facing work, special development push, or major deviation from your normal pattern gets logged as its own project-specific entry, not simply buried in overhead.

Litmus test: The weekly entries must still match reality, not just a flat pattern made up after the fact. As such, what’s not allowed is:

• Reconstructing time once a month from vague memory.

• Hiding project- or grant-specific work inside generic overhead because it’s easier.

• Letting “weekly summary” become “I didn’t really track my time; I just guessed.”

2.3.6 “No Shadow Work” (Time Version)

As a reminder from Section 1.6, “no shadow work” means we don’t do meaningful work that never shows up in Productive. For time tracking, the short version is:

• If work meets the criteria for a task and no time ever lands on either that task or an appropriate container task, it’s shadow work and is not allowed. This is because doing so hides the real effort, the true cost of projects and grants, and early warning signs essential to our financial health.

• Micro-tasks are not shadow work when they are rolled into an existing “real” task or logged under your standing “Admin & Microtasks – [Name]” container.

Litmus test: If it mattered enough to affect your focus or our commitments that week, it should show up as time in Productive somewhere, either as direct project time or overhead.

2.3.7 Guardrails, Not Gotchas—A few norms keep time tracking aligned with OWL’s financial health and culture:

• Respect grant and contract rules: Some funders are strict about what can be charged. When unsure, default to internal/overhead and ask before reallocating to a grant.

• Match time patterns to budgets: If a project or grant budget assumes a certain level of effort (e.g. 10 days facilitation + 5 days prep), but time logs show something very different, that’s a cue to adjust how we are working, or to adjust future pricing/scoping (not to just fudge the entries).

• Use time data to protect people: If someone is consistently logging heavy hours across many projects, that’s a sign of unsustainable workload, not a badge of honor. We use time data to adjust staffing and priorities, not to reward “heroic overwork.”

Bottom Line: Time entries are how we see the real cost for the mission-aligned work we care about. When we log them consistently and honestly, using daily discipline where needed and sensible weekly patterns where it’s stable, we can make smarter decisions about pricing, staffing, pacing, and when to say no. This is the essential foundation to ensure OWL stays healthy and our work stays human.

2.4 Budgets: How We Protect Runway and Grant Integrity

2.4.1 Purpose

Budgets in Productive are what connect our work to funding and cash so that we can constantly monitor how each engagement or initiative is progressing. Good budget management enables us to answer the following:

• Are we on track or bleeding on this project, contract, or grant?

• Are we honoring funder rules and guardrails?

• Can we afford to say yes, or do we need to renegotiate or say no?

At minimum, we will always:

• Start every planned project, activity, and client-facing service scope with the OWL Service Estimator, then mirror the approved estimate in Productive.

• Use the right budget pattern for the work (time & materials, lump sum/installments, grant/pass-through, or multi-funder) so that time, expenses, and reporting line up cleanly to how we actually deliver the work.

• Align Productive budgets with the Estimator, QuickBooks, and grant requirements, in coordination with the DFO.

2.4.2 What Gets a Budget (and Why)

Every meaningful external engagement gets a budget that traces back to the Estimator or to a clear funding decision. That means:

• Every signed client contract (including those anchored to a client-issued PO or proposal-as-contract per 2.1.3) and SOW goes through the OWL Service Estimator in order to develop an accurate Productive project and budget that confidently matches the final estimate (price, structure, and guardrails per what is promised).

• Every active or likely grant or major philanthropic gift gets its own budget in Productive, even if we’re not invoicing the funder. That budget is set up using categories that match the grant’s allowed uses and reporting requirements.

• Complex, multi-funder initiatives (e.g. WNCRP) are set up in Productive as a Project Group that contains multiple budgets, with one budget per major funder or phase (see Appendix C for details).

Note: Doing the above well is craft work, not just data entry! Anyone who scopes or manages projects is expected to build fluency with the Estimator and the matching Productive budget over time.

What we do not do is run substantial, open-ended, or “budget-less” external work. If time is being logged to a potential client, grant-funded project, or external initiative, there should be:

• A budget that clearly labels the work as funded or as a strategic investment, and

• An explicit time and dollar cap plus a clear ROI pathway (what we’re trying to unlock and by when).

There are only two legitimate ways to engage in work that isn’t fully funded yet:

1. Tiny, low-risk exceptions such as a one-off, <1 day partner favor that helps advance OWL’s mission and/or relationships. These can live under an internal/overhead project if the DFO and Directors agree, but with explicit boundaries in scope and expense.

2. Deliberate strategic investments such as short, focused pilots or pro-bono phases designed to unlock something concrete: future funding, powerful proof points, or essential relationships. The following are non-negotiable for these special-case projects:

   • Director-level consensus and a clear ROI pathway (how this could reasonably lead to funding or strategic leverage).

   • A real project and budget in Productive, flagged as a Strategic Investment, with a time and dollar cap that is visible and agreed.

   • A clear review date (e.g. 1–3 months) to decide whether to convert it into a funded engagement, scale back the scope, or simply capture lessons learned and close.

   • Planning, travel, and admin time for these initiatives must follow the same caps and controls described in Section 2.3.4 (Travel, Prep, and Admin). We do not plan or co-design indefinitely without a cap, budget, and decision point.

What we never do, no matter how worthy an idea or initiative may be, is let it slowly turn into a large, unfunded liability because it never had a budget, never had a cap, and never had a clear decision point. As soon as something looks like a real engagement (for example, multiple sessions, clear outcomes, or more than a token gesture), it gets:

• A proper Estimator file,

• A Productive project, and

• A budget that makes explicit our level of investment and our anticipated return.

2.4.3 Budget Patterns We Use

• Option 1: Estimator → Standard client budget

• Option 2: Lump sum / installments / grant-funded

• Option 3: Multi-funder / multi-phase (see details in Appendix C)

• Option 4: T&M (rare, with guardrails)

For concrete examples of how to structure a standard client budget and grant/lump-sum budgets in Productive, see Appendix B – Standard Budget Setup in Productive.

2.4.4 From Estimator to Productive (Single Story of the Money)

For client-facing service work, we want one consistent story from scope to cash and use the following steps to make that happen. While this overall flow is relatively simple, the process itself is rarely simple, given the inherent complexity of OWL’s work: multi-trip engagements, mixed staffing patterns, contractor caps, and strict margin guardrails. As such, the tool we use for such estimates, the OWL Service Estimator is intentionally more detailed and complex than a basic day-rate calculator. That is by design! The goal is not extra clicks for their own sake, but to embed our hard-won financial guardrails and lessons directly into the pricing math so we don’t quietly repeat “soft estimate” mistakes from past projects. Follow these steps to ensure accurate and rigorous project estimates in every case:

1. Scope and price the work in the OWL Service Estimator, making sure it respects our guardrails (margin, contractor caps, travel at cost, deposit/terms).

2. Turn that estimate into a clear SOW or contract that matches the Estimator: same structure, same total price, same assumptions and policies.

3. Create a matching project and budget in Productive so time and expenses land in the right places and budget health is visible and manageable.

4. As work happens, exercise the operating discipline to log time and expenses in a timely manner, while constantly monitoring actuals against the Estimator’s assumptions so that adjustments to scope and contracts are proactively made in real time (vs quietly absorbing overruns).

In short the above flow is critical for OWL’s financial health and sustainability: The Estimator is where we design and stress-test our financial model for the services we provide to clients, while Productive is where we see what actually happens as that work unfolds. Note that Appendix E shows the step-by-step workflow and a detailed example. Also refer to this document for more details on how to use the OWL Estimator Tool.

2.4.5 Ongoing Use & Guardrails (Day-to-Day)

Budgets are never a “set and forget” set of information. They are live instruments we use to manage real time work we do for contracts, projects, grants, and other initiatives. For each active budget, the PM and DFO will periodically do a minimum of monthly budget reviews (more often for big, fragile, or high-risk projects):

• Spent to date vs. the estimate (services, travel, stipends, etc.).

• Remaining budget and runway.

• Percent used vs. time elapsed.

• Any glaring mismatches, such as:

  • Lots of staff/contractor time with few visible deliverables.

  • Heavy travel vs. light services.

  • Time coded to a grant that doesn’t fit the grant’s intended uses.

The key outcomes of these review sessions:

• Are we on track, ahead (per ROI margin), or behind (over-serving)?

• Do we need to adjust scope, renegotiate, or change staffing to realign with the budget?

• Do we need a revised estimate/SOW or change order for additional phases or scope creep?

If scope, funding, or pricing change in a real way, we will update the contract (via a change order) SOW, and Productive budget rather than pretending the original plan still fits.

How the Rest of the Team Uses Budgets: For most team members, the expectations stay simple:

• Log time and expenses to the right project, task, and budget section (Services, Travel, Stipends, Events, etc.).

• If you notice that a budget looks tight or strange (“we’re burning hours faster than expected” or “we’re spending a lot of travel for very little impact”), raise a flag to the PM or DFO.

Guardrails: What’s Allowed and What’s Not: To keep budgets meaningful and keep OWL out of trouble, a few rules are non-negotiable. What’s expected:

• Every major client contract and grant has an Estimator file (for service scopes), and a Productive budget that matches the final agreement in structure and totals.

• Time and expenses are coded to the correct budget section (Services, Travel, Stipends, Events, Materials & Supplies, Admin/Operations, etc.).

• Internal/overhead projects and container tasks are used for:

  • Pre-sales/field-building and storytelling.

  • General admin and internal ops.

  • Strategic investments and work that is not yet clearly funded (with explicit caps and decision points per 2.4.2).

• Multi-funder work uses separate budgets per funder/phase, not one blended pot.

What’s Not OK

• Bypassing the OWL Service Estimator and “hand-building” pricing for client-facing service work.

• Running substantial external work without a Productive budget (“we’ll just track time and see”).

• Charging time or expenses to a grant that clearly don’t meet the funder’s rules, just to “use up” funds.

• Letting side spreadsheets become the real budget while the Estimator and Productive lag behind.

2.4.6 Where to Go for Details

For the hands-on details, see:

• Appendix B – Standard Budget Setup

• Appendix C – Multi-Funder / Initiative Budget Pattern

• Appendix E – From Estimator to Productive Budget (Workflow)

2.5 CRM & Pipeline: How We Track Emerging Work

2.5.1 Purpose

Productive’s CRM is where we track late-stage opportunities that are likely to turn into real work that requires tracking of time and funding. This includes contracts and renewals, significant grants and donations, and commitments to new, multi-partner initiatives (e.g. WNCRP). The Productive CRM is not designed to be OWL’s cradle-to-grave tool for logging and tracking every potential opportunity. OWL’s internal CRM/fundraising tracker is what we use to capture and document the broader set of leads, relationships, and early-stage ideas.

The specific purpose of Productive’s CRM is for Directors to be able to see, in one place:

• What work is highly probable (at least verbally confirmed),

• Rough size and timing of that work, and

• How it will connect to other projects, budgets, and capacity if it lands.

2.5.2 When We Use Productive’s CRM (and When We Don’t)

We only create a Productive Opportunity when something has moved beyond an “interesting idea” into the “likely to happen” phase, if we do our part. This includes:

• There has been at least one concrete scoping conversation, and

• There is a realistic budget or funding path (school/district funding approval, positive grant feedback, strong donor intent, etc.), and

• OWL intends to actively pursue the work in the near term (i.e. we will commit time, energy, and staffing required to do the work), and

• The chance of it moving forward is high enough that we want it to appear in the organization’s runway and staffing conversations.

Examples:

• A district has asked for a proposal and has identified a budget source.

• A grantmaker has invited a full proposal or indicated strong interest after an LOI.

• A donor has indicated they want to make a significant gift earmarked to a specific area of OWL’s work.

• A renewal or expansion of existing work is more likely than not (i.e. we’d be surprised if the school/district in question didn’t renew).

• Seed money has been provided to study and pilot a larger, multi-partner initiative.

We do not create Opportunities in Productive for:

• Early-stage leads (“they liked our session at a conference”).

• General interest conversations with no clear budget or timing.

• Blue-sky ideas that might turn into a grant “someday.”

• Every individual donor or small gift.

All of that lives in OWL’s internal CRM / fundraising tracker until it crosses the “highly probable / actively scoping” line. Note: We do not try to keep two full CRMs in sync or double-enter everything. We use each tool for what it’s good at.

Rule of thumb: Productive CRM is for “likely work we’re planning for,” not for “anyone who might someday say yes.”

2.5.3 What We Track in a Productive Opportunity

Each Opportunity in Productive should be entered in a way that captures the following minimum-essential information:

• Opportunity name – clear and specific (e.g. “WNCRP – LLF Renewal” or “Buncombe – 2026 Experiential PD Series”).

• Organization / contact – school, district, funding source, etc., including our primary contact person.

• Type – contract, grant, donation, sponsorship, etc.

• Estimated value – what we reasonably expect (this should not be a high spot guess, but a detailed estimate per OWL’s estimator tool).

• Expected close date – when we think a yes/no decision will likely be made.

• Stage – a realistic identification of the opportunity’s stage:

  • Qualified

  • Scoping / Design in Progress

  • Proposal / Application Submitted

  • Verbal Yes / Pending Contract

  • Won

  • Lost / On Hold

• Probability – a justified estimate of the chance of closing (e.g. 40%, 60%, 80%, 90%), tied to the stage so we can see and plan based on the likely revenue and runway.

• Description & references: The Opportunity entry’s details should be short, clear, and factual. This is not the forum for documenting full relationship histories and detailed notes of every interaction. What should be included are specific links back to more detailed documents, including any Estimator files, as well as other applicable internal CRM/fundraising records and shared docs (proposal drafts, LOIs, etc.).

2.5.4 Handoff: From Opportunity to Project & Budget

Once an Opportunity is Won, we do a clean handoff:

1. Confirm the final scope and amount: Make sure the signed SOW/contract or grant award matches what’s in the Opportunity (or update the value if it changed).

2. Create the project and budget in Productive (refer to section 2.4 above): Be sure the project name, client, and scope match the agreement and that the budget mirrors the Estimator and SOW structure.

3. Link the Opportunity to the project: In Productive, connect the Opportunity to the new project/budget so we can trace “pipeline → work → actuals.”

4. Update stage to “Won” and stop forecasting it in the pipeline: This moves the Opportunity from “future work” to “current work” so that it is reflected in the Projects/Budgets view.

If an Opportunity is Lost, set the stage to Lost (or On Hold), add a brief reason (if helpful for pattern-spotting), and verify we’re not still forecasting it.

2.5.5 Roles & Review Cadence:

• Program Managers are responsible for keeping their own late-stage Opportunities current (in coordination with the DPIV and DFO), including updating stages, values, probabilities, expected close dates, and details.

• The DFO uses Productive’s CRM + Budgets to inform cash-flow projections, runway scenarios, and proactive hiring/staffing decisions.

• All Directors will review the Productive pipeline as part of the monthly Strategy Meeting to address what’s likely to land in the next 3–12 months, where there are gaps we need to fill (regional, topic, capacity, etc.), and any concentration risks (too much in one funder, sector, type, etc.).

3. Documents & Links: How Productive Plays with GitBook and Drive

3.1 Purpose

Productive is not where documents live. It’s where we point to the right document so work, decisions, and evidence are easy to find. GitBook/GitHub and the OWL Google Drive remain the systems of record for organizational content; Productive is simply the tool that connects tasks, time, and budgets to those sources of truth.

At a minimum, we:

• Link every significant task or project to the one best document or folder people need to do the work.

• Respect OWL’s Document Control Policy when choosing whether that link goes to GitBook or Drive.

• Avoid using Productive as a file dump (multiple uploads, outdated attachments, mystery links, etc.).

3.2 How This Playbook Stays Current

This Playbook is a controlled document in OWL’s system, not a one-off Google Doc that drifts.

• It lives in GitBook as the canonical version, with a clear owner, version history, and last-updated date per OWL’s Document Control Policy.

• The DFO is the Steward for this Playbook, with Directors and Program Managers as co-designers and reviewers.

• Any changes to how we actually use Productive (new features, new patterns, major shifts in roles) should trigger:

  • A Productive task assigned to the DFO (or delegate) to update the Playbook, and

  • A quick note in Slack or at scrum once the update is live.

• We don’t spin up new “Productive how-to” docs in random places. If something is worth writing down, it either:

  • Gets added as a section/appendix here, or

  • Is referenced here if it needs to live as a separate SOP.

In short: this Playbook is the front door for “how OWL uses Productive,” and it is maintained like any other official OWL policy or SOP.

3.3 How Productive Fits into OWL’s Document Structure

Productive is not a filing cabinet for all things associated with projects, contracts, and initiatives. It’s a tool that connects work to the right documents. Here’s how it fits within OWL’s document architecture:

• GitBook – codified, version-controlled policies, SOPs, and reusable tools/templates.

• Google Drive – project-specific and time-bound working docs (slides, notes, drafts, event artifacts).

• Productive – tasks, projects, budgets, and deals that link to GitBook and Drive.

The rule of thumb: Productive holds the work. GitBook and Drive hold the referenced content. Productive points to content; it does not replace it.

3.4 What to Link from Productive (and Where)

To keep things simple and useful, we aim for a small number of high-value links per item.

For Tasks: Link when it helps someone actually do the work:

• Link to the primary working doc or folder in Drive for that task (e.g. “Clay – Jan Convening – Working Slides” or “WNCRP – Site Visit Notes – Henderson”).

• Link to the relevant GitBook policy or guide when the task requires using it (e.g. OWL Travel Policy, OWL Contractor Manual, etc.).

• Use clear labels in the task description so the reader knows what is linked (e.g. “Contract,” “Scope of Work,” Official Estimate,” etc.).

For Projects: Every active project should have:

• A link to the SOW/contract folder in Drive.

• Links to any key references needed repeatedly for that project:

  • Estimator & budget setup guides

  • Relevant policies (e.g. travel, stipends, data/privacy)

  • Standard tools (protocols, templates, checklists).

These live in the project’s Links/Notes area and should not be scattered across random subtasks.

For Budgets and Deals (in the Productive CRM):

• For budgets, link to the internal Estimator file (if applicable) and/or any grant/award letters or budget breakdowns in Drive that inform how we code time/expenses.

• For deals, link to the main proposal/LOI/notes doc in Drive, and, when relevant, the corresponding opportunity record in OWL’s main CRM/tracker.

Note: We don’t need a link for every individual email or artifact, just the key doc/folder that anchors the work.

3.5 What Not to Link or Store in Productive

To keep things trustworthy and safe, we deliberately don’t use Productive for certain types of content.

Do not:

• Upload or paste copies of controlled policies, templates, or tools into Productive (Always link to the GitBook version so people see the latest one).

• Link to personal drafts or random “copy-of” files when a clean shared version exists. If a doc “graduates” from messy draft to shared asset, tidy the link to point to the shared, updated version.

• Put sensitive information (PII, salaries, HR records, confidential contract terms) in task descriptions or comments. Instead, keep those in restricted Drive folders and reference them with a generic label (e.g. “HR doc – restricted Drive folder” or “Contract redlines – legal folder”).

• Create long lists of links inside tasks or projects (if you feel compelled to drop in 10 links, you probably need a single Drive folder and a link to that).

Finally, we don't go back and “fix” every old, completed task when a document moves. When something becomes official or changes location (for example, a template moves from Drive into GitBook), we update the project templates, any recurring or parent tasks, and this Playbook (if needed) so that future work points to the right place.

Appendices (Detailed How-To & References)

Appendix A – Kanban & Task Management in Productive

Purpose: This appendix shows the concrete “how” behind Section 2.2 Tasks & Kanban – what each list is for, what a good task card looks like, how we apply WIP limits, and how we prep the board for scrum. The goal is to make the board readable at a glance, not to invent new rules.

A.1 Board Structure & Columns

To avoid each project inventing its own language, OWL uses a standard set of Task lists (columns on the Kanban) on shared boards:

• Backlog: Ideas and future work that we might do, but have not committed to yet. Note: Backlog is not a parking lot for abstract ideas; it’s where we hold plausible future work that we might commit to, once we’ve had a chance to scope it, prioritize it, and decide on next steps. Note: Backlog can hold “real but unfunded yet” opportunities. Also, not everything in Backlog needs a due date.

• Ready: Work we have committed to do and are prepared to start per a target date. These tasks are well-formed, with a clear title, owner, project scope, and funding pathway. Note: Ready should mean that we intend to spend time on this and there’s a credible ROI path or explicit leadership agreement to move it forward.

• In Progress: Work someone is actively doing right now. Key: No task should live here without an owner and some recent activity. Note: In Progress = actually funded (client/grant) or explicitly covered by internal overhead (e.g. Development, Finance & Ops, Strategy) — ever just a “nice thing we’re doing for free.”

• Needs Review (Internal or External): Work that is done from the doer’s perspective, but needs either:

  • Internal review/feedback from an OWL peer, or

  • A response from an external partner/client (e.g. waiting on approval).

• Blocked / On Hold: Work that cannot move forward because of a dependency, missing information, or a decision. Being in the Blocked/On Hold column is a signal that help or a decision is needed and should never just be a parking lot.

• Done: Work that is fully complete. We regularly prune/archive Done tasks to keep the board light.

Additional Examples:

List	What belongs here	Good example	Misuse / non-example
Backlog	Real candidate work we might do soon, but have not yet committed to.	“Design draft agenda for Spring convening (pending client dates)”	“Random ideas” like “someday redesign website”
Ready	Well-formed tasks we have decided to do and are prepared to start.	“Finalize Clay PD Day 1 slide deck” (owner, due date, link attached)	Vague tasks like “WNCRP stuff”
In Progress	Work someone is actively doing right now.	“Draft WNCRP June convening agenda” while you’re actually working on it	Ten cards with your name that haven’t been touched
Needs Review	Work that’s done from the doer’s side but needs internal OWL review or feedback.	“Draft grant narrative – needs Ben/Wes comments”	Parking place for things you’re actually still writing
External Review (if used)	Work that’s sent to a partner and is waiting on their response.	“Send draft SOW to district – awaiting legal sign-off”	Internal tasks that still need our action
Blocked / On Hold	Work that can’t move because of a dependency, missing info, or decision.	“Confirm venue contract – waiting on district PO”	Things we just don’t feel like doing right now
Done	Fully complete work; safe to archive.	“Submit LLF Year 1 report – accepted”	Half-done tasks dumped here just to “clear the board”

Key distinctions:

• Blocked/On Hold vs Urgent:

  • Blocked = “I can’t move this until something else happens.”

  • Priority Level is Urgent = “This is active work with a looming deadline or high impact.”

  • Note: A card can be urgent and later become blocked, but the meanings are different.

• Backlog vs Ready:

  • Backlog is “qualified possibilities we might do.”

  • Ready is “we have decided to do this and have enough clarity to start.”

If you’re not sure where a card belongs, ask: What is actually true right now? Put the card in the list that reflects current reality, not where you hope it will be.

A.2 What Makes a Good Task Card

A good task is a clear, trackable piece of work, not a topic or wish.

Before / after examples

• Weak: WNCRP stuff Strong: Draft WNCRP June convening agenda (first pass)

• Weak: Science House Strong: Review Science House scope draft and add comments in Drive doc

• Weak: Marketing Strong: Update OWL one-pager with new WNCRP language

Each task card should, at minimum:

• Start with a verb and describe a specific outcome.

• Have a single owner (even if others are collaborating).

• Live in the correct project (client/grant or internal/overhead).

• Have a due date if there is any time sensitivity or external commitment.

• Include applicable links to the OWL Drive folder/doc and any relevant GitBook pages.

A.2a Urgent Tags = URGENT (binary flag)

Purpose: “URGENT” is a temporary visibility flag for time-sensitive work that risks money, scope, partner trust, or downstream flow if it slips. It is not a Status and does not change what lane (Task List) the card belongs in.

Definition (binary & rare): A task is “URGENT” only when all are true:

1. There is a real deadline within ≤7 days (date/time),

2. Missing it has a meaningful consequence (money/scope/partner promise/risk), and

3. It requires action before the next weekly scrum (i.e., can’t wait for normal prioritization).

WIP guardrails (so it keeps its power): One URGENT max per person at a time (exceptions require a Director-level call in scrum) AND if >3 URGENT tasks exist across the team, we pause pulling new work and re-prioritize.

How to remove URGENT (required): Clear the URGENT flag as soon as any is true: the deadline risk passed, it’s no longer top time-sensitive, it becomes truly blocked, or we consciously de-prioritize it.

How to flag URGENT in Productive:

1. Open the task and look on the right-side Info panel to find Priority Level.

2. Select URGENT (Leave Priority Level blank for normal tasks.)

3. Verify that the task also has: (1) a real due date, (2) a single owner, and (3) a concrete “next action” in the description/comments so the flag is actionable—not just a warning light.

Scrum view: How to quickly surface URGENT tasks (ideally done prior to the scrum): In the shared Kanban view:

1. Click Filters (top bar).

2. Add filter: Priority Level → URGENT.

3. (Optional but recommended) Exclude Done/Complete so the list is only active risk.

4. Sort by Due date (soonest first).

Ideally this becomes the first thing the team scans in the scrum meeting so everyone is discussing real deadlines, not just vibes.

A.3 WIP Limits & Examples

Work-in-progress (WIP) limits keep us from pretending we’re doing 20 things at once when nobody can. Minimum WIP criteria:

• On shared boards, each person aims for no more than 2–3 tasks in In Progress at any one time.

• Each person should have no more than one Priority Level = Urgent task at a time.

If you regularly see a long column of cards in In Progress, or multiple cards identified as Urgent for the same person, that’s a signal to stop pulling new work, finish or move items to Blocked/On Hold, and talk about priorities at scrum.

Example (unhealthy):

• You have 7 tasks in In Progress, 3 tagged Urgent.

• Several have not been touched in weeks.

Example (healthy):

• You have 2 tasks in In Progress, 1 tagged Urgent.

• Older tasks either moved to Done, Blocked/On Hold, or back to Ready with a note.

A.4 Scrum Prep Checklist

Before weekly scrum, each person does a quick 5–10 minute cleanup so the board can “talk” for us:

1. Move cards to the right list:

   • Anything you’re working on now → In Progress

   • Finished work → Needs Review / External Review or Done

   • Stuck items → Blocked / On Hold (with a short comment)

2. Close out Done items: Check that Done really means done; archive older Done cards as needed.

3. Tag blockers and urgent items:

   • Make sure Blocked cards explain what they’re waiting on.

   • Confirm any items with Priority Level = Urgent truly meet the definition (refer to section A.2 above).

4. Check your WIP:

   • Aim for 2–3 In Progress tasks.

   • If you’re over, decide what to pause or surface for help.

In scrum, we then focus on:

• What’s Blocked / On Hold and needs help or a decision.

• What we’re pulling from Ready into In Progress next.

• Any urgent items that might affect others’ priorities.

A.5 Epic / Parent Tasks: When and How to Use Them

Sometimes a single piece of work is too big to live as one normal task. Rather than having one giant, vague card that sits in In Progress for months, we treat it as an epic/parent task and break it into smaller, linked tasks. Use an epic/parent task only when the work:

• Spans multiple weeks or a full phase of work, and/or

• Involves multiple people doing different parts, and/or

• Has more than a handful of substantial steps that each deserve their own “Done.”

Examples that should be epics:

• “Design and run WNCRP June convening (all parts)”

• “Develop 24/25 Macon County PD series (full scope)”

• “Prepare and submit LLF renewal application”

Each of those can (and should) be broken into several smaller tasks with their own owners and due dates.

A.5.1 How to Structure an Epic

When you decide something is an epic:

1. Create the epic/parent task: Give it a clear, outcome-based title (“WNCRP June convening – design & delivery (epic),” add a brief description of the overall goal and scope, and link it to the appropriate Drive folder.

2. Create separate child tasks for the main pieces of work. For example, under “WNCRP June convening – design & delivery (epic)”:

   • “Draft June convening agenda – first pass”

   • “Confirm venue, catering, and room setup”

   • “Finalize slide deck and facilitator notes”

   • “Send pre-work to participants”

   • “Capture and file artifacts after convening”

3. Each child task should have its own owner, due date, and list position (Ready, In Progress, etc.).

4. Link the child tasks back to the epic. In each child task, add a short note like: “Parent epic: WNCRP June convening – design & delivery.” In the epic, keep a simple checklist or bullet list of the child tasks (with links).

5. Run the Kanban on the child tasks, not the epic: Child tasks move across the board (Ready → In Progress → Needs Review → Done). The epic usually lives in Backlog, Ready, or Blocked/On Hold, and only moves when the whole chunk of work is complete or paused.

6. Log time to the child tasks, not the epic: Time entries should go on the actual work units. The epic is there to organize, not to collect hours.

A.5.2 When Not to Use an Epic

Don’t create an epic/parent task when:

• The work can reasonably be done in a week or less by one person, or

• It only has two or three steps that are easy to track in one normal task, or

• You’re just trying to avoid thinking through the actual chunks of work.

Examples of bad uses of epics:

• “WNCRP work (epic)” with no breakdown.

• “Marketing 2025” as a single card that sits in In Progress all year.

• Using epics as a way to hide too much WIP under one label.

If a task feels a bit big but not epic-sized, keep it a single task and make the description clear, or add a couple of simple subtasks instead of spinning up a full parent-child structure.

A.5.3 Finishing an Epic

An epic is Done when all of its child tasks are done or explicitly closed/abandoned, and there is no remaining work tied to that overall outcome. Before marking the epic Done:

• Scan the child tasks: are they all Done or intentionally closed?

• Add a short closing comment on the epic noting any key result or link to a final artifact (e.g. final report, slide deck, project summary, etc).

Then move the epic to Done and archive it with the rest of the completed work.

Appendix B – Standard Budget Setup in Productive

Purpose: This appendix shows how to turn an approved scope/estimate into a clear, usable Productive budget for “normal” OWL work: client contracts, grant-funded projects, and internal/overhead projects. It puts concrete steps and examples behind Section 2.4.

You should read this as: “When I’m actually in Productive, what do I click and how do I structure things so the numbers make sense?”

B.1 General Rules

1. One budget per engagement: Each client contract, grant, or major internal project gets its own Productive budget, aligned with 2.4.2. For multi-funder initiatives, see Appendix C; for everything else, keep it one budget per engagement.

2. Clear naming pattern: Use a consistent naming convention so budgets are findable and reports make sense: [Org/Project] – [Scope or Phase] – [Year(s)] Examples:

   • Edgecombe County – Experiential STEM PD – 24/25

   • WNCRP – LLF – Year 1

   • Finance & Ops – Internal – 2025

3. Mirror the agreed scope: The total value and major structure of the budget should mirror the OWL Service Estimator (for service work), and the signed SOW/contract or grant award. If the contract changes late in the process, update the Estimator and the budget so they match reality.

4. Assign a Budget Owner: Every budget has a named Budget Owner (usually the PM), who partners with the DFO to monitor health and make adjustments.

B.2 Details on the Budget Patterns We Use

Option 1: OWL Service Estimator → Standard client budget (our default approach):

This is our default approach for client-facing service work (workshops, coaching, series, custom design), we use the OWL Service Estimator to set price and structure for services and pass-through costs, as well as guardrails like minimum contribution margin, deposit-first terms, travel at cost, contractor caps, and Ops & Compliance fees. This then allows us to build a matching Productive budget that:

• Uses the same total price and broad line structure (Services, Travel, Stipends, etc.).

• Carries over key assumptions (onsite vs virtual, travel expectations, pass-through vs service, etc.).

Productive is where we monitor actuals vs what the Estimator assumed, not where we invent a second pricing scheme. Because of this, the Estimator is not “optional” for service pricing or something we work around when it feels complex; it’s the shared tool we use, refine, and learn together so our scopes, contracts, and Productive budgets all tell the same financial story.

Option 2: Lump sum / installments / grant-funded:

For many grants and fixed-fee contracts, the funder or client pays a fixed amount, often in installments. In these cases, we still want to track time and costs, but we’re not invoicing strictly by the hour. The Estimator tool gives us the internal picture of expected effort and cost; Productive shows how close reality stays to that picture.

Budgets are set up in this case with a separate Lump Sum / Funding section (the fixed contracted or grant amount) and a Tracking Sections (Services, Travel, Stipends, Events, etc.) with time/expense tracking turned on:

1. Section 1 – Lump Sum / Funding

   • A single line item that represents the total contracted or granted amount.

   • Time/expense tracking off.

   • Used mainly for high-level views and “are we above/below water?” analysis.

2. Section 2+ – Tracking Sections:

   • Services

   • Travel

   • Stipends / Events

   • Materials & Supplies

   • Admin/Operations (if needed)

   • Time and/or expense tracking on, depending on what we’re tracking.

Example: Grant-Funded Project

• Section: Funding: “LLF Year 1 grant – $165,000” (tracking off)

• Section: Services (time tracking on): “Project Management & Convenings – staff time”

• Section: Travel (expense tracking on): “Mileage & lodging”

• Section: Stipends & Events (expense tracking on): “Teacher stipends” or “Regional convening costs”

This approach lets us answer the following questions without hidden costs:

• “How much funding do we have?” and

• “How are we using it (services vs travel vs stipends, etc.)?”

Option 3: Multi-funder / multi-phase initiatives:

Use this pattern when a single initiative has multiple funders with distinct restrictions, phases, or reporting needs, and/or the total value and complexity justify more structure (e.g. multi-year, large-dollar initiatives).

In these cases, we create a Project Group for the initiative and set up one budget per major funder or phase, using consistent sections (Funding, Services, Travel, Stipends & Events, Materials, Admin/Operations) so we can see both the funder view and the initiative view.

See Appendix C – Multi-Funder / Initiative Budget Pattern for concrete structure, naming examples, and sample reporting views.

Option 4: Time & materials / time & expense (rare case):

Most OWL work is fixed-fee or grant-funded, but a true time & materials / time & expense pattern is possible. We only use this pattern when a partner is explicitly paying for capacity (e.g. day-rate pool, advisory retainer) and we have agreed in writing to bill for actual time and/or expenses. Examples where this might apply might include:

• A district buys a bank of day: “Up to 20 days of implementation support at $X/day; we invoice monthly for days used, plus travel at cost.”

• A small network sets up an advisory retainer: “Up to Y hours/month of leadership coaching at $Z/hour, billed monthly for actual time used.”

If we ever use this pattern, DFO approval is required and the contract language must be clear about:

• The unit and rate (hour/day),

  • What counts as billable time,

  • How travel and other expenses are handled, and

  • Any not-to-exceed caps.

Given the nature of T&M contracts, it is critical that time tracking be highly disciplined throughout the engagement (i.e. time is logged the same day and to the precise T&M tasks). Descriptions must also be clear enough so that an invoice line would make sense to the client. Finally, the Productive budget must:

• Have a Services section with rate-based items that match the agreement (e.g. “Facilitation Day”, “Advisory Hour”).

  • Have a Travel section for reimbursable expenses.

  • Be set up so that time and expenses can flow cleanly into invoicing without side spreadsheets.

Important: We do not use T&M as a backdoor for underpriced fixed-fee work or as a way to avoid doing the upfront design and pricing in the Estimator. If a partner wants clarity on total cost and deliverables, we stick with our Estimator-driven fixed-fee model.

B.3 Estimator → Budget Mapping (Standard Client Work)

For client-facing service work, we start in the OWL Service Estimator. Once the estimate is approved, we translate it into a Productive budget. Typical Estimator sections map like this:

Estimator Section	Productive Budget Section	Notes
Facilitation / PD days	Services – Facilitation & Delivery	Number of days × day rate per Estimator
Planning & follow-up hours	Services – Design & Follow-Up	Convert hours into internal “cost” and/or rate as needed
Custom design or coaching blocks	Services – Coaching & Custom Design	Keep labels clear and aligned with SOW language
Travel (mileage, lodging, per diem, etc.)	Travel (sub-lines for main types)	Either as a single blended line or a few main categories
Stipends / events / materials	Stipends / Events / Materials	Use separate sections if needed for reporting clarity
Ops & Compliance / Admin fee	Admin / Ops & Compliance	Only if listed or needed internally

You don’t have to create a separate section for every tiny detail in the Estimator. The goal is a clean, readable structure that matches the main buckets of the SOW and makes reporting simple.

Step-by-step process for building a standard client budget: Once the Estimator and SOW are final:

1. Create the budget in the correct project.

2. Set the total amount to match the agreed contract value.

3. Add sections: Services, Travel, Stipends / Events / Materials (as needed), and Admin / Ops & Compliance (if explicit).

4. Add line items inside each section that map to the Estimator. For example, in Services: “Facilitation – 4 days” or “Design & Follow-Up – 20 hours (internal)”

5. Turn on time/expense tracking where needed:

   • Services – time tracking on.

   • Travel – expense tracking on.

   • Stipends/Events/Materials – usually expense tracking on.

   • Lump-sum funding lines (if used) – tracking off (see B.3).

6. Quick sanity check questions:

   • Does each major Estimator line have a clear home in the budget?

   • Do the budget totals match the Estimator and SOW?

   • Is a Budget Owner assigned?

Once set up, this budget becomes the place we watch actuals vs expected for the engagement.

B.4 Internal / Overhead Budgets

Internal projects (Finance & Ops, Outreach, WNCRP Backbone, etc.) still need budgets, but simpler ones.

B.4.1 Use an internal/overhead budget when:

• Work is not directly billable to a single client or grant, and

• We still want to track time/costs to understand true operating costs.

Examples:

• Finance & Ops – Internal – 2025

• Outreach & Field-Building – Internal – 2025

• Strategy & Learning – Internal – 2025

B.4.2 Simple internal pattern

Keep internal budgets light:

• Section: Staff Time: For time logged by staff in that internal area.

• Section: Contractors (if needed): For any external support that isn’t client-billable.

• Section: Tools & Subscriptions (optional): For recurring software/ops costs if you want visibility here.

You can either set a simple annual “soft cap” for internal budgets (for planning), or use them primarily for tracking actuals to inform future planning. Note: Internal budgets should be informative, not overly complex.

B.5 Final Checklist

Before you call a budget “ready,” run through this quick checklist:

1. No stray “Open Hours/Expenses” - Make sure you haven’t left generic “Open hours” or “Open expenses” lines that don’t map to real sections. If they’re there, either repurpose them clearly or remove them.

2. Totals match the Estimator and SOW/award: For client-facing work, the Contract value = Estimator price = Productive budget total. For grants, the Grant award = “Funding” section = sum of planned use across sections.

3. Sections align with how we’ll report: Ask: “If someone requested a simple breakdown report, would these sections make sense?” If not, rename or regroup before the engagement gets busy.

4. Budget Owner is clearly set: There is a named person responsible for watching this budget with the DFO.

5. Tracking flags are correct:

   • Time tracking on for services where we expect staff/contractor hours.

   • Expense tracking on where we expect travel, stipends, or materials.

   • Tracking off for pure lump-sum funding lines.

6. Grant rules are respected: For grant-funded budgets, confirm the sections align with allowed uses and reporting categories.

If any of the above feels off, fix them before time and expenses start landing. It’s much easier to correct a budget structure on Day 1 than halfway through a busy year.

Appendix C – Multi-Funder / Initiative Budget Pattern

Purpose: This appendix shows how we set up complex, multi-funder initiatives in Productive (e.g. WNCRP) so we can see:

• Each funder’s money and restrictions,

• The initiative as a whole, and

• How actual work (time/expenses) flows without double-counting.

It expands on Section 2.4.3, Option 3.

C.1 When to Use This Pattern

Use the multi-funder / initiative pattern when all (or most) of the following are true:

• The work has multiple funders (grants, donations, in-kind) that each have their own rules or reporting needs.

• The initiative runs across multiple years or clearly defined phases.

• We need to answer questions by initiative (e.g. “How is WNCRP doing overall?”) and by funder (e.g. “How did we use LLF Year 3 funds?”).

• The total size and complexity justify extra structure (e.g. multi-year, large-dollar, or flagship initiatives).

Typical examples:

• WNCRP with LLF + DHT + additional donations or phased funding.

• A regional initiative funded by multiple foundations and/or state partners.

If a project is simpler (single funder, one year, straightforward reporting), we stick with the standard single-budget pattern in Appendix B.

C.2 Project Group Setup

For qualified initiatives, we use a Project Group to collect all related projects and budgets under one umbrella. Then create a Project Group named after the initiative (e.g. WNCRP, NC Alternative Schools Initiative, etc.). Within that group, we create separate projects/budgets for each major funder or phase (see C.3).

Why a group instead of one big project? This approach lets us:

• Keep funder-specific budgets clean and compliant.

  • Build initiative-level views across all funders.

  • Add or remove funders/phases over time without wrecking existing budgets.

Possible screenshot placeholder: [Insert screenshot: Productive Project Group – "WNCRP" showing member projects/budgets]

C.3 Per-Funder / Phase Budgets

Each major funder or phase gets its own budget inside the Project Group.

Example naming pattern:

• WNCRP – LLF – Year 2

• WNCRP – Donations – Year 1

• WNCRP – DHT – Year 1

Each budget uses a consistent section structure, so initiative-wide reporting is easy to read:

• Funding (optional lump-sum section): “LLF Year 1 grant – $165,000” (tracking off)

• Services (time tracking on): “Project Management & Convenings – staff time” or “Coaching & Site Support – staff time”

• Travel (expense tracking on)

• Stipends & Events (expense tracking on)

• Materials & Supplies (expense tracking on, if needed)

• Admin / Operations (if allowed by funder or needed for internal clarity)

Each funder’s budget should clearly show both the total funding and how we’re using it (services, travel, stipends, etc.). Section names are consistent across budgets so initiative-wide views make sense.

Possible screenshot placeholder: [Insert screenshot: Budget "WNCRP – LLF – Year 1" showing Funding, Services, Travel, Stipends & Events, Admin sections]

C.4 Reports

To make the above structure useful, you should create a few saved views across the Project Group. For example:

1. All WNCRP – Services by Funder: “How much staff time are we putting into WNCRP per funder?”

   • Filters: Project Group = WNCRP; category = Services.

   • Shows: total service time/cost per budget (LLF Year 1, Donations Year 1, etc.).

2. All WNCRP – Total Actual vs Budget: “Are we on track or overspending in any budget/section?”

   • Filters: Project Group = WNCRP.

   • Shows: budget vs actual, by funder and by section.

3. Optional: WNCRP – Travel & Stipends (All Funders): “What are we spending to move people and run events regionally?”

   • Focused view on Travel + Stipends sections across all budgets.

C.5 Example Walkthrough: One Convening Across Budgets

To see how this works in practice, imagine a single WNCRP regional convening that is primarily funded by LLF Year 1, but uses a small amount of Donations Year 1 to cover extra stipends. Here’s how it plays out:

1. Tasks and project: The work lives in the WNCRP project(s) inside the WNCRP group (e.g. WNCRP – Core Backbone), with the following tasks:

   • “Plan June regional convening – agenda & design”

   • “Deliver June regional convening (onsite)”

   • “Process stipends and follow-up”

2. Time entries (Services): Staff time for planning and facilitation is logged to tasks in the WNCRP project and coded to the Services section of the LLF – Year 1 budget (unless there is a clear reason to split across funders).

3. Travel expenses: Mileage, lodging, etc. are coded as expenses to the Travel section of the LLF – Year 1 budget, assuming LLF allows this use.

4. Stipends: Teacher stipends might be mostly coded to LLF – Year 1 – Stipends & Events, and a small top-up coded to Donations – Year 1 – Stipends & Events, if LLF has a cap.

5. Reporting: To report back to LLF, we would use views filtered to the LLF – Year 1 budget only, by section and/or by time vs expenses. To understand WNCRP as a whole, we would use the Project Group views in C.4 to see services/travel/stipends across all funders.

Key points:

• No double-booking. Each time entry or expense is coded to one funder’s budget section based on what that funder is legitimately supporting.

• The initiative story is told at the Project Group level; the funder story is told at each budget level.

Appendix D – Optional Project Templates in Productive

Purpose: This appendix explains how OWL may use Project Templates in Productive so we don’t rebuild the same structure from scratch. It expands on the references to templates in Section 2.1 (Projects: How We Structure Work) and offers examples of patterns that might warrant templates as they mature.

Note: OWL uses project templates in Productive as an optional convenience, not a core part of our operating discipline. The essentials we always rely on are:

• Clear project setup (Section 2.1)

• Standard Kanban lists (Section 2.2)

• Consistent budget patterns (Section 2.4)

D.1 When to Use Templates

Templates simply exist to make it easier to start new work quickly with a solid default structure, and keep similar projects consistent (same lists, starter tasks, and key links). In cases where a pattern repeats frequently (for example, a standard PD series or a recurring internal ops project), a Director or the DFO may decide to create a Productive Project Template to speed up setup and reduce errors. When that happens:

• The template should be based on a recent, healthy project of that type.

• Client-specific details must be stripped out.

• The template should be named clearly and introduced to the team in Slack with a short “when to use this” note.

For the mechanics of creating and editing templates, we use Productive’s own documentation and tutorials rather than maintaining a separate how-to guide.

D.2 Suggested Template Examples

The table below shows examples of patterns that could justify templates as they become common and stable in our work:

Template Name	When to Use It
Standard PD Series	Multi-session professional learning for a single partner (e.g. district PD series, cohort PD).
Grant-Funded Initiative	Single-funder, multi-month or multi-year grant projects with clear deliverables.
Multi-Funder Initiative – Core	Flagship efforts like WNCRP where there are multiple budgets/funders but a shared backbone team.
Internal Ops – Finance & Ops	Finance, HR, compliance, and operational improvement work.
Internal Ops – Outreach & Field-Building	Strategic outreach, relationship-building, and field-level work not tied to a single contract.

Important: Templates are for repeatable patterns, not for every project. If a project is truly unique, it’s usually better to clone a similar project once and adjust it, rather than creating a new template.

Appendix E – From Estimator to Productive Budget (Workflow)

Purpose: This appendix turns Section 2.4.4 into a concrete workflow: how we move from scope → Estimator → SOW → Productive project and budget, and how we keep those in sync over time. It assumes you already know the basics of the Estimator itself.

Note: A learning curve with the Estimator is normal. When something doesn’t make sense, start by checking the Estimator “START HERE” page and then ask the DFO or your Program Manager to walk through a real example with you. What we don’t do is bypass the Estimator or hand-build pricing outside it, since that’s how gaps creep in between scope, contract, and Productive.

E.1 Overview: One Story of the Money

For client-facing service work, we want one coherent story, not three conflicting ones. The flow is: Scope & assumptions → OWL Service Estimator → SOW/contract → Productive project + budget → Actuals vs plan

1. Estimator: You translate the draft scope into a margin-safe price with guardrails (≥45% contribution, contractor cap, deposit/terms, travel at cost).

2. SOW / Contract: You turn the Estimator output into client-facing language: scope, deliverables, dates, price, travel rules, terms, and change-order language.

3. Productive project + budget: You set up a project and budget that mirror that agreement so time and expenses land in the right places and budget health stays visible.

4. Actuals vs assumptions: As work happens, you log time/expenses and use Productive to check: Did reality match what we priced? If not, we adjust scope/contract, not just hope.

E.2 Step-by-Step for a Typical Client Scope

This is the standard workflow for a new client-facing service engagement (workshops, series, coaching, custom design).

1. Clarify the scope (pre-Estimator)

   • Audience, outcomes, main deliverables.

   • Virtual vs onsite mix, trips, facilitators.

   • Any funder/partner constraints you already know.

2. Create and save an Estimator file: Open the official Estimator link and let it force a copy. Name it in this format: YYYY-MM-DD_<Partner>_<Scope>_v1_EST.xlsx and then save it in the partner’s Drive folder under /Estimates/ per the Estimator guide.

3. Set scope, guardrails, and price in the Estimator:

   • Choose the correct Work Type (OWL-led vs Pass-through, if relevant).

   • Enter service days, planning %, follow-up, travel, contractors (if any).

   • Let the Estimator enforce: guardrails and terms (e.g. ≥45%, Net after pass-through, price, etc.) and then adjust scope/discounts until the numbers are healthy and realistic.

4. Draft the proposal/SOW from the Estimator output: Use the Estimator to set:

   • The client price (or prices, if virtual + onsite),

   • Clear travel language (pass-through at cost; no pre-funding),

   • Terms and change-order conditions.

5. Confirm scope and price with the partner: Share the proposal/SOW; adjust as needed. If the client pushes on price/scope, revise the Estimator first so guardrails remain intact, then revise the SOW.

6. Once agreed, finalize the Estimator & SOW: Save the final Estimator version in the partner’s /Estimates/ folder (no more edits except small corrections) and then file the signed SOW/contract in the correct /Contracts or /SOW folder.

7. Create the project in Productive: Create a project with a name that matches the SOW and link the project to the correct client. Also add a link to the Estimator file and the SOW/contract in the project description or a pinned task.

8. Create the matching budget in Productive:

   • Choose the correct budget pattern (usually Option 1 from 2.4.3).

   • Set total price to match the Estimator + signed agreement.

   • Add sections that mirror the main Estimator buckets (Services, Travel, Stipends/Events, Materials, Admin/Ops).

   • Turn time/expense tracking on/off per Appendix B.

   • Assign a Budget Owner (typically the PM).

9. Start work: log time and expenses to the right places: Staff and contractors log time to tasks within this project and to the correct budget sections (Services, Travel, etc.). Travel, stipends, and materials are coded to the budget sections that match the Estimator and funder/client rules.

10. Monitor vs Estimator assumptions: PM + DFO will periodically compare service days/time used vs estimated, travel and pass-through vs the original assumptions, and actual margin vs planned contribution. If the story diverges, go to E.4 Handling Changes instead of quietly absorbing overruns.

E.3 Handling Changes (Scope, Price, or Structure)

Things change. When they do, we want all three artifacts (Estimator, SOW, Productive) to stay in sync.

E.3.1 When to update the Estimator:

• The overall scope or structure changes (e.g. extra days added, delivery mode shifts, new trips, different staffing pattern).

• The price or discount changes in a way that affects margin.

• A previously informal “phase 2” becomes a formal extension or renewal.

In those cases, open the original Estimator file and create a new version (v2, v3, etc.) rather than overwriting the old one. Adjust scope, effort, and discounts to restore the margin floor and guardrails and then use the updated output to revise the SOW/contract and Productive budget.

E.3.2 When to issue a change order / contract amendment:

• The client requests more work than originally scoped (extra sessions, new deliverables, extended support).

• The delivery model changes in a way that affects cost (e.g. virtual → onsite with travel).

• Key assumptions in the SOW no longer hold (e.g. significantly more participants, added sites).

Process:

1. Update the Estimator to reflect the new reality.

2. Draft a short change-order or amended SOW:

   • What’s changing,

   • The new fee and/or terms,

   • Any new travel or pass-through expectations.

3. Get client sign-off before continuing work at the new level.

What we don’t do: quietly absorb major scope creep against the original budget.

E.3.3 How to adjust the Productive budget cleanly (per an approved change order):

1. Update the Productive budget to match the new Estimator/SOW:

   • Adjust section totals (Services, Travel, etc.).

   • If it’s a clear new phase, consider adding a separate budget section or, in rare cases, a new budget tied to the same project.

2. Document the change in the budget: Add a short note such as “Updated 2025-03-10 – Added 2 onsite days and 1 virtual follow-up per Change Order #1; Estimator v2.”

3. Communicate to the team: Let anyone working on the project know what changed and how it affects their time allocation, any travel, and the new guardrails.

4. Monitor the new plan (PM): Use the adjusted budget as the new baseline. If things drift again, repeat: update Estimator → adjust SOW → adjust budget.

Appendix F – Productive Tutorials Library

Purpose: This appendix points to OWL’s short video tutorials (Looms and other how-tos) for teammates who prefer to see Productive in action. It keeps the Playbook focused on rules and patterns, not step-by-step screenshots.

F.1 Where the Tutorials Live

All current Productive tutorials are stored in this folder. Note that this library is governed by OWL’s Document Control Policy, which means that old or superseded videos are clearly labeled or archived. When in doubt, start from this link rather than hunting for random Looms in Slack.

F.2 Recommended Starter Playlist

If you’re new to Productive at OWL or need a refresher, start with these:

• Intro to OWL’s Productive (10 min): Big-picture tour: projects, tasks/Kanban, time, budgets, and CRM.

• Working with Tasks and the Kanban Board: How to create good tasks, move them across lanes, use the Urgent tag under Priority Level, and prep for scrum.

• Time Tracking the OWL Way: How to log time to the right project/budget, and how to use container tasks for overhead and micro-work.

• Creating a Standard Budget from the Estimator: Walking through Estimator → SOW → Productive budget for a typical client engagement.

• Multi-Funder Budgets: How the WNCRP-style pattern works with project groups and per-funder budgets.

• Using CRM Deals the OWL Way: When a relationship moves from “idea” to “real opportunity” and how to set up and maintain deals in Productive.

Note that the exact titles may evolve; the tutorials library link should always list the current “starter set” at the top.

F.3 Maintaining the Library

To keep the library useful (and not overwhelming), the DFO (or a designated delegate) curates the Productive tutorial library. New Looms or how-to videos are added only when they replace or improve an existing tutorial, or cover a clearly missing, repeat-use topic.

Note: We don’t upload every ad hoc screen share into the library. The goal is a small, curated set of high-quality tutorials that match this Playbook, not a pile of unfiltered recordings.