Program roadmap process

These roadmaps can be visualized by industry, audience segment, product version, or even campaign. Technology roadmaps: A more granular roadmap variation designed for internal audiences, technology roadmaps usually support product roadmaps by showing key milestones for engineering and development teams. In other words, product roadmaps anchor the features that a product will need, and technology roadmaps anchor the steps required to develop those features.

Examples of such roadmaps include investment project pipeline or construction projects. The roadmap allows managers to plan and prioritize their resources accordingly.

Regardless of what roadmap variation is needed, each depends on the ability to be easily understood, updated, and distributed. Keeping roadmaps current and relevant is a key task for document owners, as siloed teams aligned on common objectives depend on it. Looking for a little help to get started on your next roadmap? Here are a few tips and templates for building in a data processor, business presentation tool, and project management tool. By their very nature, however, data processors can work perfectly for data-driven roadmaps.

Per-cell functions can help aggregate key data — like total weeks or months, or resource allocation — in a way that is easily understood. At its most aesthetic use case, a data processor can be leveraged for simple visualizations that show a clear timeline. If you need to break away from the industry-standard timeline approach, work board templates can also be used as a roadmap starting point.

Updating data processor roadmaps can be a manual process, however, so choose them thoughtfully. Their animation features and wide design palette allow for both creativity and distinctiveness. Such applications can be a powerful tool for executive vision roadmaps , especially for companies focused on a small number of critical objectives.

Figure 9: The program and individual projects each have their own icons indicating different types. Figure Adding a new row to our Roadmap. When clicking on Add row 1 on Figure 10 , we are presented a new side pane with a row name 2 , Owner 3 , and Connection option. If we choose a name for ourselves, we can give it any name that we find descriptive for the project. Figure Connect to a project sub menu, which contains both Project and Azure Boards options. On the next page, you will be informed about permissions that are required to connect the schedule.

Figure The permissions page for the automations. Figure I selected the Summary and Milestone in this example. Figure Our first project is now visible on the Roadmap. Please be aware that Roadmap is a tool that is designed to assist portfolio and program management activities.

Tasks and milestones are project management terms, but a program manager is more interested in the high-level progress of projects within a program. In Roadmap, we also have the option to include the whole schedule as one bar starting from the project start date and ending at the project finish date.

Be aware that because we used a different source to bring the project in, a different permissions approval is required. Figure The permissions page for a Project Online schedule automation. Because this option is in PWA itself, it is ideal for a project manager that needs to report up to the program manager.

After adding all projects to the Roadmap and including the relevant Phases and Key dates, we are ready to begin analyzing the program. Figure A Roadmap containing the main focus areas for the program with Mirjam as main contact Owner of progress. Next, include program specific key dates. These are apart from the schedules and the focus areas that we already have in our Roadmap.

A title, date, and status are all Roadmap needs to provide you with a new Key Date. The result of this action will be a little pin on top of the Roadmap, in the color that you set earlier as a status indicator. Because Mirjam the PMO is assigned to each Roadmap row for the five projects she is managing, she will be editing the individual statuses.

It is up to the organization to decide on this because a project manager can do this as well. Basically, everyone with access to the Roadmap can change the values, so decide on the protocol your organization will be following ahead of time. The only thing the PMO needs to do is update is the status of each row. This can be done using the menu that appears when clicking on an item.

The next two examples show more typical market rhythms for companies who must get their products ready for sale well before the annual holiday shopping season. Retail software companies release rarely during that period to avoid any potential disruption while toy makers realize the majority of their sales. Armed with the understanding of market rhythms, road mapping activities typically focus on the impact of market events. Figure 2 shows three types of events: the release of new regulations, expected moves of a competitor, and technology changes and upgrades.

Market events are typically represented as milestones and strongly impact the specific releases of a solution and may adjust the content and timing of features or solution development activities identified during Program Increment PI planning. Effective road mapping efforts require an understanding of the appropriate time horizon. If the horizon is too short, the enterprise may jeopardize alignment and the ability to communicate new future Features and Capabilities. Too long, and the enterprise is basing assumptions and commitments on an uncertain future.

Multiple planning horizons provide a balance Figure 3. The outer levels of the planning horizon are longer-term and describe behavior that is less defined and less committed, while the inner levels are nearer-term, defining better understood and more committed solution behavior.

From a road mapping perspective, the PI roadmap, solution roadmap, and the portfolio roadmap are the most relevant. These are described in the following sections. The portfolio roadmap illustrates the plan of intent for achieving the portfolio vision, primarily in the form of epics, over an extended period of time. Figure 4 provides an example of a portfolio roadmap. The portfolio roadmap integrates the aspects of solution and PI roadmaps and their milestones into a comprehensive view across all the value streams in the portfolio.

It builds the larger picture for communicating to the enterprise and to portfolio stakeholders how the portfolio vision is planned to be achieved over time.

It shows a coarse-grained view of the Epics within each value stream. Market events are represented as fixed date milestones at the top of the roadmap, while solution releases are depicted with small boxes. As the time horizon extends, the level of granularity and certainty is reduced. The first year is planned in quarters e. The second-year is planned in 6-month increments e. Anything beyond that is scheduled in years e. The solution roadmap shown in Figure 5 provides a multi-year view similar to a portfolio roadmap.

The key difference is that it depicts the planned epics and capabilities to be delivered over time for a specific solution within the portfolio. Since the solution roadmap, as well as the portfolio roadmap, may span multiple years, both require estimating longer-term initiatives.

However, every enterprise must be very careful about such forecasts. While many see long-term predictability as the goal, Lean-Agile Leaders know that every long-term commitment decreases the agility of the enterprise. There can be no Business Agility if the future is already fixed. Therefore these forecasts can and should be updated regularly to reflect new learning and changing market conditions.

Each element on the roadmap is a feature, capability or even an epic that is planned to be completed in a particular PI. The PI roadmap may also reflect fixed-date and learning milestones that occur during that period. Figure 6 illustrates a roadmap that covers three PIs.

That length is typically sufficient to communicate intent with stakeholders including business and partners. It is also short enough time frame to keep long-term commitments from interfering with the ability to flex to changing business priorities. This example roadmap consists of a committed PI, and two forecasted PIs, as described in the following sections. Since the business and technical context may change, planning subsequent PIs is less precise.

These forecasts are, however, based on prior execution. Given knowledge of the ART velocities, the PI predictability measure, relative priorities, and the history of how much work is devoted to maintenance and other business-as-usual activities, ARTs can generally lay the future features into the roadmap with relative confidence. Some organizations fill the forecasted PIs sparsely to show available capacity as shown in Figure 6 and create a more stable plan. Others choose to fill future increments closer to capacity to show a more complete, but likely less stable plan.

Lean-Agile Leaders must understand the queuing theory discussed in SAFe Principle 6 , avoiding large batches of work, which create long queues wait times. The math tells us that the longer the committed queue, the longer the wait for any new initiative. Necessary cookies are absolutely essential for the website to function properly.

These cookies ensure basic functionalities and security features of the website, anonymously. The cookie is used to store the user consent for the cookies in the category "Analytics". The cookie is used to store the user consent for the cookies in the category "Other.