Hemory TeamOn this page
Your project review is approaching, and the team needs to decide whether the next release should include a requested integration. The task board shows progress, but it does not explain why the team originally deferred that work or what the customer said would make a smaller release acceptable.
Prepare the review by combining that conversation history with current project evidence. Retrieve the relevant decisions and constraints, identify what has changed, and build a short brief around the choices the review needs to make. The goal is a meeting that can resolve the next step, not a longer account of everything that happened.
TL;DR
- Start with the decisions or questions the review needs to resolve, then retrieve only the history that informs them.
- Use past conversations to recover reasons, conditions, commitments, and concerns; use current project records to establish progress.
- Hemory organizes captured discussions so you or a supported connected agent can gather the background without manually rebuilding it first.
- Turn the findings into options, implications, and a proposed next step, with unresolved questions clearly identified.
- A useful review brief tells participants what needs their attention and what decision they are being asked to make.
Define What This Review Needs to Accomplish
This workflow is for a review of a project still in progress: deciding whether to continue the plan, change it, or resolve an obstacle. A weekly status update mainly communicates where things stand. A retrospective examines what the team should learn. A project review may use both kinds of information, but its preparation should reflect the meeting’s actual purpose.
Write a clear outcome for the review:
Decide whether to keep the pilot scope for the next release or include the integration, given the customer’s requirements and the current delivery estimate.
Then identify the questions that affect that outcome. For this review, they might be:
- What did the customer say the pilot must accomplish?
- Why was the integration deferred, and was there a condition for revisiting it?
- What has changed in the requirement or delivery estimate?
- Who can approve a change to scope or timing?
You do not need a fixed number of questions. Use enough to expose the choice and the information needed to make it. A question such as “Where are we behind?” is useful if it identifies what the review can do about the delay.
Retrieve the Context for the Review
Start with the existing plan and the discussion that established it. Add later conversations that changed the requirements, raised a new constraint, or challenged an assumption. This keeps preparation focused on the review’s decision rather than every meeting in the project’s history.
If those discussions were captured in Hemory, summaries, decisions, action items, and open questions give you an initial view of the material. topics, people, Moments, and the timeline help you locate the exchanges behind it.
An AI agent connected to Hemory can help draft this background. Give the connected agent the review purpose before you spend time compiling a manual history. You can ask:
Help me prepare a review of the Northstar pilot release.
The review needs to decide whether to add the integration now
or keep it outside the pilot scope.
Use the available captured discussions about pilot requirements,
the original scope decision, and later changes. Summarize:
- the agreed goal and scope;
- why the integration was deferred;
- conditions or customer needs that could change that decision;
- unresolved questions relevant to the review.
Include conversation references where available. Separate what
participants agreed from proposals and from your interpretation.
Do not infer current completion from an earlier promise.Hemory supplies the available conversation context through the supported connection. You can provide current project documents separately as needed. The agent does not gain access to your task board or other systems merely because it is connected to Hemory.
Without an external agent, ask those questions in Hemory’s built-in Q&A to retrieve the relevant discussion context. Either route should produce a short account of the background, not a collection of every matching passage.
Add Current Evidence to the Historical Context
Past discussions explain the plan. The review also needs to know whether that plan remains workable.
| Question | Historical context | Current evidence to add |
|---|---|---|
| What must the release accomplish? | Customer discussion and scope agreement | Any approved requirement change |
| Can we deliver it on time? | Original estimate and dependencies | Current estimate, completed work, and remaining blockers |
| Does a previous constraint still apply? | Reason for deferring or limiting work | Updated technical assessment or dependency status |
| What decision is needed? | Prior agreement and revisit condition | Available options and their present implications |
For example, a customer may have accepted a manual export for the pilot. That establishes an earlier agreement, not indefinite acceptance. A later request for an integration may represent a new requirement, a question, or a preference. Read the exchange closely enough to know which one it is.
Likewise, an engineer’s earlier promise to complete a component is not evidence that it is finished. Use the current delivery record or an update from the responsible person for that claim.
If you need to summarize that progress first, see our guide to preparing a project status update.
Keep the source types visible in your working draft. “Customer agreed on October 8” and “engineering estimate updated November 1” answer different parts of the review question.
Turn Findings into Options the Review Can Discuss
A list of decisions, commitments, and risks is useful background. The review becomes more productive when that background leads to a choice.
For each important issue, state:
- What needs deciding. Make the choice specific enough that someone can answer it.
- Why it is on the agenda now. Identify the changed requirement, constraint, or unresolved dependency.
- The viable options. Describe the difference that matters, such as scope, timing, or operational effort.
- Your recommendation and its basis. Separate your assessment from what earlier participants agreed.
- What must be confirmed. Name the missing information or approval that affects the choice.
You can ask an agent to turn the retrieved context and current evidence into this structure. Review the recommendation as a proposed judgment, rather than attributing it to the customer or team unless they actually made it.
Not every disagreement is a project risk. Two people may be describing different release phases. Clarify scope before presenting a contradiction to the review.
A Completed Project Review Brief
Suppose the earlier customer discussion allowed a manual export for a limited pilot, while a later discussion raised concern about using that process after expansion. Engineering’s current estimate says the integration would add two weeks. A review brief could read:
Project: Northstar pilot
Review purpose: Decide the release scope and the condition for expansion.
Decision needed
Keep the manual export for the pilot, or add the integration before launch?
Background
The October 8 customer discussion accepted a manual export for a pilot
limited to one regional team. The October 29 discussion raised concern
about using the same process across additional teams.
Current position
Engineering’s November 1 estimate indicates that including the integration
would delay the release by two weeks.
Acceptance of that schedule change has not been established.
Options
A. Keep the limited pilot scope and manual export. Confirm that the
customer still accepts that arrangement; decide the expansion condition.
B. Add the integration before launch. Seek agreement on the revised date.
Recommendation
Keep the limited pilot scope if the customer confirms that the manual
process still meets its pilot needs. Plan integration before expansion.
Questions to resolve
Does the customer's new concern apply to the pilot or only expansion?
Who can approve a revised launch date if option B is selected?
Preparation owner
Account lead: confirm scope of concern with the customer.
Engineering lead: explain the basis of the current estimate.
References
October 8 scope discussion; October 29 customer discussion;
November 1 engineering estimate.The brief separates customer history, current evidence, and your recommendation. Participants can see why the question matters and what would change the proposed answer.
For your own review, reuse the headings and remove any field that does not help the meeting. Keep supporting detail in the referenced material so the brief remains easy to scan.
Check the Claims That Could Change the Decision
Focus your final pass on consequential details: an approval, a customer condition, a delivery estimate, or the scope of a commitment. Reopen the relevant conversation when the wording could change the option you recommend.
Also check that the brief does not present an unanswered search as proof that something never happened. If you cannot establish whether a requirement changed, make that a question for the appropriate person.
The brief is ready when participants can identify the decision, understand the relevant change, compare the options, and see what still needs confirmation. More source material is useful only if it changes one of those judgments.
After the review, record the decision and next steps in the project document you use. Capturing the review in Hemory preserves the discussion behind that update, including the reasoning that may matter when the project changes again.
FAQ
How is a project review brief different from a status update?
A status update communicates current progress, blockers, and next steps. A review brief uses that information to frame questions or choices the meeting needs to resolve. It should make the requested decision clear.
Do I need to search the entire project history?
No. Start with the agreement behind the current plan and later discussions relevant to the review. Expand only when an unresolved reason, condition, or change requires earlier context.
Can Hemory help before I have assembled the background?
Yes. Its organized Memory helps you retrieve captured discussions, and a supported connected agent can use available conversation context to help gather and draft the background. You do not have to manually rewrite every relevant discussion first.
What if the review cannot resolve an open question?
Identify who can answer it, what information they need, and which decision depends on the answer. If an interim plan is necessary, make its assumptions and revisit point clear.
For your next project review, start with one decision that needs context from past discussions. Use Hemory to recover that context, add the current evidence, and prepare a brief that helps the meeting reach a useful next step.
