Build a Platform Engineering Roadmap

Build a six-quarter Jira roadmap with scenarios and leadership reporting.

Introduction

30 Second Summary

Long-range plans often look achievable until urgent support work collides with strategic delivery. Without clear trade-offs, leaders can approve more work than the team can realistically finish.

In this project, you will build an 18-month automation and platform engineering roadmap with Jira Plans and Confluence Cloud. It will expose delivery trade-offs across six quarters before leaders approve commitments.

What You'll Build

The finished Confluence page shows a live six-quarter plan that answers what can be delivered, what is blocked, and what needs a leadership decision.

By the end of this project, you'll have:

Track the VM build portal, Red Hat Ansible Automation Platform adoption, rightsizing, certificate automation, Kubernetes and OpenShift evaluation, plus Microsoft 365 Copilot connectors discovery across a live six-quarter roadmap.
Compare baseline and BAU-surge scenarios to see which milestone moves when support demand rises.
Present a leadership-ready view with current decisions, named risks, measurable outcomes, and a clear review cadence.
Secret Mission: add a procurement decision gate that prevents Kubernetes and OpenShift adoption work from appearing committed before evidence and approval exist.

Are there any prerequisites?

You need Jira Cloud Premium or Enterprise access with permission to create or edit a Jira Plan. You also need access to an approved Automation team work source plus permission to create a Confluence page.

Before We Start

A useful 18-month roadmap helps leaders make trade-offs instead of promising every initiative at once. Before the planning begins, you will define who needs this roadmap and which portfolio decision it must support.

Set Up the Planning Workspace

Your roadmap decision statement defines the trade-off that leaders need to make. The roadmap now needs a safe operating home where planning changes can be tested without silently changing live work.

Jira Plans in Jira Cloud gives you a sandbox timeline. Confluence Cloud gives the strategy a stable draft home.

In this step, get ready to:

Validate access to Jira Plans.
Create the sandbox Jira Plan from an approved work source.
Create the Confluence strategy page as an unpublished draft.

Why use both tools?

Jira Plans keeps roadmap dates connected to existing work. Its sandbox lets you test planning changes before saving them to Jira work items.

Confluence Cloud holds the executive narrative. The two tools connect delivery detail with leadership context.

Validate Jira Plans access

Sidebar visibility is the first access check. The + control confirms whether your role can create a Plan.

Open your organization's Jira Cloud site in a browser.
Sign in with your organization account.
Inspect the left sidebar for Plans.

✔️ I see Plans and the + icon

Select Plans in the left sidebar.
Confirm the + icon appears next to Plans.

The sidebar is available. The create control confirms your Plan creation access.

ⓧ Plans is hidden

A hidden Plans item can be a sidebar preference. Customizing the sidebar changes your navigation without changing production permissions.

Select More in the Jira sidebar.
Select Customize sidebar.
Select Plans.
Return to the Jira sidebar.
Confirm Plans now appears.
Check for the + icon next to Plans.
Record a missing create control in the access checkpoint below.

ⓧ I cannot create a plan

Your account can reach Jira Plans without having permission to create a Plan. This is an access gap that your organization must review.

Record the missing Plan creation permission in the access checkpoint below.
Stop before changing any production permissions yourself.

Create the sandbox Jira Plan

A work source brings existing Jira items into the Plan. The Plan sandbox keeps draft planning changes separate from live Jira work.

Select the + icon next to Plans.
Enter Automation Platform Roadmap | 18 Months as the plan name.
Choose the Automation team's existing board or approved planning work source.
Set plan access to the smallest approved audience that includes the roadmap collaborators.
Select Create.

You now have a safe planning shell. The timeline should display work from the selected source.

Why use a board work source?

Boards include the sprint information that Jira Plans needs for capacity planning. Using the Automation team's approved board keeps future roadmap decisions connected to existing work.

Keep the Plan inside its sandbox by leaving Save changes unselected.
Leave the Jira Plan open in its current browser tab.

Plan creation blocked?

Record the missing role or work-source permission through your organization's approved access process.
Wait for approved access before creating or changing production work.

Help me diagnose the missing access.

Create the Confluence strategy draft

The Confluence draft becomes the stable home for the roadmap narrative. Keeping it unpublished protects an incomplete strategy from premature circulation.

Open a new browser tab.
Go to your organization's Confluence Cloud site.
Sign in with your organization account if prompted.
Select Create in the Confluence toolbar.
Choose a page as the content type.
Enter Automation and Platform Engineering Strategy | 18 Months as the page title.
Keep the page unpublished as a draft.

The strategy title should now be visible at the top of the page. The page should remain in its draft state.

Cannot create the draft?

Record the missing Confluence page permission through your organization's approved access process.
Keep the Jira Plan tab open while the access gap is resolved.

Help me identify the Confluence permission gap.

Before you compare the tabs, what should each artifact show if the planning workspace is ready?

Return to the Jira Plan tab.
Inspect the Plan name.
Inspect the work shown on the timeline.
Return to the Confluence draft tab.
Inspect the page title.
Inspect the page's draft state.

Jira should show the Automation Platform Roadmap | 18 Months timeline with work from the selected source. Confluence should show the unpublished draft titled Automation and Platform Engineering Strategy | 18 Months.

Keep both artifact tabs open for the next step.

Good work. Your Jira Plan and Confluence draft are ready for the outcome themes you'll build next.

Define Outcome Themes

The sandbox in Jira Plans is ready for delivery work. Your draft in Confluence is ready for the strategy behind that work.

A list of tools and projects does not explain why the Automation team is investing in them. Outcome themes give each initiative a measurable result plus a clear strategic home.

In this step, get ready to:

Write a mission statement that defines the roadmap's strategic direction.
Create five six-quarter themes with measurable outcomes.
Map each initiative once while identifying decision-gated work.

Write the roadmap mission

The mission statement gives every roadmap choice a shared purpose. It keeps later discussions focused on operational outcomes.

Switch back to the Confluence draft from the previous step.
Place your cursor beneath the page title.
Type this mission statement: reduce manual infrastructure operations while increasing self-service, governance, lifecycle control, and trusted operational knowledge.

You should see the mission statement directly beneath Automation and Platform Engineering Strategy | 18 Months. That sentence now gives every theme a reason to exist.

Build the five theme rows

Each theme needs one primary outcome plus one metric definition. A single accountable team or role makes ownership visible across the six-quarter horizon.

Why use outcome themes?

A project list shows activity. Outcome themes show the change that activity should produce.

Keeping the roadmap to five themes gives leaders a compact decision view. One primary outcome plus one metric keeps each theme focused.

Self-Service Infrastructure. Primary outcome: Standard VM requests move through governed self-service. Metric definition: The percentage of eligible VM build requests completed through the portal without manual build steps.
Automation at Scale. Primary outcome: Teams reuse governed automation for repeatable infrastructure operations. Metric definition: The percentage of in-scope automation runs that use approved reusable content.
Platform Readiness. Primary outcome: Leaders receive enough evidence to make a platform go, pilot, or pause decision. Metric definition: The percentage of required decision evidence completed before the gate review.
Lifecycle Optimisation. Primary outcome: Infrastructure teams turn workload evidence into approved rightsizing actions. Metric definition: The percentage of assessed workloads with an approved rightsizing action completed.
Operational Intelligence. Primary outcome: Approved operational knowledge becomes easier to find without weakening source permissions. Metric definition: The percentage of approved knowledge sources that meet connector quality plus permission criteria.

Use the editor toolbar's table control to add a table with seven columns plus six rows.
Enter Theme, Primary outcome, Metric definition, Accountable team or role, Horizon, Initiative mapping, plus Delivery status in the first row.
Fill the five theme rows with the primary outcomes plus metric definitions from the guide above.
Enter one actual accountable team or role in each owner cell.
Set every horizon cell to Quarter 1 to Quarter 6.

You should now see five distinct theme rows beneath the mission statement. Each row has one outcome plus one way to measure it.

Map each initiative once

Initiative mapping connects the worklist to the strategy. It also keeps evaluation work visible before leaders make delivery commitments.

The operational intelligence stream explores Microsoft 365 Copilot connectors through discovery. Any rollout remains conditional until its decision gate is complete.

Initiative Mapping Guide

Self-Service Infrastructure. Initiative mapping: VM build portal. Delivery status: Candidate delivery.
Automation at Scale. Initiative mapping: Red Hat Ansible Automation Platform adoption and governance. Delivery status: Delivery using available capability.
Platform Readiness. Initiative mapping: Kubernetes and OpenShift vendor evaluation. Delivery status: Decision-gated. No committed delivery.
Lifecycle Optimisation. Initiative mapping: rightsizing. Delivery status: Candidate delivery.
Automation at Scale. Initiative mapping: certificate automation. Delivery status: Discovery and approval before delivery.
Operational Intelligence. Initiative mapping: Microsoft 365 Copilot connector discovery. Delivery status: Discovery. Rollout decision-gated. No committed delivery.

Enter the six initiative names in the corresponding theme rows.
Enter the delivery status shown for each initiative.
Keep every initiative mapping to a single occurrence in the table.
Leave the Confluence page as an unpublished draft.

Before you review the table, do you expect all six initiatives to appear exactly once?

Count the theme rows to confirm that there are five.
Check that every theme row contains one primary outcome.
Check that every theme row contains one metric definition.
Check that every theme row names one accountable team or role.
Check that every theme row covers Quarter 1 to Quarter 6.
Count the initiative mappings to confirm that all six named initiatives appear once.
Confirm that the Kubernetes and OpenShift evaluation says Decision-gated. No committed delivery.
Confirm that the connector status says Discovery. Rollout decision-gated. No committed delivery.

You should see five completed themes plus six unique initiative mappings. The two future platform commitments are visibly controlled by decision gates.

Your roadmap now has a strategic spine. Next, you will place the initiatives across six quarters to reveal where the preferred dates collide.

Build the Six-Quarter Timeline

Your strategy draft now gives every initiative a measurable home. The next test is whether those ambitions can coexist on one timeline.

A date-first roadmap can turn every request into a promise before the team has tested whether the schedule is possible. Jira Plans provides the shared timeline for building that first draft.

In this step, get ready to:

Create roadmap-level work items for the six strategic initiatives plus BAU automation support.
Add visible outcomes and schedule every stream across six quarters using preferred dates.
Expose the initial timeline collision and record the credibility gaps in the strategy draft.

Create roadmap-level work items

Roadmap-level work items keep the plan focused on major streams of value. Detailed delivery tasks remain in the approved work source beneath this portfolio view.

Use + Create work item to add VM build portal at the roadmap level used by your plan.
Use + Create work item to add Ansible governance and reusable automation at the same level.
Use + Create work item to add Rightsizing at the same level.
Use + Create work item to add Certificate automation at the same level.
Use + Create work item to add Kubernetes and OpenShift platform evaluation at the same level.
Use + Create work item to add Microsoft 365 Copilot connector discovery at the same level.
Use + Create work item to add BAU automation support at the same level.

Strong start. Your sandbox plan now holds seven separate portfolio streams without changing live Jira work.

Missing a roadmap-level option?

Jira hierarchy names can differ between sites. Use the highest existing work-item level approved for this plan without adding a new hierarchy level.

If you cannot create a work item at that level, record the permission gap for the plan owner. Help me identify the correct roadmap level in my Jira Plan.

Add milestones and preferred dates

A visible milestone makes each schedule bar answer a clear delivery question. The outcomes already mapped in your Confluence draft provide the wording for those milestones.

Edit VM build portal so its mapped outcome appears as a visible delivery milestone.
Edit Ansible governance and reusable automation so its mapped outcome appears as a visible delivery milestone.

You can now see a concrete outcome attached to both self-service and reusable automation work.

Edit Rightsizing so its mapped outcome appears as a visible delivery milestone.
Edit Certificate automation so its mapped outcome appears as a visible delivery milestone.

The two lifecycle streams now show what each schedule bar is expected to achieve.

Use a visible decision outcome for Kubernetes and OpenShift platform evaluation so the row reflects its decision-gated status.
Use a visible decision outcome for Microsoft 365 Copilot connector discovery so the row reflects its decision-gated status.

The evaluation streams now end in decisions that leaders can assess. They do not claim that rollout has already been approved.

This first schedule uses the timing currently preferred by stakeholders. Its purpose is to show the portfolio request before feasibility is tested.

Set the preferred start and finish for VM build portal using its date fields or schedule bar.
Set the preferred start and finish for Ansible governance and reusable automation using its date fields or schedule bar.
Set the preferred start and finish for Rightsizing using its date fields or schedule bar.
Set the preferred start and finish for Certificate automation using its date fields or schedule bar.
Set the preferred start and finish for Kubernetes and OpenShift platform evaluation using its date fields or schedule bar.
Set the preferred start and finish for Microsoft 365 Copilot connector discovery using its date fields or schedule bar.
Set the preferred start and finish for BAU automation support using its date fields or schedule bar.
Leave at least one quarter with three major strategic streams visibly overlapping.

You should now see dated bars for all seven rows spanning Quarter 1 through Quarter 6.

Schedule bar missing?

Check that the work item has both a preferred start and finish. A row without a usable date range cannot appear across the timeline.

Confirm that the item sits within the plan hierarchy shown by your current view. Help me find why a scheduled work item is missing from my Jira Plan timeline.

Reveal and record the collision

Before you switch views, do you think the preferred-date plan will look achievable when every major stream is visible together?

Select Top-level planning view in the sandbox Jira Plan.
Set the timeline timeframe to quarters.
Inspect the quarter where at least three major strategic streams overlap.

You will see all six strategic initiatives plus BAU across the six-quarter horizon. At least three major streams compete for time in the same part of the plan.

That collision is intentional. The schedule exposes unprotected BAU plus shared specialists plus missing procurement gates plus commitments that lack supporting evidence.

Leave Save changes untouched so the preferred-date schedule remains in the Jira planning sandbox.
Switch back to the Confluence strategy draft from earlier.

Add a section titled Initial timeline collision below the initiative mappings.
Add Unprotected BAU as the first finding.

The strategy page now identifies the demand that the first schedule has failed to protect.

Add Shared specialists as the second finding.
Add Missing procurement gates as the third finding.

The collision record now captures both the people constraint and the unresolved approval path.

Add Initiatives presented as commitments before evidence exists as the fourth finding.
Keep the Confluence page as an unpublished draft.

Before the final check, which artifact do you expect to show the collision visually? Which artifact should explain why the collision matters?

Return to the sandbox Jira Plan tab.
Confirm that Top-level planning view remains selected.
Confirm that the timeline remains grouped by quarter.
Confirm that all seven rows span the six-quarter horizon with at least three major streams overlapping.
Switch back to the Confluence strategy draft.
Confirm that the collision section contains all four findings.

Jira now shows the preferred-date roadmap across six quarters with a visible overlap between at least three major streams. Confluence records unprotected BAU plus shared specialists plus missing procurement gates plus premature commitments.

That first draft has done its job. Next, you will protect BAU and sequence the strategic work so the roadmap reflects real capacity plus cross-team constraints.

Protect BAU and Sequence Work

Your first six-quarter timeline exposed the collision it was meant to reveal. Preferred dates currently treat every initiative as equally deliverable.

This step protects business-as-usual (BAU) demand inside Jira Plans. Missing workload evidence remains visible through low-confidence notes.

Dependencies expose sequencing constraints. Scenarios show which lower-priority milestone moves when BAU rises.

In this step, get ready to:

Represent operational demand across all six quarters.
Link strategic work to every prerequisite or decision gate.
Compare the baseline against a BAU-surge scenario.

Model BAU and technical debt

BAU consumes delivery capacity throughout the roadmap. Technical debt also competes for the specialists assigned to strategic work.

Recent actual workload anchors this demand in evidence. The team's existing estimation unit keeps the new demand comparable with current planning data.

Why use recent workload?

A universal BAU percentage can hide how this team actually spends its time. Recent workload gives roadmap owners a starting point they can challenge with evidence.

Low-confidence notes keep uncertainty visible where the available history is incomplete. Assumptions stay open for review instead of becoming silent commitments.

Switch back to the Jira Plan from earlier.
Select the existing BAU automation support work item in Top-level planning view.
Extend its schedule bar from Quarter 1 through Quarter 6.

You'll see BAU remain visible across the complete roadmap horizon.

Add a six-quarter demand breakdown to the BAU work item using recent actual workload in the team's existing estimation unit.
Add Confidence: low beside any quarter where workload evidence is missing.

The BAU item now shows evidence-based demand for every quarter. Any weak evidence is clearly marked for later validation.

Add a roadmap-level work item named technical debt by selecting + Create work item.
Extend the technical debt schedule bar from Quarter 1 through Quarter 6.

You'll see technical debt beside BAU throughout the six-quarter timeline.

Add a six-quarter demand breakdown to the technical-debt work item using recent actual workload in the team's existing estimation unit.
Add Confidence: low beside any quarter where technical-debt evidence is missing.

That is the capacity baseline in place. The timeline now shows operational demand across every quarter.

Link work to dependencies

A dependency turns an assumption into a visible scheduling constraint. Each prerequisite needs a linkable work item inside the Plan.

The link direction shows which item controls the sequence. Incoming dependencies use is blocked by. Outgoing dependencies use blocks.

Add a roadmap-level work item named Server Support and Infrastructure handoffs by selecting + Create work item.
Add a roadmap-level work item named Infrastructure and DBA data by selecting + Create work item.

You'll see two cross-team prerequisites appear on the timeline.

Add a roadmap-level work item named certificate ownership and authority approval by selecting + Create work item.
Add a roadmap-level work item named platform procurement by selecting + Create work item.

You'll see the certificate approval prerequisite beside the platform procurement gate.

Add a roadmap-level work item named security or data-governance approval by selecting + Create work item.

All five prerequisite areas are now available for dependency linking.

Add an is blocked by relationship from VM build portal to Server Support and Infrastructure handoffs using the work item's dependency controls.
Add a blocks relationship from Infrastructure and DBA data to rightsizing using the work item's dependency controls.

You'll see dependency lines connect the VM portal to its handoffs. Rightsizing now follows the availability of infrastructure data.

Add an is blocked by relationship from certificate automation to certificate ownership and authority approval using the work item's dependency controls.
Add a blocks relationship from platform procurement to Kubernetes and OpenShift platform evaluation using the work item's dependency controls.

Certificate automation now follows ownership approval. Platform evaluation now follows procurement.

Add an is blocked by relationship from Microsoft 365 Copilot connector discovery to security or data-governance approval using the work item's dependency controls.
Move every dependent schedule bar so its start follows the linked prerequisite or decision gate.

You have turned five assumptions into visible constraints. The roadmap now shows why dependent work must wait.

Can't add a dependency?

Confirm both work items belong to a work source included in the Plan. Use the approved roadmap level already established in this sandbox.

Custom hierarchy settings can change where dependency controls appear.

Help me link two work items in my Jira Plan.

Create baseline and BAU-surge scenarios

A scenario is a separate Plan variant for testing possible outcomes. It lets you compare the balanced roadmap with higher BAU demand while live Jira work remains unchanged.

Keep Live Jira Work Unchanged

Draft Plan changes remain in the sandbox until you write them back to Jira work items.

Keep Save changes untouched until stakeholders review the roadmap.

Select More actions (•••) next to the Plan name.
Select Plan settings.
Select Features.
Turn on Scenarios.

You'll see scenario controls become available in the Plan.

Create a scenario named baseline using the scenario controls.
Create a second scenario named BAU-surge using the scenario controls.

The Plan now has two variants for comparing capacity choices.

Confirm the BAU-demand increase with roadmap owners using recent workload evidence.
Record the agreed increase here: your agreed BAU-surge assumption.
Confirm the lowest-priority strategic item with roadmap owners.
Record the selected item here: your lowest-priority strategic item.
Apply your agreed BAU-surge assumption to BAU demand in the BAU-surge scenario.
Move your lowest-priority strategic item to the first quarter with enough remaining capacity.

The surge variant now makes the capacity trade-off visible without removing BAU from the roadmap.

Adjust any dependent work that now starts before its prerequisite or decision gate.
Confirm the Plan remains in Top-level planning view with the timeframe set to quarters.

Before you compare the scenarios, which lower-priority milestone do you expect the extra BAU demand to move?

Select the baseline scenario.

You'll see BAU demand throughout the six-quarter timeline. Strategic work remains sequenced after its linked constraints.

Select the BAU-surge scenario.

You'll see at least one lower-priority strategic milestone move later. BAU remains visible across all six quarters.

Dependent work stays after its prerequisite or decision gate. You've turned the overloaded draft into a defensible sequence.

Scenarios Not Available?

Return to Features inside Plan settings. Confirm Scenarios is turned on for this Plan.

If the control remains unavailable, your Jira Plan permissions may not allow this configuration change.

Help me troubleshoot missing Jira Plan scenario controls.

Your roadmap now protects operational demand while preserving dependency order. Next, you'll turn this live Plan into a leadership-ready decision view.

Publish the Leadership Roadmap

Your Jira Plans roadmap now protects BAU demand across all six quarters. Its baseline and BAU-surge scenarios show which strategic milestone moves when operational pressure increases.

Leaders need a concise decision view. Delivery teams need live work data.

Confluence provides the leadership narrative around a saved Jira Plans view. This pairing keeps the roadmap connected to the Jira data.

In this step, get ready to:

Save a quarterly leadership view focused on portfolio decisions.
Embed the live Jira Plan in the strategy page.
Publish the leadership narrative with confirmed viewer access.

Save the leadership view

The quarterly timeline already contains the planning evidence. A focused leadership view reduces task-level noise while preserving the dates and decisions that shape the portfolio.

Switch back to the Automation Platform Roadmap | 18 Months Jira Plan from earlier.
Keep Top-level planning view selected.
Keep the timeframe set to quarters.
Use the plan view controls to display progress.
Use the plan view controls to display owners.
Use the plan view controls to display dates.
Use the plan view controls to display dependencies.
Use the plan view controls to display decision milestones.

Why Save a Focused View?

A focused view preserves the live planning model while reducing task-level detail. Leaders can concentrate on timing and accountability.

Dependencies remain visible beside the milestones they can delay. Decision points remain visible beside the work they control.

Remove task-level detail from the leadership view.
Use the view save control to save the current configuration as the leadership view.

You should see a quarterly roadmap where progress, owners, dates, dependencies, and decision milestones are prominent.

Embed the live plan

An embedded plan keeps the leadership page connected to the roadmap data. Changes inside the saved Jira view can flow into the narrative without rebuilding a static timeline.

Select Share from the saved Jira view.
Select Copy link.
Switch back to the Automation and Platform Engineering Strategy | 18 Months Confluence draft from earlier.
Place the cursor where the live roadmap should appear.
Paste the copied Jira view link.
Choose Embed view.

You should see the quarterly Jira Plan inside the strategy page. The embedded view remains connected to the saved Jira data.

Why Embed the Plan?

The embed gives leaders a live view of progress and timing. The surrounding page explains the outcomes and decisions behind that data.

This separation gives each tool one clear job. Jira remains the planning layer while Confluence carries the leadership narrative.

Use the Jira sharing controls to confirm the intended leadership audience has Plan view permission.
Confirm the intended viewers have the Plans viewer global permission.
Confirm the intended viewers have access to the Jira site or app.
Confirm the intended viewers have access to the Automation team board or approved work source.
Confirm the embedded roadmap loads for an intended viewer.

The intended audience can now view both the saved Plan view and its underlying work source.

Does the Embed Look Empty?

An empty embedded Plan usually points to missing viewer access. Check the Plan view permission and the work-source access for the affected viewer.

Confirm that the viewer also has the Plans viewer global permission.

Ask the relevant Jira administrator to resolve any permission gap before publishing.

Help me diagnose an empty embedded Jira Plan.

Complete and publish the strategy page

The embedded plan supplies live timing. The rest of the page explains what leaders need to decide and how the roadmap stays accountable.

Use the roadmap decision statement from earlier to add a concise executive summary.
Place the existing mission statement below the executive summary.
Confirm the existing five-theme table still shows each primary outcome, metric definition, and accountable role.
Confirm the existing initiative mappings remain visible.
Add a current decision log.
Name the top roadmap risks in a risks section.
Add the existing cross-team dependencies to a dependencies section.

Separate Delivery and Strategy Reviews

The monthly delivery review checks progress against current dates. It also surfaces BAU pressure and dependency movement.

The quarterly strategy review compares outcomes against the theme metrics. It also revisits scenarios and pending decisions.

Add a monthly delivery review cadence.
Add a quarterly strategy review cadence.
Confirm Kubernetes work remains decision-gated.
Confirm OpenShift work remains decision-gated.
Confirm rollout work for Microsoft 365 Copilot connectors remains decision-gated.
Return to the Jira Plan from earlier.
Confirm the baseline and BAU-surge scenarios remain present.
Confirm BAU automation support and technical debt remain represented across all six quarters.

Confirm you have not selected Save changes for any unreviewed live Jira work updates.
Switch back to the Confluence strategy page.

Publishing shares the page with its permitted audience. Your permission checks protect the live roadmap from appearing empty for those viewers.

Select Publish on the Confluence page.

Before you switch to viewing mode, which leadership signals do you expect to stand out first?

Switch the published Confluence page to viewing mode.

What Should You See?

The five theme rows show one outcome, one metric definition, and one accountable role across six quarters.
The embedded Jira Plan shows quarterly progress, owners, dates, dependencies, and decision milestones.
The decision log shows the current leadership decisions.
The risks and dependencies sections name the conditions that can move delivery.
The page shows monthly delivery reviews and quarterly strategy reviews.
The theme metrics provide measurable success criteria.
The page labels Kubernetes, OpenShift, and connector rollout as decision-gated work.

That completes the leadership layer. Your published strategy page now connects measurable outcomes and live roadmap evidence without saving unreviewed changes to Jira work.

Secret mission

Secret Mission: Add a Kubernetes and OpenShift Decision Gate

Turn the platform evaluation into an evidence-based approval point. You will add a procurement gate that controls whether downstream pilot work can move forward.

Clean Up Your Resources

The roadmap uses existing Jira Cloud and Confluence Cloud subscriptions without provisioning infrastructure, so it adds no infrastructure costs. Choose whether to keep the planning artifacts active, pause further changes, or delete the practice copies under BBC retention and change-control policies.

Resources you used:

The Automation Platform Roadmap | 18 Months plan in Jira Plans contains roadmap work items, baseline and BAU-surge scenarios, the saved leadership view, dependency links, and the Kubernetes and OpenShift decision gate.
The published Automation and Platform Engineering Strategy | 18 Months page contains the embedded roadmap, outcome themes, decision records, risks, dependencies, success measures, and review cadence.

Keep everything running

No action is needed. Choose this option if the roadmap is ready to support active portfolio planning and leadership reviews.

Retain the Automation Platform Roadmap | 18 Months plan with its two capacity scenarios.
Retain the published Automation and Platform Engineering Strategy | 18 Months page as the leadership narrative.
Begin the monthly delivery review using the live Jira Plan.
Begin the quarterly strategy review using the decisions recorded in Confluence.

Pause - I'll come back to this later

Pause further roadmap changes while owners validate the capacity assumptions and dependencies. The planning artifacts remain available when the review is ready to resume.

Leave unreviewed roadmap changes in the Jira Plan sandbox.
Return the published Automation and Platform Engineering Strategy | 18 Months page to draft status through BBC's approved content workflow.
Resume the monthly delivery review after owners validate the capacity assumptions.
Resume the quarterly strategy review after owners validate dependency ownership.

Delete - I don't want to use this again

Remove the practice artifacts if you do not plan to reuse this roadmap. This clears the planning workspace without affecting infrastructure because the project provisioned none.

Confirm Approval Before Deletion

Deleting these practice artifacts is a deliberate reset. Confirm BBC retention and change-control approval before you continue.

Delete the Jira Plan

Confirm that BBC retention and change-control requirements permit removal of the practice plan.
Select Plans in the Jira Cloud sidebar.
Open Automation Platform Roadmap | 18 Months.
Select More actions (•••) next to the plan name.
Select Plan settings.
Use the plan deletion control on that settings page to remove Automation Platform Roadmap | 18 Months.
Confirm that the plan no longer appears under Plans.

Delete the Confluence Page

Open Automation and Platform Engineering Strategy | 18 Months in Confluence Cloud.
Open the page actions menu.
Use the page deletion control to remove the strategy page.
Confirm that the page no longer appears in its original Confluence space location.
Submit a deletion request through BBC's approved change-control process if either deletion control is unavailable.

Nice Work!

You did it! You built a leadership-ready 18-month Automation and Platform Engineering roadmap that turns competing requests into visible portfolio choices.

Here's what you learned:

Converted a technology worklist into five measurable outcome themes with clear metrics and accountable roles.
Modeled BAU and technical debt across six quarters in Jira Plans. Baseline and BAU-surge scenarios now reveal which strategic milestone moves when operational demand increases.
Published a leadership roadmap in Confluence Cloud that stays connected to the live Jira Plan. Its decisions, risks, success measures, and review cadence make the roadmap useful for ongoing leadership conversations.
Completed the Secret Mission by adding a Kubernetes and OpenShift procurement decision gate. Downstream pilot and rollout work now remains blocked until evidence and approval exist.

Ready to quiz yourself?