Hypothesis Before PowerPoint: Problem-Solving Discipline for Owner Teams

Around the world, owners and sponsors of large capital projects pour enormous effort into presentations. Options studies arrive as polished decks. Gate packs fill with charts. Steering committees sit through hours of slides that look decisive. Yet a familiar failure repeats: the pack arrives before anyone has written a falsifiable hypothesis about what is true, what must be tested and what would change the recommendation if the facts come out differently. The slides become the work. Data collection expands to fill the calendar. By the time contradictions appear, the room is already committed to a story that was never tested. Hypothesis before PowerPoint is the discipline that reverses that sequence — structure and test once the question is set, then let slides serve the insight.

This comprehensive blog will explore problem-solving discipline for owner teams on large capital projects after the decision question has already been named. It is written for sponsors, project directors, project managers, owner representatives, programme management consultants, study-cell leads and board members who commission, review or challenge options studies, root-cause packs and gate recommendations. We will mark a brief boundary with deciding the question first, outline a consulting-style analysing operating system and its day-to-day toolkit, show how an early hypothesis and a quick test of assumptions prune work, apply mutually exclusive and collectively exhaustive structuring through issue trees, design analysis work plans that refuse to boil the ocean, collect only for an early story line with ghost charts, interpret and present with so-what discipline, and close with how owner teams can transfer these tools under — not instead of — capital front-end realism.

1. Slides Without a Testable Story

On large capital projects the calendar rewards visible progress. A commissioned study that produces a thick deck looks like progress. A study that produces a one-page hypothesis, a short list of must-be-true assumptions and a pruned analysis plan can look like delay — until the thick deck is found to answer a convenient version of the problem, or to rest on data that never spoke to the recommendation.

The failure mode is not laziness. Capable teams work hard. They gather more interviews, more cost runs and more schedule variants. Hard work without a testable story still wastes the owner’s scarce front-end attention. Professional analytics practice warns that teams that skip framing can solve the wrong challenge with great precision. The twin failure, once the question is named, is to skip structuring and testing: precision without a hypothesis is still a slide factory.

The symptoms are easy to recognise in a study kickoff. The first workshop produces a slide outline before anyone writes what would have to be true for the leading option to be right. Interview lists grow by organisational chart rather than by issue-tree leaf. Cost and schedule sensitivities are run for every variant that can be modelled, while the commercial premise that would kill half those variants is never tested. The pack then arrives on time, dense and internally consistent — and still unable to say which facts would change the recommendation.

Owner teams feel this pressure acutely. Options cells report to steering committees that expect charts on a fixed date. Package problem-solving tiger teams are stood up after a delay or a cost spike and are asked for a recovery pack by Friday. In that climate, opening PowerPoint first feels responsible. It is often the most expensive habit in the study. The antidote is not fewer slides at the end. It is refusing to authorise major collection until a hypothesis, a short assumption test and a pruned analysis plan exist in writing.

2. Boundary: Decide the Question First — Then Structure

This blog does not teach how to name and own the live decision. That discipline — deciding the question before choosing among options — is treated in a companion ProTrain piece, Decide the Question First: Framing for Large Capital Projects. Systems thinking and professional analytics practice both warn that efficiency at the wrong objective compounds error: the righter an organisation does the wrong thing, the wronger it becomes. Agreeing the business question, and who owns it, is therefore upstream of everything that follows.

Once that question is stable enough to structure, a different toolkit takes over. Mutually exclusive structuring, issue trees, initial hypotheses, work plans, ghost charts and so-what interpretation exist to test answers — not to invent a more convenient question midstream. If the question keeps dissolving under analysis, the problem is still upstream in ownership or context. More structure will not fix an orphaned or contested frame. Practitioner guidance on problem framing puts the same point simply: framing discovers the right question, while solving finds the right answer. This blog is about the second half of that sequence.

A useful triage, treated at length in the framing companion, also keeps tools matched to failures. A wrong problem needs the question restarted. A wrong estimate inside a right question needs outside-view forecasting. A contested context that will not settle needs scenario-based reframing. Hypothesis craft, MECE trees and ghost charts address structured solving inside a settled question. Applying them as if they could repair an orphaned frame only produces a more elegant pack aimed at the wrong objective. The sections below assume the key question has been named and owned, and focus on what owner problem-solving cells should do next.

3. An Analysing Operating System — and a Day-to-Day Toolkit

Established consulting problem-solving practice describes a fact-based, hypothesis-driven analysing cycle with four steps, followed by presenting and managing.

Analysing

1. Framing — define boundaries of the already-owned question; break the problem into components; form an initial hypothesis.
2. Designing — determine the analyses needed to prove or disprove that hypothesis (work planning).
3. Gathering — collect only the data those analyses require.
4. Interpreting — test the hypothesis; develop a course of action.

Presenting asks for clear structure and genuine buy-in. Managing covers the engagement team, the client relationship and the individual’s own sustainability. Implementation and leadership sit at the edge of that model and are not treated here as a full change-management method.

A later engagement handbook reorganises the same lineage into a day-to-day operating toolkit with two halves. One half is interpersonal: talk, evaluate, assist and motivate. The other half is analytical: Frame, Organize, Collect, Understand and Synthesize — often summarised as FOCUS. Under Frame, the rules begin with identifying the key question, developing the issue tree and formulating hypotheses before heavy data collection. Organize adds a high-level process map, a content map to test hypotheses and an early story line. Collect insists on ghost charts, meaningful interviews and relevant secondary data. Understand centres on “so what,” implications for constituents and documenting the key insight on every chart. Synthesize closes with buy-in, specific recommendations and telling a good story.

Figure 1: Once the key question is owned, the analysing cycle runs Framing → Designing → Gathering → Interpreting, then Presenting — with FOCUS as a day-to-day toolkit under that cycle, not a rename of it.

Two stacking rules matter for owner teams. First, keep the analysing lettering and the FOCUS lettering separate. FOCUS maps onto Framing, Designing, Gathering, Interpreting and Presenting with different names; it is an operating toolkit under the process, not a claim that those letters are an official firm training acronym. Second, do not equate this analysing cycle with industrial front-end loading gates or with outside-view forecasting. The consulting operating system structures recommendation quality. Capital definition quality and forecast realism are adjacent disciplines that still have to be stacked in — they are not renamed by MECE or by FOCUS.

4. Hypothesis Before Research — the Quick and Dirty Test

Hypothesis-driven problem solving forms an initial hypothesis early, from limited facts already known and a short team discussion — not after exhaustive research. The hypothesis sketches a roadmap for research and analysis through to presentation. Claimed benefits in that practice include saving time, making decision making more effective and forcing early identification of dead ends.

The first validation step is deliberately light: the Quick and Dirty Test. List the assumptions that must be true for the hypothesis to hold. If any of those assumptions is false, the hypothesis fails — often without heavy analysis. That test is how owner teams escape the habit of commissioning a six-week data pull to discover, in week five, that a must-be-true commercial or technical premise was never available.

Figure 2: An early hypothesis is screened by a Quick and Dirty Test of must-be-true assumptions, then expanded into an issue tree that guides focused analysis.

Two rules protect the discipline. When later facts contradict the hypothesis, change the hypothesis, not the facts. When an initial hypothesis cannot yet be formed, analyse available facts until a solution direction emerges — then resume the cycle. Neither rule licenses inventing a hypothesis before the key question is owned. A sharp hypothesis aimed at a convenient substitute question merely accelerates the wrong problem.

5. MECE, Logic Trees and Issue Trees

MECE — mutually exclusive, collectively exhaustive — is a decomposition quality rule. Separate the problem into distinct, non-overlapping issues, and ensure that no issue relevant to the problem has been overlooked. Nothing is missed and nothing is double-counted. The rule constrains how any tree or task list is built; it is not itself a content framework.

Two related tools put the rule to work. A logic tree lists all components of a problem hierarchically and finishes as a detailed MECE map of the problem space. There may be more than one valid breakdown; the representation chosen should fit the audience and the analyses that follow. An issue tree is the evolved form: each branch is an issue, often phrased as a question, that can be broken into MECE sub-issues. Answering those questions quickly determines whether the initial hypothesis holds. After a Quick and Dirty Test clears a hypothesis, the issue tree guides analysis design. Thinking should be exhaustive; investigation should be selective. Not every branch needs equal depth.

On large capital projects this matters because issue trees are easily confused with work breakdown structures and with front-end deliverable lists. An issue tree is a hypothesis-test plan. A work breakdown structure sequences product. A front-end loading package sequences definition deliverables before authorisation. Using MECE to tidy a deliverable checklist does not prove that the recommendation has been tested. Using an issue tree to postpone Basic Data or shaping work does not make the capital case more realistic. Keep the objects separate.

6. Designing: Work Plans That Prune the Ocean

Designing the analysis — called work planning in that consulting practice — usually follows the initial hypothesis. The engagement lead determines which analyses are needed, assigns owners, discusses data sources and sketches how the likely end product should look. A comprehensive work plan begins from the issue tree and records, for each analysis: sources of information, a brief description of the likely end product, the person responsible and the due date. Sometimes the lead sketches a “ghost pack” of end-product templates to set expectations. The act of writing analyses and then prioritising and pruning can itself revise the hypothesis.

Figure 3: A work-plan row ties issue, hypothesis, analysis, sources, end-product sketch, owner and date — an analysis WBS, not a capital definition checklist.

Design principles from the same lineage keep the work honest: start from the hypothesis; get priorities straight; forget absolute precision where it does not change the decision; triangulate; find key drivers; keep the big picture; and do not boil the ocean. “Do not boil the ocean” is the anti-pattern most visible on large capital projects. Owner study cells under schedule pressure often respond by gathering everything that might someday be useful. The work plan’s job is to refuse that expansion: every analysis line must earn its place against the hypothesis and the end-product sketch.

Key-driver focus is the constructive twin of that refusal. Not every branch of an issue tree deserves equal analytical investment. The work plan should make the prioritisation visible: which leaves, if answered, would most change the recommendation; which leaves are hygiene that can wait; which leaves are interesting but irrelevant to the owned question. Triangulation — approaching the same must-be-true claim from more than one imperfect source — often beats a single precise model that rests on one fragile input. Absolute precision that does not move the decision is decoration.

Here the adjacency with capital front-end loading must stay explicit. Work planning sequences analyses for a recommendation. Front-end loading sequences project definition and the execution plan before authorisation. Both front-load thinking. They are not the same object. A tidy analysis work plan does not score as best-practical front-end loading, and a strong front-end loading score does not prove that an options recommendation was hypothesis-tested. Owner leaders should ask for both checks at a gate, not treat one as a proxy for the other.

7. Collect for the Story — Ghost Charts and an Early Story Line

Gathering is where many owner studies quietly fail. Interviews multiply. Secondary data sprawl. The pack grows thicker while the story stays thin. The day-to-day toolkit answers with two artefacts that force collection to serve the argument.

The first is the ghost chart — also called a ghost slide. Drafted early, it has three parts: a title that states the anticipated insight or “so what”; a data label naming what will be shown; and a rough sketch of the data. Teams are told not to format a sophisticated chart with fake polished numbers. Titles and labels are expected to change as real data arrive. The point is to think in insights throughout, not only at the end. Teams that skip ghost charts and gather first often discover late that key story data are missing.

Figure 4: A ghost chart carries an insight title, a data label and a rough sketch — so collection serves the story rather than the other way around.

The second artefact is the story line: an early outline of the engagement argument, designed almost from day one, that migrates into a storyboard as data arrive. The hallway question behind it is simply “What’s the story?” The story is expected to change when hypotheses are disproven; that change is success of the method, not failure of the team. Organize around content hypotheses with the end in mind, not around the easiest surface buckets. Synthesize then tells the story with specific recommendations and client buy-in — after Understand has forced the so-whats onto the charts.

Interviews and knowledge management still matter under Gathering. Interview guides, careful listening and reuse of prior firm or owner knowledge reduce reinventing the wheel. Interviews are both data and a path to buy-in when handled with respect for the interviewee’s time and for the difference between issues and people. Knowledge management — culture, infrastructure and technology that make prior lessons findable — stops each study cell from rediscovering what the owner already paid to learn. Those practices support the ghost pack; they do not replace it. Collection without an early story remains boiling the ocean under another name.

A practical test for an owner study lead is simple. Before authorising a week of interviews or a major secondary pull, ask to see the ghost titles those interviews are meant to fill and the story-line beats they support. If the answer is “we will find the story in the data,” the study is not yet ready to collect. Curiosity is not a work plan.

8. Interpreting and Presenting With Discipline

Interpreting asks a blunt question of every chart and every analysis line: what’s the so what? The same lineage emphasises eighty–twenty focus, sanity checks, respect for the limits of analysis and generating the end product through the decision-maker’s eyes. If facts contradict the hypothesis, the hypothesis changes. Forcing facts to fit a preferred pack is the failure mode the method exists to prevent.

Presenting then serves tested insight. Structure must be clear enough to pass an elevator test: can the recommendation be stated coherently in the time of a short ride? Simplicity beats decoration. Prewiring — sharing conclusions with key audiences before the formal meeting — avoids theatrical surprise and surfaces real objections while they can still be answered. Tailor the pack to the audience. Carry one message per chart. Buy-in is part of presenting, not an afterthought once the slides are frozen.

On large capital projects these presenting rules are easy to misuse. A compelling storyboard is not a validated outside-view forecast. A prewired steering committee is not the same as closed shaping among parties with enforceable claims on value. Elevator-test clarity does not replace Basic Data readiness or front-end definition quality. Keep presenting craft in its lane: it transmits a tested recommendation; it does not create capital realism.

Interpreting also has a humility clause. Analysis has limits. Not every uncertainty yields to another spreadsheet. When the remaining uncertainty is about the ambient context rather than about a testable claim inside a settled question, the right move may be to escalate for reframing rather than to polish another sensitivity case. Owner leaders should reward teams that kill their own hypothesis early at least as much as teams that defend a pack through a gate. Otherwise the incentives quietly rebuild the slide factory.

9. Owner-Team Application on Large Capital Projects

Transferred carefully, this operating system is useful for owner strategy cells, options studies, package root-cause teams and other problem-solving workstreams that sit under an integrated owner team. Industrial project-leadership practice already notes that owner problem-solving cells can borrow MECE issue trees, initial hypotheses, work plans, interview guides and engagement-team management for options and root-cause studies — with the qualification that those tools do not replace holistic project-director selection, core leadership practices or front-end loading gates. The consulting analytic operating system sits under the capital leadership and practice chain; it does not rename that chain.

Figure 5: Three layers that must not be merged — owned question, MECE/hypothesis analysing OS, and capital realism (front-end loading and outside-view checks).

An integrated owner team remains the organisational home for this work. Integration means the needed owner functions are on the project during scope development, empowered to decide for their function, reasonably continuous and reporting to the project leader. Without that home, a hypothesis-driven study cell becomes another orphaned analysis stream — precise, busy and disconnected from who can change the decision. Frame ownership and team integration are therefore complementary: one names who can change the question; the other puts the functions that must test the answer in the room.

Typical transfer settings include a concept or configuration options study before scope freeze; a root-cause cell after a cost or schedule breach that may or may not justify a recovery plan; a commercial or interface problem that cuts across packages; and a strategy cell advising a sponsor on whether an opportunity should proceed into heavier definition spend. In each setting the protocol is the same: owned question, early hypothesis, Quick and Dirty Test, MECE issue tree, pruned work plan, ghost charts, so-what interpretation, then presentation. What changes is the adjacency stack — Basic Data readiness, shaping closure, front-end loading score and outside-view checks on any capital number the recommendation will carry.

Stacking cautions for capital claims should be written into every study charter.

• Framing and FOCUS Frame are not industrial front-end loading phases. Do not score a study’s Frame step as if it were a definition gate.
• A Quick and Dirty Test of consulting assumptions is not reference-class forecasting. Capital cost, schedule and benefit claims still need outside-view checks inside Interpreting.
• Ghost charts structure analytic slides. They are not front-end deliverable lists and not a substitute for Basic Data completeness.
• Presenting craft and story line quality are not shaping closure among claimants and not authorisation readiness.
• Alumni how-to evidence from consulting handbooks is not randomised-trial evidence and not industrial-project outcome models. Application statements in this blog are transfer guidance for owner teams, labelled as such.

A related large-project research strand emphasises thinking slowly in planning and acting fast in delivery, because planning is relatively cheap and safe while delivery is expensive and dangerous. That spirit aligns with hypothesis and work-plan front-loading. It still does not turn FOCUS letters into front-end loading gates. Map the clocks; do not merge the names.

10. A Practical Protocol for Owner Problem-Solving Cells

Drawing the strands together, owner teams can install a short protocol without inventing firm-secret steps or public case-interview folklore.

1. Confirm the owned question. Open the study charter with the decision sentence from the framing companion: choice, owner, timing, success criteria and boundaries. If that sentence cannot be written, stop and escalate — do not start structuring.
2. Write the initial hypothesis on one page. Use limited facts already known. List Quick and Dirty Test assumptions beside it. Date both.
3. Build a MECE issue tree. Phrase branches as questions that can validate or invalidate the hypothesis. Be exhaustive in thinking; selective in investigation.
4. Fill the analysis work plan. For each priority leaf: analysis, sources, end-product sketch, owner, due date. Prune anything that does not change the recommendation. Refuse ocean-boiling collection.
5. Draft ghost charts and a one-page story line before major collection. Titles state anticipated so-whats. Sketches stay rough. Update both as facts arrive.
6. Interpret on a fixed cadence. Ask “what’s the so what?” of every chart. When facts contradict the hypothesis, change the hypothesis in writing. Stack outside-view checks on any capital number the recommendation will carry.
7. Present for buy-in, not theatre. Pass the elevator test. Prewire. One message per chart. Separate recommendation clarity from authorisation and shaping gates.
8. Keep a decision record. Note what was expected and why. Compare later with what happened. That record protects against hindsight rewriting a lucky or unlucky outcome as if it were process quality.

Time pressure will push teams to skip steps one through five and open the slide master. That is precisely when the protocol earns its keep. A thin, tested pack that kills a bad path early is more valuable to a sponsor than a thick pack that arrives on time and wrong.

Sponsors can reinforce the protocol with three habits. First, refuse to put an options or recovery study on the steering agenda unless the pack opens with the owned question, the current hypothesis and the Quick and Dirty Test assumptions. Second, ask which analysis lines were pruned and why — pruning is evidence of design, not of incomplete work. Third, when a recommendation carries capital cost, schedule or benefit claims, ask explicitly where the outside view entered Interpreting. Those three habits cost minutes in a meeting and save weeks of decorative analysis.

Conclusion

Large capital projects are rarely short of slides. They are often short of falsifiable stories. Once the decision question is named and owned, the work of owner problem-solving cells is to structure, hypothesise, prune, collect for the argument, interpret honestly and present for buy-in. A consulting-style analysing cycle — Framing, Designing, Gathering, Interpreting, then Presenting — supplies the spine. A day-to-day FOCUS toolkit supplies rules of engagement, ghost charts and an early story line under that spine, without renaming it. MECE and issue trees keep decomposition honest. The Quick and Dirty Test and the work plan keep the ocean unboiled. So-what interpretation and prewired presenting keep slides in service of insight.

None of that replaces deciding the question first, completing Basic Data, closing shaping or scoring front-end loading. None of it substitutes for outside-view forecasting on capital claims. Stacked under an integrated owner team, however, hypothesis before PowerPoint gives sponsors and project directors a practical way to stop paying for precision that never tested the recommendation. Basic Data as the unglamorous foundation of design is examined in a separate ProTrain piece. Forthcoming ProTrain blogs will examine front-end loading and the seven sponsor mistakes as distinct topics. The instruction for this blog is narrower and immediate: own the question, then refuse any pack that cannot show its hypothesis, its must-be-true assumptions and the analyses that could have killed it.

References

1. Ackoff, R. L. (2004). Transforming the systems movement. The Systems Thinker. https://thesystemsthinker.com/transforming-the-systems-movement/
2. Bailey, K. (2026). Problem framing in strategy. Corporate Finance Institute. https://corporatefinanceinstitute.com/resources/strategy/problem-framing/
3. Flyvbjerg, B., & Gardner, D. (2023). How Big Things Get Done. Currency.
4. Friga, P. N. (2009). The McKinsey Engagement: A Powerful Toolkit for More Efficient and Effective Team Problem Solving. McGraw-Hill.
5. INFORMS. (2024). INFORMS Analytics Framework: Explore. Institute for Operations Research and the Management Sciences. https://www.informs.org/Professional-Development/INFORMS-Analytics-Framework/Explore
6. Merrow, E. W. (2024). Industrial Megaprojects: Concepts, Strategies, and Practices for Success (2nd ed.). John Wiley & Sons.
7. Merrow, E. W., & Nandurdikar, N. S. (2018). Leading Complex Projects: A Data-Driven Approach to Mastering the Human Side of Project Management. John Wiley & Sons.
8. Rasiel, E. M., & Friga, P. N. (2002). The McKinsey Mind: Understanding and Implementing the Problem-Solving Tools and Management Techniques of the World's Top Strategic Consulting Firm. McGraw-Hill.
9. Williams, T., Vo, H., Edkins, A., & Samset, K. (2019). A Systematic Literature Review: The Front End of Projects. Project Management Institute.