---
title: Revise and refine the common understanding
acode: C1
---

This is the first management activity in the *Weekly Initiation* group.

Each card on the *Integrated Project Board* should have a single team member assigned to it as its *custodian*, to follow up on it and update it on the board. When multiple people work on a single card, only one of them can be appointed as the custodian.

At this point, custodians present their cards, and based on that and the meta-cards of the "project description" column of the board, the team refines the project's common understanding by updating the cards and their sequence, deciding what to do in the upcoming week, detailing the upcoming work, etc.

If a card has to be canceled, instead of removing it from the board, it should be marked as "canceled" and move it to the "closed" column, so that the board contains a full history.

4:: What are the most useful things we can do next for the end users and the customer?
3:: What are the best things to do next from a creator point of view?
2:: What can we do next to bring us closest to the project goal?
1:: If we have deviations, what should we do differently to meet the targets?
1:: Have all hats been involved in revising and refining the common understanding?

The old and new *deliverables* and *follow-up items* (risks, issues, etc.) should be listed and sequenced on the *Integrated Project Board*. Each card should be assigned to someone as its *custodian* to follow up on. The meta-cards in the "project description" column of the board should be updated if there are any changes to the targets or other basic information they contain.

{{< mp3v1-project-board C1 >}}

It's helpful to add some information about the acceptance criteria to each deliverable card on the board to align the work with the goals and make [D2](../../d/2/) more straightforward. If there are codes, standards, or special requirements you have to consider for a specific deliverable, that information should be added to the card on the board as well. If deliverables have similar criteria, a "general acceptance criteria" meta-card could be created in the "project description" column of the *Integrated Project Board* to record them there instead of repeating them on every deliverable card.

If a version of the project's output is already in operation, it should also be examined:

4:: What is the reaction of the users to the existing state of the project output?
3:: How is the output performing in the real world from a creator perspective?
2:: What benefits have been realized so far?

Based on these considerations, new cards may be added to the board, or the existing ones may be changed.

There is also the usual concern:

1:: Are the documents clear and easy to understand?


