You’re ready to build a roadmap if you’ve reviewed your project’s MVP or MMF and listed the features you need to achieve your goal. But unlike traditional project management, your roadmap isn’t a plan you will execute. Instead, it’s an opportunity to scout ahead and anticipate risks or alignments with other projects.
Your roadmap helps you identify any dependencies and areas where more research is needed. However, don’t let the need for more research stall the beginning of your project. Incorporate research into your plan, and be prepared to adjust as you learn more.
Now, we need to see if you can complete everything in the time you have, with the money in your budget, or with some other constraint that could require dropping a feature or facet of your project. We don’t want to go into more detail than this because we want to wait as long as possible so that when we provide more detail, we know as much as we can about what that detail should be. As we hit each milestone, we will learn more about our project, and we can tweak our roadmap.
When creating a roadmap, a helpful approach is to ask each team or group responsible for a task or milestone to estimate the time needed. Then, double those estimates. This approach often proves effective in accounting for unforeseen challenges or complexities.
Of course, if you’re experience is that your team is good at estimating how much time they need to accomplish something, then you might not have to double their estimates. However, roadmaps are also useful in setting expectations for your external audience, so modifying estimates helps you underpromise and over-deliver.
If your roadmap exceeds your project’s constraints, such as a grant’s duration, you may need to prioritize certain features or milestones by shortening or eliminating them. Conversely, if you have extra time, you can expand on existing milestones or allocate time for unforeseen discoveries. Additionally, you can designate some features as “stretch goals” to pursue if you complete higher-priority features ahead of schedule or under budget.
While this exercise may seem straightforward, it provides a solid framework for the rest of your project’s planning and execution.
Here’s an example of a roadmap I built years ago when I was the software architect for the Maryland Institute for Technology in the Humanities (MITH). We built the initial version of a WordPress plugin to transform content into Braille.
BrailleSC Calendar
The following schedule assumes 25% effort for … and 25% effort for … (100% = 40 hours/week)
BrailleSC Calendar
GitHub Setup (2 weeks)
Set up a GitHub repository supporting BrailleSC work, especially with WordPress Plugin and related sub-projects.
Library Requirements (3 weeks)
Research LibLouie and PHP to see how the two might be able to work together to produce English-to-Braille translations in a web environment, preferably using UTF-8 instead of alternate encodings.
Local LibLouie (4 weeks)
Create a PHP library that allows WordPress to use LibLouie without calling out to a remote service. The library should have a sufficiently flexible API to provide access to the affordances that surfaced in the previous research milestone. This library will be used in subsequent milestones by … as they develop the WordPress plugin properly. The PHP library should be a standalone package that can be installed on a system and used outside of WordPress.
WordPress Plugin Requirements (1 week)
WordPress Plugin Presentation (4 weeks)
Remote Library Requirements (2 weeks)
WordPress Plugin Configuration (3 weeks)
Remote LibLouie (4 weeks)
Local/Remote LibLouie and WordPress (5 weeks)
Plugin Publication (5 weeks)
Are you having trouble building a roadmap for your features? Schedule a free consultation, and let’s see what we can do.