Project Delivery and Execution Ownership Questions

Direct answer

With a fixed, non-negotiable compliance date, the timeline is not the lever, scope is, so the job is to decide, with the right people in the room, exactly what must ship to satisfy the requirement versus what can wait, and to be explicit that the compliance piece itself is never one of the things being cut.

Structured elaboration

1. Separate "must comply" from "was also planned": list every requirement the regulation actually mandates versus features that were simply bundled into the same release for convenience.
2. Decide who to involve: legal or compliance for what the regulation strictly requires, engineering leads for what is technically feasible by the date, and product for what is lost if non-required features slip.
3. Weigh business and technical impact above the original wish list: what the delay or descope costs, including any penalty for missing the date, and what is actually buildable and testable in the remaining time.
4. Communicate the trade-off: tell stakeholders exactly what ships for compliance, what is deferred, and why, framed as "we are hitting the date and the requirement, and moving this other piece to the next release."
5. Verify the requirement is actually met: build in a dedicated check, such as an independent audit, before the deadline, since "we built it" and "it passes the requirement" are different claims.

Worked example

A public benefits portal has a 10-week hard deadline to meet a new accessibility requirement covering its three core flows: starting an application, uploading documents, and checking status. A planned redesign of the account-settings page is bundled into the same release.

Legal confirms the mandate covers only the three core flows, not account settings. Engineering estimates the accessibility work across the three flows (keyboard navigation, screen-reader labels, color-contrast fixes) at 7 weeks, leaving 3 weeks for an independent accessibility audit and fixes from its findings; 7 plus 3 equals the full 10-week deadline. The account-settings redesign, originally 4 weeks of the same release, is deferred entirely, since it is not required and would consume time needed for the audit.

The message to stakeholders: the three required flows will be accessibility-compliant with an independent audit completed by week 10, and the settings redesign moves to next quarter's roadmap.

Trade-offs and pitfalls

The biggest pitfall is treating "we finished building it" as equivalent to "it is compliant," and skipping a dedicated verification step to save time, which risks discovering a gap after the deadline has already passed. A second pitfall is letting unrelated planned work ride along inside the compliance release instead of being cut first, since it competes for the same time as the actual legal requirement. Deferring the account-settings work here disappoints whoever wanted it, but protects both the date and the requirement, which is the one thing that is not negotiable.

Direct answer

A scope statement for a four-month, cross-platform authentication program needs the same four pieces as any scope document, in-scope, out-of-scope, assumptions, and success criteria, but written at program grain: each line has to hold across every platform the program touches, not just one team's slice of it. Here is the statement I would actually write, followed by why each section is drawn where it is.

Structured elaboration

• In scope: a single authentication service supporting email and password login plus one social login provider, integrated into the web, iOS, and Android clients, replacing each platform's existing separate login implementation, delivered within the four-month window.
• Out of scope: additional social login providers beyond the first one, single sign-on for enterprise customers, and any change to the existing account-recovery flow, all explicitly deferred to a follow-up phase.
• Assumptions: each platform team can allocate one engineer for the full four months to integrate against the new service (not build it), and the existing user database can be migrated without a schema change that would force re-authentication of existing users.
• Success criteria (acceptance): all three platforms authenticate exclusively through the new service (the old, separate implementations are fully decommissioned, not left running as a fallback), login failure rate across all three platforms is at or below the current baseline, and the migration completes with no forced re-authentication for existing users.

Why draw the line here: in scope is deliberately narrow, one login method plus one social provider, because a four-month program spanning three platforms already carries enough coordination risk without also carrying the scope risk of multiple auth methods shipping simultaneously. Out of scope names the two things every platform team will ask about (more providers, enterprise SSO) so those requests get parked as a next phase instead of quietly expanding the current one. The engineer-per-platform assumption is written down because it's the single biggest risk to the four-month timeline: if it's wrong, the timeline is wrong, and it's better to have platform leads confirm or correct it before commitments are made publicly. The acceptance criteria explicitly require decommissioning the old implementations, not just adding the new one, because a surviving fallback is where the next security or consistency issue hides.

Worked example

Month 1 builds the shared service and validates it against the web client, typically the fastest platform to integrate against a new backend. Months 2 and 3 integrate iOS and Android in parallel, each with their one dedicated engineer. Month 4 is reserved for decommissioning all three old implementations and confirming the login-failure-rate criterion holds for a full two weeks post-cutover before declaring the program done. If iOS integration in month 2 reveals the social-login SDK (software development kit) doesn't support an account-linking case the old implementation handled, that's exactly the kind of finding the assumptions section exists to surface early: it gets resolved with month 2's remaining time rather than discovered as a surprise in month 4.

Trade-offs and pitfalls

Writing "in scope" broadly to seem accommodating, adding SSO or a second social provider because a stakeholder asked, is the fastest way to turn a four-month program into a six-month one; every added item multiplies coordination cost across three platforms, not just one. Leaving the old implementations running "just in case" after cutover, instead of requiring decommissioning as an acceptance criterion, is the single most common way this kind of program quietly fails to actually finish. And skipping the written assumption about per-platform engineer availability means that if a platform team can't actually spare a full engineer, that surfaces as a slipped deadline in month 3 instead of a renegotiated scope in month 1, when it would have been far cheaper to address.

Direct answer

A single team's definition of done usually stops at "the code is merged, tested, and deployed to production." A program spanning multiple teams needs a definition of done one level up: it isn't done until the outcome the program exists for is verifiably true in production, every team's piece is operating together without a human quietly patching the seams, and there's a documented owner for what happens after the program's core team disbands. Below are three concrete criteria I actually used running a program that replaced three teams' separate login flows with one shared authentication service.

Structured elaboration

Situation: three teams each owned their own login flow, with duplicated bugs and inconsistent session behavior across products; my job was to consolidate them into one shared service.

Task: each team's own definition of done was "our product now calls the shared service instead of our old flow," which said nothing about whether the program actually achieved what it was funded for.

Action, I added three program-level criteria on top of each team's own done:

1. The end-to-end metric moved, not just the code shipped. Each team's individual "done" only proved their own integration worked in isolation. The program's done required the metric the whole program was funded to move, login failure rate across all three products, tracked centrally, to actually hit its target, confirmed a full week after the last team's migration, not just at merge time.
2. No team-specific workaround survived past cutover. During a migration like this it's common for a team to keep a fallback path "just in case." Program-level done required every team's fallback to old auth to be actually removed and its removal verified, not merely scheduled, because a surviving fallback is exactly where the next incident hides.
3. Ownership of the shared service was assigned to a real team, with an on-call rotation, before the program team dissolved. A cross-team build with no permanent owner tends to degrade the moment the program that built it stops existing; done meant a named team had accepted operational ownership, not that the program team promised to "keep an eye on it."

Result: the program was declared done only once all three criteria were independently confirmed, roughly six weeks after the last individual team called their own piece finished, exactly the gap those extra criteria exist to close.

Worked example

Week 0 was the last team's cutover to the shared service. Weeks 1 through 4 were spent monitoring the centrally tracked login failure rate, which had to hold at or below its target for a full week before criterion 1 could be marked satisfied; that threshold was hit in week 5. Removal of the last team's fallback path was verified in week 5 as well, via a deploy that deleted the old auth code path entirely rather than just disabling a feature flag. The receiving team's on-call rotation for the shared service was confirmed live in week 6, which is when the program was actually closed, six weeks after the last team believed their own scope was finished.

Trade-offs and pitfalls

The most common mistake is declaring a program done the moment every team's individual piece is done, which measures activity, not outcome, and misses exactly the seam-level failures (surviving fallbacks, no real owner) that a single team's definition of done was never designed to catch. Being too strict in the other direction, refusing to call anything done until every conceivable edge case is covered, stalls the program indefinitely and burns the trust that got it funded. The right calibration is a small number of criteria (three was right for this program; a smaller effort might need only one or two) that specifically test for the risks unique to spanning multiple teams: outcome versus activity, surviving workarounds, and a real owner after the program team leaves.

Direct answer

Whether the ask lands mid-sprint or mid-program, the judgment is the same: evaluate it against the current plan's goals, risk, dependencies, and acceptance criteria before reacting, bring back one of three concrete decision options rather than an immediate yes, and document and communicate whatever gets decided so the change does not just live in one conversation.

Structured elaboration

1. Evaluate the request systematically: what is the impact on current goals if this is added, does it directly serve the same objective or is it actually a different one competing for the same time; what risk does it introduce to quality, to already-tested work, or to team focus; what dependencies does it touch, another team, another system, or work already in flight; and what would count as done, meaning explicit acceptance criteria, since a vague new ask evaluated against vague acceptance criteria is exactly how scope quietly balloons.
2. Present concrete decision options rather than a single answer: include it now, and state precisely what it displaces from the current plan to make room; defer it to the next planning cycle, with a real reason tied to the evaluation rather than just being busy; or deliver it incrementally, shipping the smallest slice that addresses the core of the request now with the rest following later.
3. The scale of the request changes the stakes but not the judgment: a small mid-sprint ask, a change to a single user-interface flow, meaning the on-screen sequence a user goes through, and a much larger mid-program ask, two entirely new features requested by a senior stakeholder, go through the exact same three questions, impact, risk, dependencies, just at different altitude. The mid-program version needs a more thorough analysis and probably involves more people in the decision, while the mid-sprint version can often be evaluated and decided within the same day.
4. Document the agreed-upon change: a short written record of what was requested, the evaluation, the options presented, and which was chosen, kept somewhere the team and stakeholders can both see.
5. Communicate to both audiences distinctly: the team needs to know exactly what changed in their actual work, updated acceptance criteria or a revised task list, while stakeholders need to know what was decided and why, including what is explicitly not changing, so the locked plan does not quietly become renegotiable by default for the next request too.

Worked example

Mid-way through a program to rebuild a company's internal reporting platform, a product vice president asks for two significant new features, a new export-to-spreadsheet capability and a custom-alerting system, neither in the original locked plan. Evaluating: impact showed both features served a genuinely adjacent but different objective, self-service data export and alerting, rather than the rebuild's core objective, replacing the legacy reporting engine. Risk assessment found the export feature low-risk and mostly additive, while the alerting system would require new infrastructure that could delay the platform migration's own testing phase. Dependency analysis showed the alerting system specifically depended on a notification service another team had not yet built. Acceptance criteria for both features did not yet exist and would need defining before any serious estimate was possible.

Decision options presented: include the export feature now, since it was low-risk and additive, by extending the current phase by an explicitly stated 1 week; defer the alerting system to the next program phase entirely, since its own dependency on another team's unbuilt notification service made "now" unrealistic regardless of priority; or, as a middle path for the alerting system specifically, deliver a narrow, incremental first slice, a simple email-only alert on one critical metric, within the current program, with the fuller multi-channel system following once the dependency was resolved. A short decision record captured all three pieces of the request, the evaluation, and the choice. The vice president chose to include the export feature within the extended 1-week timeline and take the incremental email-only alert now, deferring the full alerting system to the next phase. The team received updated acceptance criteria for the export feature and the narrow alert, with the platform migration's core testing phase explicitly protected from the deferred alerting work, and the broader stakeholder group was told the program's core date moved by exactly the 1 week attributable to the export feature, with everything else unchanged.

For contrast, the same judgment shows up at the single mid-sprint scale too: a designer mid-sprint asking to change one confirmation step in a user-interface flow goes through the identical three-question evaluation, just resolved same-day between the individual engineer and the requester rather than as a documented multi-stakeholder decision.

Trade-offs and pitfalls

Treating a mid-program request from a senior stakeholder as automatically higher priority than the locked plan, without running the same evaluation applied to a smaller request, is a common and costly shortcut. Presenting only yes or no instead of the incremental option skips an outcome that often satisfies the requester's real need faster than either extreme. Agreeing to defer a request verbally without documenting it lets it resurface later as if it were never addressed. Extending the timeline to accommodate a new request without naming the exact new date and what caused it leaves the original locked plan looking unreliable rather than deliberately adjusted.

Direct answer

Keeping executive stakeholders confident without burying them in noise means splitting the metric set into a small number of fast, operational weekly indicators owned by the people doing the work, and a smaller set of monthly business-impact metrics owned by the initiative lead, calculated against a real baseline rather than a raw before-and-after, with the narrative always pairing any surfaced risk to a specific decision or ask rather than leaving it as unresolved anxiety in the room.

Structured elaboration

• Weekly metrics (owned by workstream leads): operational and cheap to compute, such as adoption or rollout percentage this week, count of open blockers, and any newly raised risks. These are the numbers that move fast enough to matter at a weekly cadence and don't need executive attention on their own.
• Monthly metrics (owned by the initiative lead): the actual business-impact numbers, such as realized cost savings, adoption rate against the full target population, and any quality or satisfaction signal, since these need a full month of data to be meaningful and are what leadership is actually funding the initiative to move.
• Calculating and attributing impact: compare against a real baseline period (a comparable stretch of time before the initiative started, used as the reference point) or, where feasible, a holdout group (a subset that experiences business as usual while the rest gets the change, isolating the initiative's actual effect), rather than a simple before-and-after that can't separate the initiative's effect from seasonality or unrelated changes happening at the same time.
• Structuring the narrative: lead with the single headline outcome metric and a status color, follow with 2 to 3 supporting metrics, then close with named risks, each paired with a specific decision or resource being asked for, so surfacing a risk reads as a concrete ask rather than an open-ended worry.

Worked example

A six-month initiative automates customer onboarding, currently costing $80 per customer across 2,000 customers a month ($160,000 a month total).

• Weekly metrics: percentage of onboarding volume routed through the new automated flow, count of open blockers, and new risks raised that week.
• Monthly metric, average cost per onboarding: total onboarding spend for the month divided by customers onboarded.
• Month 3 result: 40 percent of volume now goes through the automated flow at a cost of $50 per onboarding, while the remaining 60 percent still costs $80 per onboarding. Blended average: (0.4 times $50) plus (0.6 times $80) equals $20 plus $48, or $68 per onboarding, down from the $80 baseline.
• Attributed savings that month: the $12 reduction per onboarding, times 2,000 customers, equals $24,000 attributable to the initiative that month.
• The same month's weekly data showed automated-volume adoption at 38 percent in week 2, slightly behind the 40 percent plan, with 3 open blockers averaging 5 days old, above a 3-day threshold, which triggered an escalation two weeks before the monthly number would have shown the slower ramp on its own.
• Narrative structure for the monthly executive update: headline (cost per onboarding down from $80 to $68, on pace for the six-month target), supporting metrics (adoption percentage, blocker count trend), then the specific risk (a vendor delay on one integration) paired with the ask (approval to add a temporary contractor for two weeks to unblock it).

Trade-offs and pitfalls

The most common failure is reporting only lagging, monthly numbers, which means a stakeholder finds out about a slipping rollout a full month after it started slipping, exactly when the weekly leading indicators would have caught it early. A second failure is presenting a risk with no attached ask, which reads as noise rather than something the room can act on and trains stakeholders to tune out the risk section entirely. Comparing raw before-and-after numbers without a baseline or holdout is the third common mistake, since it invites a stakeholder to correctly ask whether the improvement was really the initiative or just seasonal variation.