Do executive project dependencies have an accepting owner?

Research question and decision

For dependencies on the executive project path, can the team identify who accepted the dependency, what delivery means, when it is needed, and who decides whether the evidence is sufficient? The unit of analysis is one dependency that links an executive-sponsored project milestone to another owner or system. This is a descriptive study of an authorized operating record, not an employee scorecard or a claim about every leadership team. The practical decision is whether the recurring weakness belongs in project coordination, functional management, executive sponsorship, or specialist review. ^[1][2]

The work sits inside the established executive-support niche. O*NET describes executive administrative work that includes scheduling, preparing reports, conducting research, arranging meetings, and handling information. Those activities support evidence collection and coordination. They do not transfer the executive's judgment, a director's duty, or a specialist's authority to the person maintaining the record. A coordinator can make the dependency visible, seek acceptance, maintain dates, and route an exception. The coordinator cannot assign resources owned by another leader or accept technical, financial, legal, or security risk. ^[2][3]

The GAO data reliability guide defines reliability in relation to the intended use and directs reviewers to consider accuracy, completeness, and applicability. For this study, a record can be useful even when it is incomplete, provided the report shows the missing field and does not turn absence into a favorable result. The reviewed sources were checked on September 18, 2026. ^[1]

Population, fields, and inclusion rules

Freeze the eligible-case register before calculating results. Collect project and milestone, dependency statement, requesting owner, proposed accepting owner, acceptance event, delivery definition, source link, need-by date, risk signal, exception decision, delivery evidence, reviewer, and downstream effect. Include accepted dependencies, proposed work without acceptance, changed dates, partial deliveries, rejected handoffs, external blockers, and dependencies discovered after a milestone moved. Keep a case in the register when a field is missing, and mark the value as unknown rather than filling it from memory. ^[1]

Choose a period long enough to include ordinary work and exceptions, then state its exact start and end. Deduplicate records by the originating identifier, not by a similar title. If one case appears in calendar, messaging, and project systems, preserve the source links and treat the records as one case unless the preregistered rule says otherwise. Record any change to the rule before rerunning the analysis. ^[1][4]

The case register should distinguish observed facts from reported explanations. A timestamp, permission event, or signed disposition is observed within the limits of its system. A participant's explanation is reported. A reviewer interpretation is analysis. A missing record stays unknown. That separation prevents a tidy workflow narrative from outrunning the evidence. ^[1]

Measures and review procedure

Report the eligible count first. Then report completion for each required field, time between defined events, clarification count, exception count, correction count, and final dispositions. Use medians and ranges only when timestamps mean the same thing across cases. A system-generated update and a human acceptance are different events and should not share one label. ^[1]

Have a second authorized reviewer reclassify a purposive sample that contains routine cases, missing records, exceptions, corrections, and at least one disputed case when available. Publish the sample rule, the disagreements, and any definition that changed. Do not report a reliability percentage from a convenient subset while omitting cases that were harder to interpret. ^[1]

Before reviewing outcomes, write down what would count as complete, late, corrected, reopened, and unresolved. Define the evidence required for a disposition. This reduces the temptation to move a threshold after seeing the results. If leadership changes the operating rule during the period, split the analysis or disclose the mixed rule rather than presenting one false comparison. ^[1]

Privacy, access, and retention

Collect the least information needed to answer the question. Replace personal message content with a coded event when the text is not necessary. Restrict the working register to named reviewers, record exports and transformations, and set a deletion or retention date before collection. NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk; it does not make the reviewer the owner of the underlying data. ^[4]

Apply access according to role, purpose, and the reviewed system's approval process. NIST SP 800-53 provides a catalog of security and privacy controls, including access-control concepts that can inform the study design. The publication should describe the control without exposing confidential content, credentials, internal locations, or a map that would make protected records easier to find. ^[5][4]

Record only the minimum evidence needed to support a public statement. If a confidential case can be reported only as an authorized status, say so. Suppression is not evidence that the case went well or badly. It is a limit on what the public analysis can inspect and should appear in both the denominator note and the limitations. ^[4][5]

How to interpret the result

A missing field identifies a record gap, not a person's motive. A long interval may reflect incomplete evidence, an unavailable decision owner, deliberate waiting, a changed priority, or a system timestamp that does not represent attention. Review case notes before assigning an operational cause, and keep disputed explanations visible when the record does not resolve them. ^[1]

Do not compare teams unless their populations, definitions, systems, and authority are comparable. Do not convert this sample into a universal staffing ratio or productivity benchmark. BLS and O*NET describe occupations and work activities at a broad level; they do not establish how many support hours a particular founder, board, or project needs. ^[3][2]

Read the result against the operating choice it was designed to inform: whether the recurring weakness belongs in project coordination, functional management, executive sponsorship, or specialist review. Start with individual cases, then look for a repeated pattern. One missing acceptance or delayed disposition can justify a correction, but it does not establish a systemwide trend. If several cases share a documented cause, test the smallest relevant process change before expanding a role or adding another reporting layer. ^[1][2]

The role boundary should remain visible in the recommendation. A coordinator can make the dependency visible, seek acceptance, maintain dates, and route an exception. The coordinator cannot assign resources owned by another leader or accept technical, financial, legal, or security risk. A useful recommendation names the support task, the accountable decision maker, the evidence that closes the task, and the event that requires escalation. This makes the proposed change reviewable without implying that better administration can replace authority or professional judgment. ^[2][5]

Use the findings to select one bounded change, name its owner, and repeat the same measure after an appropriate period. Suitable changes include adding a required field, moving a readiness check earlier, naming an acceptance step, or narrowing an access path. The next review should preserve the first definitions or clearly explain why they changed. ^[1][5]

Limitations and conclusion

Formal project records tend to represent planned work better than informal favors, exploratory work, and dependencies that teams notice only after a failure. Formal records may also overrepresent teams that use the approved system consistently. A short period can be dominated by an unusual board cycle, launch, absence, or travel schedule. Report those conditions and avoid causal language. ^[1]

This design cannot prove that a support intervention caused a faster decision, safer handoff, or better business outcome. It can show whether the defined record became more complete, exceptions became easier to inspect, and accountable owners received a clearer request. Those are useful operating observations, but they remain bounded to the population and period studied. ^[1][4]

The defensible conclusion is narrow: measure one dependency that links an executive-sponsored project milestone to another owner or system with declared definitions, preserve missing and disputed cases, and assign any change to the owner with authority to make it. Executive support can improve preparation, routing, continuity, and record quality. Consequential judgment stays with the accountable executive, director, system owner, or qualified specialist. ^[2][5]