“The fourteenth of April,” Priya read. “Eighty-five percent confidence.”
The chart filled Daniel’s second screen: a smooth grey hill made of ten thousand simulated futures, a dashed line at the eighty-fifth percentile, and beneath it a sentence he could have pasted straight into a board deck. Based on historical throughput, 85% of simulations complete the remaining scope by April 14, 2027.
It was eight on Wednesday evening, in the fourth week of Daniel’s assessment. Board prep was at ten the next morning, and Victor Lang had asked for the launch date, not the pilot.
“I asked it to do what I would have done by hand,” Daniel said. “Fourteen months of closed issues from GitHub Projects. The release scope from the product contract, broken into items. Sample the weekly throughput, run the backlog to empty, ten thousand times.”
“That method needs comparable work,” Priya said. She pulled a chair over and did not sit in it. “Let me see the history.”
She opened the data the assistant had sampled. Eleven hundred and forty closed issues. A median of nineteen a week.
“Here is what you forecast from.” She read titles at random. “Dark mode for the sidebar. Rename assistant templates. Fix tooltip overlap. Conference demo, approval animation. Most of these are a day of work. Some are an hour.” She switched to the scope list. “And here is what you are asking it to forecast. Permission-aware retrieval across connected sources. SCIM provisioning. An audit export a customer can reconstruct. Consolidate orchestrator v1. We have never done one of these. Not once. There is nothing like them in the history for it to sample.”
“So the curve is wrong.”
“The calculation can be right and still describe a different company: the one that built the prototype.” She sat down at last. “And that history includes last month’s nineteen merges that nobody reviewed. Once we account for the reviews we skipped, the numbers may get slower before they get better.”
Daniel looked at the hill for a while. It was the most persuasive thing he had produced in four weeks, and that was exactly what worried him. Victor would remember the date and forget the dashed line.
He closed the chart and left it out of the deck.
Board prep was in Olivia’s office, which had a smaller table than the boardroom and a whiteboard nobody erased. Olivia, Evan, Leila, Marcus, and Rachel sat around it. Victor joined on the screen.
Daniel had rebuilt the deck after Priya left, and it was honest. The first slide showed the planned enterprise release completing somewhere between April and October. The second listed twenty-three risks, each with a likelihood and an owner. The third listed nine assumptions behind the range.
Victor read all three without speaking. Then he took his glasses off.
“I have sat through a great many engineering forecasts,” he said. “They come in two kinds. The first is a date the team does not believe. The second is this.” He lifted a printout toward his camera. “A range from April to October is not a forecast, Daniel. It is a refusal with error bars.”
Evan did not quite smile.
“And twenty-three risks, ranked by nothing,” Victor went on. “If everything on this page could sink us, nothing on it tells me where to put money. Which three would you spend money to retire?”
Daniel had prepared to defend the absence of a single date. He had not prepared to hear that his honesty was unusable, and the uncomfortable part was that Victor was right. He had spent four weeks refusing false precision and had arrived with something nearly as unhelpful: uncertainty no one could act on.
“I can answer that,” he said. “Not well enough in this meeting.”
“When?”
“Tuesday, at the board session. A narrower range, the risks ranked by what they would cost us, and the dates on which we learn whether they are real.”
Marcus had been turning a pen over on the table. “The planned release is May,” he said, “if we stop writing documents about it.”
“Which planned release?” Leila asked.
He looked at her.
“I mean it,” she said. “There are two products on that slide. One is the release Northstar is preparing to test. The other is everything we added when we wrote the word enterprise. Daniel has drawn one range across both, and that is why it is six months wide.”
Daniel looked at his own slide and saw that she was right too.
They worked on Saturday in the small room, under Elena’s wall. The five red dots from the previous week now had names beside them. Hannah, Noah, Priya, Omar, and Sofia sat at the table. Ravi was on the screen, in his kitchen. Leila had brought the product contract and a roll of tape.
Daniel began by taking away the single number.
“For each item on the scope list, the owner gives me a range,” he said. “One you think would cover nine outcomes in ten. Put the rare early finish and the rare disaster outside it. Then the assumption that range depends on, and the earliest date we will know whether that assumption is true.”
“And if I have no idea?” Sofia asked.
“Then the range is wide and the next question is what would make it narrower. No idea is a finding. A confident number with nothing behind it is not.”
It took the morning. Hannah would not give one range for permission-aware retrieval across both connectors. She split it in two: iManage, which her team was already building for Northstar and could estimate in weeks, and SharePoint at the scale of a second tenant, which nobody had attempted and which she estimated in months. Omar gave a narrow range for the SCIM work already promised to Northstar, then raised an item that needed more than engineering time.
“SOC 2,” he said. “Type I covers the design of our controls at a point in time. Type II also tests whether they operated effectively over a period. We are planning for January through June, then the auditor’s testing and reporting. On that schedule, I would plan on autumn. Some of the buyers in Evan’s pipeline require it before they sign. We can staff the preparation. We cannot hire our way past the period the report has to cover.”
Ravi gave the widest range in the room. Consolidating orchestrator-v1 into the agent runtime would take six weeks with the two engineers he had asked for and did not have, and something closer to five months without them.
“Five months is not a forecast,” he said. “It is me doing it at night.”
“Then those are two staffing scenarios,” Daniel said. “We show both, and the date by which the people have to be in place.” He wrote it down that way.
At noon he gave the assistant the owners’ ranges and assumptions and asked it two narrower questions than he had asked on Wednesday. Which assumptions was the overall range most sensitive to? And, written as Victor Lang, what were the ten questions a skeptical former SaaS CEO would ask about this plan?
The assistant drafted scenarios with and without Ravi’s hires, with SharePoint delayed, and with less capacity under the new review rules. Noah caught the same engineers assigned to two jobs at once. Hannah pointed out that a late retrieval change would also delay Priya’s tests. They corrected the sequence before comparing completion dates.
Three assumptions drove the largest changes: the two engineers Ravi needed by December, permission-aware retrieval generalizing from iManage to SharePoint for a second tenant, and how much work the teams could finish under the new review rules. The other twenty risks stayed in the register. Some had serious consequences even if they barely moved the launch date.
Priya read the third one twice. “That is my point from Wednesday,” she said. “We do not know our own throughput. Not the prototype’s. Ours, under the rules we wrote last week.”
The second answer was ten good questions. Daniel had already prepared for eight of them. The ninth, about which assumption would fail first, he had not thought through, and he spent an hour on it. The tenth was a question about competitor response that he decided did not belong in Tuesday’s meeting.
Then Leila stood up with the tape.
She took the scope list apart and rebuilt it on the wall in two columns. On the left, the release Northstar’s pilot would help prove: evidence-backed analysis, iManage and SharePoint with permission fidelity, Entra sign-in with SCIM, audit records a customer could reconstruct, citations that still resolved months later, one Canadian region, actions proposed and never executed. On the right, everything the word enterprise had added: versioned and approved assistants, a second region, five more connectors, self-serve tenant onboarding, policy-controlled execution, and a SOC 2 Type II report.
“The left column is Release 1,” she said. “The right column is what we earn after it.”
They forecast the columns separately, keeping the shared people and dependencies in the plan. The left came out between mid-March and mid-June: much of the work had owners and near-term tests in the pilot. The additional engineering in the right column could finish between late May and late September. The Type II report had its own autumn planning date. They could not call the full enterprise release ready until both were complete.
Leila marked SharePoint’s availability beyond Northstar as the first cut if May came under pressure. The pilot promise still stood. Permission fidelity, tenant isolation, auditability, and citation integrity stayed underlined in both columns.
“We can offer fewer things,” Priya said. “We cannot lower the test for the things we offer.”
Daniel stood back from the wall.
“So we can give the board a date or a scope,” he said. “Not both. Not yet.”
Olivia read the revised deck on Monday evening at her own table, with Daniel across from her and the harbor going dark outside.
“I raised eighteen million dollars on conviction,” she said. “If I walk into that board with two ranges, they will hear that the CEO does not believe her plan.”
“Then let us show conviction about the decisions we can make,” Daniel said. “We can protect May by deciding now what leaves the release first. We can fund the tests that tell us whether the plan holds. We cannot guarantee that a second tenant’s SharePoint will behave, or that the controls will pass the audit.”
“And May?”
“By the end of May for Release 1. Roughly four in five for the left column as it stands, in my judgment and the team leads’. The enterprise engineering by then is closer to one in ten, and the Type II report falls outside May on our audit plan. I would not sell one in ten to a customer, and I do not think you want to sell it to the board.”
Olivia was silent for a while. She turned to the page with Leila’s two columns.
“I will present the choice myself,” she said. “A fixed date with flexible scope. If the CEO proposes narrowing the release to hold the date, it is strategy. If the Director proposes it, it sounds like an excuse.”
Daniel had been about to offer to do it. He was glad he had not.
The board met on Tuesday afternoon in the boardroom, with two members in the room and three on the screen. Olivia gave the choice in four minutes. Then Daniel put up the brief.
It was one page. Two engineering ranges and a separate audit constraint. Three assumptions that determined the ranges, each with an owner. Four dates on which the ranges would narrow or the board would hear why they had not: the eighteenth of November, for Northstar’s committee result and the first six weeks of reviewed delivery data; mid-December, for Ravi’s staffing and the consolidation schedule it made possible; mid-February, for SharePoint retrieval in a second tenant and a fresh capacity forecast; and the end of March, for a production-readiness review of the Release 1 candidate.
Beneath them were the conditions for narrowing or stopping, including the one Olivia had set three weeks earlier. If Northstar’s own team could not measure a material improvement on the work their partners signed, the company would revisit the evidence position before it spent another quarter building around it.
Victor read it for a long time.
“Four in five,” he said. “Where does that number come from?”
“From judgment,” Daniel said. “Mine, the four managers’, and Priya’s, checked against the scenarios on this page. It is not a measured success rate. What I can promise is that you will see it change, and why.”
“Engineers’ ranges have a habit of moving right.”
“Then track the edges, not the middle. At every milestone you get both edges of both ranges. If the right edge moves, you will hear which assumption moved it before you have to ask.”
Victor put his glasses back on and asked the question that had not appeared among the assistant’s ten.
“If the right edge of the enterprise range is September, what does this company look like in October?”
The room went still. Everyone in it could count. Fourteen months of runway from the first of September ended in the autumn of the following year, and a financing round took months to close.
“It looks like a company raising money on a release it has not finished,” Daniel said. “That is why we are asking you to back Release 1 and approve Ravi’s two hires. May leaves us time to put customer results into a financing process. In February, with three milestones behind us, you decide whether the evidence justifies the rest of the enterprise investment.”
Evan spoke for the first time. “And what do I tell prospects in the meantime?”
“May, for the release Northstar will help prove,” Leila said. “For the rest, a planning window and what has to be true before it becomes a commitment.”
“Customers hate ranges.”
“Customers hate surprises more,” Rachel said.
The vote took a minute. The board approved the two hires. The end of May 2027 became the commitment for Release 1, with Leila’s left column as the starting scope and SharePoint’s broader availability first to leave. The readiness checks still had to pass. If scope cuts could not protect them, Olivia would return to the board to change the date. The enterprise scope remained a planning range. No one would make an external commitment to it without Daniel and Leila. Each milestone became a confidence review on the board calendar.
Victor stayed on the line after the others had dropped.
“That was better than Thursday,” he said.
“Thursday was useful.”
“It usually is.” He paused. “Your widest range on that page was not technical. You noticed.”
Daniel had.
After the room emptied, he opened the register and sorted the assumptions by their effect on the completion date. Above SharePoint and Ravi’s staffing was the line Priya had forced into existence on Wednesday night: R&D delivery capacity under reviewed, owned change. Its owner was Daniel. They had tested scenarios from half the prototype’s throughput to slightly more. Its evidence column said none yet.
He had spent four weeks studying the product, the customer, the architecture, and the promise. He had not yet studied the organization that would have to keep it.
He opened his calendar and began booking conversations, thirty minutes each, with everyone in R&D.
When work is new to an organization, a single date can conceal more than it explains. A useful forecast includes a range, the assumptions that make it wide, and the dates on which those assumptions will be tested. Executives who ask for a date are usually asking for something legitimate: a basis for funding, hiring, selling, and financing. The Director’s job is to give them that basis without dressing a guess up as knowledge.
Daniel’s first answer failed in the opposite direction. A six-month range with twenty-three unranked risks gave the board little basis for a decision. Victor’s objection is the one every Director should expect: uncertainty is not a plan. A useful range shows what to fund, test, narrow, or stop. A wide range may itself be evidence that the proposed scope is not ready for a commitment.
Daniel makes two commitments: a May release with explicit scope choices, and a sequence of learning milestones that will test the forecast. At each review, the board gets both edges of each range and the reason either edge moved. New evidence may widen a range; the obligation is to act on it and report it.
| Milestone | What it tests | If it holds | If it fails |
|---|---|---|---|
| Northstar committee, Nov 18 | Measured customer value; first six weeks of reviewed delivery | Update both forecasts against observed results | Revisit the evidence position or the capacity assumption; a wall failure stops pilot use immediately |
| Mid-December | Two AI-platform engineers in place; consolidation schedule | Replace the staffing assumption with an executable plan | Reforecast Ravi’s work and its dependencies |
| Mid-February | SharePoint retrieval in a second tenant; updated capacity | Reassess scope and May confidence | Defer broader SharePoint availability; preserve Northstar’s commitments |
| End of March | Production-readiness review of Release 1 | Confirm the path to May | Cut optional scope and recheck; escalate if the minimum release cannot pass |
Report the edges, not the midpoint. A midpoint can look stable while the right edge drifts for months.
For uncertain work, holding both date and scope fixed often pushes the adjustment into quality or unpaid effort. Leila’s two columns turned one vague release into a May commitment and a planning range for the additional enterprise work. The date matters because the company needs customer results before financing. Optional scope can shrink in an order agreed in advance. Isolation, permission fidelity, auditability, and citation integrity remain release conditions. If the minimum useful release cannot meet them, the date must return for a decision.
Some elapsed time cannot be compressed by adding engineers. A SOC 2 Type II report covers control design and operating effectiveness over a specified period. Aureline’s January–June plan, followed by audit work and reporting, makes autumn its planning window. That timing depends on the reporting period and audit plan; the period must meet the report users’ needs. Preparation and audit scope still need active management.
Monte Carlo forecasting from historical throughput is useful when the work items and delivery conditions are comparable. Aureline’s history was a prototype’s: small items, little review, no enterprise controls. The simulation was precise about the wrong population. For unfamiliar work, decompose it, ask owners for ranges with an explicit coverage level, and test the assumptions that move the completion date. Account for dependencies and shared people before combining estimates. Daniel’s next six weeks of reviewed delivery would begin to supply relevant history; they would not yet prove his probabilities were calibrated.
AI reduced the cost of exploring the forecast. It ran ten thousand simulations, drafted staffing and capacity scenarios, and argued the deck from a skeptical board member’s point of view. That last exercise found a question Daniel had not thought through. The scenario comparisons became useful only after the owners corrected the resource conflicts and dependencies.
It also produced the most dangerous object in the chapter: a precise, persuasive date built on the wrong data. The model did exactly what it was asked. Only someone who knew what the history contained could see that the method did not fit. And the question that mattered most in the board meeting, what the company looked like a month after the range’s right edge, was not on the assistant’s list. It came from a board member who had once had to raise money on an unfinished product.
Humans must decide:
A probability given to a board needs a stated basis. Daniel’s four in five is a judgment; the opening chart’s eighty-five percent is a model result conditional on its inputs. Neither establishes accuracy by itself. Keep the forecasts and compare them with outcomes over time, so confidence can eventually be tested rather than merely asserted.
Wrightery
AURALIS DELIVERY CONFIDENCE — BOARD, END OF SEPTEMBER
Engineering scope Forecast range P(by end of May) Status
Release 1 mid-Mar – mid-Jun ~4 in 5 May 2027 commitment*
Enterprise additions late May – late Sep ~1 in 10 Planning only
Ranges and probabilities: judgment informed by owner estimates and scenarios.
Both ranges describe completion dates in 2027 under the current scope.
*May holds through optional scope cuts; readiness checks remain mandatory.
First cut: SharePoint availability beyond Northstar. Pilot promise stands.
Assumptions that set the width Owner Known by
1. Two AI-platform engineers by Dec Ravi mid-Dec
2. Permission-aware retrieval holds Hannah mid-Feb
for SharePoint in a second tenant
3. Throughput under reviewed change Daniel mid-Feb
SOC 2 Type II: Jan–Jun reporting period; audit/report planned for autumn 2027.
Full enterprise readiness requires both engineering and the report.
Decision: approve two AI-platform hires; reassess enterprise investment in February.
Stop / narrow conditions
- Ethical wall fails → no pilot access until fixed and verified
- Northstar cannot measure a material gain → revisit the evidence position
- March review fails → cut optional scope and recheck; escalate date if core fails
Use one page per consequential release, refreshed at every milestone, with the previous version attached so readers can see what moved.
DELIVERY CONFIDENCE BRIEF
Release: Decision owner:
Committed element: date / scope (choose one)
Minimum useful scope and mandatory release conditions:
Brief version: Previous version:
1. RANGES
For each scope column:
Scope:
Range and coverage level (e.g., intended to cover 9 outcomes in 10):
Probability of target date, and whose judgment it is:
Dependencies and shared capacity included:
2. ASSUMPTIONS THAT SET THE WIDTH (no more than five)
Assumption: Owner: Known by (date): Cost to retire:
3. CALENDAR-BOUND ITEMS
Item: Earliest date under this plan: Basis / change options:
4. LEARNING MILESTONES
Date: What we will know: Effect on each edge if it holds / fails:
5. CONDITIONS
Continue if:
Narrow if (and in what order scope leaves):
Escalate date if minimum scope cannot meet release conditions:
Stop or rethink if:
6. CHANGE SINCE LAST BRIEF
Left edge moved from ____ to ____ because:
Right edge moved from ____ to ____ because:
The brief does not make the future certain. It shows the board how uncertain the plan is, what each milestone will reveal, and when each answer will arrive.
Wrightery is in private build. Join the waitlist and we'll bring you in as soon as a seat opens — then describe one deliverable you already produce, and watch your AI analysts research it, cross-check it and draft it for your review.
No credit card. We'll email you the moment your seat is ready.
Rather talk it through? Book a 30-minute meeting ↗