上司から報告を求められて、正確に報告しようと思っていたら「早くしろよ！」と怒られて
次回は早く報告したら「全然情報足りてないじゃねぇか」と怒られて
次回は早く情報漏れがないように報告したら「間違いだらけじゃねぇか」と怒られて

・・・ってことありませんか？

早く、正確に、漏れなく報告を求められたらこれは無理ゲーというか、負けイベなんです。

情報共有のジレンマ

情報共有においては「早さ」「正確性」「網羅性」の内二つしか満たすことはできないということです。

27th Annual FIRST Conference (2015), Lightning Talk: “Four Easy Pieces”, Tom Millar (US-CERT, NIST)

元々はセキュリティにおける情報の要素を述べたものですが、日本のセキュリティ団体であるISOG-Jが取り上げた際に「情報共有のジレンマ」と名付けたようです。
セキュリティインシデントにおける情報共有についての話題ではありますが、普段のホウレンソウにおいても同じことが言えると思います。

つまり報告を「早く」「正確に」「漏れなく」報告することは最初から無理なんです。

報連相における重要性

これは報告をする側(主に部下)も報告を受ける側(主に上司)も意識すべきことであると思います。

上司側は何を優先しているのかを明確にし「今は正確でなくてもいいから一次情報が欲しい」「時間が許す限り情報を集めろ」等、ケースによって要望を伝えるべきであり、
部下に対して「早く」「正確に」「漏れなく」報告しろ！ということ自体が愚かな行為ということを認識すべきです。

・・・ただ、現実問題そう物わかりのいい上司ばかりでもないし
部下から『情報共有のジレンマって知ってます？「早く」「正確に」「漏れなく」なんて無理なんですヨ！』とか上司に言える状況が必ずあるとは限りません。
というか全部上司のせいにするのも思考停止気味ではあります。

対策：返却値とコールバック

もちろん単純に「今って早さ正確性網羅性どれ求めますか？」とケースごとに聞くのも一つの手です。

ただソフトエンジニアサイトのQiitaっぽくいうと
報告する側としてはプログラムで言うところの返却値とコールバックを意識するようにすべきです。
プログラムにおいて主に時間がかかる長い処理においては関数を呼び出しても「わかったよ、あとで言うな」「今すぐわかる情報はこれな」とだけ返却値で返します。
そして非同期処理で「終わったよ。依頼されてた情報はこれな」あるいは「中間報告な、今はこの状況だよ」とコールバックで返します。

報告に置いても同じですよね。
早く、正確に、網羅的な情報は無理なので、正確に網羅的な報告に時間がかかりそうなときは
まずは早く
「不正確な情報ですが現時点ではこうです。ここの検証はXXまでに報告します」
あるいは
「途中経過ですがここまで終わった分を報告します。残りはXXまでに報告します」
と正確性か網羅性を捨てた一次報告を早くすべきです。（可能なら目途を添えて）
そして残りの一つが満たされた時点で残りの報告をすべきです。

似ている話

データベースにおいてCAP定理というものがあります。
以下の３つの内二つしか満たせないというものです。
一貫性 :Consistency
可用性 :Availability
冗長性(分断許容) :Partition-tolerance

分断耐性とはデータベースをひとつのサーバーだけではなくいくつかの分散サーバーを持った状態のことで、冗長性を保ち障害に耐えられるようにした構成のことです。

ここで高可用性はサーバーが楽観的排他制御などロックをしない状態とすると「早さ」と言い換えることもできる（？）と思います。
一貫性は全てのデータベースで統一された最新の情報を持っている状態、つまり「正確性」と言えるかと思います。
冗長性を情報が失われないような漏れがない状態を保つと捉えれば

最後は特にちょっと無理やりですが・・・
情報のジレンマの話を知った時、CAP定理に似ているなぁと思ったという次第です。