Writing a TTRPG Project Plan
Project Managing for TTRPGs
TL;DR: Today’s post is step-by-step instructions, with a template and example, for writing a simple TTRPG project plan. I reflect on lessons learned when writing a project plan for Encounters.
This is part of a series on Project Managing for TTRPGs. Stay up to date by subscribing:
Project Plan? Project Plan.
A project plan is a document that explains what collaborators need to know about your project. What is the project, when is it happening, what will their role be, and so on, should all be covered in this plan.
While I get excited about this stuff, I feel like “Let’s write a project plan” might already be putting some of you to sleep. Here’s my pitch for why you should care:
Trust: My team told me that my project plan was the reason they trusted me as a project lead. When I was cold-emailing folks, I came off as professional and organized.
Expectations: A well-written project plan lays out what collaborators should expect from your project. If you don’t tell them what to expect they will either 1. Not join your project at all 2. Have different expectations which leads to pain and sadness down the line – this usually reflects poorly on you.
Calm before the storm: You get to make decisions, provide project structure, and ask folks to agree to things before you’re in the middle of the project and it’s crunch time.
The Template and Example
This post is meant to be exceedingly practical. First, grab the Project Plan Template:
Throughout, I’ll refer to a completed example of this template for Encounters in the Radiant Citadel:
Writing Your Project Plan
Step 1. What Are the Project Goals?
If you’re in charge of a team working on a project, it’s important to make and communicate goals for that project. Goals define what success looks like. Well-defined goals:
Are a quick way to describe what you’re all aiming for.
Act as a north star and can help with decision-making – if you’re not sure what to do or what to prioritize, you can go back to your goals.
Brainstorm Goals: To figure out project goals, ask yourself: “What does a successful version of this project look like? What are some ways I’ll know if it’s successful?” Jot down your answers to these questions.
Prioritize: Consider the relative importance of one goal versus another. Time, money, and personal-stay-up-till-2 am-energy are not infinite. If you can’t achieve all of these goals, are some more important goals than others? Order them.
Concision and Clarity: Express your goal in one clear sentence. At the end of the project, it should be unambiguous whether the goal was achieved. Limit this to 3-5 goals max.
The example shows Project Goals written in this style.
Further Reading: When I worked at Google, there was a culture of measuring and being very analytical about success. My examples above are a far shorter, dirtier version of goal-setting. If you want more in-depth guidance on goals, you can use frameworks like “SMART” goals (Specific, Measurable, Achievable, Relevant, Time-bound). Formats like this are important if you think you’ll ever need to report or prove something about your project-managing capabilities to folks who are not intimately familiar with you or your work (in the Google context, a director or VP with perhaps hundreds of reports).
Step 2. Define Roles and Responsibilities
In my humble opinion, this is the step that new folks running projects get wrong. A good leader knows how to coordinate, delegate, and empower – and as unsexy or simple as “role and responsibilities” sounds, it’s the first step in doing all three.
This is the part where you communicate what needs to be done and who’s going to do it. Here are some examples of what happens if you fail at this step:
There’s a task that nobody was responsible for so it didn’t get done or, oops, now you’re working at 2 am to finish it
It wasn’t clear who was responsible for a task, so whoops, two people did it
You were vague about what was involved in a task and, oh dear, someone did it completely wrong, and now they’re feeling extremely demotivated.
There was a task (which probably should have been a few smaller tasks), that you assigned a group of people to, and now nobody knows who’s ultimately responsible or gets to make decisions about how to complete the task. It’s a big ol’ soupy mess.
Roles and Responsibilities
First, some definitions:
A role is a job title you’ll give someone.
Each role has responsibilities. These tasks they “own” and are responsible for. Just because a team member is responsible for something, that doesn’t mean they need to do it completely alone or without help. It does mean if the task is done poorly, that person is accountable.
When you’re working on this section, ask the following:
What needs to be done? If you followed my advice about getting ready to collaborate, then you should know the steps involved in publishing TTRPG content. Write those steps down as tasks.
Who’s going to do it? Start matching those tasks to roles. For Encounters, I only defined two roles: the collaborators (a writer/editor role) and the project manager. Make sure you know who is responsible for every task on your list.
Is this task too big for one person? If there’s a task that’s too big for one person, either:
Split it into multiple tasks.
Assign one person who’s responsible (and good at coordinating) and then empower them with a mini-team to help them.
No, really, what needs to be done? Be specific. It’s great to encourage creativity and ingenuity in task completion, but if you have constraints, tell people before they’ve done the work. For a writing task, this should include a word count and any clarifications about the format.
Bad: “Write an encounter”
Good: “Write a 500-750 word encounter based on the Radiant Citadel theme, in a provided Google Document format, following the D&D 5e style guide and meeting the licensing requirements of DMsGuild.”
Optional Contributions
I wanted folks to treat the Encounters project seriously (hit deadlines, produce high-quality work, etc) and I knew that everyone on the team was balancing a mix of a full-time job, kids, and other responsibilities. This is a very different context from project managing folks who are all full-time co-workers. I wanted the workload to be reasonable and for nobody to feel tricked into doing more work than they agreed to.
So I added a new category of tasks: “Optional Contributions”. These were explicitly optional tasks and there was no pressure to do them. I decided what was part of the collaborator role was “required” based on the bare minimum I’d be happy with.
The example shows Responsibilities written in this style.
Lessons Learned: The Sign Off
When you’re creating something, there’s the person who makes the thing and the person who signs off on it (essentially confirms that the task was done correctly). Rarely is this the same person. Certain tasks might require multiple people to sign off. Here’s a TTRPG example: a writer creates a final draft of a D&D encounter, and then their editor and project lead could be the ones that sign off on it.
For Encounters, determining who and when sign off happened was honestly something that I bungled. The feedback for the editing and writing process was that contributors weren’t sure when something was done, or who needed to be happy with the state of an encounter for it to move on to layout. I will cover what happened here far more in-depth when I talk about collaborative writing and editing. The fact that folks didn’t know when something was done and I added on “sign offs” after the fact, was a clear sign I’d missed something in the planning phase.
For your project, determine which tasks need a sign off and who will do it. Also important, especially if folks are encouraged to give feedback, is communicating who doesn’t need to sign off on a task. Include this in your project plan.
Step 3. Draft Schedule
Once you’ve outlined what needs to be done and who’s doing it, it’s time to plan when it’s going to be done. A schedule is all the information in your roles and responsibilities section, with deadlines attached.
Determining reasonable deadlines is hard. Without writing a book on time management, here are some tips:
Gather information: Take a look at the calendar. Note any holidays and what’s going on in your life. Are there other work or personal projects? Do you have any big events coming up? Be aware of when you can’t devote your full energy to this project.
When you gather the rest of your team, you’re going to ask them to do the same and get feedback on the schedule – which is why I call this schedule a draft schedule.
Estimating how long tasks take: For Encounters, I used the pacing from the Write Your First Encounter workshop as a skeleton – most of my collaborators and I had done this workshop, so we had lived experience writing to similar deadlines. This is why doing a writing project yourself, before organizing a collaboration, is crucial. It’s another reason that I recommend starting small. If you can, look at a project you’ve done that’s similar to the project you’re organizing, and jot down how long each step took.
Full-time, trained, professional TTRPG writers are expected to write between 1000 - 1200 words a day (those estimates equate to 125 - 150 words an hour). The folks you’re working with are most likely not full-time trained writers. Let’s assume newbies work at half the 1000 words a day rate, and have 1 hour a day to write. For a 500-750 word encounter, that means giving them 8 - 12 days to write it. If you count outlining as writing time (which I do), then for Encounters we budgeted 18 days for writing.
Add padding: You (likely) aren’t psychic and there will be a task you didn’t account for or an unforeseen sickness. Take the original, reasonable deadlines based on your estimations, but also add a few days for padding. Then if folks need extensions you can accommodate them without a huge headache.
COMMUNICATION: Some collaborators will invariably run late. So you should ask yourself “What do I want a collaborator to do if they get sick right before a deadline or realize they have a wedding to attend during a crucial project crunch time?”
Write down what you want to happen in these cases, share it with your collaborators, and get them to agree. Then if something does come up, they know what to do and don’t spend time panicking about how to communicate to you that they might miss a deadline.
Note that for a project with more than two roles, you should add an additional column for who is responsible for the task instead of relying purely on color coding.
Lessons Learned: What we didn’t have time for
As you look at the example, here are two things I’ll change in the future:
Despite having a bit of padding, I was over-ambitious about what I could do by myself promotion-wise. Some of my amazing collaborators ended up graciously pitching in and writing social copy, posting it to Reddit, etc. I’m extremely grateful.
I didn’t budget time for playtesting (though a lot of us ran our own playtests). Having worked on other projects, playtesting is so important, so I would both add it to the core responsibilities and make time for it in the schedule.
Step 4. Code of Conduct
It sucks and is infuriatingly unfair, but about 50% of my friends have had serious, career, and life-altering incidents in the workplace, with a coworker doing something unacceptable to them.
If you’re in a leadership role in any space, have a code of conduct and processes in place. Make reporting and escalation processes known. Clarify what behavior is or isn’t acceptable on your team. Find collaborators that enthusiastically agree to the standards you set. Take questions from collaborators.
Teos Abadía wrote a standardized Code of Conduct specific for TTRPG projects that I used for Encounters. It’s free and it outlines some acceptable and unacceptable behavior. It also gives a process for reporting and handling incidents. You can download it on itch.io or DriveThruRPG and learn more here.
Step 5. Money and Legal Stuff
Include the basics of what collaborators should expect money-wise:
Where will you publish the product?
How will collaborators be paid?
What should collaborators know about ownership and licensing? For example, if you publish writing to the DMsGuild you cannot publish it elsewhere.
How will collaborators be credited?
What will be the price of the finished product?
I wrote a 3-part series on money that has information and a spreadsheet to help calculate and determine all of this. See A Pep Talk, Pricing, and Paying People
Other Categories
What I just listed – goals, roles/responsibilities, a schedule, code of conduct, and money – are the minimum parts of a project plan. Here are a few additional categories you can consider:
Technology and Communication: Do you have any technology requirements? For example, do collaborators need to use a specific writing software? On what platforms will you be communicating? I’ll dive into our decisions for Encounters in a later post, but the project plan is a great place to note any requirements for collaborators.
Vibes, touchstones, themes, systems: If you have a clear idea of what the writing and visuals should “feel” like to readers, the project plan is a great space to document this. Are there projects that are similar to the one you’re creating? Are there media touchstones that capture the vibe you’re going for? Do you have a mood board or playlist for your project? Are there cohesive themes or narrative goals for your project? Finally, is there anything you expect or want your collaborators to be familiar with, such as a rule system or specific lore? This is a great place to note that.
Risks and Mitigation: Is your project something new or risky that you haven’t done before? Is there a big risk or fear hanging over your head? If you answered yes, consider adding a risk and mitigation category. This was a section that was often included when project planning at Google. Think of all the things that could go wrong with your project. If you’ve got co-collaborators, you should ask them for their concerns. Once you have that list of risks, do the following for each:
Give them a priority: Determine both how likely the risk is to happen and how bad it would be if it does happen. Risks that are “likely to happen” and “very bad” if they occur are what you want to put more energy and thought towards.
Determine precautions and mitigations: Are there any precautions you can take to reduce, mitigate, remove, or get an early warning of the risk? For example, let’s say one of your writers has a big work assignment due at the same time as their writing work for your project. Mitigations could include giving that writer a few more days in the schedule to submit their work, teaming them up with an editor whose schedule works well with theirs, giving them less “project critical” work during that time, and/or scheduling additional check-ins with the writer.
What’s your plan B? Let’s say your mitigations don’t work, discuss with your team what you will do in that case. It’s a lot easier to do this decision-making when you’re not in the middle of a crisis.
This is a great time to get input and feedback from collaborators. Contributors can help both flag risks or offer creative mitigations. If you want to dive in deeper, this article provides a lot more guidance.
Conclusion
You should now have a simple project plan. You can use this document to reach out to collaborators and get them excited about your project. I’ll cover gathering a team in my next post, so stay tuned by subscribing:
In the meantime, if you’d like to support me, consider sharing this post or checking out some of my TTRPG projects, including Out of Luck (which recently got a Silver medal on DMsGuild) and Encounters in the Radiant Citadel (the now Electrum-medal-winning project that inspired this series).
Shout out to Taylor Navarro, an impressive project manager in her own right, for providing feedback on and editing this post.
Over and out,
- 🫙 👁️ 👁️
Thanks for sharing the tips and template! I especially liked the optional contributions idea. That was a new concept for me.