Program Roadmaps

All programs are expected to have 12 month roadmaps. Ideally these roadmaps are kept updated - "evergreen"; it's good practice for programs to update them at least once a quarter. At a minimum, programs are expected to update their roadmap once a year, as part of reviewing the past year's progress and planning the year to come, though strongly encouraged to be iteratively updating the roadmap throughout the year.

Programs are afforded discretion and independent in the format of the roadmap that works best for their programs, and the component projects and working groups within the program. FINOS recognizes that some programs have tight interdependencies between some or all of its projects and working groups, while in other programs, projects and working groups work largely autonomously from each other.

What should be in a roadmap? We recommend that the roadmap include the following:

• A summary of the product / release roadmap of each of the respective programs and work groups. What's on the "to do" list for the next year? What does the team in each project and working group want to take one? What are some of the bigger features in the backlog that the project team intends to take on (and when) in the coming 12 months?
• Across projects and working groups what are the major releases of code, standards, etc. for public consumption and production system use? Releases may also include things like a best practices library, a process model, a legal or talent template policy, or a white paper. What sort of support will the program require in terms of product marketing from the foundation team?
• Where are their emerging product and technology opportunity that might warrant starting a new working group or project and/or soliciting new contributions and contributors 

Roadmap Example 1: Confluence Template

Roadmap Example 2: Quarterly Grid