⚑ Company users with portfolio access only. Portfolio Tools are granted per person by a portfolio admin - project membership alone never opens them, and external collaborators never see portfolio information anywhere, including on projects they work in. If you don't see Portfolio tools in your sidebar, nothing is broken.
Portfolio Tools answer a different question than the rest of Ceruleo. Projects answer how is the work going; the portfolio answers what does the company intend, and can it afford to intend it. The discipline that makes it work is small but non-negotiable: say how sure you are, write down why, and let the arithmetic find the collisions. Mechanics for everything below: in-app Field Guide → Portfolio Tools.
The one entry rule - work is entered once, then enriched
Every piece of work gets exactly one planning item, created at the moment the company first needs to plan around it - usually Start Portfolio Evaluation on a Relationships opportunity. From then on, everything attaches to that one item: the evaluation project when investigation starts, the delivery project when it wins, every signal, allocation and decision along the way.
The judgment call this replaces: "should I make a project for this yet?" The answer is a rule, not a feeling - a project is made when the work needs hands. Someone must produce a drawing, run a feasibility study, coordinate dated tasks, or bring in an external party. Until then, the opportunity plus its planning item hold everything: the conversation lives in Relationships, the bet lives in planning. A project made early reads as commitment whatever you label it, clutters everyone's project list, and starts work the company hasn't chosen.
Cost of choosing wrong: too early, and your project list stops meaning anything; too late, and evaluation work leaks into email where the portfolio can't see the evidence it produces. When an item starts accumulating notes with no workspace, Ceruleo shows a quiet "evaluation?" hint - that's the too-late failure announcing itself.
Award and kick-off - two dates, two engines
An opportunity's award date is when you expect the deal to be signed - the commercial forecast buckets weighted value there. Kick-off is when the work claims the company - the delivery forecast runs on it, and Start Portfolio Evaluation carries it (with completion) into the planning item's target dates, which is what allocations and the conflict engine compute against. The rule that survives every delivery model:
Kick-off is the first day company resources are committed. Completion is the last day they are free again. Opening night belongs to neither field.
Applied to the ways the company actually works:
- A show in a truck (licensed run): kick-off is kit prep or ship date, completion is the day the kit is back in the warehouse. The kit is claimed for the whole round trip, and a collision with the next conversation only appears if completion means "home again." Refurbishment after return belongs on the resource's reset time, not in these dates.
- Produced in house: kick-off is first production hands - design or fab start. This is the biggest capacity claim, so honesty here matters most.
- External producing partner: still an opportunity - the partner is the counterparty, and the deal has ink and revenue. Kick-off is when the company's own obligations begin (kit hand-off, oversight), not when the partner starts their production.
- No client at all: not an opportunity. An in-house venture has no award date and never will - it belongs in Portfolio Planning as an item without an opportunity: an internal initiative with target dates, allocations, and evidence.
Cost of choosing wrong: enter only the award date and the portfolio believes work starts the day ink dries - capacity reads tight in the award month and loose when the work actually lands. And remember award is not a cash schedule: deposits and revenue shares arrive over a run, so treat the forecast as a pipeline-weight view and leave revenue timing to finance.
Allocations are promises - climb the ladder, don't jump it
The four allocation statuses are a ladder of promise-strength: assumed (the work would need it) → tentative (the plan counts on it) → reserved (it's being held) → committed (it's assigned). The practice is to enter claims at the rung you can actually defend and climb only when something real changed - a decision landed, a contract signed, a date firmed.
Two habits make the resource picture trustworthy:
- Record assumed demand early and honestly. An exploratory job that would need Show Kit B belongs on Kit B's timeline as assumed from day one. Assumed claims cost nothing and are drawn faintly - but three of them stacking up in one quarter is exactly the early-warning pressure the capacity view exists to show. Demand you didn't record is demand the company discovers the hard way.
- Keep reset times real. A kit that needs five weeks of refurbishment between venues has a five-week reset on its resource record, and the conflict engine extends every booking by it. Optimistic reset times manufacture feasible-looking plans that aren't.
When a conflict appears, believe the arithmetic before you argue with it - it shows the rule that produced it (committed × tentative → forecast conflict). Resolving a conflict means changing an allocation or a date, never ignoring a warning until it goes quiet.
Evidence hygiene - the five-minute habit that keeps the plan honest
Confidence in the portfolio is computed from evidence, and the evidence is only as good as the capture habit. After any meaningful client contact:
- Capture the signal at the source. Paste the note into the item's Evidence panel and accept what it proposes, or add the signal by hand - who said it, how authoritative they are, whether it supports the work or cuts against it.
- Reconfirm what you re-heard. If the client repeated the September target, one tap on the existing signal refreshes it. Reconfirming beats re-entering: the history of every confirmation is kept, and freshness is what keeps a signal's weight.
- Record contradictions as contradictions. When the site team says October and the executive says September, both signals stay - linked as contradicting. That disagreement is information; it lowers confidence honestly until someone resolves it. Never supersede a signal just because a newer one disagrees.
- Log the decision, not just the anxiety. "Waiting on capital approval" is a decision record with an owner and a needed-by date, not a worry in someone's head. Overdue decisions drag confidence down automatically - which is the system nagging on your behalf.
The payoff for the habit: when anyone asks "why is Dubai only Medium-Low confidence?", the answer is a list on screen, not a meeting.
Scenarios - ask questions, publish answers
A scenario is a question written down: what if Chicago extends? what if Dubai slips to November? Keep them shaped that way:
- Name the question, not the vibe - "Dubai Delayed", not "Option B v3 final".
- Keep few alive. Two or three live scenarios are comparison; eight are noise. Archive the ones whose questions have been answered.
- Change only what the question changes. A scenario stores disagreements with the working plan - the fewer, the sharper the comparison. If you're overriding twenty things, you're not asking a question, you're drafting a different company.
- Let the comparison table argue. Feasibility, conflict counts and value delta per scenario are the same arithmetic as everywhere else. The scenario that removes a conflict but moves revenue a quarter later is a trade-off made visible - that visibility is the point.
Publishing is the ceremony, and it should feel like one. One person with the authority, one written reason (write it for whoever reads the version history in a year), one impact preview read before confirming. Publishing applies the scenario, versions the plan with a full snapshot, and sends review cards to affected projects. It never touches a project's tasks - and that boundary is what makes teams trust it.
The two-way street with projects
The governance model is one sentence: the portfolio decides what the company intends; projects report what reality allows; neither edits the other.
Downward: when a published change touches a project, its team gets a review card - accept as target or propose an alternative. Answer them promptly; an unanswered card is a plan and a project quietly diverging. Upward: when reality disagrees with the plan - a release date slipping, a kit no longer workable - the project files an impact proposal with a reason, not a hallway complaint. On the planning side, treat accepting a proposal as the deliberate act it is: make the change in planning first, then accept, so the record shows judgment rather than reflex.
Anti-patterns - the four ways portfolios rot
- The wish list. Everything sits at Probable because nobody wants to call a deal Exploratory. The strategic states only mean something if most work is honestly low on the ladder.
- Confidence theater. Hand-set High confidence with no signals behind it. The Evidence panel shows judgment and evidence side by side precisely so this is visible - an empty panel under a High label is its own indictment.
- Zombie scenarios. Last quarter's questions still "live", polluting every comparison. Archive on answer.
- The quiet stale-out. Signals age silently while everyone assumes someone reconfirmed. The Overview counts stale signals for exactly this reason - if that number grows week over week, the plan is coasting on old news.
The weekly rhythm
Ten minutes on the Overview, Monday morning: read the needs-attention list top to bottom, reconfirm or retire the stale signals, sweep the decision calendar for anything due this month, answer whatever sits in the planning inbox (proposals and pipeline suggestions), and glance at assumption health on the published plan. A portfolio maintained ten minutes a week never needs the heroic half-day cleanup - and the Monday read is only as good as the Friday capture habits above.
The admin's half
Portfolio Tools follow the same setup ethic as every vocabulary in this manual: short lists chosen so fast nobody mis-files, and defaults that make the right habit the lazy habit. The admin surface is Portfolio Settings, and there are five decisions to make once and revisit rarely.
Roles first. You (org admin) are implicitly the top of the portfolio hierarchy and the only one who can appoint Portfolio Admins. Below them, grant User to people who plan and Viewer to people who read - and remember portfolio access is deliberately independent of project membership, so granting it never exposes project internals and withholding it never blocks project work.
Shape the strategic states before anyone plans. The nine defaults are sensible, but the words matter: states are the company's shared vocabulary for "how seriously are we taking this". Rename freely - every state maps to a fixed system category (pipeline, planning, committed, executing, suspended, closed), so reports stay comparable whatever you call things. Resist adding states; a vocabulary people can hold in their head beats a taxonomy.
Roll out pipeline mappings gently. Start every stage at Suggest - the confirmation prompt teaches the team what the mapping does while a human still says yes. Promote a stage to Automatic only after the suggestions have been accepted without argument for a while; automatic state changes are audited, but earned trust beats audit trails. "Lost → Cancelled" is usually the first safe automation.
Tune signal freshness to how your clients actually talk. The defaults (verbal target dates stale in 45 days, contracts never) fit most companies, but if your market moves faster, shorten them - a freshness threshold that's too generous is how plans coast on dead information.
Decide your AI stance deliberately. Assisted extraction is off by default and only you can turn it on - it's data governance, not tool configuration. If you enable it, tell the team where the AI activity log lives (right below the toggle) and what it guarantees: every exchange recorded before its result is returned, nothing trained on, nothing retained. If your company's answer is no, the rule-based extraction covers the habit without anything leaving the server - the practice matters more than the machinery.
One ongoing duty: keep the Customize cards choice on the Overview honest for how your company actually reads it, and watch the audit log occasionally - not for suspicion, but because publication reasons and state-change history are the institutional memory of why the plan is what it is.