Program Management Glossary
Plain-language definitions of the terms a technical program manager uses every day. Where a term maps to a working tool, there is a link to it. For the tools themselves, see the free program management tools, and for how these ideas play out on real programs, read the Insights.
Backlog
The ordered list of work that has been identified but not yet completed, including features, fixes, and tasks. The backlog is prioritized so the team always pulls the most valuable work next.
Blast radius
The scope of impact if a change or failure goes wrong, meaning how many users, systems, or teams it could affect. Reducing blast radius means limiting exposure through phasing, feature flags, or isolation.
Blocker
Anything that stops work from progressing until it is resolved. A blocker needs a clear owner and fast resolution because it holds up everything downstream of it.
Burndown
A chart that tracks remaining work against time, showing whether a team is on pace to finish a sprint or release. A flat line means work is not being completed as planned.
Critical path
The longest chain of dependent tasks that determines the earliest a program can finish. Any delay on the critical path delays the whole program, so it gets the most attention.
Cutover
The point at which work moves from an old system or process to a new one, often during a migration. A cutover plan defines the sequence, the timing, and the rollback in case something fails.
Decision log
A running record of significant decisions, including what was decided, who decided it, when, and why. A decision log stops teams from re-litigating settled choices and preserves context for new people.
See the Weighted Decision Matrix tool →Definition of done
The shared checklist that work must meet before it counts as complete, such as code reviewed, tested, documented, and deployed. It prevents work from being called finished when it is not.
Dependency
A relationship where one piece of work cannot start or finish until another is done. Dependencies are the main source of cross-team delay, so they are tracked and owned explicitly.
Track dependencies in the RAID Log →Escalation path
The defined route for raising a problem to higher authority when it cannot be resolved at the current level. A good escalation path names who to go to, when, and what they can decide.
Idempotency
A property where performing the same operation more than once produces the same result as doing it once. It matters in payments and retry systems, where a duplicate request must not cause a duplicate effect.
Kickoff
The meeting that formally starts a program or project, aligning everyone on goals, scope, roles, and timeline. A strong kickoff sets shared expectations before any work begins.
Milestone
A significant checkpoint in a program that marks the completion of a major phase or deliverable. Milestones have a date and a clear meaning, and they are used to track progress at a high level.
MVP (Minimum Viable Product)
The smallest version of a product that delivers real value and can be tested with users. The MVP exists to learn quickly with the least effort, not to ship a stripped-down final product.
North star metric
The single measure that best captures the value a product delivers to users and the direction the team is steering toward. It aligns decisions across teams around one shared outcome.
OKR (Objectives and Key Results)
A goal-setting framework that pairs a qualitative objective with a few measurable key results. OKRs align teams on what matters and make progress against goals visible.
See the OKR Tracker tool →Postmortem
A structured review held after an incident or project to understand what happened and why. A blameless postmortem focuses on systemic causes and concrete action items rather than fault.
Pre-mortem
An exercise done before work starts where the team imagines the program has already failed and names the reasons. It surfaces risks early so they can be prevented rather than discovered later.
See the Pre-Mortem Worksheet tool →RACI
A responsibility model that labels each task or decision by who is Responsible, Accountable, Consulted, and Informed. RACI removes confusion about ownership on cross-functional work.
See the RACI Matrix Generator tool →RAID
A log that tracks Risks, Assumptions, Issues, and Dependencies in one place. RAID gives a program a single view of what could go wrong, what is being taken for granted, what is already a problem, and what it relies on.
See the RAID Log tool →Retrospective
A recurring team meeting, usually at the end of a sprint, to reflect on what went well, what did not, and what to change. The goal is continuous improvement of how the team works.
Risk register
A living document that lists identified risks, each scored by likelihood and impact, with an owner and a mitigation plan. It keeps the program focused on the risks that matter most.
See the Program Risk Register tool →Rollback
Reverting a system to its previous working state after a change causes a problem. A reliable rollback plan is what makes a risky deployment or cutover safe to attempt.
Runbook
A documented set of steps for performing a routine or emergency operational task, such as a deployment or an incident response. Runbooks make critical work repeatable and less dependent on any one person.
Scope creep
The gradual expansion of a program's scope beyond what was agreed, usually through small additions that are never formally approved. Unmanaged scope creep is a leading cause of missed deadlines.
Sprint
A short, fixed time box, often one to two weeks, in which a team commits to completing a set of work. Sprints create a predictable rhythm of planning, delivery, and review.
SLA (Service Level Agreement)
A commitment to a measurable level of service such as uptime or response time. SLAs set expectations and define what counts as a breach.
Stakeholder
Anyone with an interest in or influence over a program, including sponsors, users, and dependent teams. Identifying stakeholders and their level of power and interest guides how you engage each one.
See the Stakeholder Power/Interest Grid tool →Steering committee
A group of senior leaders who provide oversight, make high-level decisions, and unblock a program. The steering committee owns direction and escalations that exceed the program team's authority.
Tiger team
A small, focused group pulled together temporarily to solve a specific, urgent, high-stakes problem. Tiger teams have a narrow mandate and disband once the problem is resolved.
Velocity
A measure of how much work a team completes in a sprint, used to forecast how much it can take on next. Velocity is a planning aid for one team, not a productivity score to compare across teams.
WBS (Work Breakdown Structure)
A hierarchical decomposition of a program into smaller, manageable pieces of work. A WBS makes scope concrete and gives every piece of work a place.
Workback plan
A schedule built by starting from a fixed end date and working backward to determine when each milestone must happen. It reveals whether a deadline is realistic given the work required.
This glossary is maintained by Arsenii Samoilov, a Senior Technical Program Manager with 19+ years at Intuit, Atlassian, Adobe, Salesforce, Roku, and Apple. For how programs differ by shape, see types of programs and projects (migration, product launch, compliance, security, and more). Several terms have a working tool in the free program management tools, and the Insights go deeper on practice.