プロジェクトオーガナイザの吉田聖書です。
プロジェクトの計画を立てる時に、
「あれ、プロジェクトの範囲ってどこまでだろう？」
って迷う時があります。
それはプロジェクトの特性によって違うので、
ここで整理してみたいと思います。
この疑問は、いつも同じような特性の
プロジェクトを担当している場合には
あまり湧いてこないかもしれません。
プロジェクトには様々なものがありますが、
今のところ大きく2種類に
分けられるのではないかと考えています。
それは定常業務に引き継がれるプロジェクトと
そうでない一過性のプロジェクトです。
新ビジネスとか新商品などの
新企画のプロジェクトの場合は前者で、
ビジネス上の施策を定常業務で行うわけですが、
その準備としてプロジェクトが計画され、
準備が完了したら、定常業務に引き継ぎ
プロジェクトは終わります。
プロジェクトの成果物は
定常業務に必要なリソースなので、
WBSは準備すべき成果物を分解したもの
ということになります。
ふりかえりをする場合、
プロジェクト活動そのものの評価と、
その後の定常業務によって行われる
施策の効果に対する評価があり、
それぞれの評価タイミングは異なります。
効果を評価するタイミングでは
もはやプロジェクトは解散しているでしょう。
一方、後者のプロジェクトというのは、
例えば、会社名やロゴの変更、
オフィスの移転、M&Aを含む組織変更、
社員旅行や種々のセレモニーなどです。
これもイベント系と非イベント系に分かれます。
その組合せということもあるでしょうから、
実際の観点としては
イベントの有無で判断することになります。
イベントがないものは一番簡単で、
最終成果物を完成させれば終了です。
プロジェクト活動の評価は速やかに行われますが、
施策の効果については、その特性によって
いつ評価すべきかが異なります。
ここまでは良いかと思います。
問題はイベントがあるプロジェクトの場合です。
ポイントは、イベントそのものを
プロジェクト活動とみなすのかということです。
イベントは、準備とイベント自体とで
動く人も人の動きも異なると思いますので、
イベント自体の計画はWBSではなく、
時間帯ごとの役割分担を明記した
タイムテーブルが良いかと思います。
準備するリソースにタイムテーブルを含め、
イベント自体の進行管理は
タイムテーブルに沿って行います。
全体スケジュールには、
イベント後の後始末も忘れずに。
後始末の計画は、WBSというよりは
準備したものを最終的にどう処理するかを
スケジュール化すれば良いと思います。
この場合のふりかえりは、
基本的には後始末が終わってから
プロジェクト活動そのものの評価と
プロジェクトの成果、つまり
施策としての効果の評価を
同じタイミングで行います。
以上の点を押さえていれば、
イベントそのものがプロジェクト活動の範囲かどうかは
どちらでもあまり変わりません。
イベント自体がプロジェクト活動ではなく
準備ができた時点で終わりとするなら、
プロジェクトの成果物は
イベントに必要なリソース
ということになろうかと思います。
でも、イベント自体も
プロジェクト活動に含まれるとするなら
プロジェクトの最終成果物を
定義するのはちょっと難しいので、
その場合はちょっと工夫して、イベントを
マイルストーンの1つと位置付けます。
そうすれば、イベントに必要なリソースを
マイルストーンの成果物とみなせるので
そこまでのWBSは作ることができます。
プロジェクトの最終成果物とは
言えないかもしれませんが、
計画すべきWBSとしてはそれで充分です。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。