Every organization makes two kinds of decisions: small routine ones (which branch opens when, which vendor to renew) and large strategic ones (which programs to fund, how to allocate budget across priorities). The small decisions run on process. The large decisions run on evidence, or, too often, on assumptions disguised as evidence.

A blind spot is a decision you must make but lack evidence to make correctly. The problem isn't that people make bad decisions, it's that they don't realise they're operating without the information they need. Intuition fills the gap invisibly. The strategic shift NLB is making, from "diversity of learning activities" to "improved reading behaviors as outcome", is exactly the kind of decision where blind spots are dangerous: the old metrics (attendance, program count) can look healthy while the new outcome (behavior change) goes unmeasured.

Decision readiness has five dimensions, not just one. You might have the data but no process to maintain it. You might have the process but no agreement on definitions. You might have everything except access. A gap in any single dimension blocks the decision just as effectively as having no data at all. When you document a blind spot, you need to identify which dimension is the bottleneck. That determines what action to take.

• → The most dangerous decisions are the ones you don't realise rely on assumptions
• → Intuition and evidence are partners, not opposites, but intuition without evidence is a risk
• → Check all five readiness dimensions: Data, Process, Ownership, Definitions, Access
• → Document blind spots formally: what's missing, which decision, why it matters, what risks result

Most data work fails not because the data is wrong, but because the question was never clear. A vague request like "we need to understand our reading promotion impact" describes a topic, not a decision. A decision-question names a specific choice: "Should we continue investing in current reading program formats, or shift to formats that show stronger evidence of changing reading behavior?" The difference is actionability. The second version points directly at what data you need.

The Decision Brief is the core tool for this shift. It forces five elements: the decision (specific, actionable), why now (real urgency, not theoretical), options (at least three and always including a pilot), success criteria (measurable before you start), and key questions (what you need to answer to choose between options). If you can't fill in the brief, the decision isn't clear enough to request data for.

Once the decision is clear, you define data requirements using the Factors → Signals → Data chain. Factors are what you care about (demand, quality, risk). Signals are what you can observe (visit counts, borrowing patterns, complaint rates). Data is what gets recorded (timestamped entries, transaction logs). You can't measure factors directly, you infer them from signals captured as data. This chain prevents the common mistake of jumping straight to "what data do we have?" without asking "what would that data actually tell us?"

Finally, not all data is equally important. Must-have data is required to make the decision. You cannot proceed without it. Should-have improves confidence but isn't essential. Could-have is interesting but deferrable. If everything feels must-have, your decision scope is too broad. All requirements should be written in plain language, readable by both your manager and the IT team who will deliver it.

• → Always start with the decision, never the data
• → A good decision-question names a specific action, implies who decides, and points toward needed data
• → Include at least three options in every Decision Brief. Always consider a pilot
• → Use Factors → Signals → Data to define what you actually need
• → Separate must-have from should-have from could-have. If everything is must-have, narrow the decision

Good data work gets rejected not because it lacks value, but because the value isn't communicated effectively. There's a language gap between what data teams speak (tools, platforms, data structures, dashboards) and what leadership speaks (outcomes, risk reduction, cost savings, operational impact). When you pitch in the language of operations, leadership hears cost without context. When you pitch in the language of decisions, leadership hears value.

Most data initiatives create value in one of four categories: Risk Reduction (reducing exposure), Capacity Release (freeing time and effort), Service Improvement (better patron experience), or Strategic Optionality (enabling future decisions). The same initiative can be framed under different categories depending on your audience. This is a communication choice, not an objective classification. If leadership is focused on risk, frame your work as risk reduction. If they care about efficiency, frame it as capacity release.

A justification pitch has four parts: the problem (in business terms, not technical), the urgency (a real deadline or escalating risk), the expected improvement (specific, tied to a value category), and the investment required (realistic, with one-time separated from ongoing, and honest about unknowns). The pitch should be deliverable in two minutes to a senior leader. Credibility matters more than persuasion, acknowledging limitations often strengthens your case.

Data leaders must also translate in both directions. When communicating with IT, specify six things: the decision being supported, the timeframe, required granularity, required history, update frequency, and access requirements. When translating technical constraints back to business, state the implication for decisions, not just simpler words. "The API has a 1000-call limit" is technical. "We cannot provide real-time updates" is the business translation.

• → Frame data work in outcomes, not tools or features
• → Use the four value categories to match your pitch to your audience
• → Present cost and impact together, never cost alone
• → Separate one-time costs from ongoing costs to avoid overstating investment
• → Translate in both directions: business → technical (add specificity) and technical → business (state decision implications)

Anyone who works with data will hear "no." Requests get refused because data isn't available, access is restricted, workload is too high, systems have limitations, costs are unclear, or policies prevent sharing. Hearing "no" does not mean a request is unreasonable, it usually means more information, negotiation, or planning is needed. The difference between effective and ineffective data leaders is how they respond.

The natural reaction to refusal is emotional: frustration, escalating emotionally, or abandoning the decision entirely. The leader's approach is diagnostic: understand the constraint, ask clarifying questions, and propose alternatives. The single most important question is: "What would need to be true for this to be a yes?" This shifts the conversation from refusal to conditions, invites the other party to problem-solve with you, and uncovers hidden constraints you didn't know about.

Different types of refusal require different strategies. Capacity constraints respond to scope reduction and phasing. Policy constraints require finding what's allowed within policy (anonymisation, aggregation). Technical constraints call for feasibility questions and proxy data. Prioritisation constraints need a stronger business case connected to strategic priorities. Value/credibility constraints like "we tried this before and no one used it", require connecting the request to a specific current decision and pre-committing to use the results. Misdiagnosing the root cause leads to the wrong response.

When alternatives are exhausted, escalation is a leadership responsibility, not a failure. Constructive escalation focuses on decisions (not individuals), impacts (not complaints), and options (not demands). The escalation message should describe the decision that can't be made, the data required, the constraint, the consequences, and the alternatives already considered. This ensures leadership understands the risk and has what they need to act.

• → Hearing "no" is normal. How you respond determines success
• → Diagnose the root cause before proposing alternatives
• → "What would need to be true for this to be a yes?" opens doors
• → Proposing alternatives shows flexibility and increases cooperation
• → Escalation is making risk visible. Focus on decisions and impacts, not individuals and complaints

Most training fails in the gap between understanding and doing. Participants leave with good ideas that fade as daily work resumes. Module 5 exists to prevent that by converting learning into a specific, committed action plan.

Sustainable improvement is incremental, not dramatic. The goal is not to transform the organization in 30 days, it's to take one concrete step that builds credibility, demonstrates value, and creates momentum for the next step. Good places to start include: the Intuition Trap (decisions made purely by gut feeling), the Zombie Report (reports everyone receives but no one reads), the Circular Debate (repeated arguments that lack evidence), and the Dead End (data requests previously refused, now you have tools to try again).

Every improvement should connect to a decision. "Get better data" is not an action plan. "Link program attendance to borrowing data so we can decide which reading formats to scale for FY26" is. Success measures must be defined before starting, not after. If you can't say what success looks like at day 30, the scope isn't clear enough.

The Report Evaluation Checklist is the single most universally actionable tool from the training. Before your FY26 workplan presentation, apply five questions to every metric and dashboard: Who uses it? How often? What decision does it support? What action results? If we stopped producing it, what would break? Any metric that can't answer these questions should be strengthened or removed. This requires no approvals, no system access, and no data requests, just honest evaluation.

• → One well-executed improvement beats multiple incomplete plans
• → Define success measures before starting, not after
• → Small wins build credibility, reduce resistance, and create momentum
• → Stopping useless reporting frees time for valuable work
• → Accountability partnerships double follow-through. Find a partner and set a check-in date

Most organisations invest heavily in making decisions and almost nothing in finding out whether those decisions were right. Teams decide, move on, and the next time they look back is the quarterly review, when it is too late to adjust. Module 6 builds the discipline of going back to your decisions and asking whether the assumptions still hold.

The Assumption Audit is the centrepiece. Every decision rests on assumptions. After the decision, each assumption falls into one of three categories: Confirmed (evidence has validated it, it is now a known), Still Untested (you assumed it was true but have not gathered evidence either way, the most dangerous category), or Contradicted (evidence suggests the assumption is wrong, the decision logic may need to change). The most dangerous assumption is the one the team has stopped noticing.

Leading indicators are the early warning system. Most teams track lagging indicators: outcomes that tell you what already happened. Effective teams define leading indicators at decision time and monitor them frequently enough to act before the outcome arrives. The Upstream Question Model traces backwards from the outcome to find the earliest signal you can act on. The test: if this signal changed, would you have time to do something before the outcome changes? If yes, it is a leading indicator. A system of leading indicators across different dimensions (engagement, programmes, service depth, collection, quality) tells you not just that something is wrong but which part of the causal chain is breaking.

The Evidence Check complements the Assumption Audit by scanning for what you were not looking for. Two questions: has any new information arrived that you did not have before? And if you were making this decision today with everything you now know, would you make the same call? After a review, there are only three honest responses: Go (evidence supports continued investment), Adjust (some assumptions shifted, the plan needs updating), or Stop (key assumptions are broken, the evidence no longer supports the investment). Stopping is not failure. It is the review process working.

• → Every decision rests on assumptions. Audit them: confirmed, untested, or contradicted
• → Define leading indicators at decision time, not after the outcome arrives
• → Trace backwards from the outcome using the Upstream Question Model to find the earliest actionable signal
• → A system of indicators tells you where to intervene, not just that something is wrong
• → The most important decision right is the authority to stop an initiative based on evidence

Module 7 connects everything from both days into a single narrative. Instead of teaching new concepts, it walks through one scenario from beginning to end, demonstrating how the five stages of a decision cycle work together: Frame, Assess, Test, Review, Communicate.

Frame the Decision applies the Module 2 discipline. The default question ("Are programmes working?") is a topic, not a decision. The structured version adds options, trade-offs, and a basis for evaluation. A decision question with structure gets an actionable answer. A topic gets a debate.

Assess Confidence applies Module 1's four elements: blind spots, data gaps, assumptions, and conflicting evidence. If the signals point in different directions, that is not noise. It is a signal that something structural has changed. The confidence assessment determines whether to proceed, test first, or slow down.

Design the Test is about finding the smallest pilot that closes the biggest gap. A good pilot is bounded (scope, time, comparison), testable (specific hypothesis), observable (leading indicator defined before launch), stoppable (clear halt criteria), and learning-oriented (success is clarity, not confirmation). A pilot is a test, not a promise.

Review applies the Module 6 disciplines: run the Assumption Audit on the original assumptions, check the leading indicators, apply Go/Adjust/Stop. Mixed results are normal. The discipline is in making the choice explicit and evidence-based rather than defaulting to momentum.

Communicate the Recommendation uses the five-element structure: Context, Tension, Evidence, Recommendation, Consequence. Two minutes, structured, with an explicit recommendation and a named consequence of inaction. End with the limitation statement: "This analysis does not account for..." This is how decisions move.

• → Five stages: Frame, Assess, Test, Review, Communicate. Each requires discipline.
• → A pilot is a test, not a promise. The most important outcome is the ability to stop.
• → Mixed results are normal. The discipline is making the choice explicit.
• → Communicate with Context, Tension, Evidence, Recommendation, Consequence
• → Every recommendation needs a limitation statement: name what the analysis cannot see