Start with one deliverable
Open the project board or document you already use. Choose a concrete result, such as a reviewed proposal or a finished presentation. Describe what “done” means for that result. Avoid mapping the entire organization when the question concerns one blocked delivery.
Rayito can explain the visible tasks and help draw their relationships. It should distinguish information written on the board from relationships you supply in conversation. If a task owner or approval is missing, keep it as an open question rather than silently assigning responsibility.
Draw prerequisites instead of a prettier list
In the example, a draft enables review and design. Those activities can proceed together, but delivery needs both. The arrows communicate that rule. They do not estimate duration, assign people, or promise a completion date.
Ask why each arrow exists. Does the next task genuinely require an output, or do the tasks happen to appear next to each other? Removing a false dependency can reveal work that is already possible. Adding a missing one can explain why a schedule has repeatedly slipped.
Locate the decision that is actually blocked
A status such as “in progress” can hide different situations. Someone may be actively working, waiting for an answer, or unable to begin. Ask which result is missing and who can clarify it. That is more useful than coloring every overdue item red.
Walk through the map one branch at a time. Rayito can highlight the current path while explaining why another branch does not need to wait. The visual should reduce the amount you have to remember, especially when several people use different names for the same deliverable.
Keep uncertain estimates separate
A dependency map and a schedule solve related but different problems. Add estimated durations only when you have a basis for them. Show uncertainty as uncertainty, and include waiting time for reviews or approvals when it affects the plan.
Do not let a tidy diagram turn a rough guess into a commitment. Before sharing a revised date, confirm assumptions with the people doing the work. An assistant can make a proposed sequence easier to inspect; it cannot know another person’s capacity from the visible board alone.
Update the real work after agreeing on the plan
Finish with a short decision: the next action, the expected output, and the person who will confirm it. Then update the project tool you actually use. A drawing on the screen does not automatically change assignments, due dates, or notifications in that tool.
If you explicitly request an app action, review the selected target and proposed change. Otherwise, treat the map as a shared explanation. Revisit the conversation in History for context, and revise the map when a prerequisite changes rather than treating the first version as permanent.
A question to try“Show me what is blocking this deliverable. Separate real dependencies from tasks that could move in parallel, and help me identify the next decision.”