2013/07/09

プロジェクトマネジメント101 その1


前回のエントリーで、プロジェクトマネジメントスキルがなぜ新規事業開発にとって重要なのかを書いた。

参考:

なぜ突然プロジェクトマネジメントの重要性を喧伝するに至ったかというと、実に単純な理由で先日プロジェクトマネジメントの研修を受けたからなのだ。
研修で学んだことはアウトプットして実践しなければ身についかないとういことで、研修で学んだプロジェクトマネジメントのプランニングの基本について、簡単にまとめてみたい。

基本的に自分自身のためのメモに過ぎないが、読んだ方に多少なりとも示唆があれば幸いだ。


プロジェクトマネジメントという言葉を定義する

プロジェクトマネジメントは、プロジェクトをマネージ(管理)するための技術だ。
では、そもそもプロジェクトとは何なのか。

プロジェクトとは、ある目的を達成するために計測可能で期限が定められた目標を立て、限られたリソースをフル活用して目標を達成し、目的を実現させる営みのことだ。
プロジェクトマネジメントは目的の実現のために正しい目標を立て、限られたリソースで期限内に目標を達成するためにの技術ということになる。

プロジェクトマネジメントの現実的な利便性

プロジェクトマネジメントは難しい技術であるし、この技術さえあればどんなプロジェクトでもサクサク完璧にこなせるというものではない。
むしろ、プロジェクトを暗礁に乗り上げさせないための最低限のフレームワークと思ったほうが良い。

決して確かな結果を約束してくれる技術ではあるが、身に着けていればいざプロジェクトを任された時に、何から手をつければ良いか分からない、どれだけの予算が必要なのか分からない、いつ頃までに完了できそうなのか検討もつかない、誰に何をしてもらえば良いのか分からず指示が出せない、という一歩も踏み出せない事態は防げる。

1. プロジェクト定義

プロジェクトの始まりではまずプロジェクトを定義することが最初の一歩だ。
このプロジェクトが何のために行われるのか、誰が関与しているのか、いつまでに行われるべきなのか、どの程度のものが出来上がっていればいいのか、そもそもなんでやらなければならないのか。
こうした基本的な問いに答えてくれるのがプロジェクト定義を資料に落とし込んだプロジェクト定義書だ。

プロジェクト定義書はプロジェクトメンバー全体の意思疎通のためにも必要不可欠だ。
小規模なイベント程度のものであれば口頭で済まされることもあるかもしれないが、数十人、数百人が関わるようなプロジェクトでは文書化された定義書がなければ、誰もが上に挙げたような問いを持ち、失敗に終わるだろう。
メンバー全体が共通の目標のために自分に課された役割を果たす土台として、共有されなければならないのがプロジェクト定義なのだ。

また、プロジェクト定義書には新たに参加したメンバーや途中からプロジェクトに携わるチームへ、プロジェクトの概要を円滑に伝えるためのツールになる。
規模によってはプロジェクトリーダーがひとりひとりにプロジェクト定義を伝えて回ることはできない。
そんな場合にしっかりと作られたプロジェクト定義書があれば、リーダーの代わりにプロジェクトの概要を新メンバー達に伝えてくれる。

1.1 プロジェクト定義書の作り方

どんなプロジェクトでも、まずきっかけとして得たい理想=目的がある。
プロジェクト定義書には目的が必要不可欠ではあるが、それだけでは不十分だ。

一般的なプロジェクト定義書に必要な項目を下記に並べてみよう。
ポイントは、内容が決定していない項目があるとすれば、決定していないという事実を伝えることだ。
プロジェクトによっては、予算や制約条件が未確定で、それらを調査することから始まるプロジェクトだってありえるからだ。

<背景>
なぜそのプロジェクトが組成されたのか、その目的を達することによって得たいことは何か、といった情報。
途中から参加するメンバーにとっては背景情報があるないではプロジェクト方針への理解度が全然違ってくる。

<目的>
このプロジェクトが完了した時に得たい現実。
数値化されたり計測可能なこととは限らない(むしろ少ないだろう)。
例えば、新しい事業を3年以内に立ち上げる、というのが新規事業プロジェクトの目的だ。

<目標>
目標は、それが達成されていれば目的が実現されているであろう、計測可能なゴールのことだ。
例えば、新しい事業を3年以内に立ち上げるという目的の目標は、3年以内にあるマーケットで10%の売上シェアを獲得する、というのが目標だ。
目標の置き方を間違えると、目標を達成して目的が実現しないという乖離が起こりかねないので、目標の置き方は非常に重要だ。

<ステークホルダー>
このプロジェクトと利害関係にある人々。
プロジェクトオーナーを始め、メンバー、協力者、受益者など。
できれば、各ステークホルダーがこのプロジェクトに参加する目的、得たい利益、などを分析しておくと、利害関係で衝突することを避けられる。

<成果物>
このプロジェクトから生み出されるあらゆるアウトプット(商品やマーケティングプラン、会議議事録なんてものまで)を予め書き出しておく。

<前提条件>
プロジェクトを実行する上で、ここまではやるけどここからはやらない、というスコープを定める。
前提条件はいくらでも洗い出そうとすれば洗い出せるが、プロジェクトに関連することだけを洗い出そう。
あるプロジェクトではマーケットは日本国内だけであると前提条件に書き加えることが必要なこともあるが、あるプロジェクトでは全く不要な場合もあるだろう。

<制約条件>
このプロジェクトで使えるリソースの制限や、スコープを制限する外的要因をここで記述する。

<期限>
目標が満たされている状態がいつまでに達成されていれば良いのか、日時を定める。

<予算>
どれだけ人、モノ、金が使えるのか、上限額を記述する。

<スケジュール概要>
詳細なスケジュールはプロジェクト計画で記述されるが、大まかなマイルストーンがプロジェクト定義書にも記述されているべきだろう。


関連エントリー
2013/7/11 プロジェクトマネジメント101 その2
2013/7/12 プロジェクトマネジメント101 その3
2013/7/8 新規事業開発にもプロジェクトマネジメントの考え方を



0 件のコメント :

コメントを投稿

LinkWithin

Related Posts Plugin for WordPress, Blogger...