Program Planning Isn't Project Planning

Every successful program begins with a business outcome—not with a feature backlog.

One of the most common planning mistakes I see is teams jumping directly into Jira, creating Epics, estimating stories, and debating technical implementation before agreeing on why the program exists.

That approach may work for a project.

It rarely works for an enterprise program.

Large engineering programs involve multiple organizations, competing priorities, and significant investment. Unless every stakeholder shares the same definition of success, individual teams naturally optimize for their own objectives.

Platform Engineering may focus on standardization.

Security may prioritize compliance and risk reduction.

SRE may optimize operational stability.

Application teams often care about developer productivity and release velocity.

Leadership, however, expects measurable business outcomes.

One of my recent programs was the rollout of Enterprise Continuous Deployment (ECD)—an internal deployment platform designed to standardize software deployments across engineering organizations.

At first, many discussions naturally revolved around engineering deliverables.

Should we support another deployment strategy?

How should the deployment workflow evolve?

Which Kubernetes features should be included?

Those were important engineering discussions, but they were not the reason the program existed.

The real objective was much broader.

The organization wanted a deployment platform that could be adopted consistently across engineering teams while improving deployment governance, reducing operational overhead, standardizing deployment practices, and providing leadership with predictable production release management.

Deployment automation was only one capability supporting that outcome.

Similarly, the MasterHelm initiative was often viewed as a Helm chart standardization effort.

In reality, the business objective was much larger.

Engineering teams were maintaining deployment templates independently, introducing inconsistencies across applications and environments.

MasterHelm established a common deployment framework that reduced maintenance effort, improved deployment consistency, simplified onboarding for new services, and enabled future platform capabilities to be delivered once instead of being reimplemented by every engineering team.

The outcome was organizational standardization—not simply another Helm chart.

I have found that outcome discussions become significantly more productive when stakeholders stop talking about features and instead answer three simple questions:

• —What business problem are we solving?
• —How will engineering operate differently after this program?
• —How will leadership know the investment was successful?

Those conversations expose assumptions surprisingly quickly.

During planning for the ECD rollout, Security emphasized deployment governance and approval workflows.

Platform Engineering focused on reusable deployment capabilities.

SRE wanted deployment reliability and operational visibility.

Engineering organizations expected a simpler deployment experience.

All of those perspectives were valid.

The responsibility of the Technical Program Manager was not to choose one over another.

It was to translate them into a shared outcome that every organization could support.

That alignment became the foundation for roadmap planning, dependency management, governance, and executive reporting throughout the program.

One lesson has remained consistent across every enterprise modernization initiative I have led.

Whether the program involved deployment modernization, centralized configuration management (CM), Vault AppRole adoption, or OpenTelemetry (OTel) rollout, engineering discussions always became easier once the organization aligned on the business outcome first.

Technical decisions changed throughout execution.

The business objective did not.

"Teams build features. Programs deliver business outcomes."

Before planning begins, I always ensure three questions can be answered clearly.

• —What business outcome will change because of this program?
• —How will we measure that change?
• —Who is ultimately accountable for delivering it?

If those answers are unclear, the program is not ready for planning.

It is only ready for more discussion.

Once business outcomes are aligned, the next step is identifying the capabilities the organization must build to achieve those outcomes.

This is where many program plans begin to drift.

Teams naturally think in terms of features because features are easy to estimate, assign, and track in Jira. Leadership, however, is investing in capabilities that transform how the organization operates.

That distinction is critical.

A feature delivers functionality.

A capability changes organizational behavior.

"Features deliver software. Capabilities change how the business operates."

One exercise I frequently use during planning is to ask engineering teams to temporarily ignore Jira Epics and instead answer a simple question:

"What should the organization be able to do after this program is complete that it cannot do today?"

The answers are almost always capabilities—not features.

For example, during the Enterprise Continuous Deployment (ECD) program, the objective was never to build deployment APIs, deployment dashboards, or release workflows.

Those were implementation details.

The capabilities we wanted the organization to achieve were much broader.

• —Standardize application deployments across engineering organizations.
• —Reduce manual deployment activities.
• —Enable repeatable production deployments with consistent governance.
• —Provide deployment visibility for Engineering, SRE, and Leadership.
• —Support controlled rollout of platform capabilities across environments.

Those capabilities drove every roadmap discussion.

Only after they were agreed upon did engineering teams begin defining the individual features required to enable them.

The same approach proved valuable during the MasterHelm initiative.

Many engineers initially viewed MasterHelm as a shared Helm chart repository.

From a program perspective, that wasn't the capability we were building.

The capability was standardized Kubernetes application deployment across hundreds of services without requiring every engineering team to maintain its own deployment templates.

To achieve that capability, multiple engineering workstreams had to come together.

Features included:

• —Shared MasterHelm framework
• —Reusable deployment templates
• —Centralized configuration management (CM)
• —Standard deployment parameters
• —Common deployment validation
• —Environment-specific configuration management

Individually, none of these features delivered business value.

Collectively, they enabled a new organizational capability.

Another good example was the rollout of Vault AppRole.

From an engineering perspective, the work appeared relatively straightforward—integrate applications with Vault and replace static credentials.

From a program perspective, the capability being delivered was much more significant.

Applications could now retrieve secrets securely at runtime using a standardized authentication mechanism instead of relying on manually managed credentials.

Achieving that capability required coordination across Platform Engineering, Security Platform, DevEx, SRE, and individual application teams.

The engineering implementation was only one part of the program.

The organizational adoption was the larger challenge.

A similar pattern emerged during our OpenTelemetry (OTel) initiative.

Installing instrumentation libraries into applications was relatively easy.

Building an organization-wide observability capability was not.

Success depended on standard telemetry conventions, deployment automation, platform support, dashboards, collector infrastructure, engineering onboarding, operational processes, and adoption across multiple product teams.

The capability was not "instrument applications."

The capability was enabling engineering teams to observe production systems consistently using a common telemetry standard.

The same thinking applied to Centralized Configuration Management (CM).

Engineering often viewed CM as another platform service.

Program planning viewed it differently.

CM enabled standardized configuration management, environment consistency, controlled release promotion, simplified onboarding, and governance across deployments.

Without that capability, deployment standardization could never be achieved regardless of how mature the deployment platform became.

This is why capability-driven planning consistently produces better roadmaps than feature-driven planning.

Features evolve throughout execution.

Capabilities remain relatively stable because they represent business needs rather than implementation choices.

When roadmap discussions are organized around capabilities, leadership conversations also improve.

Instead of reviewing hundreds of Jira tickets, executives can assess whether the organization is becoming more capable of operating at scale.

That shifts planning conversations from engineering activity to organizational outcomes.

The roadmap below illustrates how capabilities should mature over time.

Below is a practical example of how capabilities differ from features based on enterprise platform engineering programs.

A useful validation exercise during planning is to review every feature in the roadmap and ask:

"Which organizational capability does this feature improve?"

If that question cannot be answered, the feature probably does not belong in the program roadmap.

Capabilities provide the structure.

Features provide the implementation.

Confusing the two is one of the quickest ways for an enterprise program to lose focus.

If there is one area where Technical Program Managers create the most value, it is dependency management.

Engineering teams are generally very good at managing the work they own.

What consistently delays enterprise programs are the dependencies that exist between teams.

These dependencies rarely appear in sprint boards.

They are discovered during integration, production readiness, security reviews, infrastructure validation, or executive governance—usually much later than anyone would like.

That is why I consider dependency identification one of the first planning activities, not something that happens midway through execution.

"Programs rarely fail because engineers cannot build software. They fail because teams depend on each other more than they realize."

One of the best examples comes from the rollout of the Enterprise Continuous Deployment (ECD) platform.

Although ECD was owned by a relatively small engineering team, its production rollout depended on multiple organizations successfully completing their own deliverables.

The ECD team could build deployment workflows, deployment APIs, and user interfaces.

However, production rollout depended on work owned by Platform Engineering, SRE, Security Platform, DevEx, Infrastructure Engineering, and Product Engineering.

For example, MasterHelm could not be validated until the K8s platform was certified for the target release.

The deployment framework relied on Kubernetes capabilities that became available only after the platform upgrade.

Even though both teams were progressing independently, the overall program could not move forward until that dependency was resolved.

Another example was Vault AppRole adoption.

From an engineering perspective, the implementation was complete relatively early.

From a program perspective, the dependency remained open.

Before organization-wide rollout, the Security Platform team required an extended soak period across integration environments to validate authentication, secret rotation, operational monitoring, and rollback procedures.

The feature was technically complete.

The dependency was not.

That distinction significantly influenced release planning.

We encountered similar situations with Centralized Configuration Management (CM).

Application onboarding depended on standardized configuration management before teams could adopt MasterHelm consistently.

Without CM readiness, deployment automation would have produced inconsistent deployments across environments, defeating one of the primary business objectives of the program.

Observability introduced another important dependency.

During the rollout of OpenTelemetry (OTel), adding instrumentation libraries to applications was only a small portion of the work.

Engineering teams also depended on collector infrastructure, telemetry pipelines, dashboard availability, operational alerting, deployment automation, and platform support.

Treating OTel as a single engineering task would have hidden several cross-functional dependencies that directly affected production readiness.

These examples reinforced an important lesson.

The most important dependencies in enterprise programs are rarely technical.

They are organizational.

A deployment platform depends on infrastructure.

Infrastructure depends on security.

Security depends on governance.

Operations depend on observability.

Product teams depend on platform readiness.

Every dependency becomes part of a much larger delivery chain.

Because of this, I categorize dependencies during planning rather than allowing them to emerge organically throughout execution.

Typical categories include:

• —Technical Dependencies — shared services, APIs, deployment frameworks, Helm templates, platform integrations.
• —Platform Dependencies — Kubernetes platform upgrades, infrastructure readiness, CM, deployment tooling, observability platforms.
• —Security Dependencies — Vault AppRole rollout, security approvals, vulnerability remediation, production security validation.
• —Operational Dependencies — SRE readiness, monitoring, production validation, operational runbooks, incident readiness.
• —Governance Dependencies — Architecture reviews, Engineering Pod approvals, release sign-offs, production readiness reviews.
• —Product Dependencies — Feature readiness, engineering adoption, rollout sequencing, communication plans.

Classifying dependencies this way helps leadership understand where delivery risk exists.

Not every blocker is an engineering problem.

Many require coordination across organizations rather than additional development effort.

One practice that proved particularly effective during the ECD rollout was establishing a centralized Dependency Register.

Every dependency had:

• —A named owner
• —Supporting organization
• —Business impact
• —Delivery milestone
• —Current health
• —Mitigation plan
• —Escalation path

Rather than reviewing dozens of Jira boards during governance meetings, leadership reviewed one dependency register that reflected the health of the entire program.

This became the primary planning artifact during weekly release governance meetings.

Instead of asking individual teams whether their sprint work was complete, discussions focused on questions such as:

• —Which dependency determines the production Go-Live date?
• —What is currently blocking Engineering Pod sign-off?
• —Which dependency requires executive escalation?
• —What mitigation exists if this dependency slips by one sprint?

Those conversations significantly improved decision quality because they shifted governance away from task completion and toward delivery readiness.

The dependency flow below illustrates how independent workstreams converge before production execution.

One of the most valuable artifacts created during the ECD program was the dependency register shown below.

It became the single source of truth for engineering leadership, release governance, production readiness reviews, and executive status reporting.

Even the best program plan will fail without effective governance.

Governance is often misunderstood as status meetings, executive presentations, or approval checkpoints.

In reality, governance exists to accelerate decisions.

When programs become large enough to span multiple engineering organizations, workstreams begin moving at different speeds.

Platform Engineering is waiting for Security.

Security is waiting for Infrastructure.

Infrastructure is waiting for SRE.

Product Engineering is waiting for Platform Engineering.

Without a structured governance model, those dependencies remain invisible until they impact delivery.

"Good governance doesn't create bureaucracy. It creates clarity, accountability, and faster decisions."

One of the most valuable lessons from leading the Enterprise Continuous Deployment (ECD) program was realizing that governance should never revolve around status updates.

Status is an output.

Decision-making is the purpose.

As the ECD rollout expanded across Platform Engineering, DevEx, Security Platform, Infrastructure, SRE, and Product Engineering, it quickly became clear that reviewing Jira Epics or Sprint progress was no longer sufficient.

Every engineering team reported healthy sprint progress.

Yet the production release could still be delayed because one critical dependency remained unresolved.

For example, during one release cycle, engineering development was largely complete.

However, production readiness depended on several independent activities reaching completion:

• —Vault AppRole soak validation
• —K8s platform certification
• —MasterHelm compatibility validation
• —MPOD production infrastructure readiness
• —Engineering Pod production sign-off
• —OCI deployment capability
• —Production operational readiness by SRE

None of these appeared as blockers on a single Jira board.

Collectively, they determined whether the release could move to production.

This changed the purpose of our weekly governance meetings.

Instead of reviewing completed stories or sprint velocity, every discussion focused on production readiness.

Typical questions included:

• —Which dependency currently determines the Go-Live date?
• —Which blocker requires leadership escalation?
• —Has every Engineering Pod completed production validation?
• —Is SRE operationally ready to support this release?
• —Are Security and Platform Engineering comfortable proceeding with production rollout?
• —What risk are we accepting if we release this sprint?

Those conversations consistently generated better decisions than reviewing burn-down charts.

Another practice that proved valuable was separating governance forums based on the type of decision being made.

Technical discussions remained with architects and engineering leads.

Program decisions remained with delivery leadership.

Executive trade-offs remained with sponsors.

This prevented meetings from becoming overloaded with topics that belonged elsewhere.

For the ECD program, governance naturally evolved into three operating layers.

The first was the Weekly Program Review.

This became the operational heartbeat of the program.

Program Management, Platform Engineering, DevEx, Security Platform, SRE, Infrastructure Engineering, and Product Engineering reviewed:

• —Milestone health
• —Cross-team dependencies
• —Open blockers
• —Production readiness
• —Action items
• —Escalations

The objective was not reporting.

The objective was ensuring every workstream remained aligned toward the same production milestone.

The second forum consisted of Architecture and Technical Reviews.

These sessions focused on engineering decisions that could affect future delivery.

Examples included:

• —MasterHelm architecture decisions
• —Vault AppRole integration approach
• —CM onboarding strategy
• —OpenTelemetry instrumentation standards
• —Kubernetes platform compatibility
• —Deployment workflow changes

These meetings intentionally avoided program status.

Their purpose was technical quality and long-term platform consistency.

The third governance layer involved Engineering Leadership and Release Governance.

These reviews answered one question:

"Can this release safely move to production?"

Rather than discussing engineering effort, leadership reviewed:

• —Critical production blockers
• —Dependency health
• —Production validation status
• —Engineering Pod approvals
• —Operational readiness
• —Rollback readiness
• —Release risks
• —Executive decisions required

This became the final production gate before Go-Live.

One practical example illustrates why governance matters.

During ECD production validation, SRE identified two issues that initially appeared relatively small:

• —ECD-318 — Cluster View issue
• —ECD-319 — OCI deployment support

Neither represented months of engineering work.

However, both affected production operability.

Without resolving those issues, SRE could not confidently support production deployments across all target environments.

Instead of asking Engineering to "finish development," governance discussions shifted toward business decisions:

• —Do these issues block production?
• —Can rollout proceed with documented limitations?
• —Should OCI support move to the next release?
• —What operational risk remains after deployment?

Those are program management decisions—not engineering decisions.

That distinction is exactly why governance exists.

A well-governed program makes risks visible before they become production incidents.

It ensures executive decisions are based on delivery readiness rather than engineering optimism.

The governance model below illustrates how decision authority is distributed across the program.

Each governance forum serves a distinct purpose.

One lesson I have carried into every subsequent program is that governance should never become a reporting exercise.

If a meeting ends without a decision, removing a blocker, assigning ownership, or resolving a risk, governance has failed.

The best governance meetings are not the ones with the most slides.

They are the ones where teams leave with fewer uncertainties than when they entered.

Key Takeaway: Governance is not about monitoring progress—it is about enabling decisions. When structured correctly, governance provides clear ownership, timely escalation, and the decision-making discipline required to keep complex enterprise programs moving toward successful delivery.

Planning establishes direction.

Governance enables decisions.

Metrics tell you whether the program is actually moving toward its intended outcome.

One mistake I frequently see is organizations measuring only engineering activity.

Sprint velocity increases.

Story points are completed.

Deployments happen more frequently.

Dashboards look healthy.

Yet leadership still asks a simple question:

"Is the program delivering the business value we approved?"

Engineering metrics alone cannot answer that question.

Likewise, business metrics without engineering context make it difficult to understand why progress is slowing.

A Technical Program Manager needs visibility into both.

"Metrics should explain whether the program is healthy—not simply whether teams are busy."

During the Enterprise Continuous Deployment (ECD) rollout, we intentionally avoided measuring success by the number of completed Jira stories or deployment features delivered.

Those metrics were useful for engineering teams, but they did not tell leadership whether the deployment platform was becoming operationally ready.

Instead, we monitored three complementary views of program health.

• —Engineering Delivery
• —Platform Adoption
• —Program Health

Together, they provided a balanced picture of execution.

Engineering metrics answered a straightforward question:

"Can we build and release software reliably?"

Typical engineering indicators included:

• —Deployment success rate
• —Deployment failure rate
• —Deployment duration
• —Rollback frequency
• —Mean time to recover (MTTR)
• —Production deployment validation success

These metrics helped engineering teams continuously improve delivery quality.

However, they represented only one dimension of program success.

For example, achieving a 99% deployment success rate had little value if engineering organizations were not adopting the platform.

Platform programs succeed only when engineering teams actually use the capabilities that are delivered.

During ECD and MasterHelm adoption, platform health became just as important as engineering delivery.

Examples included:

• —Engineering teams onboarded to ECD
• —Applications migrated to MasterHelm
• —Vault AppRole adoption across supported services
• —CM onboarding progress
• —OpenTelemetry instrumentation coverage
• —Standardized deployment adoption across engineering organizations

These metrics demonstrated whether the platform was becoming part of day-to-day engineering operations rather than remaining another internal tool.

One example was the rollout of Vault AppRole.

Completing engineering implementation did not indicate success.

The real indicator was the number of applications successfully authenticating through Vault in production while eliminating legacy credential management.

Similarly, OpenTelemetry was not considered successful simply because instrumentation libraries had been deployed.

Success required engineering teams to consistently generate telemetry that SRE teams could use for production monitoring, troubleshooting, and operational decision-making.

Program metrics answered an entirely different question:

"Is the overall program still on track?"

These metrics became the primary focus during weekly governance meetings because they highlighted delivery risks before milestone dates began slipping.

For the ECD program, examples included:

• —Cross-team dependency aging
• —Number of critical production blockers
• —Release readiness score
• —Engineering Pod sign-off completion
• —Infrastructure readiness
• —Security approval status
• —Production validation progress
• —Executive decision backlog

Unlike engineering metrics, these indicators measured delivery confidence.

They helped leadership understand where intervention was required before production rollout.

For example, during one release cycle, engineering delivery metrics remained healthy.

Development milestones were being achieved consistently.

However, program health metrics told a different story.

The dependency register showed several high-risk items still under active tracking:

• —Vault AppRole soak validation
• —MasterHelm production validation
• —OCI deployment capability
• —Engineering Pod approvals

Although engineering execution appeared healthy, leadership correctly delayed production until those dependencies reached an acceptable level of readiness.

Without program health metrics, that risk would have remained largely invisible.

One principle I have adopted across platform modernization programs is that every metric should support a decision.

If nobody reviews a metric during governance meetings, it probably should not be on the dashboard.

Likewise, dashboards overloaded with dozens of charts often create noise rather than insight.

Leadership rarely needs more information.

They need better information.

For executive reviews, I typically limit dashboards to a small number of high-signal indicators that clearly communicate delivery confidence.

The table below illustrates the categories of metrics that proved most valuable across programs such as ECD, MasterHelm, Vault AppRole, CM, and OpenTelemetry adoption.

One metric that consistently proved valuable during release governance was the Production Readiness Score.

Rather than relying on subjective status such as Green, Amber, or Red, we evaluated readiness across multiple dimensions:

• —Platform readiness
• —Security readiness
• —Infrastructure readiness
• —Operational readiness
• —Dependency health
• —Production validation
• —Engineering approvals

This gave leadership a much clearer understanding of whether the program was genuinely ready for production or simply progressing well within individual engineering teams.

The most successful program dashboards I have seen share one characteristic.

They do not attempt to measure everything.

They measure the handful of indicators that help leadership answer three questions:

• —Are we delivering reliably?
• —Are engineering teams adopting the platform?
• —Are we ready to achieve the business outcome?

If the dashboard cannot answer those questions, it is reporting activity rather than program health.

Key Takeaway: Metrics should help leaders make better decisions, not produce larger dashboards. A balanced view across engineering delivery, platform adoption, and overall program health enables TPMs to identify emerging risks early, validate business progress, and guide complex enterprise programs toward successful outcomes.

One of the first questions teams ask is usually:

"Can you create the Epic?"

My response is almost always the same.

"We haven't agreed on the program yet."

Creating Epics, Features, and Stories feels like progress because Jira immediately gives everyone something to work on.

But a well-organized backlog does not mean the program is well planned.

During the early planning of ECD, we deliberately delayed creating detailed execution plans until leadership aligned on the deployment strategy, adoption model, production rollout approach, and success criteria.

Only after those conversations were complete did the Jira structure become meaningful.

Jira is where execution begins.

It should not be where planning begins.

Another mistake I frequently encounter is feature-first thinking.

Engineering teams naturally discuss APIs, UI improvements, deployment workflows, or automation.

Leadership, however, is funding organizational capabilities.

For example, MasterHelm was never funded because leadership wanted another Helm chart.

It was funded because the organization needed standardized deployments across engineering teams.

The deployment templates were simply one implementation of that capability.

Whenever roadmap discussions become feature-heavy, I ask a simple question:

"What organizational capability does this feature enable?"

If nobody can answer, the feature probably belongs in a backlog—not in a program roadmap.

Many governance meetings gradually become slide reviews.

Every workstream reports Green.

Every milestone appears healthy.

Everyone agrees to meet again next week.

Nothing actually gets decided.

During the ECD rollout, we intentionally changed the purpose of governance meetings.

Instead of asking teams what they completed, we asked:

• —What prevents production this week?
• —Which dependency requires executive attention?
• —Which decision cannot wait until next week?

That simple shift made governance significantly more valuable.

A governance meeting should remove blockers—not simply communicate them.

Executive sponsorship is often assumed rather than actively maintained.

Alignment achieved during kickoff does not automatically continue throughout execution.

As enterprise programs evolve, priorities change, risks emerge, and trade-offs become necessary.

One lesson I have learned is to continuously validate executive expectations throughout the program—not just at the beginning.

Regular steering discussions prevented several ECD decisions from becoming engineering debates when they actually required leadership direction.

The largest delivery risks I have managed were rarely technical.

They were dependencies that surfaced much later than expected.

For example, production rollout of ECD depended on MasterHelm validation, Vault AppRole readiness, Engineering Pod approvals, K8s certification, MPOD infrastructure readiness, and production validation by SRE.

Every team delivered quality engineering.

The challenge was ensuring every dependency matured at roughly the same pace.

That is why dependency workshops now happen during planning rather than after execution has already started.

Engineering organizations naturally measure work completed.

Programs need to measure business progress.

Completing a deployment workflow did not mean ECD was successful.

Success meant engineering organizations were adopting the platform, deployments became more standardized, operational effort decreased, and production governance improved.

Those outcomes mattered far more than the number of completed stories.

"The most successful programs I've managed spent more time discussing decisions, dependencies, and business outcomes than sprint velocity."