Tips & Tricks: A Guide to Project Proposals
Whether you’re presenting in front of publishers, fellow developers, professors, or students, talking about your next big idea can be a handful. There’s a bunch of stuff you need to include, but you don’t want it to be too long or boring, so you have to find the right balance without cutting out anything important. Even determining what is important and what isn’t can be a real challenge, and you definitely don’t want to over- or underwhelm the audience. If you’ve never made a project proposal before, it may seem difficult to find a starting point, so I’ve made this guide to help you nail both the actual proposal and the presentation.
Keep reading to learn more about making your own project proposals!
Before you even begin writing your project proposal, you should already have some documents, or at least ideas, about your game. If you haven’t already, you need to have plenty of research to support your game ideas, as well as some broad ideas on things like timelines, number of team members, estimated costs, etc. If you’re actually pitching a game to a studio, it’s very important to take these more business-centric thoughts into consideration. Once you have most everything figured out, I recommend compiling two documents before starting on the proposal: a one-pager and a research outline. Both of these documents should be very short and should only list the information that is important for the people you’re presenting to to know. A one-pager is just like it sounds: a one page document that simply lists bullet points of key game ideas, mechanics, and themes. You don’t need to include super specific information such as every character or ideas for every level; you want to keep everything short and to the point, and especially include things that will make your game stand out. The research outline is something I’ve never heard of people doing for project proposals in the industry, but I made one for mine and it definitely helped keep the business stuff clear and focused. Like the one-pager, the research outline should contain a bulleted list that outlines the major business and project management points. For mine, I included things like number of team members and their general roles, target audience for the game, timeline for completion, objectives, tasks, deliverables, and any research you found that would help support your game. If you like, you could even draw up a Gantt Chart to show the timeline for each task, objective, or milestone, although it’s not really necessary. This document is likely going to be a bit longer than the one-pager, but you still want to try to keep things short but specific. Once you’ve written up both the one-pager and the research outline, it’s time to begin writing your actual project proposal.
The Project Proposal
The actual project proposal is a document that describes all the essential aspects of the project you’d like to start. The length varies depending on the complexity of your game, but you should expect it to be longer than two pages, unless you have a really simple game. You can use the one-pager and research outline to help you write this document, as you’ve already listed everything you should include. Unlike the one-page and research outline, however, it’s important to detail everything out here. You want to write your proposal so that anyone reading it will know exactly what you want to make. Still, you don’t want to include information that would be better suited for a design document, so base it off of your one-pager and detail out each of the bullet points you listed previously. It will also help to incorporate your research to better illustrate your game’s development plan. If you didn’t include a Gantt Chart in your research outline, now would be the time to do it. The following is a general outline of sections that I included in my own project proposal. This is merely a guide, so feel free to add or subtract what you want, or come up with your own outline.
- Project Summary: This should include a basic overview of what will be needed to complete the project, such as the platform it’s being released on, as well as genre and any other pertinent information.
- Goal Statement: If you’re project has a goal, which it should, it should be stated here. Think of it sort of like the high concept in a design doc. This should only be one or two sentences long.
- Game Overview: This section should be a little more in-depth and should include all important information that explains what the game is. This is where you’ll be including most of the information from the one-pager.
- Game Mechanics: This is where you want to describe the important game mechanics that your game will feature. This should also draw from the one-pager.
- Team Members and Responsibilities: This section should describe the different team members the project will need and their general responsibilities. Don’t list specific names here.
- Target Audience: Your game should have a particular audience that would want to play it, so this should be explained here. You could also include some of the research you might have done on target audiences for your genre of game.
- Schedule Overview: This should describe the development cycle the project will undergo. You can start by listing out the different phases of development and then go into more detail about what should go on in them.
- Objectives/Milestones: Throughout the game’s development, there will be milestones you need to make, so those should be described here. If you already have specific dates in mind, you could list them here.
- Tasks: This should list out the specific tasks that need to be completed in order to meet each milestone.
- Gantt Chart/Timeline: Although it’s not absolutely necessary here, it would help to include a Gantt Chart here, but if you don’t have one, just describe a basic timeline the project needs to stick to. To make things easier, focus on milestones/objectives rather than tasks. If need be, you can create a new timeline with all of the tasks and when they need to be completed by.
- Deliverables: This should describe what will be obtained and/or created from this project. Since you’re making a game, you’d want to say that a fully playable, completed game is the final product, as well as explain why your project is worthwhile.
- Industry Impact: Since the release of your game is likely going to affect the industry, even if it’s in a small way, you want to describe how your game is going to impact the industry and other games in the same genre. This would also be a good place to explain what makes your game unique and how it could give you the upper hand against competitors.
- Game Summary: This section should be a quick sum-up of the game and your plans for development. There’s no need to include too many details since you should have described everything well enough above.
At first glance, the presentation may seem like the easiest part of the project proposal, but don’t be fooled; you’re going to be presenting in front of some important people and it can be extremely nerve-racking. Using the one-pager, research outline, and actual project proposal, you should be able to come up with a solid presentation in a program like PowerPoint, but showing off your skills in PowerPoint is only half the battle. It should be noted that you don’t want to make your presentation too flashy; there’s no need for crazy animations or absurd pictures, but that doesn’t mean it can’t look nice. When it comes time to present, try to stay calm and confident. It might help to rehearse your presentation beforehand so you can nail the real thing. If it’s a more professional proposal, you might need to have handouts of your proposal ready to go for the audience. Try your best not to read things straight from the slides and always try to make eye contact with everyone in the room. It’s also important to talk loud enough so everyone can hear you, and never ever put your hands in your pockets or mess with your cell phone. In fact, just leave your cell phone off and in another room or in your bag, if you can. You should also dress appropriately, which will usually mean no t-shirt and jeans. If you’re not feeling too nervous, try to maintain good posture and maybe even walk around a bit to keep the audience focused on you and not the slides. As fantastic as your PowerPoint may be, you need to sell them your idea, so don’t rely too heavily on your presentation.
After you’ve given your presentation, it’s likely going to be time for feedback. This could occur at the end of your presentation or at a later time or date, so it’s important to be prepared either way. When you do receive feedback, try to stay relaxed and just listen. It’s perfectly fine to try to defend your proposal, but don’t take things too far and never make it seem like you’re attacking the audience. Remember, these might be the people who are going to let you make your next big hit, but if you don’t treat them with respect, they’re probably not going to approve of your project. If someone gives you negative feedback, which they will, just thank them for their advice and move on; there’s no reason to get upset if someone doesn’t like your idea. No matter how your feedback turns out, always be sure to thank the audience for their time and feedback. Once you get back home, actually take their feedback into consideration. If you were approved, you might want to jot down the recommendations they made and add them into your game. If you were denied, don’t get discouraged; think of this as a learning opportunity so you know what to expect next time and how you can improve.
I haven’t presented very many project proposals, so this is still a bit new to me. If you have anything you’d like to add, please feel free to let me know by commenting below. Thanks for reading!