The Production Plan is your execution roadmap: what you’ll ship, when, and with which resources. It complements the Design Doc by translating your concepts/designs into a feasible plan with dated milestones and iterative sprints with scheduled production time, test sessions, and analysis. Treat it as a living document to keep scope aligned with time, resources, facilities, and budget. Just as you might imagine a creative collaborator as the audience for your Design Doc (even if you're working solo), imagine a project manager when writing this one.
📦 Deliverables: Define the artifacts you will produce or performance you will deliver and share with your audience so everyone knows what "done" means. ℹ️
🗓️ Timeline: Lay out an iterative schedule with sprints and dated milestones that include play test/critique, testable criteria, and decision points for when/what to keep/edit/cut (or pivot). ℹ️
🛠️ Resource Assessment: List tools, software, equipment, spaces/facilities, collaborators, and funding. Note what you have vs. what you need, including lead times and booking windows. ℹ️
🧯 Challenges && Risks: Have a backup plan. Identify what can go wrong and how you plan to mitigate it so surprises don’t derail the project. ℹ️
💰 Budget: Provide line-item costs (materials, fabrication, printing, software, travel, space) and funding sources (even if it's self-funded or "in-kind") so nothing is overlooked and you ensure your scope is aligned with your resources. ℹ️
⨉
Deliverables
Define the key public-facing things you will complete during the project's development (and the individual pieces that defines each), explain what needs to be produced for us to consider the piece "finished." This does not mean the various documents you're producing for this class, rather this should be the work that an outside audience can actually experience. It may be the case, given the timeframe of the Capstone sequance, that what you produce is a v1 of something you plan to continue to iterate on beyond graduation, if so make clear what the minimum viable product (MVP) is going to be. If you're making a video game, maybe that's a polished vertical slice (a narrow representative piece/demo/level with final feel). If your creating a media performance maybe your goal is to produce a preview for a select audience at a private venue before a more public release after graduation. In any case, you should focus your list of deliverables on tangible outputs that represent a significant stage of completion, not just concept art or early-stage prototypes.
In addition to defining the form the work itself will take, the last item in your list of deliverables should be some form of documentation you can share in your portfolio (examples below). The final list of deliverables is going to look different for everyone, but here are some examples for reference you could model your list of deliverables on:
Video Game:
vertical slice (core loop, final look/feel on 2 levels)
public demo (downloadable, including tutorial and credits)
dev blog (5-10 posts covering process: concept, technical dives, art spotlights, launch reflections)
special preview (documented performance in private venue for an audience of 10-20 people)
Timeline
Provide a detailed timeline outlining key milestones for your project's development. Break the timeline down into phases (discovery/interviews, prototyping/testing, deployment/exhibition, etc) noting all key dates including our pitches to the faculty panel (week 9, the first week of December) and the MADD Expo (even though that's in the spring quarter, April 24). Make sure these are manageable periods which include some buffer for unforeseen challenges (things often take twice as long as we think they might, give yourself at least 20-30% of buffer time).
Structure your timeline around short sprints, 1-2 week periods which will include the creation of some prototype (each more developed than the last) with specific goals for testing at a scheduled critique/play test. Include time at the end for analyzing the results and planning the next sprint. We want to start this process as soon as possible, in their book Rules of Play: Game Design Fundamentals Katie Salen and Eric Zimmerman have a "straightforward rule of thumb regarding prototyping and playtesting games":
a game prototype should be created and playtested, at the absolute latest, 20 percent of the way into a project schedule. If a game is a two-week student assignment, the students should be playing a version of the game two days after it is assigned.Katie Salen and Eric Zimmerman
Considering that we've got roughly 23 weeks (Autumn and Winter, including the break) to finish our Capstone, you should be testing your first prototype by the end of October (week 4) and have a handful of sprints scheduled in total across the Autumn and Winter quarters.
Each sprint should end with a prototype you put in front of your target audience for testing and feedback. When you first construct your timeline you likely won't know every test you'll run yet, but the first version of your Production Plan must lock a plan for Sprint 1 (plans for future sprints can be defined in future revisions of this doc, remember it's a living document).
For each sprint, specify:
Prototype: What exactly will be ready to test, what is it meant to demonstrate?
Audience: Specifically who/how many will participate (classmates, club members, particular friends/family)? Recruit people who match your target audience from the Creative Brief.
Questions: 3–5 focused questions you need answered. These can be the literal moderator questions (for a focus group) and/or observation questions you’ll answer by watching behavior.
Format && Methods: Pick the format that fits the prototype (critiques are best for art installations; play tests are best for board games; running a focus group is great for a designed object; etc). Explain how you’ll gather evidence: an observation script or think-aloud notes, will you be timing folks, will you be filming them, surveys/interviews, recording device/browser matrics and/or other logs (never record anyone without consent).
Acceptance Criteria: Define pass/fail thresholds tied to your Evaluation Criteria (in your Design Doc). This should make clear how/what you’ll decide to keep, change, or cut. For example, you might say "If less than 50% understand the core interaction, redesign onboarding before adding new content" or "If less than 75% make the connection to X from the title, create variants to A/B test next sprint."
Make sure you schedule time at the end of each sprint to synthesize your findings, whether that's with affinity maps, a quick metrics review, and/or a short team debrief. Capture decisions in a brief change log (what to keep/change/cut or pivot), then update your living docs (Design Doc and Production Plan) and set the questions and plan for the next sprint.
Identify the key resources you'll need to execute your project. Start by identifying any tools you will need including equipment (camera, mics, projectors, snesors), fabrication tools (laser cutter, CNC, 3D printer) and software (open source or licenced). List out any materials/consumables from post-it notes to spcecial PCB compontents, list quantities and how you plan to aquire them (is this available on campus or will you need to order these?)
You should also identify any other people invovled in the production (play testers, collaborators, consultants, advisors) and specifically what you are asking them to commit to (how much time? what sorts of skills/services?). List out any physical spaces you will need access to (studios, sound booths, installation rooms, theaters, labs, rehersal space), and how you plan to aquire that access (Is this available on campus? Do you need to book in advance?). Lastly, if you have access to any funding (if you aquire a grant or similar support) list these as welll.
As you list your resources, it's worth calling out anythign that can block progress: material shipments, fabrication turnaround time, space booking approvals, collaborator schedules. Include "need-by" dates next to critical items and make sure this is scheduled in your timeline with some buffer.
Be specific about what is already available and what you still need to secure. This section will help you anticipate and plan for resource-related challenges. Refer to IDEO's Resource Assessment worksheet for more suggestions.
Challenges & Risk
Building on your Resource Assessment, we'll use this section to anticipate problems before they happen and how we plan to mitigate these risks. Something always goes wrong on large projects (that's normal), but it can be hard to predict what that might be. Start with a pre-mortem: go through each stage in your timeline and ask yourself "If this failed, what went wrong?" Work backwards from there to try to identify 5-10 potential risks. Then come up with a realistic contingency plan for each, this might mean having back-up plan in case something goes wrong but could also mean implementing back-up practices that help mitigate the damage when something inevitably happens. For example:
Technical issues like equipment breaking or loss of data due to corrupt file or damaged hard drive. Make sure you've got a plan B for important gear (even if it's not as good as your first choice) and make regular backups of important data, whether that's manually copying things to a thumb-drive or backing it up to a cloud service. You might also consider using some sort of version managment tools.
Often times projects run into logistics challenges, like equipment or space availability and fabrication/delivery delays. Make sure you've got a plan B for any spaces you need and give yourself enough lead-time and buffer for fabrication and deliveries.
Sometimes a collaborator may back-out at the last minute (espcially when they're not getting paid and have their own projects to work on), depending on their role, you might consider training an understudy, having soeone "on-call" or making sure there are other team-members that can fill-in.
Sometimes we can be very surprised by an audience's reaction (comprehension, accessability) to our work which can send us back to the drawing board on key aspects, here testing early and often helps to mitigate surprises around audience receptin.
Budget
We don't have a big studio, label or agency backing us, so we're likely going to be self-funding our capstone projects. Treat the budget as professional practice and planning, not just spending. List every likely cost, even if it's $0 because it's covered in-kind by university resources (MADD Center, Logan Media Center, etc.). For each item, note quantity, subtotal, funding source (self, in-kind, micro-grant, sponsor), and status (secured/pending). The goal here is to help you further clarify the scope and feasibility of your project and to help prepare you for future situations where budgets will be essential (like grant applications and project proposals).
Consider that you will have a chance to win a micro-grant after presenting your Pitch Deck to the MADD faculty panel on week 9 of the Autum quarter. A clear and realistic budget will strengthen your case for faculty micro-grants, because it proves you've thought through the costs and coverage.
FAQ
How do I turn it in?
Create either a doc on Google Drive and share it with me (nbiz@uchicago.edu), then submit a link to the doc on canvas. Canvas will be used to mark the assignment as "complete" or "incomplete." When an assignment is marked incomplete I will give you specific notes regarding what sort of revisions are needed in order to get a "complete." At times this feedback will be provided in person (in one-on-one meetings where you are expected to take notes) other times it will be provided online through comments on the doc.
Can I make revisions?
Moste definitely, this is a living document, meaning it will evolve as you learn from prototypes and critique/play test, it should be updated as needed. Each time you revise this doc you should include a version number and date at the top of the first page/slide, then resubmit the link to canvas for review, leaving a note describing what has changed and why (in a comment on the doc, @me).