納期に間に合わない、という判断を何時、どのタイミングでするのか？
ということが、重要課題として存在します。

そこで、「遅れている時間を、このままでは取り返せない」
という判断が一番正確に行えるのは、
自社のプロジェクトチームが原因で起こる遅れ、ということになります。

そもそも、なぜ遅れてしまったのか？
という原因を、明らかにする必要があります。

例えば、メンバが3日間病欠で、その分遅れてしまったが、
今は復帰している、という場合、1人の3日間の工数だけ、遅れているのであれば、
この先も、どんどん遅れるとは考えなくていいでしょう。

それならば、この3日間の作業を、先に進んでいるメンバなど、
他のメンバ達で、埋め合わせができるかどうかを考えればいいわけです。

しかし、プログラム開発で、フレームワークに問題があり、
全員が少しずつ、予定スケジュールから延長しているような場合、
そして、効率が上がってこない、といった場合には、
前回お話ししたように、他社や他チームからメンバを借りてくる、
という方法が、一つの解法となるでしょう。

開発側の問題であれば、まだ何とか方法を見つけることはできるのですが、
時には、というより、大抵は、もっとまずいところに問題があるものです。

それは、お客様や外部のチームなど、自社でどうにもできない部分で
時間が止まってしまう、というような場合です。

そんな時、プロジェクトマネージャーは、自社チームのメンバが、
不安にならないような仕事の割り振りをしながら、
お客様や他社との折衝を続ける必要があります。

こういった時には、無理やり何かをさせよう、進めようとしても、
思い通りにはいかないことが多いものです。

では、どうしたらいいのでしょうか。

1つめの提案は、スケジュールを見直してもらうという方法です。

これは、自社が理由でない場合には、提案しやすいものですし、
何故遅れているのか、という原因を明示してもらうためにも、
また、関係者が（特にお客様や他社が）
現在の遅れをどのように考えているのかを知るためにも、必要なことでしょう。

自分の会社は、スケジュール通りにやっていれば問題なし。
というわけではないのですから。

2つめの提案は、遅れていてもスケジュールの見直しをしない、出来ない、
ということであれば、とにかく、何を先に出来るのか？を考え、
それが、無駄になろうとも、どんどん進めていくしかない、と考えています。

スケジュールが遅れてしまっている場合には、
「相手に確認して、答えが出てからでないと無駄だから・・・」
とか、「打ち合わせでOKが出たことをやるしかない」という考え自体が、
むしろ足をひっぱり、更にどんどん遅れていく結果になるものなのです。

SEやプログラマというのは、「まだ決まっていない」未決事項について、
考えることさえ、ストップしてしまうことが多いようです。

システム開発というものは、決まってからしか進めないものばかりなのでしょうか？

頭の中でどこまで考え抜くか、資料を読み抜くか、
提案ドキュメントを作ってみるか、といったところは、実は、
打ち合わせがなくても、一人でもどんどん進めることができるものなのです。

1つ決まってから次に進む。

といったシークエンシャルな仕事の仕方というのは、実は、
自分を甘やかしているだけで、本当はできることが限りなくあるものなのです。

実は、そこで考え抜いたことや、作ったドキュメントといったものは、
仕事が再開するときには大きな財産となり、会議中のすばやい判断や、
詳細への突っ込みといったものを、可能にするネタとなるのです。

自社以外の理由で開発が遅れている、ストップしているときは、
作業をすることを無駄だと思わずに、

「勝手に作業を進め、ドキュメントを作っておく」

それが、作業の無駄ではなく、むしろシステムそのものへの深い考察を育て、
その後の時間の短縮に繋がるのです。