日次、週次、月次、年次のようなサイクルのあるミッションではなく、１つのミッションに対してリソースの割り当て、成果を求めるのがプロジェクト。
過去にいろいろなプロジェクトに関わった。
成功したプロジェクト、半ばで方向転換が余儀なくされたプロジェクト、リソースを食いつくし、リリースはしたものの、課題が残ったプロジェクト。
プロジェクトを推進していくのは、もちろんプロジェクトの構成員全員であるが、方向性や成功に導くのは、プロジェクトマネージャーの力量によるところが大きいと思う。
プロジェクトの立案、目的、それぞれのマイルストーン、リソースの確保と割り当て、全体の進捗管理、成果物の承認、最後にプロジェクトのクローズだ。
プロジェクトの規模が大きくなると、当然１人でこれらをまかなうことは不可能であるので、メンバーに権限を委譲したり、統括をして、それぞれのタスクを推進していくことになる。
委譲するにしても、目的、期日、成果物を明確に示す必要がある。
委譲されたメンバーが、プロジェクトマネージャと意識なりを共有していれば問題は発生しないと思いがちだが、結局、成果物を提示されたとき、マネージャーが思い描いていたもので無かった場合、無駄なリソースを費やしてしまったことになる。
プロジェクトの責任者は、最終的にはプロジェクトマネージャーなのだから当然といえば当然。
タスクの中で、「顧客との仕様調整」という項目もある。
実はこれが一番の曲者。
プロジェクトを企画する場合、それぞれのタスクと想定見積もりを山積みするわけだが、ここの部分がかなりぶれるところ。
顧客としてみれば、少ない費用で、多くを求めるし、技術者としてみれば、より斬新な方法で機能を実装してみたくなる。営業としてみれば、少ない費用で顧客の要求を満足させたいし、保守の都合から、枯れた(もとい熟成された)方法によって実装してほしい。
ここらへんを予算との兼ね合いで、大局的に判断して方向性を示すのがプロジェクトマネージャーの役割になっていること場合が多いと思う。
というか、プロジェクトマネージャーは、プロジェクトに対して、リソースを持っているし、与えられたリソースに対して、成果を提示する義務があるから、当然といえば当然である。
ただ、プロジェクトマネージャの役割として確実にいえることは、
プロジェクト計画を提示する
日程を提示する
具体的なタスクを提示する
タスクに対して委譲する権限を明確にする
それぞれのタスクに対するリソースを提供する
それぞれのタスクであがった成果物に対して承認をする
プロジェクトをクローズする
それぞれについてソツなくこなしても、プロジェクトは成功するとは限らない。
不本意ながら、敗戦処理というタスクを作成しなければならない場合もある。
※そんな場合はプロジェクトマネージャーが交代させられて・・・の場合が多いが(笑)
一度立ち上げたプロジェクトは、結果はどうであれ、必ずクローズしなければならない。
結果が不本意に終わったとしても、プロジェクトで作成された成果物やプロジェクト推進の過程を見直してみると、次のプロジェクトに生かせる場合が多いからだ。
自分の場合、プロジェクトマネージャーとして関わったプロジェクトは、リソースとなるメンバーの力量があったからか、よほどの大敗は経験していない。
毎回、プロジェクトをクローズするときに、苦労をわかちあったメンバーと共に、おいしい酒を酌み交わしたいものだと思っている。