• Introducing Project Roadmaps
• Milestones
• GitHub Projects
• Prototyping
• User Testing
• Assignment: Make A Project Roadmap

Introducing Project Roadmaps

When you’re starting an open project (or restarting a project, or starting a new phase of a project), it’s important to outline and plan for the work ahead and share that plan with any potential contributors. We’ll do this using a text document we’ll call a “roadmap, ” Like a road map you’d use while traveling, this document will help to identify where you are now and how to reach your project’s end goal, as well as the course that you will need to take to get there. Your roadmap summarizes your vision and includes a timeline for tasks. This a great tool for you– it helps you schedule work and track goals– but it’s key for anyone who might contribute to your project, so they know what’s currently happening on the project, and what’s next.

As you make your Roadmap, you may realize there are dependencies among different tasks. For example, you might need to define the structure of your database before you decide on a strategy for searching it, or you might need to secure a venue for an event before you decide the number of sessions or speakers you’ll invite. Creating a Roadmap helps you get a sense of not only all the steps that have to be done on a project are (there are always more than we anticipate), but also how to schedule tasks and plan work efficiently.

Check out this example Roadmap from the STEMM Role Models project.

Milestones

The timeline of tasks is the probably most important part of the Roadmap so as a warm-up exercise, you’ll decide on project milestones which are significant turning points or events that will move the project forward. Review the different types of milestones outlined below, and decide which ones are most appropriate for the kind of work you’ll do on your project.

• Project Status Goals. If you’re creating a software project, a milestone could be completing a specific feature or a release (see the section on Prototypes, below).
• Dates. If you have deadlines or a set span of time to work on this project, use those dates as milestones. If you’re working in formal education, dates in the academic calendar can be natural milestones.
• Events. If your project will be demoed or shown at an event or conference, or if your project involves planning an event, then you’d want to create milestones around that event, for preparation (such as sending invites, arrange for space, etc), running the actual event, and follow-up after the event. (more or events and convenings in section X.
• Timeframes. If your project is a longer, ongoing effort and you don’t yet have any hard deadlines, you may want to create short, medium and long term milestones.
  • Short term - tasks you are working on now
  • Medium term - tasks that are coming up next
  • Long term - where your project is going, beyond the next few weeks or months

GitHub Projects

Another way to track your project’s progress is use to use GitHub’s Projects. This feature allows you create kanban-style boards to manage tasks, take Notes to quickly add tasks or reminders to your project which can be converted to Issues when you’re ready.

It’s found here:

Examples:

• Bootstrap Project

Prototyping

As you plan your project, you might want consider when you’ll create and test prototypes. A prototype is an early, unpolished version of your project or a feature of your project, created specifically for testing purposes. Prototyping is the act of testing a feature or solution by building or making a rough or mocked-up version of that feature. It’s important to note the difference between a prototype and an MVP (Minimum Viable Product). The MVP is a stripped down but functional version of your project that’s ready for use. The prototype is often incomplete, and not for real-world use, long term use or distribution.

Protyping small, testable iterations of different features of your project is a great way to manage time and resources. It allows you to break down a larger project into a series of achievable tasks. Testing helps ensure that a feature is successful before you move on to the next task, so you don’t spend time refining something that’s not viable. Since prototypes are not designed for long term use, they come in all forms: you could make a prototype of a user interface, a workflow, or a game mechanic by drawing on sheets of paper. You might prototype in code and make a very simple, un-designed, partial version of an app to test some very basic functionality. You might sketch out a draft lesson plan and mock up some materials for a workshop. Often in a project you will make several prototypes, each modified according to feedback or lessons learned from the previous version. You may try several different prototypes represent different directions for the project. It’s OK if something you do doesn’t work out! These “failures” are actually learning experiences that will improve your final product.

User Testing

No matter what form your prototype takes, it should be something users can react to, and their feedback should help answer questions or define a direction for further work. When you’re ready to test with users, it’s great to have a that specific question in mind. For example, you might want to know if users can easily find the search function in your interface, if the instructions for a workshop activity or game you’ve devised are complete and make sense, or if a tagging function in your app is working properly.

You don’t have to test your prototype with hundreds or even dozens of people, even talking just a to a handful of people is useful. It’s always best to test with people who are potential users, who’d might have an actual interest in using your project when it’s done. User testing sessions can be as simple as sitting down with someone who is not familiar with the project, providing them with the prototype, observing how they use it, and then asking a few questions and listening to their feedback. If your project is easily shared online, you might invite lots of people from your community to test, and ask them to fill out a feedback survey. User testing is great for both your project and your testers. Your users get a better product because they can give feedback on the design. And by showing your project to users early on, you generate buzz about your work and prime your testers to use the eventual, finished product. Some of your testers may be so excited about the project that they decide to become contributors!

Assignment: Make A Project Roadmap

1. Write your “Project Mission & Summary.” Start with the project name along with a shorted version of your project description from the readme, or you can use your vision statement. Since this is key information that all contributors need to understand, it’s okay for some it to be repeated in different places, in different documents.

2. Pick 1-3 milestones. Depending on your project, milestones can vary: they may be related to software development goals, learning resources you’ll create, events or meetings you plan to hold, campaigns you’ll run.

3. List tasks to complete for each milestone. Write a short description of each task required to successfully complete project work on a milestone. Depending on your project, these might be items like: “Research existing Javascript learning resources for kids” or “Publicize the October Online Privacy Meet-up” or “Implement a new visualization scheme for the user-facing badges.” Be sure to time here to explain why you are doing this task. This will reinforce your vision for the project and help others see why each step is meaningful in the larger timeline.

4. Let people know how they can get involved. As mentioned in the readme section above, this is where you’ll link to contributor guidelines.

5. Post your Roadmap. You’ll want to put your roadmap online where your potential contributors can find it, and let people know it’s there. If you already have a project website or a repository on a web-based collaboration tool like GitHub, these are excellent places to post your Roadmap. If you don’t have an online presence yet, don’t worry! We’ll cover GitHub in the next section!

6. Update often! The direction of your project will change as the work evolves. Return to your roadmap frequently to update, add or change milestones, and track your progress! You may want to welcome supporters or key participants into any conversation about Roadmapping, as a way of increasing their participation and sense of ownership of the project.

Now, armed with a great project description and a plan for what you’re going to do, you’re ready to consider the community of contributors that you hope to develop around your open project.

next: Building Communities  

Help us improve content and suggest changes to this page.