Maia 200 is Microsoft’s second-generation first-party AI accelerator built to support large-scale AI inference workloads in Azure. As Maia 200 moved from pre‑silicon design toward deployment, work across multiple engineering organizations was managed within a single program responsible for bringing the accelerator into Azure. At its peak, that effort tracked over 700 active tasks spanning silicon, software, and datacenters. To manage the intricacies of the effort at that scale, the program team turned to Microsoft Planner.
As the Maia 200 program was forming, much of the individual engineering organizations’ work was already in motion across different products including Planner, Excel, and Azure DevOps. Creating a shared view across multiple products proved challenging, as milestones that looked achievable to one team could quietly introduce risks for another, and executive discussions relied on manually assembled status updates rather than a live picture of where the program stood. Program leads needed a shared view of execution to manage dependencies across workstreams, align milestone progress, and identify risks that had the potential to impact delivery timelines.
Creating program-level visibility with Planner
With work already in motion across multiple organizations, the Maia 200 program maintained existing team workflows and tools, but selected Planner as the central coordination layer. As a collaborative work management solution, Planner provides a unified experience that spans individual task tracking through enterprise‑level project management, giving teams a single place to plan, manage, and complete task‑based initiatives. This allowed swim lanes, milestones, critical‑path tasks, and dependencies to be visible regardless of where the underlying work was managed.
Maia 200 program leads began setting up the plan by creating a series of visual swim lanes for each engineering organization. These were built in Planner as parent tasks and subtasks, covering areas like silicon feature readiness, networking enablement, and system validation. Each swim lane was color-coded to the product or engineering owner responsible for that area, and a custom field was added to track the directly responsible individual (DRI) for each task. This structure made ownership immediately clear throughout the plan. While the plan was originally designed for program-level visibility, it quickly became more than that, as some development leads began using these sections as their primary source of truth for day-to-day project execution.
Screenshots reflect the Planner configuration used throughout this program and have been anonymized for confidentiality.Next, the Maia 200 program team created a structure for tracking overall program milestones. The use of a single parent task called "Top‑Level Program Milestones" visually distinguished milestones from swim lanes within the plan. Underneath, milestones were captured as individual subtasks and grouped by stages of the full program lifecycle, helping align work across phases and clarify what the program was working toward at each stage.
From the start, the same plan served both executive leadership and engineering team leads by providing a consistent view of program progress while still allowing milestone tracking to connect directly to the work‑level details required for execution.
Screenshots reflect the Planner configuration used throughout this program and have been anonymized for confidentiality.Tracking the critical path and dependencies within Planner
With milestones and swim lanes in place, the next challenge was to track cross-organizational dependencies. The program leads used Planner's dependency feature to track blockers and reinforced a consistent rule in program meetings that any capability on the critical path needed to be represented in Planner. When one group's work depended on another's, both sides created dependency-linked tasks in their respective swim lanes to make the connection visible.
In practice, this meant that when multiple Azure DevOps items rolled up to a single critical-path capability, that capability was tracked in Planner as a task. Dependencies between teams were also represented within the plan, even when the underlying execution remained in other systems. As a result, if a team became blocked, that blocker was visible in the plan and acknowledged by both sides.
The Maia 200 program team also mapped milestones to related tasks within each swim lane setting each milestone as dependent on the final task (or tasks) required for completion. Planner's scheduling engine then automatically updated milestone dates as work within the swim lanes progressed.
To monitor progress over time, the team used Planner baselines to capture point-in-time snapshots of the plan, allowing them to export task data to Excel, compare multiple baselines, and identify delivery trends as needed.
Tracking risks within Planner
Risks were also tracked directly in Planner, giving program leaders a single view of the work underway and the factors that could impact it. Each risk was represented as a task in the plan and made dependent on the related tasks within each swim lane. Milestones were similarly linked to these risk tasks, keeping mitigation work directly connected to the execution required to reach each milestone.
Screenshots reflect the Planner configuration used throughout this program and have been anonymized for confidentiality.With critical path work, cross-team dependencies, and associated risks visible in one place, program leads could anticipate risks earlier and respond before changes have a chance to ripple across the program.
Over time, this shifted the nature of program discussions. Instead of spending meeting time providing status updates, program and engineering leads were able to focus on the decisions that mattered, including which risks to prioritize, which tradeoffs to make, and where to act before a dependency became a blocker.
For program leadership, this meant schedule changes never arrived as a surprise, because blockers, dependencies, and risks were already visible and actively managed within the plan. For the engineering teams, it meant a dependency could not be claimed without being represented in the plan and acknowledged by the team responsible for driving the dependent work. By connecting milestones, critical path work, cross‑team dependencies, and risk tracking in a single coordination layer, Planner gave the Maia 200 program the shared operating picture it needed to keep execution aligned across organizations, systems, and every stage of delivery.
Microsoft