How to resolve poor project communication: identify the roots of missing information, misunderstandings and delays
Start with one handoff that went wrong, rather than the general complaint that nobody communicates. Choose a concrete result: a colleague used an old delivery date, a reviewer returned the wrong document, or a decision arrived after work had begun. Reconstruct what was available to each person at the moment they acted. The useful question is where the information first stopped supporting the next action. Missing information, misunderstanding and delay can occur together. A late correction does not prove that the original message was late, and a message marked read does not prove that its meaning was understood. The method below is an editorial way to investigate an incident, not a new reporting system. Use records the team already has.
Freeze the incident before explaining it
Write down the expected action, the actual action and the point at which they differed. Keep the original message and the version of the document it referenced; today's corrected file cannot show what a colleague saw yesterday. Record an unknown time as unknown rather than filling it from memory. If people remember events differently, place both accounts beside the dated records. Ask about the work in question, not whether someone is generally attentive. A small, bounded incident is easier to verify than a collection of unrelated complaints.
Find out whether the necessary information existed
Check whether the sender already knew the fact before the recipient needed it. If a delivery date had not yet been agreed, the gap was an unresolved decision, not a failure to distribute an agreed date. If the fact existed, locate its first recorded version and the person expected to receive it. A name omitted from the recipient list, an inaccessible attachment and an absent acceptance condition are different gaps. Ray Boedecker's PMI article emphasizes knowing who needs information and when to ask or inform; it does not make sending a message equivalent to completing the handoff.
Compare meanings only after comparing versions
Ask each participant to describe the action they believed was requested. Compare the object, deadline, completion condition and any dependency. For example, “ready on Thursday” might mean ready for internal review to one person and ready to send externally to another. This is an illustrative example, not a reported company case. First make sure both people actually saw the same wording. Different document versions point to a distribution problem before they point to an interpretation problem. APM's communication guidance supports attention to audience, message, method and timing; the incident review identifies which of these needs attention here.
Locate the wait instead of calling everything late
Put the time information became available, the time it was sent, the time it could be accessed and the time it was used on one line. Compare these with the agreed time it was needed. A quick reply can still arrive too late for the work, while a next-day reply may meet an agreed schedule. If there was no agreed response time, record that absence rather than inventing a missed commitment. Then check what was waiting: access, clarification, specialist review, available capacity or authorization. A delay in approval needs evidence about the decision role, not an assumption about someone's willingness to answer.
Test the explanation against a counterexample
Before choosing a correction, ask what would make your explanation wrong. If the colleague received the current file and accurately described the requested action, more reminders would not address the remaining obstacle. If a reviewer provided advice but could not approve the change, the wait may concern authority. Atlassian's DACI guidance separates contributors from the person making the decision; the team's existing authority remains the reference. Do not impose DACI merely to investigate this incident. Also check whether the next task would have remained blocked by missing materials or workload even with a perfect message.
Close the review with one supported change
Summarize the first evidenced break, the consequence and the smallest correction tied to it. An omitted recipient might need inclusion at that specific handoff; an ambiguous completion condition might need a concrete example agreed by both sides. Name who will make the correction and inspect the next comparable handoff for the same failure. If evidence is incomplete, state what still needs checking. This review ends with a supported explanation and a testable adjustment. Designing an entire information-sharing or escalation process is a separate task, and should follow only when repeated incidents show a wider need.