Project-management frameworks describe orderly planning, governance and delivery. Real work is less orderly. Managers encounter dates that move unexpectedly, product owners who cross technical boundaries, teams that cannot agree how to estimate, risk owners with conflicting interests, and software that encodes a workflow nobody fully understands. These problems are valuable evidence because they show where formal methods meet operating reality.

MTF Institute analysed the 100 most recent public questions available through the Project Management Stack Exchange API on 18 September 2026. The questions were posted from 6 April 2024 through 10 August 2026. We coded each question into one substantive execution-problem family and examined answered status, answer count, views and tags. The objective was not to estimate the global prevalence of project failures. It was to create a dated, diverse snapshot of the problems practitioners chose to articulate publicly and translate those signals into a practical diagnostic.

The principal finding is a contrast. Agile and delivery-process questions were the largest family and almost all had an accepted or otherwise marked answer. Planning, scheduling and estimation formed the second-largest family but had a much lower answered rate. The pattern suggests that communities can often discuss process roles and rituals, while context-dependent forecasting and schedule mechanics remain harder to resolve remotely. For students and managers, the implication is direct: do not stop at method fluency. Build evidence around assumptions, dependencies, data quality and decision rights.

Research question

The report asks:

Which execution problems appear in 100 recent public project-management questions, which problem families attract weaker resolution signals, and what repeatable diagnostic can a manager use before choosing a tool or method?

The unit of observation is one distinct public question. The analysis does not count headings, required-versus-preferred labels or page structure. It codes the concrete management problem represented by the title and tags. The practical output is EXECUTE-8, an eight-part triage that helps a manager turn an ambiguous execution complaint into an evidence-based next action.

Methodology

Source and collection

We used the official Stack Exchange API with site=pm, sorted by creation date in descending order, and requested 100 questions. The capture occurred on 18 September 2026. The returned sample contained exactly 100 distinct question IDs. The newest question was dated 10 August 2026 and the oldest 6 April 2024. Project Management Stack Exchange is a comparatively low-volume specialist forum, so “recent” refers to the 100 latest available questions, not to a fixed 30- or 90-day window.

For reproducibility, the archive contains the API-derived source inventory with question ID, date, title, source link, author attribution where returned, tags, score, answer count, view count, answered status and assigned problem family. It also contains category results and a machine-readable summary. We did not redistribute question bodies. Titles and metadata retain source links and attribution under the applicable Stack Exchange licence terms.

Inclusion and exclusion

We included each distinct question returned in the first 100-item API response. We did not choose only popular, answered or recent-looking questions. We excluded no observation after collection. This reduces researcher discretion but means the sample includes narrowly technical and lower-engagement questions alongside broader managerial problems.

The population is not “all project managers” or “all project failures.” People who post on a public English-language question site are self-selecting. Platform norms, moderation, user expertise and search behaviour shape what appears. The findings are descriptive signals from this public corpus.

Coding model

Each question received one primary problem family using an ordered ruleset based on tags, with title keywords as fallback. The families were:

  • Agile and delivery process;
  • planning, scheduling and estimation;
  • tools, data and workflow;
  • risk, quality and change;
  • teams, conflict and leadership;
  • scope, requirements and product definition;
  • career, learning and certification;
  • roles, governance and decision rights;
  • other execution questions.

One primary category prevents double counting and supports comparison, but it simplifies questions that span several problems. For example, a Scrum question about communication could reflect delivery process, role clarity and stakeholder management. The source inventory preserves tags so another researcher can recode the sample.

Measures

We counted questions per family, calculated each family’s share, and measured the proportion marked answered. We also calculated median views and median answer count within families. These are platform signals, not measures of management importance. High views may reflect age, search visibility or a broadly worded title. A marked answer indicates platform resolution, not proof that the recommendation worked in the asker’s organisation.

Results at a glance

Across the 100 questions, 73 were marked answered. The median question had 180.5 views and two answers. The leading tags were agile with 23 appearances, ms-project with 20, scrum with 12, project-management-style with 12 and jira with 10.

Primary problem family Questions Share Marked answered Answered rate Median views Median answers
Agile and delivery process 38 38% 37 97.4% 216 3
Planning, scheduling and estimation 32 32% 14 43.8% 155 1
Tools, data and workflow 7 7% 5 71.4% 128 1
Other execution questions 7 7% 6 85.7% 100 1
Risk, quality and change 5 5% 4 80.0% 118 1
Teams, conflict and leadership 5 5% 4 80.0% 275 1
Scope, requirements and product definition 3 3% 1 33.3% 68 1
Career, learning and certification 2 2% 1 50.0% 237.5 1.5
Roles, governance and decision rights 1 1% 1 100.0% 134 2

Small categories should not be ranked as if their percentages were stable. The one governance question cannot support a general claim about governance resolution. The two large families, however, provide a meaningful within-sample contrast.

Finding 1: process questions dominate, but process knowledge is not the main gap

Agile and delivery-process questions represented 38% of the sample. Scrum, product-owner, Scrum-master, software-development and Kanban tags were frequent. These questions included boundaries between roles, incremental delivery, estimation within Agile teams and the interpretation of established practices.

Thirty-seven of 38 questions in this family were marked answered, with a median of three answers. Public communities appear well equipped to offer interpretations, patterns and role-based advice for named methods. Shared vocabulary helps: contributors can refer to a sprint, product owner or Scrum master without reconstructing the entire operating context.

This does not mean Agile problems are solved easily at work. A forum answer can explain the intended role boundary but cannot supply the authority, incentives or trust required to enforce it. For learners, the useful lesson is to distinguish method clarification from organisational resolution. Ask first whether the team misunderstands the framework or whether leaders have created contradictory goals. Training can address the former; governance and negotiation are needed for the latter.

Finding 2: planning, scheduling and estimation show the largest resolution gap

Planning, scheduling and estimation represented 32 questions, but only 14 were marked answered, an answered rate of 43.8%. Median answers were one. The family included planning, scheduling, Microsoft Project, Primavera P6, estimation, story points and related mechanics.

This gap is practically plausible. A scheduling question often depends on calendar configuration, dependency type, constraints, baseline logic, progress status, resource levelling and tool behaviour. A title and short explanation may not contain the file or assumptions needed to diagnose the result. Estimation questions also depend on uncertainty, team familiarity, scope quality and the purpose of the estimate.

The finding changes the learning decision. Managers should not treat planning as software operation alone. A defensible plan needs a chain from scope and assumptions to activities, dependencies, capacity, uncertainty and control rules. When a date moves, the diagnostic should identify which input changed and whether the movement is economically meaningful—not merely force the date back.

Finding 3: tools are visible, but tool problems often conceal model problems

ms-project appeared 20 times and jira 10 times. Tools, data and workflow formed seven primary-category questions, while tool tags also appeared inside planning and Agile categories. This overlap matters: the software is often where an underlying model becomes visible.

A schedule tool cannot decide whether a dependency is real. A ticket system cannot determine whether one backlog item is valuable. A dashboard cannot choose tolerance. Configuration questions should therefore be separated into three layers:

  1. mechanical: which setting or formula produced the result;
  2. model: whether the represented relationship matches the work;
  3. management: what decision follows from the information.

Teams waste time when they solve the mechanical layer and assume the decision is now correct. A manager should require a plain-language explanation of the model before accepting a tool output.

Finding 4: scope questions were few but weakly resolved

Only three questions were primarily classified as scope, requirements and product definition, and one was marked answered. The sample is too small for a population claim, yet the signal is consistent with an important practical problem: scope ambiguity is contextual and politically negotiated.

Requirements are not merely a list to be completed. They connect user need, business outcome, constraint, acceptance and change authority. When a scope dispute appears, ask who can decide, which evidence supports the need, what changes elsewhere, and how acceptance will be tested. A requirements template without decision rights can document disagreement without resolving it.

Finding 5: team and leadership questions attract attention

The five team, conflict and leadership questions had a median of 275 views, the highest median among categories with more than one question, although the category is small. People may seek these questions because interpersonal problems are consequential and difficult to discuss internally.

The managerial implication is to avoid diagnosing every conflict as attitude. Examine role ambiguity, resource competition, incompatible success metrics, missing authority and unaddressed risk. A conversation is necessary, but changing the system may be more important than improving the wording of the conversation.

What the sample does not prove

The results do not prove that 38% of all project problems are Agile-related or that scheduling has a universal 43.8% resolution rate. The sample is a platform snapshot. Questions are influenced by what users consider appropriate to ask, what search has not already answered and which software or methods are popular among participants.

The ordered coding rules can also affect category size. agile was prioritised ahead of planning, so a question tagged both Agile and estimation was classified as Agile and delivery process. This makes the contrast conservative in one sense and debatable in another. The archived source inventory allows sensitivity analysis with alternative coding priorities.

Views accumulate over time, so older questions have more opportunity to be seen. We report medians but do not treat them as current demand. Marked-answer status reflects platform conventions and can miss a useful unaccepted answer. No causal inference is made.

EXECUTE-8: a practical triage for project friction

The research suggests that managers need a diagnostic connecting framework, data, authority and action. EXECUTE-8 can be used when a project complaint arrives as “the plan is wrong,” “the team is not Agile,” “the tool changed the date,” or “nobody owns this.”

E — Expected outcome

State the outcome and the decision currently blocked. Replace “fix the schedule” with “decide whether the October regulatory launch remains feasible and which scope option protects compliance.” Without a decision, analysis expands indefinitely.

X — eXecution boundary

Define the work, time horizon and organisational boundary. Identify what the project controls and what it only influences. Many accountability disputes come from mixing supplier delivery, client acceptance and business adoption.

E — Evidence and data

List the minimum evidence: baseline, current forecast, assumptions, source data, acceptance results and recent changes. Check tool settings separately from business facts. If evidence is missing, label the conclusion provisional.

C — Constraints and capacity

Identify resource, policy, technical, contractual and timing constraints. Separate fixed constraints from preferences. A team may debate estimation while the real issue is one specialist allocated across four initiatives.

U — Uncertainty and risk

Record ranges, dependencies, triggers and response owners. Do not hide uncertainty inside a single date. Ask which assumption would change the decision and how soon it can be tested.

T — Trade-offs and decision rights

Specify feasible options, consequences and the authorised decider. If a product owner and engineering lead disagree, clarify which decision each owns and where the trade-off crosses tolerance.

E — Escalation and communication

Define what must be escalated, by when and with which evidence. Send different information to deciders, doers and affected stakeholders. Escalation should request a decision, not merely report discomfort.

8 — Eight-day learning loop

Set a short review: what changed after the decision, which indicator moved and what assumption was wrong? Eight days is not universal; it is a forcing device for rapid feedback. Longer projects can use eight working days or the next meaningful control point.

Worked example: an unexpected schedule change

A programme manager sees a six-week shift after updating progress in the scheduling tool. The team asks for help “fixing the dates.” Using EXECUTE-8, the manager reframes the expected outcome: decide whether customer migration can still begin before a contractual deadline.

The execution boundary includes data conversion, security approval, user acceptance and training, but excludes a separate marketing campaign. Evidence review shows that a predecessor was changed from start-to-start to finish-to-start, one task retained an obsolete constraint and the security team’s calendar contains limited availability. The six-week movement is therefore not one problem.

Capacity analysis finds that the security reviewer is the critical scarce resource. Uncertainty analysis shows that data-quality remediation ranges from one to four weeks. The team develops three options: restore parallel work with additional control, reduce the first migration cohort, or move the contractual date. The sponsor owns the commercial choice; security owns control acceptance.

The team selects a smaller first cohort, preserves the security gate and adds a data-quality decision trigger. Communication includes the new forecast range and the assumptions behind it. Eight working days later, the team checks defect volume, security throughput and data remediation. The tool date is now an output of a management decision rather than a number forced to match a target.

How students can apply the findings

Students should build a portfolio that demonstrates execution reasoning, not only framework recall. Choose one case and create:

  • a one-page decision statement using the first two EXECUTE elements;
  • an evidence register separating observed facts, estimates and assumptions;
  • a dependency network with acceptance conditions;
  • a capacity view for the scarcest role;
  • a three-point forecast or scenario range;
  • a decision-rights table and escalation threshold;
  • an executive exception report;
  • an eight-day review documenting what changed.

This portfolio directly addresses the research gap. Planning questions are hard to resolve when context and evidence are missing. A strong artifact makes that context inspectable. In an interview, explain not only the final plan but the assumption that changed, the option rejected and the result measured afterward.

Implications for managers and organisations

For managers, the first implication is to fund planning quality. Forecasts require time, data and cross-functional participation. Pressuring teams for one date without uncertainty produces apparent certainty, not control.

Second, integrate method training with authority design. Knowing Scrum roles does not resolve a conflict when incentives or executive direction contradict them. Leaders must define decision rights and tolerances.

Third, treat tool configuration as a governed model. Maintain calendars, dependencies, formulas, permissions and change history. Require independent review for high-consequence plans.

Fourth, create safe escalation. Public questions can indicate that practitioners lack an internal place to ask. A planning clinic, PMO office hours or peer review can surface issues before they become public failures.

Fifth, evaluate learning through decisions. A course project should require a forecast, risk response, trade-off and retrospective—not only a quiz on terminology.

Limitations and future research

This snapshot covers one English-language specialist platform and 100 questions. Future work could compare Reddit communities, professional forums, internal lessons-learned repositories or job vacancies, subject to access and privacy. A second coder could independently classify questions and measure agreement. Topic modelling could test whether the ruleset misses latent clusters, but human review should remain because management meaning is contextual.

A repeated quarterly sample would show whether AI-enabled planning, agentic tools or new delivery methods change the problem mix. Outcome research could also examine whether questions with reproducible files, data and explicit decisions receive faster or more useful answers.

Archival package and transparency

The Zenodo record and DOI contain the searchable report PDF, source inventory, category results, summary and deterministic collection and analysis code. The technical report number is MTF-RR-2026-09-18-01. Readers can inspect the source links and reproduce the descriptive calculations. Any correction should preserve the dated snapshot and document the change rather than silently altering the original evidence.

Practical next step

Take one unresolved execution issue from your current work. Run EXECUTE-8 in a 30-minute session. Do not open the project tool until the expected decision, boundary and evidence are written. End with one authorised choice, one trigger and one eight-day review. If the team cannot identify the decider or acceptance evidence, that is the first problem to fix.

For structured development in planning, scheduling, risk, stakeholders and project control, review MTF Institute’s Project Management programme. Compare the published curriculum with the capability gaps revealed by EXECUTE-8 and confirm current enrolment terms. The research does not imply that one course solves every context. It provides a dated map of where practitioners struggle and a method for turning those struggles into better evidence and decisions.

Conclusion

The 100-question snapshot shows two sides of project capability. Shared process language attracts strong public resolution, while planning, scheduling and estimation remain difficult when data, assumptions and context are incomplete. Managers need both: fluency in methods and the discipline to connect outcomes, evidence, capacity, uncertainty and authority. EXECUTE-8 converts that lesson into a practical review. The purpose is not to make every project predictable. It is to make uncertainty visible enough for responsible decisions.