OKMajorsGuided Project Management

Project working record

Keep the useful work from your project in one editable record. Use only the sections you need, and carry decisions and evidence into your approved plan, status updates, and closeout.

One record is stored on this browser and device, separately from guide progress. It is not uploaded, shared, or synchronized. Export JSON to keep an editable backup or move to another browser; text exports work in any text editor. Avoid entering sensitive information on a shared device.

Loading local record…

Project readiness and handover

Review the working record before proceeding or handing over. This view reports recorded work; it does not grant approval or certify readiness. It includes retained module evidence even when a module was removed from the guide.

Loading the working record…

Writing prompts are editable starter text. Fill them in, change them, or delete them. Your existing answers are preserved.

Project working record fields

Project context

Keep it brief: problem, owner, boundaries, approval if needed, verification, and a closing notification. Add a log entry only when there is a decision or issue to remember. Changing this selection does not change your track in the guide.

Fictional example

Cedar Support changes its ticket routing rule. Baseline: 12 misrouted tickets per day. Target: fewer than 3 per day for five working days. Jo owns the fix; Sam approves it. Test ten representative tickets and check the next day’s queue. Restore the previous rule if urgent tickets reach the wrong team. Jo sends the outcome and transfers monitoring to the support lead.

State the observed problem, who is affected, evidence, why now, and the proposed approach. For assigned work, record the sponsor’s intent and what still needs clarification. If the approach changes, explain why.

Keep the boundaries visible. Small: the fix, owner, timing, and affected users. Medium: add milestones, dependencies, capacity, and approval. Large: link your project authorization and approved delivery plan; summarize the current baseline here.

Define measurable outcomes before execution. Record a baseline, target, how and when it will be measured, and who accepts the result. Delivery and longer-term benefits may need separate checks.

Before making the change, define what to check, stop conditions, and how to restore service. Afterward, record actual evidence and unresolved problems. If reversal is impossible, obtain the appropriate risk acceptance before proceeding.

Record acceptance, remaining work, and who owns the result. Small: a confirmation and contact may suffice. Medium/large: use the Close Out Summary, link it here, and schedule a benefits check if outcomes take time to appear.

Decisions and operational log

Use an entry for a decision, parked item, risk, issue, scope change, or optional module. Add entries as needed, up to 100. Record the outcome and next action; the guide does not make approvals or contact owners for you.

  • Decision / parked item: options, reason, decision-maker, conditions, revisit trigger and date.
  • Risk / issue / change: likelihood if uncertain, impact, response, approval if needed, owner, deadline and status.
  • Module: objective, test or review criteria, evidence or document location, actual result, outcome, and next main-workflow step. Record unresolved conditions and who will close them.

Keep superseded entries with a clear status to preserve your decision history.

Phase notes and module evidence

These are the same notes and checkpoints edited inside the guide. They are included in JSON and text exports. Importing evidence does not add modules to the workflow; add them from Modules when needed.

No linked work recorded yet. Record a phase or add a connected module in the guide.