プロジェクトの進捗は全体のクリティカルパスとそれの進捗を脅かすタスクのモニタリングとコントロールだけを見ればいい

プロジェクトのチームをプロジェクトの目的を達成するために要求するチームとしてのスキルセットとして編成したチームのメンバは、チームとして必要とするスキルセットを一人ひとりが持っていることは現実ではありえなくて一人ひとりが持っているスキルの専門とスキルレベルを組み合わせることで構成するんですね。

なぜ、プロジェクトが要求するスキルセットを持っているメンバでチームが現実ではありえないか。それは、高コストとそういった人はニーズが高いので他のメンバとチームで売るからですね。コストの原価の話もあるし、メンバ育成の観点もあるし。

じゃあ、プロジェクトチームが一人ひとり様々なスキルとレベルを持っていているときに何をプロジェクトマネージャは考えておかないといけないのでしょうか。

WBSのタスクをアサインするやり方には、それぞれのメンバが持っているスキルの専門を最大限に効率良くを狙うアサインの仕方とタスクの担当を自主的に手を挙げてもらってアサインするやり方とあります。ほとんどは前者のやり方を取っているのではないでしょうか。だって、プロジェクト最適化を考えますからね。ただ、前者の場合はSPOFやトラックナンバーと呼ばれる人に技術を依存してしまうことが起き、技術とリソースが結びつく複合のリスクをどのようにコントロールするかプロジェクトマネージャは考え策を取らないといけないんですが。

進捗が遅れる原因
進捗が遅れる原因は、他責を主因とする環境的なものと担当するメンバ自身に由来するものと分別することができます。前者では、仕様を判断できないリーダや顧客、コミュニケーションの問題、アウトプットの仕様を決めずに始めてしまう文化、などなどが挙げられます。

一方、後者は担当するタスクで必要とするスキルエリアとスキルレベルと担当するメンバが持っているスキルエリアとスキルレベルのミスマッチが挙げられます。

担当するメンバが見積もりをする場合で、見積もり自体の精度が悪いというケースは、要求される見積もり精度に応えられるために必要とする技術レベルを持っていないために見積もり自体を誤ってしまうというケースが起こります。

端的に言えば、タスクを割り当てる時点ですでに進捗が遅れる可能性をプロジェクトマネージャが自ら犯しているということが言えます。

進捗はモニタリングとコントロール
じゃあどうすればいいのか、って話ですよね。進捗が遅れる原因を作らせないことが必要ですね。そしたリスクの原因を発生しないような環境を作ること、その予兆がないかをモニタリングして兆しがあればすぐに対処すること、そうした地味な落ち葉拾い的な仕事をしないといけないのです。

あと、メンバの本当時実力を知らないとタスクにアサインすること自体が賭けになってしまいます。いくら環境を整えてもメンバの実力を知っていないでアサインしてしまっては意味がありませんから。

初めてチームを組むメンバなら小さなタスクを渡して仕事の早さ、要求に対するアウトプットの品質レベル、途中のコミュニケーション力を知るテスト的なアサインが必要です。プロジェクトマネージャは、できるだろうではなく、できることを担保にアサインしなければなりません。

なぜなら、プロジェクトマネージャの仕事はプロジェクトをプロジェクトの目的を達成して完了させることだから。

そのためにはメンバの進捗実績を積み重ねてプロジェクトの予定完了日がプロジェクトのスケジュールとしての要求を満たしているか、スケジュールとして見通しを立てられないといけないのです。

その観点で見ることができれば、進捗管理は、タスクのモニタリングとコントロールが主な活動テーマであることがわかります。予定の工数ではいつも足らなくなるメンバがいればそうなってしまう原因がどこかにあるのでそれを発見することだけをすればいいのですし、そうしたことを発見するモニタリングをすればいいのです。

こうしたモニタリングとコントロールは、全部のタスクをする必要はありません。あ、全体館として押さえておく必要はありますけど、全員のメンバを満遍なくやる必要はないです。全体の進捗の阻害となるタスク、アテンションが必要なメンバのタスクだけをウォッチするのです。

満遍なくタスクを見て対処していたらそれだけでプロジェクトマネージャの時間がなくなってしまいますから。