危機プロジェクトでは，進ちょく管理の方法に問題があるため，プロジェクト・マネージャが正確な実態を把握できていないことも多い。
先に登場したCCSの梅澤氏は，危機支援に入ったあるプロジェクトの進ちょく会議に参加して唖然としたことがある。その会議でプロジェクト・マネージャはチーム・リーダーから作業の進ちょくを聞き，遅れているとその作業のスケジュールを機械的に延長するだけだった（図7左）。
「進ちょく会議で本来やるべきことは進ちょくが遅れた原因を明らかにしてその場で対策を講じること」と梅澤氏は指摘する。そこで梅澤氏は，工程が遅れた理由を突き止め，それに対して「どんな手順で，どこまでできたらよしとするか」まで決めたうえでスケジュールを再作成した。
また，前出のローリーコンサルティングの文山氏は「作業の進ちょくを数値化して一喜一憂しているプロジェクト・マネージャが多すぎる」と嘆く。文山氏は，プロジェクト・マネージャとして危機支援に入ったプロジェクトの進ちょく管理では，「プログラムの単体テストが50％完了」といった数値による報告を，一切受け付けないという。何を根拠に50％としているか，はっきりしないからだ。個々の作業が終わったか，終わっていないかだけを問題にする（図7 右）。
特にプロジェクトの成否にかかわる重要な作業については「なぜそれで終わったと言えるのか」と担当者に質問し，併せてやり残している作業がないかも確認する。
ホワイトボードで問題を把握
もちろん，進ちょくを正確に把握するのは容易ではない。先に挙げた自動車リサイクルシステム開発プロジェクトで，JAMAが「開発支援チーム」を新設したとき，各ベンダーの担当者は当初，自社の問題がオープンになることをためらっていた。「かえって責任が増すのでは」という懸念からだ。
このときに効果的だったのは，「問題をオープンにするのは担当者を責めるためではない」点を明確にしたことだ。実際，JAMAの笹野氏は「各ベンダーに『責任追及のためでは決してない』と説明して協力を求めた」と話す。
ある金融機関の開発プロジェクトのプロジェクト・マネージャを務めていたソランの大嶌康浩氏（エンタープライズソリューション事業部 eワイヤレスエンジニアリンググループグループマネージャ）も，開発現場で各メンバーが問題を自分自身で抱え込んでしまい，正確に進ちょくを把握できない問題に遭遇したことがある。これも小規模だが火事と言える。
そこで大嶌氏は，すべてのメンバーの目に留まりやすいよう，プロジェクト・ルームの出入り口にホワイトボードを設置。メンバーに問題を書き出してもらうようにした（図8）。ポイントは，問題を書く前に「この作業は完了」といった良い報告をまず書いてもらうこと。良い報告を書くと問題点も書きやすくなるからだ。「以前は問題の解決策をメールで流しても，見ていないメンバーが多かった。ホワイトボードは必ず目に入る。その結果，助け合いの雰囲気が出てきた」とチーム・リーダーの小和田浩司氏は話す。
