A sample built on fictional content. Whitlow Ferris Partners is not a real firm and this reflects no real engagement.
Whitlow Ferris Partners is a fictional management consulting firm working for private-equity portfolio companies. It runs on Microsoft 365: the playbook and the deliverable templates live in the WFP Knowledge library on SharePoint, each engagement has a folder in the Engagements library beside it, and the firm’s method and positions have been organized and approved. The deliverable assembler builds the skeleton of a readout from the playbook module and the engagement’s own data extracts, the engagement manager edits it, and the engagement partner reviews it before it is presented. Each step below is the screen a real person would be looking at.
The value in this workflow is how much of a readout changes inside the last forty-eight hours before it is presented, and how long an engagement manager spends assembling the skeleton before the analysis starts. At this firm, nine of the twenty-six readouts in the past year had three or more slides changed inside the last forty-eight hours, which is the reason the partner review rule exists. We would measure both on your own readouts. The diagnosis measured proposal development and not this workflow, so we do not put a number on it.
2:24The assembler watches the engagement channel from inside the firm’s Microsoft 365 tenant. It read Jen’s request, opened the ENG-2611 folder in the Engagements library, took the slide structure from PB-100 modules 4 and 6 and the sponsor format from SP-2, and built the outline against the extracts in the folder. Nine minutes after the request, the skeleton is waiting on SharePoint.
| # | Slide | Rests on, click to open | Numbers from, click to open |
|---|---|---|---|
| 1 | Value bridge: the diagnostic baseline to the week-four run-rate | · · | |
| 2 | The deal team’s three KPIs: cash conversion cycle, inventory days, days payable | · · ⚑ Two versions · inventory days 71 (v2) or 67 (v3); days payable 41 (v3) or 44 (v4) | |
| 3 | Sprint status: the eight workstream actions against plan | ||
| 4 | Receivables: aging by customer group and the collections cadence | ||
| 5 | Receivables: the ten largest past-due accounts | ||
| 6 | Inventory: days on hand by product family | ⚑ Version changed · v2 reads 71 days, used in week two; v3 (September 15) reads 67 | |
| 7 | Inventory: slow-moving stock and the disposition plan | ||
| 8 | Payables: terms by vendor tier and days payable | ⚑ Version changed · v3 read 41 days, used in week two; v4 (today, 1:52) reads 44 | |
| 9 | Procurement: the spend cube and the addressable base | ||
| 10 | Procurement: the three sourcing waves and their timing | ||
| 11 | Risks, and the decisions the committee is asked to make | ||
| 12 | The next four weeks |
2:24This is the outline as the assembler left it, on the firm’s own SharePoint. Click any source to see the extract or the module a slide rests on. The two numbers that moved since the week-two readout are flagged with both versions shown, and nothing about them was decided here.
Marcus, this is the QA-1 review of the Beltline steering committee readout, version 3, the version for Wednesday’s 9:00 committee. The deck is in the ENG-2611 folder. Two extract versions changed since week two; my decisions on both are on the engagement page with the reasons. One thing I want your read on: the bridge still uses the v2 inventory count and the v3 recount is in the footnote on slide 5. Say if you want the committee to see both.
Jen
PBeltline_SC_readout_wk4_v3.pptx · ENG-2611 › Readouts · version 32:58Jen owns the deck. She decided both flags, moved two slides, cut one, and left a note for Marcus, and each decision is recorded with its reason. The partner review went on Marcus’s calendar for Monday morning, forty-eight hours ahead of the committee, on the version he will be reviewing. The software assembled the outline, and the people decided what is presented.
Keep v2 on the bridge. The footnote reads fine. Add one line on when finance ties the recount to the GL so Dan doesn’t ask. Good to present.
Added. Finance ties it out by the 30th; the line is on slide 5.
Mon 9:35This is the deck Marcus reviewed on Monday morning, in the slide sorter: the value bridge first, the three KPIs second, and a source line in every footer. His one comment sits on the inventory slide, and Jen answered it by ten. The deck goes to the committee on Wednesday at 9:00 with that line added and nothing else changed after the review.
This is the whole machine. Three places the knowledge already lives, one piece of software inside the tenant, checks that are code, flags that go to the engagement manager, and a partner reviewing every readout before it is presented.
The skeleton was on SharePoint nine minutes after Jen asked, with the module and the extract named on every slide and the two numbers that had moved flagged before anyone built a chart. Jen spent her afternoon on the decisions, and the partner review went on the calendar the same day. Before the software, an engagement manager built the skeleton from the last readout she could find, and the source of a number was whatever the analyst remembered.
At a law firm, this is the board memo or the closing summary assembled from the matter file, each statement citing the document it rests on. At an accounting firm, it is the audit committee deck built from the workpapers, with every figure tied to its schedule. At an architecture practice, it is the design review package built from the current drawing set, with the sheet and revision on every page. The pattern is the same: assembled from what the firm already has, every number showing its source, a person editing and a partner reviewing.