プロジェクトマネージャが頑張るタスクと頑張らないタスク


今朝は、iTunesで買ったTridentのBlue Field - Singleを駅からオフィスまでヘビロテしてまだ聴いているという嵌りようです。一応、youtubeも貼っておきましょう。



プロジェクトをやっていると、いや、普通の仕事でも、かもしれませんが、頑張るタスクとテキトーに暴れない程度に泳がしておくタスクとあるんですね。何よりプロジェクトでは、タスクのコントロールを間違うと命取りとはいかなくても全体のスケジュールにインパクトを与えてしまって自分で自分の首をジワジワと絞めてしまうことだってあるんです。


はい。経験済みです。あれはしんどかったし、やらなくてよいことだったなーって。トラウマと言えばトラウマ。学びと言えば学び。あれ以来、その自分で自分の首を絞めてしまったパターンを感じると途端に全力で回避に走ります。


それは何か。スケジュールですね。スケジュールのdue dateをぎりぎりにしない、ということです。WBSの中でもクリティカルパスと呼ばれるプロジェクトのスケジュールの背骨になるような、頭から終わりまでWBSの依存関係を繋いで一本の線になるアレです。アレの一部のタスクのdue dateまでに顧客が仕様を決められなくて、それでいていい顔をしたくてつい、

「まだ若干大丈夫です。」


なんて言ってしまって、そのあとの進捗がどうも捗々しくないWBSがあってよく見たら

「(これクリティカルパスだった……。)」


って気づいて、今手についているWBSの工数見積もりを“理想日”で見積もりなおして、WBSごとのバッファを寄せ集めて“プロジェクトのバッファ”として積み上げて、それで凌いだという。
#それをCCPMと知ったのは後のことです。


翌週の顧客との週次定例では速攻で、

「もう、余裕ないです。今日決めましょう。」


と宣言してしまいました。はい。顧客も態度をはっきりした方がとても協力的になってくれて、

「(だったらもっと早く宣言すればよかったんジャン?)」


ておもっても後の祭りというか、その後の行動のための良い経験になりましたけど。まぁ、大事に至らなかったから、ですが。


プロジェクトマネージャとして頑張るタスク
今思えば、あのスケジュールのdue dateのコントロールはプロジェクトマネージャとして頑張るところだったんですね。いくら優秀なメンバがいても、WBSの難易度が高いとか、製品への慣れ具合だとか、ビルドの完成度とか、サポートのレスポンスとかスケジュールを足元から引っ張る要因はいくらでもあるんですね。


そうした、自分で、プロジェクトマネージャとしてコントロールできない要素が不確定なものなのか、コントロールされている環境下にあるのかを見極めることが限りあるプロジェクトマネージャのリソースをどこにフォーカスするかを判断していくポイントになるんだと、実体験をもって学んだわけです。ある意味、身を削っているので覚えは確かです。はい。


なので、今、スケジュールに関するプロジェクトの実行プランだとか見積もり時の提案プランだとかを見るとき、そういった時間軸を揺るがすような要素があるかないか、そういった視点で見るようにしているんです。


まぁ、スケジュールだとスケジュールにするために積み上げたWBSをエンジニアの要員計画を鑑みて山崩しをしてた上で平準化した時も、それぞれで変換する箇所が抜け漏れはもちろん、前提を追加しながら変換していくところに見積もりのバグを混入する危険性があることから、そうしたところでは別の視点で精査が必要です。


プロジェクトマネージャが頑張るタスクは、今のようにスケジュールにインパクトを与えるタスクなわけですが、その要素にからむ“交渉”が絡むものは、とても大事なアクティビティなんです。交渉が必要な時点でプロジェクトマネージャ自身でコントロールできない要素を含んでいる=カウンターパートナがいることであって、それは、双方での合意を見ないと物事が進まないわけで。


まぁ、それも結局はスケジュールにインパクトを与えるので最終的に帰結するところは同じなんですが、交渉自体、一つ間違えると落としどころを間違えることになるのでとても力と思考が必要なタスクなんですね。なので、交渉ごとはとても大事だし、大掛かりなことでなくても些細なことの積み重ねがスケジュールにインパクトを与えることになるので、小さくても交渉要素になるようなことは気を抜かないで頑張らないといけないんですね。


プロジェクトマネージャががんばらないタスク
プロジェクトマネージャが頑張るタスクは先のようなコントロールできない要素を含んだタスクなのだから、ある意味見切れたタスクはチェックポイントだけ気にして後は放置プレイでもいいと思っています。ただ、放置するとしてもdeliverable、つまり、成果物を作成するようなタスクであれば品質確保は外せないので、そうした品質確保のアクティビティになっているかのウォッチは欠かせませんけど。